tabindex-Attribut: Tastaturfokus gezielt steuern

Kurz erklärt: Das HTML-Attribut <code>tabindex</code> steuert, ob und in welcher Reihenfolge ein Element per Tastatur fokussierbar ist. Es ist zentral für WCAG 2.1 Kriterium 2.1.1 (Tastatur) und 2.4.3 (Fokusreihenfolge) sowie die Anforderungen des BFSG.

Das <code>tabindex</code>-Attribut ist eines der wichtigsten Werkzeuge für die Tastaturzugänglichkeit. Es bestimmt, ob ein HTML-Element in die Tab-Reihenfolge aufgenommen wird und ob es programmatisch fokussiert werden kann. Richtig eingesetzt ermöglicht es barrierefreie Custom Controls; falsch eingesetzt zerstört es die natürliche Navigationsreihenfolge und kann Keyboard Traps verursachen. Das BFSG und EN 301 549 Abschnitt 11.2.1.1 fordern, dass alle Funktionalitäten per Tastatur erreichbar sein müssen – <code>tabindex</code> ist der Schlüssel dazu.

tabindex="0" – Element in die Tab-Reihenfolge aufnehmen

Mit tabindex="0" wird ein Element in die natürliche Tab-Reihenfolge des Dokuments eingefügt. Das Element erscheint an der Stelle in der Fokusreihenfolge, die seiner Position im DOM entspricht. Dies ist besonders wichtig für Custom Controls: Ein <div> oder <span>, das als Button fungiert, ist standardmäßig nicht fokussierbar. Erst durch tabindex="0" wird es per Tastatur erreichbar. Wichtig: Zusätzlich zu tabindex="0" benötigen Custom Controls immer eine passende ARIA-Rolle (z. B. role="button") und Keyboard-Event-Handler für Enter und Leertaste. Gemäß WCAG 2.1 Kriterium 4.1.2 (Name, Rolle, Wert) muss jedes interaktive Element seinen Zustand korrekt kommunizieren. Native HTML-Elemente wie <button> oder <a href> haben tabindex="0" implizit – hier ist das Attribut überflüssig. Verwenden Sie tabindex="0" nur dann, wenn Sie nicht-interaktive Elemente interaktiv machen müssen und kein passendes natives Element existiert.

tabindex="-1" – Programmatischer Fokus ohne Tab-Reihenfolge

Ein Element mit tabindex="-1" wird aus der Tab-Reihenfolge entfernt, kann aber weiterhin per JavaScript mit element.focus() fokussiert werden. Dieses Muster ist unverzichtbar für das Fokus-Management in Single-Page-Applications und dynamischen Inhalten. Typische Anwendungsfälle sind: Fehlermeldungen – nach dem Absenden eines Formulars den Fokus auf die Fehlerzusammenfassung setzen. Skip-Link-Ziele – der Hauptinhalt erhält tabindex="-1", damit der Skip-Link dorthin fokussieren kann. Modal-Dialoge – beim Öffnen eines Dialogs den Fokus auf den Dialog-Container setzen. SPA-Routenwechsel – nach einem Seitenwechsel den Fokus auf die neue Überschrift setzen (WCAG 2.4.3). EN 301 549 Abschnitt 11.2.4.3 verlangt eine sinnvolle Fokusreihenfolge – tabindex="-1" ist das Werkzeug, um Fokus gezielt zu lenken, ohne die Tab-Reihenfolge zu verändern.

Positive tabindex-Werte – das Anti-Pattern

Werte wie tabindex="1", tabindex="5" oder tabindex="100" setzen das Element vor alle Elemente mit tabindex="0" in der Fokusreihenfolge. Elemente mit niedrigerem positivem Wert kommen zuerst. Dies ist ein Anti-Pattern und sollte niemals verwendet werden. Die Gründe: Positive Werte erzeugen eine Fokusreihenfolge, die nicht der visuellen Reihenfolge entspricht – ein direkter Verstoß gegen WCAG 2.4.3 (Fokusreihenfolge). Bei mehreren Entwicklern entstehen schnell Konflikte zwischen den Werten. Die Wartbarkeit sinkt dramatisch, da jede DOM-Änderung die gesamte Fokusreihenfolge beeinflussen kann. Browser-Erweiterungen und Screenreader können verwirrt werden. Die korrekte Lösung ist immer, die DOM-Reihenfolge so zu strukturieren, dass sie der gewünschten Fokusreihenfolge entspricht, und ausschließlich tabindex="0" und tabindex="-1" zu verwenden.

Keyboard Traps vermeiden – WCAG 2.1.2

Eine Keyboard Trap entsteht, wenn ein Nutzer per Tastatur in ein Element hinein, aber nicht wieder heraus navigieren kann. WCAG 2.1 Kriterium 2.1.2 (Keine Tastaturfalle) verbietet dies explizit. Häufige Ursachen sind: Eingebettete Inhalte wie iframes oder Flash-Objekte, die den Fokus nicht zurückgeben. Schlecht implementierte Custom Widgets, bei denen Tab ins Element führt, aber kein Event-Handler den Fokus wieder freigibt. Modals ohne Escape-Handler, die weder Escape-Taste noch Tab-Navigation nach draußen erlauben. Die Lösung: Testen Sie jedes interaktive Element, indem Sie nur mit der Tastatur (Tab, Shift+Tab, Escape, Pfeiltasten) navigieren. Jedes Element muss verlassbar sein. Für Modale Dialoge ist Focus Trapping gewollt – aber mit einer klaren Escape-Möglichkeit (Escape-Taste, Schließen-Button). Das BFSG fordert gemäß EN 301 549 Abschnitt 11.2.1.2 die Abwesenheit von Keyboard Traps als Grundvoraussetzung.

Best Practices und Praxistipps

Folgen Sie diesen Regeln für korrekten tabindex-Einsatz: 1. Bevorzugen Sie native HTML-Elemente. Ein <button> ist immer besser als ein <div tabindex="0" role="button">. 2. Verwenden Sie nur 0 und -1. Positive Werte sind ein Code Smell. 3. Testen Sie die Tab-Reihenfolge manuell. Drücken Sie Tab durch die gesamte Seite und prüfen Sie, ob die Reihenfolge logisch ist. 4. Fokus-Stile beibehalten. Entfernen Sie niemals outline: none ohne Ersatz – WCAG 2.4.7 (Sichtbarer Fokus) verlangt einen sichtbaren Fokusindikator. 5. Dynamische Inhalte: Wenn Sie Elemente per JavaScript einfügen, stellen Sie sicher, dass fokussierbare Elemente in der richtigen Reihenfolge im DOM stehen. Automatisierte Tools wie bf-check erkennen positive tabindex-Werte und fehlende Fokusindikatoren, aber manuelle Tests der Tab-Reihenfolge bleiben unverzichtbar.

Wird geprüft: bf-check erkennt positive tabindex-Werte (Anti-Pattern), fehlende Fokusindikatoren (outline: none ohne Alternative) und prüft, ob Custom Controls mit tabindex="0" eine passende ARIA-Rolle besitzen.

Wie steht deine Webseite in diesem Punkt da?

Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. tabindex-Check.

Jetzt Webseite prüfen →

Ratgeber zum Thema

Tastatur Bedienbarkeit Testen → Wcag 2 1 Einfach Erklaert → Barrierefreie Navigation Menu →