Blog / Websitekwaliteit
Website toegankelijkheid testen met je toetsenbord: praktische checklist
Controleer stap voor stap of je website zonder muis werkt. Test navigatie, focus, formulieren en menu’s met alleen je toetsenbord.
· De Sitefabriek
Kun je je website volledig gebruiken zonder een muis? Met een korte toetsenbordcontrole ontdek je snel of bezoekers links kunnen volgen, formulieren invullen en menu’s bedienen zonder vast te lopen. Je hebt hiervoor geen extra programma nodig: open je website in de browser en leg je muis even opzij.
Deze eerste controle is nuttig, maar bewijst niet dat een website volledig toegankelijk is of aan alle WCAG-succescriteria voldoet. W3C beschrijft zulke snelle checks ook als een eerste indruk: voor een volledige beoordeling zijn aanvullende controles nodig. (W3C WAI: Easy Checks — A First Review of Web Accessibility)
Waarom je website met een toetsenbord testen?
Sommige bezoekers gebruiken geen muis. Ze navigeren met een toetsenbord, een schakelaar of hulptechnologie die toetsenbordacties nabootst. Als een bediening alleen reageert op klikken of aanwijzen, kan een belangrijke taak voor hen onbereikbaar zijn.
WCAG 2.2 beschrijft onder meer dat functionaliteit met een toetsenbord bedienbaar moet zijn, zonder dat iemand specifieke timing voor losse toetsaanslagen nodig heeft. Dat uitgangspunt geldt voor de volledige handeling: een product kiezen, informatie invullen en een formulier verzenden moet als geheel lukken. (W3C WAI: Keyboard Accessible)
Een eenvoudige proef gebruikt vooral deze toetsen:
- Tab gaat doorgaans naar het volgende interactieve element.
- Shift + Tab gaat terug.
- Enter opent meestal een link of activeert een knop.
- Spatie activeert vaak een knop of selectievakje; in een tekstveld kan spatie gewoon een teken invoeren.
- Pijltoetsen bedienen onder meer keuzelijsten en sommige samengestelde bedieningselementen.
- Escape sluit veel dialoogvensters of menu’s, als die functie daar is voorzien.
De precieze bediening hangt soms af van het soort element en de browser. Let daarom vooral op de vraag: kan iemand de functie vinden, begrijpen, gebruiken en daarna weer verlaten?
Zo voer je de eerste controle uit
Kies een belangrijke pagina en begin helemaal bovenaan. Gebruik geen muis of trackpad tijdens de controle. Probeer vervolgens de belangrijkste route uit die een bezoeker op die pagina kan volgen, zoals navigeren naar een aanbod, een aanvraagformulier invullen of een accountmenu openen.
1. Volg de focus vanaf het begin
Druk één keer op Tab. Je browser kan de focus bijvoorbeeld op de adresbalk zetten; druk dan nogmaals op Tab om de pagina te bereiken. Kijk bij iedere stap naar het scherm en noteer welk element de focus krijgt.
Controleer of de volgorde logisch is. De focus hoort niet onverwacht van de header naar een verborgen element en dan naar het midden van de pagina te springen. De volgorde hoeft niet exact de visuele layout te kopiëren, maar moet betekenis en bediening behouden. Dat is het doel van WCAG-criterium 2.4.3 Focus Order. (W3C WAI: Focus Order)
2. Gebruik elk onderdeel zonder muis
Doorloop de navigatie, links, knoppen, tabs, accordions en formulieren. Een zichtbare bediening die je met de muis kunt gebruiken, moet ook via een toetsenbordroute bedienbaar zijn. Let bijvoorbeeld op een menu dat pas verschijnt wanneer je ergens overheen beweegt, of een knop die alleen op een klikhandler reageert.
Gebruik Enter of Spatie waar dat past en probeer alle zichtbare opties te bereiken. Een gewone tekstlink navigeert naar een andere pagina; een knop voert meestal een actie uit op de huidige pagina. Als iets eruitziet als een bediening maar niet met het toetsenbord reageert, noteer dan de pagina, de bediening en de toets die je gebruikte.
3. Controleer of je steeds ziet waar je bent
De actieve focus moet zichtbaar blijven. Bij links, knoppen en velden hoort een duidelijke visuele aanduiding te tonen welk element op dit moment toetsenbordacties ontvangt. Een browserstandaard kan daarvoor volstaan; als de site die aanduiding met CSS verbergt, maak dan een zichtbare focusstijl.
W3C koppelt zichtbare focus aan het kunnen bepalen welk bedieningselement toetsenbordacties ontvangt. Een subtiele verandering die op de achtergrond wegvalt kan in de praktijk moeilijk te zien zijn. Controleer de focus daarom op lichte én donkere onderdelen van de interface. (W3C WAI: Focus Visible)
4. Test menu’s, pop-ups en formulieren
Open met het toetsenbord elk onderdeel dat iets toont of verbergt. Controleer dat je naar de inhoud kunt gaan, er weer uit kunt komen en begrijpt wat er is gebeurd. Bij een dialoogvenster kan de focus bijvoorbeeld naar het venster verplaatsen; bij sluiten hoort de bediening verder te gaan vanaf een begrijpelijke plek.
Vul een formulier in zonder de muis. Beweeg tussen de velden, kies opties, verstuur het formulier en bekijk hoe fouten worden gemeld. Zie je de foutmelding én kun je naar het bijbehorende veld gaan? Kun je de ingevoerde waarden nog aanpassen? Onze aparte gids over een websiteformulier testen vóór lancering behandelt labels, validatie en terugkoppeling uitgebreider.
Let ook op toetsenbordvallen: situaties waarin je met Tab of Shift + Tab een onderdeel binnenkomt, maar er niet meer uit raakt. WCAG heeft hiervoor een afzonderlijk criterium, No Keyboard Trap. Als je meer toetsen nodig hebt om weg te komen dan de gebruikelijke navigatietoetsen, moet de pagina uitleggen hoe je dat doet. (W3C WAI: No Keyboard Trap)
5. Kijk of de focus in beeld blijft
Gebruik je een vaste header, cookiemelding, chatvenster of sticky footer? Zulke lagen kunnen een gefocust element bedekken terwijl je door de pagina navigeert. Scroll verder en controleer of je het huidige element nog kunt zien.
WCAG 2.2-criterium 2.4.11 stelt op niveau AA dat een element met toetsenbordfocus niet volledig verborgen mag zijn door inhoud die de website zelf heeft geplaatst. Een test met de toetsenbordfocus maakt dit probleem vaak snel zichtbaar. (W3C WAI: Focus Not Obscured (Minimum))
Checklist: wat schrijf je op?
Test niet alleen de homepage. Kies minstens één belangrijke route die bezoekers echt moeten kunnen afronden, zoals een dienst bekijken of een contactaanvraag versturen. Gebruik deze lijst om bevindingen concreet te noteren:
- ☐ Ik kan vanaf het begin van de pagina met Tab alle belangrijke bedieningselementen bereiken.
- ☐ De focusvolgorde volgt een begrijpelijke route door navigatie en inhoud.
- ☐ Ik zie bij elk gefocust element duidelijk waar de focus staat.
- ☐ Links, knoppen, menu’s en formulierbedieningen werken zonder muis.
- ☐ Ik kan geopende menu’s of vensters weer verlaten met het toetsenbord.
- ☐ Een formulier is volledig invulbaar en meldt fouten op een begrijpelijke manier.
- ☐ Geen melding, vaste balk of venster verbergt het element dat focus heeft.
- ☐ Ik kan een complete belangrijke taak afronden zonder de muis te gebruiken.
Noteer per probleem de URL, de naam of omschrijving van het element, de toets die je gebruikte en wat je verwachtte. Bijvoorbeeld: “Op /contact bereikt Tab de knop ‘Verzenden’ niet; ik verwacht dat de knop na het laatste veld focus krijgt.” Zo kan een ontwikkelaar het probleem terugvinden en opnieuw controleren na een aanpassing.
Veelvoorkomende problemen en wat je ermee doet
Je ziet geen focusstijl. Controleer of een algemene CSS-regel zoals outline: none de browserstijl verwijdert. Voeg een goed zichtbare stijl toe voor :focus-visible en controleer die op verschillende achtergronden. W3C noemt :focus-visible als een mogelijke techniek, geen verplichte implementatie voor iedere site.
Een bediening reageert alleen op klikken. Kijk of de functie met een echt HTML-element is gemaakt. Een link hoort doorgaans een link te zijn en een actieknop een knop. Een klikbare div krijgt niet vanzelf dezelfde toetsenbordbediening als een native knop.
De volgorde slaat elementen over of springt vreemd. Controleer verborgen elementen, aangepaste tabindex-waarden en de volgorde van elementen in de pagina. Een hoge positieve tabindex kan een eigen volgorde maken die niet overeenkomt met de inhoud.
De focus verdwijnt achter een vaste balk. Pas de ruimte rond het scrollgebied of de positie van de balk aan en herhaal de controle. De gebruiker moet het element met focus kunnen blijven vinden.
Werk telkens aan één probleem en herhaal daarna dezelfde route. Gebruik ook de checklist om je website op mobiel te testen: toetsenbordbediening en mobiel gedrag zijn verschillende controles die elkaar aanvullen.
Wat deze controle wel en niet vertelt
Een korte toetsenbordproef is een goede eerste stap. Je ontdekt ermee of bediening ontbreekt, de focus onzichtbaar is of een essentiële route vastloopt. Het is geen volledige toegankelijkheidsaudit: toetsenbordbediening is maar één onderdeel van toegankelijkheid. Denk bijvoorbeeld ook aan kleurcontrast, kopstructuur, alternatieve teksten, zoom, formuliertaal en testen met hulptechnologie.
Gebruik de uitkomst dus als een concrete lijst met verbeteringen, niet als bewijs dat een website volledig voldoet aan WCAG. W3C waarschuwt bij zijn eigen snelle eerste checks dat een pagina een paar controles kan doorstaan en toch belangrijke barrières bevatten. (W3C WAI: Easy Checks)
Wil je een wijziging met Claude Code laten onderzoeken? Geef eerst de URL of projectcontext en vraag om de betrokken onderdelen en risico’s te benoemen. Laat daarna één concreet probleem oplossen en test dezelfde toetsenbordroute opnieuw. De gratis briefing voor Claude Code helpt je om de gewenste wijziging en controleafspraken duidelijk te maken.