Website mit Tastatur bedienbar: Fokus, Tastaturfallen und der Selbsttest

Das Wichtigste in Kürze

• Sechs Erfolgskriterien der WCAG 2.1 beschreiben die Bedienung ohne Maus: 2.1.1 Tastatur, 2.1.2 Keine Tastaturfalle, 2.4.3 Fokus-Reihenfolge, 2.4.7 Fokus sichtbar, 2.5.3 Beschriftung (Label) im Namen, 4.1.2 Name, Rolle, Wert.
• Ein automatischer Scan meldet davon fast nichts. Auf den drei Seiten unseres Demo-Testshops meldete die Prüfengine axe mit dem Tagset WCAG 2.1 A und AA 14 Verstoßarten in 129 Elementen – keine davon zu Tastatur, Fokus oder Reihenfolge. Unsere eigene Tastaturmessung fand dort 14 Befunde.
• Der Selbsttest braucht sechs Handgriffe: Tabulator, Umschalt und Tabulator, Eingabetaste, Leertaste, Pfeiltasten, Escape. Kein Werkzeug, keine Vorkenntnisse, zehn Minuten.
• Die Fehlerbilder wiederholen sich: positiver tabindex, entfernter Fokusrahmen, Galerien nur mit der Maus, Menüs, die nur beim Überfahren aufgehen, Dialoge ohne Fokusfang, klickbare div-Elemente.
• Maschinell behebbar sind zwei davon: Ein positiver tabindex wird 0, eine Regel für die Fokusanzeige kommt hinzu. Der Rest ist Umbau – Raten wäre schlimmer als der Befund.

Technische Einordnung, keine Rechtsberatung. Ob und wie das BFSG auf einen bestimmten Betrieb anzuwenden ist, beurteilen Anwältinnen und Anwälte.

Die sechs Kriterien im Wortlaut

Das BFSG nennt keine Tastatur. § 3 Absatz 1 BFSG bleibt allgemein: Barrierefrei sind Produkte und Dienstleistungen, wenn sie „für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar sind“ (§ 3 Absatz 1 Satz 2 BFSG). Konkret wird es erst über die Rechtsverordnung nach § 3 Absatz 2 BFSG, die EN 301 549 und die WCAG. Die Normnummern in der Tabelle sind Fundstellen; den Normtext gibt ETSI heraus. Die Zitate darunter stammen aus der deutschen Übersetzung von Aktion Mensch e. V.; das W3C führt sie als nicht autorisierte Übersetzung, verbindlich ist die englische Originalfassung.

2.1.1 Tastatur: „Alle Funktionalitäten des Inhalts sind durch eine Tastaturschnittstelle bedienbar, ohne dass eine bestimmte Zeiteinteilung für einzelne Tastenanschläge erforderlich ist, außer wenn die zugrunde liegende Funktion Eingaben verlangt, die vom Pfad der Bewegung des Benutzers und nicht nur von den Endpunkten abhängig sind.“ Die Ausnahme greift nur, wenn es auf den Weg der Bewegung ankommt und nicht bloß auf Anfang und Ende – Freihandzeichnen etwa. Menü, Bildwechsler und Mengenauswahl gehören nicht dazu. Wer den Satz ohne die Ausnahme liest, liest ein anderes Kriterium: 2.1.3 Tastatur (keine Ausnahme), und das ist Stufe AAA.

2.1.2 Keine Tastaturfalle ist die Gegenrichtung: „Wenn der Tastaturfokus durch eine Tastaturschnittstelle auf einen Bestandteil der Seite bewegt werden kann, dann kann der Fokus von diesem Bestandteil weg bewegt werden, indem man nur die Tastaturschnittstelle benutzt; […]“ – der ausgelassene zweite Halbsatz lässt eine unübliche Ausstiegsmethode zu, verlangt dann aber, dass der Benutzer über sie informiert wird. Ein Hinweis dazu zeigt die Tragweite: Solcher Inhalt „kann die Möglichkeit eines Benutzers beeinträchtigen, die ganze Seite zu nutzen“ – ein Riegel vor allem, was danach kommt.

2.4.3 Fokus-Reihenfolge gilt unter einer Bedingung: „Wenn eine Webseite der Reihe nach navigiert werden kann und die Reihenfolge der Navigation die Bedeutung oder Bedienung beeinflusst, erhalten fokussierbare Komponenten den Fokus in einer Reihenfolge, der Bedeutung und Bedienbarkeit aufrecht erhält.“ Der grammatisch auffällige Anschluss steht so in der Übersetzung; die Bedingung davor ist der Teil, der oft wegfällt – ohne sie liest sich das Kriterium strenger, als es ist. 2.4.7 Fokus sichtbar ist der kürzeste Satz der Liste: „Jede durch Tastatur bedienbare Benutzerschnittstelle hat einen Bedienmodus, bei dem der Tastaturfokus sichtbar ist.“

2.5.3 Beschriftung (Label) im Namen: „enthält der Name den Text, der visuell angezeigt wird“. Klingt technisch, ist praktisch: Wer den Rechner mit der Stimme bedient, sagt, was er sieht. Steht auf der Schaltfläche „In den Warenkorb“, während der hinterlegte Name „Kaufen“ lautet, geht der Befehl ins Leere.

4.1.2 Name, Rolle, Wert: „Für alle Bestandteile der Benutzerschnittstelle … können Name und Rolle durch Software bestimmt werden; Zustände, Eigenschaften und Werte, die vom Benutzer festgelegt werden können, können durch Software festgelegt sein; […]“ – der ausgelassene Teil verlangt, dass Änderungen daran den Hilfsmitteln mitgeteilt werden. Ein div mit Klick-Handler erfüllt keinen der drei Teile. Fünf der sechs sind Stufe A, nur 2.4.7 ist AA. Die übrigen Erfolgskriterien beider Stufen stehen im Ratgeber zu den Kriterien der WCAG 2.1 AA.

Warum ein Scanner davon fast nichts meldet

Ein Prüfwerkzeug untersucht den Zustand, in dem eine Seite erscheint: Es liest Attribute, rechnet Kontraste, vergleicht Strukturen. Was es nicht tut: Tasten drücken. Tabulatorsprung, Fokusrahmen und Zustandswechsel entstehen erst in der Bedienung – und dort liegen fünf der sechs Kriterien.

Wie groß dieser blinde Fleck ist, haben wir an unserem Demo-Testshop gemessen – einer Übungsseite mit absichtlich eingebauten Fehlern, an der wir unsere Werkzeuge prüfen. Die Prüfengine axe meldete auf den drei Seiten 14 Verstoßarten in 129 Elementen, keine davon zu Tastatur, Fokus oder Reihenfolge. Unsere eigene Tastaturmessung fand an denselben drei Seiten 14 Befunde: zehn positive tabindex-Werte und vier Vorschaubilder der Produktgalerie, die einen Klick-Handler tragen, mit dem Tabulator aber nicht erreichbar sind. Das ist die Messung eines einzelnen Testshops und keine Aussage über andere Websites – aber sie zeigt, was ein reiner Werkzeuglauf übrig lässt.

Ganz blind ist die Automatik nicht: Randbereiche findet sie. In unserer Erhebung 2026 waren es Scrollbereiche ohne Tastaturzugang auf 4 von 85 Websites, verschachtelte Bedienelemente auf 8 von 85, fokussierbare Elemente in ausgeblendeten Bereichen auf 5 von 85 – Symptome am Rand, nicht das Problem.

Der Selbsttest: sechs Handgriffe

Legen Sie die Maus außer Reichweite – buchstäblich, sonst greifen Sie danach, ohne es zu merken. Was Sie mit diesen sechs Handgriffen nicht erreichen, erreicht auch sonst niemand, der auf sie angewiesen ist.

1. Tabulator: vorwärts

   Jeder Druck springt zum nächsten bedienbaren Element. Zu sehen sein muss: eine deutliche Markierung an genau einem Element. Verschwindet sie, kommen zwei Ursachen infrage: Entweder ist die Markierung im Stylesheet abgeschaltet – dann sieht man an keiner Stelle etwas –, oder der Fokus steht wirklich auf etwas Unsichtbarem, meist in einem eingeklappten Menü oder einem Dialog, den niemand geöffnet hat. Der Unterschied zeigt sich daran, ob die Markierung auch an anderen Elementen fehlt.

2. Umschalt und Tabulator: zurück

   Dieselbe Reihe rückwärts. Zu sehen sein muss: genau der Weg, den Sie gekommen sind. Springt der Fokus woandershin, ist die Reihenfolge künstlich gesetzt. Der Rückweg ist der empfindlichste Teil des Tests und der, den fast niemand ausprobiert.

3. Eingabetaste: auslösen

   Links und Schaltflächen reagieren darauf. Passieren muss: dasselbe wie beim Mausklick. Passiert nichts, ist das Element kein Link und keine Schaltfläche, sondern ein div mit einem Klick-Handler.

4. Leertaste: Kästchen und Schaltflächen

   Sie setzt Häkchen, wählt Optionsfelder, betätigt Schaltflächen. Passieren muss: Der Zustand wechselt, und die Seite scrollt nicht weg. Gemeint sind Kästchen, Optionsfelder und Schaltflächen: Auf einem Link blättert die Leertaste die Seite, und das ist richtig so, kein Befund. Scrollt sie dagegen bei etwas, das wie eine Schaltfläche oder ein Kästchen aussieht, hat das Element die Taste nicht abgefangen – ein nachgebautes Bedienelement.

5. Pfeiltasten: innerhalb einer Gruppe

   Optionsfelder, Reiter, Menüleisten und Schieberegler werden mit den Pfeiltasten bedient, nicht mit dem Tabulator. Passieren muss: Der Fokus wandert in der Gruppe, der Tabulator verlässt sie als Ganzes. Sieht etwas aus wie Reiter, tun die Pfeiltasten aber nichts, ist das Muster halb gebaut.

6. Escape: wieder heraus

   Dialoge, Menüs und Kalender schließen sich damit. Passieren muss: Die Ebene schließt, der Fokus kehrt zum öffnenden Element zurück. Bleibt er im geschlossenen Dialog, tabbt man anschließend durch eine unsichtbare Seite. Führt kein Weg heraus, ist es die Tastaturfalle aus 2.1.2.

Prüfen Sie dabei den Kaufweg, nicht die Startseite – die entscheidenden Elemente liegen in Filter, Warenkorb und Kasse (siehe barrierefreier Checkout).

Sechs Fehlerbilder, die immer wiederkommen

Diese sechs Bauformen erklären den größten Teil der Befunde. Alle sind mit der Maus unauffällig und fallen im Test von eben in Sekunden auf.

• Positiver tabindex. tabindex="1", tabindex="5", tabindex="12": Wer so nummeriert, holt diese Elemente vor alle anderen; der Fokus springt von der Kopfzeile ins Newsletterfeld im Fuß und zurück (2.4.3). Meist sollte damit eine Reihenfolge erzwungen werden, die sich im Quelltext leichter hätte ordnen lassen.
• Der entfernte Fokusrahmen. Eine Zeile im Stylesheet nimmt jedem Element die Markierung. Sie steht dort, weil der Standardrahmen beim Mausklick störte – und trifft dann auch die Tastatur (2.4.7).
• Galerien und Slider nur mit der Maus. Pfeile und Punkte sind div-Elemente mit Klick-Handler; mit dem Tabulator ist keiner erreichbar (2.1.1). Viele Slider erzeugen ihre Bildkopien zudem erst im Browser – im Quelltext des Betreibers stehen sie gar nicht. In unserer Erhebung 2026 fanden sich fokussierbare Elemente in ausgeblendeten Bereichen auf 5 von 85 Websites, der typische Slider-Fall.
• Menüs, die nur beim Überfahren aufgehen. Das Untermenü hängt an :hover. Ohne Maus kein Überfahren – und kein Weg zu den Kategorien, die nur dort verlinkt sind (2.1.1).
• Dialoge ohne Fokusfang. Der Dialog erscheint, der Fokus bleibt dahinter; man tabbt durch die Seite darunter und findet die Schaltfläche zum Schließen nie. Richtig ist: Fokus beim Öffnen hinein, Tabulator bleibt darin, Escape schließt, Fokus kehrt zurück (2.4.3; sperrt der Dialog danach den Rückweg, zusätzlich 2.1.2). Der häufigste Dialog dieser Art ist das Einwilligungsbanner – dazu der Ratgeber zu barrierefreien Consent-Bannern.
• Klickbare div-Elemente. Die Sammelursache hinter den meisten anderen Punkten: keine Rolle, kein Fokus, keine Taste (2.1.1, 4.1.2).

<!-- Kein Fokus, keine Rolle, keine Taste -->
<div class="btn" onclick="inDenWarenkorb()">In den Warenkorb</div>

<!-- Bedienbar, ohne eine einzige Zeile mehr JavaScript -->
<button type="button" class="btn" onclick="inDenWarenkorb()">
  In den Warenkorb
</button>

Das native Element bringt Fokus, Rolle, Eingabetaste und Leertaste mit – der billigste Fix im ganzen Feld, weil er nichts hinzufügt, sondern ersetzt.

Einen Fokus bauen, den man sieht

2.4.7 verlangt einen Bedienmodus, in dem der Tastaturfokus sichtbar ist – mehr nicht, weder Farbe noch Form sind vorgeschrieben. Das Kriterium fällt trotzdem oft aus, weil eine einzige Zeile die Voreinstellung des Browsers abräumt, ohne Ersatz zu liefern.

/* Die Zeile, die das Kriterium reißt: der Rahmen fällt für alle weg */
:focus { outline: none; }

/* Stattdessen: sichtbar bei Tastaturbedienung, ruhig beim Mausklick */
:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

/* Auf farbigen Schaltflächen mit heller Schrift: Markierung nach innen */
button:focus-visible {
  outline-offset: -3px;
}

:focus-visible löst den Zielkonflikt, aus dem die erste Zeile entstanden ist: Der Browser zeigt die Markierung bei Tastaturbedienung und lässt sie beim Mausklick weg. Damit ist der gestalterische Grund für outline: none entfallen. outline-offset setzt den Rahmen vom Element ab, currentColor nimmt die Textfarbe – für Fließtext und Links auf dem Seitenhintergrund genügt das. Bei einer farbigen Schaltfläche mit heller Schrift greift es nicht, und das ist gemessen: Die Umrandung wird weiß und liegt durch den Abstand auf der weißen Seite (1,00:1). Deshalb die zweite Regel mit negativem Abstand – dieselbe Umrandung auf der Schaltfläche ergibt 11,39:1. Wie deutlich die Markierung ausfallen muss, fasst die WCAG 2.2 in 2.4.13 Fokus-Darstellung genauer, allerdings auf Stufe AAA und damit außerhalb dessen, worauf die EN 301 549 verweist. Neu auf Stufe AA ist 2.4.11 Fokus nicht verdeckt (Minimum): Der fokussierte Bereich darf nicht hinter einer klebenden Kopfzeile oder einer Cookie-Leiste verschwinden – mehr dazu im Ratgeber zum Unterschied zwischen WCAG 2.1 und 2.2.

Eine Ausnahme nehmen wir bei eigenen Messungen ausdrücklich heraus: eingebettete Fenster. Springt der Fokus auf ein iframe, wandert er in das eingebettete Dokument, und dessen Fokusanzeige gehört dem, der es ausliefert – dem Kartendienst, dem Videoportal, dem Buchungswerkzeug. Ein Befund, dem jemand folgen kann, ohne dass sich etwas ändert, ist schlimmer als keiner. Hier hilft kein eigenes Stylesheet, sondern nur eine Frage an den Anbieter – dieselbe wie bei einer eingebundenen Terminbuchung.

Was Automatik behebt und was Umbau ist

Wir beheben die messbaren technischen Verstöße nach WCAG 2.1 AA / EN 301 549 im Quelltext. Die Grenze verläuft an einer Frage: Gibt es genau eine richtige Korrektur, und ändert sie nichts am Verhalten? Zweimal ja, dann kann eine Maschine sie schreiben. Sonst hieße es raten – das Gegenteil von Genauigkeit.

Die vierte Zeile erklärt, warum automatische Behebung nicht einfach „mehr“ sein darf. Einen fehlenden Zustand am Reiter wird man mit einem Handgriff los, indem man die Rolle entfernt. Danach meldet kein Werkzeug mehr etwas – und ein Mensch mit Vorlesesoftware erfährt nicht mehr, welcher Reiter geöffnet ist. Der Befund wäre weg, die Barriere größer. Aus demselben Grund ist ein Skript, das eine Website erst im Browser umbaut, hier keine Antwort (siehe Overlays und Barrierefreiheit). Der Aufwand bemisst sich nach Vorlagen, nicht nach Elementen – die Rechnung steht in Was kostet die BFSG-Umsetzung.

Die Checkliste für den Zehn-Minuten-Test

Fünf Stationen, zwei Minuten je Station. Nehmen Sie den Weg, den Ihre Kundschaft nimmt, und notieren Sie nur, wo Sie zur Maus greifen mussten.

1. Startseite und Banner

   Seite neu laden. Erster Tabulatordruck: Erscheint ein Sprunglink zum Inhalt? Zweiter: Landet der Fokus im Einwilligungsbanner, und lässt es sich vollständig bedienen und schließen?

2. Navigation und Suche

   Öffnet sich das Untermenü mit der Tastatur, und kommen Sie an die Unterpunkte? Danach ins Suchfeld: tippen, Eingabetaste. Wo landet der Fokus – in der Ergebnisliste oder wieder am Seitenanfang?

3. Kategorie und Filter

   Filter sind Auswahllisten, Kästchen oder Schieberegler: Pfeiltasten und Leertaste ausprobieren. Ändert sich die Liste lautlos? Bleibt der Fokus dort, wo Sie ihn gelassen haben?

4. Produktseite

   Galerie durchtabben, Variante wählen, Menge ändern, in den Warenkorb legen. Hier stecken die meisten nachgebauten Bedienelemente – besonders die Mengenauswahl mit den kleinen Plus- und Minus-Feldern.

5. Warenkorb, Formular, Rückweg

   Bis zum letzten Feld vor dem Absenden, dann mit Umschalt und Tabulator den ganzen Weg zurück. Der Rückweg deckt vertauschte Reihenfolgen auf; ein leeres Absenden zeigt, ob die Fehlermeldung den Fokus bekommt.

Zehn Minuten reichen für einen belastbaren ersten Befund. Über Alternativtexte, Kontraste und Formularbeschriftungen sagen sie nichts – dafür ist ein Werkzeug schneller, siehe die häufigsten Barrierefreiheits-Fehler. Beide zusammen ergeben ein Bild, jedes für sich ein halbes.

Was dieser Test nicht zeigt

Wir klicken auf fremden Websites nichts an. Der Tabulator bewegt nur den Fokus; ein Klick könnte bestellen, abmelden oder löschen. Unsere Messung von außen prüft deshalb nicht, ob ein Zustand beim Betätigen wirklich umspringt. Das gehört in eine Arbeitskopie, also in einen beauftragten Umbau – nicht in einen Scan.

Ob eine Reihenfolge sinnvoll ist, entscheidet ein Mensch. 2.4.3 verlangt dort, wo die Reihenfolge der Navigation die Bedeutung oder Bedienung beeinflusst, eine Reihenfolge, die „Bedeutung und Bedienbarkeit aufrecht erhält“. Das lässt sich nicht rechnen, man muss den Inhalt verstehen – wie bei der Frage, ob eine Fehlermeldung hilft oder nur meldet.

Automatisierte Prüfung deckt die maschinell prüfbaren Kriterien ab; eine vollständige Konformitätsbewertung erfordert zusätzlich manuelle Prüfung. Bei der Tastaturbedienung ist der Abstand zwischen beidem größer als bei jedem anderen Thema.

Und keine Rechtsberatung. § 14 Absatz 1 BFSG sieht vor, dass ein Dienstleistungserbringer seine Dienstleistung nur anbieten oder erbringen darf, wenn sie die Anforderungen der Rechtsverordnung nach § 3 Absatz 2 erfüllt und er die Informationen nach Anlage 3 Nummer 1 erstellt und für die Allgemeinheit in barrierefreier Form zugänglich gemacht hat; § 37 Absatz 2 BFSG nennt dafür eine Geldbuße „bis zu hunderttausend Euro“; für die übrigen Tatbestände des Absatzes 1 liegt der Rahmen bei zehntausend Euro. Das Verfahren davor beschreibt der Ratgeber zum Bußgeld nach § 37 BFSG; ob ein Betrieb betroffen ist, hängt unter anderem an der Kleinstunternehmer-Ausnahme. Im Zweifel beurteilen das Anwältinnen und Anwälte, nicht wir.

Häufige Fragen

Dieser Artikel ist eine technische Einordnung und keine Rechtsberatung. Quellen: Gesetz zur Stärkung der Barrierefreiheit von Produkten und Dienstleistungen (BFSG), insbesondere § 3 Absatz 1 und 2, § 14 Absatz 1 sowie § 37 Absatz 2, Wortlaut abgerufen bei gesetze-im-internet.de am 05.09.2026; WCAG 2.1 in der deutschen Übersetzung von Aktion Mensch e. V., die das W3C als nicht autorisierte Übersetzung vom 15. Juni 2022 führt (verbindlich ist die englische Originalfassung der W3C-Empfehlung), Erfolgskriterien 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.5.3 und 4.1.2, abgerufen am 05.09.2026 über das Übersetzungsverzeichnis des W3C; EN 301 549 (Abschnitte 9.2.1.1, 9.2.1.2, 9.2.4.3, 9.2.4.7, 9.2.5.3 und 9.4.1.2) nur als Fundstelle genannt, ohne Zitat aus dem Normtext; eigene Messung an unserem Demo-Testshop vom 04.09.2026, nachgemessen am 05.09.2026, Prüfengine axe-core über Playwright gegenüber unserer eigenen Tastaturmessung; eigene Erhebung 2026 über 85 automatisiert geprüfte Websites mittelständischer Betriebe, Tagset WCAG 2.1 Stufen A und AA.