Tastaturbedienbarkeit: Websites ohne Maus nutzbar machen

Viele Menschen bedienen Websites nie mit der Maus. Personen mit motorischen Einschränkungen, blinde Nutzer, die mit dem Screenreader arbeiten, Menschen mit Tremor – und nicht zuletzt viele geübte Anwender – navigieren mit der Tastatur. Funktioniert eine Seite nur mit der Maus, schließt sie diese Gruppen aus. Die WCAG machen die Tastaturbedienbarkeit deshalb zu einer grundlegenden Anforderung. Dieser Artikel erklärt, was verlangt ist, wie Tastaturnavigation funktioniert und wie du sie in wenigen Minuten selbst prüfst. Was die WCAG insgesamt sind, erklärt der WCAG-Leitfaden

Warum Tastaturbedienbarkeit zählt

Auf die Tastatur angewiesen sind viele: Menschen, die eine Maus nicht präzise führen können, blinde Nutzer, die einen Screenreader per Tastatur steuern, sowie Personen mit Tremor oder Belastungsschmerzen. Hinzu kommt, dass die Tastaturbedienbarkeit die Grundlage für die Screenreader-Nutzung ist – was nicht per Tastatur bedienbar ist, ist es auch mit dem Screenreader nicht. Es handelt sich also nicht um einen Randfall, sondern um ein Fundament.

Was die WCAG verlangen

Mehrere Erfolgskriterien drehen sich um die Tastatur:

• Alle Funktionen müssen per Tastatur bedienbar sein (2.1.1, Stufe A).
• Es darf keine Tastaturfalle geben – aus jedem Element muss man wieder herauskommen (2.1.2, Stufe A).
• Die Fokusreihenfolge muss logisch sein (2.4.3, Stufe A).
• Der Tastaturfokus muss sichtbar sein (2.4.7, Stufe AA).
• Ein Sprunglink sollte wiederkehrende Blöcke überspringen können (2.4.1).

WCAG 2.2 hat ergänzt, dass der Fokus nicht hinter fixierten Elementen verschwinden darf (2.4.11). Die meisten dieser Punkte liegen auf Stufe A, der sichtbare Fokus auf AA – alle innerhalb des für das BFSG maßgeblichen AA-Rahmens (siehe WCAG-Konformitätsstufen).

Die Grundlagen der Tastaturbedienung

Nutzer erwarten ein vertrautes Muster, an das sich auch eigene Komponenten halten müssen: Mit der Tabulatortaste bewegt man sich vorwärts durch die interaktiven Elemente, mit Umschalt und Tabulator zurück. Enter und Leertaste lösen Links und Schaltflächen aus. Innerhalb einer Komponente – etwa einer Auswahlgruppe, einem Menü oder einem Schieberegler – navigiert man mit den Pfeiltasten. Mit Escape schließt man Dialoge und Menüs.

Der Tastaturtest: so prüfst du es selbst

Lege die Maus beiseite und navigiere nur mit der Tastatur. Achte dabei auf fünf Dinge: Erreichst du jedes interaktive Element? Ist der Fokus immer sichtbar? Folgt die Reihenfolge dem sichtbaren Aufbau (von oben nach unten, von links nach rechts)? Kannst du alles auslösen und überall wieder heraus (keine Fallen)? Und halten Dialoge den Fokus, solange sie offen sind, und geben ihn sinnvoll zurück, wenn sie schließen?

Dieser Test dauert nur wenige Minuten und deckt viel auf. Wie er sich in eine vollständige Prüfung einfügt, zeigt Barrierefreiheit testen

Häufige Probleme

• Eigene Bedienelemente, die aus nicht-semantischen Bausteinen gebaut sind (klickbare divs), die sich gar nicht fokussieren oder bedienen lassen.
• Eine per CSS entfernte Fokusanzeige (outline: none) ohne sichtbaren Ersatz.
• Eine unlogische Fokusreihenfolge, weil Elemente per CSS visuell umsortiert wurden.
• Tastaturfallen in Dialogen, eingebetteten Inhalten oder Widgets von Drittanbietern.
• Ein nicht verwalteter Fokus beim Öffnen und Schließen von Dialogen, sodass Nutzer ihre Position verlieren.

Manches davon erkennen automatisierte Werkzeuge – etwa fehlende Fokussierbarkeit –, ob die Reihenfolge aber logisch ist oder eine eigene Komponente wirklich funktioniert, beurteilen sie nicht zuverlässig. Mehr dazu in Automatisierte WCAG-Tests