WCAG 3.3.8: Toegankelijke authenticatie (minimum)

Wat Deze Regel Betekent

WCAG 3.3.8 Accessible Authentication (Minimum) is een criterium op niveau AA dat is geïntroduceerd in WCAG 2.2. Het stelt dat een cognitieve functietest—gedefinieerd als een taak die van een gebruiker vereist dat hij of zij informatie onthoudt, manipuleert of overschrijft—niet het enige middel mag zijn om een authenticatiestap te voltooien, tenzij ten minste aan een van de volgende voorwaarden wordt voldaan:

• Alternatieve methode: Er is een ander authenticatiepad beschikbaar dat niet berust op een cognitieve functietest (bijvoorbeeld een magic link die per e-mail wordt verzonden, biometrische login of een passkey).
• Mechanisme ter ondersteuning: De user agent of een tool van derden mag de stap namens de gebruiker voltooien—bijvoorbeeld een wachtwoordmanager die inloggegevens automatisch invult, of een kopieer-en-plakactie voor een eenmalige code.
• Uitzondering voor objectherkenning: De cognitieve functietest bestaat uit het identificeren van een object in een afbeelding (bijvoorbeeld het selecteren van alle afbeeldingen met een verkeerslicht) — dit type test is toegestaan op het Minimum-niveau (AA).
• Uitzondering voor persoonlijke inhoud: De test is gebaseerd op inhoud die de gebruiker zelf heeft aangeleverd, zoals het selecteren van een eerder geüploade foto uit een raster.

In praktische termen voldoet een inlogformulier dat alleen een gebruikersnaam en wachtwoord vereist wél aan dit criterium, mits het formulier browser-autofill en wachtwoordmanagers laat werken (d.w.z. de velden gebruiken standaard <input type='password'> en plakken wordt niet geblokkeerd). Een CAPTCHA die vereist dat vervormde tekst wordt overgetypt zonder enige alternatieve authenticatieroute is een duidelijke fout. Een CAPTCHA die gebruikers vraagt afbeeldingen te selecteren die bij een categorie passen (objectherkenning) is toegestaan op AA-niveau, maar wordt strenger behandeld op AAA (3.3.9).

Het criterium is van toepassing op alle stappen van een authenticatieproces: eerste login, step-up-authenticatie, multifactorauthenticatie, accountherstel en sessie-herauthenticatie. Het is ook van toepassing op elk proces dat toegang tot functionaliteit beschermt, niet alleen op het primaire aanmeldscherm.

Een belangrijke technische implicatie is dat ontwikkelaars geen autocomplete='off' mogen gebruiken op authenticatievelden, plakken niet mogen uitschakelen via JavaScript-eventhandlers, en de standaard invoersemantiek die hulpmiddelen en browser-autofill in staat stelt correct te werken niet mogen doorbreken.

Waarom Het Belangrijk Is

Authenticatie is de toegangspoort tot vrijwel elke digitale dienst waar mensen dagelijks op vertrouwen—bankieren, zorgportalen, overheidsdiensten, e-commerce en communicatieplatforms. Wanneer die toegangspoort cognitieve drempels opwerpt, sluit zij systematisch een aanzienlijk deel van de bevolking uit.

Cognitieve beperkingen omvatten een breed spectrum: dyslexie, dyscalculie, aandachtsstoornissen, niet-aangeboren hersenletsel, dementie, verstandelijke beperkingen en angststoornissen. De Wereldgezondheidsorganisatie schat dat ongeveer 1 op de 6 mensen wereldwijd een vorm van significante beperking ervaart, en cognitieve en neurologische aandoeningen vormen een van de grootste categorieën. Voor deze gebruikers kunnen taken zoals het nauwkeurig overtypen van een reeks vervormde tekens, het oplossen van een visuele puzzel onder tijdsdruk, of het wisselen tussen een authenticator-app en een inlogformulier daadwerkelijk onmogelijk of diep vermoeiend zijn.

Neem een concreet scenario: een persoon met dyslexie probeert in te loggen op het zorgverzekeringsportaal om testresultaten te bekijken. De site toont een tekst-CAPTCHA zonder audio-alternatief en zonder mogelijkheid om deze te omzeilen. De vervormde lettervormen zijn voor deze gebruiker niet van elkaar te onderscheiden, en het invoerveld blokkeert plakken. Na meerdere mislukte pogingen wordt het account vergrendeld. De gebruiker kan geen toegang krijgen tot tijdkritische medische informatie. Dit is geen hypothetisch randgeval—het is een alledaagse ervaring voor miljoenen mensen.

Gebruikers met motorische beperkingen die afhankelijk zijn van switch access of oogvolgapparaten worden ook getroffen. Het opnieuw intypen van een complexe eenmalige code vanaf een apart apparaat, of het verslepen van afbeeldingsvakken in een specifieke volgorde, kan fysiek onmogelijk zijn met deze invoermethoden. Het toestaan van kopiëren-en-plakken of authenticatie op basis van passkeys lost de barrière volledig op.

Oudere volwassenen vormen een andere belangrijke groep. Leeftijdsgebonden cognitieve achteruitgang beïnvloedt het geheugen en de verwerkingssnelheid, waardoor complexe CAPTCHA’s en meerstaps-geheugentaken onevenredig moeilijk worden. Naarmate de bevolking in Turkije en wereldwijd vergrijst, wordt de zakelijke en regulatoire noodzaak voor toegankelijke authenticatie elk jaar sterker.

Vanuit gebruiksvriendelijkheid en conversieperspectief verhoogt frictie in authenticatiestromen direct de uitvalpercentages. E-commerceplatforms die tekst-CAPTCHA’s vervangen door risicogebaseerde authenticatie of passkeys rapporteren consequent hogere voltooiingspercentages voor inloggen en lagere ondersteuningskosten gerelateerd aan vergrendelde accounts.

Gerelateerde Axe-core-regels

WCAG 3.3.8 wordt geclassificeerd als een criterium dat handmatige tests vereist, omdat geautomatiseerde tools niet volledig kunnen beoordelen of een authenticatieproces een ontoegankelijke cognitieve functietest oplegt. Bepalen of een inlogstroom geen alternatieve route heeft, of dat plakken contextafhankelijk wordt geblokkeerd, vereist menselijk oordeel en interactie met een live authenticatiestroom. Dat gezegd hebbende, bepaalde geautomatiseerde controles ondersteunen dit criterium:

• Handmatige review — audit van de authenticatiestroom: Testers moeten elke authenticatiestap doorlopen en bepalen of er een cognitieve functietest aanwezig is, en zo ja, of er een conforme alternatieve of ondersteunende mechanisme bestaat. Er is momenteel geen axe-core-regel die automatisch wordt geactiveerd voor dit criterium, omdat de logica afhangt van het begrijpen van het doel en de context van formuliervelden en omliggende UI, niet alleen van hun markup.
• Controles van het autocomplete-attribuut (gerelateerd): De axe-core-regel autocomplete-valid markeert invoervelden waarvan de waarden van het autocomplete-attribuut niet afkomstig zijn uit de WCAG 1.3.5-tokenlijst. Hoewel deze regel direct is gericht op 1.3.5, is het een ondersteunende controle voor 3.3.8: als autocomplete='username' en autocomplete='current-password' ontbreken of onjuist zijn ingesteld, kunnen wachtwoordmanagers niet automatisch invullen, waardoor het ondersteunende mechanisme verdwijnt dat standaard wachtwoordlogin conform maakt onder 3.3.8.
• Detectie van blokkerend plakken — handmatig: Geautomatiseerde scanners kunnen JavaScript dat paste-events onderschept en onderdrukt op authenticatievelden niet betrouwbaar detecteren. Een handmatige tester moet proberen een inloggegeven of OTP in elk relevant veld te plakken en bevestigen dat de actie slaagt.
• Detectie van CAPTCHA-alternatieven — handmatig: Axe-core kan de aanwezigheid van veelvoorkomende CAPTCHA-widgets detecteren (bijv. reCAPTCHA-iframes), maar kan niet bepalen of elders op de pagina of via een andere route een alternatieve authenticatieweg wordt aangeboden. Deze beoordeling vereist handmatige inspectie van de volledige authenticatie-UX.

Hoe te Testen

1. Geautomatiseerde scan (axe DevTools / Lighthouse): Voer axe DevTools uit op elke authenticatiepagina (login, registratie, accountherstel, MFA). Zoek naar autocomplete-valid-overtredingen op gebruikersnaam- en wachtwoordvelden. Bekijk in Lighthouse de Accessibility-audit op formuliergerelateerde problemen. Let op dat geen enkele geautomatiseerde regel een 3.3.8-fout definitief zal markeren — geautomatiseerde resultaten zijn slechts een startpunt.
2. Identificeer alle cognitieve functietests: Breng handmatig elke stap in de authenticatiestroom in kaart. Noteer elke stap die van de gebruiker vereist dat hij of zij informatie herinnert die niet op het huidige scherm wordt getoond, tekens overschrijft, een puzzel oplost of een berekening uitvoert. Controleer of elke dergelijke stap een conforme alternatieve optie heeft (objectherkenning, persoonlijke inhoud, alternatieve loginmethode of ondersteunend mechanisme).
3. Test de plakfunctionaliteit: Probeer op elk authenticatieveld (gebruikersnaam, wachtwoord, OTP, herstelcode) tekst te plakken met de toetsenbordcombinatie (Ctrl+V op Windows/Linux, Cmd+V op macOS). Bevestig dat de geplakte inhoud in het veld verschijnt. Herhaal dit via het contextmenu met de rechtermuisknop. Als plakken wordt geblokkeerd, is dit een fout, tenzij er een alternatief zonder cognitieve functietest bestaat.
4. Test autofill met een wachtwoordmanager: Gebruik een browser met een wachtwoordmanager (native of als extensie), sla inloggegevens op tijdens registratie en keer vervolgens terug naar de inlogpagina. Bevestig dat de wachtwoordmanager de velden kan detecteren en automatisch invullen. Test in Firefox met NVDA, Safari met VoiceOver (macOS/iOS) en Chrome met JAWS om de belangrijkste combinaties van hulpmiddelen en browsers te dekken. Als de velden niet-standaard markup gebruiken of JavaScript de automatisch ingevulde waarden wist, is dit een fout.
5. NVDA + Firefox — schermlezer-walkthrough: Navigeer door het inlogformulier met alleen het toetsenbord en NVDA. Bevestig dat elk veld bereikbaar is, dat veldlabels correct worden aangekondigd en dat elke CAPTCHA-widget een toegankelijk alternatief heeft. Als de CAPTCHA puur visueel is zonder audio-optie en zonder alternatieve loginroute, noteer dan een fout.
6. VoiceOver + Safari (iOS): Probeer op een mobiel apparaat in te loggen met Face ID of Touch ID als de site biometrische login aanbiedt. Bevestig dat de biometrische optie via veegnavigatie bereikbaar is en dat VoiceOver deze correct aankondigt. Dit bevestigt dat een alternatief zonder cognitieve functietest operationeel toegankelijk is, en niet alleen nominaal aanwezig.
7. Controleer tijdslimieten op cognitieve stappen: Als een CAPTCHA of OTP-invoer een tijdslimiet oplegt, controleer dan of de gebruiker deze kan verlengen of uitschakelen (relevant voor 2.2.1), en noteer afzonderlijk of de getimede stap een cognitieve functietest vormt zonder alternatief.

Hoe te Herstellen

Tekst-CAPTCHA zonder alternatief — Onjuist

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

Tekst-CAPTCHA zonder alternatief — Juist

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

OTP-veld dat plakken blokkeert — Onjuist

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

OTP-veld dat plakken blokkeert — Juist

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

Afbeeldingsselectie-CAPTCHA zonder fallback (AAA-zorg, AA-goedkeuring) — Juist op AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Veelvoorkomende Fouten

• autocomplete='off' instellen op wachtwoordvelden: Dit schakelt autofill van wachtwoordmanagers uit en verwijdert het ondersteunende mechanisme dat standaard wachtwoordauthenticatie conform maakt. Gebruik in plaats daarvan autocomplete='current-password' en laat de browser het beheer van inloggegevens verzorgen.
• Plakken blokkeren met onpaste='return false;' of addEventListener('paste', e => e.preventDefault()): Dit dwingt gebruikers om inloggegevens handmatig te typen en creëert een ontoegankelijke overschrijftaak. Verwijder alle handlers die plakken voorkomen uit authenticatievelden.
• Een passkey-optie aanbieden die niet met het toetsenbord toegankelijk is: Een biometrisch alternatief voldoet alleen aan 3.3.8 als het bereikbaar en bedienbaar is via toetsenbord en hulpmiddelen. Een passkey-knop die verborgen is achter een hovermenu of wordt weergegeven als een niet-focusbare <div> telt niet als een conforme alternatieve route.
• Een tekst-CAPTCHA gebruiken als enige botmitigatiestrategie: Overschakelen op risicogebaseerde, server-side botdetectie (analyse van device fingerprint, typsnelheid, IP-reputatie) elimineert de cognitieve functietest volledig zonder in te boeten aan veiligheid. Alleen vertrouwen op client-side CAPTCHA is zowel een toegankelijkheidsfout als slechte beveiligingspraktijk.
• Een OTP splitsen in meerdere invoervelden van één teken en plakken over velden heen blokkeren: Sommige implementaties gebruiken zes afzonderlijke <input maxlength='1'>-velden voor OTP-invoer en verplaatsen de focus automatisch via JavaScript. Dit patroon breekt routinematig plakken vanuit wachtwoordmanagers en schendt 3.3.8, tenzij de implementatie expliciet ondersteunt dat een volledige code in het eerste veld wordt geplakt en de tekens correct worden verdeeld.
• Een op afbeeldingen gebaseerde CAPTCHA alleen vereisen bij accountherstel: Teams voegen vaak toegankelijke loginalternatieven toe aan de hoofdloginpagina, maar vergeten step-up-authenticatie, wachtwoordreset en accountontgrendeling. Elk van deze is een afzonderlijke authenticatiestap en moet onafhankelijk voldoen aan 3.3.8.
• Audio-CAPTCHA beschouwen als een volledige alternatieve oplossing voor tekst-CAPTCHA: Een audio-alternatief helpt blinde gebruikers, maar niet gebruikers met cognitieve beperkingen of mensen in lawaaiige omgevingen. Audio-CAPTCHA’s brengen ook hun eigen overschrijftaak met zich mee. De juiste oplossing is om de CAPTCHA te elimineren of een route te bieden die helemaal geen cognitieve functietest bevat.
• Dynamisch gegenereerde invoerveld-ID’s gebruiken die detectie door wachtwoordmanagers breken: Wanneer id-attributen op gebruikersnaam- en wachtwoordvelden bij elke paginalaadbeurt worden gerandomiseerd (een misplaatste anti-bottechniek), kunnen wachtwoordmanagers de velden niet betrouwbaar identificeren. Dit schakelt autofill feitelijk uit en verwijdert het conforme ondersteunende mechanisme.
• Aannemen dat CAPTCHA-widgets van derden automatisch conform zijn: Populaire CAPTCHA-diensten kunnen toegankelijke varianten aanbieden, maar deze zijn niet standaard ingeschakeld. Ontwikkelaars moeten expliciet de toegankelijke versie configureren en nog steeds verifiëren dat deze aan de eisen van de standaard voldoet, in plaats van simpelweg een nieuw type ontoegankelijke test toe te voegen.
• Automatisch ingevulde waarden wissen via JavaScript bij focus: Sommige formulieren wissen de inhoud van een veld wanneer het focus krijgt om placeholdertekst te tonen of herinvoer te forceren. Als dit gedrag de automatisch ingevulde waarde van een wachtwoordmanager wist, dwingt het tot handmatige herinvoer en faalt het 3.3.8.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in Staatsblad nr. 32933 op 21 juni 2025, stelt web- en mobiele toegankelijkheidsverplichtingen vast die in lijn zijn met WCAG 2.2. De circulaire vereist dat onder de regeling vallende entiteiten niveau AA-conformiteit behalen voor hun digitale producten en diensten. WCAG 3.3.8, als criterium op niveau AA in WCAG 2.2, valt daarom direct binnen de reikwijdte van de verplichte nalevingsvereisten die door deze circulaire zijn ingevoerd.

De circulaire heeft betrekking op een breed scala aan private en publieke entiteiten. Overheidsinstellingen en -organisaties moeten volledige AA-conformiteit bereiken. In de private sector is de circulaire van toepassing op e-commerceplatforms, banken en financiële instellingen, ziekenhuizen en particuliere zorgaanbieders, telecomoperators met 200.000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministerie van Nationaal Onderwijs (MoNE). Voor deze organisaties creëren ontoegankelijke authenticatiestromen—zoals inlogpagina’s met niet-ondersteunde CAPTCHA’s of OTP-velden die plakken blokkeren—directe regulatoire risico’s.

Het Accessibility Logo (Erişilebilirlik Logosu), uitgegeven door het Ministerie van Gezin en Sociale Diensten, is het officiële certificeringsmerk voor digitale toegankelijkheidsconformiteit in Turkije. Het verkrijgen van dit logo vereist aangetoonde conformiteit op niveau AA, waaronder 3.3.8. Voor e-commerce-exploitanten, banken en andere drukbezochte digitale dienstverleners fungeert het logo als een publiek vertrouwenssignaal en kan het worden genoemd in aanbestedings- en inkoopvereisten. Authenticatiestromen die afhankelijk zijn van ontoegankelijke cognitieve tests zouden certificering blokkeren en de organisatie blootstellen aan klachten en handhavingsacties.

Vanuit praktisch nalevingsperspectief moeten Turkse organisaties elk authenticatiecontactpunt—waaronder login, registratie, MFA, wachtwoordreset en accountontgrendeling—auditen op 3.3.8 voordat zij zich aanmelden voor de Accessibility Logo-beoordeling. Het vervangen van tekst-CAPTCHA’s door risicogebaseerde server-side controles, het inschakelen van autocomplete op alle inlogvelden en het aanbieden van passkey- of magic-link-alternatieven zijn de herstelacties met de grootste impact. Deze wijzigingen voldoen tegelijkertijd aan de regulatoire vereisten en verbeteren de authenticatie-ervaring voor de naar schatting 8,5 miljoen mensen met een beperking in Turkije die digitale diensten gebruiken.