WCAG 2.1.1: Tastatur

WCAG 2.1.1 verlangt, dass sich jede Funktion einer Seite vollständig über die Tastatur bedienen lässt – erreichen, aktivieren, steuern –, ohne dass es auf das Timing einzelner Tastenanschläge ankommt. Ausgenommen ist allein, was seinem Wesen nach vom Bewegungspfad abhängt, etwa Freihandzeichnen.

(Englisch: Keyboard.)

Das Wichtigste in Kürze

• 2.1.1 hat Veto-Charakter: Was mit der Tastatur nicht geht, geht für einen relevanten Teil der Nutzerschaft gar nicht.
• Drei Dinge müssen funktionieren: erreichen (Tab, Shift+Tab), aktivieren (Enter, Leertaste) und bedienen (Pfeiltasten, Esc, Pos1/Ende in zusammengesetzten Widgets).
• Die einzige Ausnahme betrifft die zugrunde liegende Funktion, nicht die Eingabetechnik: Freihandzeichnen ist ausgenommen, Texteingabe per Handschrift nicht – denn Text lässt sich auch tippen.
• Die Ursache ist fast immer dieselbe: ein <div> oder <span> mit Klick-Handler statt eines echten <button> oder <a href>. Ein nachgerüstetes tabindex="0" macht das Element nur fokussierbar, nicht bedienbar – Rolle und Tastenreaktion fehlen weiterhin.
• Im BITV-Test heißt der Prüfschritt „2.1.1 Ohne Maus nutzbar“ – und er ist einer der wenigen, die man ohne Werkzeug in fünf Minuten selbst durchführen kann.
• Auf Stufe AAA hebt 2.1.3 die Ausnahme auf – dort muss wirklich alles per Tastatur gehen.
• 2.1.1 ist die Grundlage für fast alle assistiven Technologien: Screenreader, Switch-Systeme, Sprachsteuerung und Kopfmäuse setzen auf der Tastaturschnittstelle auf.

Muss alles per Tastatur bedienbar sein?

Ja. Ausgenommen ist nur, was seinem Wesen nach eine freie Bewegung erfordert – etwa freies Zeichnen.

Die Norm formuliert es knapp: Alle Funktionalitäten des Inhalts sind über eine Tastaturschnittstelle bedienbar, ohne dass für einzelne Tastenanschläge bestimmte Zeitvorgaben bestehen. Drei Teile stecken darin, und alle drei werden geprüft:

• Erreichbarkeit. Jedes interaktive Element muss in der Tab-Reihenfolge liegen. Was nicht erreichbar ist, existiert für Tastaturnutzer nicht.
• Aktivierbarkeit. Links reagieren auf Enter, Buttons auf Enter und Leertaste. Ein selbstgebautes Widget muss dieselben Tasten unterstützen, sonst ist es zwar fokussierbar, aber nicht auslösbar.
• Steuerbarkeit. Zusammengesetzte Bedienelemente – Menüs, Tabs, Slider, Comboboxen – brauchen zusätzlich Pfeiltasten, oft auch Esc, Pos1 und Ende. Was jeweils erwartet wird, steht in den ARIA Authoring Practices des W3C.

Der Zusatz zum Timing ist kein Detail: Eine Bedienung, die nur funktioniert, wenn man zwei Tasten innerhalb von 300 Millisekunden drückt oder eine Taste exakt lange genug hält, verletzt das Kriterium selbst dann, wenn sie theoretisch mit der Tastatur möglich ist.

Wichtig ist die Abgrenzung zu den Nachbarkriterien: 2.1.1 regelt ob etwas bedienbar ist. Dass man dabei nicht steckenbleibt, regelt 2.1.2 Keine Tastaturfalle; dass man sieht, wo man ist, 2.4.7 Fokus sichtbar; und dass die Reihenfolge sinnvoll ist, 2.4.3 Fokus-Reihenfolge. Vier Kriterien, ein Durchlauf.

Wen betrifft es besonders?

Für blinde Menschen gibt es kein Zeigen: Ein Mauszeiger, den man nicht sieht, lässt sich nicht positionieren. Die gesamte Bedienung läuft über Tastenkommandos, die der Screenreader an die Seite weiterreicht.

Für Menschen mit motorischen Einschränkungen ist die Maus oft die schwierigere Eingabe – Zittern, Spastik oder eingeschränkte Reichweite machen präzises Zeigen mühsam, während eine Taste zuverlässig trifft. Und alle Switch-, Kopfmaus- und Sprachsteuerungssysteme simulieren am Ende Tastatureingaben: Wer per Sprachbefehl „Tab, Tab, Enter“ auslöst, ist auf exakt dieselbe Schnittstelle angewiesen.

Dazu kommt eine große Gruppe, die man in Barrierefreiheitsdiskussionen selten mitzählt: Menschen mit temporärer Einschränkung (gebrochener Arm, frisch operierte Hand) und schlicht alle, die schnell arbeiten. Ein Formular, das man mit Tab und Enter durchtippen kann, ist für jeden schneller.

Richtig & falsch im Code

<!-- Falsch: klickbares div – für die Tastatur unsichtbar -->
<div class="btn" onclick="submitForm()">Absenden</div>

<!-- Falsch: „Link" ohne href ist nicht fokussierbar -->
<a class="nav-item" onclick="goTo('/preise')">Preise</a>

<!-- Falsch: tabindex allein macht noch keinen Button -->
<div class="btn" tabindex="0" onclick="submitForm()">Absenden</div>

Das dritte Beispiel ist der interessanteste Fehler, weil er fast richtig ist: Das Element ist fokussierbar, aber Enter und Leertaste lösen nichts aus – die bringt nur ein echter Button mit. Wer den Weg trotzdem gehen muss, braucht alle drei Bausteine:

<!-- Richtig: natives Element, alles inklusive -->
<button type="submit">Absenden</button>
<a href="/preise.html">Preise</a>

<!-- Notlösung, wenn ein natives Element wirklich ausscheidet -->
<div class="btn" role="button" tabindex="0"
     onclick="submitForm()"
     onkeydown="if (event.key === 'Enter' || event.key === ' ') {
       event.preventDefault(); submitForm();
     }">Absenden</div>

Man sieht: Die Notlösung braucht Rolle, tabindex und Tastenbehandlung – und in echten Projekten fehlt am Ende immer eines der drei. Deshalb ist Buttons vs. Links die wichtigste Vorentscheidung für dieses Kriterium.

Ein zweiter, häufig übersehener Fall sind Hover-Menüs:

/* Falsch: Untermenü erscheint nur bei Maus-Hover */
.nav-item:hover .submenu { display: block; }

/* Richtig: Fokus im Menü öffnet es ebenso */
.nav-item:hover .submenu,
.nav-item:focus-within .submenu { display: block; }

:focus-within ist hier der billigste Gewinn überhaupt – zwei Zeilen, und ein komplettes Navigationsmenü wird tastaturbedienbar. Für das vollständige Muster mit aria-expanded siehe Mega-Menüs.

So testest du es

1. Maus weglegen. Wirklich weglegen – die Versuchung, „nur kurz“ zu klicken, ist der häufigste Grund für ein zu gutes Ergebnis.
2. Mit Tab durch die ganze Seite: Erreichst du jedes interaktive Element? Notiere jede Stelle, an der der Fokus verschwindet oder ein sichtbares Bedienelement übersprungen wird.
3. Jedes Element aktivieren: Enter auf Links, Enter und Leertaste auf Buttons. Passiert nichts, ist das ein Fund – auch wenn das Element fokussierbar war.
4. Zusammengesetzte Widgets steuern: Menüs mit Pfeiltasten, Tabs mit Pfeiltasten, Dialoge mit Esc, Slider mit Pfeil und Pos1/Ende.
5. Kernabläufe komplett durchspielen: Suche, Kontaktformular, Checkout, Filter, Login – von Anfang bis Ende ohne Maus. Der vollständige Ablauf steht unter Barrierefreiheit selbst testen.
6. Gegenprobe mit dem Screenreader: Manche Elemente sind per Tab erreichbar, werden aber nicht angesagt – das fällt erst mit NVDA auf.

Häufiger Fehler in der Praxis

Der Dauerbrenner ist das klickbare <div>, und zwar meistens nicht aus Unwissen, sondern aus Komponenten-Bibliotheken heraus: Eine Card-Komponente bekommt einen onClick, ein Icon wird zum Schließen-Kreuz, ein <span> wird zum Filter-Chip. Optisch alles perfekt, mit der Tastatur nichts davon erreichbar.

Der zweite Fall ist tückischer, weil er nur teilweise kaputt ist: selbstgebaute Dropdowns und Comboboxen. Sie lassen sich meist öffnen, aber die Optionen sind nur per Maus wählbar, oder Esc schließt nicht, oder der Fokus landet nach dem Schließen im Nichts. Das erwischt man nur, wenn man das Widget wirklich zu Ende bedient und nicht nur antippt. Wenn du eins bauen musst, orientier dich an Comboboxen und Autocomplete statt an einer eigenen Idee – die Tastaturmuster sind standardisiert und Nutzerinnen erwarten genau sie.

Der dritte: Inhalte, die nur bei Hover erscheinen. Tooltips, Vorschau-Karten, Untermenüs. Sie sind nicht falsch gebaut, sie sind nur nie mit Fokus getestet worden. :focus-within löst die meisten dieser Fälle; der Rest steht unter 1.4.13 Inhalt bei Hover oder Fokus.

Häufige Fragen

Zählt eine Bildschirmtastatur als Tastatur?

Ja. Das Kriterium spricht von der Tastaturschnittstelle, nicht von einem physischen Gerät. Eine Bildschirmtastatur, eine Braillezeile mit Tastenblock oder ein Switch-System, das Tastendrücke erzeugt, nutzen dieselbe Schnittstelle. Genau deshalb ist 2.1.1 auch für Mobilgeräte relevant.

Muss die Maus-Bedienung erhalten bleiben?

Ja. 2.1.1 verlangt Tastaturbedienbarkeit zusätzlich, nicht stattdessen. Die WCAG geht durchgängig von Eingabegeräte-Unabhängigkeit aus: Eine Oberfläche, die nur noch mit der Tastatur funktioniert, sperrt alle aus, die ausschließlich mit Zeigegeräten arbeiten – etwa mit Kopf- oder Augensteuerung. Ein Klickziel darf also nie zugunsten der Tastatur verschwinden.

Wann greift die Ausnahme für pfadabhängige Eingaben?

Nur dann, wenn die zugrunde liegende Funktion den Bewegungspfad braucht – etwa Freihandzeichnen oder eine Unterschrift. Nicht ausgenommen ist eine Funktion, die bloß pfadabhängig umgesetzt wurde: Ein Schieberegler, der sich nur ziehen lässt, muss zusätzlich mit Pfeiltasten bedienbar sein, denn „Wert einstellen“ hängt nicht am Pfad.

Reicht es, wenn alle Elemente per Tab erreichbar sind?

Nein. Erreichbarkeit ist nur der erste von drei Teilen. Ein Element, das den Fokus bekommt, aber auf Enter nicht reagiert, erfüllt das Kriterium nicht. Und ein Menü, das sich zwar öffnen, aber nicht mit Pfeiltasten durchlaufen lässt, ebenso wenig.

Wie hängt 2.1.1 mit Tastenkürzeln zusammen?

Gar nicht direkt. 2.1.1 verlangt Bedienbarkeit, nicht Abkürzungen. Wer eigene Tastenkürzel anbietet, muss allerdings 2.1.4 Tastenkürzel beachten: Einzelbuchstaben-Kürzel müssen abschaltbar oder umbelegbar sein, sonst stören sie Sprachsteuerungs-Nutzer.

Verwandte Themen

• Tastaturbedienung & sichtbarer Fokus – der ausführliche Praxis-Leitfaden
• Buttons vs. Links – die häufigste Ursache an der Wurzel
• 2.1.2 Keine Tastaturfalle und 2.4.3 Fokus-Reihenfolge – die Geschwister im selben Durchlauf
• Dialoge & Modals – wo Tastaturbedienung am häufigsten scheitert
• Barrierefreiheit selbst testen – der komplette Durchlauf in einer Stunde