WCAG 2.2.6: Time-outs

Wat Deze Regel Betekent

WCAG 2.2.6 Timeouts (Niveau AAA) vereist dat gebruikers worden gewaarschuwd voor de duur van elke inactiviteit die gegevensverlies kan veroorzaken, tenzij de gegevens langer dan 20 uur gebruikersinactiviteit worden bewaard. In praktische termen betekent dit dat als je webapplicatie of -dienst gegevens van een gebruiker kan verliezen — zoals formulierinvoer, een winkelwagen of een lopende transactie — omdat de gebruiker gedurende een bepaalde tijd inactief is geweest, je gebruikers precies moet informeren hoe lang ze hebben voordat die gegevens verloren gaan.

Het criterium is van toepassing op elke situatie waarin een timeout resulteert in gegevensverlies. Veelvoorkomende voorbeelden zijn het verlopen van een sessie op bank- of overheidsportalen waardoor formuliergegevens worden gewist, winkelwagens die na een periode van inactiviteit worden geleegd, meerstapswizards of formulieren die worden gereset wanneer een sessiecookie verloopt, en online test- of boekingssystemen die gedeeltelijke antwoorden weggooien. De belangrijkste trigger is de combinatie van inactiviteit (niet een harde tijdslimiet voor het voltooien van een taak, die wordt gedekt door 2.2.1) en het gevolg van gegevensverlies.

Wat telt als een voldoende resultaat: Een pagina voldoet aan 2.2.6 als deze gebruikers aan het begin van een sessie — of voordat ze beginnen met het invoeren van gegevens — duidelijk informeert over de specifieke inactiviteits-timeoutduur die tot gegevensverlies zal leiden. Als alternatief voldoet een pagina als er geen gegevensverlies kan optreden, ongeacht hoe lang de gebruiker inactief is (bijvoorbeeld omdat de server alle formuliergegevens langer dan 20 uur, of onbeperkt, bewaart). Het weergeven van een waarschuwing pas nadat de sessie al is verlopen, voldoet niet aan het criterium.

Wat telt als een onvoldoende resultaat: Een pagina voldoet niet als deze stilzwijgend gebruikersgegevens verliest na een periode van inactiviteit zonder de gebruiker ooit over dit risico te informeren. De pagina voldoet ook niet als er wel een waarschuwing bestaat, maar deze pas wordt getoond op het moment van gegevensverlies (te laat om te handelen), of als de waarschuwing vaag is — bijvoorbeeld door te stellen dat "je sessie kan verlopen" zonder de daadwerkelijke duur van inactiviteit te specificeren die de timeout activeert.

Officiële uitzonderingen: Het criterium sluit expliciet situaties uit waarin gegevens langer dan 20 uur inactiviteit worden bewaard. De drempel van 20 uur is gekozen om gebruikers tegemoet te komen die een taak de ene dag beginnen en de volgende dag hervatten. Als je systeem alle ingevoerde gegevens server-side gedurende ten minste 20 uur betrouwbaar opslaat zonder dat de gebruiker actie hoeft te ondernemen, ben je niet verplicht een waarschuwing weer te geven. Daarnaast is dit criterium niet van toepassing op timeouts die essentieel zijn voor de beveiliging — bijvoorbeeld een harde wettelijke of regelgevende eis dat een sessie na een vaste periode moet worden beëindigd, ongeacht de acties van de gebruiker. In dergelijke gevallen moedigt het criterium nog steeds transparantie aan, maar erkent het de juridische beperking.

Waarom Het Belangrijk Is

Timeouts zonder adequate waarschuwing treffen in onevenredige mate mensen met cognitieve beperkingen, motorische beperkingen en mensen die blind zijn of een beperkt gezichtsvermogen hebben. Gebruikers met cognitieve beperkingen zoals dyslexie, ADHD of traumatisch hersenletsel hebben mogelijk aanzienlijk meer tijd nodig om instructies te lezen, tekst te formuleren of informatie te beoordelen voordat ze een formulier indienen. Als een sessie stilzwijgend verloopt terwijl zij nog aan het werk zijn, verliezen ze al hun inspanningen en moeten ze opnieuw beginnen — een diep ontmoedigende ervaring die ertoe kan leiden dat ze de taak volledig opgeven.

Mensen met motorische beperkingen die afhankelijk zijn van switch-toegang, oogvolgapparaten of andere alternatieve invoermethoden, interageren veel langzamer met interfaces dan een muisgebruiker. Het invullen van een lang schadeformulier voor een verzekering of een meerpagina’s tellende overheidsaanvraag kan voor hen vele malen langer duren dan de standaard sessietimeout veronderstelt. Zonder de afteltijd te kennen, hebben ze geen mogelijkheid om actie te ondernemen — zoals het opslaan van voortgang of het aanvragen van een verlenging — voordat hun gegevens verdwijnen.

Schermlezergebruikers worden ook geconfronteerd met een extra uitdaging: het navigeren door complexe formulieren kost meer tijd wanneer elk veld moet worden voorgelezen en met het toetsenbord moet worden bevestigd. Een sessie die verloopt terwijl een gebruiker nog systematisch een lang formulier doorloopt, is niet alleen ongemakkelijk — het kan uren aan inspanning vertegenwoordigen en een aanzienlijke barrière vormen voor toegang tot essentiële diensten.

Overweeg dit scenario uit de praktijk: een gebruiker met multiple sclerose vraagt via een overheidsportaal een arbeidsongeschiktheidsuitkering aan. Het formulier heeft 12 secties en vereist het uploaden van ondersteunende documenten. De sessie verloopt na 15 minuten inactiviteit, maar de gebruiker is halverwege sectie 7 gestopt om een document uit een andere kamer te halen. Bij terugkomst zijn alle gegevens gewist en moet diegene opnieuw beginnen — zonder voorafgaande waarschuwing dat dit zou gebeuren. Onder 2.2.6 zou het portaal verplicht zijn de gebruiker vanaf het begin te informeren dat inactiviteit van meer dan 15 minuten tot gegevensverlies zal leiden, zodat de gebruiker hierop kan anticiperen.

Los van toegankelijkheid verbetert het proactief bekendmaken van timeoutgedrag de gebruikerservaring voor iedereen en vermindert het uitvalpercentages in waardevolle conversiestromen zoals afrekenen, registratie en aanvraagformulieren. Het vergroot ook het vertrouwen, omdat gebruikers niet achterblijven met de vraag waarom hun gegevens zijn verdwenen.

Gerelateerde Axe-core Regels

WCAG 2.2.6 vereist handmatige tests. Er is geen geautomatiseerde axe-core-regel die deze overtreding kan detecteren, en begrijpen waarom dat zo is, is belangrijk voor testers en ontwikkelaars.

• Handmatige test vereist — Openbaarmaking van sessietimeout: Geautomatiseerde tools zoals axe-core kunnen de DOM scannen op de aanwezigheid of afwezigheid van specifieke elementen, attributen en tekstpatronen, maar ze kunnen niet bepalen of een webapplicatie gebruikersgegevens zal verliezen na een periode van inactiviteit. Het timeoutgedrag wordt doorgaans bepaald door server-side sessieconfiguratie (bijv. een PHP- of Node.js-sessie-TTL), en de openbaarmaking — als die bestaat — kan voorkomen in onboarding-tekst, een modaal dialoogvenster, een helppagina of zelfs een sectie met algemene voorwaarden. Geen enkele statische DOM-analyse kan een stuk informatieve tekst betrouwbaar correleren met het daadwerkelijke server-side timeoutgedrag. Een tool kan niet weten of een zin als "For your security, sessions expire after 15 minutes" accuraat is, van toepassing is op de gegevens van de huidige pagina, of vroeg genoeg in de gebruikersreis is gepositioneerd om bruikbaar te zijn. Alleen een menselijke tester die met de applicatie kan interageren, het gedrag in de tijd kan observeren en de volledigheid en timing van eventuele openbaarmakingen kan beoordelen, kan de naleving bepalen.
• Handmatige test vereist — Verificatie van gegevensbehoud: Axe-core kan ook de 20-uur-uitzondering niet verifiëren. Of gegevens daadwerkelijk langer dan 20 uur server-side worden opgeslagen — en dus of een openbaarmaking überhaupt vereist is — hangt volledig af van backendlogica die onzichtbaar is voor een browsergebaseerde scantool. Testers moeten ofwel de serverconfiguratie bekijken, met ontwikkelaars spreken, of empirisch testen door een gedeeltelijk ingevuld formulier gedurende een langere periode te laten staan en te observeren of de gegevens behouden blijven.

Hoe te Testen

1. Geautomatiseerde pre-scan: Voer axe DevTools of Lighthouse uit op de pagina met het formulier, de checkout-flow of een andere gegevensinvoerinterface. Hoewel geen van beide tools direct een 2.2.6-overtreding zal markeren, gebruik je deze stap om eventuele timeout-gerelateerde ARIA live-regio’s of dialoogcomponenten te identificeren die deel kunnen uitmaken van het waarschuwingsmechanisme, en verifieer je dat deze zelf toegankelijk zijn (juiste rollen, labels, focusbeheer).
2. Identificeer timeoutgedrag: Spreek met het ontwikkelingsteam of bekijk de server-side configuratie om de inactiviteits-timeoutduur voor de sessie te bepalen. Veelvoorkomende locaties zijn configuratiebestanden van de webserver, instellingen van applicatiesessiemiddleware en documentatie van authenticatieproviders. Noteer de exacte duur in minuten.
3. Controleer op voorafgaande openbaarmaking: Laad de pagina vers en lees alle inhoud die aan de gebruiker wordt gepresenteerd voordat met gegevensinvoer wordt begonnen. Zoek naar een duidelijke verklaring — in de paginabody, een inleidende paragraaf, een banner of een modaal venster — die de exacte inactiviteits-timeoutduur specificeert en aangeeft dat gegevens verloren gaan als de gebruiker gedurende die periode inactief is. De openbaarmaking moet de duur expliciet noemen (bijv. "15 minuten"), niet vaag (bijv. "korte tijd").
4. Test met een schermlezer: Gebruik NVDA met Firefox, VoiceOver met Safari of JAWS met Chrome en navigeer de pagina vanaf het allereerste begin. Bevestig dat elke timeout-openbaarmaking bereikbaar is en wordt voorgelezen door de schermlezer zonder dat de gebruiker deze actief hoeft op te zoeken. Als de openbaarmaking in een visueel prominente banner staat, verifieer dan dat deze in de leesvolgorde vóór het eerste formulierveld staat.
5. Simuleer inactiviteit: Begin met het invullen van het formulier. Stop vervolgens met interactie met de pagina gedurende een periode die iets korter is dan de timeoutperiode, en observeer wat er gebeurt. Herhaal dit vervolgens, waarbij je wacht tot na het verstrijken van de timeoutperiode. Noteer of gegevens verloren gaan, of er een waarschuwing wordt weergegeven voordat gegevensverlies optreedt, en of die waarschuwing is gecommuniceerd voordat de sessie begon.
6. Test de 20-uur-uitzondering: Als het team beweert dat gegevens langer dan 20 uur worden bewaard, verifieer dit empirisch door een formulier gedeeltelijk in te vullen, ten minste 20 uur te wachten en terug te keren naar de pagina om te bevestigen dat de gegevens nog aanwezig zijn. Of bekijk als alternatief samen met het ontwikkelingsteam de server-side configuratie van de sessieopslag.
7. Toetsenbord- en focustest: Als er een timeout-waarschuwingsdialoog of -melding verschijnt, verifieer dan met alleen toetsenbordnavigatie dat deze automatisch focus krijgt, dat de inhoud volledig leesbaar is en dat de gebruiker deze kan sluiten of actie kan ondernemen (bijv. de sessie verlengen) zonder een muis te gebruiken.

Hoe te Herstellen

Sessie met stilzwijgend gegevensverlies — Onjuist

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sessie met stilzwijgend gegevensverlies — Juist

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Checkout-sessie met vage waarschuwing — Onjuist

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Checkout-sessie met vage waarschuwing — Juist

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Gegevens server-side langer dan 20 uur bewaard — Juist (uitzondering van toepassing)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Veelvoorkomende Fouten

• De timeoutwaarschuwing alleen weergeven in de browserconsole of in een serverlogboek dat onzichtbaar is voor eindgebruikers — de waarschuwing moet in de gebruikersinterface worden gepresenteerd, op een plek waar de gebruiker deze zal tegenkomen voordat gegevensverlies optreedt.
• De openbaarmaking plaatsen in een footer, privacybeleid of pagina met algemene voorwaarden die gebruikers waarschijnlijk niet lezen voordat ze met gegevensinvoer beginnen, in plaats van direct op of vlak vóór het formulier zelf.
• Een modaal dialoogvenster gebruiken om gebruikers te waarschuwen voor een naderend verlopen sessie, maar nalaten de toetsenbordfocus naar het dialoogvenster te verplaatsen — gebruikers van toetsenbord en schermlezer merken mogelijk nooit dat de waarschuwing is verschenen.
• Een sessieduur vermelden (bijv. "je sessie duurt 30 minuten") in plaats van een inactiviteits-timeout (bijv. "na 15 minuten inactiviteit gaan je gegevens verloren") — dit zijn verschillende concepten, en alleen het door inactiviteit veroorzaakte gegevensverlies valt onder 2.2.6.
• Aannemen dat omdat er een timeout-waarschuwingsmodal bestaat voor ziende gebruikers, aan het criterium is voldaan — als de modal niet toegankelijk is via het toetsenbord, geen toegankelijke naam heeft of niet wordt aangekondigd via ARIA live-regio’s of focusbeheer, ontvangen schermlezergebruikers de waarschuwing niet.
• De server-side sessietimeout instellen op 25 uur en concluderen dat geen openbaarmaking nodig is, terwijl niet wordt geverifieerd dat de browser-side of applicatieniveau-status (bijv. een Redux-store of localStorage) niet eerder wordt gewist — de effectieve timeout is het mechanisme dat als eerste gegevens verliest.
• De timeoutduur bekendmaken in een tooltip die alleen door hover wordt geactiveerd — gebruikers die afhankelijk zijn van toetsenbordnavigatie of touchapparaten kunnen de openbaarmaking mogelijk nooit tegenkomen.
• Vertrouwen op een generieke CMS- of frameworkwaarschuwing "session expired" die wordt weergegeven nadat gegevensverlies al heeft plaatsgevonden, in plaats van gebruikers proactief te informeren voordat ze beginnen met het invoeren van gegevens.
• Geen rekening houden met gebruikers die het formulier in een achtergrondtabblad openen: als de sessietimer doorloopt terwijl het tabblad inactief is, kunnen gegevens verloren gaan voordat de gebruiker enige kans heeft gehad om met het formulier te interageren. Dit is vooral problematisch op mobiele browsers die achtergrondtabbladen agressief onderbreken.
• De waarschuwing weglaten in mobiele versies of progressive web app (PWA)-contexten terwijl deze wel wordt weergegeven in de desktopversie, waardoor een inconsistente ervaring ontstaat die 2.2.6 niet naleeft voor een aanzienlijk deel van de gebruikers.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Presidentiële Circulaire 2025/10 van Turkije, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende webtoegankelijkheidsverplichtingen vast voor een brede reeks publieke en private entiteiten die in Turkije actief zijn. De circulaire schrijft naleving van WCAG 2.2 voor als technische standaard, waarbij van betrokken entiteiten wordt verlangd dat zij minimaal voldoen aan Niveau AA. WCAG 2.2.6 Timeouts is een criterium op Niveau AAA en wordt daarom niet rechtstreeks verplicht door de basisvereisten van de circulaire. De reikwijdte en doelstelling van de circulaire creëren echter sterke praktische redenen voor betrokken entiteiten om AAA-naleving na te streven voor criteria zoals 2.2.6.

De entiteiten die onder Presidentiële Circulaire 2025/10 vallen, omvatten overheidsinstellingen en -agentschappen, e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en zorgaanbieders, telecomoperators met meer dan 200,000 abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE). Veel van deze sectoren exploiteren online portalen die precies de soorten gegevensinvoerworkflows omvatten die 2.2.6 beoogt te beschermen: leningaanvragen, patiëntintakeformulieren, ticketboekingssystemen, inschrijvingsaanvragen en aanvragen voor overheidsuitkeringen.

Voor banken en e-commerceplatforms in het bijzonder zijn sessietimeouts een routinemaatregel voor beveiliging, en de interactie tussen beveiligingseisen en toegankelijkheidsverplichtingen is direct relevant. Hoewel een bank een regelgevende verplichting kan hebben om inactieve sessies na een vaste periode te beëindigen, is het implementeren van WCAG 2.2.6 door de timeoutduur vooraf bekend te maken niet in strijd met die beveiligingseis — het vormt daarop een aanvulling. Gebruikers worden op de hoogte gebracht van de beperking zonder dat de bank haar sessiebeveiliging hoeft te verzwakken.

Zorgaanbieders en ziekenhuizen die onder de circulaire vallen, behandelen enkele van de meest risicovolle gegevensinvoertaken denkbaar — patiëntgeschiedenisformulieren, pre-autorisatieverzoeken en systemen voor het plannen van afspraken. Patiënten met cognitieve beperkingen of motorische beperkingen die halverwege een formulier hun gegevens verliezen, worden in deze context niet alleen geconfronteerd met frustratie, maar ook met mogelijke vertraging bij het ontvangen van zorg. Het implementeren van 2.2.6 in deze omgevingen is een directe uitdrukking van het inclusieve dienstverleningsmandaat dat ten grondslag ligt aan de circulaire.

Hoewel Niveau AAA niet wettelijk verplicht is, vertegenwoordigt het behalen ervan op criteria zoals 2.2.6 — die relatief weinig implementatie-inspanning vereisen (het toevoegen van één enkele, accurate openbaarmakingsverklaring aan een formulier) terwijl ze aanzienlijke voordelen opleveren voor kwetsbare gebruikersgroepen — een toegankelijkheidspraktijk van topniveau. Organisaties die hun inzet voor digitale inclusie op de Turkse markt willen aantonen, of die strengere toekomstige regelgeving voorzien, doen er goed aan 2.2.6 te behandelen als een praktisch implementatiedoel in plaats van een vrijblijvende ambitie.