Definition: Eine Tastaturfalle ist ein Element, in das man per Tastatur hineinkommt, aus dem man aber mit der Tastatur nicht wieder herauskommt. Das verbietet das WCAG-Kriterium 2.1.2 Keine Tastaturfalle auf Stufe A [1].
Englisch: Keyboard trap · Auch: Fokusfalle · Zuletzt geprüft: 27. September 2026
Warum das so schwer wiegt
Wer ohne Maus arbeitet, bewegt sich mit Tab und Umschalt + Tab durch die Seite. Das betrifft blinde Menschen, die einen Screenreader nutzen, Menschen mit motorischen Einschränkungen, die eine Tastatur, einen Schalter oder einen Mundstab bedienen, und viele geübte Nutzende, die schlicht schneller sind ohne Maus. Bleibt der Fokus in einem Element stecken, ist für sie die ganze restliche Seite unerreichbar. Oft bleibt nur, den Tab zu schließen.
Die WCAG behandeln 2.1.2 deshalb besonders streng. Das Kriterium gehört zu den vier „Nichtbeeinträchtigungs“-Anforderungen: Es muss für alle Inhalte einer Seite gelten, auch für Teile, die nicht zur Konformität beitragen sollen – etwa ein eingebettetes Drittanbieter-Widget [3].
Wo Tastaturfallen entstehen
- Eingebettete Player und iframes – Videoplayer, Karten, Buchungs- oder Chat-Widgets von Drittanbietern.
- Editoren, die die Tab-Taste für Einrückung abfangen, ohne einen Ausweg zu nennen.
- Eigene Dialoge und Menüs, deren Fokus-Logik nur das Hineinspringen kennt.
- Datumsauswahl, Slider und Karussells, die Tastatureingaben mit
preventDefault()schlucken. - Cookie-Banner, die den Fokus festhalten, sich aber nicht per Tastatur schließen lassen.
Gewollter Fokus in Dialogen ist keine Falle
Ein modaler Dialog darf den Fokus bewusst einschließen, solange er offen ist. Das ist sogar richtig so [4]. Zur Falle wird er erst, wenn man ihn nicht verlassen kann: Escape schließt ihn nicht, und es gibt keine erreichbare Schließen-Schaltfläche. Braucht ein Element eine ungewöhnliche Taste zum Verlassen, muss es das sagen – etwa „Mit Strg + M verlassen Sie den Editor“ [2].
Im Code
// Falle: Tab wird immer abgefangen
editor.addEventListener('keydown', (e) => {
if (e.key === 'Tab') {
e.preventDefault()
insertIndent()
}
})// Besser: Escape gibt Tab frei
let indent = true
editor.addEventListener('keydown', (e) => {
if (e.key === 'Escape') { indent = false; return }
if (e.key === 'Tab' && indent) {
e.preventDefault()
insertIndent()
}
})
editor.addEventListener('focus', () => { indent = true })
// Sichtbarer Hinweis: „Tab rückt ein.
// Escape, dann Tab: Editor verlassen.“So prüfen Sie es
Klicken Sie in die Adresszeile und legen Sie die Maus weg. Gehen Sie mit Tab durch die ganze Seite und mit Umschalt + Tab zurück. Öffnen Sie jeden Dialog, jedes Menü und jedes eingebettete Element, und verlassen Sie es wieder – mit Tab, Umschalt + Tab und Escape. Kommen Sie überall hinein und wieder heraus?
Wie Reviseberg damit umgeht
Der Tastatur-Agent von Reviseberg geht Ihre wichtigste Nutzerreise mit echten Tastendrücken durch: Tab, Umschalt + Tab, Enter, Leertaste und Escape. Hängt der Fokus fest, meldet er die Regel keyboard:trap mit der Tastenfolge Schritt für Schritt und einem Bildschirmfoto der Stelle. Geprüft wird die Reise, die Sie festlegen – nicht jede denkbare Kombination auf jeder Seite. Ein reiner Regel-Scan mit axe-core findet Tastaturfallen dagegen nicht, weil er keine Tasten drückt.
Verwandte Begriffe
Tastaturbedienbarkeit · Fokusreihenfolge · Fokusindikator · Skip-Link · Screenreader