SC 2.2.1: Tijdslimiet van 8 uur

[julezrulez]

Situatieschets

Een overheidsorganisatie beschikt over een registratiesysteem waar mensen bij bedrijven kunnen inloggen en gegevens kunnen opzoeken en vastleggen. Eenmaal ingelogd krijg je een sessie van 8 uur (als je niet zelf uitlogt en afsluit). Je kunt in die 8 uur meerdere keren dezelfde taak uitvoeren. Na 8 uur word je er onherroepelijk uitgelogd.

Het lijkt erop dat deze applicatie op SC 2.2.1 (Timing aanpasbaar) terecht is afgekeurd.
Ik heb de punten rondom de tijdslimiet uit het succescriterium inclusief de wensen en eisen van de overheidsorganisatie op een rijtje gezet.

• Uitzetten: In verband met security-eisen is 8 uur het maximum.
• Aanpassen: In verband met security-eisen is 8 uur het maximum.
• Verlengen: Je zou in theorie de sessie-timeout op 44 minuten kunnen zetten. Na 440 minuten heb je dan 10x een melding kunnen presenteren. In de laatste sessie bereik je de 8 uur (=480 minuten). Tussentijdse melding of uitloggen is echter niet gewenst gezien de aard van het werk.
• Real-time uitzondering is hier niet van toepassing.
• Essentiële uitzondering is hier niet van toepassing.
• 20 uur uitzondering: In verband met security-eisen is 8 uur het maximum.

Doel van dit succescriterium

Er staat: "Dit succescriterium helpt om ervoor te zorgen dat gebruikers taken kunnen voltooien zonder onverwachte veranderingen in content of context die het resultaat zijn van een tijdslimiet.".
De huidige tijdslimiet biedt de gebruiker nu de mogelijkheid om de taak (het registratieproces) meerdere keren binnen de 8 uur uit te voeren. Op basis hiervan lijkt er een hiaat te zitten in dit succescriterium.

Vragen

Vraag van de overheidsinstantie:
Op welke wijze kunnen wij aan SC 2.2.1 (Timing aanpasbaar) voldoen?

Mijn vraag:
De aard van de applicatie (beperkte groep, sessie van 8 uur (kantoortijd?), taak meer dan 1x uitvoerbaar) geeft mij het gevoel dat er ruimte moet zijn om dit soort applicaties niet af te hoeven keuren op dit punt. Zou SC 2.2.1 aangepast of aangevuld moeten worden omdat binnen de aard van de applicatie en de doelgroep 8 uur nu een redelijke tijd is om minimaal 1x de taak uit te voeren?

[rianrietveld]

Interessent, als veiligheid een conflict geeft met WCAG.
Ik kan me die 8 uur goed voorstellen, de sessie is gelding voor 1 werkdag.

[rvantonisse]

Goeie usecase!

In dit geval zou ik de sessie informatie duidelijk aan de gebruiker communiceren. Bijvoorbeeld wanneer je het gebruikersmenu / sessie menu opent.
En ruim van te voren aangeven wanneer de sessie tot een einde komt met een alert / blijvende banner oid. Dan kan de gevruiker daar op besluiten of opnieuw inloggen nodig is om de taak af te ronden.

Je kan het proces van uit te voeren taakeventueel tijdelijk bewaren, zodat je na inloggen verder kan waar je gebleven was.

Er is ruim tijd om de uit te voeren taak meermaal uit te voeren. En met eventueel bovenstaande toe te passen oplossing, is dit denk ik een goede om de "pas toe of leg uit" regel te gebruiken bij het opstellen van de verklaring.

Deze regel valt ook niet onder de non-interference clausule, dus een goed alternatief zou ik bovenstaande oplossing vinden. Alszijnde Er is voldoende informatie aanwezig mbt de maximale sessie.

[Aircl0wn]

Je noemt meermaals de security eisen, maar neemt dit niet mee als essentiële uitzondering?

We hebben hier gisteren wat uitgebreider over gesproken, maar de situatie an sich is natuurlijk al wat vreemd.
Als iemand om 7 uur inlogt, dan moet er tegen het einde van de dag nogmaals worden ingelogd, anders haal je de gebruikelijke werkdag lengte niet eens (een situatie die bij dit specifieke systeem veelvuldig van toepassing gaat zijn, en daarna is het systeem dus tot midden in de nacht ingelogd (iig op de systemen die nooit uitgezet worden, en dat zijn er bij bedrijven best veel).

Waarom de sessie niet korter maken en automatisch verlengen bij acties? Uiteraard met nog een dialog voor als de timer wel verloopt, zodat iemand alsnog op verlengen kan klikken. Daarmee is het SC makkelijk haalbaar en hun beveiliging, wat ze blijkbaar belangrijk vinden, gaat erop vooruit.

[Thomas-Machielsen]

Ik ben de literatuur nog niet helemaal door gegaan maar ISO27001 (security) heeft ook ergens een tijdslimiet. Mocht er iemand al wat weten hoe deze 2 standaarden naast elkaar kunnen leven, graag. Anders kijk ik hier deze week even naar.

Het lljkt een conflict of interests te zijn

[erikkroes]

Knuppel in het hoenderhok, maar waarom moet toegankelijkheid hier in schikken, en niet security?

[DanielleCuppen]

Omdat niemand geholpen is met een onveilige, maar toegankelijke oplossing! Dus zeker streven naar evenwicht maar security zou altijd op 1 moeten staan.

[rianrietveld]

@julezrulez
Het geldt voor een "onderdeel van een pagina", ik neem aan een formulier.
Wat nu als de gegevens die je wijzigt bewaard worden, je vantevoren goed geïnformeerd wordt over de uitlogprocedure en je na weer inloggen verder kunt gaan met waar je mee bezig was.

Overvang je dan niet:

"This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit."

Het is niet onverwacht, je weet het van tevoren en langer dan 8 uur voor een formulier invullen, is dat realistisch?
Ik zou hier soepel mee omgaan. Want dit lijkt me buiten de echte betekenis van het SC:

"Users have adequate time to complete tasks."

[sander-nl]

Waarom kan de organisatie dit niet in de toegankelijkheidsverklaring noemen? In de trant van "We weten dat we niet aan dit succescriterium voldoen, maar onze interne veiligheidseisen geven geen mogelijkheid om de tijdslimiet aan te passen of uit te zetten" of iets dergelijks.

Dit is namelijk een keuze die de organisatie zelf heeft gemaakt. Voldoen aan veiligheidseisen maakt nog niet dat het ook voldoet aan WCAG. Ik ken niet alle details en discussies achter dit succescriterium, maar uit de Understanding begrijp ik dat veiligheid wel is meegenomen. Zie "Notes regarding server time limits".

[BartCardan]

Dit is inderdaad een erg interessante.
Van de ene kant zie ik de noodzaak om vast te houden aan de security-vereisten.
Van de andere kant is het succescriterium nou eenmaal gebaseerd op 20 uur en niet op 8 uur.

Voor beiden is veel te zeggen. Ik vraag me wel af waarom toegankelijkheid zou moeten schikken voor security en of er dan niet nog meer redenen zijn waarom we maar niet toegankelijk zouden hoeven te zijn omdat er misschien andere redenen zijn.
Ook vraag ik me af of 8 uur in alle situaties wel ideaal is (wat Ronny zegt).

De organisatie kan er natuurlijk altijd voor kiezen om op dit punt te verklaren dat ze een B-status hebben, maar ze willen vast een perfecte A-status hebben. (Wat Sander zegt)

Puur inhoudelijk. Het succescriterium vereist dat de gebruiker weet dat ie wordt uitgelogd en dat ie dan vervolgens dit kan uitschakelen, aanpassen of verlengen. Daar wordt op dit moment niet aan voldaan, terwijl er wel aan voldaan kan worden, namelijk door de tijdslimiet (al dan niet virtueel) aan te passen naar 10 periodes van 48 minuten (zoals je zelf al schetst).
Je geeft aan dat tussentijds melden niet gewenst is. Ik ken natuurlijk de situatie niet, maar ik vraag me af waarom niet?

Ik vind de optie van Roel ook wel goed. Niemand zegt hoe die melding er uit moet zien. Als je een (niet-storende) melding toont bovenaan het scherm kan de gebruiker gewoon door gaan. Het succescriterium vereist dat door een "simpele actie" je kan verlengen. Wat nou als we zeggen dat "doorwerken in de applicatie" een simpele actie is. Daarmee geef je indirect aan dat je namelijk verder bent en dat je wilt verlengen. In de praktijk betekent dit min of meer dat je automatisch aan het verlengen bent. Dat lijkt mij een mega "simpele actie" zoals in het succescriterum wordt verreist.