Was ist Keyboard Navigation?

Keyboard Navigation (Tastaturnavigation) bedeutet, dass sich jede Funktion einer Website allein mit der Tastatur erreichen und bedienen lässt. Nutzer springen mit Tab und Shift+Tab von Element zu Element, lösen mit Enter oder Leertaste Aktionen aus und steuern Menüs, Tabs oder Slider mit den Pfeiltasten.

Das klingt nach einem Nischenthema. Ist es nicht. Wer blind ist und einen Screenreader nutzt, arbeitet fast immer mit der Tastatur. Dazu kommen Menschen mit motorischen Einschränkungen, Nutzer von Schaltern, Mundstäben oder Sprachsteuerung und alle Power User, die schneller tippen als klicken. Für sie alle entscheidet die Tastaturnavigation, ob eine Seite funktioniert oder eine Sackgasse ist.

In den WCAG 2.2 gehört die Tastaturbedienung zum Prinzip Bedienbar. Seit dem BFSG ist sie für viele Onlineshops und digitale Dienste in Deutschland Pflicht.

Tastaturnavigation prüfen wir nicht nur von Hand. Roland Golla ist Cypress Ambassador, und bei NCA laufen Tab Reihenfolge, Fokus Management und Fokusfallen als automatisierte Cypress Tests in der Pipeline. Seit Cypress den Befehl cy.press() mit echten Tastatur Events mitbringt, lassen sich genau die Fehler abfangen, die sonst erst im manuellen Audit auffallen. Unsere Frontends bauen wir mit Astro, React und Vue, deshalb kennen wir die typischen Fallen von Custom Komponenten aus dem eigenen Code.

Wir unterstützen Teams beim barrierefreien Webdesign, mit einem strukturierten Accessibility Audit und beim Aufbau von automatisiertem Accessibility Testing. Dazu gehören Tests mit axe DevTools und Cypress, die Prüfung der Tab Reihenfolge mit taba11y und die Einordnung eurer Seite gegen das Barrierefreiheitsstärkungsgesetz.

Eine Maus setzt voraus, dass man sehen und fein zielen kann. Die Tastatur setzt nichts davon voraus. Deshalb ist sie die gemeinsame Basis für fast alle alternativen Eingabegeräte. Schalter, Mundstäbe, Augensteuerung und viele Sprachsteuerungen schicken am Ende Tastatur Events an den Browser.

Wer auf Tastaturnavigation angewiesen ist:

• Blinde Menschen mit Screenreader wie NVDA, JAWS oder VoiceOver
• Menschen mit motorischen Einschränkungen, etwa bei Tremor, Lähmungen oder Rheuma
• Nutzer von Schaltern und Sprachsteuerung, deren Hilfsmittel Tastendrücke simulieren
• Menschen mit vorübergehenden Einschränkungen, etwa mit gebrochenem Arm
• Power User und Entwickler, die mit der Tastatur schlicht schneller sind

Wenn ein einziges Element nicht per Tastatur erreichbar ist, reicht das oft schon. Ein Cookie Banner ohne Fokus, ein Warenkorb Button als div oder ein Modal ohne Ausgang: Für diese Nutzer ist der Kauf an dieser Stelle vorbei.

Tastaturnavigation ist in den WCAG nicht ein einzelnes Kriterium, sondern ein ganzes Bündel. Die wichtigsten Erfolgskriterien im Überblick:

• 2.1.1 Tastatur (A): Jede Funktion muss per Tastatur bedienbar sein, ohne feste Zeitvorgaben für einzelne Tastendrücke.
• 2.1.2 Keine Tastaturfalle (A): Der Fokus darf nirgends festhängen. Wer in eine Komponente hineinkommt, muss auch wieder herauskommen.
• 2.1.4 Tastaturkurzbefehle (A): Kürzel aus einzelnen Buchstaben müssen abschaltbar oder umbelegbar sein, sonst lösen Sprachsteuerungen sie versehentlich aus.
• 2.4.1 Blöcke umgehen (A): Ein Skip Link oder saubere Landmarks erlauben den Sprung direkt zum Hauptinhalt.
• 2.4.3 Fokus Reihenfolge (A): Die Tab Reihenfolge muss Sinn und Bedienung erhalten.
• 2.4.7 Fokus sichtbar (AA): Der aktuelle Fokus muss immer erkennbar sein.
• 2.4.11 Fokus nicht verdeckt, Minimum (AA): Neu in WCAG 2.2. Sticky Header, Cookie Banner oder Chat Widgets dürfen das fokussierte Element nicht komplett verdecken.
• 2.4.13 Fokus Darstellung (AAA): Ebenfalls neu in 2.2. Legt Mindestgröße und Kontrast für den Fokusindikator fest.

Für die Praxis heißt das: WCAG 2.2 Stufe AA ist das Ziel. Die beiden neuen Kriterien treffen genau die Probleme moderner Layouts mit festen Headern und Overlays. Wer sie heute umsetzt, muss beim nächsten Audit nicht nachbessern.

Tastaturnavigation ist kein Schalter, den man umlegt. Sie wächst in Stufen. Jede Stufe baut auf der vorherigen auf, und erst die letzte sorgt dafür, dass das Ergebnis auch nach dem nächsten Release noch stimmt.

Regel Nummer eins: native Elemente nutzen. Ein echter button ist fokussierbar, reagiert auf Enter und Leertaste und wird vom Screenreader korrekt angesagt. Ein div mit Click Handler kann nichts davon.

Fokus sichtbar machen. Mit :focus-visible zeigt der Browser den Fokusring nur bei Tastaturbedienung. Maus Nutzer sehen ihn nicht, Tastatur Nutzer immer. Ein outline: none ohne Ersatz ist dagegen ein klarer WCAG Verstoß.

Skip Link als erstes Element. Er erlaubt den Sprung über die Navigation direkt zum Inhalt und wird erst beim ersten Tab sichtbar.

Dialoge mit dem nativen dialog Element. showModal() hält den Fokus im Dialog, macht den Rest der Seite inert und schließt mit Escape. Eigene Fokusfallen in JavaScript werden damit in den meisten Fällen überflüssig.

Wichtig ist die letzte Zeile: Nach dem Schließen muss der Fokus zurück auf den Auslöser. Sonst landet der Nutzer am Seitenanfang und muss sich neu durchtabben. Für komplexe Widgets wie Tabs, Menüs oder Comboboxen gelten die Tastatur Patterns aus dem ARIA Authoring Practices Guide: Tab springt in die Komponente, Pfeiltasten bewegen sich darin.

Lange war das Testen der Tab Taste in Cypress ein Workaround mit Plugins. Seit Cypress 14.3 gibt es den Befehl cy.press(). Er schickt echte, native Tastatur Events an den Browser. Mit Cypress 15.1 kamen Pfeiltasten, Enter, Leertaste und weitere Tasten dazu. Damit lässt sich Tastaturnavigation so testen, wie Nutzer sie erleben.

Diese Tests laufen in unserer CI mit GitHub Actions oder GitLab CI bei jedem Pull Request. Kombiniert mit axe core in Cypress fällt ein kaputter Fokus auf, bevor er live geht. Für die visuelle Kontrolle der Reihenfolge nutzen wir zusätzlich die Browser Extension taba11y.

Was Automatisierung nicht ersetzt: den kurzen manuellen Test. Maus weglegen, einmal durch die wichtigste Strecke tabben, etwa Startseite, Produkt, Warenkorb, Checkout. Fünf Minuten, die mehr zeigen als jeder Score.

Die meisten Probleme wiederholen sich von Projekt zu Projekt. Diese sechs sehen wir am häufigsten:

1. outline: none ohne Ersatz. Oft aus einem CSS Reset übernommen. Der Fokus ist danach unsichtbar.
2. Klickbare div und span Elemente. Sie sind weder fokussierbar noch per Enter auslösbar.
3. Positiver tabindex. Werte wie tabindex="3" zerreißen die natürliche Reihenfolge. Erlaubt sind in der Praxis nur 0 und minus 1.
4. Modals ohne Fokus Management. Der Fokus bleibt hinter dem Overlay oder kehrt nach dem Schließen nicht zurück.
5. Cookie Banner und Chat Widgets. Sie verdecken den Fokus oder lassen sich nur per Maus schließen.
6. Mega Menüs nur per Hover. Untermenüs öffnen sich bei Mausbewegung, aber nicht per Tastatur.

Viele dieser Fehler hängen mit einer falschen logischen Reihenfolge oder fehlendem semantischem HTML zusammen. Wer an der Wurzel ansetzt, löst mehrere Probleme auf einmal.

Unsere wichtigste Erkenntnis: Tastaturnavigation geht selten beim ersten Bauen kaputt. Sie geht beim zehnten Release kaputt. Ein neues Chat Widget, ein umgebautes Menü, ein Cookie Banner vom Marketing. Deshalb gehört sie für uns in die Test Pipeline und nicht nur in das einmalige Audit.

Die Grundlage ist Operabilität, eines der vier POUR Prinzipien. Für neue Astro Projekte setzen wir gerne auf Accessible Astro Components, die Tastaturbedienung bereits mitbringen. Bei der Werkzeugwahl helfen unsere Übersicht der Accessibility Testing Tools, die Firefox Accessibility Tools und der Lighthouse Accessibility Audit.

Eng verwandt sind barrierefreie Formulare, bei denen Fokus und Fehlermeldungen zusammenspielen, und die Color Accessibility, denn ein Fokusring braucht genug Kontrast. Spannend ist auch die Agent Readiness: KI Agenten, die Websites bedienen, profitieren von denselben sauberen Strukturen wie Tastatur Nutzer.

Die wichtigsten Antworten rund um Tastaturnavigation, WCAG 2.2 und automatisierte Tests.