Tastaturfalle (keyboard:trap)

Die Regel keyboard:trap meldet ein Element, in das der Tastaturfokus hineinkommt, aber nicht wieder heraus: Tab, Umschalt+Tab und Escape lassen den Fokus, wo er ist. Wer ohne Maus arbeitet, kommt auf dieser Seite nicht weiter. Die Lösung: Die Standardtasten führen weiter – und wo ein Widget Tab wirklich selbst braucht, gibt es einen Ausweg, der auf dem Bildschirm steht.

Was die Regel bedeutet

WCAG 2.1.2 verlangt: Kann der Fokus per Tastatur in eine Komponente bewegt werden, muss er sich auch allein per Tastatur wieder heraus bewegen lassen. Braucht das Verlassen andere als die üblichen Tasten (Tab, Umschalt+Tab, Pfeiltasten, Escape), muss die Person erfahren, wie es geht.

Eine Falle ist nicht dasselbe wie ein modaler Dialog, der den Fokus bei sich behält. Ein Dialog, der den Fokus hält, bis er geschlossen wird – mit Escape oder einem Schließen-Button –, macht es richtig, denn der Rest der Seite ist solange ohnehin nicht bedienbar.

Wen es betrifft

Alle, die statt einer Maus die Tastatur nutzen: Menschen mit motorischen Einschränkungen mit Tastatur, Schalter oder Mundstab, blinde Menschen mit Screenreader und geübte Tastatur-Nutzende. Eine Falle ist der schwerste Tastaturfehler überhaupt. Nichts auf dem Rest der Seite ist mehr erreichbar, oft nicht einmal die Adresszeile – außer mit Tastenkürzeln, die viele nicht kennen.

Warum die Prüfung anschlägt

• Texteditoren und Code-Felder, die bei Tab ein Tabulatorzeichen einfügen und keinen anderen Weg hinaus bieten.
• Eingebettete Player und Karten (iframes, Canvas, Plugins), die den Fokus übernehmen und nie zurückgeben.
• Fokusschleifen in Menüs, Karussells oder Chat-Widgets, die wie ein modaler Dialog gebaut sind, aber keiner sind.
• Skripte, die den Fokus zurückholen, etwa bei blur in ein Feld, damit erst eine gültige Eingabe erfolgt.
• Datumsauswahl und eigene Auswahllisten, die im geöffneten Zustand jede Taste abfangen und Escape nicht behandeln.

So beheben Sie es

Lassen Sie Tab und Umschalt+Tab das tun, was sie immer tun. Braucht ein Widget eine Taste für sich, geben Sie ihm eine andere – und sagen Sie es.

<!-- Vorher: Das Notizfeld schluckt Tab und Escape -->
<label for="notiz">Notiz</label>
<textarea id="notiz"
  onkeydown="if (event.key === 'Tab' || event.key === 'Escape') {
    event.preventDefault(); /* fügt nichts ein und hält den Fokus */
  }"></textarea>
<button type="button">Speichern</button>

<!-- Nachher: Tab führt weiter; Einrücken hat ein eigenes Kürzel, das dasteht -->
<label for="notiz">Notiz</label>
<textarea id="notiz" aria-describedby="notiz-hinweis"
  onkeydown="if (event.ctrlKey && event.key === ']') {
    event.preventDefault();
    this.setRangeText('\t', this.selectionStart, this.selectionEnd, 'end');
  }"></textarea>
<p id="notiz-hinweis">Strg + ] rückt die aktuelle Zeile ein.</p>
<button type="button">Speichern</button>

Für eigene Widgets gilt:

• Escape schließt, was sich geöffnet hat (Menüs, Auswahlfenster, Pop-ups), und setzt den Fokus zurück auf das auslösende Element.
• Ein echter modaler Dialog nutzt <dialog> mit showModal() oder role="dialog" mit aria-modal="true" – und lässt sich immer schließen.
• Eingebettete Inhalte: Prüfen Sie Player und Karten von Drittanbietern mit der Tastatur, bevor Sie sie einbinden. Hält einer den Fokus fest, verstößt Ihre Seite.

So prüfen Sie es von Hand

1. Klicken Sie in die Adresszeile und drücken Sie Tab, bis Sie jedes Bedienelement der Seite besucht haben.
2. Versuchen Sie an jedem Widget, es zu verlassen: Tab, Umschalt+Tab, dann Escape.
3. Öffnen Sie jedes Menü, jede Datumsauswahl und jeden Dialog und schließen Sie sie allein mit der Tastatur.
4. Prüfen Sie eingebettete Inhalte (Videos, Karten, Chat) genauso. Fallen stecken meist in dem, was man nicht selbst gebaut hat.

Zugehöriges WCAG-Kriterium

2.1.2 Keine Tastaturfalle, Stufe A. Verwandt: 2.1.1 Tastatur, weil zuerst einmal alles per Tastatur bedienbar sein muss, und 2.4.3 Fokus-Reihenfolge.

So meldet Reviseberg diese Regel

Diese Regel stammt nicht aus axe-core: Eine Falle zeigt sich erst, wenn jemand Tasten drückt. Der Tastatur-Agent von Reviseberg geht die Nutzerreise, die Sie festlegen, mit echten Tastendrücken in Chromium durch. Bleibt der Fokus nach einem Tab auf demselben Element wie zuvor, versucht er Umschalt+Tab und danach Escape. Erst wenn der Fokus nach allen dreien noch dort ist, meldet er die Falle – „Focus cannot leave this element with Tab, Shift+Tab or Escape“ – und beendet den Durchlauf, weil danach nichts mehr erreichbar ist. Fokus, der in einem geöffneten modalen Dialog bleibt (<dialog open> oder role="dialog" mit aria-modal="true"), meldet er nicht.

Zum Befund gehören der Selektor, der Schritt in der Tastenfolge und bei einem vollständigen Crawl ein zugeschnittener Screenshot. Der Agent drückt nicht erst Escape und dann Tab: Ein Widget, das man nur so verlässt – manche Code-Editoren tun das –, wird als Falle gemeldet. Steht der Ausweg auf Ihrer Seite, markieren Sie den Befund mit dieser Begründung als „Fehlalarm“.

Verwandte Regeln

• undefined – das umgekehrte Problem: ein Bedienelement, das kein Tab erreicht.
• undefined – ein Fokus, den niemand sieht.
• undefined – ein Scrollbereich, den die Tastatur nicht erreicht.

Tastatur-Agent auf Ihrer Website – kostenloser Bericht