WCAG 2.0 - Succescriterium 2.2.1 Timing aanpasbaar

Bedoeling van dit Succescriterium

De bedoeling van dit Succescriterium is om te garanderen dat gebruikers met functiebeperkingen, waar mogelijk, voldoende tijd krijgen om interactie aan te gaan met webcontent. Mensen met functiebeperkingen als blindheid, beperkt zicht, motorische stoornissen en cognitieve beperkingen hebben meer tijd nodig om content te lezen of functies uit te voeren als het invullen van een webformulier. Als webfuncties tijdsafhankelijk zijn, hebben sommige gebruikers er moeite mee om de vereiste actie te ondernemen voordat zich een tijdslimiet voordoet. Hierdoor kan de dienst voor hen ontoegankelijk worden. Het ontwerpen van functies die niet tijdsafhankelijk zijn, zal mensen met functiebeperkingen helpen om deze met succes uit te voeren. Het bieden van mogelijkheden om tijdslimieten uit te zetten, de lengte van tijdslimieten aan de eigen behoefte aan te passen, of meer tijd te vragen voordat zich een tijdslimiet voordoet, helpt gebruikers die meer tijd nodig hebben dan verwacht om taken met succes af te ronden. Deze opties zijn gerangschikt naar nut voor de gebruiker. Het uitzetten van de tijdslimieten is beter dan het aanpassen van de lengte ervan, wat weer beter is dan meer tijd vragen voordat zich een tijdslimiet voordoet.

Elk proces dat na een bepaalde tijdsduur of periodiek plaatsvindt zonder gebruikersinitiatief is een tijdslimiet. Hieronder vallen onder meer gedeeltelijke of complete updates van content (bijvoorbeeld het verversen van een pagina), veranderingen in content of het verlopen van de tijd waarbinnen een gebruiker kan reageren op een verzoek om invoer.

Ook wordt hieronder content verstaan die in een hoger tempo opschuift of wordt ververst dan de gebruiker kan lezen en/of begrijpen. Met andere woorden: geanimeerde, bewegende of scrollende content stelt een tijdslimiet in op het vermogen van de gebruiker om content te lezen.

In sommige gevallen is het echter niet mogelijk om de tijdslimiet te veranderen (bijvoorbeeld bij een veiling of andere real-time gebeurtenissen) en daarom gelden er voor die gevallen uitzonderingen.

Opmerkingen over tijdslimieten van de server

• Getimede verwijzingen van de server kunnen hieronder bij Veelgemaakte fouten worden gevonden.

• Tijdslimieten van de server zoals het verlopen van de logintijd worden behandeld in Succescriterium 2.2.5 .

• Niet-getimede verwijzingen van de server (bijvoorbeeld 3xx response codes) zijn niet van toepassing, omdat er geen tijdslimiet is: ze werken direct.

• Dit Succescriterium heeft alleen betrekking op tijdslimieten die door de content zelf worden ingesteld. Over tijdslimieten die extern voor content zijn ingesteld, zoals door de user agent of door factoren die intrinsiek aan internet zijn, heeft de auteur geen zeggenschap en deze limieten vallen niet onder de conformiteitseisen van WCAG. De auteur zou wel zeggenschap moeten hebben over tijdslimieten die zijn ingesteld door webservers. Deze tijdslimieten worden behandeld in andere Succescriteria.

• Tien keer de standaardinstelling werd gekozen op basis van klinische ervaring en andere richtlijnen. Als de gebruiker bijvoorbeeld 15 seconden krijgt om te reageren en een schakelaar over te halen, zou 150 seconden voldoende zijn om vrijwel alle gebruikers in staat te stellen een schakelaar over te halen, zelfs als ze problemen ondervonden.

• De 20 seconden was eveneens gebaseerd op klinische ervaring en andere richtlijnen. Vrijwel alle gebruikers hebben genoeg aan 20 seconden om een willekeurige schakelaar over te halen, met inbegrip van die gebruikers met spasticiteit. Sommigen zouden er niet genoeg aan hebben, maar voor sommigen zouden geen enkele tijdsduur genoeg zijn. Er is een redelijke periode nodig om meer tijd te vragen, aangezien een willekeurige tijdslengte bij sommige applicaties veiligheidsrisico's voor alle gebruikers kan inhouden, met inbegrip van degenen met functiebeperkingen. Bij kiosken of terminals die worden gebruikt voor financiële transacties, komt het bijvoorbeeld vaak voor dat mensen weglopen zonder uit te loggen. Dit maakt hen kwetsbaar voor degenen die na hen komen. Door een lange periode van inactiviteit toe te staan alvorens naar aanwezigheid te vragen en dan een lange periode te bieden waarin de persoon kan bevestigen aanwezig te zijn kan er misbruik worden gemaakt van terminals. Als er geen activiteit plaatsvindt, zou het systeem moeten vragen of de gebruiker aanwezig is. Het zou iemand vervolgens moeten vragen om zijn/haar aanwezigheid te bevestigen ('druk op een willekeurige toets') en dan zo lang moeten wachten dat vrijwel iedereen kan reageren. Voor "druk op een willekeurige toets," zou 20 seconden voldoende zijn. Als de persoon aangeeft nog aanwezig te zijn, zou het apparaat de gebruiker naar exact dezelfde toestand moeten terugbrengen die bestond voordat de vraag werd gesteld.

• De bovengrens van 20 uur werd gekozen omdat het langer is dan de totale tijdsduur die men gedurende een dag wakend doorbrengt.

In gevallen waarin timing geen intrinsieke eis is, maar de uitkomst ongeldig zou worden als gebruikers controle zouden krijgen over getimede gebeurtenissen, kan een derde partij de tijdslimieten voor de gebruiker instellen (bijvoorbeeld tweemaal zoveel tijd toestaan voor het maken van een toets).

Zie ook Begrijpen Succescriterium 2.2.3 Geen timing.