Tastaturbedienung: die Prüfung, die du in fünf Minuten selbst machst

Worum es geht

Ein Teil deiner Besucher benutzt keine Maus. Manche wegen einer motorischen Einschränkung, manche weil sie einen Screenreader verwenden, manche weil sie mit Spracheingabe arbeiten. Für sie ist die Tabulatortaste das Navigationsinstrument.

Damit das funktioniert, müssen drei Dinge stimmen: Jedes Bedienelement muss per Tab erreichbar sein, die Reihenfolge muss der Leserichtung folgen, und es muss jederzeit sichtbar sein, wo der Fokus gerade steht.

Dazu kommt die Struktur darunter: Landmarks (header, nav, main, footer), mit denen Screenreader-Nutzer direkt in den Hauptinhalt springen, und ein Skip-Link, der die Navigation überspringt.

Warum das zählt

WCAG 2.1.1 (Level A) verlangt, dass die gesamte Funktionalität per Tastatur bedienbar ist. WCAG 2.1.2 verlangt, dass Nutzer nirgends hängenbleiben — der klassische Fall ist ein Cookie-Banner oder ein Dialog, den man per Tastatur nicht schließen kann. Und WCAG 2.4.7 (Level AA) verlangt einen sichtbaren Fokus mit mindestens 3:1 Kontrast zur Umgebung (Rheinwerk, Barrierefreie Webseiten, Kap. 8.2).

Der Skip-Link ist der Punkt, an dem der Aufwand am sichtbarsten wird. Ohne ihn muss ein Tastaturnutzer auf jeder einzelnen Seite durch die komplette Navigation tabben, bevor er beim Inhalt ankommt. Bei einem Menü mit dreißig Einträgen ist das dreißigmal Tab — pro Seite.

Zwei Fehlerklassen sehe ich regelmäßig.

Fokus unsichtbar gemacht. Irgendwo im CSS steht outline: none, weil jemand den blauen Standardrahmen unschön fand. Damit ist die Seite technisch weiter bedienbar, aber niemand sieht mehr, wo er ist. Das ist, als würde man den Mauszeiger ausblenden.

Positive tabindex-Werte. Ein Element mit tabindex="1" springt an den Anfang der gesamten Tab-Reihenfolge des Dokuments, unabhängig davon, wo es steht. Ein paar solcher Werte machen die Reihenfolge unvorhersehbar. Die Empfehlung ist eindeutig: eine logische Reihenfolge über die HTML-Struktur erreichen statt über tabindex (Rheinwerk, Barrierefreie Webseiten, Kap. 8.2).

Es gibt außerdem eine Reihe von Fehlern, die sich ohne jedes Urteilsvermögen feststellen lassen und deshalb schwer zu diskutieren sind: ARIA-Verweise, die auf nichts zeigen. Rollen, die es nicht gibt. Eine ID, die doppelt vergeben ist und auf die ein Label oder ein Sprunglink verweist — dann wird nur der erste Treffer gefunden. Ein Skip-Link, dessen Ziel fehlt oder keinen Fokus annehmen kann. Solche Fälle sind schlicht kaputt.

Noch eine Sache zu Bedienelementen: WCAG 2.5.8 (Level AA) verlangt mindestens 24 × 24 CSS-Pixel für Klickziele — mit einer Ausnahme, die zählt: Ein kleineres Ziel ist in Ordnung, wenn im Umkreis von 24 Pixeln um seinen Mittelpunkt nichts anderes liegt. Gut verteilte Fußzeilenlinks sind also kein Fehler.

Und ein Wort zu Accessibility-Overlays: Diese Widgets, die per Skript eine Bedienleiste einblenden, ändern an den hier genannten Punkten nichts. Was sie anbieten, sind Schriftgrößen und Kontrastschalter. Was sie nicht reparieren, sind fehlende Labels, kaputte Fokusreihenfolgen und Tastaturfallen.

Wie du das selbst prüfst

Das ist der Test, den du wirklich selbst machen kannst, und er dauert fünf Minuten.

Öffne deine Startseite in einem privaten Fenster — ohne Cookies zu akzeptieren, denn genau dann steht das Banner im Weg und du siehst, wie sich die Seite tatsächlich verhält (Rheinwerk, Barrierefreie Webseiten, Kap. 8.2). Leg die Maus zur Seite. Dann drücke Tab.

Achte auf fünf Dinge:

Ist der allererste Sprung ein Skip-Link („Zum Inhalt springen")? Er darf unsichtbar sein, solange er nicht fokussiert ist — aber sobald er den Fokus hat, muss er sichtbar werden.

Siehst du bei jedem Schritt, wo du bist?

Folgt die Reihenfolge dem, was du liest — oben nach unten, links nach rechts?

Kommst du überall wieder heraus? Öffne bewusst das Menü, ein Akkordeon, ein Modal. Schließt Escape es? Kommst du danach dorthin zurück, wo du warst?

Kannst du alles auslösen? Links mit Enter, Buttons mit Enter und Leertaste.

Wenn du an einer Stelle nicht weiterkommst oder nicht mehr weißt, wo du bist, hast du den Befund gefunden.

Was zu tun ist, wenn es fehlt

Setze einen Skip-Link als erstes fokussierbares Element, verlinkt auf die id des <main>-Elements.

Ersetze jedes outline: none durch einen eigenen sichtbaren Fokusstil. Ein bewährter Wert ist ein Rahmen von mindestens 2 px mit etwas Abstand:

:focus-visible { outline: 3px solid #1a73e8; outline-offset: 2px; }

Entferne alle positiven tabindex-Werte. Wenn die Reihenfolge danach falsch ist, ist die HTML-Reihenfolge falsch — und die gehört repariert, nicht überschrieben.

Baue die Seitenstruktur mit echten Landmarks: ein <header>, ein <main>, ein <footer>, <nav> für Navigationsblöcke, und bei mehreren <nav> je ein aria-label zur Unterscheidung.

Bei interaktiven Elementen greife zuerst zu den nativen: <details>/<summary> für Akkordeons und <dialog> mit showModal() für Modals bringen Fokusverwaltung, Escape-Verhalten und Rückkehr des Fokus mit, ohne dass jemand sie programmieren muss.

Und für Klickziele: Vergrößere die klickbare Fläche über Innenabstand, nicht über Schriftgröße.

Quellen

• WCAG 2.1.1 (Level A) verlangt vollständige Tastaturbedienbarkeit; WCAG 2.1.2 verbietet Tastaturfallen, klassischer Fall Cookie-Banner oder Dialog ohne Tastaturausstieg; WCAG 2.4.7 (Level AA) verlangt sichtbaren Fokus mit 3:1 Kontrast nach WCAG 1.4.11; Test im Inkognito-Fenster ohne Cookie-Zustimmung; Prüfliste Erreichbarkeit, Tab-Reihenfolge, sichtbarer Fokus, Herauskommen, reine Tastaturfunktion; positive tabindex-Werte machen ein Element zu einem der ersten fokussierbaren des Dokuments und sind fehleranfällig; logische Reihenfolge über HTML-Struktur statt über tabindex; WCAG 2.4.11 Focus Not Obscured; Fokusreihenfolge folgt der Quelltextreihenfolge -- @ctx:atlas-accessibility-rheinwerk-barrierefreie-webseiten-08-02-keyboard-operability@1 -- Rheinwerk, Barrierefreie Webseiten, Kap. 8.2
• WCAG 2.4.1 Bypass Blocks (Level A): Mechanismus zum Überspringen wiederholter Inhalte; Skip-Link als erstes fokussierbares Element, verlinkt auf die id des main-Elements; ohne ihn muss jede Seite komplett durchtabbt werden -- @ctx:atlas-accessibility-criteria-2-4-1-bypass-blocks@1
• WCAG 2.5.8 Target Size (Minimum), Level AA: mindestens 24 × 24 CSS-Pixel; Ausnahme bei ausreichendem Abstand zu Nachbarzielen; Klickfläche über Innenabstand vergrößern -- @ctx:atlas-accessibility-criteria-2-5-8-target-size-minimum@1
• Landmarks header / nav / main / footer auf jeder Seite, mehrere nav je mit aria-label; kein positiver tabindex; sichtbarer Fokusindikator auf allen interaktiven Elementen, mindestens 2 px, Codebeispiel :focus-visible; native details/summary und dialog bevorzugen wegen eingebauter Fokusverwaltung und Escape-Verhalten; Tastaturverhalten je Komponente -- @ctx:atlas-accessibility-wcag22-checklist@1
• Tastaturzugänglichkeit und Fokusverwaltung als technische Grundlage der EAA/BFSG-Anforderungen; teuerster Sanierungsposten sind tastaturbedienbare Custom-Widgets -- @ctx:atlas-legal-eu-accessibility-act@2