Was ist die Tastaturnavigationsreihenfolge?

Was ist die Tastaturnavigationsreihenfolge?

Die Tastaturnavigationsreihenfolge, auch Tab-Reihenfolge oder Fokusreihenfolge genannt, ist die Abfolge, in der Links, Buttons und Formularfelder den Fokus erhalten, wenn jemand die Tab-Taste drückt. Sie sollte zu Bedeutung und visuellem Ablauf der Seite passen. WCAG 2.4.3 Fokusreihenfolge (Stufe A) verlangt, dass fokussierbare Komponenten den Fokus in einer Reihenfolge erhalten, die Bedeutung und Bedienbarkeit bewahrt.

So funktioniert sie

Standardmäßig folgt die Reihenfolge dem HTML-Quelltext. Nativ fokussierbare Elemente wie Links mit href, Buttons, Eingabefelder, Auswahllisten, Textareas, iframes und summary-Elemente werden in der Reihenfolge besucht, in der sie im Dokument stehen. Drei Dinge ändern das (siehe MDN zu tabindex):

• tabindex="0" macht ein Element in Quelltextreihenfolge per Tab erreichbar.
• tabindex="-1" nimmt es aus der Tab-Folge, lässt aber einen Skript-Fokus zu, passend für ein sich öffnendes Modal oder eine Fehlermeldung nach einem fehlgeschlagenen Absenden.
• Ein positiver tabindex zieht das Element vor alles andere. MDN empfiehlt nur 0 und -1, weil positive Werte und CSS, das fokussierbare Elemente umordnet, die Navigation für Tastatur- und Hilfstechnologie-Nutzer erschweren.

Die Falle: CSS kann Elemente optisch verschieben (Flexbox-Reihenfolge, Grid, absolute Positionierung), während der Fokus weiter dem Quelltext folgt. Dann springt der Fokus über den Bildschirm.

Die zugehörigen WCAG-Kriterien

Die Tastaturreihenfolge gehört zu einer kleinen Gruppe von Kriterien der Web Content Accessibility Guidelines (Quelle: Understanding-Dokumente des W3C zu WCAG 2.2):

• 2.1.1 Tastatur (A): Alle Funktionen sind über eine Tastaturschnittstelle bedienbar, mit engen Ausnahmen für pfadabhängige Eingaben wie freihändiges Zeichnen.
• 2.1.2 Keine Tastaturfalle (A): Lässt sich der Fokus per Tastatur in eine Komponente bewegen, lässt er sich auch per Tastatur wieder herausbewegen; braucht es mehr als Tab oder Pfeiltasten, wird der Nutzer informiert.
• 2.4.3 Fokusreihenfolge (A): Die Reihenfolge bewahrt Bedeutung und Bedienbarkeit. Sie muss nicht dem visuellen Layout entsprechen, darf aber nicht zufällig springen.
• 2.4.7 Fokus sichtbar (AA): Der Tastaturfokus ist sichtbar.
• 2.4.11 Fokus nicht verdeckt, Minimum (AA, neu in WCAG 2.2): Eine fokussierte Komponente wird nicht vollständig von Inhalten des Autors verdeckt, etwa von einer fixierten Kopfzeile oder einem Cookie-Banner.

Beispiel: ein Bestellformular

Ein Formular zeigt Name, Adresse und Kartennummer untereinander, doch eine CSS-Regel platziert den Button Bezahlen optisch unten, während er im HTML an erster Stelle steht. Wer per Tastatur von oben tabbt, landet auf Bezahlen, bevor etwas ausgefüllt ist. Die Lösung: die Elemente im HTML in der Reihenfolge anordnen, in der Menschen sie nutzen, statt tabindex-Werte zu vergeben. Verdeckt eine fixierte Kopfzeile das fokussierte Feld beim Abwärts-Tabben, ergänzen Sie scroll-padding, damit das Feld sichtbar bleibt.

Häufige Fehler

• Reihenfolge mit positivem tabindex reparieren. Das erzeugt eine zweite, versteckte Ordnung, die bricht, sobald jemand ein Feld ergänzt.
• Fokusrahmen ausblenden. Wer den Outline ohne Ersatz entfernt, verfehlt Fokus sichtbar.
• Klickbare divs. Ein div mit Klick-Handler ist nicht fokussierbar. Nutzen Sie Button oder Link; ARIA-Rollen fügen von selbst kein Tastaturverhalten hinzu.
• Modals, die den Fokus verlieren oder festhalten. Fokus beim Öffnen in den Dialog setzen, ihn dort halten, per Tastatur schließbar machen und danach zum Auslöser zurückgeben.
• Verdeckte Inhalte, die tabbar bleiben. Optisch versteckte, aber fokussierbare Menüs lassen den Fokus verschwinden.
• Nur mit der Maus testen. Reihenfolgeprobleme zeigen sich erst, wenn man Tab drückt.

Tastaturreihenfolge, Tests und Monitoring

Der Test ist manuell: Maus weglegen, mit Tab und Umschalt+Tab durch die Seite gehen und prüfen, ob jedes Element erreichbar ist, der Fokus immer sichtbar bleibt und die Reihenfolge Sinn ergibt. Ein Durchgang mit einem Screenreader zeigt dieselbe Struktur aus zweiter Sicht. Automatische Audits finden fehlende Beschriftungen und manche Fokusprobleme, beurteilen aber nicht, ob die Reihenfolge sinnvoll ist; lesen Sie dazu unseren Beitrag, warum Performance-Tests Barrierefreiheit einschließen sollten. Gegen Rückschritte hilft LoadFocus Page Speed Monitoring: geplante Lighthouse-Audits, die neben der Performance auch den Accessibility-Wert verfolgen. Ergänzen Sie das um einen manuellen Tab-Test wichtiger Seiten und lesen Sie, wie ein barrierefreies Layout aufgebaut wird.

Häufige Fragen: Tastaturnavigationsreihenfolge

Was ist die Standard-Tab-Reihenfolge?

Die Reihenfolge der fokussierbaren Elemente im HTML-Quelltext. Die optische Position spielt keine Rolle, weshalb CSS-Umordnungen verwirrende Fokussprünge verursachen können.

Sollte ich je einen positiven tabindex verwenden?

Fast nie. MDN empfiehlt nur 0 und -1. Ordnen Sie stattdessen das HTML logisch an.

Welche WCAG-Kriterien betreffen die Tastaturnavigation?

Die wichtigsten sind 2.1.1 Tastatur, 2.1.2 Keine Tastaturfalle, 2.4.3 Fokusreihenfolge, 2.4.7 Fokus sichtbar und, in WCAG 2.2, 2.4.11 Fokus nicht verdeckt (Minimum). Die ersten drei gehören zu Stufe A, die letzten beiden zu Stufe AA.

Was ist eine Tastaturfalle?

Eine Komponente, in die der Tastaturfokus gelangt, aus der er sich aber nicht allein per Tastatur lösen lässt, zum Beispiel ein schlecht gebautes eingebettetes Widget. WCAG 2.1.2 verbietet das.

Muss die Fokusreihenfolge der visuellen Reihenfolge entsprechen?

Nicht genau. WCAG verlangt eine Reihenfolge, die Bedeutung und Bedienbarkeit bewahrt, und es können mehrere gültig sein. Sie sollte trotzdem logisch wirken und nicht springen.