- Stufe
- A
- Seit
- WCAG 2.0
2.1.2 Keine Tastaturfalle
Wenn der Tastaturfokus in einen Teil der Seite gelangen kann, muss er ihn per Tastatur auch wieder verlassen können, und braucht es dafür eine ungewöhnliche Taste, muss die Seite sagen, welche.
/ Was es verlangt
Eine Tastaturfalle ist eine Stelle, an der Tab, Umschalt+Tab und die Pfeiltasten nicht mehr wirken: Der Fokus gerät in einen eingebetteten Player, einen Editor, eine Karte oder ein schlecht gebautes Widget und kommt nicht wieder heraus. Wer nur die Tastatur nutzt oder eine Schaltersteuerung oder einen Screenreader, die Tastaturbefehle senden, verliert den Rest der Seite, und oft bleibt nur, den Tab zu schließen. Deshalb zählt WCAG dieses Kriterium zu den vier, die für alle Inhalte einer Seite gelten, auch für Teile, auf die sich die Erfüllung anderer Kriterien nicht stützt.
Die Regel: Lässt sich der Fokus per Tastatur in eine Komponente bewegen, lässt er sich auch allein per Tastatur wieder herausbewegen. Braucht das mehr als unveränderte Pfeil- oder Tabulatortasten oder eine andere übliche Methode zum Verlassen, muss die Person erfahren, wie es geht. WCAG definiert diese üblichen Methoden nicht, weil sie von Hardware, Browser und Betriebssystem abhängen, das W3C nennt aber Escape als die gängige auf einer physischen Tastatur. Den Fokus in einem geöffneten modalen Dialog zu halten ist keine Falle, solange die Person weiß, wie sie ihn verlässt. Ein Texteditor, der Tab zum Einrücken nutzt, besteht, wenn er sagt, welche Taste den Fokus herausführt.
/ Woran Seiten scheitern
- Ein eingebetteter Videoplayer, eine Karte oder ein Spiel in einem Plugin oder iframe übernimmt den Fokus und verarbeitet jede Taste selbst, ohne eine Taste, die den Fokus an die Seite zurückgibt.
- Ein modaler Dialog lässt den Fokus zwischen seinen Schaltflächen kreisen, ignoriert Escape, und sein einziger Ausgang ist ein Schließen-Symbol, das keinen Fokus annimmt.
- Ein Skript, das den Fokus festhält, bleibt aktiv, nachdem sein Dialog geschlossen wurde, sodass Tab immer wieder zu einem Element zurückkehrt, das nicht mehr sichtbar ist.
- Ein Texteditor oder Codefeld belegt Tab für Einrückungen und gibt keinen Hinweis, wie der Fokus es verlassen kann.
- Ein eigener Datumswähler setzt beim Öffnen den Fokus in sein Raster und holt ihn bei jedem keydown zurück, sodass weder Tab noch Escape herausführt.
/ So prüfen Sie es selbst
- Beginnen Sie in der Adresszeile und gehen Sie mit Tab durch alle Bedienelemente der Seite, eingebettete Player, Karten, Editoren und Widgets eingeschlossen, bis der Fokus zum Browser zurückkehrt.
- Prüfen Sie bei jeder Komponente, ob Tab weitergeht und Umschalt+Tab zurück. Bleibt der Fokus nach mehreren Tastendrücken stehen, versuchen Sie die Pfeiltasten und Escape.
- Öffnen Sie jeden Dialog, jedes Menü und jedes Popup per Tastatur, verlassen Sie es mit Escape oder seiner Schließen-Schaltfläche und prüfen Sie, ob sich der Fokus danach durch den Rest der Seite bewegen lässt.
- Braucht eine Komponente eine andere Taste zum Verlassen, prüfen Sie, ob die Seite das sagt, in sichtbarem Text vor der Komponente oder in einem Hinweis, der beim Fokuserhalt erscheint.
- Ist der Fokus nicht sichtbar, verfolgen Sie ihn mit einem Live-Ausdruck (Live expression) in der Konsole der Chrome-Entwicklerwerkzeuge, gesetzt auf document.activeElement.
/ So beheben Sie es
- Entfernen Sie Listener, die den Fokus festhalten, sobald der Dialog schließt, und setzen Sie den Fokus zurück auf das Bedienelement, das ihn geöffnet hat.
- Schließen Sie modale Dialoge mit einem keydown-Handler auf Escape und machen Sie das Schließen-Element zu einem button-Element. Ein natives dialog-Element, geöffnet mit showModal(), schließt standardmäßig mit Escape.
- Geben Sie einem Editor, der Tab übernimmt, eine dokumentierte Taste, die den Fokus herausführt, und zeigen Sie diesen Hinweis, wenn der Editor den Fokus erhält.
- Rufen Sie preventDefault() bei keydown-Ereignissen der Tabulatortaste nur auf, wenn die Komponente den Fokus selbst bewegt und ihn an beiden Enden hinauslässt.
- Testen Sie Player und Widgets von Drittanbietern vor dem Einsatz an Ort und Stelle und ersetzen Sie jene, die den Fokus festhalten. Eine Falle in eingebettetem Inhalt lässt die Seite durchfallen, die ihn enthält.
/ Was unser Scanner prüft
Der Website-Scan drückt keine Tasten und kann eine Falle deshalb nicht nachweisen. Zwei Prüfungen in der Browsererweiterung OAKMONT Inspector tun es auf Anforderung, mit echten Tastenereignissen über den Chrome-Debugger. focus-trap drückt bis zu 60-mal Tab und meldet ein Element, auf dem der Fokus drei Tastendrücke in Folge bleibt. escape-does-not-close öffnet mit Eingabe bis zu sechs Bedienelemente mit aria-expanded oder aria-haspopup, drückt Escape und meldet, was offen bleibt. Eine Schleife über mehrere Elemente und Umschalt+Tab werden nicht geprüft, und ein Widget, das Escape ignoriert, ist nur dann eine Falle, wenn auch keine andere Taste herausführt.
/ Wer es verletzt, nach unseren eigenen Messungen
Der wöchentliche Index hat für dieses Kriterium keine Zahlen, weil keine Prüfung des Website-Scans es testen kann. Ein Mensch beurteilt es, und genau dafür gibt es ein manuelles Audit.
Eine Seite je Stelle, automatisch im Wochenrhythmus gemessen. Behebungen seit dem letzten Durchlauf erscheinen beim nächsten, und jede Eintragsseite bietet ein Recht auf Gegendarstellung.
/ Fragen zu diesem Kriterium
Ist ein modaler Dialog, der den Fokus festhält, eine Tastaturfalle?
Nein. Laut W3C verstößt es nicht gegen 2.1.2, den Fokus auf einen geöffneten modalen Dialog zu beschränken, solange die Person weiß, wie sie ihn verlässt. Übliche Ausgänge sind Escape und eine Schaltfläche Abbrechen oder Schließen. Der Dialog fällt durch, wenn keiner davon per Tastatur funktioniert.
Was gilt als übliche Methode zum Verlassen?
WCAG definiert das nicht, weil es von Hardware, Browser und Betriebssystem der Person abhängt. Unveränderte Tabulator- und Pfeiltasten zählen immer, und das W3C nennt Escape als gängige Methode auf einer physischen Tastatur. Jede andere Taste oder Kombination ist nur erlaubt, wenn die Person darüber informiert wird.
Gilt 2.1.2 auch für Inhalte von Drittanbietern wie eingebettete Player?
Ja. Es ist eines von vier Kriterien, die für alle Inhalte einer Seite gelten, zusammen mit 1.4.2, 2.2.2 und 2.3.1, weil ein Verstoß die Nutzung der ganzen Seite blockiert. Eine Falle in einem eingebetteten Player oder Chat-Widget lässt die Seite durchfallen, die ihn einbindet, ganz gleich, wer den Code geschrieben hat.