WCAG 2.2.3: Geen timing

Wat Deze Regel Betekent

WCAG 2.2.3 — No Timing bevindt zich op het AAA-conformiteitsniveau onder Richtlijn 2.2: Voldoende Tijd. De eis is direct: tijd mag geen essentieel onderdeel zijn van een gebeurtenis of activiteit die aan de gebruiker wordt gepresenteerd. Met andere woorden, als je content of functionaliteit een tijdslimiet, deadline of tijdkritische interactie van welke aard dan ook bevat, moet die tijdsafhankelijkheid óf verwijderbaar zijn óf volledig irrelevant voor de uit te voeren taak — tenzij een van de beperkte uitzonderingen van toepassing is.

Dit criterium gaat verder dan criterium 2.2.1 (Timing Adjustable) op niveau A en criterium 2.2.2 (Pause, Stop, Hide) op niveau AA. Terwijl die eerdere criteria instelbare of pauzeerbare tijdslimieten toestaan, vereist 2.2.3 dat timing simpelweg helemaal niet bestaat als betekenisvolle beperking. Een gebruiker die tien seconden of tien minuten nodig heeft om een formulier in te vullen, een menu te doorlopen of een workflow te voltooien, moet tot hetzelfde resultaat komen als een gebruiker die onmiddellijk klaar is.

Wat telt als een voldoende resultaat: Content waarbij geen tijdslimiet bestaat, of waarbij een eventuele tijdslimiet puur cosmetisch is en geen invloed heeft op de uitkomst (bijvoorbeeld een animatie die in een lus afspeelt maar interactie niet verhindert). Content die volledig functioneel blijft ongeacht hoe lang de gebruiker nodig heeft, voldoet aan dit criterium.

Wat telt als een onvoldoende resultaat: Sessie-time-outs die gebruikers na inactiviteit uitloggen; getimede quizzen of toetsen waarbij de score of voltooiing afhangt van afronden binnen een bepaalde tijd; timers voor het verlopen van winkelwagens die items verwijderen; veilingbiedinterfaces met aftelklokken die het bieden sluiten; velden voor eenmalige wachtwoorden (OTP) die verlopen; CAPTCHA-uitdagingen met tijdslimieten; en elk interactief element dat onbeschikbaar wordt of automatisch verzendt op basis van verstreken tijd.

Officiële uitzonderingen gedefinieerd door WCAG: Het criterium sluit expliciet twee categorieën uit. Ten eerste, real-time-uitzonderingen — gebeurtenissen waarbij timing absoluut inherent is aan de activiteit, zoals een live veiling, een live uitzending of een real-time multiplayergame. Ten tweede, essentiële uitzonderingen — situaties waarin het verwijderen van de tijdslimiet de activiteit fundamenteel zou veranderen. Een typevaardigheidstest meet bijvoorbeeld inherent snelheid, dus timing is essentieel. Ontwikkelaars en producteigenaren moeten echter streng zijn: gemak, technische legacy of zakelijke voorkeur kwalificeren niet als “essentieel”. De lat ligt bij de vraag of de activiteit haar kernbetekenis of -doel zou verliezen zonder de tijdsbeperking.

Het is belangrijk op te merken dat gesynchroniseerde media — zoals een vooraf opgenomen video met ondertiteling — ook is uitgesloten, omdat timing bij mediweergave wordt beheerd door de mediaspeler van de gebruiker en geen beperking oplegt aan het vermogen van de gebruiker om met de rest van de pagina te interageren.

Waarom Het Belangrijk Is

Tijdslimieten op het web schaden gebruikers met een brede reeks beperkingen in onevenredige mate. De impact is niet abstract — voor veel gebruikers is een getimede interface in de praktijk een ontoegankelijke interface.

Gebruikers met motorische beperkingen — waaronder mensen die schakelbedieningsapparaten, mondstokken, oogvolgsoftware of andere alternatieve invoermethoden gebruiken — werken in een fundamenteel ander tempo dan muis-en-toetsenbordgebruikers. Het invullen van een meerstapsformulier of het navigeren in een dropdownmenu kan meerdere keren zo lang duren. Een sessie-time-out of een automatisch verlopen winkelwagen kan minuten aan zorgvuldig, inspannend werk in één klap tenietdoen.

Gebruikers met cognitieve beperkingen, waaronder dyslexie, ADHD, verwerkingsstoornissen en niet-aangeboren hersenletsel, hebben mogelijk aanzienlijk meer tijd nodig om instructies te lezen, opties te begrijpen of antwoorden te formuleren. Onderzoek dat is verzameld door het Web Accessibility Initiative schat dat cognitieve en leerstoornissen in een of andere vorm ongeveer 15–20% van de wereldbevolking treffen. Voor deze gebruikers is een afteltimer niet alleen stressvol — hij belemmert actief de cognitieve verwerking die nodig is om de taak te voltooien.

Screenreader-gebruikers die blind zijn of een beperkt gezichtsvermogen hebben, navigeren lineair door content en moeten interface-elementen sequentieel beluisteren of lezen. Het begrijpen van de structuur en opties op een complexe pagina kost meer tijd dan voor een ziende gebruiker die visueel scant. Een getimede checkout-flow die verloopt terwijl een blinde gebruiker zorgvuldig de besteloverzicht controleert, vormt een directe barrière voor e-commerce.

Gebruikers met angststoornissen kunnen ervaren dat de loutere aanwezigheid van een afteltimer voldoende cognitieve en emotionele belasting creëert om taakvoltooiing te verhinderen, zelfs als ze technisch gezien genoeg tijd hebben. Het verwijderen van timing als factor verwijdert deze barrière volledig.

Een concreet scenario uit de praktijk: Stel je een online bankportaal voor dat een time-out na vijf minuten inactiviteit gebruikt, gecombineerd met een OTP die na zestig seconden verloopt. Een gebruiker met de ziekte van Parkinson die ondersteunende invoertechnologie nodig heeft om te typen, of een oudere gebruiker die niet gewend is snel tussen apps te wisselen, kan het fysiek onmogelijk vinden om de sms te ontvangen, van applicatie te wisselen, de code te lezen, terug te schakelen en deze binnen de toegestane tijd in te voeren. Ze worden buitengesloten van hun eigen account — niet door een veiligheidsnoodzaak, maar door een willekeurige tijdsbeperking. Door de OTP langer geldig te laten blijven (of de harde vervaldatum te verwijderen ten gunste van een “opnieuw verzenden”-mechanisme) wordt het probleem opgelost zonder de veiligheid in gevaar te brengen.

Los van toegankelijkheid verbetert het verwijderen van onnodige tijdsbeperkingen de algemene bruikbaarheid en vermindert het het aantal afgebroken sessies. Een e-commerce-checkout die niet halverwege verloopt, behoudt meer klanten, verhoogt de conversie en vermindert de ondersteuningslast — waardoor dit zowel een zakelijk positieve verandering is als een ethische noodzaak.

Gerelateerde Axe-core-regels

WCAG 2.2.3 vereist handmatige tests. Geen enkele geautomatiseerde axe-core-regel komt direct overeen met dit criterium, en dit is een belangrijke architecturale realiteit om te begrijpen.

• Handmatige test vereist — Sessie- en interactietiming: Geautomatiseerde tools kunnen niet detecteren of een webapplicatie een tijdslimiet afdwingt, omdat timinglogica wordt geïmplementeerd in sessiebeheer aan de serverzijde, JavaScript-timers of back-end API-responses — die geen van alle zichtbaar zijn in statische DOM-analyse. Een tool als axe-core inspecteert de gerenderde HTML en de toegankelijke boom; hij kan niet waarnemen dat een fetch-request na vijf minuten inactiviteit een 401 zal retourneren, of dat een JavaScript-setTimeout de gebruiker naar een uitlogpagina zal omleiden. Alleen een menselijke tester die langzaam met de applicatie interageert en observeert wat er gebeurt, kan bepalen of er tijdsbeperkingen bestaan en of deze de taakvoltooiing beïnvloeden.
• Handmatige test vereist — OTP- en CAPTCHA-verval: Eenmalige wachtwoorden en tijdgebonden verificatie-uitdagingen verschijnen in de DOM als gewone invoervelden. De afteltimer, indien zichtbaar, kan een eenvoudige tekstnode of een CSS-geanimeerd element zijn. Axe kan niet afleiden dat het invoeren van een waarde in dit veld na negentig seconden zal resulteren in een foutstatus. Een tester moet bewust wachten tot na het vervalvenster en proberen te verzenden om te bevestigen of timing wordt afgedwongen.
• Handmatige test vereist — Automatisch verzenden en automatisch doorlopende formulieren: Sommige interfaces gaan automatisch naar de volgende stap of verzenden een formulier na een periode van inactiviteit of na een vaste duur (bijvoorbeeld een enquête die na dertig seconden naar de volgende vraag gaat). Axe-core zal dit niet markeren omdat de DOM-structuur geldig lijkt; het problematische gedrag manifesteert zich alleen tijdens daadwerkelijke interactie in de tijd.
• Handmatige test vereist — Verloop van transacties en reserveringen: Timers voor het reserveren van winkelwagens, ticketreserveringen en blokkeringen van afspraaksleuven worden geïmplementeerd via serverlogica en worden in de UI alleen weergegeven als een aftelweergave. Geautomatiseerde tools zien een getal dat op het scherm wordt bijgewerkt, maar kunnen niet bepalen of dit gegevensverlies of toegangsweigering veroorzaakt wanneer het nul bereikt.

Hoe te Testen

1. Geautomatiseerde baselinescan: Voer axe DevTools of Lighthouse uit op de pagina om gerelateerde timingovertredingen op lager niveau te identificeren (zoals die onder 2.2.1 of 2.2.2) die je kunnen wijzen op gebieden die diepere handmatige inspectie vereisen. Hoewel geen enkele axe-regel 2.2.3 direct test, kunnen bevindingen rond waarschuwingen voor tijdslimieten of automatisch vernieuwen je handmatige auditscope sturen. Bekijk in Lighthouse de sectie “Accessibility” op tijdgerelateerde meldingen.
2. Maak een inventaris van alle tijdsafhankelijke functies: Breng vóór het testen systematisch elke functie in de applicatie in kaart die met timing te maken kan hebben. Dit omvat: sessiebeheer en inactiviteits-time-outs; velden voor OTP en verificatiecodes; reserveringen van winkelwagens of boekingen; getimede quizzen, toetsen of enquêtes; veiling- of biedinterfaces; CAPTCHA-uitdagingen; mechanismen voor automatisch opslaan met inzendvensters; en elke zichtbare aftel- of voortgangstimer.
3. Test gedrag bij sessie-time-out: Open de applicatie en begin een taak die meerdere stappen omvat (bijvoorbeeld het invullen van een meerpaginaformulier of het voltooien van een checkout). Interageer niet gedurende een periode die langer is dan het vermoedelijke time-outvenster. Probeer vervolgens door te gaan. Observeer of je voortgang behouden blijft, of je wordt gewaarschuwd en de mogelijkheid krijgt om je sessie te verlengen, of dat je wordt uitgelogd of gegevens verliest. Een voldoende resultaat vereist dat óf geen time-out bestaat, óf de time-out puur preventief is en gegevens worden behouden na opnieuw aanmelden, óf dat de gebruiker voldoende waarschuwing en controle krijgt.
4. Test OTP- en codeverval: Start een OTP- of verificatiecodeflow. Wacht tot na de aangegeven vervaltijd van de code (of langer als er geen tijd wordt weergegeven). Probeer de code in te voeren. Als het systeem deze uitsluitend vanwege tijd afwijst, is dit een schending van 2.2.3. Let op: een “opnieuw verzenden”-mechanisme alleen lost 2.2.3 niet op — het vervallen van de oorspronkelijke code legt nog steeds timing op.
5. Screenreader-testen (NVDA + Firefox): Navigeer met NVDA en Firefox door elke getimede interface met alleen het toetsenbord en de screenreader. Let op hoe lang elke stap duurt met de extra navigatietijd van ondersteunende technologie. Ga bewust in een langzaam tempo te werk — pauzeer om alle instructies te beluisteren, verken alle opties via de virtuele cursor — en probeer vervolgens te verzenden of door te gaan. Controleer dat trage navigatie geen time-out of verlies van status veroorzaakt.
6. Screenreader-testen (VoiceOver + Safari op macOS): Herhaal dezelfde test met langzame navigatie met VoiceOver op macOS en Safari. Let in het bijzonder op dynamische afteltimers: kondigt VoiceOver de resterende tijd aan op een manier die urgentie creëert, en faalt de interface wanneer de tijd om is?
7. Screenreader-testen (JAWS + Chrome): Test dezelfde flows met JAWS en Chrome. JAWS-gebruikers vormen een aanzienlijk deel van de professionele screenreader-gebruikers; timingproblemen die NVDA-gebruikers treffen, zullen doorgaans JAWS-gebruikers in gelijke mate treffen.
8. Controleer de legitimiteit van uitzonderingen: Documenteer voor elke timing die het ontwikkelingsteam als “essentieel” of “real-time” bestempelt de rechtvaardiging en beoordeel of de timing werkelijk inherent is aan het doel van de activiteit, of dat deze versoepeld, verlengd of verwijderd kan worden zonder de fundamentele aard van de taak te veranderen.

Hoe te Oplossen

Sessie-time-out — Onjuist

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Sessie-time-out — Juist

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Verlopend OTP-veld — Onjuist

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Verlopend OTP-veld — Juist

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Getimede quiz — Onjuist

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Getimede quiz — Juist

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Veelvoorkomende Fouten

• Aannemen dat sessiebeveiliging een harde time-out vereist: Veel teams implementeren korte inactiviteits-time-outs onder verwijzing naar beveiligingseisen, maar de meeste beveiligingsstandaarden (waaronder PCI-DSS en OWASP) staan gebruikersgestuurde sessieverlenging toe. Een harde uitlog zonder waarschuwing of mogelijkheid tot verlenging is een toegankelijkheidsfout, geen beveiligingsnoodzaak.
• Een afteltimer weergeven zonder een manier te bieden om deze te stoppen of te verlengen: Het toevoegen van een aria-live-regio aan een afteltimer maakt het erger voor screenreader-gebruikers — hij kondigt elke seconde aan — zonder het onderliggende timingprobleem op te lossen. De oplossing is de beperking te verwijderen, niet om deze toegankelijker aan te kondigen.
• “Code opnieuw verzenden” behandelen als oplossing voor OTP-verval: Het bieden van een knop om de code opnieuw te verzenden stelt gebruikers in staat een nieuwe code te krijgen, maar pakt niet aan dat de oorspronkelijke code door timing is verlopen. De tijdslimiet is nog steeds aanwezig. De juiste oplossing is het verlengen van het geldigheidsvenster om tijdsdruk te elimineren.
• Automatisch doorschuiven van carrousel- of wizardstappen na inactiviteit: Meertrapsformulieren of wizards die automatisch naar de volgende stap gaan na een ingestelde tijd, leggen een tijdsbeperking op. Gebruikers die instructies lezen of over hun antwoord nadenken, worden benadeeld. Stappen mogen alleen doorgaan op expliciete gebruikersactie.
• Timers voor winkelwagens die items verwijderen zonder ze te bewaren: Reserveringstimers in e-commerce (“Je winkelwagen verloopt over 15 minuten”) voldoen niet aan 2.2.3 wanneer items permanent verloren gaan bij het verlopen in plaats van simpelweg uit reservering te worden vrijgegeven. Op zijn minst moeten items worden opgeslagen in een verlanglijst of moet de sessie herstelbaar zijn.
• De “real-time-uitzondering” te ruim toepassen: Een interface als “real-time” bestempelen om tijdsbeperkingen te rechtvaardigen wanneer deze niet echt live is. Een vooraf opgenomen veilingreplay, een statische biedinterface of een quiz die slechts op een spelshow lijkt, komt niet in aanmerking voor de real-time-uitzondering.
• Timing in back-end API-responses negeren: Teams lossen timers aan de front-end op maar zien over het hoofd dat de API zelf verzoeken afwijst die na een bepaald venster worden gedaan. De gebruiker ziet geen aftelklok, maar zijn inzending faalt stilzwijgend. Sessiebeheer aan de back-end moet in lijn zijn met de ervaring aan de front-end.
• setTimeout gebruiken voor automatisch uitloggen zonder formulierstatus op te slaan: Wanneer automatisch uitloggen onvermijdelijk is (bijvoorbeeld vanwege wettelijke vereisten), betekent het niet opslaan van de formuliergegevens van de gebruiker vóór omleiding dat al het werk verloren gaat. Op zijn minst moet conceptstatus worden opgeslagen en na opnieuw aanmelden worden hersteld.
• 2.2.1-naleving verwarren met 2.2.3-naleving: Het bieden van een bediening om uit te schakelen, aan te passen of te verlengen (zoals vereist door 2.2.1 niveau A) voldoet niet aan 2.2.3. Niveau AAA vereist dat timing niet essentieel is — niet alleen beheersbaar. Een tijdslimiet met een royale verlenging blijft een tijdslimiet.
• Timing in ingesloten componenten van derden over het hoofd zien: Ingesloten chatwidgets, betalingsverwerkers, identity-verificatie-SDK’s en kaartdiensten kunnen hun eigen tijdsbeperkingen introduceren. Herkomst van derden ontslaat deze niet van WCAG-toepasselijkheid wanneer ze in je interface zijn geïntegreerd.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt een nationaal raamwerk voor webtoegankelijkheid vast dat WCAG 2.2 als technische basis hanteert. De circulaire verplicht naleving voor een brede reeks entiteiten die digitale diensten in Turkije aanbieden.

De typen entiteiten die onder de regeling vallen, omvatten overheidsinstellingen en -organen, e-commerceplatforms, banken en financiële diensten, ziekenhuizen en zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE). Deze organisaties moeten voldoen aan de toegankelijkheidsnormen die in of via de circulaire zijn gedefinieerd wanneer zij digitale diensten aan het publiek leveren.

WCAG 2.2.3 — No Timing is een criterium op niveau AAA, en de Presidential Circular 2025/10 verplicht, net als de Europese norm EN 301 549 waarmee zij in lijn is, conformiteit op niveau A en niveau AA als wettelijke ondergrens. Naleving van niveau AAA is geen directe wettelijke verplichting binnen dit kader. Het bereiken van niveau AAA — en specifiek het implementeren van 2.2.3 — wordt echter erkend als een kenmerk van een zeer volwassen toegankelijkheidsniveau en toont een oprechte inzet voor inclusieve vormgeving die verder gaat dan de minimale wettelijke drempels.

Voor bepaalde typen entiteiten, met name banken en financiële diensten die onder toezicht van de BDDK opereren, en e-commerceplatforms met hoge transactievolumes, zijn tijdsbeperkingen zoals OTP-verval, sessiebeheer en timers in checkout-flows wijdverbreide functies. Zelfs waar 2.2.3 niet wettelijk vereist is, creëert het niet aanpakken van tijdsbarrières in deze flows een reëel discriminatierisico — vooral naarmate de Turkse handhavingsmechanismen voor toegankelijkheid volwassen worden en klachtenprocedures beter worden ingebed.

Overheidsinstellingen en zorgaanbieders die mensen met een beperking, oudere gebruikers en gebruikers met lage digitale vaardigheden bedienen, hebben een bijzonder sterke ethische reden om tijdsbeperkingen volledig te elimineren. Het verwijderen van tijdslimieten uit digitale overheidsdiensten en zorgportalen sluit aan bij de bredere e-government-inclusiedoelen van Turkije en vermindert het risico op toekomstige regulatoire blootstelling naarmate AAA-adoptie in aanbestedingen in de publieke sector gebruikelijker wordt.

Organisaties die hun digitale producten als volledig inclusief willen positioneren — of dat nu is voor nationaal leiderschap, toegang tot internationale markten of aanbestedingsvoordelen in de context van de Europese Unie (waar EN 301 549 en de European Accessibility Act van toepassing zijn) — moeten naleving van WCAG 2.2.3 zien als een strategische investering in plaats van een optionele verbetering.