2.1.2 Keine Tastaturfalle

1. Was ist das Ziel dieses Kriteriums?

Du kennst es vielleicht aus Escape Rooms – der Nervenkitzel, aber auch die Panik, wenn du keinen Ausgang findest. Genau das passiert Menschen, die mit Tastatur oder Screenreader unterwegs sind, wenn sie in einem Element einer Website „gefangen“ sind und nicht mehr herauskommen.

Das Ziel von Erfolgskriterium 2.1.2 ist es sicherzustellen, dass niemand in einem Teil deiner Website stecken bleibt. Alle müssen mit der Tastatur nicht nur in jedes Element hineinkommen, sondern auch wieder heraus – ohne Umweg über die Maus.

2. Was fordert das Erfolgskriterium genau?

Ganz konkret geht es um eine einfache Regel: Wer per Tastatur hineinkommt, muss per Tastatur auch wieder herauskommen.

Wenn der Tastaturfokus auf ein Element bewegt werden kann, muss er sich auch allein mit der Tastatur wieder davon wegbewegen lassen. Das bedeutet:

• Standard-Navigation: Meist reichen Tab, Umschalt+Tab oder die Pfeiltasten völlig aus
• Besondere Komponenten: Wenn zum Verlassen mehr nötig ist als ungeänderte Pfeil- oder Tab-Tasten oder andere übliche Methoden, müssen Nutzer:innen darüber informiert werden – am besten, bevor sie das Element betreten
• Alle Bereiche der Seite: Dialoge, Widgets, eingebettete Inhalte wie Videoplayer oder Karten, Formulare – alles muss sich wieder verlassen lassen

Besonderheit: 2.1.2 gehört zu den Kriterien mit „Nicht-Beeinträchtigung“ (Non-Interference). Es gilt für alle Inhalte einer Seite – auch für solche, die gar nicht Teil der barrierefreien Version sein sollen. Denn eine einzige Tastaturfalle kann die gesamte Seite unbenutzbar machen.

Wichtig zur Abgrenzung: Ein modaler Dialog, der den Fokus bewusst innerhalb des Dialogs hält, ist keine Tastaturfalle – solange er sich per Tastatur schließen lässt, etwa mit Escape oder einem Schließen-Button.

3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du navigierst nur mit der Tastatur durch eine Website und landest in einem eingebetteten Player. Egal, was du drückst – du kommst nicht mehr raus. Das ist nicht nur frustrierend, sondern macht die gesamte Website unbenutzbar.

Tastaturfallen schaffen echte Barrieren, weil sie:

• Blinde und sehbehinderte Menschen daran hindern, mit dem Screenreader weiterzukommen
• Menschen mit motorischen Einschränkungen blockieren, die keine Maus verwenden können
• Power-User beim effizienten Arbeiten mit der Tastatur ausbremsen
• Alle im Stich lassen, deren Maus oder Touchpad gerade nicht verfügbar ist

Und das Tückische: Eine einzige Tastaturfalle kann die gesamte Website unbrauchbar machen – selbst wenn alle anderen Bereiche vorbildlich barrierefrei sind.

4. So setzt du das Kriterium erfolgreich um

Die gute Nachricht: Tastaturfallen lassen sich meist leicht vermeiden, wenn du ein paar Grundregeln beachtest.

Grundlagen für alle Elemente:

• Teste alle interaktiven Bereiche: Kommst du mit Tab hinein und mit Tab oder Umschalt+Tab wieder heraus?
• Nutze native HTML-Elemente, wann immer möglich – sie bringen das richtige Verhalten meist schon mit
• Vergiss die Rückwärts-Navigation nicht: Umschalt+Tab muss immer funktionieren
• Fange Tastaturereignisse wie Tab nicht pauschal ab, z. B. in Editoren oder Spielen – oder dokumentiere den Ausweg

Für modale Dialoge und Pop-ups:

• Fokus beim Öffnen in den Dialog setzen
• Escape und einen sichtbaren Schließen-Button zum Schließen anbieten
• Fokus innerhalb des Dialogs halten (Tab springt vom letzten zum ersten Element) – das ist erlaubt, weil der Dialog per Tastatur schließbar ist
• Nach dem Schließen den Fokus auf das auslösende Element zurücksetzen
• Das native <dialog>-Element mit showModal() nimmt dir einen Teil dieser Arbeit ab

Für komplexe Widgets und eingebettete Inhalte:

• Wenn ein Widget eigene Tasten zum Verlassen braucht, erkläre sie vorher sichtbar, z. B.: „Mit Esc verlässt du den Editor.“
• Bevorzuge übliche Wege zum Verlassen (Tab, Umschalt+Tab, Esc)
• Prüfe eingebettete Inhalte von Drittanbietern (Videoplayer, Karten, Chat-Widgets) – auch für sie bist du verantwortlich

Der wichtigste Test: Leg deine Maus weg und navigiere nur mit der Tastatur durch deine gesamte Website. Wenn du irgendwo „hängen bleibst“, hast du eine Tastaturfalle gefunden. Mehr zur Tastaturbedienung im Allgemeinen findest du bei Tastatur.

5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

Tastaturfallen sind nicht nur ein Barrierefreiheitsproblem – sie kosten dich direkt Kund:innen und Geschäftschancen.

1. Zielgruppe erweitern

Ein Website-Bereich, aus dem man nicht herauskommt, ist wie ein Geschäft ohne Ausgang. Du verlierst nicht nur Menschen mit Behinderungen, sondern auch alle, die gerade auf die Tastatur angewiesen sind – etwa bei defekter Maus.

2. Rechtliche Risiken vermeiden

Tastaturfallen verletzen ein Level-A-Kriterium und machen Websites für viele Menschen mit Behinderungen komplett unbenutzbar. Gerade solche Blocker fallen bei Prüfungen schnell auf.

3. Nutzererfahrung für alle verbessern

Tastaturnavigation ist nicht nur für Menschen mit Behinderungen relevant. Power-User, Entwickler:innen und alle, die effizient arbeiten wollen, nutzen die Tastatur. Tastaturfallen frustrieren auch sie unnötig.

Und nicht zuletzt: rechtliche Anforderungen. Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Produkte und Dienstleistungen für Verbraucher:innen, etwa Online-Shops. Technischer Maßstab ist die EN 301 549, die für Webinhalte auf WCAG 2.1 Level AA verweist – 2.1.2 gehört dazu. Öffentliche Stellen sind über die BITV 2.0 bzw. Landesrecht verpflichtet. Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung.

6. Das Erfolgskriterium im Wortlaut des W3C

Success Criterion 2.1.2 No Keyboard Trap (Level A)

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Note: Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

Kurz gesagt: Wenn der Fokus per Tastatur in eine Komponente gelangt, muss er sie auch allein per Tastatur wieder verlassen können – und wenn dafür besondere Tasten nötig sind, müssen Nutzer:innen erfahren, welche.