Tastaturnavigation.

Tastaturnavigation heißt, dass eine Website ohne Maus, allein mit der Tastatur, von Anfang bis Ende benutzbar ist — eine der grundlegendsten A-Anforderungen der WCAG.

Auf die Frage, wo eine Barrierefreiheitsprüfung beginnen soll, lautet die Antwort fast immer gleich: Legen Sie die Maus weg. Die Tastaturtour ist die eine Methode, die kein Werkzeug braucht, zehn Minuten dauert und den Großteil der Fehler ans Licht bringt.

Der Grund: Tastaturzugang ist ein Indikator für vieles andere. Eine Komponente, die mit der Tastatur nicht funktioniert, ist fast immer auch semantisch falsch — ein Klick-Handler an einem div, ein mit div imitierter Button, ein an Mausereignisse gebundenes Menü. Die Tastaturtour fängt all diese Fehler zugleich.

Wer mit der Tastatur navigiert

Die verbreitete Annahme: Tastaturnavigation sei für eine kleine Minderheit. Die Wirklichkeit ist breiter.

1. Nutzer mit motorischen Beeinträchtigungen — Menschen, die mauspräzise Bewegungen nicht ausführen können oder Tremor haben.
2. Screenreader-Nutzer — sie navigieren fast vollständig per Tastatur; der Mauszeiger ist für sie bedeutungslos.
3. Nutzer von Schalterzugang und Blicksteuerung — diese Technologien emulieren Tastaturereignisse; Tastaturunterstützung ist auch ihr einziger Weg.
4. Vorübergehende Situationen — der gebrochene Arm, die verpackte Maus, das defekte Touchpad.
5. Poweruser — alle, die beim Ausfüllen eines Formulars die Maus nie berühren. Zahlenmäßig die größte Gruppe.

Die letzte Gruppe zeigt: Tastaturzugang ist ebenso ein Posten der Gebrauchstauglichkeit wie der Barrierefreiheit. Ein guter Tastaturfluss nützt allen direkt, die Formulare schnell ausfüllen.

Die Tastaturtour: die Zehn-Minuten-Methode

Die Methode ist einfach und braucht kein Werkzeug. Ziehen Sie die Maus vom Tisch, laden Sie die Seite neu und versuchen Sie, sie nur mit der Tastatur zu benutzen.

1. Tab — zum nächsten fokussierbaren Element. Shift+Tab zurück.
2. Enter — den Link öffnen, den Button drücken, das Formular absenden.
3. Leertaste — den Button drücken, die Checkbox umschalten, die Seite scrollen.
4. Pfeiltasten — innerhalb von Radiogruppen, Dropdowns und Tab-Gruppen bewegen.
5. Escape — eine offene Ebene, ein Menü oder einen Dialog schließen.

Während der Tour achtet man auf drei Dinge: Ist bei jedem Schritt sichtbar, WO der Fokus ist; ergibt die Reihenfolge Sinn; und bleiben Sie irgendwo hängen. Jedes entspricht einem eigenen Kriterium.

Vier verbreitete Fehler

Die in Tastaturtouren wiederkehrenden Fehler ähneln einander, und jeder hat eine bekannte Lösung.

Der Fokus ist unsichtbar. Der häufigste Fehler, und er kommt fast immer aus derselben Zeile: einer CSS-Regel, die den Fokusring entfernt. Die Regel wird meist geschrieben, weil er „hässlich aussieht“ — ohne zu bemerken, dass sie Tastaturnutzer vollständig von der Website abschneidet. Die richtige Lösung ist nicht, den Ring zu entfernen, sondern einen eigenen zu gestalten.

Die Reihenfolge ergibt keinen Sinn. Visuelles Layout und Fokusreihenfolge können auseinanderlaufen — besonders bei per CSS versetzten Elementen. Der Nutzer springt in die rechte Spalte, dann zurück nach links, dann wieder nach rechts. Quellreihenfolge und visuelle Reihenfolge zur Deckung zu bringen ist die einzige gesunde Lösung; die Reparatur mit positivem tabindex verschlimmert die Lage.

Die Fokusfalle. Öffnet sich eine Ebene oder ein Dialog, wird der Fokus darin gefangen und kommt weder mit Escape noch über einen Schließen-Button heraus. Dem Nutzer bleibt nur das Neuladen der Seite. 2.1.2 verbietet das direkt — und wohlgemerkt: Das ist ein Verstoß der Stufe A.

Fokus auf einem unsichtbaren Element. Ein auf dem Bildschirm verborgenes, aber im DOM verbliebenes Menü kann in der Tab-Reihenfolge fokussierbar bleiben. Der Nutzer drückt mehrmals Tab, sieht nichts und versteht nicht, wohin er geraten ist. Geschlossene Ebenen müssen auch aus der Fokusreihenfolge entfernt werden.

Eine per Tastatur nicht navigierbare Komponente ist fast immer auch semantisch falsch.

Das richtige Element löst es von Anfang an

Die meisten Tastaturfehler entstehen aus der Wahl des falschen HTML-Elements. Wird statt eines Links ein div verwendet, müssen Tastaturunterstützung, Fokussierbarkeit und Rollenansage von Hand nachgebaut werden — und werden meist unvollständig nachgebaut.

Die Regel ist klar: Was klickbar ist und irgendwohin FÜHRT, ist ein Link; was klickbar ist und etwas TUT, ist ein Button. Beide bekommen Tastaturunterstützung, Fokussierbarkeit und die richtige Rolle vom Browser geschenkt. Einem div all das hinzuzufügen ist möglich, aber unnötig und fehleranfällig.

Dieselbe Logik gilt für Formularelemente. Eine eigens gestaltete Checkbox, gebaut, indem die echte Checkbox versteckt und ein Visual darübergelegt wird, behält ihre Tastaturunterstützung; von null mit einem div gebaut, verliert sie sie. Der erste Ansatz ist immer vorzuziehen.

Der Sprunglink

Beginnt jede Seite mit demselben Navigationsmenü, muss ein Tastaturnutzer auf jeder Seite das ganze Menü durch-tabben. Bei einem Menü mit zwanzig Links heißt das zwanzig Tastendrücke bis zum Inhalt — auf jeder Seite.

Die Lösung ist, was 2.4.1 verlangt: Das erste fokussierbare Element der Seite soll ein Link sein, der direkt zum Hauptinhalt springt. Normalerweise unsichtbar, wird er beim Fokus sichtbar. Er muss beim ersten Tab erscheinen und mit Enter zum Hauptinhalt führen.

Ein kleines Detail wird oft übersehen: Der Sprunglink darf nicht nur scrollen — er muss auch den Fokus zum Ziel bewegen. Ein nur scrollender Link sieht aus, als funktionierte er, aber der nächste Tab bringt den Nutzer zurück an den Menüanfang. Das Zielelement fokussierbar zu machen löst es.

Tab-Reihenfolge und Quellreihenfolge

In welcher Reihenfolge der Tastaturfokus voranschreitet, bestimmt die Quellreihenfolge des HTML — nicht die visuelle Ordnung des CSS. Laufen die beiden auseinander, entsteht eine Navigation, die der Nutzer nicht deuten kann: Der Fokus springt nach rechts oben, fällt nach links unten, klettert wieder hinauf. Eine visuell ordentliche Seite kann auf der Tastatur völlig zerwürfelt sein.

Die häufigste Ursache der Abweichung sind moderne Layoutwerkzeuge. In Grid- und Flexbox-Layouts ist das visuelle Umordnen von Elementen eine Ein-Zeilen-Arbeit, und die Änderung berührt die Quellreihenfolge nie. Eine für Mobil gemachte Umordnung kann den Fokusfluss am Desktop brechen — und niemand bemerkt es, weil niemand auf Mobil tabbt.

Die richtige Lösung ist, die Korrektur im HTML zu machen, nicht im CSS: Die Quellreihenfolge soll der Reihenfolge entsprechen, in der gelesen werden soll. Das ist nicht immer möglich; wo nicht, muss wenigstens in den kritischen Abläufen — Formular, Bezahlung, Suche — die Quellreihenfolge stimmen.

Die Reihenfolge mit einem positiven Tab-Index zu erzwingen verschlimmert die Lage fast immer. Elemente mit positivem Index kommen vor ALLEN Elementen ohne; ein einziger positiver Index auf einer Seite schiebt dieses Element ganz nach vorn und zerwirft alles Übrige. Die einzigen brauchbaren Werte sind null (fokussierbar machen, Reihenfolge lassen) und minus eins (programmatisch fokussierbar machen, aus der Tab-Reihenfolge nehmen).

Eigene Komponenten: der Tastaturvertrag

Wenn eigene Komponenten — Tabs, Akkordeons, Dropdown-Menüs und dergleichen — geschrieben werden, bringen die Nutzer eine erwartete Tastenbelegung für diesen Komponententyp mit. Diese Erwartungen sind nicht willkürlich; sie stammen aus den Oberflächen der Betriebssysteme und sind im WAI-ARIA-Autorenleitfaden je Komponententyp definiert.

1. Tab-Gruppe — Tab betritt die Gruppe, Pfeiltasten wechseln zwischen den Tabs, Tab verlässt sie in den Inhalt. Jeder Tab ist KEIN eigener Tab-Halt.
2. Dropdown-Menü — Enter oder Pfeil-nach-unten öffnet, Pfeiltasten navigieren, Enter wählt, Escape schließt und gibt den Fokus an den Auslöser zurück.
3. Akkordeon — jede Überschrift ist ein Button; Enter oder Leertaste öffnet und schließt.
4. Modaler Dialog — beim Öffnen geht der Fokus hinein, solange offen kein Durchgriff nach hinten, Escape schließt und der Fokus kehrt zurück.
5. Radiogruppe — ein Tab-Halt für die Gruppe; die Auswahl wechselt mit den Pfeiltasten.

Die gemeinsame Logik dieser Verträge: Tab navigiert ZWISCHEN Komponenten, Pfeiltasten navigieren INNERHALB einer Komponente. Jeden Tab einer Tab-Gruppe zum eigenen Tab-Halt zu machen funktioniert technisch, bricht aber die Erwartung und ermüdet den Nutzer in einer Oberfläche mit zehn Tabs.

Statt diese Komponenten von null zu schreiben, ist es — wo immer möglich — sicherer, eingebaute Elemente zu verwenden, deren Tastaturverhalten bereits stimmt. Die Tastaturunterstützung eines eingebauten Elements liefert der Browser; sie ist getestet und mit Hilfstechnologien kompatibel.