WCAG 2.1.2: Keine Tastaturfalle

WCAG 2.1.2 verlangt, dass der Tastaturfokus jeden Bereich, den er erreichen kann, auch wieder verlassen kann – allein mit der Tastatur. Reichen dafür Tab und Shift+Tab nicht aus, muss dem Nutzer vorher gesagt werden, mit welcher Taste er wieder herauskommt.

(Englisch: No Keyboard Trap. Der BIK-BITV-Test führt den Prüfschritt unter demselben Namen „Keine Tastaturfalle“.)

Das Wichtigste in Kürze

• Hineinkommen ist erlaubt, Steckenbleiben nicht. Jeder fokussierbare Bereich braucht einen Ausgang über die Tastatur.
• Der Fokus-Kreis in einem modalen Dialog ist keine Falle, solange sich der Dialog per Esc oder über einen erreichbaren Schließen-Knopf verlassen lässt.
• Sonderfall Sondertaste: Wenn ein Bereich Tab für sich beansprucht – etwa ein Code-Editor –, ist das zulässig, sofern der Ausweg vorher angesagt wird.
• Der häufigste Verstoß sind eingebettete Fremdinhalte: Chat-Widgets, Kartendienste, Videoplayer, Werbe-iframes.
• Fallen sind oft einseitig: Vorwärts kommt man durch, rückwärts nicht. Ohne Shift+Tab-Durchlauf findet man diese Hälfte nicht.
• Der BITV-Test prüft in Firefox und Chrome mit aktiviertem JavaScript, weil die meisten Fallen aus Skripten entstehen.
• 2.1.2 gilt seitenweit: Es ist eines der Kriterien, die auch dann verletzt sind, wenn die Falle in einem Teil steckt, der selbst gar nicht konform sein müsste.
• Für Mausnutzer ist die Falle unsichtbar – man klickt einfach woanders hin. Deshalb überlebt sie oft jahrelang unbemerkt.

Was ist eine Tastaturfalle?

Der Normtext ist knapp: Wenn sich der Fokus über die Tastatur auf einen Bestandteil bewegen lässt, muss er sich auch wieder wegbewegen lassen. Reichen dafür die üblichen Tasten nicht – Tab, Shift+Tab, Pfeiltasten –, muss der Nutzer vorher erfahren, welche Taste ihn befreit.

Dieses „vorher“ ist der Teil, der übersehen wird. Ein Editor, der Tab abfängt, um Code einzurücken, ist kein Verstoß: Er wird zu einem, wenn nirgends steht, dass Esc gefolgt von Tab hinausführt. Der Hinweis muss dort stehen, wo man ihn liest, bevor man drin ist – also im sichtbaren Text vor dem Element oder in einer Beschreibung, die per aria-describedby verknüpft ist.

Historisch stammt das Kriterium aus der Zeit der Plugins: Flash-Filme und Java-Applets schluckten den Fokus und gaben ihn nicht zurück. Die Technik ist verschwunden, das Muster nicht. Heute entstehen Fallen an drei Stellen:

• Eingebettete Fremdinhalte. Ein Chat-Widget, ein Kartendienst, ein Videoplayer oder ein Werbe-iframe fängt Tastenereignisse ab und gibt den Fokus nicht weiter. Man kommt hinein, aber nicht hindurch.
• Selbstgebaute Fokusverwaltung. Skripte, die den Fokus zurückholen, sobald er ein Element verlässt – meist gut gemeint als Validierung: „Bitte erst dieses Feld korrekt ausfüllen.“
• Halbfertige Dialog-Nachbauten. Ein <div> mit role="dialog", um das jemand einen Fokus-Kreis programmiert hat, ohne dass Esc schließt oder der Schließen-Knopf im Kreis liegt.

Wichtig zur Abgrenzung: Der Fokus-Kreis in einem modalen Dialog ist erwünscht. Solange der Dialog offen ist, soll Tab darin bleiben – sonst landet man hinter dem Dialog in Inhalten, die visuell gar nicht bedienbar sind. Zur Falle wird er erst, wenn es keinen Weg gibt, den Dialog selbst zu schließen.

Ein weiterer Punkt betrifft die Konformitätsbedingungen: 2.1.2 gehört zu den wenigen Kriterien, die nicht auf konformen Inhalt beschränkt sind. Eine Tastaturfalle in einem eingebetteten Drittanbieter-Element macht die gesamte Seite nicht konform, auch wenn dieses Element selbst nicht Teil der Prüfung wäre.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.1.2; das deutsche Prüfvorgehen beschreibt der Prüfschritt 2.1.2 des BIK BITV-Tests.

Wen betrifft es besonders?

Alle, die ohne Maus arbeiten. Für sie endet die Seite an der Falle – nicht im übertragenen Sinn, sondern wörtlich: Der Rest des Dokuments ist ab diesem Punkt nicht mehr erreichbar. Wer den Weg über die Tastatur nimmt, hat keine Umgehung; der Klick woanders hin, mit dem Mausnutzer das Problem lösen, existiert nicht.

Screenreader-Nutzer haben eine Teilrettung: In der Regel können sie mit dem virtuellen Cursor weiter durch das Dokument lesen. Sobald sie aber etwas bedienen wollen und in den Fokusmodus wechseln, sitzen sie in derselben Falle.

Am härtesten trifft es Menschen mit Switch- oder Kopfsteuerung. Ihre Eingabe ist im Kern ein automatisch weiterlaufender Tab-Durchlauf – landet der in einer Schleife, hilft nur noch, die Seite zu verlassen und neu zu laden.

Und schließlich betrifft es alle, die aus Gewohnheit über die Tastatur arbeiten: Formularprofis, die den Tab-Weg auswendig kennen, Nutzer mit Spracheingabe, Menschen mit einer vorübergehend gebrochenen Hand.

Richtig & falsch im Code

Der Klassiker unter den selbstgebauten Fallen ist der Fokus, der zurückgeholt wird:

// Falsch: der Fokus wird zwanghaft festgehalten
input.addEventListener('blur', () => {
  if (!input.checkValidity()) input.focus();
});

// Richtig: Fehler anzeigen, Fokus lassen, wo er ist
input.addEventListener('blur', () => {
  fehlerFeld.textContent = input.validationMessage;
  input.setAttribute('aria-invalid', String(!input.checkValidity()));
});

Bei Dialogen erspart das native Element die gesamte Fokusverwaltung – Fokus-Kreis und Esc-Ausgang sind eingebaut, und der Fokus kehrt beim Schließen zum auslösenden Knopf zurück:

<!-- Richtig: natives dialog-Element mit showModal() -->
<button type="button" id="oeffnen">Newsletter abonnieren</button>

<dialog id="newsletter" aria-labelledby="nl-titel">
  <h2 id="nl-titel">Newsletter abonnieren</h2>
  <form method="dialog">
    <label for="mail">E-Mail-Adresse</label>
    <input id="mail" type="email" name="mail" required />
    <button value="ok">Anmelden</button>
    <button value="abbruch">Abbrechen</button>
  </form>
</dialog>

oeffnen.addEventListener('click', () => newsletter.showModal());

Wenn ein Bereich Tab wirklich für sich braucht, gehört der Ausweg angesagt – und zwar sichtbar, nicht nur für den Screenreader:

<!-- Richtig: Tab bleibt im Editor, der Ausgang ist beschrieben -->
<p id="editor-hinweis">
  Im Editor fügt <kbd>Tab</kbd> eine Einrückung ein.
  Mit <kbd>Esc</kbd> und danach <kbd>Tab</kbd> verlassen Sie das Feld.
</p>
<div id="editor" role="textbox" contenteditable="true" tabindex="0"
     aria-describedby="editor-hinweis"></div>

Für eingebettete Fremdinhalte gilt: Was du nicht selbst reparieren kannst, musst du ersetzen oder umgehen. Ein Chat-Widget, das den Fokus hält, kann man hinter einen eigenen Knopf legen, der es erst auf Anforderung lädt – dann liegt es nicht im Standard-Tab-Weg. Die Muster dafür stehen unter Dialoge & Modals.

So testest du es

1. Einmal komplett vorwärts durchtabben. Von der Adressleiste bis wieder zurück in die Adressleiste. Wer die Runde nicht schließt, hat eine Falle gefunden – oder eine sehr lange Seite.
2. Denselben Weg rückwärts. Mit Shift+Tab. Fallen sind häufig einseitig: Der Player lässt vorwärts durch, aber nicht zurück.
3. In Firefox und Chrome prüfen. Der BITV-Test verlangt beide ausdrücklich, weil Fokusverwaltung in Skripten browserabhängig fehlschlägt. Safari lohnt sich als dritter Durchgang, wenn die Zielgruppe Apple-Geräte nutzt.
4. Jedes Overlay einzeln öffnen und schließen: Cookie-Banner, Suchdialog, Bildergalerie, Warenkorb-Klappe, Filterleiste. Schließt Esc? Ist der Schließen-Knopf im Fokus-Kreis erreichbar?
5. Fremdinhalte gezielt betreten. Karten, Videoplayer, Chat, Terminbuchung, Bezahl-iframes. Das sind die Stellen, an denen die Falle am längsten unbemerkt bleibt, weil sie niemand im eigenen Code sucht.
6. Bei Verdacht die Pfeiltasten probieren. Der BITV-Test sieht das ausdrücklich vor: Wenn Tab nicht weiterhilft, prüfen, ob Pfeiltasten oder eine dokumentierte Sondertaste hinausführen. Nur wenn auch das scheitert, ist es eine Falle.

Häufiger Fehler in der Praxis

Der Befund, den ich am häufigsten sehe, ist das Cookie-Banner ohne Esc. Es liegt über allem, hält den Fokus fest – so weit richtig –, aber Esc tut nichts, und „Einstellungen“ öffnet eine zweite Ebene, aus der es keinen Rückweg gibt. Das ist die schlimmste Stelle für eine Falle, weil sie vor dem Inhalt sitzt: Wer hier hängen bleibt, sieht von der Website nie etwas. Muster dafür stehen unter Cookie-Banner.

Der zweite ist das Chat-Widget, das nachträglich per Skript eingebunden wird. Es kommt vom Dienstleister, niemand im Projekt hat den Code, und im Tab-Weg liegt es meist ganz am Ende – also da, wo beim Testen die Aufmerksamkeit nachlässt. Ich würd dir raten, solche Widgets grundsätzlich als Letztes zu prüfen und dabei bewusst langsam zu machen.

Der dritte ist eine Verwechslung, kein Fehler: Ein endlos nachladender Feed, bei dem man den Footer per Tab nie erreicht, ist keine Tastaturfalle im Sinne von 2.1.2 – der Fokus bleibt ja nirgends stehen. Das ist ein Fall für 2.4.1 Blöcke umgehen und für 2.4.3 Fokus-Reihenfolge. Die Unterscheidung ist im Prüfbericht wichtig, weil sie über die Einordnung des Mangels entscheidet.

Häufige Fragen

Ist der Fokus-Kreis in einem Modal ein Verstoß?

Nein, im Gegenteil – er ist erwünscht. Solange ein modaler Dialog offen ist, soll der Fokus darin bleiben, damit niemand versehentlich in den verdeckten Inhalt dahinter gerät. Ein Verstoß entsteht erst, wenn der Dialog sich nicht mehr über die Tastatur schließen lässt. Das native <dialog> mit showModal() löst beides in einem Zug.

Zählt es als Falle, wenn ich zum Verlassen Esc drücken muss?

Nur, wenn das nirgends steht. Der Normtext lässt Sondertasten ausdrücklich zu, verlangt aber, dass der Nutzer vorher darüber informiert wird. Praktisch heißt das: ein sichtbarer Hinweis vor oder im Element, zusätzlich per aria-describedby verknüpft, damit auch der Screenreader ihn vorliest.

Was mache ich mit einer Falle in einem fremden iframe?

Zuerst beim Anbieter melden – häufig ist es ein bekannter Fehler mit vorhandenem Patch. Bis dahin hilft nur, das Element aus dem regulären Tab-Weg zu nehmen: es erst auf Knopfdruck laden, durch eine eigene Umsetzung ersetzen oder eine gleichwertige Alternative daneben anbieten. Auf der Seite stehen lassen und ignorieren geht nicht, weil 2.1.2 auch für eingebettete Fremdinhalte gilt.

Wie unterscheidet sich 2.1.2 von 2.1.1?

2.1.1 Tastatur fragt, ob alle Funktionen mit der Tastatur erreichbar und bedienbar sind. 2.1.2 fragt, ob man auch wieder herauskommt. Eine Falle verletzt oft beide: Was hinter der Falle liegt, ist nicht mehr bedienbar, und damit fällt auch 2.1.1 – der BITV-Test weist ausdrücklich auf diesen Zusammenhang hin.

Reicht es, mit dem Screenreader zu testen?

Nein. Screenreader haben einen eigenen Lesemodus, mit dem sich Inhalte auch dann noch durchgehen lassen, wenn der Fokus feststeckt. Eine Falle kann so unentdeckt bleiben. Getestet wird deshalb zuerst mit der bloßen Tastatur ohne Screenreader – und der Screenreader kommt als zweiter Durchgang dazu.

Verwandte Themen

• 2.1.1 Tastatur – das Fundament, auf dem 2.1.2 aufsetzt
• Dialoge & Modals – Fokus-Kreis richtig bauen
• 2.4.3 Fokus-Reihenfolge – schlüssige Reihenfolge statt Sprüngen
• 2.4.7 Fokus sichtbar – Fallen sieht man nur mit sichtbarem Fokus
• Tastatur & Fokus – der Praxisartikel zum ganzen Themenfeld