Tastaturnavigation testen: Ein Rundgang ohne Maus

Warum ist die Bedienung per Tastatur so wichtig?

Viele Menschen nutzen keine Maus: blinde Menschen mit Screenreader, Menschen mit motorischen Einschränkungen, die eine Tastatur, Schalter oder Sprachsteuerung verwenden, und alle, die schnell per Tastatur arbeiten. Viele Hilfsmittel greifen dabei auf dieselbe Tastaturschnittstelle zu.

WCAG verlangt deshalb im Kriterium 2.1.1 auf Stufe A, dass alle Funktionen per Tastatur bedienbar sind. Ein Tastaturtest braucht kein Werkzeug und findet trotzdem einige der folgenreichsten Barrieren. Probleme, die er zeigt, haben oft technische Ursachen, die auch Screenreader betreffen.

Welche Tasten brauchst du für den Test?

Manche Komponenten haben bewusst nur einen Tab-Stopp, etwa eine Reihe von Reitern. Innerhalb der Gruppe bewegst du dich dann mit den Pfeiltasten. Auf dem Mac springt Safari mit Tab je nach Einstellung nur zu Formularfeldern. Aktiviere in den erweiterten Einstellungen, dass Tab alle Objekte einer Webseite hervorhebt, oder teste in einem anderen Browser.

1. 1Tab springt zum nächsten Bedienelement, Umschalt+Tab zum vorherigen.
2. 2Enter folgt einem Link oder löst einen Button aus.
3. 3Die Leertaste löst Buttons aus, setzt Häkchen in Checkboxen und scrollt die Seite, wenn kein Element fokussiert ist.
4. 4Pfeiltasten wechseln zwischen Radiobuttons, Menüeinträgen, Reitern oder Schieberegler-Werten.
5. 5Escape schließt Dialoge, Menüs und Ausklapplisten.

Wie läuft ein Tastaturtest ab?

1. 1Lade eine wichtige Seite neu und klicke nicht hinein, damit du am Dokumentanfang startest.
2. 2Drücke einmal Tab: Gibt es einen Link „Zum Inhalt springen“, mit dem sich die wiederkehrende Navigation überspringen lässt (WCAG 2.4.1)?
3. 3Folge mit Tab allen interaktiven Elementen und beobachte Reihenfolge und Fokus.
4. 4Öffne Menü, Suche und Akkordeons und schließe sie wieder.
5. 5Öffne einen Dialog, bediene ihn und schließe ihn mit Escape.
6. 6Fülle ein Formular aus, erzeuge einen Fehler und sende es ab.
7. 7Prüfe am Seitenende, ob Footer-Links, eingebettete Videos oder Karten erreichbar sind und sich wieder verlassen lassen.
8. 8Wiederhole den Rundgang mit 200 Prozent Zoom und prüfe, ob der Fokus im sichtbaren Bereich bleibt.

Was ist eine sinnvolle Fokusreihenfolge?

Der Fokus soll sich in einer Reihenfolge bewegen, die zum Inhalt und zur Bedeutung passt (WCAG 2.4.3). Meist heißt das: von oben nach unten und von links nach rechts, so wie man die Seite liest.

Typische Ursachen für Sprünge sind Elemente, die per CSS optisch umsortiert wurden, und positive tabindex-Werte wie tabindex="3". Ein häufiger Fehler sind ausgeblendete Menüs, deren Links trotzdem fokussierbar bleiben. Dann landet der Fokus minutenlang auf unsichtbaren Elementen.

Prüfe auch, wohin der Fokus nach einer Aktion springt. Nach dem Hinzufügen zum Warenkorb oder dem Nachladen weiterer Ergebnisse sollte er nicht zurück an den Seitenanfang fallen.

Wie muss der Tastaturfokus aussehen?

Der Fokus muss sichtbar sein (WCAG 2.4.7, Stufe AA). Viele Websites entfernen den Standardrahmen des Browsers mit outline: none, ohne einen eigenen Fokusstil zu setzen. Dann weiß niemand, wo er gerade ist.

Seit WCAG 2.2 darf das fokussierte Element außerdem nicht vollständig von eigenen Inhalten verdeckt werden, etwa von einem fixierten Header oder Cookie-Banner (WCAG 2.4.11). Ein deutlicher, kontrastreicher Fokusrahmen hilft allen; genaue Vorgaben zur Fokusdarstellung enthält das AAA-Kriterium 2.4.13. Teste den Fokus auch auf farbigen Flächen und Bildern, denn ein Rahmen in Markenfarbe kann dort verschwinden.

Welche Tastaturprobleme sind typisch?

Viele dieser Probleme vermeidest du mit nativen HTML-Elementen: button für Aktionen, a mit href für Links, select und input für Auswahl und Eingaben. Sie bringen Tastaturbedienung und Fokus von Haus aus mit. Für eigene Komponenten beschreiben die ARIA Authoring Practices, welche Tasten erwartet werden.

1. 1Unsichtbarer Fokus: Du erkennst nicht, welches Element gerade aktiv ist.
2. 2Tastaturfalle: Der Fokus kann einen Bereich nicht mehr verlassen, etwa ein eingebettetes Video oder eine Karte (WCAG 2.1.2).
3. 3Nicht erreichbare Aktion: Ein sichtbarer Button ist ein div mit Klick-Ereignis und reagiert nur auf die Maus.
4. 4Eigene Auswahllisten oder Datumswähler, die sich nur per Maus öffnen lassen.
5. 5Karussells, die weiterlaufen und den Fokus mitnehmen.
6. 6Dialog ohne Rückweg: Nach dem Schließen landet der Fokus an einer unerwarteten Stelle.
7. 7Tastenkürzel aus einzelnen Buchstaben, die sich weder abschalten noch ändern lassen (WCAG 2.1.4).

Wie sollen sich Dialoge und Menüs verhalten?

Für modale Dialoge beschreibt die W3C-Sammlung ARIA Authoring Practices ein klares Muster: Beim Öffnen springt der Fokus in den Dialog. Tab und Umschalt+Tab bewegen sich nur innerhalb des Dialogs. Escape schließt ihn. Danach kehrt der Fokus zu dem Element zurück, das den Dialog geöffnet hat.

Das Festhalten des Fokus im offenen Dialog ist gewollt und keine Tastaturfalle, solange er sich per Tastatur wieder schließen lässt. Bei Ausklappmenüs sollte Escape das Menü schließen und den Fokus auf den auslösenden Button zurücksetzen. Prüfe auch das Cookie-Banner: Es sollte früh per Tab erreichbar sein und sich per Tastatur bestätigen oder ablehnen lassen.

Wie dokumentierst du Tastaturprobleme?

Halte URL, Browser, Startpunkt, Tastenschritte und beobachtetes Verhalten fest. Beschreibe die blockierte Aufgabe statt nur „Tastatur funktioniert nicht“. So kann die Entwicklung das Problem nachstellen und nach einer Änderung erneut prüfen. Ein Beispiel: „Chrome, Startseite, siebenmal Tab: Fokus verschwindet hinter dem Cookie-Banner, Menü nicht erreichbar.“

Der Tastaturtest ist keine vollständige Bewertung. Ergänze Screenreader-Tests, Vergrößerung und automatische Findings. Ein Scanner wie der Accessonaut-Check findet etwa Bedienelemente ohne Namen, eine unlogische Fokusreihenfolge erkennt er nicht. Bei zentralen Abläufen helfen Rückmeldungen von Menschen, die diese Zugangswege täglich nutzen.