Ga naar hoofdinhoud

WCAG-succescriterium 2.1.1 Toetsenbord

Niveau A

Alle functionaliteit is te gebruiken met een toetsenbord.

Als een pagina niet werkt voor een toetsenbord, dan werkt het ook niet voor technieken die werken als een toetsenbord. Websites zijn vaak ingericht op het gebruik van een touchscreen of een muis. Deze apparaten worden veel gebruikt, maar niet iedereen kan deze apparaten gebruiken. Een website moet daarom ook werken voor andere apparaten en technieken.

Uitleg

Alle interactieve elementen op een pagina moet je kunnen bereiken en bedienen met het toetsenbord. Dit zijn bijvoorbeeld buttons, links, en invoervelden. In HTML zijn dit <button>, <a> en <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.
  • Bij onderdelen met eigen subonderdeel zijn pijltjestoetsen nodig. Voorbeelden zijn radio-buttons, sliders, 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 enter.
    • Een button is te activeren met enter en de spatiebalk.
    • Selecties binnen een onderdeel maakt men met de spatiebalk.
    • Een formulier kan soms ook verzonden worden met enter in plaats van een <button> te gebruiken. Dit heet implicit submission.
    • Er zijn andere manieren om het toetsenbord te gebruiken. Acties kun je annuleren met esc en je kan navigeren met toetsen als home en end. Als er bij zelfgebouwde elemente twijfel is hoe die bediend moeten worden, vergelijk dan met pure HTML.

Voordelen

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. Dit zijn bijvoorbeeld 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. Dit zijn bijvoorbeeld 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 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.

Als je op MacOS test en het werkt niet zoals verwacht, dan kan het zijn dat instellingen niet goed staan. Er zijn instellingen op zowel system- als browserniveau die goed moeten staan. Lees hoe dit moet op de Engelstalige pagina How to activate keyboard navigation on MacOS.

Veelgemaakte fouten

Custom components zijn niet gebouwd voor het toetsenbord

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.

Een element met een role is niet meteen bruikbaar. De volgende foute code kan gebruikt zijn om een button te maken:

<!-- Foute code, niet gebruiken  ->
<div role="button">Verstuur</div>

De role geeft aan dat dit element zich wil gedragen als een button. Dit maakt het echter nog geen bruikbare button. Pas als het element ook te bereiken en te bedienen is, voldoet het aan aan dit criterium. De toevoeging van een role is wel essentieel voor WCAG-succescriterium 4.1.2 Naam, rol, waarde maar maakt de button niet toegankelijk voor het toetsenbord.

Dit probleem is afhankelijk van code.

De volgorde in de code komt niet overeen met wat er te zien is

Een uitklappend menu en andere overlappende onderdelen zoals chatvensters zijn lastig voor het toetsenbord. Ze zien er uit alsof ze bij een button horen. In de code 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 button 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.

Dialoogvensters krijgen geen focus

Bij het openen van een dialoogvenster wordt de focus hier vaak niet naar verplaatst. 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.

Functies werken alleen met 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 design.

Tabindex wordt verkeerd toegepast

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.

Kaarten en andere datavisualisaties zijn niet te bedienen

Kaarten en andere datavisualisaties zijn vaak slecht bereikbaar voor het toetsenbord. Deze ingewikkelde onderdelen 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 krijgen geen focus

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. Door de grote afstand in de code moet de gebruiker onpraktisch vaak tab gebruiken. Daarnaast kan een gebruiker niet doorhebben dat de melding er uberhaupt is, of bereikbaar is. 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 chatbuttons zijn onbereikbaar

Net als cookiemeldingen staan feedback- en chatbuttons vaak aan het eind van de code van een pagina. Ze zijn daarmee ook moeilijk te bereiken. De buttons kunnen ook verwerkt worden in de pagina. Plaats ze op een plek waar feedback of ondersteuning gewenst is. Hier zullen ze minder snel gemist worden. Dit kan ook naast de bestaande buttons.

Dit probleem is afhankelijk van design en content.

Op het oog uitgeschakelde elementen zijn niet uitgeschakeld

Een element kan op het oog uitgeschakeld zijn, maar met het toetsenbord nog werken. Het element ziet er bijvoorbeeld anders uit en/of de bediening door muis en aanraking is uitgeschakeld. Als het niet voor iedereen uitgeschakeld is, kan dit zorgen voor onverwacht gedrag en foutmeldingen. Gebruik native HTML attribuut disabled om een element als een <button> uit te schakelen: 

<button type="submit" disabled>Verstuur</button>

De vormgeving in CSS kan inhaken op deze code:

button:disabled {
  /* voeg hier je styling toe */
}

Dit attribuut werkt niet op alle interactieve elementen. Een <a> kan niet op deze manier uitgeschakeld worden. Voor uitgeschakelde links moet men geen <a> gebruiken. Het attribuut werkt soms ook op niet-interactieve elementen. De inhoud van een <fieldset> of <optgroep> kan uitgeschakeld worden door disabled hier op toe te passen.

Dit probleem is afhankelijk van code en design.

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. Met deze context kun je nog praktischer met dit criterium aan de slag. Je kan meerdere problemen tegelijk oplossen, en de gebruikerservaring breder verbeteren.

NL Design System-richtlijnen

WCAG richtlijnen

Deze WCAG richtlijnen gaan ook over het gebruik van een toetsenbord. Het kan praktisch zijn om deze tegelijk te bekijken en te beoordelen.

Bronnen

Officiële WCAG criteria

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.