WCAG 3.3.9: Toegankelijke authenticatie (uitgebreid)

Wat Deze Regel Betekent

WCAG 3.3.9 — Accessible Authentication (Enhanced) is de AAA-tegenhanger van WCAG 3.3.8 (Accessible Authentication — Minimum, AA). Samen vormen ze een paar criteria die in WCAG 2.2 zijn geïntroduceerd om ervoor te zorgen dat het proces van het bewijzen van identiteit aan een website of applicatie zelf geen toegankelijkheidsbarrière wordt.

Op AAA-niveau worden de vereisten in 3.3.9 aanzienlijk aangescherpt. Het criterium stelt: Er mag geen cognitieve functietest vereist zijn voor een stap in een authenticatieproces, tenzij die stap ten minste één van de volgende zaken biedt: een alternatieve authenticatiemethode die niet afhankelijk is van een cognitieve functietest; een mechanisme is beschikbaar om de gebruiker te helpen bij het voltooien van de cognitieve functietest; of de cognitieve functietest bestaat uit het herkennen van objecten. Cruciaal is dat, in tegenstelling tot de AA-versie (3.3.8), het AAA-criterium de uitzondering verwijdert die het herkennen van niet-objectinhoud toestond (zoals afbeeldingen van niet-objectitems die een gebruiker eerder heeft geselecteerd). Op dit niveau is alleen echte objectherkenning — het herkennen van veelvoorkomende objecten uit de echte wereld, zoals afbeeldingen van een kat, een fiets of een huis — toegestaan als cognitieve functietest, en alleen als niet aan de andere voorwaarden wordt voldaan.

Een cognitieve functietest wordt gedefinieerd als elke taak die van de gebruiker vereist dat hij of zij informatie onthoudt, manipuleert of overschrijft. Dit omvat: het onthouden van een gebruikersnaam of wachtwoord, het oplossen van een wiskundige puzzel, het voltooien van een CAPTCHA die vereist dat vervormde tekst wordt ontcijferd, het beantwoorden van een beveiligingsvraag over persoonlijke geschiedenis (bijv. "Wat was de naam van je eerste huisdier?"), of het overschrijven van een reeks tekens. Dit zijn allemaal geheugen- of overschrijvingstaken die veel gebruikers niet betrouwbaar kunnen uitvoeren.

Wat telt als een voldoende resultaat: Een authenticatiestap voldoet aan 3.3.9 als er geen cognitieve functietest vereist is, of als aan één van deze voorwaarden wordt voldaan: (1) er wordt een volledig apart, niet-cognitief authenticatiepad aangeboden (bijv. een magic link die per e-mail wordt verzonden, WebAuthn/passkey, biometrische login); (2) een mechanisme helpt bij het voltooien van de test (bijv. de wachtwoordmanager van de browser wordt niet geblokkeerd, of kopiëren-plakken is toegestaan); of (3) de enige betrokken cognitieve test is het herkennen van een veelvoorkomend object uit de echte wereld uit een set afbeeldingen.

Wat telt als een onvoldoende resultaat: Elke flow die de gebruiker — zonder omweg of alternatief — dwingt om een wachtwoord uit het geheugen te herinneren, een code over te schrijven die niet geplakt kan worden, een visuele of audio-CAPTCHA op te lossen zonder alternatief, kennisgebaseerde beveiligingsvragen te beantwoorden, of eerder geselecteerde afbeeldingen van niet-objectinhoud (bijv. abstracte vormen of persoonlijke foto’s) te identificeren zonder een alternatief authenticatiepad.

Officiële uitzonderingen: De WCAG-specificatie zelf merkt op dat het herkennen van objecten (foto’s van dingen uit de echte wereld) de enige beeldherkenningstaak is die op dit AAA-niveau is toegestaan. Het AA-criterium (3.3.8) stond ook het herkennen van persoonlijk gekozen "niet-object"-afbeeldingen toe, maar 3.3.9 verwijdert die uitzondering volledig. Er is geen uitzondering voor "wijdverbreide" authenticatiepatronen — als een patroon een cognitieve test vereist zonder alternatief, voldoet het niet aan 3.3.9.

Waarom Het Belangrijk Is

Authenticatie is vaak de eerste betekenisvolle interactie die een gebruiker met een digitale dienst heeft. Als die interactie zelf niet toegankelijk is, wordt de rest van de toegankelijkheid van de site irrelevant — de gebruiker komt simpelweg niet binnen. WCAG 3.3.9 pakt deze barrière direct aan, en de impact ervan strekt zich uit over een breed scala aan doelgroepen met een beperking.

Gebruikers met cognitieve beperkingen — waaronder mensen met dyslexie, ADHD, traumatisch hersenletsel, dementie of leerstoornissen — kunnen het extreem moeilijk of onmogelijk vinden om complexe wachtwoorden te onthouden, tijdsgebonden eenmalige codes handmatig over te schrijven, of vervormde CAPTCHA-tekst te ontcijferen. De Wereldgezondheidsorganisatie schat dat ongeveer 1 op de 6 mensen wereldwijd een vorm van significante beperking ervaart, en cognitieve beperkingen vormen een van de grootste en meest onderbediende categorieën in webtoegankelijkheid.

Gebruikers met motorische beperkingen — zoals mensen met de ziekte van Parkinson, essentiële tremor, ruggenmergletsels, of aandoeningen waarbij schakelbediening of oogbesturingstechnologie nodig is — kunnen moeite hebben om wachtwoorden nauwkeurig te typen of codes teken voor teken over te schrijven. Het blokkeren van klembordplakken (een veelgebruikte anti-fraudemaatregel die actief schadelijk is) betekent dat deze gebruikers elk teken moeizaam via hun ondersteunende technologie moeten invoeren, wat de foutkans en vermoeidheid drastisch verhoogt.

Gebruikers die blind zijn of een beperkt gezichtsvermogen hebben zijn mogelijk volledig afhankelijk van schermlezers of vergrotingstools. Visuele CAPTCHA’s zijn volledig ontoegankelijk zonder een audio-alternatief, en zelfs audio-CAPTCHA’s zijn berucht moeilijk voor gebruikers met gehoorbeperkingen of auditieve verwerkingsstoornissen. Op afbeeldingen gebaseerde uitdagingen als "selecteer alle verkeerslichten" kunnen ook problematisch zijn wanneer afbeeldingsbeschrijvingen ontbreken of misleidend zijn.

Gebruikers die doof of slechthorend zijn kunnen barrières ondervinden bij authenticatiemethoden die uitsluitend vertrouwen op telefoongesprekken om eenmalige codes te leveren, vooral wanneer die gesprekken alleen spraak bevatten zonder SMS-alternatief.

Een concreet scenario uit de echte wereld: Stel een 72-jarige gebruiker met milde cognitieve achteruitgang die probeert toegang te krijgen tot zijn of haar online bankportaal. De bank vereist een gebruikersnaam (die onthouden moet worden, niet het e-mailadres), een complex wachtwoord (klembordplakken is geblokkeerd) en een CAPTCHA met vervormde tekst. De gebruiker faalt de CAPTCHA twee keer, wordt buitengesloten en moet de hulplijn van de bank bellen — een proces van 40 minuten. Als de bank passkeys of een magic link had geïmplementeerd, zou deze gebruiker binnen enkele seconden geauthenticeerd zijn. Dit scenario speelt zich dagelijks miljoenen keren af op het web, en het is volledig te voorkomen.

Los van beperkingen komt toegankelijke authenticatie alle gebruikers ten goede. Wachtwoordmanagers, die door honderden miljoenen mensen worden gebruikt, zijn afhankelijk van de mogelijkheid om inloggegevens te plakken. Plakken blokkeren, handmatige overschrijving vereisen of ontoegankelijke CAPTCHA’s inbedden frustreert ook reguliere gebruikers. Er zijn ook beveiligingsargumenten: het afdwingen van complexe handmatige wachtwoordinvoer vergroot de kans dat gebruikers eenvoudigere, zwakkere wachtwoorden kiezen of ze op meerdere sites hergebruiken. Passkeys en magic links, de aanbevolen alternatieven, zijn zowel toegankelijker als veiliger dan traditionele flows met wachtwoord plus CAPTCHA.

Gerelateerde Axe-core Regels

WCAG 3.3.9 wordt geclassificeerd als alleen handmatig testbaar. Vanaf axe-core 4.10 is er geen geautomatiseerde regel die dit criterium volledig evalueert. Begrijpen waarom geautomatiseerde tools deze overtredingen niet kunnen detecteren, vereist inzicht in wat het criterium daadwerkelijk meet.

• Handmatige test vereist — detectie van cognitieve functies: Geautomatiseerde scanners kunnen de aanwezigheid van bepaalde HTML-elementen detecteren (zoals een <input type='password'> of een iframe dat een CAPTCHA-widget van een derde partij insluit), maar ze kunnen niet bepalen of een volledige authenticatie-flow een cognitieve functietest vereist zonder toegankelijke alternatieven. Het criterium gaat over de volledige gebruikersreis over mogelijk meerdere stappen en pagina’s, niet over de eigenschappen van één enkel element. Een scanner kan niet beoordelen of plakken programmatisch wordt geblokkeerd via JavaScript, of een tijdslimiet op een code-invoerveld redelijk is, of dat een alternatief authenticatiepad daadwerkelijk cognitieve tests vermijdt. Dit zijn gedrags- en architectuurvragen die een menselijke beoordelaar vereisen die het daadwerkelijke authenticatieproces doorloopt.
• Handmatige test vereist — verificatie van alternatieve paden: Zelfs als een scanner een CAPTCHA-widget detecteert, kan hij niet verifiëren of er een toegankelijke alternatieve authenticatiemethode bestaat op dezelfde pagina of in dezelfde flow. Hij kan niet beoordelen of een optie "gebruik in plaats daarvan een passkey" werkelijk gelijkwaardig is of dat deze verborgen is op een secundaire instellingenpagina die zelf vereist dat eerst de ontoegankelijke CAPTCHA wordt doorstaan. Het beoordelen van de gelijkwaardigheid van alternatieve paden vereist menselijk oordeel over de volledigheid en prominentie van die alternatieven.
• Handmatige test vereist — gedrag van klembordplakken: JavaScript dat paste-events onderschept en annuleert (event.preventDefault() op een paste-listener) is onzichtbaar voor statische HTML-analyse. Een scanner ziet een geldig <input>-element; hij kan niet weten dat plakken daarin is uitgeschakeld. Alleen handmatig testen — daadwerkelijk proberen een wachtwoord of code te plakken — kan deze fout aan het licht brengen.
• Handmatige test vereist — compatibiliteit van authenticatiewidgets met ondersteunende technologie: Authenticatie-SDK’s van derden (sociale login-knoppen, CAPTCHA-providers, biometrische prompts) kunnen worden weergegeven in iframes of Shadow DOM die geautomatiseerde scanners niet volledig kunnen doorgronden. Handmatig testen met schermlezers zoals NVDA, JAWS en VoiceOver is essentieel om te bevestigen dat alle interactieve elementen binnen de authenticatieflow bedienbaar en begrijpelijk zijn.

Hoe te Testen

1. Identificeer alle authenticatie-ingangspunten: Breng vóór het testen alle plaatsen in de applicatie in kaart waar een gebruiker zich moet authenticeren of de identiteit moet verifiëren. Dit omvat eerste login, aanmaken van een account, wachtwoordreset, prompts voor twee-factor-authenticatie, re-authenticatie na sessietime-out, schermen voor betalingsbevestiging en leeftijdsverificatie. Elk van deze flows moet afzonderlijk worden geëvalueerd.
2. Voer een geautomatiseerde baselinescan uit: Gebruik axe DevTools (browserextensie) of Lighthouse in Chrome DevTools op elke authenticatiepagina. Hoewel deze tools 3.3.9-overtredingen niet direct zullen markeren, brengen ze gerelateerde problemen aan het licht — ontbrekende labels op formuliervelden, ontoegankelijke iframe-inhoud, ontbrekend focusbeheer — die authenticatiebarrières verergeren. Noteer alle gemarkeerde problemen als context voor de handmatige evaluatie. Bekijk in axe DevTools het tabblad "Needs Review" voor items die handmatig oordeel vereisen.
3. Controleer op cognitieve functietests: Vraag voor elke authenticatiestap: vereist deze stap dat de gebruiker (a) iets onthoudt, (b) iets overschrijft, of (c) een puzzel oplost? Zo ja, controleer dan of ten minste één van de volgende zaken aanwezig en even prominent is: een niet-cognitief alternatief pad; een mechanisme (zoals toegestaan klembordplakken of een veld dat compatibel is met automatisch invullen) dat helpt bij het voltooien; of dat de enige cognitieve taak het herkennen van een veelvoorkomend object uit de echte wereld is.
4. Test het gedrag van klembordplakken: Kopieer in elk wachtwoord- en code-invoerveld een tekststring naar je klembord en probeer deze te plakken met Ctrl+V (Windows/Linux) of Cmd+V (macOS). Als plakken wordt geblokkeerd, is dit een fout. Test ook of automatisch invullen door de wachtwoordmanager van de browser wordt onderdrukt (controleer op autocomplete='off' of JavaScript dat automatisch ingevulde waarden bij focus wist).
5. Test met NVDA + Firefox: Doorloop de volledige authenticatieflow met alleen het toetsenbord en de NVDA-schermlezer. Controleer of alle formuliervelden worden aangekondigd met betekenisvolle labels, alle interactieve bedieningselementen (knoppen, links, CAPTCHA-uitdagingen) bereikbaar en bedienbaar zijn, en of foutmeldingen programmatisch zijn gekoppeld aan het relevante veld en direct worden aangekondigd zonder extra navigatie.
6. Test met VoiceOver + Safari (macOS/iOS): Herhaal de volledige authenticatieflow. Controleer op iOS ook of biometrische authenticatie (Face ID / Touch ID) wordt aangeboden als alternatief waar native authenticatie wordt gebruikt, en of de webgebaseerde flow volledig bedienbaar is met Switch Control als biometrie niet beschikbaar is.
7. Test met JAWS + Chrome: Herhaal de flow en let in het bijzonder op hoe widgets van derden (OAuth-sociale login, CAPTCHA-iframes) worden aangekondigd. JAWS gaat op een andere manier om met bepaalde ARIA-patronen dan NVDA; beide moeten worden getest.
8. Evalueer alternatieve paden op echte gelijkwaardigheid: Als er een alternatieve authenticatiemethode bestaat (bijv. "Inloggen met een magic link"), doorloop dan de volledige flow uitsluitend met dat alternatief. Bevestig dat deze dezelfde geauthenticeerde status bereikt zonder enige cognitieve test. Als het alternatieve pad zelf een CAPTCHA of geheugentest bevat, is het geen geldig alternatief onder 3.3.9.
9. Documenteer bevindingen met bewijs: Leg voor elke fout een schermopname of geannoteerde screenshot vast waarop precies te zien is welke stap faalt en waarom. Deze documentatie is essentieel voor overdracht naar ontwikkelteams voor herstel en voor auditdoeleinden.

Hoe te Herstellen

CAPTCHA zonder alternatief — Onjuist

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA vervangen door passkey en magic link — Juist

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Klembordplakken geblokkeerd op OTP-veld — Onjuist

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

OTP-veld met plakken ingeschakeld en autocomplete-hint — Juist

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Kennisgebaseerde beveiligingsvragen — Onjuist

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Identiteitsverificatie met niet-cognitieve alternatieven — Juist

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Veelvoorkomende Fouten

• autocomplete='off' toevoegen aan wachtwoordvelden om automatisch invullen door de browser te voorkomen. Dit schakelt het primaire mechanisme uit waarmee gebruikers het onthouden van wachtwoorden kunnen vermijden en leidt direct tot een overtreding van 3.3.9. Verwijder autocomplete='off' en gebruik in plaats daarvan autocomplete='current-password' of autocomplete='new-password'.
• Een JavaScript-paste-eventlistener koppelen die event.preventDefault() aanroept op authenticatie-invoervelden, in de veronderstelling dat dit de beveiliging verbetert. In werkelijkheid blokkeert dit wachtwoordmanagers en ondersteunende technologieën en vormt het een overschrijvingseis onder 3.3.9.
• De audio-CAPTCHA als voldoende omweg beschouwen voor visuele CAPTCHA’s. Audio-CAPTCHA’s vormen nog steeds een cognitieve functietest (het overschrijven van vervormde audiotekens) en voldoen niet aan 3.3.9. Er is een echt niet-cognitief alternatief pad vereist.
• Een passkey- of sociale login-optie aanbieden maar deze achter een CAPTCHA-uitdaging plaatsen. Als de gebruiker een cognitieve test moet doorstaan om toegang te krijgen tot het toegankelijke alternatief, is het alternatief niet werkelijk gelijkwaardig en voldoet de flow niet aan 3.3.9.
• Zes afzonderlijke invoervelden van één teken gebruiken voor OTP-invoer (een veelvoorkomend UI-patroon) zonder ondersteuning voor plakken-om-te-vullen over de velden heen. Veel implementaties plakken alleen in het eerste veld en vereisen handmatige invoer, toets voor toets, voor de overige vijf, wat een overschrijvingsbarrière vormt.
• Vertrouwen op "Onthoud mij" of persistente sessiecookies als enige voorziening voor gebruikers die zich niet herhaaldelijk kunnen authenticeren. Hoewel het verminderen van de authenticatiefrequentie helpt, lost het een ontoegankelijk authenticatieproces niet op — gebruikers moeten de cognitieve test nog steeds ten minste één keer doorstaan, en sessies verlopen of worden gewist.
• Tijdgebonden OTP-velden implementeren die bij time-out zonder waarschuwing worden gewist, waardoor gebruikers een nieuwe code moeten aanvragen en opnieuw moeten proberen deze over te schrijven. Dit vergroot de cognitieve belasting voor gebruikers met trage motorische of cognitieve verwerkingssnelheid.
• Gebruik van op afbeeldingen gebaseerde CAPTCHA-uitdagingen die het herkennen van niet-objectinhoud vereisen — zoals abstracte patronen, kleuren of reeksen persoonlijk geselecteerde foto’s — en denken dat dit voldoet aan 3.3.9. Het AAA-criterium staat alleen objectherkenning toe (objecten uit de echte wereld zoals auto’s, fietsen, verkeerslichten); herkenning van niet-objectafbeeldingen is op dit niveau niet uitgezonderd.
• Toegang tot de credentialmanager van de browser blokkeren via autocomplete='new-password' op loginvelden (in plaats van op registratievelden). De waarde new-password geeft aan browsers door dat dit een veld is voor het aanmaken van een nieuw wachtwoord, waardoor automatisch invullen van opgeslagen inloggegevens tijdens het inloggen wordt voorkomen.
• Verzuimen om authenticatieflows met daadwerkelijke ondersteunende technologieën te testen en in plaats daarvan uitsluitend vertrouwen op geautomatiseerde scanresultaten. Omdat 3.3.9 alleen handmatig testbaar is, zullen teams die handmatig testen met schermlezers en toetsenbord overslaan, systematisch fouten in dit criterium missen bij elke releasecyclus.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular No. 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt uitgebreide web- en mobiele toegankelijkheidsverplichtingen vast voor een brede reeks publieke en private entiteiten die in Turkije actief zijn. De circulaire schrijft conformiteit met WCAG 2.2 voor en is daarmee het eerste Turkse juridische instrument dat expliciet verwijst naar versie 2.2 van de standaard.

De entiteiten die onder de circulaire vallen, omvatten: overheidsinstellingen en -agentschappen op alle bestuursniveaus; e-commerceplatforms en online marktplaatsen; banken en financiële instellingen; ziekenhuizen en 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 moeten digitale diensten — waaronder loginportalen, patiëntenportalen, bankdashboards, ticketingsystemen en leerlinginformatiesystemen — voldoen aan de toegankelijkheidseisen die door de circulaire zijn gedefinieerd.

WCAG 3.3.9 is als AAA-criterium geen minimale wettelijke verplichting onder de circulaire. De wettelijk verplichte basislijn komt overeen met conformiteit met WCAG 2.2 niveau A en AA. De geest en reikwijdte van de circulaire maken 3.3.9 in de praktijk echter om meerdere redenen zeer relevant.

Ten eerste is WCAG 3.3.8 (Accessible Authentication — Minimum) wél een vereiste op AA-niveau en daarom juridisch bindend voor alle betrokken entiteiten. Organisaties die werken aan naleving van 3.3.8 zullen merken dat de stap naar naleving van 3.3.9 vaak klein en incrementeel is — voornamelijk het verwijderen van de uitzondering voor beeldherkenning die 3.3.8 toestaat en ervoor zorgen dat alle cognitieve tests niet-cognitieve alternatieven hebben, niet alleen ondersteunende mechanismen.

Ten tweede betekent voor entiteiten die diensten leveren aan populaties met hogere percentages cognitieve of motorische beperkingen — met name ziekenhuizen, publieke zorgportalen en overheidsdienstportalen — het behalen van AAA-conformiteit op authenticatiecriteria een betekenisvolle inzet voor gelijke toegang die in lijn is met de bredere constitutionele gelijkheidsbeginselen van Turkije en de verplichtingen van het land onder het VN-Verdrag inzake de Rechten van Personen met een Handicap (CRPD), dat door Turkije is geratificeerd.

Ten derde staan Turkse banken en fintech-aanbieders onder bijzondere aandacht wat betreft authenticatie. De Banking Regulation and Supervision Agency (BDDK) en de Financial Crimes Investigation Board (MASAK) leggen strenge eisen op aan identiteitsverificatie, en organisaties implementeren vaak complexe, meerstaps-authenticatieflows om aan deze eisen te voldoen. Het implementeren van 3.3.9-conforme authenticatie — met gebruik van passkeys, WebAuthn of magic-link-flows — is zowel toegankelijker als in lijn met moderne best practices voor veilige authenticatie die worden onderschreven door internationale financiële toezichthouders, waardoor het een ontwerpdoel is dat naleving op meerdere fronten tegelijk ondersteunt.

Organisaties die hun toegankelijkheidsprofiel willen onderscheiden, zich willen voorbereiden op mogelijke toekomstige aanscherping van regelgeving, of gebruikers op toegankelijke en inclusieve manieren willen bedienen, worden sterk aangemoedigd om WCAG 3.3.9 als ontwerpnorm te behandelen en niet louter als een optionele verbetering. Het implementeren van volledig niet-cognitieve authenticatiepaden is steeds beter haalbaar met moderne browser-API’s (WebAuthn/passkeys) en authenticatie-SDK’s, waardoor de kosten van naleving lager zijn dan ooit, terwijl het voordeel — het elimineren van een van de meest ingrijpende toegankelijkheidsbarrières in elk digitaal product — aanzienlijk is.