Wenn ich einer Website auf den Zahn fühlen will, mache ich als Erstes eine einfache Sache: die Maus weglegen. Nicht ausstellen, nicht abdecken – physisch zur Seite legen, damit der Reflex nicht greift. Was dann passiert, ist eine der ehrlichsten Accessibility-Prüfungen, die es gibt. Eine saubere Tastaturbedienung als Barrierefreiheits-Anforderung ist die Grundlage für blinde Nutzer mit Screenreader, für Menschen mit motorischen Einschränkungen, für Powernutzer mit Tastaturkürzeln und für alle, deren Maus gerade nicht funktioniert. Sie ist nicht verhandelbar – sie ist WCAG-Pflicht auf Stufe A. In diesem Ratgeber zeige ich Ihnen, wie Sie Tastaturbedienung und Fokus-Management richtig umsetzen, welche WCAG-Kriterien relevant sind und – am wichtigsten – wie Sie das selbst testen, so wie es Ihre Nutzer tun werden.
Was Tastaturbedienung im Sinne der WCAG bedeutet
Eine Website ist tastaturbedienbar, wenn sich jede Funktion ohne Maus ausführen lässt – mit Tab zur Navigation zwischen Elementen, mit Enter und Leertaste zum Aktivieren, mit Pfeiltasten in komplexeren Komponenten, mit Escape zum Abbrechen. Dabei muss der Fokus zu jedem Zeitpunkt sichtbar sein, in einer logischen Reihenfolge laufen und sich aus jeder Komponente wieder herausbewegen lassen. Diese Anforderungen sind in mehreren WCAG-Kriterien festgehalten und betreffen sowohl die Grundkonformität auf Stufe A als auch wichtige Erweiterungen auf Stufe AA – darunter zwei Kriterien, die mit WCAG 2.2 neu hinzugekommen sind.
Die WCAG-Kriterien rund um Tastatur und Fokus
Die wichtigsten Erfolgskriterien im Überblick:
| Kriterium | Stufe | Worum es geht |
|---|---|---|
| 2.1.1 Tastatur | A | Alle Funktionalität muss per Tastatur erreichbar sein |
| 2.1.2 Keine Tastaturfalle | A | Fokus muss jedes Element wieder verlassen können |
| 2.4.3 Fokus-Reihenfolge | A | Reihenfolge der Fokussierung muss sinnvoll sein |
| 2.4.7 Fokus sichtbar | AA | Der Tastaturfokus muss visuell erkennbar sein |
| 2.4.11 Fokus nicht verdeckt (Minimum) | AA (neu in 2.2) | Der fokussierte Bereich darf nicht vollständig verdeckt werden |
| 2.5.7 Ziehbewegungen | AA (neu in 2.2) | Drag-Funktionen brauchen eine Tastatur-Alternative |
Wie echte Nutzer testen: Die Tastatur-Checkliste
Bevor wir in die häufigsten Fallen einsteigen, hier die Test-Reihenfolge, mit der Sie Ihre eigene Seite selbst prüfen können. Es braucht keine spezielle Software – nur Disziplin, die Maus liegen zu lassen.
- Maus zur Seite legen. Wirklich. Hände auf die Tastatur.
- Mit Tab von oben nach unten durch die Seite gehen. Notieren Sie, wo der Fokus landet und ob er sichtbar ist.
- Prüfen Sie die Reihenfolge. Folgt sie der visuellen Anordnung, oder springt sie unerwartet?
- Versuchen Sie, jede interaktive Aktion auszulösen – Buttons mit Enter oder Leertaste, Links mit Enter, Checkboxen mit Leertaste, Radio-Gruppen mit Pfeiltasten.
- Öffnen Sie ein Modal, einen Dialog oder ein Akkordeon. Bleibt der Fokus innerhalb, solange das Modal offen ist? Schließt Escape das Modal? Springt der Fokus danach zurück zum auslösenden Element?
- Schauen Sie auf Sticky-Elemente. Verschwindet das fokussierte Feld hinter einem Cookie-Banner, einem Sticky-Header oder einem Live-Chat-Widget?
- Versuchen Sie, Filter und Slider zu bedienen. Geht das ohne Ziehbewegung?
- Notieren Sie, wo Sie „stecken bleiben“ – das sind die Tastaturfallen.
Diese zehn Minuten ersetzen kein vollständiges Audit, aber sie finden in fast jeder Website Mängel, die mit automatischen Scannern unsichtbar bleiben. Es ist die direkteste Form, in den Schuhen eines Tastatur-Nutzers zu laufen.
Die häufigsten Tastatur-Fallen
Das Modal ohne Focus-Trap
Ein Modal-Dialog öffnet sich, aber wenn Sie weitertabben, wandert der Fokus hinter den Dialog und navigiert in der nicht mehr sichtbaren Seite herum. Ein blinder Nutzer hört Inhalte, die er gar nicht erreichen können sollte. Die saubere Lösung ist ein Focus-Trap, der den Fokus innerhalb des Modals zirkulieren lässt, plus eine korrekte Initialisierung – beim Öffnen springt der Fokus in den Dialog, beim Schließen zurück zum auslösenden Element. Und Escape muss das Modal schließen können.
Der unsichtbare Fokus
In meinen Audits sehe ich es ständig: outline: none im globalen CSS, ohne Ersatz. Der Tastaturfokus verschwindet komplett, niemand sieht mehr, wo er steht. Das ist nicht „cleanes Design“, das ist ein Verstoß gegen WCAG 2.4.7. Wer den Default-Outline-Stil des Browsers nicht mag, ersetzt ihn durch einen eigenen, sichtbaren Stil – mit Outline, Box-Shadow oder Border, mit ausreichendem Kontrast und ausreichender Stärke. Aber niemals einfach entfernen.
Der Sticky-Header, der den Fokus verdeckt
Ein klassisches Symptom der modernen Web-Architektur. Sie tabben durch ein Formular, kommen zum unteren Bereich – und das aktive Eingabefeld verschwindet unter einem klebenden Header oder einem Cookie-Banner am unteren Rand. Genau dafür gibt es das neue Kriterium 2.4.11 in WCAG 2.2. Die Lösung ist Scroll-Padding oder eine intelligente Sticky-Logik, die zurückweicht, wenn ein Element dahinter den Fokus erhält.
Custom-Komponenten ohne Tastatur-Handler
Ein selbstgebauter Dropdown, der nur auf Maus-Hover reagiert. Ein Akkordeon, das sich per Klick öffnet, aber Enter und Leertaste ignoriert. Ein Datepicker, der mit den Pfeiltasten nicht funktioniert. Diese Komponenten fallen zuverlässig in Audits durch. Wer Custom-Widgets baut, muss die zugehörigen Tastatur-Patterns mitbauen – und davor steht oft die Frage, ob man die Komponente überhaupt selbst bauen muss oder ob ein natives HTML-Element den Job erledigen würde. Welche ARIA-Regeln dabei gelten, habe ich in ARIA-Label richtig einsetzen: Der Praxis-Guide für Entwickler ausführlich beschrieben.
Drag-only Slider und Karten
Preisfilter, Schieberegler, Image-Slider, die ausschließlich durch Ziehen mit der Maus bedienbar sind, scheitern an WCAG 2.5.7 und am grundlegenden Tastatur-Kriterium gleichzeitig. Jede Funktion, die Drag verlangt, braucht eine Alternative – Tastaturkürzel, Plus-Minus-Buttons, ein direktes Eingabefeld.
Cookie-Banner, die den Fokus stehlen
Der häufigste Erstkontakt mit der Tastatur-Realität: Sie laden die Seite, drücken Tab – und landen sofort im Cookie-Banner, aus dem Sie ohne Klick auf „Akzeptieren“ nicht mehr herauskommen. Manchmal lässt sich der Fokus gar nicht weiterbewegen. Manchmal landet er unsichtbar im Overlay. Cookie-Banner gehören zu den am häufigsten falsch implementierten Komponenten überhaupt, gemessen an ihrer Verbreitung.
tabindex richtig einsetzen
Das tabindex-Attribut ist eines der mächtigsten und am häufigsten missbrauchten Werkzeuge. Es kennt im Wesentlichen drei sinnvolle Werte:
tabindex="0": Macht ein Element, das nativ nicht fokussierbar wäre (etwa eindiv), per Tab erreichbar. Sinnvoll bei Custom-Komponenten, bei denen kein natives Element passt.tabindex="-1": Macht ein Element programmatisch fokussierbar, aber nicht über Tab. Wichtig für dynamisches Fokus-Management – etwa bei einer Fehlerübersicht, zu der der Fokus per JavaScript gesetzt werden soll.tabindex="1"und höher: Vermeiden Sie diese Werte. Sie erzeugen eine separate, manuelle Tab-Reihenfolge, die fast immer mit der visuellen Reihenfolge in Konflikt gerät und Wartung zur Hölle macht.
Die Regel in einem Satz: Lassen Sie die natürliche DOM-Reihenfolge die Tab-Reihenfolge bestimmen. Sortieren Sie nicht per tabindex-Werten, sondern strukturieren Sie Ihr HTML so, dass die Lesereihenfolge bereits stimmt – die Grundlagen dazu finden Sie in Semantisches HTML als Fundament der Barrierefreiheit.
Fokus-Management bei dynamischen Inhalten
Sobald sich die Seite dynamisch ändert, müssen Sie den Fokus aktiv steuern. Die wichtigsten Fälle: Beim Öffnen eines Modals oder Dialogs springt der Fokus in den Dialog. Beim Schließen springt er zurück zum auslösenden Element. Beim Absenden eines fehlerhaften Formulars springt der Fokus zur Fehlerübersicht oder zum ersten fehlerhaften Feld. Beim Laden neuer Inhalte – etwa nach einem Filter-Klick – muss klar sein, wohin der Fokus geht; idealerweise zur Überschrift des neuen Inhaltsbereichs. Und ein Skip-Link am Seitenanfang – „Zum Hauptinhalt springen“ – erspart Tastatur-Nutzern, sich jedes Mal durch den vollständigen Header tabben zu müssen.
Wie Sie Tastatur-Probleme vor jedem Release fangen
Die manuelle Maus-weg-Probe ist die wichtigste Prüfung und die, die Ihre Nutzer letztlich auch durchführen. Sie hat aber einen praktischen Nachteil: Sie wird selten konsequent gemacht. Niemand testet vor jedem Sprint-Release alle Seiten manuell mit der Tastatur. Genau für die Lücke dazwischen ist unser Access Guard da.
Das Monitoring prüft Ihre Seiten nach jedem Code-Deployment automatisch auf typische Tastatur-Verstöße – fehlende Fokus-Indikatoren, nicht fokussierbare Interaktionselemente, Custom-Komponenten ohne sichtbare Fokus-Behandlung, neu eingeführte Tastaturfallen. Die Befunde landen direkt in Ihren Entwicklungs-Werkzeugen wie Jira, Slack oder Teams, mit konkreten Code-Hinweisen zur Behebung. So bleibt eine einmal sauber umgesetzte Tastaturbedienung auch nach dem nächsten Refactoring sauber. Die manuelle Maus-Probe ersetzt das nicht – sie ergänzt sie um die kontinuierliche, automatisierte Absicherung dazwischen.
