Toegankelijkheid voor toetsenbord

Dat je een website met het toetsenbord kan bedienen is een van de belangrijkste aspecten van webtoegankelijkheid. Veel gebruikers met een motorische handicaps zijn namelijk afhankelijk van een toetsenbord. Sommige mensen hebben moeite met fijne motoriek. Anderen kunnen hun handen niet of nauwelijks gebruiken (denk bijvoorbeeld aan RSI), of hebben helemaal geen handen. Naast traditionele toetsenborden kunnen sommige gebruikers aangepaste toetsenborden gebruiken of andere hardware die de functionaliteit van een toetsenbord nabootst. Blinde gebruikers gebruiken doorgaans ook een toetsenbord, om zo hun screenreader te bedienen en websites te navigeren. Bij problemen is er een inbreuk op de Richtlijnen voor Toegankelijkheid van Webcontent (WCAG).

Gebruikers zonder handicap kunnen een toetsenbord gebruiken voor navigatie vanwege voorkeur of efficiëntie (👋 hoi powerusers en toetsenbordninja's!). Zij zullen mee profiteren als de toegankelijkheid voor en met het toetsenbord wordt verbeterd.

Mogelijke problemen

Er zijn vele manieren waarop een webpagina problemen kan opleveren voor gebruikers die voor navigatie afhankelijk zijn van een toetsenbord. Hieronder staan een paar van de meest voorkomende problemen die je tegen kan komen bij het testen van jouw project.

↑ Terug naar boven

Focusindicatoren

Een toetsenbordgebruiker gebruikt gewoonlijk de tab-toets om door interactieve elementen op een webpagina te navigeren - links, knoppen, velden voor het invoeren van tekst, enz. Wanneer naar een item wordt getabbed, heeft het toetsenbord "focus" en kan het worden geactiveerd of gemanipuleerd met het toetsenbord. Een ziende toetsenbordgebruiker moet een visuele indicator krijgen van het element dat op dat moment toetsenbordfocus heeft.

Meer uitleg over focus indicatoren en hoe problemen op te lossen.

↑ Terug naar boven

Lees- en tabvolgorde (ook wel focusvolgorde)

Als een toetsenbordgebruiker door de pagina navigeert, is de volgorde waarin items toetsenbordfocus krijgen belangrijk. De volgorde moet logisch en intuïtief zijn. Dit betekent over het algemeen dat deze de visuele stroom van de pagina volgt: van links naar rechts, van boven naar beneden. Voor de meeste pagina's betekent dit eerst de header, dan de hoofdnavigatie, dan items in de content (indien aanwezig) en ten slotte de footer. Deze volgorde (en ook de leesvolgorde voor schermlezers) wordt bepaald door de broncode van de webpagina.

Voor de beste resultaten:

• Structureer broncode zo dat de lees- en tabvolgorde correct is.
• Gebruik vervolgens, indien nodig, CSS om de visuele presentatie van de elementen op de pagina te regelen.
• Let vooral goed op bij het gebruik van moderne CSS-technieken als grid of flex. Rachel Andrew legt uit hoe flex en grid de tabvolgorde negatief kunnen beinvloeden. CSS Tricks heeft ook geschreven over herordenenen met grid en ook MDN Docs heeft het over grid en toegankelijkheid.
• Gebruik geen tabindex waarden van 1 of hoger om de volgorde te veranderen.

↑ Terug naar boven

Items die geen toetsenbordfocus mogen krijgen

Links, knoppen en formulierelementen zijn van nature toegankelijk voor gebruikers van het toetsenbord, en moeten dus waar mogelijk worden gebruikt voor interactiviteit. Elementen die niet interactief zijn voor gebruikers van een muis of aanraakschermen mogen geen toetsenbordfocus krijgen (zoals door het gebruik van tabindex). Niet-interactieve elementen via het toetsenbord bedienbaar maken zal verwarring veroorzaken.

↑ Terug naar boven

Ontoegankelijke custom widgets of componenten

Als een native HTML-element niet voldoende is, kan een op maat gemaakt widget of component nodig zijn. Dit wordt ook niet verboden door WCAG. Maar deze moeten nog steeds toegankelijk zijn voor gebruikers met een toetsenbord. Het kan nodig zijn om tabindex te gebruiken om ervoor te zorgen dat ze toetsenbordfocus kunnen krijgen. ARIA kan ook nodig zijn om ervoor te zorgen dat het component of de widget correct wordt gepresenteerd aan screenreaders. De ARIA Authoring Practices schetsen de noodzakelijke toetsenbordinteracties en ARIA-code die nodig zijn voor veel soorten zelfgemaakte componenten of widgets.

Om toegankelijk te worden gemaakt, moet het volgende gebeuren:

• De interactie wordt op een intuïtieve en voorspelbare manier gepresenteerd.
• JavaScript event handlers werken met een toetsenbord en een muis.
• Er wordt gebruik gemaakt van toetsen die bij het component of de widget verwacht worden.

↑ Terug naar boven

Teveel elementen

Ziende gebruikers met een muis zijn in staat een webpagina visueel te scannen en direct op een item te klikken. Toetsenbordgebruikers moeten de tab-toets (of andere navigatietoetsen) indrukken om door de interactieve elementen te navigeren. Tabben door heel veel interactieve elementen totdat je bent waar je wil zijn, kan bijzonder veeleisend zijn voor gebruikers met motorische beperkingen. Hoe meer items doorgewerkt moeten worden voordat een gebruiker bijvoorbeeld de hoofdininhoud bereikt, hoe lastiger.

Lange lijsten met links of andere interactieve items kunnen overweldigend zijn voor gebruikers die alleen een toetsenbord gebruiken. De volgende best practices kunnen navigatie met het toetsenbord vergemakkelijken:

• Zorg voor een skip link op de pagina om meteen naar de inhoud te kunnen gaan.
• Gebruik een goede kopstructuur.
• Gebruik landmarks.

↑ Terug naar boven

Tabindex

Het tabindex-attribuut heeft invloed op de toetsenbordfocus. Het heeft daardoor veel macht en je moet goed opletten dat je er geen problemen mee door creëert.

Lees meer over tabindex en hoe je dat correct moet toepassen.

↑ Terug naar boven

Accesskeys

Accesskeys zijn sneltoetsen. Zeker sneltoetsen die uit 1 cijfer of letter bestaan, kunnen problematisch zijn.

Ik vertel je alles over het correct toepassen van accesskeys.

↑ Terug naar boven

Testen met toetsenbord

Je moet met een toetsenbord de volgende interactieve elementen kunnen bedienen:

• links
• knoppen
• controls van formulieren (tekstvelden, keuzelijsten, radio buttons, checkboxen, …)
• dingen die getriggerd worden door :hover zoals tooltips
• widgets, bijv. een date picker

Je kunt je eigen project testen door de muis aan de kant te schuiven en enkel het toetsenbord te gebruiken. Bekijk ook mijn lijst van de te gebruiken toetsen op je toetsenbord en waar je bij testen op moet letten.

↑ Terug naar boven

Conclusie

Het heeft een grote impact als een website of web applicatie niet bedienbaar is met het toetsenbord. Het testen en controleren van toegankelijkheid voor en met toetsenbord kost tijd, maar eventuele grote hindernissen kunnen dan wel weggenomen worden. Als het op dit gebied goed zit, is je project al voor een groot deel toegankelijk. Veel succes!

↑ Terug naar boven

Credits

Deze pagina is grotendeels gebaseerd op een vertaling van WebAim’s pagina over toegankelijkheid met toetsenbord.

Bronnen

↑ Terug naar boven