Tastaturbedienung im Webdesign: Tipps zur Barrierefreiheit

Bevor eine Webseite online geht, wird meist ausführlich geprüft, ob die Funktionalität den Erwartungen der Nutzer*innen entspricht. Das geschieht meist mit der Maus, dem Touchpad oder dem Touchscreen — und nur selten mit der Tastatur. Denn obwohl die Richtlinien für barrierefreie Webinhalte (WCAG) die Bedienung über die Tastatur als Erfolgskriterium führen, reden wir dabei zum Leid vieler Betroffener immer noch über ein Nischenthema. Nicht jeder Mensch ist in der Lage, die Webseite visuell wahrzunehmen und/oder sich mittels Maus oder Touchpad durch sie zu navigieren. Im schlimmsten Fall funktionieren Webseiten nicht oder nicht vorhersehbar für diese Nutzer*innen. Sie haben folglich keinen adäquaten Zugang zu den Informationen.

Dabei bringen Browser die Kernfunktionalität bereits mit und der Aufwand, eine Webseite für die Bedienung mit der Tastatur zu optimieren, ist meist überschaubar. Folgend werden wichtige Tipps zur Barrierefreiheit mit der Tastaturbedienung aufgeführt.

Aber ganz von vorne: Das Hauptwerkzeug für die Bedienung einer Webseite mittels Tastatur ist die Tabulator-Taste: ↹ beziehungsweise ⇥ auf Apple-Tastaturen. Mit ihr kann man linear von Element zu Element springen, in umgedrehter Reihenfolge drückt man dazu zeitgleich die Umschalttaste: ⇧. Bei jedem fokussierten Element sollte eine optische Änderung eintreten. Mit der Eingabetaste ⏎ (auch »Enter« oder »Return« genannt) kann man Links und andere Schaltflächen betätigen. Zusätzlich gibt es die Möglichkeit, individuelle Tastenkombinationen festzulegen.

Leider scheitern viele Webseiten bereits daran, dass die Elemente eine optische Änderung erfahren, wenn sie mit der Tastatur fokussiert werden. Eine Mitschuld tragen CSS-Resets, die von vielen Webdesigner*innen eingesetzt werden. Diese setzen das Erscheinungsbild komplett zurück — einschließlich dem Fokus-Zustand, den die Browser ohne Einwirkung normalerweise von sich aus kennzeichnen würden:

/* remember to define focus styles! */
*:focus {
outline: 0;
}

Dabei wird oft vergessen, CSS-Regeln für den Fokus-Zustand wieder zu setzen.

Nicht selten wird die Umrandung aber auch gewollt deaktiviert, wenn sie von Webdesigner*innen als unschön empfunden wird. Anwender*innen, die auf die Bedienung mittels Tastatur angewiesen sind, werden dabei vergessen oder ignoriert. Dabei gibt es auch elegante Lösungen für diesen Fall: Zum einen ist es möglich, den Fokus-Zustand individuell zu gestalten. Man könnte ihn mit einer neuen Farbe, einem neuen Hintergrund oder einer passenderen Umrandung kennzeichnen. Hierbei sollte eine barrierefreie Farbwahl beachtet werden. Zum anderen gibt es auch Skripte wie unfocus.js, die den Fokus-Zustand nur bei der Bedienung mit der Tastatur hervorheben.

Gerade bei dynamischen, interaktiven Elementen und eingebetteten Frames kann es passieren, dass man mit der Tastatur einfach nicht mehr weiterkommt. Die Bedienung verfängt sich, indem man nur noch durch einen Bereich der Webseite navigieren kann, aus dem man ohne Tastatur nicht mehr herauskommt. Das kann von Webdesigner*innen vermieden werden, indem sie in erster Linie ein besseres Fokus-Management definieren und gegebenenfalls auch Tastaturkürzel unterstützen. Bei Inhalten wie Slideshows oder großen Menüs, die sich innerhalb des Browserfensters ausklappen oder öffnen, bietet sich beispielsweise auch die Escape-Taste an. Diese wird auch oft von Anwender*innen genutzt, die nicht auf die Tastatur angewiesen sind.

Die Reihenfolge, in der man mit der Tabulator-Taste von Element zu Element springt, sollte logisch und für Anwender*innen nachvollziehbar sein. In der Praxis ist das manchmal nicht der Fall. Der Kern des Problems kann darin liegen, dass die Struktur der Seite insgesamt nicht logisch ist. Dabei ist das die oberste Regel für barrierefreies Webdesign. Je nach Beeinträchtigung und Hilfstechnologie werden die Inhalte der Webseite nicht visuell ausgegeben, weshalb eine logische Seitenstruktur und damit gegebenenfalls auch die logische Lesereihenfolge für die Barrierefreiheit unabdingbar ist.

Wenn man ein Element mit der Tastatur fokussiert, darf dabei keine Fokus- oder Kontextänderung auftreten. Diese Änderungen dürfen und sollen erst eintreten, wenn sie von den Anwender*innen mit der Eingabe- oder Leertaste aktiv ausgelöst werden. Deshalb müssen Elemente mit ein onfocus-JavaScript-Event konsequent gemieden werden, damit nicht allein beim »Durchtabben« der Elemente eine Aktion getriggert wird.

Ein Autofokus sollte ebenfalls mit Bedacht eingesetzt werden, weil für eine benutzerfreundliche Bedienung allein Anwender*innen die Kontrolle über den Fokus haben sollten. Ausnahmen gibt es aber immer: In Formularen wäre es wiederum äußerst benutzerfreundlich, wenn der Autofokus nach dem Absenden direkt auf einem Eingabefeld liegt, das keinen validen Inhalt hat.

Das »tabindex«-Attribut für Elemente ist ein Werkzeug zur Korrektur der Sprungreihenfolge. Nicht in jeder Seitenstruktur ist die lineare Reihenfolge die benutzerfreundlichste. Insbesondere bei mehr mehrspaltigen Layouts kann es sinnvoll sein, auf die Reihenfolge Einfluss zu nehmen. Mitunter ist es auch ratsam, ein Element von der Tastatursteuerung auszuschließen. Dazu muss der Tabindex auf -1 gestellt werden.

Über das »accesskey«-Attribut lassen sich individuelle Tastenbelegungen festlegen. Insbesondere für Webseiten mit Dutzenden bis Hunderten von Elementen, durch die sich die Anwender*innen nacheinander mit der Umschalttaste bewegen müssten, ist es sinnvoll, für wichtige Schaltflächen zusätzlich Accesskeys zu definieren. Damit können lange Umwege in der Tastaturbedienung gespart werden. Sogar mit Screenreadern können Accesskeys genutzt werden.

Leider gibt es mehrere Wer­muts­trop­fen: Zum einen gibt es keine einheitliche Hilfstaste, die zusammen mit dem Accesskey gedrückt muss. Das heißt, dass selbst unter einem Betriebssystem die Browser unterschiedliche Hilfstasten nutzen. Unter Windows reicht bei Chrome die Alt-Taste, bei Firefox muss hingegen die Alt- sowie die Umschalttaste gedrückt werden. Des Weiteren gibt es auch keine Standards für die Belegung der Accesskeys selbst. Das heißt, dass sie den Anwender*innen wenig nützen, solange man sie nicht obendrein kommuniziert. Diese Accesskeys gelten aber als gebräuchlich:

• 0: Startseite
• 1: Navigation
• 2: ggf. Inhaltsverzeichnis
• 3: Kontaktmöglichkeit
• 4: Sitemap
• 5: Suche

Auch Buchstaben können als Accesskey belegt werden. In dem Fall wird gerne das »h« für »Home« genutzt et cetera.

Webseiten sollten auf die Tastaturbedienung optimiert werden. Die Browser bringen die Bordmittel, der Rest muss von den Webdesigner*innen und Webentwickler*innen erledigt werden. Oft ist es aber mit wenigen Schritten getan.