Tastaturnavigation: Websites ohne Maus bedienen

Wird geladen…

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

WebAIM – Keyboard Accessibility

Praxisnahe Einführung in Tastaturbedienbarkeit mit konkreten Beispielen und Gegenbeispielen.

Keyboard Accessibility besuchen

Über die Autorin / den Autor

Benjamin Christi

Benjamin ist Webentwickler mit dem Anspruch, das Handwerk ernst zu nehmen – sauberer Code, durchdachte Lösungen, langfristige Begleitung statt schneller Abschlüsse. Ein besonderes Herzensthema ist barrierefreie Entwicklung: Als Accessibility-Spezialist setzt er sich dafür ein, dass das Web für alle Menschen zugänglich ist - nicht als Pflichtübung, sondern als Haltung.