Fragt mich jemand nach der wichtigsten Eigenschaft digitaler Barrierefreiheit, fällt mir fast immer sofort ein Begriff ein: Tastaturbedienbarkeit. Gemeint ist damit, dass sich eine Website, ein Interface oder eine Anwendung vollständig über die Tastatur bedienen lässt, ganz ohne Maus oder Touch.
Wenn ich selbst eine Website teste oder zur Barrierefreiheit befragt werde, ist mein erster Handgriff fast immer derselbe: Maus beiseitelegen, mit Tab durch die Seite gehen. Das dauert keine fünf Minuten und zeigt sofort, wie es um eine Seite steht. Meine steile These dazu: Funktioniert die Tastaturbedienung nicht, muss ich eigentlich gar nicht weiter testen. Dann ist die Seite nicht barrierefrei, Punkt.
Nicht nur eine Frage der Tastatur
Warum wiegt Tastaturbedienbarkeit so schwer? Sie ist zunächst eine Alternative zur Maus, für alle Situationen, in denen Maus oder Touch nicht zur Verfügung stehen oder schlicht nicht gut funktionieren: ein gebrochenes Handgelenk, eine Sehnenscheidenentzündung, Zittern durch Parkinson oder essenziellen Tremor, Arthritis, die die feinmotorische Mausbedienung erschwert. Genauso zählen die ganz alltäglichen Situationen dazu: eine leere Batterie, ein zu enger Schreibtisch für eine Maus, oder schlicht Kaffee in der einen Hand.
Genauso wichtig, und keineswegs nur eine Randnotiz: Wer viel am Rechner arbeitet, kommt über Tastenkombinationen und schnelles Durchtabben oft spürbar zügiger durchs Formular oder Menü als mit der Maus, ganz ohne Einschränkung. Das betrifft nicht nur ausgesprochene Power-User: Ein langes Formular per Tastatur auszufüllen ist für die meisten Menschen einfach schneller, als ständig zwischen Tastatur und Maus zu wechseln.
Der eigentliche Grund reicht aber weiter: Ein großer Teil der assistiven Technologien baut auf Tastatureingaben auf. Screenreader werden fast ausschließlich über die Tastatur gesteuert, nicht nur zur Navigation, sondern auch, um Inhalte vorlesen zu lassen, Formulare auszufüllen oder Menüs zu bedienen; ohne funktionierende Tastaturbedienung läuft ein Screenreader ins Leere, egal wie gut seine Ausgabe sonst ist. Braillezeilen greifen auf dieselbe Logik zurück. Wer motorisch eingeschränkt ist, nutzt oft Schalter oder Sondertastaturen, die dem System eine Tastatureingabe vorgaukeln. Auch Spracheingabe-Software simuliert an vielen Stellen Tastaturbefehle. Funktioniert eine Seite mit der Tastatur nicht, fällt sie für all diese Gruppen gleich mit weg, nicht nur für Menschen, die tatsächlich eine physische Tastatur bedienen.
Funktioniert die Tastaturbedienung nicht, brauche ich eigentlich nicht weiterzutesten: Die Seite ist nicht barrierefrei.
Das zeigt sich auch in den WCAG selbst: Innerhalb der vier Grundprinzipien gehört die Richtlinie „Tastaturbedienbar“ zum Prinzip Bedienbar, und mehrere ihrer Erfolgskriterien zählen bereits auf der untersten Konformitätsstufe A zu den Pflichtkriterien. Es geht also nicht ohne, auf keiner Stufe.
Die Grundlagen: Wie Tastaturbedienung funktioniert
Für die Bedienung mit der Tastatur gibt es feste Muster, auf die sich Nutzende verlassen können:
| Taste | Funktion |
|---|---|
| Tab | Sprung zum nächsten fokussierbaren Element |
| Shift + Tab | Sprung zurück |
| Enter | Aktivierung von Links und Buttons |
| Leertaste | Aktivierung von Buttons und Checkboxen |
| Pfeiltasten | Navigation in Listen, Tabs, Slidern, Radiobuttons |
| Esc | Schließen von Dialogen, Menüs, Overlays |
Wichtig ist, dass wirklich jedes interaktive Element so funktioniert, wie diese Muster es erwarten lassen: Navigationen müssen erreichbar sein, Menüs sich öffnen und wieder schließen lassen, Formularfelder in einer nachvollziehbaren Reihenfolge durchlaufen werden.
Tastaturnavigation
Beim Tabben durch die Beispielseite zeichnet visuell eine Linie den Fokus-Weg nach und nummeriert jede erreichbare Stelle der Reihe nach; absichtlich nicht erreichbare Elemente werden mit einem „übersprungen"-Fähnchen markiert. Dieselben Angaben stehen als Text im Protokoll.
Termin anfragen
- Möbel nach Maß
- Treppe
- Einbauschrank
- Restaurierung
- Möbel nach Maß
- Treppe
- Einbauschrank
- Restaurierung
Protokoll
Per Tab durch die Seite – hier erscheint Zeile für Zeile, was die Tastatur erreicht und was übersprungen wird.
Am besten selbst ausprobieren: Das Demo oben zeigt, wie sich die Muster in der Praxis anfühlen.
Typische Probleme in der Praxis
Unerreichbare Bereiche und Tastaturfallen
Ganze Bereiche einer Seite sind manchmal komplett unerreichbar, das betrifft am häufigsten die Hauptnavigation. Fast genauso häufig lassen sich einzelne Komponenten wie Modals, Akkordeons oder Slider zwar per Tastatur ansteuern, aber nicht bedienen: Der Fokus wandert hinein, kommt aber nicht wieder heraus. Das ist eine klassische Tastaturfalle, besonders ärgerlich bei Modalen oder Untermenüs, die sich öffnen, aber nicht wieder schließen lassen.
Ein überlagerndes Element, das sich per Tastatur nicht schließen lässt, blockiert nicht nur einen Bereich, sondern die komplette Seite. Besonders häufig bei Cookie-Bannern und Datenschutzhinweisen, die sich zwar per Maus, aber nicht per Tastatur wegklicken lassen. Die Seite ist dann faktisch tot.
Fehlender oder unsichtbarer Fokus
Dazu kommt der Klassiker: CSS-Resets setzen outline beziehungsweise den :focus-Zustand zurück, oft ohne Ersatz. Damit ist für Tastaturnutzende nicht mehr erkennbar, wo sie sich gerade befinden.
/* Schlecht: Fokus verschwindet komplett */
button:focus {
outline: none;
}
/* Besser: eigener Fokus-Stil, nur bei Tastaturnutzung sichtbar */
button:focus-visible {
outline: 2px solid #0057ff;
outline-offset: 2px;
}Über :focus-visible lässt sich der Fokusring so gestalten, dass er zum Corporate Design passt, ohne bei jedem Mausklick aufzublitzen.
Fehlende Tastatur-Interaktion bei eigenen Komponenten
Bei selbst gebauten Komponenten fehlen oft schlicht die nötigen Key-Bindings, etwa wenn ein <div> per JavaScript wie ein Button funktioniert, aber weder fokussierbar noch mit Enter oder Leertaste aktivierbar ist.
<!-- Schlecht: sieht aus wie ein Button, ist aber keiner -->
<div onclick="submitForm()">Absenden</div>
<!-- Gut: nutzt das native Element und dessen Tastatur-Verhalten -->
<button type="submit">Absenden</button>Wo ein natives Element wie <button> reicht, spart man sich die ganze Nacharbeit an Fokus, Tastatur-Events und ARIA gleich mit. Gerade bei komplexeren Eigenbauten wie Datepickern oder Multiselects lohnt sich an dieser Stelle ein zweiter, geschulter Blick von außen.
Tabindex und Reihenfolge
Ebenfalls häufig: Die Tab-Reihenfolge wird per tabindex manuell verändert. Positive Werte reißen Elemente aus der natürlichen Reihenfolge und sorgen fast immer für Verwirrung. Sinnvoll sind eigentlich nur zwei Werte: 0, um ein sonst nicht fokussierbares Element in die natürliche Reihenfolge einzureihen, und -1, um ein Element aus der Tab-Reihenfolge zu nehmen und nur noch per Skript fokussierbar zu machen, etwa bei einer Dialog-Überschrift.
Der Mythos: Mobile Geräte brauchen keine Tastaturbedienung
Ein hartnäckiger Irrtum begegnet mir außerdem regelmäßig: Apps und mobile Websites müssten nicht tastaturbedienbar sein, weil dort ja niemand mit Tastatur tippt. Auch Smartphones und Tablets lassen sich per Bluetooth-Tastatur bedienen, und viele assistive Technologien auf mobilen Geräten simulieren genau das im Hintergrund.
Inhalte, die nur bei Hover erscheinen
Und ein letzter, oft übersehener Punkt: Inhalte, die nur bei :hover erscheinen, etwa Tooltips oder Untermenüs, sind für Tastaturnutzende unsichtbar. Alles, was per Hover erreichbar ist, muss auch per Fokus erreichbar sein.
Die Tastaturbedienung selbst testen
Das Gute daran: Tastaturbedienbarkeit lässt sich ohne Vorwissen selbst testen, direkt auf der eigenen Website. Maus beiseitelegen und nur mit der Tastatur durch die Seite navigieren: Tab und Shift + Tab zum Springen, Enter zum Aktivieren, Pfeiltasten für Slider, Tabs oder komplexere Formularfelder.
Testen Sie ruhig, was sich bedienen lässt und wo Sie hängen bleiben. Zwei, drei Minuten reichen für einen ersten Eindruck. Wer tiefer einsteigen will: Die Barrierefreiheits-Werkzeuge in Firefox und Chrome zeigen die Tab-Reihenfolge direkt im Quelltext an, und automatisierte Tools wie axe finden offensichtliche Fehler. Ersetzen können sie einen manuellen Test bei individuell gebauten Komponenten aber nicht, dafür braucht es geschultes Auge und Erfahrung. Genau da setzt ein Barrierefreiheits-Audit an.
Viel Spaß beim Ausprobieren.
WCAG-Pflicht und gute Praxis
In den WCAG steckt Tastaturbedienbarkeit nicht in einem einzelnen Kriterium, sondern zieht sich durch mehrere Richtlinien: ein sichtbarer Fokus, keine Tastaturfallen, Sprungmarken zum Überspringen wiederkehrender Bereiche, ein Fokus, der nicht vollständig durch Cookie-Banner oder Sticky-Header verdeckt wird, und bei selbst gebauten Komponenten die korrekte technische Umsetzung über ARIA. Praktisch heißt das vor allem: ein „Zum Inhalt springen“-Link an erster Tab-Position und ein Fokusring mit mindestens 3:1 Kontrast zur Umgebung.
Nicht alles davon ist tatsächlich WCAG-Pflicht, manches ist einfach gute Praxis, die sich daraus ergibt. Weitere Sprungmarken zu Navigation, Suche oder anderen wiederkehrenden Bereichen etwa, oder die Möglichkeit, umfangreiche Inhaltselemente wie Slider gezielt zu überspringen: Kein WCAG-Kriterium verlangt das im Detail, es macht die Bedienung aber spürbar angenehmer. Dasselbe gilt für Tastaturkürzel: Legt man welche an, sollten sie bekannte Browser- oder Betriebssystem-Kürzel nicht überschreiben, auch das ist eher Sorgfalt als Vorschrift.
Welche WCAG-Erfolgskriterien betrifft das konkret?
Tastaturbedienbarkeit ist über mehrere Themenblöcke verteilt:
| Thema | Kriterien | Stufe |
|---|---|---|
| Grundfunktion per Tastatur | 2.1.1, 2.1.2, 2.1.4 | A |
| Sprungmarken und Reihenfolge | 1.3.2, 2.4.1, 2.4.3 | A |
| Verhalten bei Fokus/Eingabe | 3.2.1, 3.2.2 | A |
| Selbst gebaute Komponenten | 4.1.2 | A |
| Sichtbarer Fokus | 1.4.11, 2.4.7, 2.4.11 | AA |
| Freiwillig, aber sauber gelöst | 2.1.3, 2.4.12, 3.2.5 | AAA |
Auf Konformitätsstufe A sind bereits die Grundfunktion, keine Tastaturfallen und Sprungmarken Pflicht. Ab Stufe AA kommen der sichtbare Fokus (2.4.7), die Vorgabe, dass er nicht vollständig durch überlagernde Elemente verdeckt werden darf (2.4.11), und ausreichender Kontrast für Bedienelemente wie den Fokusring dazu (1.4.11, mindestens 3:1). Die drei AAA-Kriterien sind gesetzlich nicht gefordert, aber ein gutes Ziel für besonders sorgfältig umgesetzte Anwendungen: 2.1.3 (Tastatur ohne Ausnahme, also auch für zeitkritische Eingaben wie Freihand-Zeichnen), 3.2.5 (Änderungen nur auf ausdrückliche Anfrage) und 2.4.12 als schärferes Pendant zu 2.4.11, das verlangt, dass der Fokus komplett statt nur teilweise sichtbar bleibt.
Wer noch tiefer einsteigen möchte: Die Handreichung Tastaturbedienbarkeit der Überwachungsstelle des Bundes (BFIT-Bund) (öffnet in neuem Tab) geht noch einmal ausführlich auf Nutzergruppen, Erfolgskriterien und eine Umsetzungs-Checkliste ein, inklusive PDF-Download.
Tastaturbedienbarkeit ist im Grunde simpel, aber voller Fallstricke, gerade bei individuell gebauten Komponenten. Wer sie von Anfang an mitdenkt statt sie nachträglich zu reparieren, spart sich mehr Aufwand, als der Test kostet: zwei Minuten mit der Tastatur, dafür ein Problem weniger, das später mühsam behoben werden muss.