WCAG 2.5.6: Gleichzeitige Eingabemechanismen

Was diese Regel bedeutet

\n

WCAG 2.5.6 — Concurrent Input Mechanisms ist ein Erfolgskriterium der Stufe AAA unter WCAG 2.2. Die Kernanforderung ist einfach: Webinhalte dürfen die Fähigkeit der Nutzer nicht einschränken oder beeinträchtigen, mehrere Eingabemechanismen gleichzeitig oder austauschbar zu verwenden. In der Praxis bedeutet dies, dass eine Webseite oder Anwendung nicht programmatisch erkennen darf, welches Eingabegerät der Nutzer aktuell verwendet, und ihn dann auf diese eine Modalität festlegen darf, indem ihm der Zugang zu anderen verfügbaren Eingabemethoden verwehrt wird.

\n

Moderne Geräte unterstützen eine große Vielfalt an Eingabemechanismen: physische Tastaturen, Mäuse und Trackpads, Touchscreens, Stifte, Schaltersteuerungen, Spracheingabe, Blickverfolgung und mehr. Viele Nutzer verlassen sich gleichzeitig auf mehr als einen dieser Mechanismen — zum Beispiel kann ein Laptop-Nutzer mit Touchscreen fließend zwischen Touchpad und Finger-Touch-Oberfläche wechseln. Ein Power-User kann ein Formular per Tastatur bedienen, während er eine Maus zum Scrollen verwendet. Eine Person mit motorischer Beeinträchtigung kann eine Kombination aus Kopfmaus und Schaltergerät verwenden. Das Kriterium schützt all diese Arbeitsabläufe.

\n

Ein Fehler tritt auf, wenn eine Website JavaScript verwendet, um den verwendeten Eingabetyp zu erkennen, und dann Funktionen für andere Eingabetypen entfernt oder deaktiviert. Wenn eine Website beispielsweise ein Touch-Ereignis erkennt und anschließend Tastatur-Fokusindikatoren entfernt oder die Tastaturnavigation deaktiviert, ist dies ein direkter Verstoß. Ebenso stellen das Blockieren von Zeigereingaben nach Erkennung der Tastaturnutzung oder die Verwendung von Plattform-APIs zur künstlichen Beschränkung der Eingabe auf eine einzige Modalität allesamt Fehler dar.

\n

Ein Bestehen liegt vor, wenn Nutzer jederzeit während ihrer Interaktion mit allen verfügbaren Eingabemechanismen arbeiten können. Die Inhalte sollten korrekt auf jeden Eingabemechanismus reagieren, den der Nutzer zu einem bestimmten Zeitpunkt verwenden möchte, ohne dass ein Neuladen der Seite, ein Moduswechsel oder zusätzliche Nutzeraktionen erforderlich sind, um einen Eingabetyp wieder zu aktivieren.

\n

Das Kriterium enthält eine offizielle Ausnahme, die in WCAG definiert ist: Die Einschränkung ist zulässig, wenn sie wesentlich ist — das heißt, wenn eine bestimmte Eingabemodalität intrinsisch erforderlich ist. Ein klassisches Beispiel ist eine Handschrifterkennungsanwendung, bei der Touch- oder Stifteingabe der eigentliche Zweck der Funktionalität ist. Ein weiteres Beispiel könnte ein Feld zur Erfassung einer digitalen Unterschrift sein, das eine bestimmte Zeigereingabe erfordert. Selbst in diesen Fällen sollte die Ausnahme eng ausgelegt werden, und der Autor sollte nach Möglichkeit alternative Möglichkeiten zur Erledigung der Aufgabe bereitstellen.

\n

Wichtig ist, dass dieses Kriterium Autoren nicht dazu verpflichtet, Unterstützung für Eingabemechanismen hinzuzufügen, die das Gerät nicht besitzt. Es regelt Einschränkungen, die für Mechanismen gelten, die das Gerät und die Plattform bereits unterstützen. Wenn ein Gerät keinen Touchscreen hat, gibt es nichts einzuschränken.

\n\n

Warum es wichtig ist

\n

Die Freiheit, gleichzeitige oder austauschbare Eingabemechanismen zu verwenden, ist kein Komfortmerkmal — sie ist eine kritische Barrierefreiheitsanforderung, die mehrere unterschiedliche Nutzergruppen direkt betrifft.

\n

Nutzer mit motorischen Beeinträchtigungen sind häufig auf unterstützende Technologien angewiesen, die mehrere Eingabemechanismen kombinieren. Eine Person mit eingeschränkter Handbeweglichkeit kann ein Sip-and-Puff-Schaltergerät zusammen mit einer Bildschirmtastatur verwenden. Jemand mit Tremor kann beginnen, eine Seite per Tastatur zu navigieren, aber zu Maus- oder Touch-Oberfläche wechseln, wenn ein Tastaturkürzel fehlschlägt. Wenn eine Website einen Eingabetyp erkennt und andere deaktiviert, können diese Nutzer vollständig von Inhalten oder Funktionen ausgeschlossen werden.

\n

Nutzer mit kognitiven oder Lernbeeinträchtigungen profitieren häufig von der Möglichkeit, die Eingabemethode zu wählen, die sich für eine bestimmte Aufgabe am angenehmsten oder natürlichsten anfühlt. Das Erzwingen einer einzigen Modalität nimmt diese Wahl und kann unnötige kognitive Belastung verursachen, insbesondere wenn ein Nutzer mit der primären Eingabemethode des Geräts nicht vertraut ist.

\n

Ältere Erwachsene, die altersbedingte motorische Herausforderungen haben können, verwenden zunehmend Geräte, die sowohl Touch- als auch Tastatureingabe unterstützen. Die Möglichkeit, zwischen diesen Mechanismen zu wechseln, wenn die Feinmotorik im Laufe des Tages schwankt, ist wichtig für die langfristige selbstständige Nutzung des Webs.

\n

Power-User und Nutzer multimodaler Geräte — wie Surface Pro- oder iPad Pro-Nutzer — verwenden regelmäßig Tastatur, Stift und Touch-Oberfläche auf demselben Gerät in derselben Sitzung. Eine Website, die Touch-Eingaben erkennt und Tastaturkürzel entfernt oder umgekehrt, verschlechtert die Erfahrung einer enormen Nutzerbasis, die sich möglicherweise nicht als Menschen mit Behinderung versteht.

\n

Betrachten Sie dieses Szenario aus der Praxis: Das Online-Portal einer türkischen Bank erkennt, dass ein Kunde ein Tablet mit Touchscreen verwendet, und wechselt in einen „Mobilmodus“, der die Tastaturnavigation deaktiviert. Ein Kunde mit motorischer Behinderung, der das Tablet mit einer Bluetooth-Tastatur verwendet, kann nun nicht mehr durch Formularfelder tabben, Menüs mit Pfeiltasten navigieren oder Tastaturkürzel verwenden. Er kann seine Bankgeschäfte nicht mehr selbstständig erledigen. Dies ist nicht nur ein Barrierefreiheitsfehler, sondern auch ein potenzielles rechtliches Risiko im Rahmen der türkischen Barrierefreiheitsvorschriften.

\n

Aus Usability- und SEO-Perspektive korreliert die Beachtung gleichzeitiger Eingabemechanismen mit besseren Core Web Vitals-Werten, niedrigeren Absprungraten und höherer Nutzerzufriedenheit über verschiedene Gerätekategorien hinweg — alles Signale, die von Suchmaschinen belohnt werden.

\n\n

Verwandte Axe-core-Regeln

\n

WCAG 2.5.6 erfordert manuelles Testen — es gibt keine automatisierte axe-core-Regel, die alle Verstöße gegen dieses Kriterium zuverlässig erkennen kann. Der Grund ist grundlegend: Automatisierte Tools können den statischen DOM und CSS untersuchen und bestimmte JavaScript-Muster erkennen, aber sie können das Laufzeitverhalten von Ereignis-Listenern nicht vollständig beobachten, wenn diese während einer tatsächlichen Nutzersitzung auf verschiedene Eingabemodalitäten reagieren. Die Entscheidung, einen Eingabemechanismus einzuschränken, ist oft in Anwendungslogik kodiert, die nur als Reaktion auf bestimmte Ereignisse ausgeführt wird, wodurch statische Analysen unzureichend sind.

\n

\n
• Es gibt keine dedizierte automatisierte axe-core-Regel für 2.5.6. Axe-core liefert keine Regel aus, die speziell auf Einschränkungen gleichzeitiger Eingabemechanismen prüft, da sich der Verstoß als dynamisches JavaScript-Verhalten und nicht als strukturelles HTML- oder ARIA-Problem manifestiert. Eine Seite kann alle automatisierten axe-Prüfungen bestehen und dennoch 2.5.6 verletzen, wenn ihre Ereignishandler zur Laufzeit Eingabemodalitäten programmatisch entfernen oder deaktivieren.
\n
• Pointer-Ereignisse und Touch-Ereigniserkennung: Während axe-core die Einschränkung selbst nicht erfassen kann, sollten manuelle Prüfer nach JavaScript suchen, das auf touchstart- oder pointerdown-Ereignisse hört und dann den DOM verändert, Fokusverwaltung entfernt oder Flags setzt, die das Tastaturverhalten verändern. Ebenso sind keydown-Listener, die CSS-Klassenänderungen auslösen, die Touch-Ziele ausblenden, Warnsignale, die manuell überprüft werden sollten.
\n
• Warum Automatisierung nicht ausreicht: Automatisierte Scanner analysieren das Dokument zu einem bestimmten Zeitpunkt. Einschränkungen von Eingabemechanismen sind bedingt — sie werden nur aktiviert, nachdem ein bestimmtes Eingabeereignis ausgelöst wurde. Ein Scanner, der vor der Nutzerinteraktion läuft, kann nicht sehen, dass ein touchstart-Handler später document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) aufruft und die Tastaturnavigation effektiv zerstört. Nur ein menschlicher Tester, der beide Eingabemodalitäten nacheinander verwendet, kann diesen Fehler entdecken.
\n

\n\n

Wie man testet

\n

\n
1. Automatisierter Basisscan: Führen Sie axe DevTools oder Lighthouse auf der Seite aus, um eine Basislinie zu erstellen und gleichzeitig auftretende Probleme zu erkennen. Obwohl keines der Tools eine dedizierte 2.5.6-Regel hat, können die Best-Practice-Prüfungen von axe DevTools Tastaturfallen oder Probleme mit der Fokusverwaltung markieren, die symptomatisch für Eingabebeschränkungen sind. Notieren Sie alle Fehler zur Behebung zusammen mit den unten aufgeführten manuellen Prüfungen.
\n
2. JavaScript-Quellcode und Ereignis-Listener untersuchen: Öffnen Sie Chrome DevTools, wechseln Sie zum Elements-Panel und verwenden Sie den Bereich Event Listeners, um zu prüfen, ob touchstart-, pointerdown-, pointermove- oder MSPointerDown-Listener an das Dokument oder den Body angehängt sind. Suchen Sie in der Konsole im JavaScript-Quellcode der Seite nach Mustern wie ontouchstart in window, navigator.maxTouchPoints oder 'pointer' in navigator in Kombination mit DOM-Änderungen. Dies sind gängige Techniken zur Erkennung von Eingabemodalitäten und zur Steuerung von Funktionalität.
\n
3. Test der Multimodalität (Tastatur + Touch): Verwenden Sie ein Gerät, das sowohl Touch- als auch Tastatureingabe unterstützt (z. B. ein Surface, ein iPad mit Tastatur oder ein Laptop mit Touchscreen), und beginnen Sie, die Seite ausschließlich per Tastatur zu navigieren (Tab, Shift+Tab, Enter, Leertaste, Pfeiltasten). Notieren Sie, welche interaktiven Elemente erreichbar und funktionsfähig sind. Wechseln Sie dann, ohne die Seite neu zu laden, zur Touch-Navigation — tippen Sie auf Links, Schaltflächen und Formularelemente. Vergewissern Sie sich, dass alle Funktionen, die über die Tastatur verfügbar sind, auch über Touch zugänglich bleiben und umgekehrt. Dokumentieren Sie alle Elemente, die nach dem Wechsel unerreichbar oder nicht funktionsfähig werden.
\n
4. Screenreader-Test mit kombinierter Eingabe: Verwenden Sie NVDA mit Firefox und navigieren Sie per Tastatur über die Seite, um den Screenreader-Modus zu aktivieren. Verwenden Sie dann den Touchscreen (falls vorhanden), um zu versuchen, mit denselben Elementen zu interagieren. Bestätigen Sie, dass der Screenreader und die Seite korrekt auf beide Eingaben reagieren. Wiederholen Sie dies mit VoiceOver in Safari auf einem iPad, indem Sie sowohl Touch-Gesten als auch eine gekoppelte Bluetooth-Tastatur verwenden. Überprüfen Sie mit JAWS in Chrome, dass der Wechsel zwischen Tastatur und Maus die Fokusverwaltung nicht unterbricht oder dazu führt, dass interaktive Elemente nicht mehr bedienbar sind.
\n
5. Code-Review auf Muster zur Modalitäts-Sperrung: Überprüfen Sie manuell alle JavaScript-Bibliotheken oder Frameworks, die auf der Seite verwendet werden, auf integrierte Modalitätserkennung. Einige UI-Bibliotheken, insbesondere ältere mobile-first Frameworks, enthalten Code, der Maus- oder Tastaturereignisse auf Geräten mit Touch-Erkennung deaktiviert. Prüfen Sie die Dokumentation und den Quellcode der Bibliothek auf ein solches Verhalten und stellen Sie sicher, dass es überschrieben oder deaktiviert wurde.
\n
6. Erneutes Testen nach dynamischen Interaktionen: Führen Sie Aktionen aus, die erhebliche DOM-Änderungen auslösen — das Öffnen von Modals, das Navigieren zwischen Routen in Single-Page-Apps, das Absenden von Formularen — und führen Sie nach jedem Übergang den Multimodalitätstest erneut durch. Einschränkungen werden manchmal nur in bestimmten Anwendungszuständen eingeführt.
\n

\n\n

Wie man es behebt

\n

Touch-Erkennung zur Deaktivierung der Tastaturnavigation — Falsch

\n

<!-- JavaScript erkennt Touch und entfernt alle tabindex-Werte,\n     wodurch die Tastaturnavigation für Nutzer, die die Eingabemodi wechseln, unterbrochen wird -->\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-Erkennung zur Deaktivierung der Tastaturnavigation — Richtig

\n

<!-- Beschränken Sie die Tastaturzugänglichkeit nicht auf Grundlage der Touch-Erkennung.\n     Ermöglichen Sie das gleichzeitige Funktionieren beider Eingabemodalitäten.\n     Wenn Sie Fokus-Stile aus ästhetischen Gründen steuern müssen, verwenden Sie die\n     CSS-Pseudoklasse :focus-visible anstelle des Entfernens von tabindex. -->\n<style>\n  /* Fokusrahmen nur für Tastaturnavigation anzeigen, nicht für Mausklicks,\n     ohne den Tastaturzugang vollständig zu entfernen */\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<!-- Keine JavaScript-Modalitätserkennung erforderlich -->

\n\n

Pointer-Ereignis zur Unterdrückung von Tastaturereignissen verwendet — Falsch

\n

<!-- Ein benutzerdefinierter Slider, der nach Empfang einer Zeigereingabe\n     nicht mehr auf Pfeiltasten reagiert und den Nutzer auf\n     Zeigereingabe beschränkt -->\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; // Tastatur nach Zeigereingabe deaktiviert\n    if (e.key === 'ArrowRight') { /* erhöhen */ }\n    if (e.key === 'ArrowLeft') { /* verringern */ }\n  });\n</script>

\n

Pointer-Ereignis zur Unterdrückung von Tastaturereignissen verwendet — Richtig

\n

<!-- Sowohl Zeiger- als auch Tastaturinteraktionen werden unabhängig behandelt.\n     Es wird kein Flag gesetzt, das verhindert, dass eine Modalität funktioniert,\n     nachdem die andere verwendet wurde. -->\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  // Pointer-Handler — immer aktiv\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // neuen Wert aus der Zeigerposition berechnen\n    }\n  });\n\n  // Tastatur-Handler — immer aktiv, nicht durch Zeigereingabe deaktiviert\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

Mobiles Framework deaktiviert Mausereignisse automatisch — Falsch

\n\n

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