WCAG 2.1.2: Geen toetsenbordval

Wat Deze Regel Betekent

WCAG 2.1.2 — Geen toetsenbordval — is een succescriterium op niveau A onder het principe Bedienbaar. Het stelt: "If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow keys or tab keys to move focus away, the user is informed of the method for moving focus."

In praktische termen betekent dit dat elk interactief onderdeel op een webpagina waar een toetsenbordgebruiker naartoe kan tabben, de gebruiker ook moet toestaan om er weer uit te tabben. Een toetsenbordval treedt op wanneer een gebruiker navigeert naar een widget, dialoog, aangepast formulierelement, ingesloten mediaspeler of een andere focusbare regio en deze vervolgens niet kan verlaten met standaard toetsenbordbediening — de gebruiker zit in feite vast.

Het criterium heeft betrekking op alle HTML-elementen die toetsenbordfocus kunnen ontvangen: native interactieve elementen zoals <input>, <select>, <textarea>, <button> en <a>-tags, evenals aangepaste widgets die focus ontvangen via tabindex, ARIA-rollen of JavaScript-focusbeheer. Het is evenzeer van toepassing op ingesloten componenten van derden zoals chatwidgets, videospelers, kaart-embeds, datumprikkers en richtext-editors.

Een component voldoet aan dit criterium als een toetsenbordgebruiker de focus altijd kan verplaatsen met standaardtoetsen — meestal Tab, Shift+Tab, Escape of pijltjestoetsen — of als de pagina gebruikers duidelijk informeert over een niet-standaard toetsenbordmechanisme om de focus te verplaatsen. Een component faalt als de focus erin wordt opgesloten zonder toetsenbordtoegankelijke uitweg, of als het enige mechanisme om te ontsnappen een muisklik, touchbeweging of andere niet-toetsenbordinvoer vereist.

WCAG voorziet in een beperkte uitzondering: het is acceptabel om toetsenbordfocus tijdelijk binnen een component te beperken wanneer dit deel uitmaakt van een bewuste en toegankelijke ontwerppatroon — met name een modale dialoog. Een modale dialoog moet de focus binnen de dialoog vasthouden zolang deze open is (om te voorkomen dat gebruikers interageren met verborgen achtergrondinhoud), maar moet altijd een toetsenbordtoegankelijke manier bieden om de dialoog te sluiten en de focus vrij te geven — zoals een Escape-toets-handler of een duidelijk gelabelde sluitknop die met Tab bereikbaar is. Dit soort opzettelijke, te verlaten focusbeperking is geen toetsenbordval; het is een correcte implementatie van het modale dialoogpatroon. Het wordt pas een val wanneer de gebruiker er helemaal niet aan kan ontsnappen.

Waarom Het Belangrijk Is

Toetsenbordvallen behoren tot de ernstigste toegankelijkheidsfouten die een website kan hebben. In tegenstelling tot veel andere toegankelijkheidsproblemen die de ervaring voor bepaalde gebruikers verslechteren, kan een toetsenbordval een gebruiker volledig blokkeren om een pagina verder te gebruiken. Het is in wezen het equivalent van een fysieke barrière in een gang plaatsen zonder een manier om eromheen te gaan.

De groepen die het zwaarst worden getroffen zijn gebruikers met motorische of lichamelijke beperkingen die geen muis kunnen bedienen en volledig afhankelijk zijn van toetsenbordnavigatie. Dit omvat mensen met aandoeningen zoals RSI, multiple sclerose, de ziekte van Parkinson, tetraplegie en cerebrale parese. Volgens de Wereldgezondheidsorganisatie leven ongeveer 1.3 miljard mensen — 16% van de wereldbevolking — met een vorm van significante beperking, en motorische beperkingen vormen een substantieel deel van dat cijfer. Voor deze gebruikers kan het tegenkomen van een toetsenbordval op een afrekenpagina, een inlogformulier of een klantenservice-chatwidget betekenen dat zij de taak helemaal niet kunnen voltooien.

Schermlezergebruikers — voornamelijk blinde en slechtziende gebruikers — worden ook zwaar getroffen. Schermlezers zoals NVDA, JAWS en VoiceOver navigeren volledig via toetsenbordcommando’s. Als de focus in een component wordt opgesloten, hoort de schermlezergebruiker hetzelfde element herhaald worden telkens wanneer hij op Tab drukt, zonder mogelijkheid om verder of terug over de pagina te gaan. Dit is zeer desoriënterend en dwingt de gebruiker om het browsertabblad te sluiten of de pagina te verversen, waarbij alle voortgang verloren gaat.

Stel je dit scenario uit de echte wereld voor: een gebruiker met beperkte handmobiliteit bezoekt een Turkse e-commercesite om een product te kopen. Ze voegen een artikel toe aan hun winkelwagen en gaan naar de kassa. De afrekenpagina bevat een adres-autocompletewidget van een derde partij, gebouwd met een aangepast JavaScript-framework. De widget opent een dropdown met suggesties wanneer het adresveld focus krijgt. De ontwikkelaar is vergeten toetsenbordafhandeling toe te voegen om deze dropdown te sluiten — dus zodra de gebruiker naar het adresveld tabt en de dropdown verschijnt, kan die niet meer uit het veld tabben, niet op Escape drukken en de dropdown niet sluiten zonder muisklik. De gebruiker wordt volledig geblokkeerd om de aankoop te voltooien. Dit is geen klein ongemak — het is een totale uitsluiting van de dienst.

Naast toegang voor mensen met een beperking raken toetsenbordvallen ook power users die de voorkeur geven aan toetsenbordnavigatie vanwege de snelheid, gebruikers in bedrijfsomgevingen waar muisgebruik beperkt is, en gebruikers op bepaalde mobiele of hybride apparaten met hardwaretoetsenborden. Het oplossen van toetsenbordvallen verbetert daarom de ervaring voor een breder publiek dan alleen gebruikers met een beperking.

Gerelateerde Axe-core-regels

WCAG 2.1.2 vereist handmatige tests. Er is geen geautomatiseerde axe-core-regel die toetsenbordvallen direct en betrouwbaar detecteert. Dit komt doordat geautomatiseerde tools werken door de statische structuur van de DOM te analyseren — ze kunnen focusbare elementen identificeren, de tabvolgorde controleren en ARIA-attributen valideren, maar ze kunnen niet de volledige interactieve toetsenbordnavigatie-ervaring simuleren die een menselijke tester uitvoert. Een toetsenbordval ontstaat meestal door JavaScript-eventafhandeling die toetsenbordgebeurtenissen tijdens runtime onderschept of onderdrukt; dit gedrag is niet zichtbaar in de DOM-structuur en kan niet worden afgeleid door een statische analyzer.

• Handmatige test vereist — geen speciale axe-core-regel: Axe-core levert geen regel die toetsenbordvallen automatisch detecteert, omdat de foutmodus fundamenteel gedragsmatig is. De val manifesteert zich pas wanneer een gebruiker daadwerkelijk met de Tab-toets een component binnen navigeert en probeert te vertrekken. Een geautomatiseerde scanner kan dit niet repliceren, omdat hij sequentiële toetsenbordnavigatie over elk focusbaar element op de pagina zou moeten simuleren, alle bijbehorende JavaScript-eventlisteners zou moeten triggeren en vervolgens zou moeten bepalen of de focus de bedoelde regio heeft verlaten — een probleem dat computationeel onoplosbaar is voor complexe pagina’s. Bovendien vereist het onderscheid tussen een val en opzettelijke focusbeperking (zoals bij een modal) contextuele beoordeling die geautomatiseerde regels niet betrouwbaar kunnen maken. Testers kunnen axe DevTools of Lighthouse gebruiken om focusbare elementen en problemen met de tabvolgorde te identificeren als startpunt, maar moeten vervolgens handmatig met het toetsenbord door elke interactieve regio navigeren om te bevestigen dat er geen vallen bestaan.

Hoe te Testen

1. Voer een geautomatiseerde toegankelijkheidsscan uit als basislijn. Open axe DevTools (browserextensie) of voer een Lighthouse-toegankelijkheidsaudit uit in Chrome DevTools. Hoewel geen van beide tools een toetsenbordval direct zal markeren, identificeert de scan focusbare elementen, ontbrekende ARIA-rollen en onjuiste tabvolgorde die kunnen wijzen op risicovolle interactieve componenten die handmatig onderzocht moeten worden. Noteer alle aangepaste widgets, ingesloten iframes, componenten van derden, modale dialogen, dropdownmenu’s, datumprikkers, carrousels en richtext-editors — dit zijn de meest voorkomende bronnen van toetsenbordvallen.
2. Koppel je muis los of leg hem weg. Voor geldige handmatige toetsenbordtests mag je geen muis gebruiken. Leg je muis buiten handbereik of schakel hem uit in de instellingen van je besturingssysteem om te voorkomen dat je er per ongeluk op vertrouwt tijdens het testen.
3. Navigeer door de hele pagina met alleen de Tab- en Shift+Tab-toetsen. Begin vanuit de adresbalk van de browser of de bovenkant van de pagina, druk herhaaldelijk op Tab en observeer waar de focus naartoe gaat. Volg de focusindicator bij elke stap visueel. Wanneer je elk interactief onderdeel bereikt — vooral aangepaste widgets, ingesloten content of complexe UI-elementen — controleer dan of het indrukken van Tab of Shift+Tab de focus netjes uit de component verplaatst naar het volgende of vorige focusbare element op de pagina.
4. Test elke interactieve component afzonderlijk. Voor modale dialogen: open de modal, controleer of de focus erin terechtkomt, druk vervolgens op Escape en bevestig dat de focus terugkeert naar het element dat de modal opende. Voor dropdownmenu’s: open de dropdown, navigeer erin, druk vervolgens op Escape en bevestig dat de dropdown sluit en de focus terugkeert naar de trigger. Voor datumprikkers, kleurkiezers en vergelijkbare widgets: tab erin, voer interacties uit, tab er vervolgens uit en bevestig dat de focus de component verlaat. Voor ingesloten iframes (bijv. kaarten, videospelers, chatwidgets): tab het iframe in, navigeer erin en bevestig dat je er weer uit kunt tabben terug naar de hoofdpagina.
5. Test met NVDA en Firefox. Open NVDA, navigeer naar de pagina in Firefox en gebruik Tab om door interactieve elementen te gaan. Let erop of NVDA bij elke Tabdruk een nieuw element voorleest of dat het lijkt terug te springen naar hetzelfde element. Als Tab de focus niet voorbij een component brengt, is dit een toetsenbordval.
6. Test met VoiceOver en Safari op macOS. Schakel VoiceOver in (Command + F5), open de pagina in Safari en gebruik de Tab-toets om te navigeren. Bevestig dat VoiceOver bij elke Tabdruk een nieuw element aankondigt en dat de focus nooit vastzit in een regio die je niet kunt verlaten.
7. Test met JAWS en Chrome. Open JAWS, navigeer naar de pagina in Chrome en gebruik Tab om door alle interactieve componenten te navigeren. Test in het bijzonder elke component die JavaScript-gestuurd focusbeheer gebruikt, omdat JAWS met de toegankelijkheidsboom interageert op manieren die vallen kunnen onthullen die bij visuele tests niet zichtbaar zijn.
8. Controleer op niet-standaard ontsnappingsmechanismen. Als een component een andere toets dan Tab, Shift+Tab of Escape vereist om te verlaten, controleer dan of de pagina dit duidelijk aan de gebruiker communiceert — bijvoorbeeld via instructies op het scherm, een tooltip of een ARIA live-regio-aankondiging wanneer de focus de component binnenkomt.

Hoe te Herstellen

Modale Dialoog Zonder Escape-afhandeling — Onjuist

<!-- Modal opens but has no Escape key handler and no close button reachable by keyboard -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- No close button, no Escape key listener -- keyboard users are trapped -->
</div>

Modale Dialoog Zonder Escape-afhandeling — Juist

<!-- Modal with proper focus trap, Escape handler, and accessible close button -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Close button is reachable by Tab and allows keyboard users to exit -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Escape key closes the modal and returns focus to trigger
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Return focus to opener
  }
</script>

Aangepaste Dropdown Die Alle Tab-toetsgebeurtenissen Opvangt — Onjuist

<!-- Custom dropdown intercepts all keydown events including Tab, preventing focus from leaving -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // BUG: This captures ALL keyboard events and calls preventDefault on Tab,
  // meaning the user can never Tab out of this component
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // This traps the keyboard
    if (e.key === 'ArrowDown') { /* move focus down */ }
    if (e.key === 'ArrowUp') { /* move focus up */ }
  });
</script>

Aangepaste Dropdown Die Alle Tab-toetsgebeurtenissen Opvangt — Juist

<!-- Correct: Only prevent default for arrow keys used for internal navigation;
     allow Tab and Escape to function normally so users can exit -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Only prevent default for internal navigation keys
      // move focus between options
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // Do NOT call preventDefault -- allow Tab and Escape to propagate
      // so the browser can move focus away from this component naturally
      closeDropdown();
    }
  });
</script>

Ingesloten Iframe van Derden Zonder Uitweg — Onjuist

<!-- An embedded chat widget iframe that absorbs all Tab keypresses
     and never returns focus to the parent page -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- The iframe's internal JavaScript consumes Tab events, trapping users inside it -->

Ingesloten Iframe van Derden Zonder Uitweg — Juist

<!-- Use a button to open the chat in a new window rather than embedding
     an iframe that may trap keyboard users -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- If an iframe must be used, add a visible skip link before it
     so keyboard users can bypass it if they choose -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

Veelvoorkomende Fouten

• event.preventDefault() aanroepen binnen een keydown-listener zonder dit te beperken tot specifieke toetsen — preventDefault() toepassen op alle toetsenbordgebeurtenissen op een focusbare component blokkeert Tab en Shift+Tab, waardoor onmiddellijk een toetsenbordval ontstaat. Beperk preventDefault() altijd tot alleen de specifieke toetsen die je component intern moet afhandelen (zoals pijltjestoetsen voor listboxes).
• Een modale dialoog bouwen die de focus erin plaatst maar geen Escape-toetsafhandeling of sluitknop biedt — ontwikkelaars implementeren vaak het deel van het modale patroon waarin de focus de modal binnenkomt correct, maar vergeten dat focusbeperking binnen een modal alleen acceptabel is als er altijd een toetsenbordtoegankelijke uitweg is. Elke modal moet de Escape-toets afhandelen en een tabbable sluitknop bevatten.
• tabindex='-1' gebruiken op een containerelement om te voorkomen dat het in de tabvolgorde verschijnt, terwijl JavaScript nog steeds de focus er programmatisch naartoe kan verplaatsen — wanneer de focus via element.focus() naar een element met tabindex='-1' wordt verplaatst, is er geen natuurlijk Tab-doel om het te verlaten, wat de gebruiker kan vastzetten als er geen verdere toetsenbordafhandeling is geïmplementeerd.
• Widgets van derden (chat, kaarten, video) insluiten zonder ze te controleren op toetsenbordvalgedrag — leveranciers bouwen hun ingesloten widgets niet altijd toetsenbordtoegankelijk. Site-eigenaren blijven verantwoordelijk voor alle content op hun pagina’s, inclusief embeds van derden. Test ingesloten componenten altijd handmatig en, als ze toetsenbordgebruikers vastzetten, voorzie ze van een skiplink of vervang ze door een toetsenbordveilige alternatieve oplossing.
• Een focustrap implementeren voor een modal of drawer maar de trap niet opheffen wanneer de component sluit — als de JavaScript die de focus beperkt niet correct wordt opgeruimd wanneer de modal sluit, kan deze Tab-gebeurtenissen blijven onderscheppen en de gebruiker vasthouden op de nu onzichtbare laag.
• CSS visibility: hidden of display: none gebruiken om de sluitknop van een dialoog om visuele redenen te verbergen zonder een alternatieve toetsenborduitweg te bieden — als de sluitknop visueel verborgen is maar niet uit de toegankelijkheidsboom is verwijderd, kunnen schermlezergebruikers hem nog steeds vinden; maar als hij ook uit de toegankelijkheidsboom is verborgen, is er mogelijk geen uitweg. Controleer dat alle sluitmechanismen met het toetsenbord bedienbaar zijn, zelfs als ze visueel discreet zijn gestileerd.
• Aangepaste autocomplete- of type-aheadcomponenten bouwen die een suggestielijst openen en vervolgens alle Tab-toetsdrukken gebruiken om door suggesties te bladeren in plaats van te verlaten — gebruikers moeten op Escape kunnen drukken om de suggestielijst te sluiten en vervolgens op Tab om naar het volgende formulierveld te gaan. Autocomplete-widgets die Tab omleiden naar interne navigatie schenden dit criterium.
• Vergeten richtext-editors te testen (WYSIWYG-editors zoals TinyMCE, CKEditor of Quill) — deze componenten beheren hun eigen toetsenbordinteractie intern en zijn een frequente bron van toetsenbordvallen. Bevestig altijd dat het indrukken van Escape of een gedocumenteerde toetscombinatie de editor verlaat en de focus terugbrengt naar de normale tabvolgorde van de pagina.
• Aannemen dat een component geen toetsenbordval kan zijn omdat hij native HTML-elementen gebruikt — een <select>-element in een formulier dat JavaScript gebruikt om zijn blur-event te overschrijven, kan de focus nog steeds vastzetten. Het gebruik van semantische HTML garandeert geen gedrag zonder toetsenbordvallen wanneer er aangepaste JavaScript-eventafhandeling bovenop wordt gelegd.
• Geen documentatie op het scherm bieden wanneer een niet-standaard toets nodig is om een component te verlaten — WCAG 2.1.2 staat expliciet componenten toe die niet-standaard toetsen vereisen om te verlaten, mits de gebruiker wordt geïnformeerd. Als je widget vereist dat de gebruiker op F6 of een aangepaste toetscombinatie drukt om te vertrekken, moet je dit duidelijk communiceren, idealiter via zichtbare instructies naast de component of een ARIA live-regio-aankondiging wanneer de focus de component binnenkomt.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidentiële Circulaire 2025/10, gepubliceerd in het Staatsblad nr. 32933 op 21 juni 2025, stelt bindende digitale toegankelijkheidseisen vast voor een breed scala aan publieke en private entiteiten die in Turkije actief zijn. De circulaire verplicht naleving van internationaal erkende webtoegankelijkheidsstandaarden — in lijn met WCAG 2.1 niveau AA als basis, dat alle criteria op niveau A omvat, waaronder WCAG 2.1.2 Geen toetsenbordval.

WCAG 2.1.2 is een criterium op niveau A, wat het minimale nalevingsniveau vertegenwoordigt. Onder de circulaire is naleving op niveau A verplicht voor alle betrokken entiteiten. Overheidsinstellingen moeten deze naleving binnen één jaar na publicatie van de circulaire bereiken, terwijl private entiteiten twee jaar krijgen om te voldoen.

De entiteiten die onder de circulaire vallen, zijn breed en omvatten overheidsinstellingen en -organen op alle niveaus, e-commerceplatforms en exploitanten van online marktplaatsen, banken en financiële dienstverleners, ziekenhuizen en zorgaanbieders, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die zijn gemachtigd door het Ministry of National Education (MoNE). Dit betekent dat het niet aanpakken van toetsenbordvallen op een website of webapplicatie die door een van deze entiteiten wordt beheerd, een directe schending vormt van de verplichte toegankelijkheidsregelgeving van Turkije.

Gezien de prevalentie van toetsenbordvalfouten in complexe webapplicaties — met name in online bankportalen, systemen voor het boeken van ziekenhuisafspraken, e-commerce-afrekenstromen en telecompagina’s voor accountbeheer — verdient WCAG 2.1.2 bijzondere aandacht in de Turkse nalevingscontext. Dit zijn precies de soorten interactie-intensieve, JavaScript-gedreven interfaces die het meest waarschijnlijk aangepaste widgets, modale dialogen en embeds van derden bevatten die toetsenbordgebruikers onbedoeld kunnen vastzetten.

Organisaties die onder de circulaire vallen, moeten toetsenbordvaltests beschouwen als een niet-onderhandelbaar onderdeel van hun toegankelijkheidsauditproces. Omdat geautomatiseerde tools toetsenbordvallen niet betrouwbaar kunnen detecteren, moeten betrokken entiteiten investeren in handmatige toetsenbordtests, uitgevoerd door gekwalificeerde toegankelijkheidsspecialisten, bij voorkeur inclusief gebruikers met een beperking, als onderdeel van hun pad naar naleving. Het niet verhelpen van toetsenbordvallen die tijdens een audit worden geïdentificeerd, vormt niet alleen een juridisch risico onder de circulaire, maar ook een aanzienlijke toegangsbarrière voor gebruikers met motorische en visuele beperkingen die afhankelijk zijn van toetsenbordnavigatie om digitale diensten te gebruiken.