Tastaturbedienung prüfen: Barrieren ohne Maus finden

Was ein automatischer Lauf von der Tastatur sieht

Die Abdeckung automatischer Prüfung wird gern als eine Zahl gehandelt, es sind aber zwei - und sie beantworten verschiedene Fragen. Gemessen an der Menge der Befunde nennt die Herstellerdokumentation der quelloffenen Prüfmaschine 57 Prozent (Deque, axe-core). Die Auswertung echter Erstaudits kommt auf einen sehr ähnlichen Wert: Von 294.958 Befunden auf über 13.000 Seiten und Seitenzuständen wurden 57,38 Prozent maschinell gefunden (Deque). Das klingt nach einer soliden Grundlage und ist es auch - solange man versteht, was diese Quote zählt. Sie zählt Fehler, nicht Fehlerarten. Ein einziges fehlendes Alternativtextmuster, das in einer Schleife hundertfach ausgegeben wird, erzeugt hundert Befunde. Eine Fokusfalle erzeugt einen einzigen - und wird nicht gefunden.

Rechnet man stattdessen über die Erfolgskriterien, fällt das Bild deutlich anders aus. In derselben Auswertung deckten die automatischen Regeln 16 von 50 Erfolgskriterien der Stufe AA ab (Deque). Für die beiden Kriterien, um die es bei der Tastaturbedienung im Kern geht - 2.4.3 Fokus-Reihenfolge und 2.4.7 Fokus sichtbar - lag der Anteil der maschinell gefundenen Befunde bei null: Sie kamen ausschließlich aus der Handprüfung (Deque). Wer also einen grünen Prüfbericht als Beleg für Tastaturzugänglichkeit liest, liest ihn falsch. Welche Fehlerarten der maschinelle Teil dafür sehr zuverlässig findet, ist im Beitrag zu den häufigsten WCAG-Fehlern auf Firmenwebsites aufgeschlüsselt.

Die Kriterien, an denen die Tastatur scheitert

Tastaturzugänglichkeit ist kein einzelnes Kriterium, sondern eine Kette. Ganz vorn steht 2.1.2 Keine Tastaturfalle auf Stufe A - der niedrigsten Konformitätsstufe. Die Formulierung ist knapp: Wenn der Fokus über eine Tastaturschnittstelle auf ein Element bewegt werden kann, muss er sich auch wieder davon wegbewegen lassen (W3C). Das Kriterium fällt zusätzlich unter die Bedingung der Nichtbeeinträchtigung, gilt also selbst dann, wenn der betroffene Teil der Seite gar nicht Gegenstand der Konformitätserklärung ist. Eine Tastaturfalle ist damit kein Schönheitsfehler, sondern ein Verstoß, an dem die gesamte Erklärung hängt.

WCAG 2.2 hat diese Kette im Oktober 2023 erweitert. Die Empfehlung, erstmals am 5. Oktober 2023 veröffentlicht und am 12. Dezember 2024 in überarbeiteter Fassung neu herausgegeben, führt neun neue Erfolgskriterien ein - 2.4.11, 2.4.12, 2.4.13, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8 und 3.3.9 (W3C); zugleich entfiel 4.1.1 Parsing. Drei davon betreffen den Fokus unmittelbar, und zwei davon beschreiben genau die Fehler, die eine Maschine schlecht sehen kann: dass eine klebende Leiste das fokussierte Element verdeckt, und dass die Fokusanzeige zu schwach ausfällt. Was das für die Umsetzungsfrist bedeutet, ordnet der Beitrag zu den BFSG-Anforderungen an Website-Betreiber ein.

Fokusfalle: der Tabulator kommt nicht mehr heraus

Der häufigste Weg in eine Fokusfalle führt über den Eingriff in die Reihenfolge selbst. Startseiten trugen im Februar 2026 im Schnitt 30,4 Vorkommen von tabindex=0 oder tabindex=-1 - ein Zuwachs von 17 Prozent gegenüber dem Vorjahr und von fast 300 Prozent seit 2020 (WebAIM Million 2026). Jedes einzelne dieser Vorkommen ist zunächst harmlos: tabindex=0 nimmt ein Element in die natürliche Reihenfolge auf, tabindex=-1 nimmt es heraus und macht es nur für Skripte fokussierbar. Problematisch wird die Menge. Wo Hunderte von Stellen die Reihenfolge anfassen, entsteht ein Zustand, den niemand mehr im Kopf hat - und der sich nur noch durch Abfahren feststellen lässt.

• Der Dialog ohne Rückweg: Ein modales Fenster fängt den Fokus ein, damit die Tastatur nicht in den Hintergrund läuft. Fehlt der Ausstieg über die Abbruchtaste oder der Rücksprung auf das auslösende Element, bleibt der Fokus im Fenster.
• Der Rahmen mit fremdem Inhalt: Ein eingebetteter Kartenausschnitt oder ein Videoplayer übernimmt die Tastatursteuerung und gibt sie nicht zurück, weil die eingebettete Anwendung eigene Tastenbelegungen setzt.
• Das nachgebaute Auswahlfeld: Die Auf- und Ab-Tasten bewegen die Auswahl, der Tabulator wird abgefangen, und aus der geöffneten Liste führt kein dokumentierter Weg heraus.
• Der unsichtbare Rest: Ein ausgeblendetes Menü bleibt im Fokusbaum, weil es nur per Transparenz oder Verschiebung aus dem Bild geschoben wurde. Der Fokus wandert in einen Bereich, den niemand sieht.
• Die Bestätigungsschicht: Ein Einwilligungsdialog liegt über der Seite, ohne den Fokus zu halten. Der Tabulator läuft dahinter weiter, die Auswahl bleibt unerreichbar.

Die härtere Variante sind positive tabindex-Werte, die die Reihenfolge künstlich umsortieren. Sie sind selten: Der Crawl des Web Almanac fand sie auf 3,7 Prozent der Seiten in der Desktop-Ansicht und auf 3,4 Prozent in der mobilen (Web Almanac 2025). Wo sie vorkommen, wiegen sie schwer, weil ein einziger positiver Wert die gesamte natürliche Reihenfolge hinter sich zieht: Alle Elemente mit positivem Wert kommen zuerst, danach erst der Rest des Dokuments. Ein Formularfeld mit tabindex=1 im Fußbereich holt den Fokus vor die Navigation.

Verdeckter Fokus: fokussiert, aber nicht zu sehen

Seit WCAG 2.2 gibt es dafür ein eigenes Kriterium. 2.4.11 Fokus nicht verdeckt auf Stufe AA verlangt, dass ein Bedienelement, das den Tastaturfokus erhält, nicht vollständig durch vom Autor erstellte Inhalte verborgen wird (W3C). Als typische Ursachen nennt das erläuternde Dokument klebende Fußzeilen, klebende Kopfzeilen und nicht-modale Dialoge. Der Fehler ist deshalb so verbreitet, weil er erst im Zusammenspiel entsteht: Die Leiste ist korrekt, das Formularfeld ist korrekt, und die Kombination aus beidem schiebt das fokussierte Feld unter die Leiste, sobald die Seite an dieser Stelle steht.

Die Trennlinie zwischen der Stufe AA und der strengeren Stufe AAA verläuft beim Wort vollständig: Auf Stufe AA ist ein teilweise verdecktes Element noch zulässig, auf Stufe AAA nicht mehr. In der Praxis ist die Unterscheidung heikel, weil ein zur Hälfte verdeckter Fokusrahmen für viele Menschen bereits nicht mehr erkennbar ist. Wer die Prüfung selbst starten will, bevor er sie in einen festen Takt legt, findet im BFSG-Schnellcheck einen Einstieg über eine einzelne Adresse.

Der gelöschte Fokusrahmen

Die Voraussetzung für eine unsichtbare Tastaturbedienung wird meist bewusst geschaffen. Im Crawl des Web Almanac entfernten 2025 rund 67 Prozent der Seiten den vom Browser vorgegebenen Fokusrahmen ausdrücklich - 14 Prozent mehr als im Jahr davor (Web Almanac 2025). Der Grund ist gestalterisch: Der Standardrahmen erscheint auch beim Klicken mit der Maus, und das wirkt auf vielen Oberflächen störend. Die saubere Antwort darauf existiert seit Jahren und heißt :focus-visible - sie zeigt den Rahmen nur, wenn die Eingabe über die Tastatur kam. Verbreitet ist sie trotzdem kaum: rund ein Viertel der Seiten in der Desktop-Ansicht setzt sie ein (Web Almanac 2025).

/* Falsch: entfernt den Rahmen für alle Eingabearten */
:focus { outline: none; }

/* Richtig: Maus ohne Rahmen, Tastatur mit deutlichem Rahmen */
:focus { outline: none; }

:focus-visible {
  outline: 3px solid #004d43;   /* mehr als die geforderten 2 CSS-Pixel */
  outline-offset: 2px;          /* Abstand hält den Rahmen lesbar */
  border-radius: 2px;
}

/* Klebende Leisten: Platz freihalten, damit der Fokus nicht darunter rollt */
:root { scroll-padding-top: 72px; scroll-padding-bottom: 64px; }

/* Sprunglink: sichtbar, sobald er den Fokus hat */
.sprunglink {
  position: absolute;
  transform: translateY(-120%);
}
.sprunglink:focus-visible {
  transform: translateY(0);
}

Wie stark der Rahmen ausfallen muss, beschreibt WCAG 2.2 erstmals in messbaren Größen. Das Kriterium 2.4.13 Fokus-Darstellung auf Stufe AAA verlangt eine Fläche, die mindestens so groß ist wie ein zwei CSS-Pixel starker Umriss um das unfokussierte Element (W3C), und dazu ein Kontrastverhältnis von mindestens 3:1 zwischen fokussiertem und unfokussiertem Zustand. Das deutsche Prüfverfahren fragt denselben Wert getrennt ab: Der Prüfschritt zur aktuellen Fokusposition prüft, ob der Kontrastabstand zwischen fokussiertem und unfokussiertem Zustand mindestens 3:1 beträgt (BITV-Test), und zwar mit aktiviertem JavaScript in zwei Browsern nacheinander. Wie sich solche Werte nach jedem Deploy nachhalten lassen, beschreibt der Beitrag zum kontinuierlichen Überwachen von WCAG-Regressionen.

Sprunglinks: selten vorhanden, oft kaputt

Der Sprunglink zum Hauptinhalt ist die billigste Tastaturhilfe, die es gibt: eine Zeile HTML, ein wenig CSS, und schon muss niemand mehr durch sechzig Navigationseinträge, um zum ersten Absatz zu kommen. Vorhanden ist er trotzdem selten. Im Februar 2026 trugen 17,1 Prozent der untersuchten Startseiten einen solchen Link, gegenüber 15,3 Prozent im Vorjahr (WebAIM Million 2026). Und von den vorhandenen war jeder zehnte defekt - entweder so versteckt, dass er nicht erreichbar war, oder mit einem Sprungziel, das es auf der Seite gar nicht gab (WebAIM Million 2026).

Ein zweiter Crawl kommt auf höhere Werte, weil er nicht nur Startseiten betrachtet: Der Anteil stieg dort von 19,7 Prozent im Jahr 2021 auf 25,65 Prozent in der Desktop-Ansicht und 26,23 Prozent in der mobilen (Web Almanac 2025). Beide Erhebungen zeigen dieselbe Richtung und dieselbe Größenordnung des Problems: Drei von vier Seiten zwingen Tastaturnutzer durch den kompletten Kopfbereich. Der zweite Teil des Befunds ist der unangenehmere, weil er sich wie eine erledigte Aufgabe anfühlt. Ein Sprungziel, das nach einem Umbau nicht mehr existiert, ist derselbe Fehlertyp wie ein toter interner Verweis - und wird mit denselben Mitteln gefunden, siehe den Beitrag zum automatisierten Aufspüren toter Verweise.

Nachgebaute Bedienelemente und stumme Beschriftungen

Ein Element, das aussieht wie eine Schaltfläche, ist noch keine. Der Anteil der Seiten, die eine Schaltfläche über die entsprechende ARIA-Rolle nachbauen, ist um rund 4 Prozent gestiegen und liegt bei 53 Prozent in der Desktop-Ansicht und 54 Prozent in der mobilen (Web Almanac 2025). Die Rolle allein sagt der Sprachausgabe, was das Element sein soll - sie bringt weder Fokussierbarkeit noch Tastenbehandlung mit. Ein div mit role=button braucht zusätzlich tabindex=0 und eine eigene Behandlung der Eingabe- und Leertaste. Fehlt eines von beiden, ist die Funktion mit der Maus vorhanden und mit der Tastatur nicht.

Der Durchlauf: acht Stationen ohne Maus

Die Prüfung selbst braucht kein Werkzeug, nur Disziplin. Man legt die Maus beiseite, setzt den Fokus mit einem Klick in die Adresszeile und arbeitet sich von dort durch die Seite. Entscheidend ist, dass jede Station protokolliert wird - nicht nur die auffälligen. Ein Protokoll mit acht Zeilen ist auch dann ein Ergebnis, wenn alle acht in Ordnung sind, und es ist der Bezugspunkt für den nächsten Durchlauf.

1. Startpunkt setzen: Fokus in die Adresszeile, dann mit dem Tabulator in das Dokument wechseln. Die erste Station sollte der Sprunglink sein - erscheint er nicht sichtbar, ist der erste Befund schon da.
2. Reihenfolge mitschreiben: Jede Station durchnummerieren und mit der sichtbaren Anordnung vergleichen. Springt der Fokus von der Kopfzeile in den Fußbereich und wieder zurück, liegt ein Verstoß gegen 2.4.3 vor.
3. Sichtbarkeit an jeder Station prüfen: Ist der Fokusrahmen erkennbar, und liegt das Element vollständig frei? Klebende Leisten zeigen sich hier, nicht vorher.
4. Rückwärts laufen: Mit Umschalt und Tabulator zurück. Die Rückwärtsreihenfolge deckt Fallen auf, die vorwärts nicht auffallen, weil Skripte den Fokus nur in eine Richtung umlenken.
5. Jeden Dialog öffnen und wieder verlassen: Öffnen, mit dem Tabulator einmal umlaufen, mit der Abbruchtaste schließen. Der Fokus muss auf dem auslösenden Element landen, nicht am Seitenanfang.
6. Nachbauten gezielt betätigen: Alles, was wie eine Schaltfläche aussieht, mit der Eingabetaste und mit der Leertaste auslösen. Reagiert nur eine der beiden, fehlt die Tastenbehandlung.
7. Formulare bis zum Absenden führen: Fehlermeldungen müssen den Fokus bekommen oder angesagt werden. Ein rot umrandetes Feld ohne Fokuswechsel bleibt für Tastaturnutzer unbemerkt.
8. Bei 200 Prozent Vergrößerung wiederholen: Klebende Leisten wachsen mit, der verfügbare Bereich schrumpft - verdeckter Fokus tritt hier deutlich häufiger auf als bei voller Breite.

Die Konsolenzeilen ersetzen den Durchlauf nicht, sie beschleunigen ihn. Sobald ein Befund feststeht, gehört er in einen wiederholbaren Ablauf, damit er nicht beim nächsten Umbau zurückkommt. Genau dafür sind aufgezeichnete Bedienabläufe gedacht: Ein Skript, das die acht Stationen in derselben Reihenfolge abfährt, ist in wenigen Minuten aufgesetzt und läuft danach unbeaufsichtigt - das Vorgehen ist im Beitrag zum Aufzeichnen von Browserabläufen beschrieben, die technische Seite im Browser-Monitoring.

Warum ein einmaliger Befund nicht trägt

Barrierefreiheitsfehler sind auf Startseiten die Regel: 95,9 Prozent der untersuchten Startseiten wiesen erkennbare WCAG-Verstöße auf (WebAIM Million 2026). Insgesamt fanden sich 56.114.377 Einzelfehler, im Schnitt 56,1 je Seite (WebAIM Million 2026). Diese Zahlen stammen aus einem automatischen Lauf über die Startseiten der eine Million meistbesuchten Websites - die manuell zu prüfenden Tastaturprobleme kommen darauf noch obendrauf. Der Grund für die Beharrlichkeit steht in derselben Erhebung: Die durchschnittliche Zahl der Seitenelemente stieg im Februar 2026 auf 1437 je Startseite, ein Zuwachs von 22,5 Prozent in nur einem Jahr (WebAIM Million 2026).

Die durchschnittliche Zahl der Seitenelemente stieg im Februar 2026 auf 1437 je Startseite - ein Anstieg um 22,5 Prozent in nur einem Jahr.

— WebAIM Million 2026, sinngemäß übersetzt

Mehr Elemente heißt mehr Stationen, die eine Tastatur abfahren muss, und mehr Stellen, an denen eine Reihenfolge kippen kann. Ein Befund von vor sechs Monaten sagt über den heutigen Zustand wenig, wenn seitdem zwölf Mal ausgeliefert wurde. Deshalb gehört die Barrierefreiheitsprüfung an dieselbe Stelle wie jede andere Zustandsprüfung: in einen festen Takt, mit Vergleich zum Vorlauf und mit einer Meldung, sobald sich etwas verschlechtert. Das BFSG-Modul vergleicht die Befunde je Adresse gegen den Vorlauf; die technische Verwandtschaft zu einer tief prüfenden Zustandsabfrage beschreibt der Beitrag zum Health-Check-Endpunkt.

Wer betroffen ist und was auf dem Spiel steht

Die Gruppe, um die es geht, ist keine Randgruppe. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen Menschen mit schwerer Behinderung, das entspricht 9,4 Prozent der Bevölkerung (Statistisches Bundesamt); gezählt sind Menschen mit gültigem Ausweis und einem Grad der Behinderung von mindestens 50. Weltweit schätzt die Gesundheitsorganisation die Zahl der Menschen mit einer erheblichen Behinderung auf 1,3 Milliarden, rund 16 Prozent der Weltbevölkerung (WHO). Nicht alle davon sind auf Tastaturbedienung angewiesen - aber jede motorische Einschränkung, jede vorübergehende Verletzung und jede Sprachausgabe führt über dieselbe Eingabeart.

Wie sich das im Alltag auswirkt, zeigt die größte laufende Befragung von Sprachausgabe-Nutzern. Sie erhielt 1539 gültige Antworten, erhoben im Dezember 2023 und Januar 2024 (WebAIM Screen Reader Survey 10); 1372 der Befragten, also 89,9 Prozent, nutzen eine Sprachausgabe aufgrund einer Behinderung. In der Rangliste der problematischsten Elemente steht fehlende Tastaturzugänglichkeit auf Rang 5 von 12 (WebAIM Screen Reader Survey 10) - hinter CAPTCHA, unerwartet reagierenden Bedienelementen, nichtssagenden Links und sich unangekündigt ändernden Bereichen, aber vor komplexen Formularen (Rang 7) und fehlenden oder falschen Überschriften (Rang 8), die in Projekten oft deutlich mehr Aufmerksamkeit bekommen.

Rechtlich hat sich der Rahmen bereits geschlossen. Die europäische Richtlinie gilt für Dienstleistungen, die für Verbraucher nach dem 28. Juni 2025 erbracht werden (Richtlinie EU 2019/882). Das deutsche Umsetzungsgesetz sieht für den Fall, dass eine betroffene Dienstleistung nicht barrierefrei angeboten wird, eine Geldbuße bis zu hunderttausend Euro vor (BFSG, § 37 Absatz 2); für die übrigen Fälle liegt der Rahmen bei bis zu zehntausend Euro. Bestandslösungen dürfen nach der Übergangsbestimmung nicht länger als bis zum 27. Juni 2030 unverändert fortbestehen (BFSG, § 38 Absatz 1). Welche Abmahnrisiken daneben bestehen, ordnet der Beitrag zur Abmahnlage bei Barrierefreiheit ein.

Vom Befund zur Behebung

Ein Protokoll mit acht Stationen ist noch keine Behebung, aber es ist die Grundlage für eine Priorisierung, die sich begründen lässt. Die Reihenfolge ergibt sich aus der Konformitätsstufe und aus der Zahl der betroffenen Abläufe: Eine Falle in der Bezahlstrecke wiegt schwerer als ein fehlender Sprunglink auf einer Randseite, und ein Verstoß gegen ein Kriterium der Stufe A wiegt schwerer als einer gegen Stufe AAA.

• Zuerst die Stufe A: Tastaturfallen und unerreichbare Funktionen blockieren die Nutzung vollständig und hängen zusätzlich an der Bedingung der Nichtbeeinträchtigung.
• Dann die Fokusanzeige: Ein wiederhergestellter Rahmen über :focus-visible ist meist eine Änderung an einer einzigen Stelle im Stylesheet und wirkt auf der gesamten Seite.
• Dann die Reihenfolge: Positive tabindex-Werte entfernen und die Anordnung im Quelltext an die sichtbare Anordnung angleichen - das behebt oft mehrere Befunde zugleich.
• Dann die Nachbauten: Wo eine native Schaltfläche möglich ist, ersetzt sie den Nachbau samt Rollenangabe, Fokussierbarkeit und Tastenbehandlung.
• Zuletzt das Feinmaß: Umrissstärke und Kontrast der Fokusanzeige, Sprunglinks auf Unterseiten, Reihenfolge in selten benutzten Bereichen.

Was danach folgt, ist der Nachweis. Eine Erklärung zur Barrierefreiheit, die auf einem einmaligen Befund beruht, altert schnell; belastbar wird sie erst mit einem wiederkehrenden Prüflauf und einer Ablage der Ergebnisse, die auch in einem halben Jahr noch zeigt, wann welcher Zustand galt. Für die Berichtsseite dieser Ergebnisse eignet sich dieselbe Mechanik wie für Verfügbarkeitsberichte, beschrieben unter Reporting und Statusseiten. Und weil ein Umbau der Navigation regelmäßig beides zugleich verändert - Fokusreihenfolge und Adressstruktur - lohnt der Blick auf die Überwachung der Canonical-Angaben im selben Zug.