Tastaturbedienung: kommst du ohne Maus durch deine Website?

Es gibt eine Prüfung, die zehn Minuten dauert, kein Werkzeug braucht und mehr echte Probleme findet als die meisten automatischen Tests: Leg die Maus weg und bedien deine Website nur mit der Tastatur. Die Richtlinien für barrierefreie Webinhalte (WCAG) verlangen schon auf der untersten Stufe A, dass alle Funktionen mit der Tastatur bedienbar sind und dass man aus keinem Element gefangen wird. Dazu kommen ein sichtbarer Fokus und eine sinnvolle Reihenfolge. Die typischen Fundstellen sind das Menü, das Cookie-Banner und Fenster, die sich öffnen und nicht mehr schließen lassen.

Wer auf die Tastatur angewiesen ist

Das W3C nennt in seiner Erläuterung zum Kriterium 2.1.1 „Tastatur" drei Gruppen:

• Blinde Menschen, die keinen Mauszeiger benutzen können, weil der Auge-Hand-Koordination voraussetzt. Ihr Screenreader wird über die Tastatur gesteuert.
• Menschen mit Sehbehinderung, die dem Mauszeiger auf dem Bildschirm nur schwer folgen können.
• Menschen mit Zittern in den Händen, für die eine Maus mühsam ist.

Dazu kommen alle, die Tastatur-Ersatzgeräte benutzen: Spracheingabe, Bildschirmtastaturen, Saug-Blas-Steuerungen und Scan-Software. Diese Systeme schicken Tastatureingaben an die Seite. Was mit der Tastatur nicht geht, geht mit ihnen auch nicht.

Die Anforderung selbst ist knapp. Kriterium 2.1.1, Stufe A: Alle Funktionen müssen über eine Tastaturschnittstelle bedienbar sein, ohne dass einzelne Tastenanschläge ein bestimmtes Timing brauchen. Ausgenommen ist nur, was von der Bewegung selbst abhängt, etwa freihändiges Zeichnen. Wer diese Stufe verfehlt, hat kein Feinschliff-Problem.

Wie du prüfst

Öffne deine Startseite in einem privaten Browserfenster. So siehst du das Cookie-Banner in dem Zustand, in dem es neue Besucher sehen, und nicht schon weggeklickt. Dann benutzt du nur diese Tasten:

Taste	Was sie tut
Tab	springt zum nächsten bedienbaren Element
Umschalt + Tab	springt zurück
Enter	aktiviert Links und Buttons
Leertaste	aktiviert Buttons und Checkboxen, scrollt sonst die Seite
Pfeiltasten	bewegen sich in Auswahlfeldern, Radiobutton-Gruppen und gut gebauten Menüs
Esc	schließt Dialoge

Dabei schaust du auf fünf Dinge:

1. Erreichbarkeit. Kommst du an jeden Link, jeden Button, jedes Formularfeld und jeden Menüpunkt?
2. Reihenfolge. Ergibt der Weg, den der Fokus nimmt, einen Sinn?
3. Sichtbarer Fokus. Siehst du zu jedem Zeitpunkt, wo du bist?
4. Wieder herauskommen. Kommst du von jedem Element, das du erreicht hast, auch wieder weg?
5. Vollständige Funktion. Funktioniert alles, oder gibt es Dinge, die nur reagieren, wenn die Maus darüberfährt?

Der sichtbare Fokus

Kriterium 2.4.7 „Fokus sichtbar", Stufe AA: Jede per Tastatur bedienbare Oberfläche muss eine Bedienart haben, in der der Tastaturfokus sichtbar ist. Der Fokusrahmen ist für den Tastaturnutzer, was der Mauszeiger für den Mausnutzer ist. Ohne ihn drückt man Enter und weiß nicht, was gleich passiert.

2.4.7 selbst nennt keinen Kontrastwert. Der kommt aus Kriterium 1.4.11 zum Kontrast von Nicht-Text-Inhalten: Der Fokusrahmen braucht 3:1 gegenüber den Farben, an die er grenzt. Liegt er außen um das Element, zählt der Hintergrund, auf dem das Element steht. Liegt er innen, zählen die Farben im Element.

Der häufigste Fehler in diesem Bereich ist eine einzige CSS-Zeile. Das W3C führt sie als eigenen Fehlerfall F78:

:focus {
  outline: none;
}

Sie steht in vielen Themes und eigenen Stylesheets, weil der Standardrahmen des Browsers als unschön gilt. Ihn ersatzlos zu entfernen, macht die Website für einen Teil der Nutzer unbedienbar. Der richtige Weg ist, ihn zu ersetzen:

:focus-visible {
  outline: 3px solid var(--fokusfarbe);
  outline-offset: 2px;
}

:focus-visible ist der praktische Unterschied zu :focus. Der Browser entscheidet, wann ein Fokusrahmen gebraucht wird: beim Tabben ja, beim Mausklick auf einen Button nicht. Genau der Rahmen beim Klick war meist der Grund, warum er entfernt wurde.

Fokus nicht verdeckt

Kriterium 2.4.11 „Fokus nicht verdeckt (Minimum)", Stufe AA, kam im Oktober 2023 mit WCAG 2.2 dazu: Ein Element, das den Fokus bekommt, darf nicht vollständig von anderem Inhalt der Seite verdeckt sein. Teilweise verdeckt besteht das Kriterium noch, auch wenn das W3C rät, es möglichst zu vermeiden. Der klassische Fall ist eine Kopfzeile, die oben festklebt: Man tabbt weiter, die Seite scrollt mit, und das fokussierte Element landet genau darunter. Dasselbe passiert mit Cookie-Bannern am unteren Rand, Chat-Fenstern und nicht-modalen Dialogen. Eine Lösung, die das W3C selbst nennt, ist die CSS-Eigenschaft scroll-padding in Höhe der festen Kopfzeile.

Die Reihenfolge

Kriterium 2.4.3 „Fokus-Reihenfolge", Stufe A: Wenn die Reihenfolge Bedeutung oder Bedienung beeinflusst, muss der Fokus in einer Reihenfolge wandern, die beides erhält. Das heißt nicht, dass die Reihenfolge exakt dem Bildschirm folgen muss. Das W3C zeigt selbst ein Beispiel, in dem die Navigation im Quelltext nach dem Inhalt steht und per CSS links angezeigt wird, und das besteht.

Die natürliche Reihenfolge ergibt sich aus dem HTML-Quelltext. Probleme entstehen, wenn Quelltext und Anzeige so weit auseinanderlaufen, dass der Sinn verloren geht: Rasterlayouts, die per CSS umsortiert werden, oder Bausteine, die mobil anders angeordnet sind als am Desktop. Besonders hart trifft das Menschen mit Bildschirmlupe. Das W3C schreibt: Sie sehen bei starker Vergrößerung nur einen kleinen Ausschnitt und deuten ein Feld leicht im falschen Zusammenhang, wenn der Fokus unlogisch springt.

tabindex ist das meistmissbrauchte Attribut in diesem Feld. MDN beschreibt die drei Wertebereiche so:

• tabindex="0" macht ein Element fokussierbar. Es reiht sich an seiner Stelle im Quelltext ein.
• tabindex="-1" nimmt ein Element aus der Tab-Reihenfolge. Per JavaScript kann der Fokus trotzdem dorthin gesetzt werden, was man etwa für Dialoge braucht.
• Positive Werte wie tabindex="1" kommen in der Reihenfolge vor allen Elementen mit 0 und ohne Wert, unabhängig davon, wo sie auf der Seite stehen.

MDN rät ausdrücklich, nur 0 und -1 zu verwenden. Positive Werte funktionieren nur, solange sie lückenlos gepflegt werden. Sobald jemand einen Inhalt ergänzt, ist die Reihenfolge kaputt, und niemand merkt es. Die Lösung ist nicht, die Reihenfolge per tabindex zu reparieren, sondern den Quelltext in die richtige Reihenfolge zu bringen.

Tastaturfallen

Kriterium 2.1.2 „Keine Tastaturfalle", Stufe A: Wer mit der Tastatur in ein Element hineinkommt, muss mit der Tastatur auch wieder heraus. Braucht das mehr als Tab, Pfeiltasten oder die üblichen Wege, muss die Seite sagen, wie es geht.

Eine Falle ist der schwerste Fehler in diesem Bereich, weil sie die Website nicht erschwert, sondern beendet. Wer festsitzt, kann nur noch neu laden. Typische Stellen:

• Cookie-Banner. Das Banner erscheint, aber der Fokus bleibt im Inhalt dahinter, und man erreicht die Schaltflächen nie. Oder umgekehrt: Man kommt hinein und danach nirgendwo mehr hin.
• Modale Fenster. Der Dialog öffnet sich, der Fokus bleibt im Hintergrund.
• Eingebettete Inhalte. Videoplayer, Karten, Buchungssysteme in einem Rahmen, die die Tastatur abfangen.
• Mehrstufige Menüs. Die Unterpunkte klappen nur auf, wenn die Maus darüberfährt. Für Tastaturnutzer existiert die Hälfte der Website dann nicht. Das passiert, wenn ein Aufklappmenü nur auf :hover reagiert und nicht zusätzlich auf :focus-within oder einen Button.

Wie ein Dialog richtig funktioniert, beschreibt das Muster für modale Dialoge der WAI: Beim Öffnen wandert der Fokus in den Dialog. Tab und Umschalt + Tab bleiben darin und springen vom letzten zum ersten Element. Esc schließt ihn. Danach kehrt der Fokus zu dem Element zurück, das ihn geöffnet hat. Dass der Fokus im offenen Dialog bleibt, ist keine Falle, solange Esc oder ein Schließen-Button wieder herausführt.

Inhalte, die bei Hover oder Fokus erscheinen

Kriterium 1.4.13, Stufe AA, betrifft alles, was zusätzlich eingeblendet wird: Erklärungskästen, Aufklappmenüs, Vorschaufenster. Drei Bedingungen:

• Schließbar. Der Inhalt lässt sich schließen, ohne Maus oder Fokus zu bewegen, üblicherweise mit Esc.
• Überfahrbar. Erscheint er beim Überfahren mit der Maus, muss man den Zeiger auf ihn bewegen können, ohne dass er verschwindet.
• Beständig. Er bleibt sichtbar, bis der Auslöser wegfällt, der Nutzer ihn schließt oder die Information ungültig wird.

Ausgenommen ist, was der Browser selbst darstellt, etwa der Tooltip aus dem title-Attribut.

Ein technischer Hinweis dazu: Das onclick-Ereignis eines Links oder Buttons reagiert auch auf die Tastatur, weil es an die Standardaktion des Elements gebunden ist. Auf einem div gilt das nicht. Wer eine Funktion nur an onmouseover oder onmousedown hängt, schließt Tastaturnutzer aus, und das W3C führt genau das als Fehlerfall F54. Zu onmouseover gehört onfocus, zu onmouseout gehört onblur.

Nichts darf unerwartet passieren

Zwei Kriterien der Stufe A gehören zusammen:

3.2.1 „Bei Fokus". Ein Element zu fokussieren darf allein keinen Kontextwechsel auslösen. Das W3C nennt drei Beispiele: Ein Formular wird abgeschickt, ein neues Fenster öffnet sich, der Fokus springt woandershin.

3.2.2 „Bei Eingabe". Eine Einstellung zu ändern darf keinen Kontextwechsel auslösen, ohne dass vorher darauf hingewiesen wurde. Der Klassiker ist ein Auswahlfeld, das beim Ändern sofort eine neue Seite lädt. Für Mausnutzer ist das bequem. Wer mit den Pfeiltasten durch die Optionen geht, löst dagegen bei der ersten Option schon den Wechsel aus. Die Lösung ist ein Button neben dem Auswahlfeld, der die Auswahl erst auf Wunsch ausführt.

Was das Gesetz verlangt

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für Dienstleistungen an Verbraucher, darunter den elektronischen Geschäftsverkehr, also etwa Online-Shops und Buchungen. Kleinstunternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme sind teilweise ausgenommen. Als Maßstab gilt die europäische Norm EN 301 549. Sie übernimmt nach Angaben des Bundes die WCAG 2.1 und schreibt deren Stufen A und AA verbindlich vor. Alle Kriterien dieses Artikels außer 2.4.11 gehören zu diesem Kern. 2.4.11 ist mit WCAG 2.2 neu dazugekommen und heute Stand der Praxis. Ob dein Betrieb unter das Gesetz fällt, klärt eine Rechtsberatung, nicht eine technische Prüfung.

Was zu tun ist

1. Such nach outline: none und outline: 0 in deinen Stylesheets. Gibt es keinen sichtbaren Ersatz, ist das der erste Fund und meist der schnellste.
2. Setz einen Fokusstil, der zur Gestaltung passt. Ein deutlicher Umriss in einer Farbe aus deiner Palette, mit etwas Abstand zum Element und 3:1 gegenüber dem Hintergrund. Wenn der Rahmen gut aussieht, entfernt ihn später niemand.
3. Repariere das Menü zuerst. Ein Aufklappmenü, das nur auf :hover reagiert, sperrt Tastaturnutzer aus großen Teilen der Website aus.
4. Nimm dir das Cookie-Banner vor. Es ist das erste, was jeder Besucher sieht, und meist von einem fremden Anbieter. Prüf es im privaten Fenster mit der Tastatur, bevor du irgendetwas anderes prüfst.
5. Räum positive tabindex-Werte weg und bring stattdessen den Quelltext in die richtige Reihenfolge.
6. Gib festen Kopf- und Fußzeilen scroll-padding, damit der Fokus nicht darunter verschwindet.
7. Prüf nach jeder Änderung neu. Ein neues Plugin oder Skript kann die Tastaturbedienung still kaputtmachen. Zehn Minuten Durchtabben gehören in jede Wartungsrunde.

Ein Werkzeug, das dabei hilft: Die Browser-Erweiterung Accessibility Insights for Web von Microsoft hat einen Test „Tab stops", der beim Durchtabben die Position jedes Elements als Nummer einblendet. So werden Sprünge sichtbar, die man beim bloßen Tabben leicht übersieht.

Quellen

• W3C, Understanding WCAG 2.2 — 2.1.1 Tastatur: Wortlaut, Stufe A, betroffene Gruppen, Tastatur-Ersatzgeräte: w3.org
• W3C, Understanding WCAG 2.2 — 2.1.2 Keine Tastaturfalle, mit dem modalen Dialog als zulässigem Fall: w3.org
• W3C, Understanding WCAG 2.2 — 2.4.3 Fokus-Reihenfolge, Beispiel mit abweichender Quelltext-Reihenfolge, Bildschirmlupe: w3.org
• W3C, Understanding WCAG 2.2 — 2.4.7 Fokus sichtbar, Verweis auf 1.4.11: w3.org
• W3C, Understanding WCAG 2.2 — 1.4.11 Nicht-Text-Kontrast, 3:1 für Fokusrahmen gegenüber angrenzenden Farben: w3.org
• W3C, Fehlerfall F78 — outline: none ohne Ersatz: w3.org
• W3C, Understanding WCAG 2.2 — 2.4.11 Fokus nicht verdeckt, vollständig gegen teilweise verdeckt, scroll-padding: w3.org
• W3C, What's New in WCAG 2.2 — neue Kriterien, veröffentlicht am 5. Oktober 2023: w3.org
• W3C, Understanding WCAG 2.2 — 1.4.13 Inhalte bei Hover oder Fokus, drei Bedingungen und Ausnahme: w3.org
• W3C, Understanding WCAG 2.2 — 3.2.1 Bei Fokus: w3.org
• W3C, Understanding WCAG 2.2 — 3.2.2 Bei Eingabe: w3.org
• W3C, Technik SCR35 — onclick an Links und Buttons ist geräteunabhängig: w3.org
• W3C, Fehlerfall F54 — Funktionen nur über Maus-Ereignisse: w3.org
• W3C, Technik SCR2 — Maus- und Tastaturereignisse paarweise: w3.org
• W3C WAI, ARIA Authoring Practices — Muster für modale Dialoge: w3.org
• MDN, tabindex — die drei Wertebereiche und die Empfehlung, nur 0 und -1 zu verwenden: developer.mozilla.org
• MDN, :focus-visible — Unterschied zu :focus: developer.mozilla.org
• Portal Barrierefreiheit des Bundes — Barrierefreiheitsstärkungsgesetz, Geltung ab 28.06.2025, Kleinstunternehmen: barrierefreiheit-dienstekonsolidierung.bund.de
• Portal Barrierefreiheit des Bundes — WCAG 2.1 und EN 301 549, Stufen A und AA: barrierefreiheit-dienstekonsolidierung.bund.de
• Microsoft, Accessibility Insights for Web — FastPass mit dem Test „Tab stops": accessibilityinsights.io