Ein Sprunglink ganz oben spart Tastaturnutzenden auf jeder Seite dutzende Tastendrücke: einmal Tabulator, Eingabetaste, vorbei an Navigation und Kopfzeile. Fast jede Seite, die Barrierefreiheit ernst nimmt, hat einen — und erstaunlich viele davon tun nur die Hälfte dessen, was sie sollen.
Die Ansicht springt, der Fokus bleibt
<a href="#main"> scrollt zuverlässig an die richtige Stelle. Was dabei
passiert — und was nicht — sieht man erst, wenn man danach weitertabbt: Der
Fokus steht immer noch im Kopfbereich, der nächste Tabstopp ist wieder ein
Menüpunkt. Die Ansicht ist gesprungen, die Tastatur nicht.
Der Grund ist, dass <main> von Haus aus nicht fokussierbar ist. Ein
Fragmentlink kann den Fokus nur auf ein Element setzen, das ihn annehmen kann.
Fehlt tabindex="-1" am Ziel, verschiebt der Browser lediglich den Ausschnitt.
Das Tückische: Kein automatisches Prüfwerkzeug meldet das — der Link ist ja vorhanden und sein Ziel existiert. Es fällt nur auf, wenn jemand tatsächlich mit der Tastatur weiterarbeitet.
Verwandte Fälle
Dasselbe Muster steckt hinter mehreren Befunden, die im Alltag getrennt gemeldet werden:
- Der Sprunglink ist dauerhaft versteckt und wird deshalb nie fokussierbar
- Nach einem Routenwechsel in einer Single-Page-Anwendung bleibt der Fokus stehen, und die neue Seite wird nicht angesagt
- Ein Dialog schließt, ohne den Fokus an die auslösende Schaltfläche zurückzugeben
Jedes Mal geht es um dieselbe Frage: Wo steht der Fokus nach dieser Aktion — und wer hat ihn dorthin gesetzt?
Mehr dazu im Seminar
Fokusreihenfolge, sichtbare Indikatoren unter klebenden Kopfzeilen, Tastaturmuster für Tabs, Menüs und Comboboxen sowie das Reparieren eines mehrstufigen Ablaufs behandelt das Modul Tastatur, Fokus und Navigation — inklusive Video und Kapitelübersicht.