Ga naar hoofdinhoud

WCAG

WCAG-succescriterium 2.1.1 Toetsenbord

Niveau A

In het kort

Doel
Elke actie is uit te voeren met een toetsenbord.
Wat te doen

Acties die je kunt uitvoeren met een aanwijzer kunnen ook met een toetsenbord.

Waarom het belangrijk is

Veel mensen zijn afhankelijk van bediening met het toetsenbord, onder andere mensen die blind zijn of een beperkte mobiliteit hebben.

Uitleg

Elke actie is uit te voeren met een toetsenbord.

Het toetsenbord is een veel gebruikt hulpmiddel voor mensen met een beperking. Niet iedereen kan een muis of een ander apparaat met aanwijzer gebruiken. Dit criterium is voor tal van hulpmiddelen die zich gedragen als een toetsenbord. Denk hierbij naast het toetsenbord aan een screenreader of een eenfunctieschakelaar.

Hoe het hoort te werken

Het is relatief laagdrempelig om verbeteringen te vinden voor dit criterium; een computer met toetsenbord volstaat. Dit zorgt ervoor dat velen een bijdrage kunnen leveren aan het voldoen aan dit criterium.

  • De interactieve onderdelen op een pagina moet je kunnen bereiken met tab en de combinatie shift+tab. tab navigeert je van het ene naar het andere interactieve element 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 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 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 twijfel is bij zelfgebouwde elementen, vergelijk dan met pure HTML.

Op MacOS kunnen extra instellingen nodig zijn:

Hoe te testen

  1. Vind alle plekken op een website waar je iets kan doen.
  2. Controleer of je het met een toetsenbord kan doen.

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

Tips

Semantische HTML
Gebruik zo veel mogelijk HTML-elementen in plaats van zelfgebouwde onderdelen. Zelfgebouwde onderdelen houden vaak geen rekening met bediening door een toetsenbord terwijl HTML standaard goed werkt met een toetsenbord. Een niet-interactief element dat klikbaar is gemaakt met JavaScript zal standaard niet werken met een toetsenbord. Een element dat van zichzelf interactief is (<button>, <link>, etc) werkt wel.
Gerelateerde successcriteria

Als je test voor bediening met het toetsenbord, test dan meteen gerelateerde successcriteria zoals:

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 vaak erg onhandig. 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.
Dialoogvensters
Bij het openen van een dialoogvenster moet de focus hierop geplaatst worden. 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.
Hover
Elementen die reageren op een hover moeten ook werken met het toetsenbord. Denk hierbij bijvoorbeeld aan tooltips en uitklappende menus.
Tabindex
Gebruik geen positieve tabindex. Voeg ook geen tabindex="0" toe aan elementen die niet interactief zijn. Als een element wel interactief moet zijn, voeg ook een naam toe voor WCAG-succescriterium 4.1.2 Naam, rol, waarde.
Ingewikkelde onderdelen
Kaarten en visualizaties zijn soms erg lastig toegankelijk te maken voor een toetsenbord. 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.

Gerelateerde NL Design System-richtlijnen

Gebruikersonderzoek

Heb je gebruikersonderzoek gedaan dat betrekking heeft op dit succescriterium en wil je dit delen? Kijk eens bij Gebruikersonderzoeken delen op gebruikersonderzoeken.nl.

Bronnen

W3C referenties

Belangrijk: De richtlijnen van NL Design System zijn geen wettelijke verplichting

De richtlijnen van NL Design System zijn niet wettelijk verplicht en zijn geen vervanging voor de wettelijk geldende WCAG 2.1 specificatie.

Ons doel is om praktische uitleg en voorbeelden te geven die helpen bij het toegankelijk inzetten van de NL Design System componenten, patronen en richtlijnen. We doen dat op basis van een interpretatie van de nieuwe WCAG 2.2 specificatie.

Weten waar je volgens de wet aan moet voldoen? Ga dan naar wat is verplicht van DigiToegankelijk.

Help richtlijn verbeteren

Deze pagina's over WCAG worden onderhouden door NL Design System. Heb je aanvullingen of opmerkingen? Deel je mening op GitHub.