Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Das role-Attribut: Worauf es ankommt

Einstieg in ARIA 1.0 – Teil I

Das role-Attribut: Worauf es ankommt

Für Webworker bedeutet es immer eine Herausforderung, dynamische Anwendungen mit Barrierefreiheit in Einklang zu bringen. ARIA 1.0 (Accessible Rich Internet Applications) will diese Lücke schließen. Mit dem role-Attribut bietet ARIA dazu ein mächtiges Werkzeug. Allerdings muss dieses auch richtig eingesetzt werden, damit Tastatur- und Screenreader-Nutzer etwas davon haben.

Früher war nicht alles besser. Im barrierefreien Webdesign postulierten die 1999 veröffentlichten Web Content Accessibility Guidelines (WCAG) 1.0 noch, dass Webseiten ohne aktiviertes JavaScript funktionieren müssen. Obwohl diese Haltung weiterhin als Best-Practice gilt, wird es seit Veröffentlichung der WCAG 2.0 aus dem Jahr 2008 langsam, aber sicher möglich, JavaScript-Widgets mit WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) barrierefrei zu gestalten.

Das role-Attribut

Das Problem der Barrierefreiheit ist nicht JavaScript. Das Problem dynamischer Anwendungen bestand vielmehr in der fehlenden Semantik und der fehlenden Bedienbarkeit mit der Tastatur. Während die Tastaturbedienung als alter Schlendrian der Webentwicklung bezeichnet werden kann, stellte die Semantik durchaus eine Herausforderung dar. Wie sollen beispielsweise Tab-Panels oder Slider mit den HTML-Elementen in einem Screenreader erkannt werden? Die Antwort liefert die WAI-ARIA-Spezifikation: Das role-Attribut, das Anfang diesen Jahres als W3C-Empfehlung veröffentlicht wurde, sowie zahlreiche neue Attribute, die Zustände und Eigenschaften dynamischer Elemente beschreiben.

Hinweis: Bei Webstandards-Enthusiasten dürften sich bei nachfolgendem Code die Fußnägel aufrollen, bei manchen anderen leider nicht.

Das role-Attribut ist ziemlich mächtig. Mit diesem Attribut können Webentwickler die native Rolle eines Elements überschreiben. Aus einem span kann zum Beispiel eine Überschrift werden.

  1. <span role="heading">Überschriftentext</span>

Browser geben nun der Accessibility-Schnittstelle des jeweiligen Betriebssystems an, dass der Überschriftentext tatsächlich eine Überschrift ist. Entsprechend identifizieren die meisten Screenreader den Text als Überschriftentext. Besser ist selbstverständlich die Verwendung der vorgesehenen HTML-Elemente:

  1. <h1>Überschriftentext</h1>

Wann immer möglich, sollten HTML-Elemente nach ihrer Bedeutung eingesetzt werden.

Desweiteren sollte die Rolle semantisch bedeutsamer Elemente nicht mit role entfernt werden. Wenn eine Überschrift anklickbar sein soll, sollte nicht das Überschriftenelement mit einem role="link" versehen werden (dann handelt es sich nämlich nicht mehr um eine Überschrift), sondern ein enthaltenes Element soll die Interaktion ermöglichen, damit das Element sowohl als Überschrift als auch als Link identifiziert werden kann:

  1. <h1><span role="link" tabindex="0" onclick="foo();">Linktext</span></h1>

beziehungsweise als Best-Practice natürlich

  1. <h1><a href="#" onclick="foo();">Linktext</a></h1>

Hinweis: Links und Steuerelemente müssen tastaturbedienbar sein. Ein span-Element ist von sich aus nicht mit der Tastatur bedienbar, und die Tastaturbedienbarkeit muss vom Webentwickler zusätzlich eingebaut werden. Das role-Attribut ändert die Semantik, aber nicht das Verhalten eines Elements!

Umgekehrt bleibt ein ursprünglich tastaturbedienbares Element auch nach einer Neudefinition mit role mit der Tastatur bedienbar:

  1. <a href="seite.html" role="heading">Linktext</a>

Die »neue« Überschrift steht nach wie vor in der Tabulatorreihenfolge und das ursprüngliche Linkziel kann durch Klicken oder Drücken der Eingabetaste aufgerufen werden. Semantisch ist die Überschrift aber kein Link mehr – im Screenreader handelt es sich um eine fokussierbare Überschrift. Das role-Attribut ist deshalb mit Vorsicht einzusetzen beziehungsweise nur dort einzusetzen, wo Probleme tatsächlich behoben werden müssen.

Verschiedenartige Rollen und neue Attribute

In der WAI-ARIA-Spezifikation werden vier Arten von Rollen definiert. Die Rollen dienen unterschiedlichen Zwecken:

  • Bei den landmark roles geht es vor allem um ein Navigationskonzept für Tastatur- und insbesondere Screenreader-Nutzer. Die landmark roles dienen der strukturellen Navigation und werden die seit vielen Jahren genutzte Technik der Navigation über Überschriften ersetzen. Wenn sämtliche Inhaltsblöcke einer Seite mit passenden Rollen (Navigation, Inhalt etc.) versehen werden, können Screenreader-Nutzer eine Seite besser erkunden.
  • Die document structure roles sind im Gegensatz zu landmark roles nicht für die strukturelle Navigation vorgesehen, geben dem Aufbau der Seite aber ebenfalls eine zusätzliche Semantik. Auf vielen Websites werden sie bereits intensiv genutzt, was aber im Screenreader zu sehr vielen, meist überflüssigen Informationen führt.
  • Mit den widget roles werden komplexere, interaktive UI Komponente gekennzeichnet (zum Beispiel Tab-Panels, Baumstrukturen oder Akkordeons). Sie müssen oft mit weiteren Attributen ergänzt werden, um Zustände und Eigenschaften der Komponenten korrekt an den Browser vermitteln zu können. Teilweise erlauben Browser dann eine bessere Tastaturbedienbarkeit in Screenreadern; grundsätzlich muss aber die Bedienung mit der Tastatur vom Webentwickler bereitgestellt werden.
  • Die abstract roles sind für die Webentwicklung uninteressant; sie dienen der Klassifikation der anderen Rollen.

Es gibt zahlreiche Attribute für die einzelnen Rollen. Die WAI-ARIA-Attribute beginnen mit "aria-" (und bleiben somit von HTML5-Attributen unterscheidbar). Um beispielsweise ein Element mit der Rolle einer Überschrift auch die Eigenschaft einer Überschriftenebene zuzuweisen, wird das aria-level-Attribut eingesetzt:

  1. <h1 role="heading" aria-level="3">Überschriftentext</h1>

oder

  1. <span role="heading" aria-level="3">Überschriftentext</span>

Mit den ARIA-Attributen sollten alle Browser den Inhalt als Überschrift übersetzen und dem jeweiligen Accessibility-API des Betriebssystems durchreichen. Ein Screenreader holt die Informationen von der Accessibility-API ab und in beiden Fällen sollten die Screenreader-Nutzer eine Überschrift dritter Ebene vorfinden.

Statische oder dynamische Technik?

Wann WAI-ARIA-Attribute eingesetzt werden sollten, hängt immer vom HTML ab. WAI-ARIA ergänzt eine Auszeichnungssprache wie HTML und sollte zum Fine-Tuning eingesetzt werden. Alles, was mit HTML erledigt werden kann, sollte mit HTML umgesetzt werden, sei es im HTML selbst oder in Skripts.

Ob die Rollen und weiteren ARIA-Attribute im HTML stehen oder durch JavaScript der Webseite zugewiesen werden, ist im Prinzip ohne Belang. Während landmark und document structure roles ohne Weiteres im HTML stehen können, sind widget roles meist nur auf dynamischen Seiten zweckmäßig. Das heißt: Wenn JavaScript die Voraussetzung für die Funktionalität einer Seite ist, spielt es keine Rolle, ob die Attribute im HTML stehen oder erst später dynamisch zugewiesen werden. Wichtig ist, dass die Attribute für Zustände und Eigenschaften der Rollen korrekt mit JavaScript aktualisiert werden.

Handarbeit oder JavaScript-Bibliothek?

WAI-ARIA wird leider oft unterschätzt, vor allem bei den widget roles. Die tatsächliche Funktionalität hängt nicht nur von der Rolle und der Vergabe einiger weiterer Attribute ab, sondern von der korrekten Aktualisierung von Zuständen und Eigenschaften bei dynamischen Elementen auf einer Webseite. Auch ist die vollständige Unterstützung in Browsern und Hilfsmitteln wie Screenreader leider immer noch nicht gegeben. Und, obwohl es viele wohlklingende Tutorien draußen im Netz gibt, einiges funktioniert in der Praxis doch nicht. Teilweise werden falsche oder die Barrierefreiheit nicht unterstützende Attribute eingesetzt und manchmal fehlen HTML5-Attribute. Wo auch immer die Gründe für die Unzugänglichkeiten liegen mögen, ausführliche Tests mit Screenreadern sind unumgänglich, um die Barrierefreiheit sicherzustellen.

Es gibt einfache und komplexere Widgets; auch gibt es kombinierte Widgets. Während einfachere Widgets wie tri-state Checkboxen durchaus mit Marke Eigenbau erstellt werden können (und das morgige Türchen dieses Adventskalenders gibt dazu ein Beispiel), wird es bei zunehmender Komplexität einer Komponente immer ratsamer, eine der zahlreichen JavaScript-Bibliotheken einzusetzen. Der bloße Einsatz dieser Bibliotheken garantiert keinesfalls tastaturbedienbare oder screenreaderfähige Ergebnisse.

Für die drei Bibliotheken jQuery, Dojo und MooTools gibt es das unabhängige accessible component modules, das die Ausgabe verschiedener Widgets vor allem für die Tastaturbedienung und Nutzbarkeit in Screenreader optimiert. Die Ergebnisse dieser Module lassen sich sehen: Die Widgets sind mit der Tastatur und in Screenreadern getestet, allerdings nur in aktuelleren Versionen von JAWS und das kostenfreie NVDA. Andere Screenreader wie VoiceOver, Kobra, Supernova oder Window Eyes sowie die zahlreichen Vergrößerungssysteme mit unterstützender Sprachausgabe werden mit Sicherheit nicht die gleichen guten Ergebnisse erzielen.

Kommentare

Gunnar Bittersmann
am 07.12.2013 - 12:16

Bei einer Codezeile rollen sich mir aber dann doch die Fußnägel auf, obwohl diese nicht dazu bestimmt war:
<h1><a href="#" onclick="foo();">Linktext</a></h1>
Das mag leider common practice sein, ist aber nicht best practice.

Wenn man keinen Sprung zum Seitenanfang meint, ist href="#" falsch. Stattdessen sollte man tabindex="0" verwenden (wie in der Codezeile darüber, die zum Fußnägel-Aufrollen angedacht war), damit die Bedienung per Tastatur möglich ist:
<h1><a tabindex="0" onclick="foo();">Linktext</a></h1>

Oder ist ein a-Element ohne href-Attribut für AT kein Link, so dass mann dann doch
<h1><a role="link" tabindex="0" onclick="foo();">Linktext</a></h1>
schreiben müsste?

Best practice ist natürlich auch, keinen JavaScript-Code im HTML zu notieren, also kein onclick, sondern die Eventhandler mit JavaScript zu definieren.

Permanenter Link
Jan Hellbusch

Jan Hellbusch (Autor)
am 07.12.2013 - 14:27

Die Variante mit tabindex statt href geht natürlich auch - keine Frage. Liest sich auf jeden Fall sauberer und ich werde das zukünftig auch einsetzen. "Best-Practice" ist zumindest nicht präzise genug, aber ich sage es mal so: Wenn eine Anwendung JS voraussetzt, dann ist es Wurst, wie Events bestimmt werden; ohne JS geht dann ohnehin meist nichts. Das "Best-Practice" bezog sich nur auf das A-Element (um role zu vermeiden), was im Text selbstredend nicht deutlich wird.
Permanenter Link

nikosch
am 10.12.2013 - 14:34

Letztlich sind die Artikel ja alles Lehrbeispiele. Best Practice schließt für mich als Entwickler sowohl href="#", als auch inline-Javascript aus. Meine Musterlösung wäre für diesen Fall - die Role jetzt mal außen vorgelassen - ein href auf ein konkretes Dokument oder den Anker eines konkreten Dokuments und die Definition des Klick-Events über ein modernes „Javascripting“. Das bedeutet: Element im Markup markieren, bspw. über eine CSS-Klasse oder ein data-Attribut, Event zuweisen über bspw. addEventListener onDOMReady, Ausschalten des ursprünglichen nativen Klick-Ereignisses über preventDefault. Ggf. über Hilfetexte auf verändertes Linkverhalten hinweisen.
Der Hinweis auf JS-only-Anwendungen ist zwar valide, trotzdem kann man IMHO immer auf ein echtes Dokument verlinken, und wenn es auch nur den Nutzer darüber aufklärt, dass die Anwendung JS erfordert. Damit steht der Betroffene wenigstens nicht mit einem Ankerklick da, der ihn nirgendwo hin führt. (Eine alte Variante ist übrigens href="javascript:void(0)", selbst die wäre hier noch konsequenter, wenn man von einer reinen JS-Funktionalität ausgeht)

Permanenter Link

Die Kommentare sind geschlossen.