WCAG 2.2.5: Opnieuw verifiëren

Wat Deze Regel Betekent

WCAG 2.2.5 Opnieuw authenticeren behoort tot Richtlijn 2.2 (Voldoende tijd) en is een Level AAA-vereiste. Het criterium stelt: "Wanneer een geauthenticeerde sessie verloopt, kan de gebruiker de activiteit voortzetten zonder verlies van gegevens na opnieuw te zijn geauthenticeerd." In praktische termen betekent dit dat als een gebruiker midden in het invullen van een formulier zit, een aankoop afrondt, een bericht opstelt of een andere taak met meerdere stappen uitvoert op een geauthenticeerd platform en de sessie verloopt, die gebruiker opnieuw moet kunnen inloggen en precies verdergaan waar hij of zij was gebleven — met alle eerder ingevoerde gegevens behouden.

Dit criterium hangt nauw samen met WCAG 2.2.1 (Tijd instelbaar, Level A) en 2.2.4 (Onderbrekingen, Level AAA), maar behandelt een specifieke situatie: het moment waarop een sessiegrens wordt overschreden. Waar 2.2.1 vraagt om gebruikers voldoende tijd te geven of hen toe te staan hun sessie te verlengen, behandelt 2.2.5 de faalsituatie — wat er gebeurt nadat de tijd is verstreken. De twee werken samen: idealiter verleng je zowel de sessie als dat je de gegevens bewaart als deze toch verloopt.

Een pass onder dit criterium vereist dat het platform alle door de gebruiker ingevoerde gegevens bewaart — tekstinvoer, geselecteerde opties, bestandsbijlagen, selectievakjes, keuzerondjes en elke andere formulierstatus — over een opnieuw-authenticatiegebeurtenis heen. Nadat de gebruiker opnieuw is ingelogd, moet hij of zij worden teruggebracht naar hetzelfde punt in de activiteit waarmee hij of zij bezig was, met de gegevens intact en de taak voltooidbaar zonder herhaling.

Een fail treedt op wanneer een sessietime-out een van de volgende situaties veroorzaakt: de gebruiker wordt doorgestuurd naar een inlogpagina en wordt na succesvol inloggen naar de homepage gestuurd in plaats van naar de pagina waarop hij of zij zich bevond; formuliergegevens die vóór de time-out zijn ingevoerd gaan verloren en de gebruiker moet alles opnieuw invoeren; de gedeeltelijk voltooide status van een wizard met meerdere stappen wordt gereset; of de gebruiker wordt simpelweg uitgelogd zonder mechanisme om opnieuw te authenticeren en te hervatten.

De officiële WCAG-specificatie definieert geen minimale sessieduur voor dit criterium — het is van toepassing ongeacht hoe lang of kort de time-outperiode is. Let echter op dat er geen uitzondering wordt gemaakt voor gegevensverlies om veiligheidsredenen; de verwachting is dat implementaties veilige manieren vinden om de status te bewaren, zoals server-side sessieopslag gekoppeld aan de identiteit van de gebruiker, of versleutelde client-side tokens die de opnieuw-authenticatiestroom overleven.

Waarom Het Belangrijk Is

Sessietime-outs die gegevens wissen, creëren een onevenredig zware belasting voor mensen met een beperking. Veel gebruikers met een beperking hebben aanzienlijk meer tijd nodig om digitale taken te voltooien dan hun niet-gehandicapte leeftijdsgenoten, en zij kunnen vaak niet simpelweg "sneller typen" of "om" een willekeurige time-out heen werken.

Gebruikers die blind zijn of een beperkt gezichtsvermogen hebben navigeren door formulieren met schermlezers, wat inherent langzamer is dan visueel scannen. Een blinde gebruiker die een lang schadeformulier voor een verzekering invult, kan 20 of 30 minuten besteden aan zorgvuldig veld voor veld navigeren, om vervolgens al het werk kwijt te raken wanneer een sessietime-out van 15 minuten afgaat. Hij of zij moet dan opnieuw beginnen — zonder garantie dat hetzelfde niet een tweede keer gebeurt.

Mensen met motorische beperkingen — zoals degenen die schakelbediening, oogvolgtechnologie of mondstokken gebruiken — kunnen meerdere keren langer dan gemiddeld nodig hebben om tekst in te voeren en door formulieren te navigeren. Een gebruiker met ALS of spinale musculaire atrofie kan bezig zijn met het invullen van een cruciaal medisch verwijsformulier en slechts enkele tekens per minuut typen. Sessietime-outs die hun werk vernietigen zijn geen klein ongemak; ze kunnen een volledige barrière vormen voor het voltooien van essentiële taken.

Gebruikers met cognitieve beperkingen, waaronder mensen met dyslexie, ADHD, traumatisch hersenletsel of dementie, moeten mogelijk instructies meerdere keren opnieuw lezen, pauzes nemen om informatie te verwerken, of gewoon langzamer door processen met meerdere stappen gaan. Onderzoek laat consequent zien dat deze groep onevenredig wordt getroffen door tijdsdruk en gegevensverlies — die beide de cognitieve belasting vergroten van het proberen helemaal opnieuw te beginnen.

Beschouw een concreet scenario uit de echte wereld: een gebruiker met multiple sclerose vraagt via het webportaal van een publieke instelling een overheidsuitkering voor een handicap aan. De aanvraag heeft 8 stappen en vereist het uploaden van medische documenten, het invoeren van arbeidsverleden en het schrijven van een persoonlijke verklaring. De gebruiker komt in 45 minuten tot stap 6, de sessie verloopt en alle ingevoerde gegevens gaan verloren. Hij of zij moet nu dezelfde documenten opnieuw verzamelen en het hele proces herhalen, en kan de aanvraag mogelijk helemaal opgeven. Dit is geen hypothetisch scenario — het is een patroon dat herhaaldelijk is gedocumenteerd in toegankelijkheidsonderzoek en gebruikerstesten.

Los van beperkingen treft gegevensverlies bij sessietime-out alle gebruikers en heeft het meetbare zakelijke impact: achtergelaten winkelwagentjes, onvolledige registraties en gemiste leads. Het behouden van sessiestatus is zowel een toegankelijkheidsvereiste als een goede UX- en conversieoptimalisatiepraktijk. Volgens het Baymard Institute is formulierverlating een belangrijke factor in het verlaten van winkelwagentjes in e-commerce, en onverwacht gegevensverlies is een van de meest genoemde redenen waarom gebruikers online aankopen niet afronden.

Gerelateerde Axe-core Regels

WCAG 2.2.5 vereist alleen handmatige tests. Er zijn geen geautomatiseerde axe-core regels die betrouwbaar overtredingen van dit criterium kunnen detecteren. Het volgende legt uit waarom geautomatiseerde tools tekortschieten en wat menselijke testers in plaats daarvan moeten doen:

• Er bestaat geen geautomatiseerde regel voor het bewaren van sessiestatus: Axe-core en vergelijkbare geautomatiseerde toegankelijkheidsengines werken door de huidige DOM te inspecteren en statische of bijna statische voorwaarden te evalueren, zoals kleurcontrastverhoudingen, correctheid van ARIA-attributen en ontbrekende alternatieve tekst. Ze kunnen het verstrijken van tijd niet simuleren, geen sessieverloopgebeurtenis triggeren, geen opnieuw-authenticatiegegevens indienen en vervolgens verifiëren of eerder ingevoerde gegevens zijn hersteld. Deze hele reeks is een stateful, tijdsafhankelijk gedrag dat door een mens (of een gescripte end-to-end test) moet worden geobserveerd.
• Detectie van sessietime-out valt buiten de scope van statische analyse: Zelfs als een geautomatiseerde tool zou kunnen detecteren dat een pagina een sessietime-out implementeert (bijvoorbeeld door een meta refresh-tag of een JavaScript setTimeout-aanroep te lezen), kan deze niet evalueren wat er met gebruikersgegevens gebeurt nadat de time-out afgaat. Het gedrag rond gegevensbehoud bevindt zich in server-side sessiebeheerlogica, niet in de DOM-structuur die geautomatiseerde tools analyseren.
• Complexiteit van de opnieuw-authenticatiestroom: De ervaring van opnieuw authenticeren kan meerdere pagina's omvatten (inlogformulier, MFA-prompt, redirect), en het herstellen van de status kan afhangen van server-side logica, cookies, local storage of URL-parameters. Geen enkele single-page DOM-inspectietool kan deze multi-page, multi-systeemstroom volgen.
• Waarom handmatig testen essentieel is: Een gekwalificeerde tester moet handmatig een geauthenticeerde workflow starten, bewust wachten op of een sessieverloop triggeren, het opnieuw-authenticatieproces doorlopen en vervolgens de gegevensintegriteit verifiëren. Dit is de enige betrouwbare methode om conformiteit te testen. Geautomatiseerde scans kunnen als startpunt worden gebruikt om gerelateerde problemen te signaleren (zoals ontbrekende sessiewaarschuwingsmechanismen die onder 2.2.1 vallen), maar ze kunnen handmatige tests voor 2.2.5 niet vervangen.

Hoe te Testen

1. Identificeer geauthenticeerde workflows met formulieren of processen met meerdere stappen. Begin met het in kaart brengen van alle delen van de site die authenticatie vereisen en gebruikersgegevensinvoer omvatten — checkoutflows, profielbeheerders, aanvraagformulieren, boekingssystemen, berichteninterfaces en administratieve dashboards. Dit zijn de gebieden met het hoogste risico op 2.2.5-fouten.
2. Bepaal de duur van de sessietime-out. Controleer serverconfiguratie, applicatie-instellingen of raadpleeg het ontwikkelingsteam om te achterhalen wanneer sessies verlopen. Start eventueel een sessie en wacht tot je automatisch wordt uitgelogd. Noteer de duur. Veelvoorkomende time-outs variëren van 15 minuten tot 2 uur.
3. Begin een taak en voer substantiële gegevens in. Log in en begin met het invullen van een representatief formulier — bijvoorbeeld een registratie- of aankoopflow met meerdere velden. Voer tekst in tekstvelden in, maak selecties en doorloop eventuele wizardstappen. Dien het formulier niet in.
4. Trigger het verlopen van de sessie. Wacht ofwel tot de natuurlijke time-out optreedt, of — als je ontwikkelaarsrechten hebt — laat de sessie kunstmatig verlopen door de sessiecookie ongeldig te maken in de ontwikkelaarstools van de browser (tabblad Application > Cookies > verwijder de sessiecookie), of door de sessie direct aan de serverzijde te laten verlopen.
5. Observeer de prompt voor opnieuw authenticeren. Controleer of de site je vraagt om opnieuw te authenticeren (pass) of je simpelweg zonder waarschuwing doorstuurt naar een inlogpagina (een gerelateerd bruikbaarheidsprobleem, hoewel 2.2.5 zich richt op gegevensbehoud, niet op de waarschuwing zelf). Probeer opnieuw in te loggen.
6. Verifieer gegevensbehoud na inloggen. Observeer na succesvol opnieuw authenticeren waar je naartoe wordt doorgestuurd en of je eerder ingevoerde gegevens intact zijn. Als je naar de homepage wordt gestuurd en/of je formuliergegevens zijn verdwenen, is dit een overtreding van 2.2.5.
7. Test met ondersteunende technologieën. Herhaal de bovenstaande testreeks met NVDA met Firefox, JAWS met Chrome en VoiceOver met Safari om ervoor te zorgen dat de prompt voor opnieuw authenticeren toegankelijk is voor schermlezergebruikers en dat de herstelde paginastatus correct wordt aangekondigd. Een ziende gebruiker kan herstelde gegevens visueel herkennen; een schermlezergebruiker heeft nodig dat de focus correct wordt geplaatst en dat de herstelde inhoud in de leesvolgorde staat.
8. Test met alleen toetsenbordnavigatie. Zorg ervoor dat het hele opnieuw-authenticatieproces — van de melding over het verlopen van de sessie tot opnieuw inloggen en terugkeren naar de bewaarde taak — volledig met alleen een toetsenbord kan worden doorlopen, zonder muis.
9. Test met simulaties van verlengde time-outs. Verlaag indien mogelijk de sessietime-out tot 1–2 minuten in een ontwikkelomgeving en voer volledige gebruikersreistests uit om de testcyclus sneller en beter herhaalbaar te maken.

Hoe te Oplossen

Eenvoudig loginformulier met sessietime-out — Onjuist

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Eenvoudig loginformulier met sessietime-out — Juist

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Wizard met meerdere stappen die voortgang verliest — Onjuist

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Wizard met meerdere stappen die voortgang verliest — Juist

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Waarschuwing voor sessieverloop zonder gegevensbehoud — Onjuist

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Waarschuwing voor sessieverloop zonder gegevensbehoud — Juist

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Veelvoorkomende Fouten

• Doorsturen naar de homepage na opnieuw authenticeren in plaats van naar de oorspronkelijke pagina: Het meest voorkomende faalpatroon. Na inloggen stuurt de applicatie de gebruiker naar /dashboard of / in plaats van naar de URL waarop hij of zij zich bevond toen de sessie verliep, waardoor de gebruiker handmatig moet terugnavigeren naar de taak — en de gegevens al verdwenen zijn.
• Formulierstatus alleen in JavaScript-geheugen of React/Vue-componentstatus opslaan: Client-side frameworkstatus overleeft geen paginareload die wordt veroorzaakt door een redirect naar de inlogpagina bij sessieverloop. Status moet server-side worden bewaard of in een opslagmechanisme (bijv. localStorage) dat betrouwbaar wordt hersteld bij terugkeer.
• Alleen een "return URL" opslaan maar niet de formuliergegevens: Sommige implementaties slaan de URL op waarnaar na inloggen moet worden teruggestuurd, maar bewaren de daadwerkelijke formulierwaarden niet. De gebruiker komt op de juiste pagina aan, maar met lege velden, wat nog steeds in strijd is met 2.2.5.
• Automatisch opslaan in sessionStorage dat wordt geleegd wanneer het tabblad wordt gesloten: Als het sessieverloop ervoor zorgt dat het browsertabblad weg navigeert (bijv. redirect naar login), wordt sessionStorage geleegd. Gebruik localStorage met een op de gebruiker gebaseerde namespace, of bij voorkeur server-side conceptopslag.
• Niet testen met bestandsuploadvelden: Bestandsinvoer kan om veiligheidsredenen niet vooraf worden ingevuld door HTML. Als een formulier een bestandsupload bevat die vóór sessieverloop is voltooid, gaat de bestandsreferentie verloren. Applicaties moeten dit afhandelen door geüploade bestandsreferenties server-side op te slaan en de gebruiker te laten zien dat het bestand nog steeds is bijgevoegd.
• Opgeslagen conceptgegevens direct bij opnieuw authenticeren wissen: Sommige implementaties verwijderen het concept zodra de gebruiker inlogt, voordat is geverifieerd dat de gebruiker de herstelde gegevens daadwerkelijk heeft gezien en bevestigd. Het concept moet bewaard blijven totdat de taak expliciet is voltooid of geannuleerd.
• Herstelde gegevens niet aankondigen aan schermlezergebruikers: Na opnieuw authenticeren en redirect hebben schermlezergebruikers een aria-live-regio of gefocuste aankondiging nodig die bevestigt dat hun gegevens zijn hersteld en dat ze verder kunnen gaan waar ze waren gebleven. Zonder dit weten ze mogelijk niet dat hun werk is opgeslagen.
• AJAX-gebaseerde sessies anders behandelen dan paginagebaseerde sessies: Single-page applicaties die token-gebaseerde authenticatie gebruiken (bijv. JWT-verloop) laten API-aanroepen vaak stil falen wanneer het token verloopt, zonder de gebruiker de kans te geven opnieuw te authenticeren en te hervatten. Het mechanisme voor opnieuw authenticeren moet even robuust zijn voor SPA-architecturen.
• Gebruik van <meta http-equiv='refresh'> om uitloggen af te dwingen zonder vooraf gegevens op te slaan: Een meta refresh die bij time-out afgaat, stuurt de gebruiker onmiddellijk door zonder enige server-side statusbewaring, waardoor gegevensherstel onmogelijk wordt. Sessiebeheer moet op applicatieniveau worden afgehandeld met juiste statuspersistentie.
• Aannemen dat korte sessies de noodzaak voor dit criterium wegnemen: Zelfs een sessietime-out van 5 minuten kan een langzame typist treffen, een gebruiker met een cognitieve beperking die instructies opnieuw leest, of iemand die wordt onderbroken door een mantelzorger. De duur van de time-out verandert niets aan de verplichting om gegevens over opnieuw authenticeren heen te bewaren.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10 (gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025) stelt het nationale kader voor digitale toegankelijkheid vast en verwijst naar WCAG 2.2 als technische standaardbasis. De circulaire verplicht tot conformiteit voor een breed scala aan entiteiten die in Turkije actief zijn, waaronder publieke instellingen en agentschappen, e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en particuliere zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere transportbedrijven en particuliere onderwijsinstellingen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE).

WCAG 2.2.5 Opnieuw authenticeren is een Level AAA-criterium, wat betekent dat het niet behoort tot de minimaal wettelijk verplichte vereisten onder de circulaire (die zich richt op Level A- en AA-conformiteit). Organisaties die echter leiderschap in toegankelijkheid willen tonen, diverse gebruikerspopulaties inclusief mensen met een beperking willen bedienen, of zich willen positioneren als digitale dienstverleners van topniveau, zouden Level AAA-criteria — vooral die met een zo praktische impact als 2.2.5 — moeten behandelen als ambitieuze doelen die het nastreven waard zijn.

Bepaalde categorieën van gedekte entiteiten hebben bijzonder sterke redenen om 2.2.5 te implementeren. Banken en financiële platforms vereisen vaak dat gebruikers lange formulieren invullen voor leningaanvragen, het openen van rekeningen of beleggingsproducten, en hun door veiligheid gedreven korte sessietime-outs staan in directe spanning met verplichtingen rond gegevensbehoud. Ziekenhuizen en zorgportalen stellen patiënten bloot aan gegevensverlies tijdens kritieke taken zoals het boeken van afspraken of het invullen van gezondheidsvragenlijsten, wat reële gevolgen kan hebben voor de continuïteit van zorg. Publieke instellingen die e-overheidsdiensten aanbieden — zoals belastingaangifte, vergunningaanvragen of uitkeringsclaims — bedienen burgers met een beperking die mogelijk extra tijd nodig hebben om complexe overheidsformulieren in te vullen.

Zelfs waar Level AAA-conformiteit niet wettelijk vereist is, moeten Turkse organisaties zich ervan bewust zijn dat toezichthouders, maatschappelijke organisaties en belangenbehartigers voor mensen met een beperking de kwaliteit en volledigheid van digitale toegankelijkheidsimplementaties steeds kritischer bekijken. Het documenteren van conformiteit met Level AAA-criteria zoals 2.2.5 versterkt de toegankelijkheidsverklaring van een organisatie, vermindert het risico op rechtszaken en toont een oprechte inzet voor inclusief ontwerp die verder gaat dan minimale vinkjes. Voor entiteiten met internationale reikwijdte, met name degenen die naast Turkije actief zijn op EU-markten, kunnen Level AAA-criteria overlappen met vereisten onder de European Accessibility Act (EAA) en gerelateerde nationale implementaties.