Tastaturzugänglichkeit
Alle Funktionen müssen ohne Maus bedienbar sein. Tab wechselt zwischen fokussierbaren Elementen; Enter/Leertaste aktiviert; Pfeiltasten navigieren innerhalb von Widgets. Schaltersteuerung, Sprachsteuerung und Screenreader nutzen alle dieselbe Tastaturschnittstelle.
Tastaturzugänglichkeit bedeutet, dass jede Aktion, die Nutzende auf einer Seite ausführen können, ausschließlich mit der Tastatur ausgeführt werden kann. Sie ist die unverhandelbarste Barrierefreiheitsanforderung: Ohne sie funktioniert keine andere assistive Technologie.
Die Tastaturschnittstelle ist die universelle Schnittstelle
Screenreader, Schaltergeräte, Sprachsteuerung, Eye-Tracking — jede assistive Technologie im Web führt letztlich über die Tastaturschicht. Eine nutzende Person ohne motorische Beeinträchtigung mag nie die Tab-Taste drücken, aber dieselbe Website muss auf diese Weise vollständig bedienbar sein, damit Menschen mit Behinderungen sie nutzen können.
Deshalb ist 2.1.1 Tastatur ein Erfolgskriterium der Stufe A: Wer es nicht erfüllt, macht die Website nicht lediglich schwieriger, sondern für ganze Nutzergruppen vollständig unbrauchbar.
Was „per Tastatur bedienbar“ konkret erfordert
- Tab und Shift+Tab verschieben den Fokus vorwärts und rückwärts durch interaktive Elemente.
- Enter aktiviert Links und die meisten Schaltflächen.
- Leertaste aktiviert Schaltflächen und schaltet Checkboxen und Radiobuttons um.
- Pfeiltasten navigieren innerhalb zusammengesetzter Widgets (Tab-Panels, Menüs, Radiogruppen, Listboxen, Schieberegler).
- Escape schließt modale Dialoge, Popovers und Dropdowns.
- Bild auf/ab, Pos1/Ende navigieren durch lange Inhalte, wo dies der Plattformkonvention entspricht.
Ein Widget, das den Tastaturvertrag nicht erfüllt, den Nutzende eines Screenreaders aufgrund seiner Rolle erwarten — etwa eine ARIA-Combobox, die auf Klicks, nicht aber auf Pfeiltasten reagiert — ist technisch fokussierbar, aber funktional defekt.
Die schnellste manuelle Prüfung
Die Seite wird von ganz oben (Fokus in der Adressleiste, dann Tab)
bis zur Fußzeile durchgetabbt. Die Tab-Reihenfolge sollte der visuellen
Reihenfolge entsprechen. Jedes klickbare Element sollte genau einmal den
Fokus erhalten. Das Drücken von Enter oder Leertaste auf einem fokussierten
Element sollte dasselbe Ergebnis liefern wie ein Mausklick darauf. Das
Drücken von Escape innerhalb eines modalen Dialogs sollte ihn schließen.
Ist ein Element nicht erreichbar, wird ein Element in falscher Reihenfolge
angesprungen oder wird der Fokus eingeschlossen, wurden Fehler gefunden.
Fünf Minuten diszipliniertes Tab-Navigieren deckt mehr Barrierefreiheitsprobleme auf als fünfzehn Minuten axe-core-Scanning.
Häufige Fehlermuster
<div onclick>für klickbare Karten. Nicht fokussierbar, nicht per Tastatur aktivierbar, für Screenreader als interaktives Element vollständig unsichtbar. Stattdessen<button>(für Aktionen) oder<a href>(für Navigation) verwenden.- Benutzerdefinierte Dropdowns, die sich nicht mit Enter/Leertaste öffnen. Nur mit Klick-Handlern implementiert; Nutzende können den Auslöser fokussieren, aber die Liste nicht öffnen.
- Modale Dialoge, die den Fokus nicht einschließen. Tab verschiebt den Fokus aus dem Dialog heraus in die (visuell verdeckte) Seite dahinter. Nutzende wissen nicht, wo sie sich befinden.
- Modale Dialoge, die den Fokus zu stark einschließen. Escape schließt den Dialog nicht. Die nutzende Person ist eingesperrt.
- Sprunglink-Ziel nicht fokussierbar. Der Sprunglink springt zu
#main, aber<main id="main">fehlttabindex="-1", sodass der Fokus sich nicht tatsächlich verschiebt und das nächste Tab wieder vom Seitenanfang startet.
Zwei Bibliotheken sind empfehlenswert: focus-trap für die Fokusverwaltung innerhalb von modalen Dialogen und tabbable für das Auffinden fokussierbarer Elemente innerhalb eines Containers. Beide sind klein und ohne Vorgaben.