BITV Reloaded – Anforderung 9

Bedingung 9.5: Accesskeys (Prio. 2)

Es sind Tastaturkurzbefehle für Hyperlinks, die für das Verständnis des Angebots von entscheidender Bedeutung sind (einschließlich solcher in clientseitigen Imagemaps), Formularkontrollelemente und Gruppen von Formularkontrollelementen bereitzustellen.«

Was heißt das?

Die hier geforderten Tatstaturkurzbefehle werden in HTML mit dem accesskey-Attribut realisiert. Sie funktionieren wie die Taststur-Shortcuts zu den Menübefehlen in den unterschiedlichen Betriebssystemen: Alt + D öffnet unter Windows üblicherweise das Menü ›Datei‹, Alt + B steht für Bearbeiten und so weiter.

Soweit die Theorie: leider sind so gut wie alle Zeichen in den gängigen Browsern schon mit irgendwelchen Menübefehlen belegt, so dass fast nur noch die Ziffern des 10er-Blocks für die Inhalte und Funktionen einer Webseite übrig bleiben. Selbst die Zahlen werden von manchen assistiven Tools für Sonderfunktionen verwendet, so wie Alt + 1 vom IBM Home Page Reader für dessen Überschriftenfunktion.

Bei komplexen Formularen mit vielen Kontrollelementen ist es unmöglich, für alle Elemente einen passenden Accesskey zu finden, der nicht in irgendeiner Anwendung mit anderen Funktionen belegt ist. Daher bleibt nur die Empfehlung, sich maximal auf die zehn zur Verfügung stehenden Zahlen zu beschränken und diese möglichst sinnvoll zu verteilen. Wie dies geschieht, ist dem Seitenbauer selbst überlassen, da es keinen einheitlichen Standard gibt. Sie sollten die Verwendung der Accesskeys auf jeden Fall z. B. auf einer Hilfe-Seite dokumentieren.

Das Fehlen von Regeln wirft jedoch weitere Probleme auf, die die Sinnhaftigkeit von accesskey weiter in Frage stellen. In Ermangelung eines de-fakto-Standards müssen Anwender die Tastaturbelegungen auf jeder Website neu erlernen – ein nicht zu unterschätzender Aufwand, der vom Anbieter gegen den zu erwartenden Nutzen abzuwägen ist, bevor man diese Attribute einsetzt. In Angeboten, die eher Anwendungscharakter haben (wie einem Online-Banking-Angebot oder einer Intranet-Anwendung) mag die Entscheidung für Accesskeys noch zu rechtfertigen sein, in reinen Content-Angeboten, wo der Nutzer nur mal gelegentlich ›vorbeischaut‹, ist dies eher nicht der Fall.

Screenreader geben die Informationen über vorhandene Accesskeys und deren Funktion erst dann aus, wenn das Element bereits fokussiert ist – dann braucht man den Accesskey aber nicht mehr, um das Element zu bedienen. Für den Anwender setzt der Nutzen erst bei wiederholten Besuchen ein, vorausgesetzt dieser ist willens und in der Lage, sich die Belegung zu merken.

Was meint die BIENE?

Im BIENE-Prüfverfahren wird dieser Punkt seit dem Jahr 2006 nur noch abgeschwächt geprüft:

Accesskeys/ Shortcuts sollen nur dort eingesetzt werden, wo es für die Anwendung sinnvoll ist. Ihr Einsatz ist konsistent und transparent zu realisieren.

Wie können Sie das testen?

Generell geben die heutigen grafischen Browser, aber auch viele Hilfsmittel einen hinterlegten Accesskey nicht sicht- oder hörbar aus, daher hilft hier nur ein kleiner Kniff, um den Blick in den Quelltext zu vermeiden. In den meisten grafischen Browsern lässt sich ein Benutzer-eigenes Style Sheet definieren, das eventuell vorhandene Accesskeys in die Dokumente schreibt. Fügen Sie die Zeile:

*[accesskey]:after {content: "[" attr(accesskey) "]";}

in Ihr Benutzer-eigenes Style Sheet ein und schon werden Ihnen die Accesskeys angezeigt. Dieser verwendete CSS-Trick nennt sich »Generated Content« und kann zu vielen verschiedenen Dingen benutzt werden, die das Surfen oder Testen erleichtern.

Einfacher geht es wie üblich mit den Webentwickler-Werkzeugen für Firefox und andere Browser. In der Web Developer Toolbar finden Sie im Menü ›Information‹ den Befehl ›Display Access Keys‹, der eventuell vorhandene Taststurkürzel neben den Elementen darstellt, denen sie zugewiesen sind.