Eine Seite mit der Tastatur bedienen

Zieh die Maus ab und drück die Tab-Taste: Jeder Link, jeder Button und jedes Feld sollte der Reihe nach aufleuchten, in der Reihenfolge, in der du die Seite liest.

Wer die Tastatur benutzt

Viele Menschen fassen nie eine Maus an. Manche können sie nicht ruhig halten, manche benutzen einen Schalter, einen Mundstab oder eine Spracherkennung, die Tastendrücke sendet, und auch Screenreader-Nutzer bewegen sich meist mit der Tastatur. Das WCAG-2.2-Erfolgskriterium 2.1.1 Tastatur auf Stufe A sagt, dass alles auf der Seite per Tastatur funktionieren muss. Kriterium 2.1.2 Keine Tastaturfalle ergänzt: Wenn der Fokus in einen Teil der Seite hineingelangen kann, muss er auch mit der Tastatur wieder herauskommen.

Elemente verwenden, die schon funktionieren

Links mit href, button, input, select und textarea sind von Haus aus fokussierbar und reagieren auf die richtigen Tasten. Ein div mit Klick-Handler ist das nicht: Man erreicht es nicht mit Tab, Enter bewirkt nichts, und ein Screenreader sagt es nicht als Button an. Der Rat von MDN ist klar: tabindex nicht benutzen, um ein div wie einen Button wirken zu lassen, sondern das Element button nehmen, das seine Rolle und sein Tastaturverhalten eingebaut mitbringt.

Fokusreihenfolge und tabindex

Die Tab-Reihenfolge folgt der Reihenfolge der Elemente im HTML-Quelltext. Kriterium 2.4.3 Fokus-Reihenfolge verlangt, dass diese Reihenfolge Bedeutung und Bedienung der Seite erhält. Die einfachste Lösung für eine seltsame Reihenfolge ist also, das HTML umzuordnen. MDN nennt drei Arten von tabindex-Werten. Null nimmt ein Element in die normale Reihenfolge auf. Ein negativer Wert, meist -1, nimmt es aus der Tab-Reihenfolge, lässt aber zu, dass ein Skript focus() darauf aufruft, nützlich für einen Dialog oder eine Fehlermeldung. Ein positiver Wert zwingt das Element vor alles andere, und MDN empfiehlt, nur 0 und -1 zu verwenden, weil positive Werte die Reihenfolge schwer nachvollziehbar machen.

Sehen, wo man ist

Tastaturnutzer müssen sehen, welches Element den Fokus hat. Kriterium 2.4.7 Fokus sichtbar auf Stufe AA verlangt einen sichtbaren Fokusindikator. Eine Stylesheet-Regel wie outline: none ohne Ersatz ist also ein Verstoß. Die WCAG 2.2 haben zwei verwandte Kriterien ergänzt. 2.4.11 Fokus nicht verdeckt (Minimum) auf Stufe AA sagt, dass das fokussierte Element nicht vollständig hinter etwas verborgen sein darf, das der Autor hinzugefügt hat, etwa einer klebenden Fußleiste oder einem Cookie-Banner. 2.5.8 Zielgröße (Minimum), ebenfalls AA, verlangt, dass Dinge, die man anklickt oder antippt, mindestens 24 mal 24 CSS-Pixel groß sind oder genug Abstand drumherum haben.

Ein weiteres Muster hilft enorm: der Skip-Link (Sprunglink). Auf einer Website mit langem Menü müssen Tastaturnutzer auf jeder Seite mit Tab durch jeden Menüpunkt. Ein Link ganz am Anfang der Seite, der auf den Hauptinhalt zeigt, lässt sie mit einem Tastendruck darüber springen. Er kann unsichtbar bleiben, bis er den Fokus bekommt.

Der Test dauert zwei Minuten. Klick in die Adressleiste und drück dann immer wieder Tab, durch die ganze Seite. Prüf, dass jedes Bedienelement erreichbar ist, dass die Reihenfolge der Lesereihenfolge entspricht, dass du immer siehst, wo der Fokus ist, und dass Enter und Leertaste dasselbe tun wie ein Mausklick. Drück dann Umschalt+Tab, um zurückzukommen. Jedes Bedienelement, das du nicht erreichst, und jede Stelle, an der der Fokus verschwindet, ist ein Fehler.