Wie teste ich die Tastaturzugänglichkeit?

Legen Sie die Maus beiseite und navigieren Sie mit Tab, Umschalt+Tab, Enter, Leertaste und den Pfeiltasten. Wenn Sie ein Element nicht erreichen, nicht bedienen oder den Fokus nicht sehen können, liegt ein Tastaturfehler vor.

Warum scheitern Klick-Handler auf div-Elementen bei Tastaturnutzern?

Ein ` ` oder ` ` mit `onclick` ist standardmäßig weder fokussierbar noch per Tastatur bedienbar. Verwenden Sie ein natives ` ` oder ` ` oder ergänzen Sie `tabindex`, einen Tastatur-Handler und die richtige Rolle – native Elemente sind deutlich sicherer.

Welche WCAG-Regel deckt den Tastaturzugang ab?

SC 2.1.1 (Tastatur), Stufe A, flankiert von 2.1.2 (Keine Tastaturfalle). Alles, was mit der Maus möglich ist, muss auch mit der Tastatur möglich sein.

Häufige Verstöße

Tastaturunzugängliche Steuerelemente: Warum 'funktioniert mit der Maus' nicht reicht

Versuchen Sie, Ihre Maus abzustecken und Ihre Website nur mit Tab, Umschalt+Tab, Eingabe und den Pfeiltasten zu navigieren. Wenn Sie nicht jedes interaktive Element erreichen können oder nicht erkennen können, wo Sie sich auf der Seite befinden, haben Sie einen Tastaturbarrierefreiheitsfehler gefunden – und Sie haben gerade die Website so erlebt, wie sie standardmäßig jeder reine Tastaturnutzer, jeder Nutzer eines Schaltgeräts und jeder Screenreader-Nutzer erlebt, da Screenreader über dieselbe Tastaturschnittstelle navigieren statt über einen Zeiger.

Branchendaten beziffern Tastaturunzugänglichkeit auf etwa 61 % der ADA-Beschwerden zur Web-Barrierefreiheit – das vierthäufigste zitierte Problem, und eines, das automatisierte Werkzeuge nur teilweise erfassen können (WCAG-Erfolgskriterium 2.1.1, Tastatur, ist eine Kategorie-B-"teilweise automatisierbare" Prüfung: Ein Scanner kann verdächtige Muster wie ein tabindex ungleich null markieren, aber die Bestätigung vollständiger Tastaturbedienbarkeit erfordert tatsächliches Durchtabben der Seite).

Die häufigsten Fehlermuster

Ein <div> oder <span>, das wie eine Schaltfläche aussieht, mit nur einem onclick-Handler. Mausklicks lösen es aus; Tab überspringt es komplett, da ein reines <div> nicht in der Tastaturfokus-Reihenfolge liegt und keine eingebaute Eingabe-/Leertaste-Aktivierung besitzt.

<!-- Vorher: für Tastaturnutzer unsichtbar -->
<div class="button" onclick="submitForm()">Absenden</div>

<!-- Nachher: eine echte Schaltfläche, fokussierbar und kostenlos per Eingabe/Leertaste aktivierbar -->
<button type="submit">Absenden</button>

Von Grund auf selbstgebaute Dropdowns, Modals und Menüs, die nur auf mouseover/mouseout reagieren und nie Tastaturereignisse verdrahten (Esc zum Schließen, Pfeiltasten zum Wechseln zwischen Optionen, Eingabe zum Auswählen).

Ein sichtbarer Fokusindikator, der entfernt wurde. Selbst eine vollständig tastaturbedienbare Seite scheitert in der Praxis, wenn outline: none (oder Ähnliches) global ohne Ersatz angewendet wird – ein Tastaturnutzer kann technisch durch die Seite tabben, hat aber keine Möglichkeit zu sehen, wo er sich befindet. Dies überschneidet sich mit WCAG 2.4.7 (Fokus sichtbar).

Positive tabindex-Werte (tabindex="1", tabindex="2" usw.), die versuchen, die Tab-Reihenfolge manuell zu steuern – diese erzeugen fast immer eine schlechtere Reihenfolge als die natürliche DOM-Reihenfolge, die sie überschreiben, und axe-core markiert jeden positiven Tabindex genau aus diesem Grund.

Wie man es behebt

Bevorzugen Sie echte, native interaktive Elemente (<button>, <a href>, <input>, <select>) gegenüber der Nachbildung ihres Verhaltens auf generischen Elementen – sie bringen Tastaturunterstützung, Fokusverwaltung und Screenreader-Semantik kostenlos mit. Dies ist dasselbe Prinzip "semantisches HTML vor ARIA", das für die meisten Barrierefreiheitskorrekturen gilt: bauen Sie nicht neu, was die Plattform bereits korrekt bereitstellt.

Wenn ein benutzerdefiniertes Widget unvermeidlich ist, benötigt es den vollständigen Satz erwarteter Tastaturinteraktionen für seine Rolle (der WAI-ARIA Authoring Practices Guide dokumentiert den genauen Tastaturvertrag für jedes gängige Widget-Muster – Menüs, Tabs, Dialoge, Comboboxen) sowie einen sichtbaren Fokusstil und tabindex="0" (niemals eine positive Zahl), um es in die natürliche Tab-Reihenfolge zu bringen.

Offizielle Referenzen

Deque University: tabindex

Häufige Fragen

Wie teste ich die Tastaturzugänglichkeit?: Legen Sie die Maus beiseite und navigieren Sie mit Tab, Umschalt+Tab, Enter, Leertaste und den Pfeiltasten. Wenn Sie ein Element nicht erreichen, nicht bedienen oder den Fokus nicht sehen können, liegt ein Tastaturfehler vor.
Warum scheitern Klick-Handler auf div-Elementen bei Tastaturnutzern?: Ein `<div>` oder `<span>` mit `onclick` ist standardmäßig weder fokussierbar noch per Tastatur bedienbar. Verwenden Sie ein natives `<button>` oder `<a>` oder ergänzen Sie `tabindex`, einen Tastatur-Handler und die richtige Rolle – native Elemente sind deutlich sicherer.
Welche WCAG-Regel deckt den Tastaturzugang ab?: SC 2.1.1 (Tastatur), Stufe A, flankiert von 2.1.2 (Keine Tastaturfalle). Alles, was mit der Maus möglich ist, muss auch mit der Tastatur möglich sein.