Tastaturbedienung der Website testen: So prüfen Sie ohne Maus

Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026

Drücken Sie einmal Tab auf Ihrer Website. Sehen Sie, wo der Fokus landet? Können Sie von dort aus mit der Tastatur allein zur Navigationsleiste, ins Kontaktformular und wieder zurück? Dieser Test dauert keine fünf Minuten und zeigt Ihnen mehr über die Zugänglichkeit Ihrer Website als jeder automatische Scanner.

Tastaturbedienung ist kein Randthema für Spezialisten. Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025, und die technische Basis ist die Norm EN 301 549, die auf WCAG 2.2 verweist. Fünf konkrete Kriterien betreffen die Tastaturbedienung. Welche das sind, was sie verlangen und wie der Test Schritt für Schritt funktioniert, erklärt dieser Ratgeber.

Wer auf die Tastatur angewiesen ist

Die WAI (Web Accessibility Initiative) nennt drei Hauptgruppen, die auf eine funktionierende Tastaturbedienung angewiesen sind:

Menschen mit motorischen Einschränkungen können keine Maus bedienen. Das kann eine dauerhafte Lähmung sein, eine Erkrankung wie Multiple Sklerose oder auch ein gebrochenes Handgelenk. Viele nutzen alternative Eingabegeräte, die sich wie eine Tastatur verhalten: Mundstäbe, Fußpedale, Eye-Tracker, Schalter. Diese Geräte emulieren Tastaturbefehle. Wenn eine Website bestimmte Mausbewegungen verlangt (Hover-Menüs, die nur bei Überfahren aufgehen), sind diese Nutzer ausgesperrt.

Blinde und stark sehbehinderte Menschen bedienen Screenreader fast immer über die Tastatur. Ein Screenreader liest den Inhalt der Seite vor und übermittelt dabei Fokus-Position und Elementtyp. Wandert der Fokus durch die Seite, hört der Nutzer: „Schaltfläche: Absenden“, „Link: Zur Startseite“, „Eingabefeld: E-Mail-Adresse“. Fehlt ein sichtbarer oder programmatischer Fokusindikator, verliert der Screenreader seine Orientierung.

Menschen mit wiederholten Belastungsverletzungen (RSI, repetitive strain injury) vermeiden Mausbewegungen aus medizinischen Gründen. Das gilt häufig für Berufsgruppen, die viele Stunden täglich tippen.

Dazu kommt eine größere Gruppe, die nicht dauerhaft eingeschränkt ist: ältere Menschen, die die Maus schwer kontrollieren, temporär Verletzte, Power-User, die grundsätzlich lieber tippen als klicken. Nach Angaben des Statistischen Bundesamts lebten in Deutschland zuletzt rund 7,9 Millionen Menschen mit einer anerkannten Schwerbehinderung. Die Gruppe derer, die gelegentlich oder situativ auf Tastaturbedienung angewiesen ist, ist noch deutlich größer.

Die fünf WCAG-Kriterien zur Tastaturbedienung

WCAG 2.2 enthält fünf direkt einschlägige Kriterien für Tastaturbedienung. Drei davon (2.1.1, 2.1.2, 2.4.3) sind Stufe A, zwei (2.4.7, 2.4.11) sind Stufe AA. Alle fünf sind BFSG-Pflicht. Das sechste Kriterium (2.4.13) liegt auf der freiwilligen Stufe AAA.

Das Kriterium 2.4.11 ist neu in WCAG 2.2 und häufig übersehen. Es greift genau dann, wenn ein Sticky-Header, ein schwebendes Chat-Widget oder ein Cookie-Banner ein fokussiertes Element komplett überdeckt. Vollständige Verdeckung ist ein Verstoß gegen Stufe AA. Eine partielle Überlappung ist zulässig, solange der Nutzer das Element noch wahrnehmen kann.

Kriterium 2.4.13 liegt dagegen auf Stufe AAA und ist damit keine Pflichtanforderung des BFSG. Es lohnt sich trotzdem als Zielwert, denn ein klar konturierter, kontrastreicher Fokusring verbessert die Usability für alle Tastaturnutzer spürbar. Was Farbkontraste generell bedeuten, erklärt der Ratgeber Farbkontrast nach WCAG richtig prüfen.

Welche Taste wofür gilt

Eigene Tastaturbelegungen (etwa Strg+Shift+X für eine benutzerdefinierte Funktion) sind zulässig, solange die Standard-Navigation davon unberührt bleibt. Das ARIA Authoring Practices Guide (APG) des W3C legt für komplexe Widgets wie modale Dialoge oder Menü-Schaltflächen die erwarteten Interaktionsmuster fest.

Schritt-für-Schritt-Tastaturtest

Dieser Test kommt ohne Lizenz und ohne Vorkenntnisse aus. Planen Sie 20 bis 30 Minuten für eine mittelgroße Website ein.

1. Browser vorbereiten: Öffnen Sie Chrome oder Firefox ohne Erweiterungen in einem neuen Fenster. Erweiterungen können das Fokusverhalten beeinflussen. Auf macOS müssen Sie in den Systemeinstellungen unter „Tastatur“ die Option „Alle Steuerelemente mit Tab hervorheben“ aktivieren, sonst überspringt Safari und auch Chrome auf macOS bestimmte Elemente.
2. Fokus in die Seite bringen: Klicken Sie einmal in die Adressleiste und drücken Sie dann einmal Tab. Damit landet der Fokus im Seiteninhalt. Alternativ: In die Seite klicken, dann Tab drücken.
3. Navigation vorwärts: Gehen Sie mit Tab durch die gesamte Seite. Notieren Sie für jedes Element: Ist der Fokus sichtbar? Ist die Reihenfolge logisch? Kommen Sie zu jedem interaktiven Element?
4. Navigation rückwärts: Prüfen Sie Shift+Tab. Die Reihenfolge muss sich umkehren, ohne dass Elemente verschwinden oder der Fokus springt.
5. Aktivieren und interagieren: Öffnen Sie das Hauptmenü mit Enter oder den Pfeiltasten. Prüfen Sie, ob Untermenüs ebenfalls per Tastatur zugänglich sind.
6. Dialoge und Overlays: Öffnen Sie jeden modalen Dialog (Cookie-Banner, Newsletter-Popup, Kontaktformular als Overlay). Prüfen Sie: Springt der Fokus beim Öffnen in den Dialog? Bleibt der Fokus innerhalb (zirkuläres Tab-Management)? Schließt Escape den Dialog? Kehrt der Fokus zur auslösenden Schaltfläche zurück?
7. Formulare ausfüllen: Füllen Sie ein vollständiges Formular per Tastatur aus. Prüfen Sie Felder, Auswahllisten, Checkboxen und den Absende-Button. Sind Fehlermeldungen per Tastatur erreichbar?
8. Sticky-Elemente prüfen: Navigieren Sie zu Elementen, die sich in der Nähe eines Sticky-Headers oder eines eingeblendeten Banners befinden. Wird das fokussierte Element teilweise verdeckt (zulässig) oder vollständig (Verstoß gegen 2.4.11)?

Halten Sie zu jedem Fehler drei Angaben fest: Wo auf der Seite tritt er auf? Welches Element ist betroffen? Welches WCAG-Kriterium ist verletzt? Diese Liste ist die Basis für die spätere Behebung und für eine nachvollziehbare Dokumentation gegenüber der Behörde.

Typische Fehler und wie sie aussehen

Tastaturfalle

Die gefährlichste Art von Tastaturproblem: Der Nutzer gelangt in eine Komponente, aber nicht mehr heraus. Klassische Quelle ist ein modal geöffneter Dialog ohne korrektes Fokusmanagement. Das Overlay ist offen, der Fokus wandert aber weiter durch den Hintergrundinhalt, ohne die Dialog-Kontrollen zu erreichen. Das ARIA APG schreibt vor: Tab und Shift+Tab dürfen einen geöffneten modalen Dialog nicht verlassen. Escape muss ihn schließen. Fehlt beides, ist die Seite für Tastaturnutzer blockiert.

Weitere typische Fallen: eingebettete PDF-Viewer, Karten-Widgets (Google Maps, OpenStreetMap) und Karussells, die den Fokus schlucken und nicht wieder abgeben. Ein eingebettetes iframe-Element übernimmt den Fokus von außen, gibt ihn aber nicht zurück, wenn kein explizites Fokusmanagement implementiert ist.

Unsichtbarer Fokusindikator

Die häufigste Ursache ist ein globaler CSS-Reset:

/* typischer Übeltäter in Theme-Stylesheets */
* { outline: none; }
/* oder */
a:focus, button:focus { outline: 0; }

Diese Regeln entfernen den nativen Browser-Fokusrahmen aus optischen Gründen, ohne einen eigenen Ersatz zu setzen. Das Ergebnis: Wer mit der Tastatur navigiert, sieht nicht, wo er sich befindet. Ein Verstoß gegen 2.4.7. Die korrekte Lösung ist nicht, outline komplett zu verbieten, sondern einen eigenen, gut sichtbaren Fokusindikator zu definieren:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Die Pseudo-Klasse :focus-visible zeigt den Fokusring nur, wenn der Nutzer tatsächlich die Tastatur benutzt. Bei einem Mausklick bleibt er aus. Das ist technisch und gestalterisch die sauberere Lösung als :focus allein.

Falsche Fokus-Reihenfolge

Sichtbar falsch geordnete Elemente entstehen häufig durch CSS-Layouttricks: float, flexbox order oder position: absolute verschieben ein Element visuell an eine andere Stelle, ohne die DOM-Reihenfolge zu verändern. Der Tab-Fokus folgt der DOM-Reihenfolge, nicht der visuellen. Das Ergebnis: Ein Nutzer tabbt von links nach rechts, während die visuelle Anordnung von rechts nach links läuft. Das erfüllt 2.4.3 nicht mehr, wenn die Reihenfolge die Bedienbarkeit beeinträchtigt.

Ein anderer Fall: tabindex-Werte größer 0 erzwingen künstliche Reihenfolgen und sind fast immer ein Fehler. Positive tabindex-Werte zerstören den natürlichen Tabulatorfluss und machen die Reihenfolge kaum vorhersehbar. Zulässig sind nur tabindex="0" (in den natürlichen Fluss einordnen) und tabindex="-1" (programmatisch fokussierbar, aber nicht per Tab erreichbar).

Fokus komplett verdeckt (WCAG 2.4.11)

Sticky-Header sind auf vielen Websites so hoch, dass das fokussierte Element dahinter verschwindet. Wenn der Nutzer in die untere Hälfte der Seite tabbt, rutscht das Element unter den Header, bleibt fokussiert, ist aber nicht mehr sichtbar. Das verletzt Kriterium 2.4.11. Die Lösung ist ein scroll-padding-top in der Höhe des Headers, damit der Browser beim Fokussieren ausreichend Abstand nach oben hält:

html {
  scroll-padding-top: 80px; /* Höhe des Sticky-Headers */
}

Pseudo-Schaltflächen ohne Tastaturfunktion

Ein klickbares <div> oder <span> ist von Haus aus nicht per Tab erreichbar. Ohne role="button", tabindex="0" und explizite Keyboard-Event-Handler reagiert es auf keine Tastatureingabe. Das ist ein Verstoß gegen 2.1.1. Ein echtes <button>-Element bringt Fokussierbarkeit, Tastaturinteraktion und die korrekte ARIA-Rolle ohne zusätzlichen Code mit. Verwenden Sie es, wann immer eine Aktion ausgelöst wird. Für Probleme mit interaktiven Formularelementen im Allgemeinen lohnt sich der Ratgeber Barrierefreie Formulare. Wann und wie ARIA-Attribute korrekt eingesetzt werden, zeigt der Ratgeber ARIA richtig einsetzen.

Was automatische Tools leisten und wo sie enden

Werkzeuge wie Axe DevTools, WAVE oder Lighthouse prüfen statische HTML-Eigenschaften zuverlässig: fehlende Alt-Texte, Farbkontraste, fehlende Formular-Labels. Der WebAIM Million Report 2026 (achter Jahresbericht, Analyse von einer Million Startseiten) zeigt, dass 83,9 % aller Seiten Kontrastprobleme haben und 51 % fehlende Formularbeschriftungen. Beides erkennen automatische Werkzeuge zuverlässig.

Bei Tastaturproblemen sind dieselben Werkzeuge weitgehend blind. Hier ist der Grund: Eine Tastaturfalle entsteht durch Laufzeitverhalten, nicht durch statisches HTML. Axe kann prüfen, ob ein outline: none gesetzt ist. Es kann nicht prüfen, ob Ihr selbstgestalteter Fokusrahmen auch auf einem dunkelblauen Hero-Hintergrund den erforderlichen Kontrast hält. Und ob der Fokus nach dem Schließen eines modalen Dialogs korrekt zur auslösenden Schaltfläche zurückkehrt, lässt sich nur durch echtes Interagieren mit der Seite feststellen.

Kurzum: Ein grünes Lighthouse-Ergebnis im Accessibility-Score schließt erhebliche Tastaturfehler nicht aus. Der manuelle Test ist unverzichtbar. Einen Überblick über alle häufigen Fehler, die automatische Werkzeuge melden, liefert der Ratgeber Die 12 häufigsten Barrierefreiheits-Fehler. Eine vollständige Selbstprüfung in 30 Minuten zeigt Website-Barrierefreiheit selbst testen.

Praxisbeispiel: Ein Dialog, der den Fokus festhält

In einem Kundenprojekt prüften wir einen WordPress-Webauftritt mit einem Newsletter-Popup. Das Popup öffnete sich nach drei Sekunden, überdeckte die gesamte Seite und ließ sich per Maus mit einem Schließen-X oben rechts schließen.

Per Tastatur war die Situation eine andere: Der Fokus sprang beim Öffnen nicht in das Popup-Fenster, sondern blieb auf dem zuletzt fokussierten Element im Hintergrund. Wer zu diesem Zeitpunkt durch die Seite tabbt, fährt einfach unter dem Overlay weiter, ohne die Möglichkeit zu haben, das Overlay zu schließen. Das Schließen-X war ein <div> ohne tabindex, also für die Tastatur unsichtbar. Escape war nicht implementiert.

Das Ergebnis: Für jeden Tastaturnutzer, der die Seite öffnete, war nach drei Sekunden die Navigation de facto beendet. Der Popup-Anbieter (ein verbreitetes WordPress-Plugin) hatte kein barrierefreies Dialog-Pattern implementiert. Die Lösung war kurzfristig ein eigener JavaScript-Handler: Fokus beim Öffnen auf das erste interaktive Element im Dialog setzen, Tab und Shift+Tab innerhalb des Dialogs halten, Escape und Klick aufs Schließen-X implementieren, Fokus beim Schließen zurück auf den auslösenden Trigger. Das ARIA APG Dialog-Pattern bietet dafür ein fertiges, getestetes Referenzbeispiel.

Kein automatisches Werkzeug hätte diesen Fehler gefunden. Der manuelle Test dauerte 90 Sekunden.

Sofort-Checkliste: Tastaturtest

• Browser-Einstellung für vollständiges Tab-Cycling aktiviert (macOS: Systemeinstellungen → Tastatur)?
• Alle interaktiven Elemente per Tab erreichbar (Links, Buttons, Formularfelder, Akkordeons, Karussells)?
• Fokusindikator auf jedem Element sichtbar, auch auf dunkel- und hellfarbigen Hintergründen?
• Kein outline: none ohne definierten Ersatz-Indikator im CSS?
• Tab-Reihenfolge entspricht der visuellen und inhaltlichen Logik?
• Kein positiver tabindex-Wert im HTML?
• Modale Dialoge: Fokus springt beim Öffnen hinein, bleibt innerhalb, Escape schließt, Fokus kehrt zurück?
• Sticky-Header und fixierte Elemente verdecken das fokussierte Element nicht vollständig (WCAG 2.4.11)?
• scroll-padding-top in Höhe des Sticky-Headers gesetzt?
• Alle anklickbaren Elemente sind echte <button>– oder <a>-Elemente, keine div/span mit onClick?
• Formulare vollständig per Tastatur ausfüllbar und absendbar?
• Fehlermeldungen im Formular per Fokus erreichbar und per Screenreader angekündigt?

Das Wichtigste zum Mitnehmen

Häufige Fragen

Was ist der Unterschied zwischen 2.4.7 und 2.4.11?

Kriterium 2.4.7 verlangt, dass der Fokusindikator überhaupt sichtbar ist. Kriterium 2.4.11 (neu in WCAG 2.2) geht einen Schritt weiter: Das fokussierte Element darf nicht vollständig hinter Autoren-Inhalten wie einem Sticky-Header, einem Chat-Widget oder einem Cookie-Banner verschwinden. Beide sind AA-Anforderungen und gelten damit als Pflicht im Rahmen des BFSG.

Gilt die Pflicht zur Tastaturbedienung auch für kleinere Unternehmenswebsites?

Das hängt von Größe und Angebot ab. Das BFSG gilt seit dem 28. Juni 2025 für Produkte und Dienstleistungen im Endkundengeschäft. Ausgenommen sind Kleinstunternehmen, die ausschließlich Dienstleistungen erbringen, mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Bilanzsumme. Beide Bedingungen müssen zusammen erfüllt sein. Für Produkte gilt die Ausnahme nicht. Unabhängig von der Rechtspflicht profitiert jede Website davon, wenn alle Besucher sie problemlos bedienen können.

Reicht ein automatisches Tool wie Lighthouse für den Tastaturtest?

Nein. Automatische Werkzeuge prüfen statische HTML-Eigenschaften und erkennen dabei einen Teil der Barrieren. Für Tastaturprobleme sind sie weitgehend ungeeignet: Tastaturfallen, falsches Fokusmanagement in Dialogen und Fokus hinter Sticky-Headern entstehen durch Laufzeitverhalten, das nur durch echte Interaktion sichtbar wird. Ein grüner Lighthouse-Score schließt erhebliche Tastaturfehler nicht aus.

Was tue ich, wenn ein eingebettetes Drittanbieter-Tool nicht tastaturkonform ist?

Als Betreiber tragen Sie die Gesamtverantwortung für alle Inhalte auf Ihrer Seite, auch für eingebettete Tools. Liefert der Anbieter keine barrierefreie Variante, prüfen Sie Alternativen. Bis dahin dokumentieren Sie das bekannte Problem schriftlich und bieten einen gleichwertigen Alternativkanal an, etwa telefonische Buchung oder Kontakt per E-Mail. Das reduziert das Haftungsrisiko, löst das Problem aber nicht vollständig.

Wie oft muss der Tastaturtest wiederholt werden?

Nach jeder strukturellen Änderung: neues Theme, neues Plugin, neue Navigation, überarbeitetes Kontaktformular. Bei redaktionellen Inhalten wie Blogbeiträgen genügt eine Stichprobe. Die Grundstruktur der Seite sollte nach jedem größeren Update systematisch neu geprüft werden.

Ist tabindex="0" auf einem div jemals korrekt?

Ja, in einem Fall: Wenn Sie ein benutzerdefiniertes Widget bauen, das kein semantisches HTML-Äquivalent hat und das als ganzes Element den Fokus empfangen soll. Dann gehört neben tabindex="0" immer auch die passende ARIA-Rolle (role="button", role="checkbox" usw.) und ein vollständiger Keyboard-Handler. Für Aktionen, die einen Button auslösen, gilt: Verwenden Sie lieber ein echtes <button>-Element. Es liefert alles von Haus aus.

Quellen und weiterführende Informationen