html-einfach.de

WCAG & BFSG · WCAG in der Praxis

Tastaturbedienung: Website ohne Maus bedienbar machen

Von Zuletzt geändert am

Eine Website ist tastaturbedienbar, wenn sich jede Funktion ohne Maus erreichen und auslösen lässt – Tab und Shift+Tab wechseln zwischen den Elementen, Enter und Leertaste aktivieren, Pfeiltasten navigieren innerhalb von Widgets, Esc schließt Dialoge – und der Fokus dabei jederzeit sichtbar bleibt. Sieben WCAG-Kriterien regeln dieses Themenfeld: 2.1.1, 2.1.2, 2.1.4, 2.4.3 und 3.2.1 auf Stufe A sowie 2.4.7 und 2.4.11 auf Stufe AA – alle über BFSG und BITV 2.0 verpflichtend.

Die Tastatur ist der Lackmustest der Barrierefreiheit: Funktioniert eine Seite ohne Maus, stimmt meist auch der Rest. Angewiesen darauf sind blinde Menschen (Screenreader sind im Kern Tastaturschnittstellen), Menschen mit motorischen Einschränkungen oder Bildschirmlupe, Nutzerinnen von Schaltern und Spezialeingaben, temporär Verletzte – und Power-User.

Den Ist-Zustand misst die WebAIM-Million-Analyse jährlich an einer Million Startseiten. Stand Februar 2026: 95,9 % mit automatisch feststellbaren WCAG-Fehlern, im Schnitt 56,1 pro Seite, nur 17,1 % mit Skip-Link, jeder zehnte davon defekt. Die kursierende 15-bis-20-Prozent-Behauptung zu Tastaturverstößen ist unbelegt; den Fokus-Indikator misst die Analyse gar nicht, weil er sich automatisiert nicht prüfen lässt.

Das Wichtigste in Kürze

  • Sieben WCAG-Kriterien regeln Tastatur und Fokus: 2.1.1, 2.1.2, 2.1.4, 2.4.3, 3.2.1 (Stufe A) sowie 2.4.7 und 2.4.11 (Stufe AA) – alle über BFSG und BITV 2.0 verpflichtend.
  • Grundbedienung: Tab/Shift+Tab wechseln zwischen Elementen, Enter und Leertaste aktivieren, Pfeiltasten navigieren in Widgets, Esc schließt Dialoge.
  • Der Fokus-Indikator braucht mindestens 3:1 Kontrast zu angrenzenden Farben (1.4.11); outline: none ohne Ersatz ist in meinen Audits der häufigste Fund zu 2.4.7.
  • tabindex kennt nur zwei sinnvolle Werte: 0 und -1 – positive Werte zerstören die Fokus-Reihenfolge.
  • Stand Juli 2026: :focus-visible (Baseline seit März 2022) und inert (seit April 2023) laufen in allen großen Browsern.
  • WebAIM Million, Februar 2026: 95,9 % von 1 Million Startseiten haben WCAG-Fehler.
  • Seit 28.06.2025 verlangt das BFSG Tastaturbedienbarkeit auch von Onlineshops; Übergangsfristen nach § 38 laufen längstens bis 27.06.2030.

Die Grundbedienung: ein Tab-Stopp pro Widget

Der Teil, den Eigenbauten meist vergessen, sind die Pfeiltasten: Sie navigieren innerhalb zusammengesetzter Widgets – Radiogruppen, Auswahllisten, Tabs, Menüs. Das Prinzip dahinter formuliert der W3C-Leitfaden für Tastaturschnittstellen: Pro zusammengesetztem Widget gehört nur ein Tab-Stopp in die Tab-Folge – Tab wechselt zwischen Komponenten, Pfeiltasten bewegen sich darin.

Native HTML-Elemente liefern all das gratis: <a href>, <button> und <select> sind ohne eine Zeile JavaScript bedienbar – die Unterschiede erklärt Buttons vs. Links. Ein <div> mit Click-Handler ist für die Tastatur unsichtbar:

<!-- Für die Tastatur unsichtbar -->
<div class="knopf" onclick="speichern()">Speichern</div>

<!-- Fokussierbar, Enter und Leertaste funktionieren, Rolle stimmt -->
<button type="button" onclick="speichern()">Speichern</button>

Wer es doch tastaturfähig macht, braucht tabindex="0", ARIA-Rolle und keydown-Handler für Enter und Leertaste – und bleibt hinter dem nativen Element zurück.

Sieben Kriterien, ein Themenfeld

Alle sieben Kriterien stecken über die EN 301 549 im BFSG – seit 28.06.2025 auch für weite Teile der Privatwirtschaft, etwa E-Commerce – und in der BITV 2.0 für öffentliche Stellen. § 38 BFSG regelt die Übergangsfristen: Dienstleistungen mit vor dem 28.06.2025 rechtmäßig eingesetzten Produkten bis längstens 27.06.2030, Selbstbedienungsterminals bis zum Ende der wirtschaftlichen Nutzungsdauer, höchstens 15 Jahre. Keine Rechtsberatung – Details unter Ausnahmen, Fristen, Bußgeld und Aktuelles zum BFSG.

2.1.1 Tastatur (A): alles muss ohne Maus gehen

2.1.1 „Tastatur“ verlangt, dass sich jede Funktion über die Tastaturschnittstelle bedienen lässt, ohne Zeitvorgaben für einzelne Anschläge; ausgenommen sind nur pfadabhängige Eingaben wie Freihandzeichnen. Drei Feinheiten aus dem W3C-Understanding-Dokument: MouseKeys erfüllt das Kriterium nicht, weil es eine Maus emuliert; eine gleichwertige Alternative genügt (Enter im Suchfeld statt Klick auf den Lupe-Button); Drag-and-drop ist nicht ausgenommen – Ziehen mit relevanten Endpunkten braucht eine Alternative, wie Karten und Drag-and-drop sie zeigt. Die AAA-Verschärfung 2.1.3 streicht selbst diese Ausnahme für pfadabhängige Eingaben.

2.1.2 Keine Tastaturfalle (A): überall wieder heraus

2.1.2 „Keine Tastaturfalle“: Was der Fokus per Tastatur betreten kann, muss er per Tastatur verlassen können; braucht es dafür andere Tasten als Tab oder Esc, muss die Seite das sagen (W3C-Technik G21). Typische Fallen: iFrames und Dritt-Widgets, Modal-Dialoge ohne Esc und erreichbaren Schließen-Button, endlos nachladende Listen, hinter denen der Footer unerreichbar bleibt.

2.1.4 Tastenkürzel (A): das „Hey Kim“-Problem

2.1.4 „Tastenkürzel“ betrifft Kürzel aus einzelnen Buchstaben, Ziffern oder Satzzeichen. Warum, zeigt das W3C-Beispiel: Eine Sprachsteuerungs-Nutzerin heißt Kim, ein Kollege ruft „Hey Kim“ – ihr Webmailer liest Y als Archivieren, K als „eine Konversation weiter“ und M als Stummschalten. Solche Kürzel müssen abschaltbar, mit Modifier (Strg/Alt) umbelegbar oder nur bei Fokus der Komponente aktiv sein; eigene Shortcuts wie „S für Suche“ sind nur mit einer dieser Sicherungen erlaubt.

2.4.3 Fokus-Reihenfolge (A): das DOM bestimmt

Die Tab-Reihenfolge folgt dem DOM, nicht der Optik; 2.4.3 „Fokus-Reihenfolge“ verlangt, dass sie Sinn und Bedienbarkeit erhält. Klassischer Fehler ist der Zickzack-Fokus: flex-direction: row-reverse, order oder freie Grid-Platzierung ändern nur die Darstellung. 

/* Optisch zuerst, im DOM zuletzt – der Fokus springt ans „Ende“ */
.aktions-leiste { display: flex; flex-direction: row-reverse; }

3.2.1 Bei Fokus (A): Fokussieren ist keine Aktion

3.2.1 „Bei Fokus“ verbietet, dass das bloße Fokussieren einen Kontextwechsel auslöst: kein Absenden, kein neues Fenster, kein Fokus-Wegspringen. Klassiker ist das <select>, das bei onchange weiterleitet – wer sich mit Pfeiltasten durch die Optionen bewegt, navigiert ungewollt. Der BITV-Test prüft genau das.

2.4.7 Fokus sichtbar (AA): niemals unterdrücken

2.4.7 „Fokus sichtbar“ fordert einen sichtbaren Tastaturfokus; die Form ist frei – Rahmen, Farb- oder Hintergrundwechsel, Unterstreichung –, Hauptsache Kontrast und Fläche stimmen. Am häufigsten finde ich in Audits outline: none ohne gleichwertigen Ersatz.

2.4.11 Fokus nicht verdeckt (AA): Sticky-Header im Weg

Neu seit WCAG 2.2 (Oktober 2023): 2.4.11 „Fokus nicht verdeckt“ verbietet, dass das fokussierte Element vollständig hinter autorenerzeugtem Inhalt verschwindet – typisch Sticky-Header und Cookie-Banner beim Rückwärts-Tabben. Drei Auswege: Banner modal machen, automatisch schließen – oder ein Ein-Zeilen-Fix: 

/* Reserviert beim Scrollen zu fokussierten Elementen Platz für den Sticky-Header */
html { scroll-padding-top: 5rem; }

Der Fokusring: sichtbar, kontrastreich, robust

:focus vs. :focus-visible

:focus trifft jede Fokussierung, auch die per Maus; :focus-visible greift nur, wenn der Browser eine sichtbare Anzeige für nötig hält – bei Tastatur ja, bei Maus meist nein. Damit erledigt sich der alte Streit „der Ring stört beim Klicken“. Laut MDN ist :focus-visible seit März 2022 Baseline in allen großen Browsern (Stand Juli 2026).

/* Anti-Pattern: macht die Tastaturbedienung unsichtbar */
:focus { outline: none; }

/* Kräftiger Ring nur bei Tastaturbedienung */
:focus-visible {
  outline: 3px solid #0b3d91;
  outline-offset: 2px;
}

/* Optional: Maus-Fokus zurücksetzen, Tastatur-Fokus behalten */
:focus:not(:focus-visible) { outline: none; }

Ein Ring, der AA erfüllt und AAA übersteht

Pflicht (AA) ist 1.4.11 „Nicht-Text-Kontrast“: mindestens 3:1 Kontrast zu angrenzenden Farben – messen wie bei Farbkontrasten. Die AAA-Zielmarke 2.4.13 „Fokus-Erscheinungsbild“ ergänzt eine Mindestfläche von der Größe eines 2-CSS-Pixel-Perimeters um die unfokussierte Komponente plus 3:1 Kontrast zwischen fokussiertem und unfokussiertem Zustand. Rechenbeispiel: Ein Button von 90 × 30 px hat 240 px Umfang, mal 2 px ergibt 480 px² – eine durchgehende 2-px-Outline erfüllt das automatisch. Mein Standardrezept ist ein Zweifarb-Ring:

:focus-visible {
  outline: 2px solid #0b3d91;      /* dunkler Ring */
  outline-offset: 2px;
  box-shadow: 0 0 0 2px #ffffff;   /* heller Zwischenring */
}

Der helle Zwischenring sichert 3:1 auf dunklen Flächen, die dunkle Outline auf hellen; outline folgt inzwischen dem border-radius.

Windows-Kontrastmodus nicht vergessen

Im Forced-Colors-Modus (Windows-Kontrastmodus) ersetzt das System alle Farben und entfernt box-shadow: Ein Fokusring nur daraus ist dort weg. Der Trick ist eine zusätzliche transparente Outline – sie bleibt erhalten und bekommt die Systemfarbe.

.knopf:focus-visible {
  box-shadow: 0 0 0 3px #0b3d91;
  outline: 2px solid transparent;  /* im Kontrastmodus sichtbar */
  outline-offset: 2px;
}

tabindex: zwei Werte genügen

  • tabindex="0" nimmt ein Element in die DOM-Reihenfolge auf – nötig nur für echte Custom-Controls und scrollbare Bereiche.
  • tabindex="-1" macht ein Element per Skript fokussierbar, ohne es in die Tab-Folge zu legen – für Modals, Sprungziele, Fehlermeldungen.
  • Positive Werte (tabindex="3") niemals: Sie hebeln die Dokumentreihenfolge aus, verletzen fast immer 2.4.3 und machen jede Änderung zum Wartungsalptraum.

Dazu zwei Regeln: kein Fokus auf unsichtbare Elemente, und nie aria-hidden="true" auf etwas Fokussierbares – sonst landet der Fokus auf einem für Screenreader nicht existenten Element. Umgekehrt sinnvoll: In klickbaren Cards nimmt tabindex="-1" plus aria-hidden="true" den redundanten zweiten Link aus der Tab-Folge. Wie oft das schiefgeht, zeigt die WebAIM Million: 30,4 tabindex-Instanzen je Startseite (Februar 2026, plus 17 % gegenüber 2025).

<!-- Sprungziel: per Skript fokussierbar, nicht in der Tab-Folge -->
<main id="inhalt" tabindex="-1">…</main>

<!-- Nie: positive Werte -->
<input tabindex="3" name="plz">

Ein Skip-Link zum Hauptinhalt als erstes fokussierbares Element erspart das Durchtabben der Navigation – eine mögliche Technik für 2.4.1 „Blöcke umgehen“ (Stufe A). Das Sprungziel bekommt tabindex="-1", damit der Fokus dort ankommt.

Dialoge: natives dialog-Element plus inert

Für Dialoge und Modals gilt das Vier-Punkte-Programm: Fokus beim Öffnen in den Dialog, dort halten, Esc schließt, Fokus zurück zum Auslöser. Das native <dialog> mit showModal() erledigt fast alles selbst – Fokus hinein, Esc eingebaut, Top-Layer. Den Seitenrest nimmt inert aus dem Spiel: Es entfernt Fokus, Klicks und den Eintrag im Accessibility-Tree (MDN-Detail: per showModal() geöffnete Dialoge entkommen der inert-Vererbung). inert ist seit April 2023 Baseline (Stand Juli 2026).

const dialog = document.querySelector("#einstellungen");
const oeffner = document.querySelector("#einstellungen-oeffnen");

oeffner.addEventListener("click", () => {
  dialog.showModal();                       // Fokus hinein, Esc eingebaut
  document.querySelector("main").inert = true;
});

dialog.addEventListener("close", () => {
  document.querySelector("main").inert = false;
  oeffner.focus();                          // Fokus-Rückgabe sicherstellen
});

Das löst 2.1.2 gleich mit – ohne Focus-Trap-Bibliothek.

Roving tabindex in zusammengesetzten Widgets

Damit ein Widget nur einen Tab-Stopp belegt, wandert der tabindex: Das aktive Element trägt 0, alle anderen -1; bei jeder Pfeiltaste tauschen die Werte, element.focus() zieht den Fokus mit und scrollt das Element in den Sichtbereich.

function aktiviereTab(tabs, neuerTab) {
  tabs.forEach((tab) => (tab.tabIndex = -1));
  neuerTab.tabIndex = 0;
  neuerTab.focus();
}

Die Alternative ist aria-activedescendant: Der DOM-Fokus bleibt auf dem Container, die assistive Technologie bekommt trotzdem die passenden Fokus-Events – praktisch bei Comboboxen und Autocomplete. Beide Muster vollständig zeigen Tabs und Menüs und Dropdowns.

So testest du es

Mein Testrezept kombiniert den Tab-Test mit dem BITV-Prüfschritt 9.2.1.1 – Maus weglegen, dann:

  1. Seite in Firefox mit Tab durchgehen; landet der Fokus nicht im Seitenfenster, holt F6 ihn dorthin.
  2. Erreichbarkeit: Kommt der Fokus an jeden Link, Button, jedes Formularfeld und in jeden scrollbaren Bereich?
  3. Sichtbarkeit und Reihenfolge: Ist erkennbar, wo der Fokus steht, und folgt er der visuellen Logik? Dabei helfen das Bookmarklet „Force Show Keyboard Focus“ und der Firefox Accessibility Inspector („Tab-Reihenfolge anzeigen“).
  4. Aktivieren: Enter auf Links, Enter und Leertaste auf Buttons; Auswahllisten mit Alt+Pfeil-runter öffnen – ohne dass die Seite navigiert.
  5. Mit Shift+Tab rückwärts – dieselbe Strecke, andere Fehler.
  6. Overlays öffnen: Schließt Esc? Kehrt der Fokus zum Auslöser zurück?
  7. Custom Components: Slider und Karussells, Datepicker, Menüs – funktionieren die Pfeiltasten?
  8. Alles in Chrome wiederholen – der BITV-Test prüft bewusst in beiden Browsern.

Mehr davon sammelt Barrierefreiheit selbst testen.

Häufiger Fehler in der Praxis

Der CSS-Reset killt den Ring. In vielen Projekten steckt noch ein *:focus { outline: none } aus einem Boilerplate der 2010er – unbemerkt, weil das Team mit der Maus testet. Mein erster Griff im Audit ist die Suche nach outline; der Fund ist fast garantiert.

Der Fokusdieb. autofocus, ein focus() beim Laden, ein Karussell, das bei jeder Rotation den Fokus an sich reißt: Alles, was den Fokus ungefragt versetzt, wirft Tastatur- und Screenreader-Nutzer aus der Bahn – das Spiegelbild zu 3.2.1.

Aufgeräumt und dabei kaputtrepariert. Nach einem Redesign stimmt die Reihenfolge nicht mehr, und jemand „repariert“ sie mit tabindex="1" bis tabindex="7" – ab jetzt kommen diese sieben Elemente vor allem anderen, auch vor dem Skip-Link. Sauber ist nur eins: die DOM-Reihenfolge an die visuelle anpassen.

Neue Tab-Stopps, die niemand eingebaut hat. Chrome macht seit Version 132 (Januar 2025) scrollbare Container ohne fokussierbare Kinder von sich aus tastaturfokussierbar – ein erster Anlauf in Chrome 127 (Juli 2024) wurde wegen Kompatibilitätsproblemen zurückgezogen. Plötzlich fokussierbare Code-Boxen im Audit sind kein Bug. Firefox verhält sich seit Längerem ebenso, Safari nicht – deshalb weiterhin selbst tabindex="0" plus Beschriftung setzen.

Häufige Fragen

Wie teste ich, ob meine Website mit der Tastatur bedienbar ist?

Maus weglegen und mit Tab durch die ganze Seite gehen: Jedes interaktive Element muss erreichbar sein, der Fokus jederzeit sichtbar, die Reihenfolge logisch, Enter und Leertaste müssen aktivieren, Esc muss Overlays schließen, und nirgends darfst du stecken bleiben. Der BITV-Test prüft das in Firefox und Chrome, weil sich Fokusverhalten unterscheidet.

Warum darf man outline: none nicht verwenden?

Weil damit der einzige sichtbare Hinweis verschwindet, wo sich der Tastaturfokus befindet – die Seite ist dann per Tastatur praktisch blind zu bedienen, ein Verstoß gegen WCAG 2.4.7 (Stufe AA). Erlaubt ist das Entfernen nur, wenn gleichzeitig ein mindestens gleichwertiger eigener Indikator gesetzt wird, etwa eine kontrastreiche Outline auf :focus-visible mit outline-offset.

Was ist der Unterschied zwischen :focus und :focus-visible?

:focus greift bei jeder Fokussierung, auch nach einem Mausklick. :focus-visible greift nur, wenn der Browser eine sichtbare Fokusanzeige für nötig hält – bei Tastaturbedienung immer, nach Mausklicks meist nicht. Damit bekommst du einen kräftigen Fokusring für Tastaturnutzer, ohne dass er bei jedem Klick aufblitzt. Baseline-Support besteht seit März 2022 (Stand Juli 2026).

Was ist eine Tastaturfalle und wie vermeide ich sie?

Eine Tastaturfalle ist ein Bereich, in den der Fokus per Tastatur hineinkommt, aber nicht mehr heraus – verboten durch WCAG 2.1.2 (Stufe A). Typisch sind eingebettete Widgets, iFrames und selbstgebaute Modals. Vermeiden: natives <dialog> mit showModal() verwenden, Esc anbieten, den Seitenrest per inert deaktivieren und jede Einbettung einmal komplett durchtabben.

Ist Tastaturbedienbarkeit gesetzlich vorgeschrieben?

Ja. Für öffentliche Stellen über die BITV 2.0, für weite Teile der Privatwirtschaft – etwa Onlineshops – seit dem 28.06.2025 über das BFSG. Beide verweisen über die EN 301 549 auf die WCAG-Stufen A und AA. Übergangsfristen nach § 38 BFSG laufen längstens bis zum 27.06.2030 (keine Rechtsberatung).

Fazit

Native Elemente, eine saubere DOM-Reihenfolge, ein kontrastreicher :focus-visible-Ring sowie <dialog> und inert erledigen den Großteil aller sieben Kriterien – der Rest ist Tabben ohne Maus.

Verwandte Themen

Quellen

Gratis E-Book PDF Das Praxishandbuch

Kostenloses E-Book

Das Praxishandbuch für sauberes, zugängliches Web

Alles rund um semantisches HTML, Barrierefreiheit, WCAG & BFSG, GEO und SEO — praxisnah und am echten Code. In mehreren Feedbackschleifen von Leserinnen und Lesern verbessert.

  • 3.000+ Downloads
  • 7. Auflage
  • 37 Seiten
  • PDF

Kein Spam. Abmeldung jederzeit mit einem Klick möglich.