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.

Markus Stahmann

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.

Barrierefreiheit erleben

Tastaturnavigation

Aktivieren Sie „Selbst ausprobieren" und bedienen Sie die Beispielseite mit der Tastatur – Tab, Enter, Pfeil nach obenPfeil nach untenPfeil nach linksPfeil nach rechts, Esc. Im Protokoll erscheint, was erreichbar ist.

Steuerung:

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

Vor- und Nachname
Absenden
Protokoll

Per Tab durch die Seite – hier erscheint Zeile für Zeile, was die Tastatur erreicht und was übersprungen wird.

Ende der Demo „Tastaturnavigation"

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.

Achtung:

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.

CSS
/* 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.

HTML
<!-- 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.