Wird geladen…
Tastaturnavigation: Websites ohne Maus bedienen
Tastaturbedienbarkeit ist eines der vier WCAG-Grundprinzipien – und in der Praxis eines der häufigsten Probleme. Die Anforderung selbst ist klar: Alles, was mit einer Maus erreichbar ist, muss auch per Tastatur erreichbar und bedienbar sein. Was das konkret bedeutet, ist eine andere Frage.
Dieser Artikel erklärt, warum Tastaturnavigation für eine diverse Nutzergruppe relevant ist, welche Fehler am häufigsten auftreten – und was gute Umsetzung ausmacht.
Wer wirklich davon abhängig ist
Menschen, die keine Maus benutzen können oder wollen, sind vielfältiger als oft angenommen. Motorische Einschränkungen, Tremor, Lähmungen – das sind offensichtliche Gründe. Aber auch Power-User navigieren bevorzugt per Tastatur, weil es schneller ist. Sprachsteuerungssoftware wie Dragon NaturallySpeaking baut intern auf Tastatur-Events auf. Automatisierte Testsysteme simulieren Tastatureingaben. Und wer auf einem Tablet mit angeschlossener Tastatur surft, braucht dieselbe Unterstützung.
Fokus: sichtbar und logisch
Der sichtbare Fokusindikator zeigt, welches Element gerade aktiv ist. In WCAG 2.2 ist ein ausreichend sichtbarer Fokusindikator jetzt eine AA-Anforderung – und viele Designs verstoßen dagegen, weil Browser-Standardstile mit outline: none überschrieben wurden, ohne Ersatz zu bieten.
Guter Fokus bedeutet: kontrastreich (mindestens 3:1 zum Hintergrund), gut erkennbar in der Größe, und bei allen interaktiven Elementen vorhanden. Das muss kein aufdringliches Rechteck sein – aber es muss da sein.
Häufige Probleme bei der Tastaturnavigation
! – Kein sichtbarer Fokus
Fokusindikator fehlt oder kontrastiert zu schwach. Nutzende wissen nicht, wo sie sich auf der Seite befinden.
! – Fokus-Falle
Ein Dialog oder Widget kann per Tab betreten, aber nicht mehr verlassen. Der Nutzer steckt fest und muss die Seite neu laden.
! – Falsche Tab-Reihenfolge
tabindex-Werte größer 0 bringen den Fokus in eine Reihenfolge, die nicht der visuellen Darstellung entspricht.
! – Eigene Komponenten ohne Tastatur
Selbst entwickelte Dropdowns, Accordions oder Slider, die keine Tastatur-Events implementieren – und damit nicht bedienbar sind.
ARIA: Semantik allein reicht nicht
Wenn HTML-Semantik allein nicht ausreicht – etwa bei komplexen Widgets wie Tabs, Bäumen oder Datumswählern – kommen ARIA-Rollen und -Attribute ins Spiel. Sie ergänzen die Bedeutung und ermöglichen Screenreadern, Interaktionsmuster zu kommunizieren.
Wichtig: ARIA macht ein Element nicht automatisch per Tastatur bedienbar. Ein role="button" auf einem div macht es semantisch zum Button – aber ohne Tastaturereignis. Die Interaktion muss separat implementiert werden. Der ARIA Authoring Practices Guide (APG) beschreibt für alle gängigen Muster, welche Tastaturinteraktionen erwartet werden.
Weiterführende Ressourcen
W3C – ARIA Authoring Practices Guide (APG)
Offizielle Referenz für Tastaturinteraktionsmuster in ARIA-Widgets. Unverzichtbar für die Entwicklung komplexer Komponenten.
ARIA Authoring Practices Guide (APG) besuchen (öffnet in neuem Tab)WebAIM – Keyboard Accessibility
Praxisnahe Einführung in Tastaturbedienbarkeit mit konkreten Beispielen und Gegenbeispielen.
Keyboard Accessibility besuchen (öffnet in neuem Tab)
Über die Autorin / den Autor
