WCAG 2.5.6: Gelijktijdige invoermechanismen

Wat Deze Regel Betekent

\n

WCAG 2.5.6 — Gelijktijdige invoermechanismen is een succescriterium op niveau AAA onder WCAG 2.2. De kernvereiste is eenvoudig: webcontent mag het vermogen van de gebruiker om meerdere invoermechanismen gelijktijdig of uitwisselbaar te gebruiken niet beperken of verstoren. In praktische termen betekent dit dat een webpagina of applicatie niet programmatisch mag detecteren welk invoerapparaat de gebruiker op dat moment gebruikt en de gebruiker vervolgens mag vastzetten in die ene modaliteit, waardoor de toegang tot andere beschikbare invoermethoden wordt ontzegd.

\n

Moderne apparaten ondersteunen een rijke variëteit aan invoermechanismen: fysieke toetsenborden, muizen en trackpads, touchscreens, stylussen, schakelbediening, spraakinput, oogtracking en meer. Veel gebruikers vertrouwen tegelijkertijd op meer dan één van deze mechanismen — bijvoorbeeld een laptopgebruiker met een touchscreen die soepel wisselt tussen het touchpad en de vinger-touchinterface. Een power user kan een formulier met het toetsenbord doorlopen terwijl hij een muis gebruikt om te scrollen. Iemand met een motorische beperking kan een combinatie van een hoofdaanwijzer en een schakelapparaat gebruiken. Het criterium beschermt al deze workflows.

\n

Een fout treedt op wanneer een website JavaScript gebruikt om het type invoer te detecteren en vervolgens functionaliteit voor andere invoertypen verwijdert of uitschakelt. Als een site bijvoorbeeld een touch-gebeurtenis detecteert en vervolgens toetsenbordfocus-indicatoren verwijdert of toetsenbordnavigatie uitschakelt, is dat een directe schending. Evenzo vormen het blokkeren van aanwijzerinvoer na het detecteren van toetsenbordgebruik, of het gebruik van platform-API’s om invoer kunstmatig te beperken tot één modaliteit, allemaal fouten.

\n

Een goede implementatie is aanwezig wanneer gebruikers op elk moment tijdens hun interactie gebruik kunnen maken van alle beschikbare invoermechanismen. De content moet correct reageren op welk invoermechanisme de gebruiker op een bepaald moment ook kiest, zonder dat een herladen van de pagina, een moduswissel of een extra gebruikersactie nodig is om een invoertype opnieuw in te schakelen.

\n

Het criterium bevat één officiële uitzondering zoals gedefinieerd in WCAG: de beperking is toegestaan wanneer dit essentieel is — wat betekent dat een specifieke invoermodaliteit intrinsiek vereist is. Een klassiek voorbeeld is een handschriftherkenningsapplicatie waarbij touch- of stylus-invoer juist de kern van de functionaliteit vormt. Een ander voorbeeld kan een veld voor digitale handtekening zijn dat een specifieke aanwijzerinvoer vereist. Zelfs in deze gevallen moet de uitzondering eng worden geïnterpreteerd en moet de auteur waar mogelijk alternatieve manieren bieden om de taak te voltooien.

\n

Het is belangrijk op te merken dat dit criterium auteurs niet verplicht om ondersteuning toe te voegen voor invoermechanismen die het apparaat niet heeft. Het regelt beperkingen die worden opgelegd aan mechanismen die het apparaat en het platform al ondersteunen. Als een apparaat geen touchscreen heeft, valt er niets te beperken.

\n\n

Waarom Het Belangrijk Is

\n

De vrijheid om gelijktijdige of uitwisselbare invoermechanismen te gebruiken is geen gemaksfunctie — het is een cruciale toegankelijkheidsvereiste die direct verschillende specifieke groepen gebruikers raakt.

\n

Gebruikers met motorische beperkingen vertrouwen vaak op ondersteunende technologie die meerdere invoermechanismen combineert. Iemand met beperkte handmobiliteit kan een sip-and-puff-schakelapparaat gebruiken naast een schermtoetsenbord. Iemand met een tremor kan beginnen met het navigeren van een pagina via het toetsenbord, maar overschakelen naar een muis- of touchinterface wanneer een toetsenbordsnelkoppeling faalt. Als een website één invoertype detecteert en andere uitschakelt, kunnen deze gebruikers volledig worden buitengesloten van content of functionaliteit.

\n

Gebruikers met cognitieve of leerstoornissen profiteren vaak van de mogelijkheid om de invoermethode te kiezen die voor een bepaalde taak het meest comfortabel of natuurlijk aanvoelt. Het afdwingen van één enkele modaliteit neemt die keuze weg en kan onnodige cognitieve belasting introduceren, vooral wanneer een gebruiker niet bedreven is in de primaire invoermethode van het apparaat.

\n

Oudere volwassenen, die mogelijk leeftijdsgebonden motorische uitdagingen hebben, gebruiken in toenemende mate apparaten die zowel touch- als toetsenbordinvoer ondersteunen. De mogelijkheid om tussen deze mechanismen te wisselen naarmate de fijne motoriek gedurende de dag fluctueert, is belangrijk voor langdurig zelfstandig gebruik van het web.

\n

Power users en multimodale apparaatgebruikers — zoals Surface Pro- of iPad Pro-gebruikers — gebruiken regelmatig een toetsenbord, stylus en touchinterface op hetzelfde apparaat in dezelfde sessie. Een website die touchinvoer detecteert en toetsenbordsnelkoppelingen verwijdert, of andersom, verslechtert de ervaring van een enorme gebruikersgroep die zichzelf mogelijk niet als iemand met een beperking ziet.

\n

Overweeg dit scenario uit de echte wereld: het online portaal van een Turkse bank detecteert dat een klant een touchscreen-tablet gebruikt en schakelt over naar een “mobiele modus” die toetsenbordnavigatie uitschakelt. Een klant met een motorische beperking die de tablet met een Bluetooth-toetsenbord gebruikt, kan nu niet meer door formuliervelden tabben, menu’s met pijltjestoetsen navigeren of toetsenbordsnelkoppelingen gebruiken. Diegene kan zijn of haar bankzaken niet zelfstandig afhandelen. Dit is niet alleen een toegankelijkheidsfout, maar ook een potentiële juridische risico onder de Turkse toegankelijkheidsregelgeving.

\n

Vanuit een gebruiksvriendelijkheids- en SEO-perspectief correleert het respecteren van gelijktijdige invoermechanismen met betere Core Web Vitals-scores, lagere bouncepercentages en hogere gebruikerstevredenheid over diverse apparaatcategorieën — allemaal signalen die door zoekmachines worden beloond.

\n\n

Gerelateerde Axe-core-regels

\n

WCAG 2.5.6 vereist handmatig testen — er is geen geautomatiseerde axe-core-regel die alle schendingen van dit criterium betrouwbaar kan detecteren. De reden is fundamenteel: geautomatiseerde tools kunnen de statische DOM en CSS inspecteren, en ze kunnen bepaalde JavaScript-patronen detecteren, maar ze kunnen het runtimegedrag van event listeners niet volledig observeren terwijl deze reageren op verschillende invoermodaliteiten tijdens een daadwerkelijke gebruikerssessie. De beslissing om een invoermechanisme te beperken is vaak gecodeerd in applicatielogica die alleen wordt uitgevoerd als reactie op specifieke events, waardoor statische analyse onvoldoende is.

\n

\n
• Er bestaat geen speciale geautomatiseerde axe-core-regel voor 2.5.6. Axe-core levert geen regel die specifiek controleert op beperkingen van gelijktijdige invoermechanismen, omdat de schending zich manifesteert als dynamisch JavaScript-gedrag in plaats van een structureel HTML- of ARIA-probleem. Een pagina kan alle geautomatiseerde axe-controles doorstaan en nog steeds 2.5.6 schenden als de event handlers programmatisch invoermodaliteiten verwijderen of uitschakelen tijdens runtime.
\n
• Pointer-events en detectie van touch-events: Hoewel axe-core de beperking zelf niet kan detecteren, moeten handmatige auditors letten op JavaScript dat luistert naar touchstart- of pointerdown-events en vervolgens de DOM wijzigt, focusbeheer verwijdert of flags instelt die het toetsenbordgedrag veranderen. Evenzo zijn keydown-listeners die CSS-klassewijzigingen activeren die touchdoelen verbergen, rode vlaggen om handmatig te inspecteren.
\n
• Waarom automatisering tekortschiet: Geautomatiseerde scanners analyseren het document op één moment in de tijd. Beperkingen van invoermechanismen zijn conditioneel — ze worden pas geactiveerd nadat een specifiek invoerevent is afgevuurd. Een scanner die draait vóór gebruikersinteractie kan niet zien dat een touchstart-handler later document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) zal aanroepen en effectief toetsenbordnavigatie zal vernietigen. Alleen een menselijke tester die beide invoermodaliteiten na elkaar gebruikt, kan deze fout ontdekken.
\n

\n\n

Hoe te Testen

\n

\n
1. Geautomatiseerde baselinescan: Voer axe DevTools of Lighthouse uit op de pagina om een baseline vast te stellen en eventuele gelijktijdig optredende problemen te detecteren. Hoewel geen van beide tools een speciale 2.5.6-regel heeft, kunnen de best practice-controles van axe DevTools toetsenbordvallen of focusbeheerproblemen signaleren die symptomatisch zijn voor invoerbeperkingen. Noteer eventuele fouten voor herstel naast de onderstaande handmatige controles.
\n
2. Inspecteer JavaScript-bron en event listeners: Open Chrome DevTools, ga naar het tabblad Elements en gebruik het paneel Event Listeners om te inspecteren of touchstart-, pointerdown-, pointermove- of MSPointerDown-listeners zijn gekoppeld aan het document of de body. Zoek in de Console in de JavaScript-bron van de pagina naar patronen zoals ontouchstart in window, navigator.maxTouchPoints of 'pointer' in navigator in combinatie met DOM-wijzigingen. Dit zijn veelgebruikte technieken om invoermodaliteit te detecteren en functionaliteit af te schermen.
\n
3. Test van multimodale interactie (toetsenbord + touch): Op een apparaat dat zowel touch- als toetsenbordinvoer ondersteunt (bijv. een Surface, een iPad met toetsenbord of een laptop met touchscreen), begin je de pagina uitsluitend met het toetsenbord te navigeren (Tab, Shift+Tab, Enter, Spatie, pijltjestoetsen). Noteer welke interactieve elementen bereikbaar en functioneel zijn. Schakel vervolgens, zonder de pagina te herladen, over naar touchnavigatie — tik op links, knoppen en formulierelementen. Controleer of alle functionaliteit die via het toetsenbord beschikbaar is, toegankelijk blijft via touch en omgekeerd. Documenteer elk element dat onbereikbaar of niet-functioneel wordt na het wisselen.
\n
4. Screenreader-combinatietest van invoer: Gebruik NVDA met Firefox en navigeer de pagina met het toetsenbord om de screenreader-modus te activeren. Gebruik vervolgens het touchscreen (indien beschikbaar) om te proberen met dezelfde elementen te interageren. Bevestig dat de screenreader en de pagina correct reageren op beide invoeren. Herhaal dit met VoiceOver in Safari op een iPad, met zowel touchgebaren als een gekoppeld Bluetooth-toetsenbord. Controleer met JAWS in Chrome dat het wisselen tussen toetsenbord en muis het focusbeheer niet verbreekt of ervoor zorgt dat interactieve elementen onbruikbaar worden.
\n
5. Code review op patronen die modaliteit vergrendelen: Beoordeel handmatig alle JavaScript-bibliotheken of -frameworks die op de pagina worden gebruikt op ingebouwde detectie van modaliteit. Sommige UI-bibliotheken, met name oudere mobile-first-frameworks, bevatten code die muis- of toetsenbordevents uitschakelt op apparaten waarbij touch is gedetecteerd. Controleer de documentatie en broncode van de bibliotheek op dergelijk gedrag en verifieer dat dit is overschreven of uitgeschakeld.
\n
6. Opnieuw testen na dynamische interacties: Voer acties uit die aanzienlijke DOM-wijzigingen veroorzaken — modals openen, routes in een single-page-app navigeren, formulieren verzenden — en voer na elke overgang de multimodaliteitstest opnieuw uit. Beperkingen worden soms alleen geïntroduceerd in specifieke applicatiestaten.
\n

\n\n

Hoe te Herstellen

\n

Touch detecteren om toetsenbordnavigatie uit te schakelen — Onjuist

\n

<!-- JavaScript detecteert touch en verwijdert alle tabindex-waarden,\n     waardoor toetsenbordnavigatie wordt gebroken voor gebruikers\n     die van invoermodus wisselen -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Touch detecteren om toetsenbordnavigatie uit te schakelen — Juiste aanpak

\n

<!-- Beperk toetsenbordtoegankelijkheid niet op basis van touch-detectie.\n     Laat beide invoermodaliteiten gelijktijdig functioneren.\n     Als je focusstijlen om esthetische redenen moet beheren, gebruik dan de\n     :focus-visible CSS-pseudoklasse in plaats van tabindex te verwijderen. -->\n<style>\n  /* Toon focusringen alleen voor toetsenbordnavigatie, niet voor muiskliks,\n     zonder toetsenbordtoegang volledig te verwijderen */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Geen JavaScript-detectie van modaliteit nodig -->

\n\n

Pointer-event gebruikt om toetsenbordevents te onderdrukken — Onjuist

\n

<!-- Een aangepaste slider die, na het ontvangen van aanwijzerinvoer,\n     stopt met reageren op pijltjestoetsen, waardoor de gebruiker\n     wordt vastgezet in alleen-aanwijzerinteractie -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // toetsenbord uitgeschakeld na aanwijzerinteractie\n    if (e.key === 'ArrowRight') { /* verhogen */ }\n    if (e.key === 'ArrowLeft') { /* verlagen */ }\n  });\n</script>

\n

Pointer-event gebruikt om toetsenbordevents te onderdrukken — Juiste aanpak

\n

<!-- Zowel aanwijzer- als toetsenbordinteracties worden onafhankelijk afgehandeld.\n     Er wordt geen flag ingesteld die voorkomt dat één modaliteit werkt nadat\n     de andere is gebruikt. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Aanwijzerhandler — altijd actief\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // bereken nieuwe waarde op basis van aanwijzerpositie\n    }\n  });\n\n  // Toetsenbordhandler — altijd actief, niet uitgeschakeld door aanwijzergebruik\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Mobiel framework dat muis-events automatisch uitschakelt — Onjuist

\n\n

(Content truncated due to token limit — please retry this article.)