Tastaturbedienung

Es ist aus den Grundlagen der Web-Barrierefreiheit bekannt, dass Bedienoberflächen auf mehrere Arten benutzbar sein müssen. Im Web-Kontext bedeutet das grundlegend: alles mit dem Zeigegerät (Maus oder Finger) Bedienbare muss auch per Tastatur bedienbar sein. Denn eine sinnvolle Nutzung per Tastatur oder anderen Hilfsmitteln, die Tastatureingaben erzeugen (also einem Tastaturinterface), ist gleichzeitig die Grundlage für viele Nutzungsformen und ein Zeichen dafür, wie und ob Menschen mit Behinderungen E-Commerce-Portale nutzen können. Aus diesem Grund haben auch die Aktion Mensch und Google in ihrer Studie zur Zugänglichkeit in Online-Shops die Tastaturbedienbarkeit in ihre Liste von „Indikationsprüfschritten“ aufgenommen und Tastaturbedienung sogar zu einem entscheidenden Filter für eine weitere Betrachtung der Shop-Barrierefreiheit werden lassen. Das Studien-Zusammenfassung kommt allerdings zu der ernüchternden Aussage:

Diese beiden Faktoren zeigen an, dass die Tastaturbedienung als eine wichtige Säule der Web-Zugänglichkeit einen besonderen Fokus und auch ein eigenes Modul erhalten sollte.

Fangen wir zunächst einmal mit einem verbreiteten Missverständnis an: Nicht jedesElement muss tastaturerreichbar sein, sondern ganz mehrheitlich nur interaktive (wie z. B. <button>s oder Links) und definitiv nur Elemente mit so genannten zugänglichen Namen, also programmatischen Beschriftungen. Auch wenn es aus guter Absicht zum Beispiel für die Nutzung per Screenreader geschieht, sind zum Beispiel tastaturerreichbare Absätze (also <p>-Elemente) in der absoluten Mehrheit der Fälle unsinnig. Screenreader zum Beispiel haben ihre eigene Art der Navigation (häufig „Lesemodus“ genannt), mit der sie Inhalte eines Dokuments der oder dem Nutzenden das Verstehen und Interagieren mit einem Web-Dokument erleichtern. Dieser Modus arbeitet dabei ausdrücklich nicht mit der Tabulator-Taste, die für grundsätzlich für Sprünge von einem anderen interaktiven Element zum anderen gedacht ist. Daraus ergibt sich wiederum, dass man mit dem HTML-Attribut tabindex="0" sehr vorsichtig umgehen sollte, denn dieses führt dazu, dass das Element, auf das es angewendet wird in die Gesamtheit aller tastaturerreichbaren Elemente aufgenommen wird – und jenem Element eine potentielle Interaktivität unterstellt wird. Und eine solche Unterstellung hat z. B. bei einer Überschrift keinen Sinn, denn rein akademisch gesehen haben diese die semantische Rolle heading, welche für das Strukturieren von Daten, aber nicht eine Interaktion irgendeiner Art zuständig ist.

Daraus kann man den folgenden Merksatz ableiten: „Rollen sind Versprechen“, denn sie kommunizieren an Hilfstechnologien und ihre Nutzenden, mit was für einer Art Element sie es zu tun haben. Ist es beispielsweise ein Datensatz in Form einer Aufzählung? Ist es ein Zitat einer Person, ein Fussbereich oder gar ein Element, mit dem man interagieren kann (wie z. B. ein Registerreiter)? Für interaktive Elemente lässt sich der Merksatz sogar erweitern: „Rollen sind Nutzungsversprechen“. Nutzende gehen zum Beispiel davon aus, dass man eine Schaltfläche mit unter anderem der Leer- und einen Link mit der Eingabetaste aktivieren kann. Somit gehört zur Tastaturbedienung auch das Thema „ist die Interaktion mit einem Interface per Tastatur auch logisch, erwartbar und sinnvoll“?

Und für genau dieses Unterthema der Tastaturbedienung, das die Bedienung erschweren könnte, halten die Web Content Accessibility Guidelines (WCAG) ein so genanntes Erfolgskriterium bereit: Der Test auf eine sinnvolle Fokusreihenfolge (2.4.3). Das betrifft einerseits Interfacekonzepte wie modale Dialoge, andererseits aber auch das dynamische Verändern und Nachladen von Inhalten, wie es zum Beispiel in einem Warenkorb vorkommen kann. Die Frage, die man sich als planender oder webentwickelnder Mensch in diesem Kontext stellen muss, sind: Ergibt die Tastaturbedienung für Nutzende Sinn, auch wenn man durch bestimmte Events HTML nach oder vor der Fokusposition einfügt? Ist der Tastaturfokus an einer logischen Stelle? Mutet man den Bedienenden unverhältnismäßig viele Tastaturanschläge zu? Ist sichergestellt, dass er nicht durch z. B. eine Element-Entfernung verloren geht? Ist gleichzeitig das eingreifende Fokusmanagement so wenig und passiv wie möglich (denn niemand mag unnötige Fremdkontrolle)?

Wie schon im entsprechenden Dialog-Modul erwähnt, bedeutet ein modaler Charakter eines (z. B.) Unterfensters, dass es bei Erscheinen das restliche Interface deaktiviert und die Aufmerksamkeit auf sich, seine Funktionen und Inhalte, zieht. Daraus lässt sich ableiten, dass auch der sprichwörtliche wie wörtliche Fokus in den modalen Dialog versetzt werden und verhindert werden muss, dass inaktive Elemente „außerhalb“ bzw. „hinter“ dem modalen Dialog nicht erreichbar sind. Sobald der Dialog dann schließt, darf der Fokus nicht etwa verloren gehen (weil beispielsweise das Dialog-Element dynamisch aus dem Dokument entfernt wird), sondern wandert zurück auf den ursprünglichen Auslöser (häufig eine Schaltfläche). All dieses Verhalten ist selbst zu implementieren, wenn man einen modalen Dialog mit allen nötigen Rollen, ARIA-Eigenschaften und Deaktivierung vom DOM-Teilbäumen selbst baut (zum Beispiel nach diesem Vorbild). Es ist aber häufig viel sinnvoller, das native <dialog>-Element zu nutzen, dass alle nötigen Rollen und Verhaltensweisen implementiert, wenn man es per .showModal() als modalen Dialog startet.

Wie schon im entsprechenden Modul angemerkt ist die sinnigste Datenstruktur für einen Warenkorb die Datentabelle. In ihr können gleichzeitig Produkteigenschaften und -optionen (Tabellenspalten) und Produkte oder Dienstleistungen im Warenkorb (jeweils eine Tabellenzeile) abgebildet werden, wobei die Menge der Zeilen der Menge der Elemente des Warenkorbs entspricht. Insgesamt kann man hier also von einer Art „Matrix“-Darstellung sprechen.

Wird nun, wie häufig in der Praxis anzutreffen, ein Eintrag aus dem Warenkorb ohne Neuladen der Seite entfernt, heißt dies auch, dass dynamisch eine Zeile einer Tabelle verschwindet. Nun ist auch davon auszugehen, dass der Tastaturfokus sich genau in der jeweiligen Zeile und zum Beispiel in der Tabellenspalte mit den Optionen befindet:

Die Gefahr, dass der Fokus „verloren geht“, weil das HTML-Konstrukt entfernt wird, das ihn beherbergt, ist dadurch real. Ein Best Practice in diesem Szenario besteht aus einem aktiven Fokusmanagement, das den Fokus im Moment des Löschens der Zeile programmatisch auf die Tabelle insgesamt setzt. Nun sind Tabellen in ihrer ursprünglichen Form keine interaktiven Elemente und dürfen nicht in der Gesamtheit der tastaturbedienbaren Elemente (dem Tabindex) auftauchen. Wir lösen dies durch das Attribut tabindex="-1", dass ein programmatisches Versetzen des Fokus' auf dieses Element erlaubt, aber nicht in der Tastaturreihenfolge auftaucht und deswegen versehentlich mit der Tabulatortaste angesteuert werden kann.

In der letzten Sektion wurde erwähnt, dass Elemente, die im Tastaturfokus sein können, zugängliche Namen benötigen. Hier stellt sich allerdings die Frage: „Wie stattet man eine Datentabelle mit einer Beschriftung aus?“. Die passende Antwort lautet: Mit einem <caption>-Element. Dieses kann sowohl visuell sichtbar wie versteckt existieren und sollte, ähnlich einer ARIA-Live-Region, am besten eine Meta-Info, wie z. B. die Gesamtsumme im Warenkorb, bekommen:

Auf ecbf.shop findet sich eine Warenkorb-Implementierung, die einerseits in Form eines modalen Dialogs gebaut ist, also die drei Aspekte des „blockierenden Unterfensters“ verfolgt:

Gebaut ist das Muster mit dem <dialog>-Element, da dieses den absoluten Großteil des erwarteten Verhaltens dem Browser überlässt.

Im Warenkorb selbst befindet sich nun die dynamische Datentabelle. Das oben genannte Fokusmanagement ist neben den weiteren Aspekten eines zugänglichen Warenkorbs implementiert.

Nachdem wir uns jetzt darum gekümmert haben, dass nur alles Interaktiv-Benannte tastaturbedienbar ist und diese Bedienungsart insgesamt sinnvoll implementiert ist, kümmern wir uns nun um eine gute Nutzbarkeit bei der Tastaturnavigation.

Sollte es in Ihrem Projekt viele Fokushaltepunkte geben (was zum Beispiel bedeuten könnte, dass es in Ihrem Shop viele Produktkategorien gibt), ist eine gute Möglichkeit für Tastatur- und Screenreadernutzende so genannte Sprunglinks anzubieten. Ikea.de implementiert diese internen Links zum Hauptbereich beispielsweise in Ihrer Auswahl der Räume:

Sprung- oder Skiplinks, wie man sie zum Beispiel als Mechanismus zum Überspringen von Bereichen wie dem Seitenkopf kennt, funktionieren als interne Links zu anderen Stellen des Dokuments (z. B. dem Hauptinhaltsbereich). Dazu sind sie meist visuell unsichtbar, aber dann wahrnehmbar, sobald sie Fokus haben und logischerweise vor dem zu überspringenden Bereich platziert. Aus dem Basics-Modul wissen wir, dass es einen entscheidenden Unterschied zwischen „versteckt“ und „visuell nicht wahrnehmbar“ gibt, und dieser ist der entscheidende Aspekt im Fall von Skiplinks. Sie müssen tastaturerreichbar sein (denn sie sollen sie ja die Tastaturbedienung verbessern) – insofern ist ein „radikales Verstecken“ mit z. B. display: none keine Option. Vielmehr kommt für den nicht fokussierten Sprunglink wieder unsere erwähnte Hilfs-CSS-Klasse, also beispielsweise sr-onlyoder visually-hidden zum Zug, und deren visuell verbergende Anweisungen wie position, width, height usw. wir im Fokuszustand (also :focus im CSS) negieren, um den Link unter diesen Umständen auch visuell sichtbar zu machen.

Eine andere Möglichkeit, viele Fokusstationen überspringbar zu machen, ist das ebenfalls aus dem Basismodul bekannte sogenannte Ausklappmuster. Da der „auszuklappende“ Container mit radikalen Methoden wie display: none oder dem hidden-HTML-Attribut versteckt sind, sind auch in ihm befindliche interaktive Elemente nicht im Tabindex – und müssen entsprechend nicht übersprungen werden. Ein Beispiel für das Prinzip ist hier ein Ausklappbereich im Hauptmenü – ist beispielsweise die Sektion „Tee“ gar nicht ausgeklappt, so müssen seine Unterpunkte auch gar nicht überspringen werden und das Herunterdrücken der Tabulatortaste führt zum nächsten für die Nutzenden vielleicht interessanteren Navigationsbereich.

Ein ebenso wichtiger Teil der Tastaturbedienung ist es außerdem, den oder die Nutzende auch darüber aufzuklären, welches Element genau im Moment den Tastaturfokus hat. Ob eine Fokushervorhebung vorliegt (oder nicht) entscheidet ganz wesentlich, ob eine Oberfläche nutzbar ist. Denn was nützt einem User, dass alle Funktionen einer Site tastaturbedienbar sind, wenn er oder sie aber keine Information darüber hat, welches Element gerade aktiviert ist?

Die Lösung ist im im Prinzip simpel: CSS bietet mit der Pseudoklasse :focus einen Weg an, Elemente im Fokus gesondert zu gestalten. In Realität werden Fokusstile, auch nativ vom Browser angebotene, aber mit Anweisungen wie *:focus { outline: 0;} abgeschaltet, weil die Fokushervorhebungen häufig auch für einem kurzen Moment nach einem Klick auf ein Element erscheinen und eventuell von (grafisch) Verantwortlichen als unschön wahrgenommen werden. Unterdrückt man somit die Fokusstile, um diesen Effekt zu vermeiden, schüttet man allerdings das Kind mit dem Bade aus und macht sein Interface für Tastaturbedienende annähernd unbedienbar.

Abhilfe soll hier eine weitere, vergleichsweise neue CSS-Pseudoklasse schaffen: :focus-visible wird erst dann aktiv, wenn ein Fokuszustand durch beispielsweise die Tastatur erzeugt wurde, lässt sich aber ansonsten verwenden wie die bekannte :focus-Eigenschaft.

Wenn es um die visuelle Deutlichkeit und Gestaltung der Fokushervorhebungen geht, sind hier natürlich auch die WCAG-Mindestkontrastvorgaben zu beachten – und das unabhängig davon, ob eine Hervorhebung auf einem dunklen oder hellen Hintergrund steht. Auch wenn das genaue Design der Fokusindikation ganz wesentlich von der Gesamtgestaltung des Webauftritts und der Marke zu tun haben wird – bietet sich doch in einem Großteil der Fälle das Prinzip der „Doppelumrandung“ an. Wie genau man einen Fokusindikator umsetzt, der sowohl in hellen wie auch in dunklen Kontexten gut wahrnehmbar ist, erklärt das Design-System-Team der britischen Regierung hier.