Toetsenbordtoegankelijkheid: hoe u uw website volledig navigeerbaar met het toetsenbord maakt

Stel je voor dat je een sollicitatieformulier probeert in te vullen, een medische afspraak wilt boeken of een online aankoop wilt afronden — en je muis doet het niet. Niet kapot, gewoon irrelevant: je navigeert volledig met Tab, Enter en pijltjestoetsen. Voor miljoenen mensen wereldwijd is dit geen gedachte-experiment. Mensen met motorische beperkingen, RSI-klachten, visuele beperkingen en mensen die afhankelijk zijn van schermlezers vertrouwen allemaal op toetsenbordnavigatie als hun primaire interface met het web. Toch laat onderzoek consequent zien dat 85% van de websites geen adequate toetsenbordnavigatie biedt, waardoor deze gebruikers elke dag worden buitengesloten van basis digitale taken. Als jouw site tot die meerderheid behoort, is deze gids voor jou.

Wie Afhankelijk Is van Toetsenbordnavigatie — en Waarom Het Belangrijker Is Dan Je Denkt

Toetsenbordtoegankelijkheid is geen nicheprobleem voor een kleine groep gebruikers. De groep mensen die ervan afhankelijk is, is breder en gevarieerder dan de meeste ontwikkelaars beseffen. Mensen met fysieke beperkingen die geen muis kunnen gebruiken, mensen die blind zijn en de muisaanwijzer op het scherm niet kunnen zien, en mensen met chronische aandoeningen zoals RSI die hun muisgebruik moeten beperken, vertrouwen allemaal op toetsenbordnavigatie als hun toegangspoort tot het web. Buiten de context van beperking geven veel power users — ontwikkelaars, schrijvers, data-entry professionals — de voorkeur aan sneltoetsen voor snelheid en efficiëntie.

Schermlezergebruikers vormen een andere grote groep. Schermlezers interpreteren en kondigen pagina-elementen aan op basis van focus en semantische structuur, en gebruikers bewegen door de content met toetsaanslagen. Als een website de toetsenbordfocus niet behoudt of geen logische focusvolgorde ondersteunt, valt schermlezernavigatie volledig uit elkaar. Spraakherkenningssoftware zoals Dragon NaturallySpeaking genereert ook toetsenbordgebeurtenissen, wat betekent dat slechte toetsenbordondersteuning ook spraakgestuurde browsing breekt.

De zakelijke argumenten zijn minstens zo overtuigend. Volgens beschikbare gegevens beschikken mensen met een beperking in de VS over bijna een half biljoen dollar aan vrij besteedbaar inkomen. Wanneer je website niet toetsenbordtoegankelijk is, keer je actief een aanzienlijk deel van die markt de rug toe. De juridische risico’s zijn ook reëel: toetsenbordtoegankelijkheid is essentieel voor conformiteit met WCAG, de maatstaf voor naleving van de ADA, Section 508, de European Accessibility Act en EN 301 549 wereldwijd. Alleen al toetsenbordvallen — waarbij een gebruiker vast komt te zitten in een pagina-element zonder uitweg — worden genoemd als duidelijke WCAG-fouten die in toegankelijkheidsrechtszaken zijn aangehaald.

Misschien wel het meest veelzeggend: 71% van de gebruikers met een beperking verlaat simpelweg een website die ze moeilijk te gebruiken vinden. Ze klagen niet. Ze gaan weg. En omdat problemen met toetsenbordtoegankelijkheid zich vaak concentreren rond de meest kritieke interactiepunten — formulieren, modals, navigatiemenu’s en checkoutflows — komt de schade rechtstreeks terecht op je conversieratio’s.

Het WCAG-raamwerk: Wat de Regels Echt Vereisen

De Web Content Accessibility Guidelines (WCAG) organiseren toetsenbordvereisten primair onder Richtlijn 2.1 — "Maak alle functionaliteit beschikbaar via een toetsenbord". Begrijpen wat wel en niet vereist is, is de eerste stap richting naleving. WCAG 2.2, dat op 5 oktober 2023 de officiële W3C-standaard werd en negen nieuwe succescriteria toevoegde aan het bestaande raamwerk, is nu de aanbevolen standaard voor ADA, Section 508 en de European Accessibility Act.

De belangrijkste toetsenbordgerelateerde succescriteria die je moet kennen zijn:

• SC 2.1.1 Keyboard (Niveau A): Alle functionaliteit moet bedienbaar zijn via een toetsenbordinterface zonder specifieke timingvereisten voor individuele toetsaanslagen, behalve wanneer de onderliggende functie pad-afhankelijke invoer vereist (zoals vrij tekenen). Dit is de basis — elk interactief element moet via het toetsenbord bereikbaar en bedienbaar zijn.
• SC 2.1.2 No Keyboard Trap (Niveau A): Als de toetsenbordfocus met het toetsenbord naar een component kan worden verplaatst, moet de focus ook uitsluitend met het toetsenbord weer kunnen worden verplaatst. Als een niet-standaard methode nodig is om te ontsnappen, moeten gebruikers daarover worden geïnformeerd. Toetsenbordvallen zijn een absolute blokkade voor toetsenbordgebruikers.
• SC 2.4.3 Focus Order (Niveau A): Als een webpagina sequentieel kan worden genavigeerd, moet de focusvolgorde betekenis en bedienbaarheid behouden. Een logische, voorspelbare tabvolgorde is niet onderhandelbaar.
• SC 2.4.7 Focus Visible (Niveau AA): Elke via het toetsenbord bedienbare gebruikersinterface moet een modus hebben waarin de toetsenbordfocusindicator zichtbaar is. Gebruikers moeten altijd kunnen zien waar ze zich op de pagina bevinden.
• SC 2.4.11 Focus Not Obscured (Minimum) (Niveau AA — nieuw in WCAG 2.2): Wanneer een element dat met het toetsenbord focusbaar is, focus krijgt, mag het niet volledig verborgen zijn door door de auteur gecreëerde content zoals sticky headers of cookiebanners.
• SC 2.4.12 Focus Not Obscured (Enhanced) (Niveau AAA): Een strengere versie die vereist dat geen enkel deel van de gefocuste component wordt verborgen door door de auteur gecreëerde content.
• SC 2.5.8 Target Size (Minimum) (Niveau AA — nieuw in WCAG 2.2): Interactieve targets moeten minimaal 24x24 CSS-pixels zijn, om fouten te verminderen voor gebruikers met beperkte motorische controle.
• SC 2.5.7 Dragging Movements (Niveau AA — nieuw in WCAG 2.2): Elke functionaliteit die slepen vereist, moet een alternatief met één aanwijzer hebben — wat indirect ook ten goede komt aan toetsenbordgebruikers die geen sleepacties kunnen uitvoeren.

WCAG 2.2 is volledig achterwaarts compatibel met WCAG 2.1 — er worden criteria toegevoegd maar geen verwijderd (behalve het nu verouderde 4.1.1 Parsing). Als je site al voldoet aan WCAG 2.1 AA, hoef je alleen de zes nieuwe Level AA-criteria te implementeren. Voor toetsenbordtoegankelijkheid in het bijzonder is de grote nieuwe toevoeging dat gefocuste elementen nooit volledig mogen worden bedekt door sticky paginameubels — een veelvoorkomend praktijkprobleem dat WCAG 2.1 niet expliciet adresseerde.

Het WCAG-principe is eenvoudig te formuleren, veeleisend om te implementeren: als alle functionaliteit met het toetsenbord kan worden uitgevoerd, kan die worden gebruikt door toetsenbordgebruikers, spraakinput, on-screen toetsenborden en een breed scala aan ondersteunende technologieën die gesimuleerde toetsaanslagen genereren. Geen enkele andere invoervorm heeft deze flexibiliteit of wordt zo universeel ondersteund.

De Meest Voorkomende Fouten bij Toetsenbordtoegankelijkheid (en Waardoor Ze Worden Veroorzaakt)

Handmatige audits laten consequent zien dat problemen met toetsenbordtoegankelijkheid behoren tot de meest voorkomende en verstorende toegankelijkheidsbarrières op het web. In één grootschalige studie had 54% van de pagina’s met formulieren problemen met toetsenbordtoegankelijkheid die kritieke gebruikersacties beïnvloedden, zoals tabben tussen formuliervelden, pop-upvensters sluiten of op verzendknoppen drukken. Testers werden vaak gedwongen winkelwagens te verlaten of pagina’s te verversen nadat ze vastliepen op elementen die ze niet uitsluitend met het toetsenbord konden bedienen.

De oorzaken clusteren rond een handvol terugkerende patronen die het waard zijn om in detail te bekijken.

1. Alleen-muis event handlers. Het gebruik van onmouseover, onmouseout of onclick op <div>-elementen zonder equivalente toetsenbord-event handlers is een van de meest voorkomende fouten. Een <div> met een click handler is geen knop — het heeft geen impliciete toetsenbordrol, krijgt geen focus via Tab en reageert niet op Enter of Spatie. Het toevoegen van role='button' via ARIA helpt schermlezers, maar vereist nog steeds dat je handmatig tabindex='0', onkeydown en onkeyup handlers toevoegt. De juiste oplossing is bijna altijd het gebruik van een echt <button>-element.

2. Onderdrukte focusomtrekken. Een van de meest wijdverspreide problemen is de CSS-regel outline: none of outline: 0 die globaal of op gefocuste elementen wordt toegepast. Designers verwijderen vaak de standaard focusring van de browser omdat die er in bepaalde thema’s onaantrekkelijk uitziet. Het resultaat is dat toetsenbordgebruikers geen idee hebben waar ze zich op de pagina bevinden. Dit is een directe schending van WCAG SC 2.4.7 en een van de makkelijkste problemen om te creëren — en op te lossen.

3. Toetsenbordvallen in modals, widgets en iframes. Modale dialogen die de focus niet correct beperken, laten Tab gewoon doorlopen voorbij de modal naar verborgen achtergrondcontent, waardoor de modal onmogelijk via het toetsenbord kan worden gesloten. Third-party widgets — chattools, videospelers, datepickers, kaart-embeds — zijn hier bijzonder gevoelig voor omdat hun interne toetsenbordafhandeling voor jou ondoorzichtig is.

4. Onlogische tabvolgorde. De standaard navigatievolgorde met het toetsenbord wordt bepaald door de DOM-bronvolgorde. Wanneer ontwikkelaars CSS Grid, Flexbox of CSS-positionering gebruiken om de visuele presentatie onafhankelijk van de DOM-volgorde te herschikken, springt de Tab-focus over het scherm op manieren die volledig losstaan van de visuele layout. Positieve tabindex-waarden (bijv. tabindex='2') die worden gebruikt om een specifieke volgorde af te dwingen, maken dit probleem in de meeste praktijksituaties aanzienlijk erger.

5. Alleen-hover dropdownmenu’s. Navigatiemenu’s die alleen openen bij muis-hover, zonder toetsenbordtrigger, laten toetsenbordgebruikers in de steek. Dit is een extreem veelvoorkomend patroon in CSS-only dropdownmenu’s, waar submenu’s verschijnen bij :hover maar nooit worden blootgesteld aan focusgebaseerde navigatie.

6. Focus wordt niet teruggezet na dynamische interacties. Wanneer een modal, drawer of flyout wordt gesloten, moet de focus terugkeren naar het element dat deze heeft geopend. Als dat niet gebeurt — als de focus bovenaan de pagina belandt of verdwijnt naar een onbepaalde locatie — is de gebruiker volledig de weg kwijt. Dynamische single-page applicaties zijn hier bijzonder kwetsbaar voor.

Toetsenbordtoegankelijkheid Goed Bouwen: Praktische Implementatie

Met de faalpatronen in gedachten, volgt hier hoe correcte implementatie eruitziet in de belangrijkste delen van een typische website.

Gebruik Eerst Semantische HTML

Native HTML-elementen zijn standaard toetsenbordtoegankelijk. Links (<a href>), knoppen (<button>), formulierinputs, selects en textareas doen allemaal mee in de tabvolgorde, reageren op standaardtoetsaanslagen en communiceren hun rol aan ondersteunende technologieën — allemaal zonder een regel extra JavaScript. Een <button>-element heeft automatisch de juiste rol, is toetsenbordtoegankelijk, reageert op Enter en Spatie en heeft ingebouwde focusafhandeling. Het toevoegen van role='button' aan een <div> geeft wel de juiste rol, maar vereist nog steeds dat je toetsenbordondersteuning en focusafhandeling handmatig implementeert. Geef altijd de voorkeur aan semantische HTML.

<!-- Vermijd: niet-semantische div die zich voordoet als knop -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Correct: native button-element -->
<button type='button' onclick='doSomething()'>Submit</button>

Repareer Je Focusindicatoren

In plaats van de standaardomtrek van de browser te verwijderen, overschrijf je die met een gestileerde, aangepaste focusindicator. WCAG 2.2 SC 2.4.11 vereist dat het gebied van de focusindicator minstens zo groot is als een 2 CSS-pixel dikke omtrek van de ongefocuste component, met een contrastverhouding van minimaal 3:1 tussen gefocuste en ongefocuste staten. Gebruik de pseudo-class :focus-visible in plaats van :focus om focusindicatoren alleen voor toetsenbordgebruikers te tonen, zonder de esthetiek van muisinteractie te beïnvloeden.

/* Verwijder standaard alleen om te vervangen door betere indicator */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Deze aanpak geeft je volledige visuele controle terwijl je WCAG-conform blijft. Zorg ervoor dat de focuskleur voldoende contrast heeft met zowel de achtergrond als de component zelf, vooral op dark-themed sites of boven afbeeldingen.

Beheer Focus bij Dynamische Interacties

Wanneer content dynamisch verandert — een modal openen, nieuwe content laden, een element verwijderen — moet je de focus programmatisch beheren. Bij het openen van een modal verplaats je de focus naar het eerste focusbare element erin. Bij het sluiten breng je de focus terug naar het triggerelement. Gebruik hiervoor de .focus()-methode van JavaScript. Om de focus correct binnen een modal te vangen, onderschep je Tab- en Shift+Tab-toetsgebeurtenissen en laat je de focus cyclen tussen het eerste en laatste focusbare element binnen de dialoog.

// Een modal openen: focus naar binnen verplaatsen
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Een modal sluiten: focus terug naar trigger
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Implementeer Skip Navigation Links

Toetsenbordgebruikers moeten op Tab drukken om bij elke paginalaad door elk interactief element vóór de hoofdcontent — headers, navigatiemenu’s, zoekbalken — te navigeren. Skiplinks zijn de oplossing: een visueel verborgen link helemaal bovenaan de pagina die zichtbaar wordt bij focus en gebruikers direct naar het hoofdcontentgebied brengt. Ze zijn een WCAG Level A-vereiste en een van de meest impactvolle quick wins die er zijn.

<!-- Plaats als eerste element in <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Doelanker op de hoofdcontentcontainer -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Toon skiplink alleen bij toetsenbordfocus */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Bouw Toegankelijke Navigatiemenu’s

Navigatiemenu’s met dropdownsubmenu’s vereisen zorgvuldige aandacht. Het juiste toetsenbordinteractiepatroon voor een navigatiemenu is: Tab beweegt tussen top-level items; Enter of Spatie opent een submenu; pijltjestoetsen navigeren binnen het submenu; en Escape sluit het submenu en brengt de focus terug naar de trigger. Gebruik ARIA-attributen om de status te communiceren. Menu’s die alleen openen bij hover, zonder toetsenbordtrigger, zijn ontoegankelijk en moeten worden aangepast.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Gebruik aria-expanded='false' en aria-expanded='true', via JavaScript omgeschakeld, om de open/dicht-status te communiceren. Gebruik aria-haspopup='true' om aan te geven dat het activeren van de knop een submenu opent. Zorg ervoor dat de Escape-toets het submenu sluit en de focus terugbrengt naar de knoptrigger.

Ga Correct om met tabindex

Er zijn drie betekenisvolle waarden voor tabindex en elk heeft een eigen doel. tabindex='0' voegt een niet-interactief element toe aan de natuurlijke tabvolgorde — gebruik dit wanneer je echt een normaal niet-focusbaar element (zoals een container van een custom widget) focusbaar moet maken. tabindex='-1' verwijdert een element uit de tabvolgorde maar maakt het mogelijk om er programmatisch focus op te zetten via .focus() — essentieel voor modaltargets en bestemmingen van skiplinks. Positieve tabindex-waarden (zoals tabindex='1' of tabindex='5') overschrijven de natuurlijke volgorde op manieren die bijna altijd meer problemen veroorzaken dan ze oplossen; vermijd ze volledig en corrigeer in plaats daarvan de DOM-volgorde.

ARIA: Een Krachtig Hulpmiddel, Geen Wondermiddel

Accessible Rich Internet Applications (ARIA)-attributen breiden de semantiek van HTML uit om ondersteunende technologieën te helpen custom componenten te begrijpen die niet door native HTML worden gedekt — tabs, accordeons, boomstructuren, carrousels, comboboxen. ARIA-attributen kunnen extra context bieden, maar ze moeten semantische HTML aanvullen — niet vervangen. Een veelvoorkomende en gevaarlijke fout is ARIA inzetten voordat is overwogen of een native HTML-element de taak niet gewoon kan vervullen.

De eerste regel van ARIA is: gebruik geen ARIA als een native HTML-element of -attribuut hetzelfde kan doen. De tweede regel: geen ARIA is beter dan slechte ARIA. Onjuiste ARIA-markup — bijvoorbeeld role='menu' toepassen zonder de juiste hiërarchie van role='menuitem'-kinderen, of aria-hidden='true' gebruiken op een element dat focus krijgt — kan toegankelijkheid actief schaden in plaats van helpen.

Wanneer ARIA echt nodig is, zijn de meest bruikbare attributen voor toetsenbordinteracties: aria-expanded om open/dicht-status te communiceren op uitklapbare elementen; aria-controls om een trigger te koppelen aan de content die het aanstuurt; aria-haspopup om aan te geven dat een knop een menu of dialoog opent; aria-modal='true' op dialoogelementen om aan te geven dat achtergrondcontent inert is; en aria-live-regio’s (polite voor statusberichten, assertive voor urgente waarschuwingen) om dynamische contentwijzigingen aan schermlezergebruikers aan te kondigen zonder de focus te verplaatsen.

Een subtiele maar belangrijke overweging: schermlezers zoals NVDA en JAWS gebruiken hun eigen sneltoetsen — bijvoorbeeld, H indrukken in NVDA verplaatst de gebruiker naar de volgende heading op de pagina. Ontwikkelaars moeten vermijden custom applicatiesneltoetsen te maken die conflicteren met deze commando’s van ondersteunende technologie.

Testen op Toetsenbordtoegankelijkheid

De meest effectieve test die je nu meteen kunt uitvoeren, vereist geen tools: trek de stekker van je muis eruit en navigeer je website uitsluitend met het toetsenbord. Druk op Tab om vooruit te gaan door interactieve elementen, Shift+Tab om terug te gaan, Enter om links en knoppen te activeren, Spatie om selectievakjes te toggelen en knoppen te activeren, Escape om modals en menu’s te sluiten en pijltjestoetsen om binnen componenten te navigeren. Vraag jezelf af: Kun je elk interactief element bereiken? Kun je altijd zien waar je bent? Kun je elke kritieke gebruikersflow afronden zonder vast te lopen?

Geautomatiseerde tools kunnen een betekenisvolle subset van problemen met toetsenbordtoegankelijkheid opsporen — met name ontbrekende labels, lege knoppen en sommige focusafhandelingsproblemen. Tools zoals axe DevTools, WAVE en Lighthouse zijn waardevolle eerste checks. Geautomatiseerde tools detecteren echter slechts ongeveer 40% van de WCAG-problemen. Focuszichtbaarheid, logische focusvolgorde en correcte ARIA-statusafhandeling vereisen allemaal handmatige menselijke beoordeling. Voor de meest grondige beoordeling combineer je geautomatiseerde scans met handmatig testen met alleen het toetsenbord in meerdere browsers, en neem je schermlezertests op met NVDA (Windows), JAWS (Windows) of VoiceOver (macOS/iOS).

Enkele specifieke scenario’s die je handmatig moet testen telkens wanneer je een nieuwe component of pagina uitbrengt: Kun je elke dropdown, modal en accordeon openen en sluiten met alleen Tab, Enter en Escape? Wanneer een modal sluit, keert de focus dan terug naar de trigger? Verschijnt de skip navigation link en werkt die bij de eerste Tab-toets? Zijn er punten waar de Tab-focus verdwijnt in een element zonder zichtbare indicator? Bedekken sticky headers of cookiebanners gefocuste elementen terwijl je door de pagina tabt?

Voor teams die componentbibliotheken bouwen, is de WAI-ARIA Authoring Practices Guide (APG) van W3C de definitieve referentie voor toetsenbordinteractiepatronen voor tientallen typen widgets — van accordeons en carrousels tot datepickers en boomstructuren. Elk patroon specificeert precies welke toetsen moeten worden ondersteund en wat het verwachte gedrag moet zijn.

Sticky Headers, Fixed Footers en Focusverhulling

Een van de praktisch meest relevante nieuwe vereisten in WCAG 2.2 is Succescriterium 2.4.11: Focus Not Obscured. Het pakt een probleem aan dat zo vaak voorkomt dat het het moderne web bijna definieert: sticky navigatiebalken, cookieconsentbanners, chatwidgets en fixed footers die bovenop pagina-inhoud liggen. Wanneer een toetsenbordgebruiker naar een element tabt dat achter een van deze vaste lagen is weggescrold, wordt het gefocuste element onzichtbaar — de gebruiker kan niet zien waarmee hij of zij interacteert.

De oplossing vereist samenwerking tussen CSS en JavaScript. Wanneer een element focus krijgt, moet de browser het naar een zichtbaar gebied scrollen. Maar een sticky header met position: fixed en een hoogte van bijvoorbeeld 80px betekent dat de bovenste 80px van de viewport permanent bezet zijn. CSS scroll padding kan dit compenseren:

html {
  /* Hoogte van je sticky header + een kleine buffer */
  scroll-padding-top: 96px;
}

Dit vertelt de browser de scroll-ankering met het opgegeven bedrag te compenseren, zodat wanneer hij automatisch een gefocust element in beeld brengt, hij rekening houdt met de vaste header. Je hebt mogelijk ook equivalente scroll-padding-bottom nodig als je een sticky footer hebt. Zorg er bij cookiebanners of overlays die verschijnen en verdwijnen voor dat ze z-index-waarden hebben die het gefocuste element niet bedekken, of pas scroll padding dynamisch aan wanneer de banner zichtbaar is.

Belangrijkste Punten

• Semantische HTML is je beste eerste stap. Native elementen zoals <button>, <a> en formuliercontrols zijn standaard toetsenbordtoegankelijk. Elke custom widget die je van divs bouwt, kost je toegankelijkheid die je vervolgens handmatig moet herbouwen met ARIA en JavaScript.
• Onderdruk nooit focusindicatoren zonder ze te vervangen. De globale regel outline: none is een van de meest schadelijke dingen die je in een stylesheet kunt zetten. Gebruik :focus-visible om een gestileerde, contrastrijke focusring te bieden die voldoet aan de minimale grootte- en contrastvereisten van WCAG 2.2.
• Beheer focus programmatisch bij elke dynamische interactie. Modals, drawers, toastmeldingen en dynamische contentwijzigingen vereisen allemaal expliciet focusbeheer — focus naar binnen verplaatsen en bij sluiten terugbrengen. Zonder dit raken toetsenbordgebruikers elke keer hun plek kwijt wanneer de UI verandert.
• Voeg bovenaan elke pagina een skip navigation link toe. Het kost minder dan 20 regels code en verbetert de ervaring drastisch voor toetsenbordgebruikers die anders bij elke paginalaad door je hele header en navigatie zouden moeten tabben.
• Test met je toetsenbord voordat je live gaat. Geautomatiseerde tools vangen slechts een fractie van de problemen met toetsenbordtoegankelijkheid. Een toetsenbord-only walkthrough van tien minuten door je belangrijkste gebruikersflows brengt echte blokkades aan het licht die geen enkele scanner zal vinden — en kan door elke ontwikkelaar in het team worden uitgevoerd zonder specialistische training.