Ga naar hoofdinhoud
Interactie & Toetsenbord

Interactie en toetsenbord binnen Accessibility & Design Systems

Voor veel gebruikers is de muis geen vanzelfsprekend of zelfs geen mogelijk invoermiddel. Toetsenbordtoegankelijkheid en voorspelbare interactie zijn daarom geen technische details, maar fundamentele voorwaarden voor bruikbare digitale dienstverlening.

Deze pagina beschrijft hoe interactie-ontwerp en focusgedrag bepalen of mensen zelfstandig kunnen navigeren, welke eisen volgen uit WCAG 2.2 en EN 301 549, en hoe je dit borgt in componenten, flows en productteams.

Waarom toetsenbordtoegankelijkheid cruciaal is

Toetsenbordgebruikers zijn onder andere:

  • Mensen met motorische beperkingen
  • Mensen die screenreaders gebruiken
  • Gebruikers met tremor of beperkte precisie
  • Power users die sneller werken zonder muis

Als een interface niet goed met het toetsenbord te bedienen is:

  • wordt navigatie onmogelijk
  • raken gebruikers gedesoriënteerd
  • kunnen processen niet worden afgerond

Toetsenbordtoegankelijkheid is daarmee een harde randvoorwaarde voor inclusieve dienstverlening.

Relevante WCAG-criteria

Interactie en focus raken meerdere kerncriteria:

2.1.1
Keyboard – alle functies moeten met toetsenbord te bedienen zijn
2.1.2
No Keyboard Trap – focus mag nergens vast komen te zitten
2.4.3
Focus Order – logische en voorspelbare tabvolgorde
2.4.7
Focus Visible – focus moet zichtbaar zijn
3.2.1
On Focus – geen onverwachte contextwissels bij focus
4.1.2
Name, Role, Value – componenten moeten correct worden aangekondigd

Binnen overheidscontext geldt dit verplicht via EN 301 549.

Tabvolgorde: volgt de interface, niet het grid

Wat vaak misgaat

  • Visuele layout via CSS die afwijkt van DOM-volgorde
  • Interactieve elementen buiten logische volgorde
  • Focus die springt tussen kolommen

Voor toetsenbord- en screenreadergebruikers voelt de pagina dan chaotisch aan.

Best practice
  • DOM-volgorde volgt visuele volgorde
  • Geen positieve tabindex-waarden
  • Alleen focusbare elementen in de tabvolgorde

Navigatie moet voorspelbaar en consistent zijn.

Focusindicatoren: essentieel voor oriëntatie

Zonder zichtbare focus weet een gebruiker niet waar hij zich bevindt of welk element actief is.

Veelvoorkomende ontwerpfouten
  • outline: none
  • Focus alleen via kleurverandering
  • Focus die verdwijnt op donkere achtergronden
Toegankelijke focus
  • Duidelijke contrastrijke rand of achtergrond
  • Zichtbaar in alle thema's en states
  • Consistent over componenten heen

Focus is geen visuele bijzaak, maar navigatie-informatie.

Dynamische content: wanneer de pagina verandert

In moderne webapplicaties:

Verschijnen meldingen Openen panels Worden validatiefouten getoond

Zonder goed focusbeheer merkt de gebruiker niets van de wijziging en blijft focus op de oude positie.

Wat WCAG verwacht
  • Focus verplaatsen naar relevante nieuwe content
  • Veranderingen aankondigen via ARIA live-regio's waar nodig

Zonder dit is feedback functioneel onzichtbaar.

Modals, dialogs en overlays

Modals zijn berucht om toegankelijkheidsproblemen.

Veelgemaakte fouten

  • Focus blijft achter op pagina
  • Tabben verlaat de modal
  • Sluitknop niet bereikbaar
Toegankelijke modal vereist
  • Focus verplaatst naar de modal bij openen
  • Focus blijft binnen de modal (focus trap)
  • Focus keert terug naar trigger na sluiten
  • Dialoog wordt correct aangekondigd

Zonder deze stappen is een modal onbruikbaar voor toetsenbordgebruikers.

Custom componenten: grootste bron van fouten

Dropdowns, tabs, sliders en autocomplete-velden worden vaak zelf gebouwd, visueel goed maar technisch ontoegankelijk.

Typische problemen

  • Niet bedienbaar met pijltjestoetsen
  • Verkeerde ARIA-rollen
  • Geen aankondiging van status
Richtlijn
  • Gebruik native HTML waar mogelijk
  • Volg WAI-ARIA authoring practices
  • Test altijd met toetsenbord én screenreader

Custom UI vraagt extra discipline.

Interactie zonder verrassing

3.2.1
On Focus – bij focus mag geen onverwachte actie plaatsvinden

Bij focus mag geen:

  • Automatische submit plaatsvinden
  • Nieuwe pagina openen
  • Contextwissel starten
Praktisch
  • Navigatie pas na expliciete actie
  • Geen onchange-redirects zonder waarschuwing

Voorspelbaarheid is essentieel voor vertrouwen.

Toetsenbordtesten: onmisbaar in acceptatie

Veel toegankelijkheidsproblemen worden zichtbaar door simpelweg de muis los te leggen en alleen met tab, shift+tab en enter te werken.

Wat teams zouden moeten testen
  • Kun je elk onderdeel bereiken?
  • Kun je alles bedienen?
  • Weet je steeds waar je bent?

Dit hoort thuis in:

Acceptatiecriteria
Definition of Done

Niet alleen in audits achteraf.

Interactie in design systems: structurele borging

Als componenten al niet goed zijn, worden fouten massaal herhaald en kost herstel extreem veel tijd.

In toegankelijke componenten zit

Correct focusgedrag
Toetsenbordinteractie
Juiste semantiek
Visuele focus

Design, development en QA moeten hier samen verantwoordelijk voor zijn.

Wat dit betekent voor overheidsorganisaties

Voor publieke digitale diensten geldt:

  • Iedereen moet zelfstandig kunnen navigeren
  • Ondersteuning via balie mag geen vereiste zijn
  • Toegankelijkheid is een wettelijk én maatschappelijk criterium

Daarom moet interactie-toegankelijkheid:

Onderdeel zijn van UX-ontwerp
Meegenomen in technische keuzes
Structureel getest worden

Van compliance naar gebruikskwaliteit

Sterke teams:

  • Ontwerpen flows met focus in gedachten
  • Testen iteratief
  • Gebruiken bewezen patronen
  • Documenteren interactierichtlijnen

Zo wordt toegankelijkheid onderdeel van normaal productwerk.

Hulp nodig bij interactie-ontwerp in jullie portalen?

Interactieproblemen zijn vaak het resultaat van kleine ontwerpbeslissingen met grote gevolgen. Ik help overheidsorganisaties zodat digitale dienstverlening voor iedereen zelfstandig bruikbaar blijft.

  • UX-review van interactiepatronen
  • Toetsing van componentbibliotheken
  • Meedenken in ontwerp en refinement
  • Borging van WCAG in deliveryprocessen