Was ohne Maus auf deiner Seite schiefgeht

Stell dir vor, dein rechtes Handgelenk liegt sechs Wochen im Gips. Die Maus fällt damit aus, und du willst nur die Telefonnummer einer Werkstatt heraussuchen. Du drückst Tab, und dann achtundzwanzig weitere Male, bis das Hauptmenü hinter dir liegt und du beim ersten Satz des Textes ankommst. Du gehst auf Kontakt, die nächste Seite lädt, und das Zählen beginnt von vorn.

Wir haben 14.984 deutsche Firmenwebsites automatisiert geprüft. Auf 98,0 Prozent davon fehlt der Sprunglink. Wer die Seite per Tastatur bedient, arbeitet sich deshalb auf jeder Unterseite erneut durch das gesamte Menü. Diese Zahl beschreibt keine Handvoll vernachlässigter Bastelseiten, sie beschreibt den Normalzustand. Wie so ein Sprunglink aufgebaut ist, steht in einem eigenen Artikel. Hier geht es um alles, was danach kommt, also um die Reihenfolge, in der der Fokus durch deine Seite wandert, und um die Stellen, an denen er hängen bleibt.

Wer ohne Maus bedient, und warum

Das erste Bild im Kopf ist meistens ein blinder Mensch mit Screenreader. Das stimmt, deckt aber nur einen kleinen Teil ab. Die Tastatur ist für sehr unterschiedliche Leute der Hauptweg durch eine Website.

Wer einen Tremor hat, bekommt den Mauszeiger nicht ruhig auf ein dreißig Pixel breites Ziel.
Wer Arthrose in den Fingern hat, dem tut das Halten und Ziehen der Maus schlicht weh.
Wer seinen Rechner per Sprache steuert, löst damit im Hintergrund ebenfalls Tastaturbefehle aus.
Wer sich den Arm bricht, gehört für ein paar Wochen dazu, und das trifft jeden irgendwann.

Dazu kommt eine Gruppe, die in keiner Statistik zur Barrierefreiheit auftaucht: geübte Büroleute, die Formulare grundsätzlich mit Tab ausfüllen, weil das schneller geht. Springt dein Bestellformular nach der Postleitzahl in die Fußzeile, verlierst du diese Leute genauso wie alle anderen. Der Unterschied ist nur, dass sie sich nicht beschweren, sondern das Fenster schließen.

Woher die Tabulatorreihenfolge kommt

Der Fokus folgt nicht dem, was du siehst. Er folgt der Reihenfolge, in der die Elemente im Quelltext stehen. Das erklärt die meisten Überraschungen. Steht deine Seitenleiste im HTML vor dem Artikel und wird per CSS nach rechts geschoben, läuft der Fokus trotzdem zuerst durch sie. Ein order im Flexbox-Layout oder eine umsortierte Grid-Zeile verschiebt das Bild, nicht den Weg der Tastatur.

Von Haus aus fokussierbar sind im Wesentlichen die Elemente, die für Interaktion gebaut wurden: a mit href, button, input, select, textarea und summary. Dazu kommen Sonderfälle wie iframe oder ein Video mit sichtbaren Bedienelementen. Alles andere überspringt der Browser, und genau daraus entsteht die erste der drei häufigen Fallen.

Falle 1: ein div, das aussieht wie eine Schaltfläche

Sieht ein Element wie ein Knopf aus, verhält sich aber nicht so, merkt das nur die Tastatur. In der Praxis sieht der Fehler so aus:

<div class="btn btn-primary" onclick="oeffneFormular()">
  Termin vereinbaren
</div>

Und so dieselbe Schaltfläche richtig:

<button type="button" class="btn btn-primary" onclick="oeffneFormular()">
  Termin vereinbaren
</button>

Das ist die ganze Änderung. Der button bringt vier Dinge mit, die du sonst von Hand nachbauen müsstest. Er ist per Tab erreichbar, reagiert auf Enter und auf die Leertaste, ein Screenreader kündigt ihn als Schaltfläche an, statt nur den Text vorzulesen, und ein disabled wird tatsächlich respektiert. Hängt dein CSS an div.btn, ergänze die Regel um button.btn und setze border: 0 sowie font: inherit, dann sieht der Knopf hinterher genauso aus wie vorher.

Manchmal hörst du, das lasse sich auch mit tabindex="0" und role="button" heilen. Damit ist die Hälfte repariert, denn die Tastaturereignisse fehlen weiterhin. Du schreibst also einen Handler für Enter und einen für die Leertaste samt Unterdrückung des Seitensprungs. Am Ende stehen vier Zeilen JavaScript dort, wo ein ausgetauschtes Tag gereicht hätte.

Falle 2: tabindex mit positiven Zahlen

Ein tabindex="3" wirkt harmlos und ist der zuverlässigste Weg, eine Seite unbedienbar zu machen. Jedes Element mit einem positiven Wert wird vorgezogen, und zwar vor sämtliche normalen Elemente der Seite. Zwei Leute, die unabhängig voneinander durchnummerieren, erzeugen eine Reihenfolge, die niemand mehr versteht. Brauchbar sind genau zwei Werte. Die 0 holt ein Element in die normale Reihenfolge, die -1 macht es per Skript fokussierbar, ohne es in den Tab-Weg zu legen. Alles darüber gehört gelöscht, und die Reihenfolge sortierst du stattdessen im HTML.

Falle 3: Menüs, die nur auf Mausberührung reagieren

Ein Untermenü, das nur per :hover aufklappt, endet für die Tastatur auf eine von zwei Arten, und beide sind schlecht. Liegt es auf display: none oder visibility: hidden, nimmt der Browser die Links darin komplett aus dem Tab-Weg, und ein ganzer Ast deiner Navigation bleibt per Tastatur unerreichbar. Versteckst du es dagegen nur mit opacity: 0 oder weit außerhalb des Bildschirms, bleiben die Links fokussierbar, und der Fokus läuft durch Ziele, die niemand sieht. Im CSS reicht als Sofortmaßnahme eine zweite Bedingung:

/* vorher */
.nav-eintrag .untermenue { display: none; }
.nav-eintrag:hover .untermenue { display: block; }

/* nachher */
.nav-eintrag .untermenue { display: none; }
.nav-eintrag:hover .untermenue,
.nav-eintrag:focus-within .untermenue { display: block; }

:focus-within greift, sobald der Fokus irgendwo innerhalb des Menüpunktes landet, also schon beim obersten Link. Das Untermenü klappt auf, seine Links rücken in den Tab-Weg, und es bleibt offen, solange der Fokus darin steht. Sauberer wäre ein button mit aria-expanded, der das Untermenü bewusst öffnet und schließt, aber die zwei Zeilen oben kosten zwei Minuten und beseitigen den akuten Schaden.

Die Tastaturfalle in Dialogen

Der zweite Klassiker steckt in Overlays wie Cookie-Hinweis, Suchfeld oder Bildergalerie. Zwei Dinge gehen dabei regelmäßig kaputt. Entweder wandert der Fokus nach ein paar Mal Tab aus dem Dialog heraus in die abgedunkelte Seite dahinter, und du tabst blind durch unsichtbare Links. Oder er kommt gar nicht erst hinein, weil er beim Öffnen auf dem alten Element stehen bleibt und der Dialog für die Tastatur nicht stattfindet.

Drei Handgriffe lösen das. Setze den Fokus beim Öffnen auf das erste Bedienelement im Dialog. Halte ihn drin, indem du entweder ein natives dialog-Element mit showModal() nutzt oder dem Rest der Seite inert gibst. Und gib den Fokus beim Schließen an das Element zurück, das den Dialog geöffnet hat, sonst steht die Tastatur wieder am Seitenanfang. Escape sollte den Dialog schließen, beim nativen dialog erledigt der Browser auch das von allein.

Der Selbsttest, zwei Minuten, keine Zusatzsoftware

Öffne deine Startseite und klicke einmal in die Adresszeile des Browsers, damit der Fokus definiert oben startet.
Drücke Tab und bleib langsam. Frage dich nach jedem Druck: Siehst du auf einen Blick, wo du gerade bist? Leuchtet nirgends ein Rahmen auf, wurde der Fokusring per CSS entfernt, und das ist der erste Eintrag auf deiner Reparaturliste.
Zähle mit, wie oft du drücken musst, bis du im Seiteninhalt landest. Alles über zehn spürt man deutlich, und genau hier hilft der Sprunglink.
Tabbe bis zu einem Menüpunkt mit Untermenü. Klappt es sichtbar auf, oder verschwindet dein Fokus ins Nichts?
Öffne ein Overlay, etwa die Suche oder den Cookie-Hinweis, ausschließlich mit Enter. Drücke danach fünf Mal Tab und schau, ob du im Dialog bleibst. Drücke Escape und prüfe, ob er sich schließt.
Geh im Kontaktformular per Tab von oben nach unten durch und beobachte, ob die Sprungfolge der sichtbaren Anordnung entspricht. Schick das Formular am Ende mit Enter ab, ohne die Maus anzufassen.

Noch ein Hinweis für Safari auf dem Mac: Dort springt Tab in der Voreinstellung nur zu Formularfeldern und übergeht Links. In den Einstellungen unter Erweitert aktivierst du "Tab-Taste hebt jedes Objekt auf einer Webseite hervor", danach verhält es sich wie die anderen Browser. Ohne diese Einstellung kommst du mit Wahltaste und Tab weiter.

Was du bei diesem Rundgang findest, steckt meistens in einem einzigen Template, sodass eine Korrektur an einer Stelle die ganze Seite mitrepariert. Eine Sache noch, in aller Deutlichkeit. Unser Widget kann Schrift vergrößern, Kontraste anheben und Texte vorlesen, aber aus einem div macht es keinen Knopf. Diese eine Zeile im HTML musst du selbst ändern, und sie ist der billigste Handgriff auf der ganzen Liste.