Ga naar hoofdinhoud

WCAG-succescriterium 2.1.1 Toetsenbord

Niveau A

Pagina's kunnen bediend worden met een toetsenbord.

Veel mensen gebruiken een touchscreen of een muis. Websites zijn hier vaak op ingericht. Niet iedereen kan deze apparaten gebruiken. Een website moet daarom ook werken voor andere apparaten en technieken.

Denk hierbij aan apparaten zoals toetsenborden, maar ook technieken die werken als een toetsenbord. Als een website niet werkt met het toetsenbord, dan werkt het ook niet met deze technieken.

Uitleg

Alle interactieve elementen op een pagina moet je kunnen bereiken en bedienen met het toetsenbord. Dit zijn bijvoorbeeld knoppen (<button>), links (<a>) en invoervelden (<input>).

  • Je bereikt interactieve onderdelen op een pagina met tab en de combinatie shift+tab. tab navigeert je van het ene naar het andere interactieve onderdeel in een logische volgorde (WCAG-successcriterium 2.4.3 Focus volgorde). shift+tab doet hetzelfde, maar in omgekeerde volgorde.
  • Binnen een onderdeel zijn soms de pijltjestoetsen nodig. Denk hierbij aan groeperingen zoals radio-buttons, tabbladen en kalenders. Een groepering zoals een kalender is bereikbaar met tab. Losse dagen zijn daarna bereikbaar met pijltjestoetsen.
  • Het activeren of bedienen van elementen moet ook met het toetsenbord kunnen.
    • Een link is te activeren met return/enter.
    • Een knop is daarnaast ook te activeren met de spatiebalk.
    • Selecties binnen een onderdeel kunnen vaak met de spatiebalk.
    • Sommige elementen zoals sliders zijn te bedienen met pijltjestoetsen.
    • Een formulier kan soms ook verzonden worden met return/enter in plaats van een <button> te gebruiken. Dit heet implicit submission.
    • Soms zijn er nog andere manieren om het toetsenbord te gebruik. Denk hierbij aan acties annuleren met esc of navigeren met toetsen als home en end. Als er bij zelfgebouwde elemente twijfel is hoe die bediend moeten worden, vergelijk dan met pure HTML.

Op MacOS kunnen extra instellingen nodig zijn voor bediening met het toetsenbord:

Het toetsenbord zelf is een veel gebruikt hulpmiddel voor mensen met een beperking. Niet iedereen kan een muis of andere invoerapparaten gebruiken. Dit criterium is ook voor tal van apparaten die werken als een toetsenbord. Denk hierbij naast het toetsenbord aan een screenreader of een eenfunctieschakelaar. Screenreaders worden vooral gebruikt door mensen met een visuele beperking, maar ook door mensen met cognitieve beperkingen. Daarnaast zijn er tal van hulpmiddelen zoals de eenfunctieschakelaar die gebruikt worden door mensen met motorische beperkingen. Werkende toetsenboordbediening helpt mensen met beperkingen maar ook andere mensen. Denk hierbij aan zogenaamde power users en mensen regelmatige bezoekers die sneller werken met een toetsenbord.

Hoe te testen

Lees in de uitleg hoe een toetsenbord zou moeten werken.

  1. Vind alle alle onderdelen op een website waarmee je iets kan bedienen.
  2. Controleer of je deze onderdelen kan bereiken met je toetsenbord.
  3. Controleer of je deze onderdelen ook kan bedienen met je toetsenbord.

Deze tests moeten ook slagen als de website ingezoomd is. Er kunnen dan andere interactieve elementen aanwezig zijn.

Veelgemaakte fouten

Custom components

Onderdelen worden vaak zelf gebouwd. De mogelijkheden van een framework worden gebruikt om iets te bouwen wat HTML al biedt. Denk hierbij aan ongewone en creatieve onderdelen die bestaande componenten combineren, maar ook simpelere elementen zoals een <button> kunnen nagebouwd worden. Bij dit soort zelfbouw wordt toegankelijkheid niet altijd goed getest wordt. Gebruik waar mogelijk zogenaamde native HTML. Dit werkt in de basis goed, en is makkelijker te gebruiken, bouwen en onderhouden dan zelfbouw. Termen als onClick in de JavaScript-code kunnen duiden op problemen. Dit probleem is afhankelijk van code.

Volgorde in de code

Een uitklappend menu en andere overlappende onderdelen zoals chatvensters en cookiemeldingen zijn lastig voor het toetsenbord. Visueel worden ze vaak onderaan een pagina geplaatst. Voor een toetsenbord is het einde van de pagina niet snel te bereiken. De code van een uitklappend menu plaats je het liefst direct na de knop die het opent. Zo zit het voor de navigatie volgorde op een logische plek. De gebruiker opent iets, en met een opvolgende tab is het gefocust. Dit probleem is afhankelijk van code en design.

Dialoogvensters

Bij het openen van een dialoogvenster wordt de focus hier vaak niet naar geplaatst. Dit moet wel om het venster te kunnen bedienen. Welk onderdeel de focus krijgt hangt af van de inhoud van het venster. Dit wordt uitgelegd op de Engelstalige pagina Dialog (Modal) Pattern van de ARIA Authoring Practices Guide (APG). Als een dialoogvenster sluit moet de focus weer terug naar het element dat het opende. Dit probleem is afhankelijk van code.

Hover

Uitklappende menus, tooltips en soortgelijke elementen werken soms alleen bij een hover. Deze moeten ook werken met het toetsenbord. Als iets uitklapt, moet het geactiveerd kunnen worden met het toetsenbord. Daarnaast moet de inhoud ook te bereiken zijn met het toetsenbord. Extra hints of informatie zoals die in een tooltip kan soms ook via aria-describedby gecommuniceerd worden. Dit probleem is afhankelijk van code en UX.

Tabindex

Het attribuut tabindex geeft vaak problemen. Gebruik geen positieve tabindex. Voeg ook geen tabindex="0" toe aan elementen die niet interactief zijn, zoals paragrafen. Deze hoeven niet met het toetsenbord bereikt te worden. Hier zijn andere technieken voor. Dit probleem is afhankelijk van code.

Ingewikkelde onderdelen

Kaarten en visualizaties zijn vaak slecht bereikbaar voor het toetsenbord. Ze zijn lastig toegankelijk te maken. Als er geen andere oplossing mogelijk is kan er een alternatief geboden worden. Zo kan een kaart met markers en adressen aangevuld worden met een lijst met dezelfde adressen. Let wel op dat het alternatief een volwaardige oplossing is. Dit probleem is afhankelijk van content.

Cookiemeldingen

Een cookiemelding is vaak niet of moeilijk te bereiken en bedienen met een toetsenbord. De focus staat op het achterliggende document en niet op de melding. De melding staat aan het einde van de code van een pagina, en is daarom moeilijk te bereiken. Idealiter is de melding modal als een dialoogvenster. Zet de focus op de melding en zorg dat de content in de achtergrond niet te bereiken is. Dit probleem is afhankelijk van code.

Feedback- en chatknoppen

Net als cookiemeldingen staan feedback- en chatknoppen vaak aan het eind van de code van een pagina. Ze zijn daarmee ook moeilijk te bereiken. Door deze knoppen in de pagina te verwerken zullen ze minder snel gemist worden. Dit kan als alternatief. De bestaande knoppen kunnen blijven bestaan. Dit probleem is afhankelijk van design en content.

Gerelateerde NL Design System-richtlijnen en WCAG criteria

Binnen NL Design System is meer geschreven over dit criterium en onderwerpen die ermee te maken hebben. Door je te verdiepen in deze context kun je mogelijk meerdere problemen tegelijk oplossen, en de gebruikerservaring breder verbeteren.

NL Design System-richtlijnen

WCAG criteria

Bronnen

Wat is verplicht?

De richtlijnen zijn geen wettelijke verplichting of vervanging voor WCAG. Ze zijn een praktische uitleg met voorbeelden die helpen bij het toegankelijk inzetten van NL Design System. Meer informatie of de wettelijke verplichting staat op de pagina wat is verplicht van DigiToegankelijk.

Aanvullingen of opmerkingen?

Deel je mening op GitHub of bezoek onze actieve community op Slack.