html-einfach.de

WCAG & BFSG · WCAG in der Praxis

Tastaturbedienung & sichtbarer Fokus

Von Zuletzt geändert am

Die Tastatur ist der Lackmustest der Barrierefreiheit. Wer keine Maus benutzen kann – aus motorischen Gründen, mit einem Screenreader, mit alternativen Eingabegeräten oder schlicht aus Gewohnheit –, bedient eine Seite vollständig über die Tastatur. Funktioniert das, ist meist auch vieles andere in Ordnung. Funktioniert es nicht, hilft kein noch so hübsches Design.

Zwei Dinge gehören dabei untrennbar zusammen: Alles muss bedienbar sein, und der Fokus muss dabei immer sichtbar sein. Das eine ohne das andere genügt nicht.

Alles bedienbar – ohne Fallen

Das Grundkriterium 2.1.1 verlangt, dass sich jede Funktion per Tastatur nutzen lässt. Die gute Nachricht: Native Elemente bringen das mit. Ein <button> und ein <a href> sind automatisch fokussierbar und auslösbar – Enter beim Link, Enter und Leertaste beim Button. Probleme entstehen fast immer dort, wo dieses Verhalten mit <div> und Skript nachgebaut wurde und die Hälfte vergessen wurde.

Ebenso wichtig (2.1.2): keine Fokusfalle. Man muss aus jedem Element auch wieder heraustabben können – ein häufiger Fehler bei selbstgebauten Dialogen und Menüs.

Der Fokus muss sichtbar sein

Kriterium 2.4.7 verlangt einen sichtbaren Fokus – man muss jederzeit erkennen, wo man gerade ist. Der größte Sündenfall ist hier eine einzige CSS-Zeile:

/* Niemals ohne Ersatz – macht die Tastaturbedienung blind */
:focus { outline: none; }

Wer den Standard-Umriss entfernt, muss einen deutlich sichtbaren Ersatz setzen. Ich nutze dafür :focus-visible, damit der kräftige Fokusring bei Tastaturnutzung erscheint, ohne bei jedem Mausklick aufzupoppen:

:focus-visible {
  outline: 3px solid #0b3d91;
  outline-offset: 2px;
}

Genau so ist es auf dieser Website umgesetzt. Der Fokusring braucht übrigens selbst genug Kontrast (3:1) – ein blasser Ring ist fast so schlecht wie keiner. Und seit WCAG 2.2 darf das fokussierte Element nicht von Sticky-Headern verdeckt sein (2.4.11).

Eine logische Reihenfolge

Der Fokus soll der Lesereihenfolge folgen (2.4.3). Am einfachsten erreichst du das, indem die DOM-Reihenfolge der sichtbaren Reihenfolge entspricht – dann stimmt die Tab-Reihenfolge fast von allein. Für tabindex gilt:

  • tabindex="0" – nimmt ein Element in die natürliche Reihenfolge auf.
  • tabindex="-1" – macht es per Skript fokussierbar, aber nicht per Tab erreichbar (etwa das Sprungziel eines Skip-Links).
  • Positive Werte (tabindex="3") – vermeide ich konsequent. Sie hebeln die natürliche Reihenfolge aus und werden fast immer zur Stolperfalle.

Ein Skip-Link als erstes Element erspart dabei das ewige Durchtabben der Navigation.

Der billigste wirksame Test

Es gibt kaum einen besseren Schnelltest: Maus weglegen und die Seite einmal komplett mit Tab, Shift+Tab, Enter, Leertaste und den Pfeiltasten durchspielen. Kommt man überall hin? Sieht man immer, wo man ist? Bleibt man irgendwo hängen? Diesen Durchlauf mache ich vor jedem Launch – er deckt mehr auf als jedes automatische Tool. Mehr dazu unter Barrierefreiheit selbst testen.

Häufige Fehler

  • outline: none ohne Ersatz. Der Klassiker – Fokus unsichtbar.
  • Klickbare <div>. Nicht fokussierbar, nicht auslösbar.
  • Fokusfalle in Overlays und Menüs – man kommt nicht mehr heraus.
  • Unlogische Reihenfolge durch positive tabindex oder CSS-Umsortierung.
  • Verdeckter Fokus hinter Sticky-Headern (WCAG 2.2).

Häufige Fragen

Was ist mit komplexen Widgets wie Tabs?

Die haben ein eigenes Tastaturmodell (Pfeiltasten, Roving Tabindex) – nachzulesen unter Tabs. Das ist die Ausnahme; die meisten Elemente folgen dem einfachen Tab/Enter-Modell.

Darf ich den Fokus per Skript setzen?

Ja, gezielt – etwa in einen geöffneten Dialog oder auf eine Fehlermeldung. Wichtig ist, dass der Fokus nachvollziehbar wandert und nicht „springt“, ohne dass klar ist, warum.

Reicht es, wenn die Maus funktioniert?

Nein. Maus-Bedienbarkeit sagt nichts über die Tastatur aus. Der Tastatur-Durchlauf ist ein eigener, unverzichtbarer Test.

Fazit

Tastaturbedienbarkeit heißt: alles erreichbar und auslösbar, keine Fokusfallen, der Fokus immer sichtbar und in logischer Reihenfolge. Native Elemente liefern den Großteil davon gratis; der Rest ist Disziplin beim CSS (:focus-visible statt outline:none) und beim DOM-Aufbau. Und der ehrlichste Prüfstein bleibt: einmal die Maus weglegen.