Erfolgskriterien

WCAG 2.1.1 Tastatur

Erfolgskriterium 2.1.1 verlangt, dass die gesamte Funktionalität des Inhalts über eine Tastaturschnittstelle bedienbar ist, ohne bestimmtes Timing für einzelne Tastenanschläge zu erfordern. Es ist ein Kriterium der Stufe A – eine der grundlegenden Anforderungen unter dem Bedienbar-Prinzip, Richtlinie 2.1 (Tastaturzugänglich).

Warum "Tastatur" und nicht nur "nicht mausabhängig"

Dieses Kriterium ist speziell um eine Tastaturschnittstelle formuliert, weil sie stellvertretend für eine ganze Kategorie assistiver Technologie steht: Schaltgeräte, Sprachsteuerungssoftware und Screenreader arbeiten typischerweise alle über dieselbe tastaturäquivalente Ereignisschnittstelle, die auch eine echte Tastatur verwendet. Ein per Tastatur bedienbares Steuerelement ist sehr oft gleichzeitig für all diese bedienbar; ein reines Maus-Steuerelement schließt sie alle gleichzeitig aus.

Was "alle Funktionalität" tatsächlich bedeutet

Jede interaktive Fähigkeit auf der Seite benötigt einen Tastaturweg – nicht nur die Hauptnavigation, sondern auch Drag-and-Drop-Neuordnung, durch Hover ausgelöste Menüs, benutzerdefinierte Schieberegler, Canvas-basierte Zeichenwerkzeuge, Rechtsklick-Kontextaktionen. Wenn ein Mausnutzer etwas tun kann, braucht ein Tastaturnutzer eine gleichwertige Möglichkeit, es ebenfalls zu tun, selbst wenn sich das genaue Interaktionsmuster unterscheidet (Pfeiltasten statt Ziehen, zum Beispiel).

Die eine enge Ausnahme

WCAG erlaubt eine Ausnahme nur dort, wo die zugrunde liegende Funktion grundlegend eine Eingabe erfordert, die nicht mit angemessener Genauigkeit per Tastatur emuliert werden kann – Freihandzeichnen ist das Standardbeispiel. Dies ist eine enge Ausnahme, keine allgemeine Entschuldigung: Ein benutzerdefiniertes Dropdown, Modal oder eine Ziehen-zum-Neuordnen-Liste werden alle erwartungsgemäß Tastaturäquivalente haben; sie erfordern nicht grundlegend einen Zeiger, sie wurden nur unter der Annahme gebaut, dass einer verwendet wird.

Wo dies in der Praxis scheitert

Siehe Tastaturunzugängliche Steuerelemente für die konkreten Fehlermuster: <div>s, die als Schaltflächen gestylt sind, aber nur einen Maus-Klick-Handler haben, benutzerdefinierte Widgets ohne Tastaturereignis-Verdrahtung, und positive tabindex-Werte, die die natürliche Tab-Reihenfolge durcheinanderbringen. Die Lösung ist in fast jedem Fall dieselbe: Bevorzugen Sie echte, native interaktive HTML-Elemente, die kostenlos eingebautes Tastaturverhalten mitbringen, gegenüber dem Neubau dieses Verhaltens von Grund auf auf einem generischen Element.

Die verwandte Falle: Tastaturfallen

Ein separates, aber eng verwandtes Kriterium, 2.1.2 (Keine Tastaturfalle), verlangt, dass, wenn der Tastaturfokus in eine Komponente hineinbewegt werden kann, er auch mit ausschließlich der Tastatur wieder heraus bewegt werden kann (oder dem Nutzer gesagt wird, wie). Ein Modal-Dialog, der per Tab geöffnet werden kann, aber keine per Tastatur zugängliche Schließen-Schaltfläche hat, ist eine Tastaturfalle – technisch getrennt von einem 2.1.1-Fehler, aber meist zusammen mit einem gefunden.

Häufige Fragen

Was ist WCAG 2.1.1 Tastatur?

Ein Kriterium der Stufe A, das verlangt, dass jede interaktive Funktion allein mit der Tastatur nutzbar ist, nicht nur mit der Maus.

Was verstößt typischerweise gegen 2.1.1?

Eigene Bedienelemente aus div oder span mit Klick-Handlern ohne Tastaturunterstützung sowie Interaktionen, die nur auf Hover oder Mausereignisse reagieren.

Gibt es Ausnahmen?

Ja – Funktionen, die zwingend eine durchgehende pfadabhängige Eingabe erfordern (etwa freies Zeichnen), sind ausgenommen. Die weitaus meisten Bedienelemente müssen jedoch tastaturbedienbar sein.