Tastaturbedienung und Tabindex
Widersprüche in der Barrierefreiheit
Standardkonforme Webseiten brauchen für ihre Links eigentlich nicht die zusätzliche Hinterlegung von tabindex. Wenn diese Funktion zusammen mit anderen Techniken wie Skip-Links verwendet wird, dann kann das tabindex-Attribut die Funktionalität und Gebrauchstauglichkeit sogar beeinträchtigen.
Autor: df
Einer der Grundsätze bei der Erstellung von barrierefreien Websites ist, daß diese geräteunabhängig gestaltet sind. Die gängigste Interpretation von »Geräteunabhängig« bedeutet sicherzustellen, dass allen Benutzern die Bedienung per Tastatur ermöglicht wird – sowohl denen, die eine Tastatur benutzen müssen, als auch denen, die vielleicht lieber die Tastatur als die Maus als primäres Eingabewerkzeug benutzen. Darüber hinaus arbeiten viele assistive Werkzeuge für Menschen mit motorischen Behinderungen direkt mit der Tastatur oder durch die Emulation von Tastatur-Funktionalitäten.

In der Bemühung, ihre Seiten barrierefreier zu gestalten benutzen viele (wenn auch nicht alle) Entwickler sowohl den »Zum Inhalt springen«-Link als auch das tabindex-Attribut.
Was kann also passieren, wenn diese beiden Techniken kombiniert werden? Stellen Sie sich eine Seite vor, in welcher der Link »Navigation überspringen« einen tabindex von 1 hat. Direkt darauf folgt die globale Navigation der Website: Home, Über uns, Service, Kontakt mit entsprechendem tabindex von 2, 3, 4, und 5.
Ein Tastaturbenutzer geht per Tab zum Link »Navigation überspringen» (tabindex="1"
) und aktiviert den Link, um damit zum eigentlichen Inhalt zu gelangen. Er drückt dann erneut die Tab-Taste und wird nun zum Link mit dem nächsten tabindex gebracht (der Home-Link mit tabindex="2"
) — was ihn wieder zurück zur Navigationsleiste der Seite bringt. Wenn das tabindex-Attribut bei solchen Links eingesetzt wird, dann macht dies in vielen Fällen den Link »Zum Inhalt springen« effektiv unbrauchbar.
Oops!
Dieses Verhalten hängt von dem benutzen User Agent ab. Ein schneller Tests zeigt dass:
- Gecko-basierte Browser (Mozilla etc.) das oben erklärte Verhalten zeigen (sowohl Mac als auch PC).
- IE 5.1 (Mac) das oben umrissene Verhalten zeigt,
- IE 6 and 5.5 (PC) beide den nächsten tabindex im Inhaltsbereich nehmen,
- Opera 7.x es erlaubt, dem Link »Zum Inhalt springen« zu folgen. Benutzt man die Tab-Taste erneut, dann kommt man zurück zum Link »Zum Inhalt springen« und kann dann von dort aus weitermachen.
- Netscape 4 (klar, warum nicht...) sich wie die Gecko-Browser verhält.
Diese Testreihe wird noch weitergeführt und bei Bedarf ergänzt.
Die Ursache: Web Content Accessibility Guidelines
In diesem Fall befolgen die Entwickler einfach nur zwei Richtlinien, die in den Web Content Accessibility Guidelines (WCAG) aufgeführt sind.
Anmerkung:
Wir beziehen uns hier auf die deutsche Übersetzung von René Hartmann, die Richtlinien der BITV folgen aber auch hier dem Original und sind genauso zu interpretieren.
WCAG Checkpunkt 13.6 rät Entwicklern: »Gruppieren Sie verwandte Links, identifizieren Sie die Gruppe (für Benutzeragenten), und ermöglichen Sie das Überspringen der Gruppe, bis Benutzeragenten dies gestatten«
. Dies hat dazu geführt, dass auf vielen Websites Links wie »Navigation überspringen« oder »Zum Inhalt springen« gesetzt werden und dass diese üblicherweise die ersten Elemente sind, die man auf einer solchen Seite findet. Hierbei handelt es sich durchaus um ein nützliches Element.
WCAG Checkpunkt 9.4 sagt: »Definieren Sie eine logische Tab-Reihenfolge […] Spezifizieren Sie in HTML die Tab-Reihenfolge mit dem "tabindex"-Attribut oder sorgen Sie für ein logisches Seitendesign«
.
Das Problem tritt genau dann auf, wenn Autoren den tabindex in Fällen einsetzen, in denen es nicht wirklich notwendig ist. Wie meistens in der Entwicklungsarbeit würden einige einfache Tests zur Barrierefreiheit dieses Problem beinahe sofort identifizieren.
Wer ist verantwortlich?

Wie immer teilen wir alle die Verantwortung für die Barrierefreiheit. Zum jetzigen Zeitpunkt gibt es unter den Browserherstellern keinen Konsens dazu, wie dies zu implementieren ist und auch die User Agent Accessibility Guidelines (UAAG) geben keine Hinweise, wie man diese Funktionalität implementieren sollte.
Auch die Benutzer müssen eine passende Wahl treffen bei den Browsern, die sie benutzen, und sie könnten einen auswählen, der sich entsprechend korrekt verhält. In diesem Fall scheint es, als wäre ausnahmsweise mal der Internet Explorer dem gewünschten Verhalten am nächsten: die Aktivierung eines Links auf der gleichen Seite (wie ein »Zum Inhalt springen«-Link) bewegt den Fokus auf das nächste Ziel und geht von dort aus weiter statt zum nächsten Element mit tabindex-Attribut zurück zu kehren, wie dies Gecko-basierte Browser tun.
Bleiben nur noch die Webentwickler übrig. Die gute Nachricht ist, dass Checkpunkt 9.4 der WCAG sagt: »Spezifizieren Sie in HTML die Tab-Reihenfolge mit dem ‘tabindex’-Attribut oder sorgen Sie für ein logisches Seitendesign«
.
Jetzt, da viele Entwickler und Designer sich nach vorne bewegen und standardkonforme, tabellenfreie Layouts produzieren, entwickeln sie in den meisten Fällen Seiten, die ein logisches Seiten-Design und damit eine logische Tab-Reihenfolge haben. Im Allgemeinen brauchen Autoren mit dieser Art Layout keinen tabindex mehr, da diese Technik mehr Probleme hervorruft als sie lösen kann.
Zum Autor:
Derek Featherstone hat in den letzten 9 Jahren als Webentwickler, Berater und Trainer gearbeitet. Man findet ihn auch unter boxofchocolates.ca. Dieser Artikel ist eine Übersetzung von »Contradictions in Accessibility - Keyboard Usage and Tabindex «
Wir würden gerne Ihre Meinung wissen: Teilen Sie uns Ihre Erfahrungen mit und diskutieren Sie diesen Artikel mit anderen Experten.