Tastaturbedienung nach WCAG: Kriterium 2.1.1, Fokusfalle, Fokus-Reihenfolge und sichtbarer Fokus
21. September 2026 · 7 Min. Lesezeit · BarriereRadar RedaktionVier Erfolgskriterien der WCAG 2.1 machen die Tastaturbedienung aus: 2.1.1 verlangt, dass jede Funktion per Tastatur geht, 2.1.2 den Ausweg aus jedem Element, 2.4.3 eine Reihenfolge, die der Seite folgt, und 2.4.7 einen sichtbaren Fokus. Alle vier gehören zum Umfang, den das BFSG über die EN 301 549 verlangt.
Legen Sie die Maus weg und versuchen Sie, in Ihrem Shop etwas zu kaufen: Tab, Tab, Tab, Enter. Wenn der Fokus irgendwo verschwindet, das Menü sich nur mit der Maus öffnet oder das Cookie-Fenster Sie nicht mehr herauslässt, verletzt die Seite eines von vier Erfolgskriterien der WCAG 2.1, die zusammen die Tastaturbedienung ausmachen: 2.1.1 Tastatur, 2.1.2 Keine Tastaturfalle, 2.4.3 Fokus-Reihenfolge und 2.4.7 Fokus sichtbar. Drei davon sind Stufe A, die vierte Stufe AA, und alle vier liegen in dem Bereich, den die EN 301 549 mit ihrem Verweis auf die WCAG 2.1 abdeckt, dem zulässigen Weg zur Erfüllung der BFSGV. Dieser Beitrag erklärt jedes Kriterium mit dem Wortlaut, zeigt die typischen Verstöße im Quelltext, gibt eine Zehn-Minuten-Prüfung und ordnet ein, welche Fehler ein Scanner findet und welche nur die Hand auf der Tastatur.
Die vier Erfolgskriterien und was sie verlangen
| Kriterium | Stufe | Kernaussage |
|---|---|---|
| 2.1.1 Tastatur | A | Alle Funktionen sind über eine Tastaturschnittstelle bedienbar, ohne bestimmte Zeitvorgaben für einzelne Tastenanschläge; Ausnahme nur, wenn die Funktion selbst vom Pfad der Bewegung abhängt, etwa Freihandzeichnen. |
| 2.1.2 Keine Tastaturfalle | A | Kann der Fokus per Tastatur auf ein Element bewegt werden, kann er auch per Tastatur wieder weg; braucht es dafür mehr als Tab oder Pfeiltasten, wird der Nutzer darüber informiert. |
| 2.4.3 Fokus-Reihenfolge | A | Wird die Seite sequenziell durchlaufen und beeinflusst die Reihenfolge Bedeutung oder Bedienung, erhalten die Elemente den Fokus in einer Reihenfolge, die Bedeutung und Bedienbarkeit erhält. |
| 2.4.7 Fokus sichtbar | AA | Jede per Tastatur bedienbare Oberfläche hat einen Modus, in dem der Tastaturfokus sichtbar ist. |
Der Wortlaut von 2.1.1 ist weiter, als er auf den ersten Blick wirkt. „Alle Funktionen“ heißt: nicht nur Links und Knöpfe, sondern auch das Aufklappmenü, der Bildwechsler, der Größenwähler, der Schieberegler für den Preisfilter und der Schließen-Knopf des Hinweisfensters. Die Ausnahme greift nur, wenn die Funktion selbst pfadabhängig ist; ein Schieberegler ist es nicht, weil sein Ergebnis ein Wert ist, kein Weg. Welche vier Prinzipien hinter den Kriterien stehen, erklärt der Beitrag zu den vier WCAG-Prinzipien.
Die Anforderungen an Websites stehen in der BFSGV; Anlage 3 Nr. 2 BFSG erlaubt, harmonisierte Normen anzuwenden, und § 4 BFSG knüpft daran eine Konformitätsvermutung. Die EN 301 549 mit ihrem Verweis auf die WCAG 2.1 auf den Stufen A und AA ist dieser zulässige Weg, und die vier Erfolgskriterien der Tastaturbedienung gehören alle dazu. Ein Shop, der nur mit der Maus bedienbar ist, verfehlt die Bedienbarkeit als Ganzes, nicht ein Detail.
Die typischen Verstöße im Quelltext
- <div onclick> als Knopf: bekommt keinen Fokus und reagiert nicht auf Enter
- outline: none ohne Ersatz: der Fokus ist da, aber niemand sieht ihn
- tabindex="3", tabindex="1": die Reihenfolge folgt Zahlen statt der Seite
- Modales Fenster ohne Rückweg: Tab kreist in der Seite dahinter
- Menü, das nur auf mouseover öffnet
- <button> und <a href>: Fokus, Enter und Leertaste kommen mit
- :focus-visible mit sichtbarem Rahmen in Markenfarbe
- tabindex="0" oder gar keins: die Reihenfolge ist die des Dokuments
- Fokus wird beim Öffnen ins Fenster gesetzt, Escape schließt es, Fokus kehrt zurück
- Menü öffnet auf Enter und auf Fokus
Der häufigste Fehler ist der unsichtbare Fokus. Viele Vorlagen setzen outline: none, weil der blaue Rahmen des Browsers das Design stört, und ersetzen ihn nicht. Der Fokus ist dann vorhanden, aber unsichtbar: Der Nutzer drückt Tab und weiß nicht, wo er ist. 2.4.7 verlangt keinen bestimmten Rahmen, nur dass ein Modus existiert, in dem der Fokus sichtbar ist; eine Linie in Markenfarbe mit ausreichendem Kontrast genügt.
Der zweithäufigste ist der positive tabindex. Wer einem Element tabindex="1" gibt, hebt es an den Anfang der Reihenfolge, vor die Navigation und vor die Suche. Alle weiteren positiven Werte werden davor oder danach einsortiert, und die Reihenfolge entspricht nicht mehr dem, was auf dem Bildschirm zu sehen ist. 2.4.3 ist damit verletzt, obwohl jedes Element für sich erreichbar bleibt. Welche Formularfehler dazukommen, zeigt der Beitrag zum barrierefreien Checkout.
Die Zehn-Minuten-Prüfung ohne Maus
- Maus wegschieben, Startseite laden Tab drücken. Erscheint als Erstes ein Sprunglink „Zum Inhalt“? Wenn nicht, beginnt jede Seite mit der ganzen Navigation.
- Fokus verfolgen Bei jedem Tab muss sichtbar sein, wo der Fokus ist. Verschwindet er, ist 2.4.7 verletzt oder ein unsichtbares Element bekommt Fokus.
- Reihenfolge mit dem Auge vergleichen Springt der Fokus von der Kopfzeile in die Fußzeile und zurück in die Mitte, ist 2.4.3 verletzt.
- Menü und Filter bedienen Enter auf dem Menüpunkt: Öffnet es sich? Pfeiltasten im Preisfilter: Ändert sich der Wert? Sonst 2.1.1.
- Cookie-Fenster und Warenkorb-Overlay Kommt der Fokus hinein, lässt Escape oder Tab wieder heraus? Kreist er dahinter, ist 2.1.2 verletzt.
- Bis zur Bestellung durchgehen Produkt wählen, Größe wählen, in den Warenkorb, Kasse, Zahlungsart. Jeder Schritt nur mit Tab, Enter, Leertaste, Pfeilen.
Diese Prüfung ersetzt keinen vollständigen Test, aber sie findet in zehn Minuten die Fehler, die einen Tastaturnutzer am Kauf hindern. Was die Prüfung ergibt, gehört als Befund mit Seite, Element und Kriterium in dieselbe Liste wie die Ergebnisse des Scanners. Welche Seiten dabei zuerst dran sind, steht im Beitrag BFSG: Welche Seiten prüfen?.
Was der Scanner findet und was nicht
Automatisch prüfbar ist, was im Quelltext eindeutig entscheidbar ist. BarriereRadar meldet deshalb den entfernten Fokus-Indikator (outline: none ohne Ersatz, Kriterium 2.4.7), den positiven tabindex-Wert (Kriterium 2.4.3), Schaltflächen ohne zugänglichen Namen, das fehlende Ziel eines Sprunglinks und fokussierbare Elemente, die vor dem Screenreader versteckt sind. Das sind die Verstöße, die sich aus dem Markup lesen lassen; ein <div> mit Klickbehandlung, aber ohne Rolle und tabindex, erkennt der Scanner nicht als Knopf, weil im Markup kein Knopf steht.
Nicht automatisch prüfbar ist, ob eine Funktion tatsächlich per Tastatur funktioniert: ob das Menü auf Enter öffnet, ob der Schieberegler auf Pfeiltasten reagiert, ob der Fokus aus dem Overlay wieder herauskommt. Das erfordert die Hand auf der Tastatur, und dafür gibt es die Prüfung oben. Der Scanner sagt, wo ein Verstoß wahrscheinlich ist; der Mensch bestätigt ihn. Was der Scan grundsätzlich leisten kann, ordnet der Beitrag zu den Grenzen des Barrierefreiheits-Scans ein.
| Verstoß | Kriterium | Scanner | Hand auf der Tastatur |
|---|---|---|---|
| outline: none ohne Ersatz | 2.4.7 | Ja | Ja |
| Positiver tabindex | 2.4.3 | Ja | Ja, als falsche Reihenfolge |
| div als Knopf ohne Rolle und tabindex | 2.1.1, 4.1.2 | Nein, im Markup steht kein Knopf | Ja, Element wird übersprungen |
| Menü öffnet nur auf mouseover | 2.1.1 | Nein | Ja |
| Fokus kreist hinter dem Overlay | 2.1.2 | Nein | Ja |
| Fokus springt nach dem Schließen ins Leere | 2.4.3 | Nein | Ja |
Häufige Fragen
Was verlangt WCAG 2.1.1 Tastatur?
Dass alle Funktionen des Inhalts über eine Tastaturschnittstelle bedienbar sind, ohne bestimmte Zeitvorgaben für einzelne Tastenanschläge. Ausgenommen sind nur Funktionen, die vom Pfad der Bewegung abhängen, etwa Freihandzeichnen. Menüs, Filter, Bildwechsler und Overlays müssen also per Tastatur bedienbar sein.
Ist outline: none ein Verstoß gegen die WCAG?
Wenn kein sichtbarer Ersatz für den Fokus definiert ist, ja: Kriterium 2.4.7 Fokus sichtbar (Stufe AA) verlangt einen Modus, in dem der Tastaturfokus sichtbar ist. Ein eigener Rahmen über :focus-visible mit ausreichendem Kontrast erfüllt das Kriterium; das Entfernen ohne Ersatz nicht.
Was ist eine Tastaturfalle?
Ein Element, auf das der Fokus per Tastatur gelangt, von dem er aber per Tastatur nicht mehr wegkommt, etwa ein Overlay, hinter dem Tab weiter durch die Seite kreist, oder ein eingebettetes Element ohne Ausweg. Kriterium 2.1.2 verlangt, dass der Fokus per Tastatur wieder weg kann und ungewöhnliche Wege dafür angesagt werden.
Kann ein automatischer Scanner die Tastaturbedienung prüfen?
Teilweise. Aus dem Quelltext lassen sich entfernte Fokus-Indikatoren, positive tabindex-Werte, Schaltflächen ohne Namen und fehlende Sprunglink-Ziele erkennen. Ob ein Menü auf Enter öffnet oder der Fokus aus einem Overlay herauskommt, zeigt nur die Prüfung mit der Tastatur.
Das Wichtigste in Kürze
Vier Erfolgskriterien der WCAG 2.1 machen die Tastaturbedienung aus: 2.1.1 verlangt, dass jede Funktion per Tastatur geht, 2.1.2 den Ausweg aus jedem Element, 2.4.3 eine Reihenfolge, die der Seite folgt, und 2.4.7 einen sichtbaren Fokus. Alle vier gehören zum Umfang, den das BFSG über die EN 301 549 verlangt.
Die häufigsten Verstöße sind outline: none ohne Ersatz, positive tabindex-Werte und div-Elemente als Knöpfe; die ersten beiden findet ein Scanner, das dritte nur die Hand auf der Tastatur. Ob Menü, Filter und Overlay wirklich per Tastatur funktionieren, zeigt nur die Prüfung ohne Maus bis zur Bestellung.
Dieser Beitrag ersetzt keine Rechtsberatung. Eine automatisierte Erstprüfung ersetzt nicht den vollständigen BITV-/WCAG-Test – maßgeblich sind BFSG, BFSG-Verordnung und die harmonisierte Norm EN 301 549 in ihrer aktuellen Fassung.