WCAG 2.1.3: Toetsenbord (geen uitzondering)

Wat Deze Regel Betekent

WCAG 2.1.3 — Keyboard (No Exception) is een succescriterium op Niveau AAA onder WCAG 2.1 en 2.2 dat WCAG 2.1.1 (Keyboard, Niveau A) uitbreidt door alle uitzonderingen te verwijderen. Concreet stelt het: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. Het cruciale verschil met 2.1.1 is de afwezigheid van de uitzonderingsclausule die functionaliteit uitsluit waarbij de onderliggende functie invoer vereist die afhangt van het pad van de beweging van de gebruiker, en niet alleen van de eindpunten.

Onder 2.1.1 kunnen ontwikkelaars legitiem functies zoals freehand-teken­canvassen, gebaren­gebaseerde tekentools of padgevoelige sleepinterfaces uitsluiten van toetsenbordondersteuning, omdat het exacte pad van de aanwijzer van de gebruiker de output bepaalt. WCAG 2.1.3 elimineert deze uitzondering volledig. Onder dit criterium moet elke afzonderlijke functie—inclusief tekenen, slepen, padafhankelijke gebaren en elke interactie die historisch gezien afhankelijk was van aanwijzerbeweging—toegankelijk zijn via het toetsenbord. Dit betekent dat ontwikkelaars alternatieve toetsenbordmechanismen moeten bieden (bijvoorbeeld een toegankelijke toolbar met vormtools, toetsenbordgestuurde tekenmodi of formuliergebaseerde invoeralternatieven) zelfs voor freehand- of padafhankelijke taken.

Een pass vereist dat elke handeling op de pagina kan worden gestart, genavigeerd en voltooid met alleen het toetsenbord. Dit omvat focusbeheer, modale dialogen, drag-and-drop herschikking, aangepaste sliders, canvas-teken­tools, kaartinteracties, carrouselnavigatie en videobediening. Er mag geen toetsenbordval zijn (ook gedekt door 2.1.2), geen functie die alleen kan worden geactiveerd door te klikken, hoveren of touch-gebaren te gebruiken zonder een gelijkwaardig toetsenbordpad, en geen afhankelijkheid van muisaanwijzerpaden.

Een fail treedt op wanneer enige functionaliteit—ongeacht hoe niche of secundair die ook lijkt—niet kan worden bereikt of voltooid met alleen het toetsenbord. Omdat dit criterium geen uitzonderingen kent, vormt zelfs één enkele functie die niet via het toetsenbord toegankelijk is een volledige mislukking, wat het tot een van de meest veeleisende standaarden in WCAG maakt.

Waarom Het Belangrijk Is

Toetsenbordtoegankelijkheid is fundamenteel voor gebruikers met motorische beperkingen die geen aanwijzerapparaat kunnen gebruiken. Mensen met aandoeningen zoals de ziekte van Parkinson, tetraplegie, cerebrale parese, RSI of verschillen in ledematen zijn vaak volledig afhankelijk van een fysiek toetsenbord, een schakelapparaat, een sip-and-puff-controller of oogbesturingstechnologie die toetsenbordinvoer emuleert. Volgens de Wereldgezondheidsorganisatie leven wereldwijd ongeveer 1,3 miljard mensen met een vorm van significante beperking, en motorische of fysieke beperkingen vormen een substantieel deel van die populatie. Alleen al in Turkije geven gegevens van het Turkse Statistische Instituut (TÜİK) aan dat meer dan 8,5 miljoen mensen ten minste één vorm van functionele beperking rapporteren.

Naast motorische beperkingen komt toetsenbordtoegankelijkheid ten goede aan blinde en slechtziende gebruikers die navigeren met schermlezers zoals NVDA, JAWS of VoiceOver—die allemaal vertrouwen op toetsenbordcommando’s om webcontent te doorlopen en ermee te interageren. Gebruikers met fotosensitieve aandoeningen vermijden mogelijk touchscreens, en gebruikers met cognitieve beperkingen profiteren vaak van de voorspelbare, lineaire navigatie die toetsenbordinteractie biedt.

Denk aan een concreet scenario uit de echte wereld: een grafisch ontwerpplatform dat een freehand vector-teken­tool aanbiedt. Onder WCAG 2.1.1 zou dit kunnen worden uitgezonderd omdat het aanwijzerpad de vorm bepaalt. Onder WCAG 2.1.3 moet het platform een alternatief bieden—bijvoorbeeld een vormenbibliotheek, een reeks toetsenbordgestuurde ankerpunten of een tekstgebaseerde SVG-padeditor—zodat een gebruiker met een motorische beperking nog steeds vectorillustraties kan maken zonder muis. Dit niet doen sluit een betekenisvol segment van creatieve professionals uit die afhankelijk zijn van uitsluitend toetsenbordtoegang.

Vanuit gebruiksvriendelijkheid en SEO-perspectief hebben interfaces die goed toetsenbordtoegankelijk zijn doorgaans schoner focusbeheer, een logischere tabvolgorde en goed gestructureerde DOM-hiërarchieën—die allemaal bijdragen aan betere crawlbaarheid en een hogere kwaliteit van de gebruikerservaring voor iedereen, inclusief power users die toetsenbord­snelkoppelingen prefereren voor snelheid.

Gerelateerde Axe-core Regels

WCAG 2.1.3 vereist handmatige tests. In tegenstelling tot veel WCAG-criteria kunnen geautomatiseerde tools overtredingen van dit criterium niet betrouwbaar detecteren omdat:

• Detectie van padafhankelijke functionaliteit buiten statische analyse valt: Axe-core en Lighthouse inspecteren de DOM op structurele patronen—ontbrekende tabindex, ontbrekende role-attributen of defect focusbeheer—maar ze kunnen niet simuleren dat een gebruiker elke functie op een pagina probeert en vaststelt of er een toetsenbordalternatief bestaat. Een canvas-element kan in de DOM aanwezig zijn zonder ARIA-attributen, terwijl een toegankelijke toetsenbordtoolbar in de buurt volledig aan 2.1.3 kan voldoen. Omgekeerd kan een ogenschijnlijk normale knop een JavaScript-actie triggeren die op zijn beurt een widget start die alleen met de muis te bedienen is, wat geautomatiseerde tools nooit zouden signaleren. De logische gelijkwaardigheid van toetsenbordalternatieven aan muisgestuurde paden vereist menselijke beoordeling.
• Er is geen specifieke axe-core-regel die naar 2.1.3 mapt: De meest verwante axe-regels—zoals scrollable-region-focusable (die controleert of scrollbare contentregio’s toetsenbordfocus kunnen krijgen) en tabindex (die positieve tabindex-waarden markeert die de natuurlijke focusvolgorde verstoren)—behandelen gerelateerde maar beperktere kwesties onder 2.1.1 en 2.4.3. Ze evalueren niet en kunnen niet evalueren of alle functionaliteit, inclusief padgevoelige handelingen, een toetsenbord­equivalent heeft.
• Audits van interactieve widgets vereisen runtime-interactie: Aangepaste drag-and-drop-componenten, canvasgebaseerde editors en gebarengestuurde carrousels onthullen hun toetsenbordontoegankelijkheid pas wanneer een tester daadwerkelijk probeert ze zonder muis te gebruiken. De statische DOM-scan van axe-core kan geen event listeners triggeren, geen focusverlies tijdens asynchrone operaties observeren en niet beoordelen of een sleepactie kan worden voltooid via pijltjestoetsen en Enter/Spatie.
• Waarop te letten tijdens een handmatige audit: Testers moeten specifiek letten op canvas-elementen die worden gebruikt voor tekenen of interactie, drag-and-drop-lijsten of bestandsuploadgebieden, aangepaste kaart- of datavisualisatie­bediening, tijdgebaseerde sliders en elke component die reageert op mousemove, pointermove of touch-gebeurtenissen zonder bijbehorende toetsenbord­eventhandlers.

Hoe te Testen

1. Voer een geautomatiseerde baselinescan uit: Gebruik axe DevTools (browserextensie of CLI) of Google Lighthouse op je pagina om voor de hand liggende toetsenbordtoegankelijkheidsproblemen te identificeren—ontbrekende focusbare elementen, toetsenbordvallen of elementen met pointer-events: none die interactief zouden moeten zijn. Hoewel deze tools 2.1.3-overtredingen niet direct zullen detecteren, brengen ze gerelateerde problemen aan het licht en leggen ze een schone basis voordat met handmatig testen wordt begonnen.
2. Breng alle interactieve functionaliteit in kaart: Maak vóór het testen een volledige inventaris van elke interactieve component op de pagina: knoppen, links, formulieren, modals, accordeons, carrousels, kaarten, canvas-tools, drag-and-drop-gebieden, aangepaste dropdowns, datumprikkers, videospelers en elke widget die reageert op muis- of touchgebeurtenissen. Deze inventaris wordt je testchecklist.
3. Testen met alleen het toetsenbord: Koppel je muis los of schakel die uit. Gebruik Tab en Shift+Tab om de focus te verplaatsen, Enter en Spatie om bedieningselementen te activeren, Pijltjestoetsen voor samengestelde widgets (menu’s, sliders, tabs, radiogroepen) en Escape om dialogen te sluiten. Probeer elke functie op je inventarislijst te voltooien. Noteer elke functie die je niet kunt starten, voltooien of verlaten met alleen het toetsenbord.
4. Schermlezertest met NVDA + Firefox: Start NVDA (Windows) met Firefox. Navigeer met de virtuele cursor (H voor koppen, B voor knoppen, F voor formuliervelden, Tab voor interactieve elementen). Probeer elke functie. Luister naar aangekondigde rol, naam en status. Identificeer elke interactieve regio die onbereikbaar is of geen hoorbare aankondiging produceert.
5. Schermlezertest met JAWS + Chrome: Gebruik JAWS op Windows met Chrome. Gebruik de JAWS-virtuele cursor en Forms Mode (schakel met Enter). Controleer of alle functionaliteit bedienbaar is en of de focus correct wordt beheerd na elke interactie—vooral nadat modale dialogen openen of AJAX-content wordt geladen.
6. Schermlezertest met VoiceOver + Safari (macOS/iOS): Schakel VoiceOver in (Command + F5 op macOS). Gebruik Control + Option + Pijltjestoetsen om te navigeren. Gebruik op iOS veeggebaren. Bevestig dat alle functies bereikbaar en bedienbaar zijn. Let in het bijzonder op aangepaste touch-gebaseerde widgets die mogelijk toetsenbord­equivalenten missen in de desktopversie.
7. Audit van padafhankelijke functionaliteit: Controleer voor elke teken­canvas, kaartinteractie of gebarengestuurde component of er een alternatief toetsenbordmechanisme bestaat. Probeer een vorm te maken, een lijstitem te herschikken of een kaart te pannen met alleen toetsenbordbediening. Als er geen toetsenbordpad bestaat, is dit een directe 2.1.3-fout.
8. Controle van focuszichtbaarheid: Bevestig tijdens navigatie met alleen het toetsenbord dat de focus altijd zichtbaar is op het scherm en logisch geordend. Onzichtbare focus of focus die naar onverwachte locaties springt, is een gebruiksvriendelijkheidsprobleem en schendt waarschijnlijk ook 2.4.7 en 2.4.3.

Hoe te Herstellen

Canvas-teken­tool — Onjuist

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Canvas-teken­tool — Juist

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Drag-and-drop-lijst herschikken — Onjuist

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Drag-and-drop-lijst herschikken — Juist

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Interactieve kaartbediening — Onjuist

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Interactieve kaartbediening — Juist

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Veelvoorkomende Fouten

• Aannemen dat de padafhankelijke uitzondering van WCAG 2.1.1 nog steeds van toepassing is: Ontwikkelaars die vertrouwd zijn met Niveau A bouwen soms freehand-teken- of gebarentools zonder toetsenbordalternatieven, zonder zich te realiseren dat 2.1.3 deze uitzondering expliciet verwijdert. Elke functie, inclusief padgevoelige functies, moet op dit niveau een toetsenbord­equivalent hebben.
• Alleen onclick- en onmousedown-handlers koppelen aan aangepaste interactieve elementen: Aangepaste widgets die zijn gebouwd met <div>- of <span>-elementen die alleen naar muisgebeurtenissen luisteren, zijn volledig onbereikbaar via het toetsenbord. Voeg altijd onkeydown- of onkeyup-handlers toe naast muisgebeurtenislisteners en zorg ervoor dat het element tabindex='0' en een passende ARIA-rol heeft.
• tabindex='-1' gebruiken op elementen die in de tabvolgorde zouden moeten staan: Het instellen van tabindex='-1' verwijdert een element uit de sequentiële tabvolgorde. Dit is alleen geschikt voor elementen die programmatisch worden beheerd (bijv. binnen een samengestelde widget met roving tabindex). Het toepassen ervan op zelfstandige interactieve bedieningselementen maakt ze ontoegankelijk via het toetsenbord.
• Drag-and-drop implementeren zonder een toetsenbordgebaseerd mechanisme voor herschikking: Bibliotheken zoals SortableJS of aangepaste sleepimplementaties bieden vaak standaard geen toetsenbordalternatief. Ontwikkelaars moeten het ARIA-drag-and-drop-patroon implementeren of herschikking met pijltjestoetsen Omhoog/Omlaag bieden zodat het herschikken van lijsten volledig via het toetsenbord bedienbaar is.
• Vertrouwen op :hover-CSS om interactieve bedieningselementen te tonen: Dropdown-submenu’s, tooltip-gebaseerde actieknoppen of bedieningselementen die alleen bij hover verschijnen, zijn ontoegankelijk voor toetsenbordgebruikers tenzij :focus- en :focus-within-toestanden ook worden afgehandeld. Een toetsenbordgebruiker kan nooit hoveren, dus content die alleen bij hover zichtbaar is, is feitelijk voor hen verborgen.
• Focus niet beheren na dynamische contentwijzigingen: Wanneer een modal wordt geopend, een inline-melding verschijnt of een AJAX-geladen widget bestaande content vervangt, moet de focus programmatisch naar de nieuwe content worden verplaatst met element.focus(). Dit niet doen laat toetsenbordgebruikers achter op de positie waar ze de wijziging hebben geactiveerd, zonder bewustzijn dat er nieuwe content bestaat.
• Aangepaste sliders bouwen met alleen onmousemove: Range-achtige sliders die zijn opgebouwd uit <div>-elementen die muispositie volgen voor waardewijzigingen, moeten ook ArrowLeft, ArrowRight, Home en End-toetsafhandeling implementeren volgens het ARIA-sliderpatroon, en de huidige waarde blootleggen via aria-valuenow, aria-valuemin en aria-valuemax.
• Toetsenbordfocus in iframes plaatsen zonder een uitweg te bieden: Ingesloten iframes—vooral die met third-party widgets zoals kaarten, betaalformulieren of chattools—kunnen toetsenbordfocus vasthouden als de ingesloten content zelf niet toetsenbordtoegankelijk is en de Escape-toets niet ondersteunt om de focus terug te brengen naar het bovenliggende document.
• Toetsenbordondersteuning weglaten bij canvas-gebaseerde datavisualisaties: Grafieken en diagrammen die op <canvas> worden gerenderd, zijn onzichtbaar voor het toetsenbord en schermlezers tenzij er een toegankelijke alternatieve weergave (een datatabel, een SVG-equivalent met ARIA of toetsenbordnavigeerbare datapunten) naast het canvas-element wordt aangeboden.
• Toetsenbordtoegankelijkheid alleen testen met Tab en Enter, waarbij samengestelde widgetpatronen worden genegeerd: Veel ARIA-widgetpatronen—menu’s, trees, grids, tabpanels, listboxen—vereisen navigatie met pijltjestoetsen binnen de widget, met slechts één tabstop voor de hele component (roving tabindex). Alleen testen met Tab en Enter zal fouten in deze samengestelde patronen niet aan het licht brengen en geeft een vals gevoel van conformiteit.

Relatie met de Toegankelijkheidsregelgeving van Turkije

De Turkse Presidential Circular 2025/10, gepubliceerd in het Staatsblad met nummer 32933 op 21 juni 2025, stelt een uitgebreid raamwerk voor web- en mobiele toegankelijkheid vast voor een brede reeks publieke en private entiteiten die in Turkije actief zijn. De circulaire verplicht naleving van normen die zijn afgestemd op WCAG 2.1 en 2.2, en vereist dat betrokken organisaties ervoor zorgen dat hun digitale diensten waarneembaar, bedienbaar, begrijpelijk en robuust zijn voor alle gebruikers, inclusief mensen met een beperking.

De entiteiten die onder deze regelgeving vallen, omvatten overheidsinstellingen en -agentschappen op alle bestuursniveaus, e-commerceplatforms, banken en aanbieders van financiële diensten, ziekenhuizen en zorginstellingen, telecombedrijven met 200,000 of meer abonnees, reisbureaus, particuliere vervoersbedrijven en particuliere scholen die opereren onder autorisatie van het Ministry of National Education (MoNE). Voor deze organisaties is naleving van succescriteria op Niveau A en Niveau AA de minimale wettelijke basislijn.

WCAG 2.1.3 — Keyboard (No Exception) is een criterium op Niveau AAA en is daarom niet expliciet voorgeschreven als minimale wettelijke vereiste onder de circulaire. De geest van de regelgeving—het waarborgen van gelijke digitale toegang voor de miljoenen gebruikers met een beperking in Turkije—sluit echter sterk aan bij de intentie van dit criterium. Organisaties in de betrokken sectoren die gespecialiseerde diensten aanbieden aan gebruikers met motorische beperkingen, of die overheidsportalen exploiteren die worden gebruikt door burgers die afhankelijk zijn van ondersteunende technologie, doen er verstandig aan AAA-conformiteit voor toetsenbordtoegang na te streven.

Het behalen van WCAG 2.1.3-conformiteit geeft blijk van een toonaangevende toegankelijkheids­inzet die verder gaat dan de minimale regelgevingseisen. Voor Turkse organisaties die de breedst mogelijke gebruikersbasis willen bedienen, maatschappelijke verantwoordelijkheid willen tonen of willen deelnemen aan digitale markten van de Europese Unie waar hogere toegankelijkheidsnormen kunnen gelden, is het implementeren van volledige toetsenbordbedienbaarheid zonder uitzonderingen zowel een concurrentievoordeel als een ethisch voordeel. Naarmate het regelgevingslandschap van Turkije zich ontwikkelt en handhavingsmechanismen volwassen worden, zullen vroege adopters van AAA-criteria zoals 2.1.3 goed gepositioneerd zijn om eventuele toekomstige aanscherping van regelgeving het hoofd te bieden zonder kostbare hersteltrajecten.