Tastaturnavigation ist der Lackmustest jeder barrierefreien Website. Denn wer eine Seite nicht allein mit der Tastatur bedienen kann, sperrt damit alle aus, die keine Maus benutzen können – blinde Menschen ebenso wie viele mit motorischen Einschränkungen. In diesem Ratgeber zeige ich Ihnen aus der Audit-Praxis, wer auf die Tastatur angewiesen ist, welche WCAG-Kriterien gelten, wie Sie Tastatur-Fallen, falsche Fokus-Reihenfolgen und unsichtbare Fokus-Markierungen vermeiden und warum gerade dieser Bereich kein Scanner allein prüfen kann. Am Ende verrate ich Ihnen den Test, den jede und jeder in fünf Minuten selbst durchführen kann.

Was ist Tastaturnavigation?

Tastaturnavigation bedeutet, eine Website vollständig mit der Tastatur zu bedienen – ganz ohne Maus. Mit der Tabulatortaste springen Nutzer von einem Bedienelement zum nächsten, mit Umschalt und Tabulator zurück. Enter und Leertaste lösen Aktionen aus, die Pfeiltasten steuern innerhalb von Komponenten, und Escape schließt geöffnete Dialoge.

Hinter dieser Anforderung steht ein klares Kriterium. Das Erfolgskriterium 2.1.1 Tastatur (Stufe A) verlangt, dass sich jede Funktion einer Seite per Tastatur ausführen lässt. Es gibt dabei keine Ausnahme: Was per Maus geht, muss auch per Tastatur gehen.

Wichtig ist die Erkenntnis dahinter. Tastaturbedienung ist kein Sonderfall für wenige. Denn sie ist die Grundlage, auf der viele Hilfsmittel überhaupt erst funktionieren. Wer hier patzt, verliert nicht einen Nutzer, sondern eine ganze Gruppe auf einmal. Deshalb gehört die Tastaturbedienung zu den ersten Dingen, die wir in einem Audit prüfen.

Wer auf die Tastatur angewiesen ist

Auf die Tastatur angewiesen ist eine größere Gruppe, als die meisten vermuten. An erster Stelle stehen blinde Menschen. Denn ein Screenreader wird vollständig per Tastatur gesteuert. Daraus folgt ein harter Satz: Was nicht mit der Tastatur funktioniert, funktioniert auch nicht mit dem Screenreader.

Dazu kommen motorische Einschränkungen. Menschen mit Parkinson, einer Spastik oder einer Sehnenscheidenentzündung können eine Maus oft nicht präzise führen. Sie nutzen stattdessen die Tastatur, spezielle Schalter oder Sprachsteuerung – und all diese Eingaben landen am Ende als Tastaturbefehle im System. Auch Nutzer einer Bildschirmlupe sind betroffen, weil sie sehen müssen, wo der Fokus gerade steht. Hinzu kommen Menschen mit einer nur vorübergehenden Einschränkung, etwa einem gebrochenen Arm.

Die Zahlen unterstreichen das. Tastatur- und Fokusprobleme machen je nach Erhebung rund 15 bis 20 Prozent aller WCAG-Verstöße aus. Sie gehören damit zu den häufigsten Barrieren überhaupt. Wie Screenreader im Detail arbeiten, zeige ich im Ratgeber zu Screenreadern.

Die fünf Regeln barrierefreier Tastaturbedienung

Barrierefreie Tastaturnavigation lässt sich auf fünf zentrale Kriterien herunterbrechen. Sie bilden zusammen das Fundament, an dem ein Audit die Tastaturbedienung misst. Drei davon sind bereits auf der Mindeststufe A verpflichtend, zwei weitere auf Stufe AA.

Kriterium	Stufe	Worum es geht
2.1.1 Tastatur	A	Jede Funktion per Tastatur bedienbar
2.1.2 Keine Tastaturfalle	A	Aus jedem Element wieder herauskommen
2.4.3 Fokus-Reihenfolge	A	Logische, sinnvolle Tab-Reihenfolge
2.4.7 Fokus sichtbar	AA	Sichtbare Markierung des Fokus
2.4.11 Fokus nicht verdeckt (Minimum)	AA	Fokus nicht hinter Inhalten versteckt

Das letzte Kriterium ist neu. Es kam erst mit WCAG 2.2 hinzu und schließt eine Lücke, die in der Praxis ständig auftrat. Die Details dieser Neuerungen behandle ich im Ratgeber zu den Neuerungen in WCAG 2.2. Zusammen ergeben diese fünf Regeln eine Seite, die sich vollständig ohne Maus bedienen lässt.

Erreichbar und bedienbar: native gegen eigene Elemente

Die meisten Tastaturprobleme entstehen aus einem einzigen Fehler. Entwickler bauen Bedienelemente aus den falschen Bausteinen. Ein echtes Button-Element und ein Link sind von Haus aus per Tastatur erreichbar und auslösbar. Ein <div> mit einem Klick-Handler dagegen ist es nicht.

Diese „div-Suppe“ ist tückisch. Mit der Maus funktioniert ein solches Pseudo-Element scheinbar einwandfrei. Mit der Tastatur erreicht man es jedoch nie, weil es nicht in der Tab-Reihenfolge liegt und auf Enter oder Leertaste nicht reagiert. Wer es dennoch nutzen will, muss tabindex="0", eine passende Rolle und eigene Tastatur-Handler ergänzen.

Mein Rat aus der Praxis ist deshalb einfach. Nutzen Sie native HTML-Elemente, wo immer es geht. Denn sie bringen Fokus, Rolle und Tastaturbedienung bereits mit, ganz ohne Zusatzcode. Wo Sie eigene Komponenten brauchen, hilft der Ratgeber zu ARIA in Webanwendungen weiter. Die Faustregel bleibt: erst nach nativen Elementen suchen, eigene erst dann, wenn es keine Alternative gibt.

Die Tastaturfalle vermeiden

Eine besonders ärgerliche Barriere ist die Tastaturfalle. Sie tritt auf, wenn ein Nutzer per Tabulator in ein Element hineinkommt, aber nicht wieder heraus. Das Erfolgskriterium 2.1.2 Keine Tastaturfalle (Stufe A) verbietet das ausdrücklich.

Die Ursachen sind fast immer dieselben. Ein selbst gebauter Dialog hält den Fokus fest, bietet aber keine Escape-Taste zum Schließen. Eine endlos nachladende Liste sorgt dafür, dass der Tabulator nie die Fußzeile erreicht. Oder ein eingebettetes Fremd-Widget in einem iframe schluckt den Fokus und gibt ihn nicht mehr her.

Hier lohnt eine wichtige Unterscheidung. Ein modaler Dialog soll den Fokus durchaus in sich halten – das ist gewollt. Entscheidend ist nur, dass man ihn jederzeit verlassen kann, in der Regel mit Escape, und dass der Fokus danach an die auslösende Stelle zurückkehrt. Eine Falle ist nicht das Festhalten, sondern das Fehlen eines Ausgangs. Genau diese Rückkehr des Fokus wird in der Praxis übrigens am häufigsten vergessen.

Die richtige Fokus-Reihenfolge

Die Reihenfolge, in der Elemente den Fokus erhalten, entscheidet über die Orientierung. Das Erfolgskriterium 2.4.3 Fokus-Reihenfolge (Stufe A) verlangt eine Reihenfolge, die Sinn und Bedienbarkeit erhält. In der Regel heißt das: Der Fokus folgt der visuellen Lese-Reihenfolge, also von oben nach unten und von links nach rechts.

Gestört wird diese Reihenfolge auf typische Weise. Ein positiver tabindex-Wert reißt einzelne Elemente aus der natürlichen Folge und gilt deshalb als Anti-Muster. Auch das Umsortieren per CSS ist tückisch: Wenn die Anzeige per Flexbox umgestellt wird, der Quelltext aber unverändert bleibt, springt der Fokus plötzlich quer über die Seite.

Vorbeugen lässt sich das mit klaren Regeln. Verlassen Sie sich auf die Reihenfolge im Quelltext und vermeiden Sie positive tabindex-Werte. Sorgen Sie zudem dafür, dass eingeklappte Menüs ihre Elemente erst dann fokussierbar machen, wenn sie geöffnet sind. Wie Quelltext und Anzeige zusammenhängen, vertiefe ich im Ratgeber zur DOM-Struktur.

Der sichtbare Fokus: das vergessene Detail

Kein Detail wird häufiger übersehen als die sichtbare Fokus-Markierung. Das Erfolgskriterium 2.4.7 Fokus sichtbar (Stufe AA) verlangt, dass stets erkennbar ist, wo der Fokus gerade steht. Genau dieses Kriterium gehört zu den am häufigsten verletzten überhaupt.

Der Klassiker unter den Fehlern ist eine einzige CSS-Zeile. Mit outline: none entfernen Entwickler den Fokusrahmen, weil er ihnen optisch nicht gefällt – und ersetzen ihn durch nichts. Für Tastaturnutzer wird die Seite damit unbrauchbar, weil sie nicht mehr sehen, wo sie sind. Die saubere Lösung nutzt :focus-visible und einen Rahmen mit ausreichendem Kontrast von mindestens 3:1. So erscheint die Markierung nur bei Tastaturbedienung und stört Mausnutzer nicht.

WCAG 2.2 hat diesen Bereich zusätzlich verschärft. Das neue Kriterium 2.4.11 Fokus nicht verdeckt (Minimum, Stufe AA) fordert, dass die fokussierte Stelle nicht vollständig hinter anderen Inhalten verschwindet – etwa hinter klebenden Kopfzeilen, Cookie-Bannern oder Chat-Fenstern. Auf höchster Stufe regelt 2.4.13 Fokus-Aussehen (AAA) sogar die Mindestgröße und den Kontrast der Markierung. Worauf es beim Kontrast ankommt, zeige ich im Ratgeber zu Farben und Kontrasten.

Fokus gezielt steuern: Dialoge und dynamische Inhalte

Sobald sich Inhalte dynamisch ändern, muss der Fokus aktiv gesteuert werden. Öffnet sich ein Dialog, gehört der Fokus hinein – meist auf das erste Bedienelement oder den Schließen-Knopf. Schließt er sich wieder, muss der Fokus an die Stelle zurückkehren, von der aus er geöffnet wurde.

In modernen Single-Page-Anwendungen ist das besonders wichtig. Wechselt die Ansicht, ohne dass die Seite neu lädt, verliert der Fokus sonst seinen Halt. Setzen Sie ihn deshalb gezielt auf eine sinnvolle Stelle, etwa die neue Hauptüberschrift, und kündigen Sie die Änderung über eine Statusmeldung an (4.1.3 Statusmeldungen).

Hilfreich ist das Verständnis der tabindex-Werte. Eine 0 nimmt ein Element in die natürliche Reihenfolge auf. Eine -1 macht es nur per Skript fokussierbar, etwa zur Orientierung beim Ansichtswechsel. Positive Werte dagegen sollten Sie meiden, weil sie die Reihenfolge durcheinanderbringen. Mit diesen drei Werten lässt sich der Fokus in fast jeder Situation sauber führen.

Sprunglinks und Tastenkürzel

Tastaturnutzer brauchen Abkürzungen, sonst wird das Tabben zur Tortur. Genau hier setzt das Erfolgskriterium 2.4.1 Blöcke umgehen (Stufe A) an. Es verlangt einen Mechanismus, um wiederkehrende Blöcke zu überspringen – in der Praxis ein Sprunglink „Zum Hauptinhalt springen“ gleich zu Beginn der Seite.

Ohne einen solchen Link wird es mühsam. Denn dann muss sich ein Tastaturnutzer auf jeder Unterseite erneut durch die komplette Navigation tabben, bevor er den eigentlichen Inhalt erreicht. Ein Sprunglink erspart ihm genau das und ist mit wenigen Zeilen umgesetzt.

Auch Tastenkürzel verdienen Beachtung. Reagiert eine Seite auf einzelne Buchstabentasten, kann das mit Hilfsmitteln kollidieren (2.1.4 Zeichentastenkürzel). Solche Kürzel müssen sich abschalten oder umlegen lassen. Und seit WCAG 2.2 gilt: Auch Ziehbewegungen brauchen eine Tastatur-Alternative (2.5.7 Schleppbewegungen).

Eigene Komponenten richtig per Tastatur bedienen

Wo Sie eigene Bedienelemente bauen, müssen Sie deren Tastaturverhalten selbst nachbilden. Denn Nutzer erwarten von einem Menü, einem Tab-Reiter oder einer Auswahlliste ein bestimmtes Verhalten. Und dieses Verhalten ist nicht beliebig, sondern in den ARIA-Mustern des W3C festgehalten.

Konkret heißt das je nach Komponente etwas anderes. In einem Menü oder einer Tab-Leiste bewegt man sich mit den Pfeiltasten, nicht mit dem Tabulator. Eine Akkordeon-Sektion öffnet und schließt man mit Enter oder Leertaste. Und eine Auswahlliste lässt sich mit den Pfeiltasten durchlaufen und mit Escape wieder schließen.

Ein bewährtes Muster dahinter ist der wandernde Fokus. Dabei trägt nur ein Element der Gruppe den Wert tabindex="0", alle anderen eine -1. So springt der Tabulator zur Gruppe als Ganzem, und die Pfeiltasten bewegen sich darin. Wer diese Konventionen einhält, baut Komponenten, die sich sofort vertraut anfühlen.

Tastaturbedienung in Formularen

Formulare sind der Ort, an dem Tastaturbedienung am häufigsten scheitert. Denn hier treffen viele Bedienelemente auf engem Raum zusammen. Mit dem Tabulator wandert man von Feld zu Feld, und native Felder wie Eingabe, Auswahl und Kontrollkästchen bringen ihr Verhalten von selbst mit.

Die Probleme beginnen bei eigenen Lösungen. Eine selbst gebaute Auswahlliste oder ein eigener Datumswähler ist oft eine klassische Tastaturfalle: Man kommt hinein, aber nicht sinnvoll heraus. Achten Sie deshalb darauf, dass jedes Feld erreichbar ist und auch jede Fehlermeldung den Fokus erhält, sobald sie erscheint.

Ein verstecktes Risiko ist zudem der automatische Sprung. Wenn das bloße Anspringen eines Feldes schon etwas auslöst oder gar abschickt, verwirrt das Tastaturnutzer (3.2.1 Bei Fokus). Vermeiden Sie das unbedingt. Mehr zur Gestaltung zeige ich im Ratgeber zu barrierefreien Formularen.

Tastaturnavigation auf mobilen Geräten

Ein verbreiteter Irrtum lautet: Auf dem Smartphone zählt nur der Touchscreen. Das stimmt nicht. Denn auch mobile Geräte werden per Tastatur bedient – über angeschlossene Bluetooth-Tastaturen oder über Schalter-Steuerungen für Menschen mit starken motorischen Einschränkungen.

Das Kriterium gilt deshalb überall. Auch auf Tablet und Smartphone muss jede Funktion ohne Maus und ohne Touch allein per Tastatur erreichbar sein. Eine Bedienung, die nur auf Wischen oder Tippen reagiert, schließt diese Nutzer aus.

Wichtig ist daher der durchgängige Blick. Prüfen Sie Ihre Anwendung nicht nur am Desktop, sondern auch auf dem mobilen Gerät mit externer Tastatur. Worauf es bei mobilen Angeboten sonst noch ankommt, vertiefe ich im Ratgeber zur mobilen Barrierefreiheit.

Häufige Tastatur-Barrieren in der Praxis

Über viele Audits hinweg wiederholen sich dieselben Fehler. Diese sieben sehe ich am häufigsten – und alle lassen sich beheben:

• Der falsche Baustein: ein <div> als Button statt eines echten Buttons.
• Unsichtbarer Fokus: outline: none ohne sichtbaren Ersatz.
• Positives tabindex, das die Reihenfolge durcheinanderbringt.
• Dialog ohne Ausgang: ein Modal, das sich nicht mit Escape schließt.
• Eigene Auswahllisten, die nicht mit Pfeiltasten bedienbar sind.
• Verlorener Fokus, der nach einer Aktion ins Nichts springt.
• Versteckt, aber fokussierbar: eingeklappte Menüs, in die man hineintabbt.

Auffällig ist dabei eines. Fast kein Fehler entsteht aus bösem Willen. Vielmehr entsteht er, weil mit der Maus entwickelt und getestet wird – und die Maus all diese Probleme schlicht überspringt.

Der Test, den jeder selbst machen kann

Sie müssen kein Entwickler sein, um die größten Tastaturprobleme zu finden. Ein simpler Test genügt.

Aus der Praxis – der Fünf-Minuten-Tab-Test: Legen Sie die Maus beiseite und bedienen Sie Ihre Seite nur mit der Tastatur. Drücken Sie wiederholt die Tabulatortaste und beobachten Sie genau fünf Dinge. Erstens: Erreichen Sie wirklich jedes Bedienelement, jeden Link, jedes Formularfeld? Zweitens: Sehen Sie zu jedem Zeitpunkt, wo der Fokus gerade steht? Drittens: Folgt die Reihenfolge der sichtbaren Anordnung, oder springt der Fokus quer? Viertens: Kommen Sie aus jedem Dialog und jedem Menü wieder heraus, notfalls mit Escape? Fünftens: Lässt sich jedes Element auch auslösen, mit Enter, Leertaste oder Pfeiltasten? Schon dieser Durchgang deckt die meisten Barrieren auf – kostenlos und ohne ein einziges Werkzeug. Wer ihn einmal gemacht hat, sieht seine Seite mit anderen Augen.

Warum Scanner hier an ihre Grenzen stoßen

Bei der Tastaturnavigation zeigt sich die Grenze automatischer Prüfung besonders deutlich. Denn von allen Fokus-Kriterien der WCAG 2.2 lässt sich nur ein einziges vollständig automatisiert testen – ausgerechnet das neue 2.4.11. Alles andere entzieht sich dem Scanner.

Der Grund liegt in der Natur der Sache. Ob man wirklich jedes Element erreicht, ob die Reihenfolge sinnvoll ist und ob man aus einem Dialog wieder herauskommt, lässt sich nur feststellen, indem ein Mensch sich tatsächlich durch die Seite tabbt. Ein Scanner erkennt eine fehlende Fokus-Markierung im Code vielleicht – ob die Bedienung in der Realität gelingt, erkennt er nicht.

Genau hier setzt unser Tiefen-Audit Access Ready an. Wir prüfen Ihre Tastaturbedienung manuell und mit echten Nutzern assistiver Technik – also genau so, wie Ihre Besucher die Seite wirklich erleben. Wo ein reiner Scan nur einen Bruchteil sieht, decken wir die tatsächlichen Hürden auf. So erhalten Sie kein theoretisches Ergebnis, sondern ein Bild der echten Bedienbarkeit.

Häufige Fragen zur Tastaturnavigation

Zum Abschluss die Fragen, die mir in der Praxis am häufigsten begegnen. Die Antworten fallen dabei kürzer aus, als viele erwarten.

Reicht es nicht, wenn die Seite mit der Maus funktioniert?

Nein. Denn blinde Menschen und viele mit motorischen Einschränkungen nutzen gar keine Maus. Was nur per Maus geht, ist für sie schlicht nicht vorhanden.

Darf ich den Fokusrahmen per CSS entfernen?

Nur, wenn Sie ihn ersetzen. Ein outline: none ohne sichtbare Alternative verstößt gegen 2.4.7 Fokus sichtbar. Sauberer ist :focus-visible mit ausreichendem Kontrast.

Sind positive tabindex-Werte erlaubt?

Erlaubt schon, sinnvoll selten. Denn sie reißen Elemente aus der natürlichen Reihenfolge und führen fast immer zu Verwirrung. Verlassen Sie sich besser auf die Reihenfolge im Quelltext.

So sichern Sie Ihre Tastaturnavigation ab

Der Weg beginnt bei einem schnellen Überblick und endet bei belastbarer Gewissheit. Eine erste Einschätzung liefert der kostenlose Access Score in Minuten. Er findet die messbaren Probleme, etwa fehlende Fokus-Stile oder Strukturfehler im Code.

Die eigentliche Tastaturprüfung braucht jedoch den Menschen. Mit Access Ready tabben sich unsere Prüfer durch Ihre gesamte Anwendung, testen jede Komponente und stellen am Ende ein rechtssicheres Zertifikat aus. Wo andere Anbieter Sie mit einem automatischen Bericht allein lassen, begleiten wir den Weg von der Analyse bis zum Nachweis.

Ansatz	Prüft Tastaturbedienung	Echte Nutzer	Nachweis
Reiner Scanner	nur Teilaspekte im Code	nein	nein
Overlay-Widget	kaschiert, behebt nicht	nein	nein
Access Ready (IFDB)	komplette Bedienung manuell	ja	ja

Der Unterschied liegt im Anspruch. Andere prüfen, was sich leicht messen lässt, und überlassen Ihnen den Rest. Wir prüfen, was wirklich zählt: ob ein Mensch Ihre Seite ohne Maus von Anfang bis Ende bedienen kann. So wird aus „sollte eigentlich funktionieren“ ein belegtes „funktioniert für alle“.