WCAG 2.4.3: Fokus-Reihenfolge

WCAG 2.4.3 verlangt, dass der Tastaturfokus die Elemente einer Seite in einer Reihenfolge durchläuft, die Bedeutung und Bedienbarkeit erhält – in aller Regel also der Lesereihenfolge folgt. Die drei Ursachen für Verstöße sind immer dieselben: per CSS umsortierte Layouts, positive tabindex-Werte und fehlendes Fokus-Management bei dynamischen Inhalten.

(Englisch: Focus Order.)

Das Wichtigste in Kürze

• Der Fokus folgt dem DOM, nicht der Optik. Wer per Flexbox oder Grid umsortiert, erzeugt eine Tab-Reihenfolge, die im Zickzack über den Bildschirm läuft.
• Positives tabindex ist praktisch immer ein Befund. Erlaubt sind nur tabindex="0" (fokussierbar machen) und tabindex="-1" (nur per Skript fokussierbar).
• Die Norm verlangt nicht „identisch zur visuellen Anordnung“, sondern „Bedeutung und Bedienbarkeit erhalten“. In der Praxis läuft das aufs Gleiche hinaus.
• Nach jeder dynamischen Änderung muss der Fokus bewusst gesetzt werden – Dialog auf, Dialog zu, Zeile gelöscht, Route gewechselt, „Mehr laden“ geklickt.
• Geschlossene Menüs und Off-Canvas-Panels bleiben ein Dauerthema: Sind sie nur optisch weggeschoben, tabbt man weiter hinein.
• Stufe A und über die EN 301 549 verbindlich; im BIK-BITV-Test heißt der Prüfschritt „2.4.3 Schlüssige Reihenfolge bei der Tastaturbedienung“.
• Automatisch prüfbar ist nur der tabindex-Teil. Ob eine Reihenfolge schlüssig ist, entscheidet ein Mensch mit der Tabulator-Taste.

In welcher Reihenfolge muss der Tab-Fokus laufen?

Der Normtext ist bewusst weich formuliert: Wenn eine Seite sequenziell navigiert werden kann und die Reihenfolge Bedeutung oder Bedienbarkeit beeinflusst, dann müssen fokussierbare Komponenten den Fokus in einer Reihenfolge erhalten, die Bedeutung und Bedienbarkeit erhält. Es steht dort ausdrücklich nicht, dass die Reihenfolge exakt der visuellen Anordnung entsprechen muss. Gemeint ist der Sinnzusammenhang – ein Beschriftungsfeld vor seinem Eingabefeld, eine Frage vor ihrer Antwortauswahl, ein Zustimmen-Knopf nach dem Text, dem zugestimmt wird.

Drei Praxisregeln decken das Kriterium ab:

1. DOM-Reihenfolge gleich Sinn-Reihenfolge. Der Fokus folgt dem Quelltext. Wer per CSS visuell umsortiert – order, flex-direction: row-reverse, explizite Grid-Positionen, float –, löst die beiden Reihenfolgen voneinander.
2. Kein positives tabindex. Werte ab 1 ziehen ein Element vor alle Elemente mit tabindex="0" – über die ganze Seite hinweg, auch über Kopf- und Fußbereich. Ein einziges tabindex="1" verschiebt damit die komplette Ordnung.
3. Fokus-Management bei Dynamik. Öffnet sich ein Dialog, wandert der Fokus hinein; schließt er, kehrt er zum auslösenden Element zurück. Erscheint neuer Inhalt, muss der Fokus sinnvoll weitergeführt werden – etwa bei „Mehr laden“.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.4.3; das deutsche Prüfvorgehen beschreibt der Prüfschritt „2.4.3 Schlüssige Reihenfolge bei der Tastaturbedienung“.

Wen betrifft es besonders?

Tastatur- und Switch-Nutzer haben keine Möglichkeit, einen Sprung zu korrigieren, außer weiterzutabben oder von vorn zu beginnen. Bei Switch-Bedienung mit Scanning kommt hinzu, dass jeder zusätzliche Schritt Zeit kostet – ein Zickzack durch ein zwölfteiliges Formular verdoppelt schnell die Bearbeitungsdauer.

Menschen mit Bildschirmvergrößerung folgen dem Fokus mit ihrem Ausschnitt. Springt er quer über die Seite, springt der Ausschnitt mit – und man weiß nicht mehr, wo man ist. Für diese Gruppe ist eine unsaubere Fokusreihenfolge oft schlimmer als für Screenreader-Nutzer, weil ihnen der Kontext um den Fokus herum fehlt.

Screenreader-Nutzer merken den Bruch vor allem in Formularen: Wenn Beschriftung und Feld auseinanderfallen, hört man ein Label ohne zugehöriges Eingabefeld – und rät.

Richtig & falsch im Code

<!-- Falsch: positive tabindex-Werte „reparieren“ die Optik -->
<input tabindex="3" id="ort" />
<input tabindex="1" id="name" />
<input tabindex="2" id="plz" />

<!-- Richtig: DOM in Sinn-Reihenfolge, kein tabindex nötig -->
<input id="name" />
<input id="plz" />
<input id="ort" />

/* Falsch: Optik umsortiert, DOM bleibt wie es war */
.formular { display: flex; flex-direction: column; }
.feld-name { order: 1; }
.feld-ort  { order: 3; }
.feld-plz  { order: 2; }

/* Richtig: Reihenfolge im HTML ändern, CSS ordnet nur an */
.formular { display: grid; grid-template-columns: 1fr 1fr; }

order und explizite Grid-Positionen sind nicht generell verboten – sie sind unbedenklich, solange sie nur Zeilen oder Blöcke umstellen, die keine Reihenfolgebeziehung haben. Sobald sie fokussierbare Elemente betreffen, wird es kritisch.

// Richtig: Fokus-Rückgabe beim Schließen eines Dialogs
const ausloeser = document.activeElement;
dialog.showModal();
dialog.addEventListener('close', () => ausloeser.focus());

// Richtig: Fokus nach dem Löschen einer Tabellenzeile weiterführen
function zeileLoeschen(zeile) {
  const naechste = zeile.nextElementSibling ?? zeile.previousElementSibling;
  zeile.remove();
  (naechste?.querySelector('button') ?? tabelle).focus();
}

Dieser zweite Fall wird selten bedacht und fällt im Test sofort auf: Wird das Element mit dem Fokus entfernt, landet der Fokus am <body> – der nächste Tabulator-Druck beginnt wieder ganz oben auf der Seite.

<!-- Richtig: Hintergrund während eines Overlays stilllegen -->
<main inert>…</main>
<div role="dialog" aria-modal="true">…</div>

Das inert-Attribut nimmt einen ganzen Teilbaum aus der Tabulator-Reihenfolge und aus dem Zugriffsbaum – seit 2023 in allen aktuellen Browsern verfügbar und die sauberste Lösung für Off-Canvas-Menüs und eigene Overlays. Beim nativen <dialog>-Element mit showModal() erledigt der Browser das bereits selbst.

So testest du es

1. Kompletten Tabulator-Durchlauf machen, von der Adresszeile bis zum Seitenende, und dabei auf den sichtbaren Fokus achten. Folgt er der Lesereihenfolge, ohne zu springen und ohne Elemente auszulassen?
2. Rückwärts prüfen mit Umschalt + Tabulator. Die Reihenfolge muss in beide Richtungen dieselbe sein – bei eigenem Fokus-Management stimmt oft nur eine.
3. Im Quelltext nach tabindex= suchen. Jeder Wert ab 1 ist ein Befund, ohne Wenn und Aber.
4. Overlays durchspielen: Dialog öffnen, mit dem Tabulator kreisen, schließen – und prüfen, ob der Fokus wieder auf dem Auslöser sitzt. Dasselbe mit dem mobilen Menü.
5. Geschlossene Bereiche kontrollieren. Bei zugeklapptem Menü, geschlossenem Akkordeon und ausgeblendetem Tab-Panel darf der Fokus nicht hineinlaufen.
6. Dynamik testen: Zeile löschen, „Mehr laden“ klicken, Filter setzen, Route wechseln. Nach jeder Aktion in der Konsole document.activeElement abfragen – das zeigt schwarz auf weiß, wo der Fokus gelandet ist.

Häufiger Fehler in der Praxis

Der häufigste Befund ist das optisch weggeschobene Menü. Das Off-Canvas-Panel liegt mit transform: translateX(-100%) außerhalb des Bildschirms, ist aber weiter fokussierbar. Wer tabbt, wandert plötzlich durch unsichtbare Links – der Fokusring ist nicht zu sehen, die Seite scrollt seltsam, und niemand versteht, was los ist. Das ist gleichzeitig ein Verstoß gegen 2.4.7 Fokus sichtbar. Die Lösung ist ein zusätzliches inert oder visibility: hidden im geschlossenen Zustand, nicht nur die Verschiebung.

Der zweite ist das Kartenraster mit order. Im Design sollte die Hervorhebungskarte in der Mitte stehen, im HTML steht sie an erster Stelle, und per order: 2 rutscht sie optisch dorthin. Auf dem Desktop merkt das niemand; mit der Tastatur springt der Fokus zuerst in die Mitte, dann nach links, dann nach rechts. Ich würd solche Umsortierungen grundsätzlich im HTML machen und CSS nur das Anordnen überlassen – dann kann der Fall gar nicht auftreten.

Der dritte ist der Suchvorschlag ohne Fokus-Plan: Man tippt, eine Vorschlagsliste erscheint unterhalb des Feldes, und der nächste Tabulator-Druck landet nicht in der Liste, sondern beim Suchknopf. Comboboxen brauchen deshalb eine eigene Tastaturlogik mit Pfeiltasten statt Tabulator – das Muster steht unter Comboboxen & Autocomplete.

Häufige Fragen

Muss die Fokusreihenfolge exakt der visuellen Anordnung entsprechen?

Nicht wörtlich. Die Norm verlangt, dass Bedeutung und Bedienbarkeit erhalten bleiben. Bei mehrspaltigen Layouts kann es legitim sein, erst die Hauptspalte und danach die Randspalte zu durchlaufen, auch wenn sie nebeneinanderstehen. Unzulässig wird es, sobald zusammengehörige Elemente auseinandergerissen werden – etwa Beschriftung und Eingabefeld.

Ist tabindex="0" erlaubt?

Ja. tabindex="0" nimmt ein Element in die natürliche Reihenfolge auf, ohne sie zu verändern – nötig zum Beispiel bei eigenen Bedienelementen oder scrollbaren Containern. Problematisch sind nur Werte ab 1, weil sie eine eigene Vorrangordnung über die ganze Seite legen.

Wohin gehört der Fokus nach dem Absenden eines Formulars?

Bei Fehlern auf die Fehlerzusammenfassung am Formularanfang, damit Umfang und Art der Fehler sofort klar sind. Bei Erfolg auf die Überschrift der Bestätigung. In beiden Fällen braucht das Zielelement tabindex="-1". Wie die Meldung zusätzlich angesagt wird, regelt 4.1.3 Statusmeldungen.

Was ist der Unterschied zu 1.3.2 Bedeutungstragende Reihenfolge?

1.3.2 betrifft die Lesereihenfolge – also die Reihenfolge, in der ein Screenreader den gesamten Inhalt durchgeht, auch nicht fokussierbaren Text. 2.4.3 betrifft nur die Fokusreihenfolge der bedienbaren Elemente. Beide haben dieselbe Wurzel im DOM, weshalb eine CSS-Umsortierung meistens beide Kriterien gleichzeitig verletzt.

Wie prüfe ich die Fokusreihenfolge auf einer langen Seite effizient?

Mit einem Skript statt mit Geduld: In der Konsole alle fokussierbaren Elemente einsammeln und in DOM-Reihenfolge nummerieren lassen, dann die Nummern mit der optischen Anordnung vergleichen. Für den täglichen Gebrauch tut es auch die Fokusreihenfolge-Ansicht der Accessibility Insights-Erweiterung, die den Weg als Linie einzeichnet.

Verwandte Themen

• 1.3.2 Bedeutungstragende Reihenfolge – dieselbe Wurzel im DOM
• 2.4.7 Fokus sichtbar – man muss die Reihenfolge auch sehen
• 2.1.2 Keine Tastaturfalle – der Nachbar, wenn der Fokus nicht mehr herauskommt
• Dialoge & Modals – Fokus-Management als fertiges Muster
• Tastatur & Fokus – der Praxis-Leitfaden zum Thema