Webseiten für Tastaturbedienung optimieren

Folgender Beitrag zeigt, worauf Sie beim Gestalten einer barrierefreien Webseite achten müssen und wie Sie deren Usability durch Optimierung für die Tastaturbedienung verbessern können.

Änderungen des Kontextes sind für Tastaturnutzer oft nicht zu bewältigen oder nicht leicht zu erfassen, vor allem wenn sie den Bildschirm aufgrund von Blindheit oder einer Sehbehinderung nicht vollständig wahrnehmen können. Etwa wenn ein Nutzer ein Feld für eine PLZ ausfüllt, und der Fokus nach fünf Zeichen automatisch in das Feld Ort springt, ohne dass ein Tastaturnutzer etwas davon mitbekommt. Deshalb hat die Thematik auch Eingang in die Web Content Accessibility Guidelines (WCAG) 2.0 gefunden, wo mehrere Anforderungen zur Vorhersehbarkeit formuliert sind.

Der zentrale Aspekt bei der Bedienung des Computers mit der Tastatur ist der Systemfokus. Die Herrschaft über den Fokus sollten Sie stets dem Nutzer überlassen. Mit anderen Worten: Wenn der Fokus vom Nutzer irgendwo auf einer Webseite mit der Tab-Taste bewegt wird, können Sie als Webentwickler nicht davon ausgehen, dass der Nutzer einen Link aktivieren oder ein Steuerelement bedienen möchte. Während das Drücken der Eingabe- oder Leertaste impliziert, dass wie bei einem Mausklick der Nutzer eine Änderung der Seiteninhalte, des Fensters oder der Anwendung erwarten kann, wird beim bloßen Fokussieren eines Elements eine solche signifikante und nicht steuerbare Änderung unter Umständen zu einer nicht bedienbaren Webseite führen.

Gleiches gilt bei der Auswahl in Formularen und Widgets, die vornehmlich durch Pfeiltasten vorgenommen werden. Signifikante Veränderungen können verschiedenartig sein. Zum einen geht es um den Austausch von Inhalten, die der Seite eine andere Bedeutung geben. Zum anderen geht es um diverse Umstände wie das automatische Abschicken eines Formulars, das Anzeigen eines neuen Fensters oder die Fokus-Manipulation. Entscheidend ist in den meisten Fällen, dass der Tastaturfokus dort bleibt, wo der Nutzer ihn erwartet.

Thema Fokus

Um Nutzererwartungen zu erfüllen, wird die Funktionalität für Mausnutzer und zwischenzeitlich auch Touchscreennutzer geprüft, aber Tastaturnutzer bleiben viel zu oft auf der Strecke. Die Folge ist, dass manche Webseiten für diese Nutzer nicht oder nicht vorhersehbar funktionieren. Für Tastaturnutzer ist der Fokus heilig. Normalerweise wird der Fokus von aktivem Element zu aktivem Element (meist Links oder Formular-Steuerelemente) mit der Tab-Taste bewegt. Da der Fokus ein Event auslöst, müssen Entwickler in ihren Skripts darauf achten, dass der Fokus alleine keine Änderung des Kontextes verursacht. Kontextänderungen sollten Mausklicks und dem Drücken von Eingabe- bzw. Leertasten vorbehalten sein.

Im Tab-Panel führt ein Klick per Maus auf einen Reiter dazu, dass der Reiter per JavaScript ausgetauscht wird. Ein Tastaturnutzer sollte die Registerseite fokussieren, eine Auswahl mit Pfeiltasten vornehmen und die Anzeige der dazugehörigen Registerseite mit der Leertaste auslösen können. Was nicht passieren darf, ist, dass der Nutzer den ersten Reiter fokussiert und nach Drücken der Tab-Taste der zweite Reiter fokussiert und die Registerseite automatisch ausgetauscht wird. 

Die richtige Customer Experience schaffen

Mit dieser Verhaltensweise würde stets immer nur die letzte Registerseite bedient werden können, wenn nur die Tastatur als Eingabemöglichkeit besteht. Die Reiter dürfen nur einmal mit der Tab-Taste angesteuert werden. Wenn der aktive Reiter fokussiert und die Tab-Taste erneut gedrückt wird, muss der Fokus auf das nächste fokussierbare Element unterhalb der Reiter geändert werden. Das bedeutet, die Auswahl der Reiter per Pfeiltasten muss von der Webentwicklung bereitgestellt werden.

Die Tastatursteuerung obliegt dem Entwickler, sobald komplexere UI-Komponenten wie Registernavigationen eingesetzt werden. Der Einsatz von JavaScript-Bibliotheken wie jQuery, Dojo oder MooTools erlaubt zwar eine barrierefreie Umsetzung, garantiert sie allerdings nicht. Gerade bei Widgets sollten Sie sich bei der genauen Tastenbelegung an gängige Empfehlungen wie in den "Authoring Practices" zu der WAI-ARIA-Spezifikation anlehnen.

Viele der Probleme bei der Tastaturbedienung sind deutlich trivialer. Vielleicht ist es einfach ein Missgeschick, aber der Fokus wird viel zu oft dafür genutzt, Aktionen auszulösen. Mit Schnipseln wie <a href="#" onfocus="link_aufrufen();">Menüpunkt 1 </a> werden manche Seiten komplett unbrauchbar. Hier gehört ein onclick- und kein onfocus-Event-Handler hin. Der onclick-Event-Handler verhält sich bei Links und Formular-Steuerelementen im Übrigen geräteunabhängig, d. h., er wird dann auch durch Eingabe- und Leertaste ausgelöst.

Auch der Verlust des Fokus kann die Bedienung mit der Tastatur stark beeinträchtigen. Manchmal ist es so, dass Webentwickler aus vermutlich ästhetischen Gründen den Fokus von fokussierten Elementen mit kleinen Code-Schnipseln wie onfocus="this.blur();" entfernen. Das ist eine echte Gemeinheit gegenüber Tastaturnutzern und führt dazu, dass ein Element nicht fokussiert und entsprechend an dem Inhalt nicht vorbeinavigiert werden kann. Auf der Webseite können Sie zum Anfang der Breadcrumb-Navigation navigieren, und dann ist Schluss; die Links im Inhalt können Sie per Tastatur nicht aufrufen.

IT-Sicherheitsgesetz für Unternehmen

Natürlich gibt es auch positive Beispiele der Fokus-Manipulation. Nach Aufruf von google.de blinkt bei aktiviertem JavaScript der Cursor bereits im Eingabefeld. Diese Technik sollten Sie jedoch mit äußerster Vorsicht einsetzen. Nur wenn davon auszugehen ist, dass praktisch alle Nutzer diese eine Funktion verwenden wollen, ist die Manipulation des Fokus berechtigt. Auf den meisten Webseiten - vor allem solchen mit dynamischen Inhalten - geht es allerdings darum, die Tastatursteuerung zusätzlich zu berücksichtigen und Fokus-Verluste zu vermeiden. Bei der Fehlerbehandlung in Formularen kann zudem das kontrollierte Setzen des Fokus in einem fehlerhaft ausgefüllten Eingabefeld die Nutzbarkeit des Formulars fördern.

Thema Bedienung

Änderungen des Kontextes betreffen nicht nur den Fokus, sondern auch die Bedienung von Steuerelementen. Es gibt etliche Beispiele im Web, die mit kleinem Aufwand für Tastaturnutzer und insbesondere Screenreadernutzer besser nutzbar gemacht werden können. Für einige dynamische Situationen sollte ein Hinweis auf die Dynamik ausreichend sein; in anderen hingegen ist es sinnvoller, eine Schaltfläche zum Abschicken des Formulars bereitzustellen. Natürlich können Sie die Tastatursteuerung alternativ auch mit JavaScript steuern.

Der klassische Fall einer Änderung des Kontextes ist ein Quick-Launcher: Ein Nutzer öffnet die Auswahlliste mit der Maus und wird durch Klick auf einen der Einträge sofort auf eine neue Seite weitergeleitet. Für Tastaturnutzer ist die Schrittfolge etwas anders: Es wird zunächst die Auswahlliste mit der Tab-Taste fokussiert, dann wird mit den Pfeiltasten durch die Einträge gewandert und schließlich mit Eingabetaste oder Leertaste eine Auswahl getroffen. 

Planungskomplexität gekonnt reduzieren

Beim Durchwandern der Optionen darf die Weiterleitung nicht ausgelöst werden. Solche Unannehmlichkeiten für Tastaturnutzer können Sie per JavaScript abfangen, indem Sie im ausführenden Skript zuerst prüfen, ob die Eingabe- oder Leertaste gedrückt worden ist.

Es sind im Übrigen nicht nur Eingabe- und Leertaste zu berücksichtigen. Browser stellen die Tastatursteuerung für HTML-Steuerelemente normalerweise bereit, aber mit JavaScript können Sie diese Funktionalität aushebeln. Bei einem Quick-Launcher muss beispielsweise mit den Pfeiltasten eine Auswahl getroffen werden können.

Änderungen des Kontextes sind oft eine Gratwanderung zwischen Usability und Accessibility. Es gibt viele Situationen, die für Tastaturnutzer im Allgemeinen gut funktionieren, allerdings nicht im Speziellen für blinde Nutzer. In den folgenden zwei Beispielen geht es um den Wechsel von einem Formular-Steuerelement zum nächsten. Am Bildschirm wird die Funktionsweise schnell deutlich, aber nicht in einem Screenreader. Im Beispiel in Abb. 5 wird der Fokus automatisch zum nächsten Eingabefeld gesetzt, wenn im ersten Feld drei Zeichen oder im zweiten Feld acht Zeichen eingegeben wurden. Die Minimalanforderung für die Barrierefreiheit in diesem Beispiel ist, dass das dynamische

Verhalten angekündigt wird.

Ähnlich gelagert sind kontextabhängige Auswahllisten: Bei Auswahl eines Eintrags in einer ersten Auswahlliste wird die Liste geschlossen und deaktiviert, die nächste Auswahlliste eingeblendet und der Fokus in die zweite Auswahlliste gelegt. Diese Vorgehensweise wird für die folgenden Auswahllisten wiederholt, bis die letzte mögliche Auswahl getroffen wurde. 

Beim Wechsel des Fokus von einer zur nächsten Auswahlliste sollte zwar die Beschriftung des nächsten Steuerelements vom Screenreader vorgelesen werden, aber das ist nicht zwingend gegeben; es kann also passieren, dass ein Screenreadernutzer nicht erfährt, dass der Fokus sich in einer neuen Auswahlliste befindet. Eine Ankündigung - wie in Abb. 6 berücksichtigt - erlaubt es vor allem blinden Nutzern, die Dynamik zu antizipieren. Eine zwischendurch falsch getroffene Auswahl kann übrigens in diesem Beispiel nur schwer rückgängig gemacht werden.

Anregungen für Usability-Optimierungen

Die Usability ist viel zu oft auf Maus- und zwischenzeitlich auch Touchscreennutzer abgestimmt. Wenn Sie Ihre Webseite auch auf Tastaturnutzer abstimmen wollen, heißt das jedoch nicht, dass Sie kein JavaScript einsetzen dürfen. Das Ziel der besseren Usability für Tastaturnutzer kann nicht sein, auf dynamische Effekte zu verzichten. Das Ziel muss vielmehr sein, die tastaturspezifischen Events mit der gleichen Intensität zu optimieren wie die mausabhängigen Ereignisse. Wo das Optimum für die Tastaturbedienung liegt, hängt wie immer von der konkreten Situation ab.