Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Barrierefreiheit auch für dynamische Seiten – mit HTML5 und ARIA

    Barrierefreiheit auch für dynamische Seiten – mit HTML5 und ARIA
Barrierefreiheit mit HTML

Websites barrierefrei zu gestalten, ist an sich nicht schwieirig, wenn man sich an Webstandards hält und auf Techniken wie JavaScript weitestgehend verzichtet. Doch seit Web 2.0 werden oft auch dynamische Elemente wie Tabs und Fortschrittsbalken und damit auch sehr viel JavaScript eingesetzt. Um auch solche Techniken barrierefrei zu halten, gibt es ARIA.

ARIA steht für „Accessible Rich Internet Applications“ und ist eine Spezifikation, die Menschen mit Behinderungen den Zugriff auf Webinhalte vereinfachen soll. Entwickelt wird ARIA von der Web Accessibility Initiative (WAI) unter dem Dach des W3C, weshalb man auch von WAI ARIA spricht.

Wie sorgt ARIA für Barrierefreiheit?

Mit ARIA werden HTML-Elementen zusätzliche Informationen übergeben, welche die Rolle, Eigenschaft oder den Zustand der Elemente beschreiben:

<ul id="reiter-nav" role="tablist"> <li id="reiter-1" role="tab">Start</li> <li id="reiter-2" role="tab">Profil</li> </ul> <div id="reiter-inhalt-1" role="tabpanel" aria-labelledby="reiter-1">Inhalt 1</div> <div id="reiter-inhalt-2" role="tabpanel" aria-labelledby="reiter-2">Inhalt 2</div>

Tabs werden oftmals wie im Beispiel als unsortierte Liste erstellt und mittels CSS und JavaScript so gestaltet und konfiguriert, dass der dazugehörige Inhaltsbereich – in der Regel ein DIV-Container – sichtbar wird, wenn man auf den jeweiligen Tab klickt.

Mit ARIA lassen sich den einzelnen Elementen ihre jeweiligen Rollen mit dem Attribut „role“ zuweisen. Dem UL-Element wird also die Rolle „tablist“ als übergeordnetes Element für die Tabs, den LI-Elememten die Rolle „tab“ und den DIV-Elememten die Rolle „tabpanel“ als Inhaltselement der jeweiligen Tabs zugewiesen. Entsprechende Browser (zum Beispiel für Sehgeschädigte) können nun die Rollen auslesen und die Inhalte entsprechend – zum Beispiel über eine Sprachausgabe – ausgeben. Der Kontext zwischen dem Tabmenü und den Inhaltscontainern wird mit ARIA ersichtlich und lässt sich bei der Ausgabe berücksichtigen. Zusätzlich können Eigenschaften und Zustände – ebenfalls als Attribut – übergeben werden. Diese Attribute beginnen alle mit der Zeichenkette „aria-“, gefolgt von der entsprechenden Bezeichnung. Über „aria-labelledby“ lässt sich die ID des zum Tabpanels gehörenden Tabs übergeben.

Welche Rollen gibt es?

Für viele der gängigen Funktionen, die für dynamische Inhalte realisiert werden, bietet ARIA Rollen an. Neben Tabs und Fortschrittsbalken lassen sich viele weitere Rollen zuweisen. Hier nur einige wenige Beispiele:

  • Tabs mit „tablist“, „tab“ und „tabpanel“
  • Fortschrittsbalken mit „progressbar“
  • Tooltips mit „tooltip“
  • Scrollleisten mit „scrollbar“ (für selbst programmierte Scrolleisten)

Bei Formularen lassen sich über ARIA auch Pflichtfelder auszeichnen. Für Sehbehinderte sind farbliche Hervorhebungen für Pflichtfelder nicht oder nur schwer wahrnehmbar. Mit ARIA lässt sich das ändern:

<input type="text name="email" aria-required="true" />

Eine komplette Zusammenstellung der Rollen und der dazugehörigen Eigenschaften und Zustände gibt es auf den entsprechenden Seiten des W3C.

Barrierefreiheit für Interaktionen

Auch dynamische Interaktionen wie sie bei sozialen Netzwerken stattfinden, lassen sich mit ARIA barriefrei darstellen. ARIA besitzt die Möglichkeit, sogenannte Live-Regionen zu definieren. Das sind Bereiche, die zum Beispiel für einen Chat mittels AJAX dynamisch aktualisiert werden.

Für solche Bereiche lässt sich zudem definieren, wie dieser Bereich für Menschen mit Behinderung aktualisiert werden soll:

<div id="chat" aria-live="polite">Chatinhalt</div>

Es gibt drei mögliche Eigenschaften. Die Eigenschaft „off“ gibt keine Aktualisierung des Inhalts aus, „polite“ gibt Aktualisierungen zu einem günstigen Zeitpunkt aus (zum Beispiel nachdem ein Text gesprochen wurde) und „assertive“ gibt Aktualisierungen umgehend aus.

Interessant ist diese Rolle für Browser mit Sprachausgabe. Wer sich gerade einen Text vorlesen lässt, will eventuell nicht ständig durch die Wiedergabe aktueller Kommentare unterbrochen werden.

ARIA und HTML5

Für viele Rollen, die ARIA zur Verfügung stellt, gibt es mit HTML5 mittlerweile äquivalente Elemente. So gibt es für Fortschrittsbalken ein eigenes Element, das die Zuweisung einer Rolle über ARIA überflüssig macht:

<progress max="100" value="75"></progress>

Da viele der neuen HTML5-Elememte allerdings – wenn überhaupt – nur von aktuellen Browsern unterstützt werden, sollte jeweils überlegt werden, ob man bereits auf HTML5 setzt oder eher auf einen Workaround mit Unterstützung von ARIA setzt:

<div id="progress" role="progressbar" aria-valuemax="100" aria-valuenow="75"></div>

Die Spezifikationen von ARIA erlauben es nicht, vorgegebene Rollen von HTML-Elementen zu überschreiben. Allerdings gibt es in HTML5 einige Elemente, die zwar auch eine vorgegeben Rollen besitzen, die sich aber mit ARIA noch expliziter beschreiben lässt.

So gibt es in HTML5 das ARTICLE-Element, das – wie der Name schon sagt – einen Bereich für einen Artikel definiert. In ARIA gibt es zudem die Rolle „article“, mit der sich zum Beispiel ein DIV-Element als Artikel auszeichnen lässt:

<div role="article">Artikel in einem DIV-Container mit ARIA-Rolle</div>
<article>Artikel in einem HTML5-Element ohne Rolle</article>

Wer das HTML5-Element nutzt, kann auf die Rollenbezeichnung verzichten; es sei denn, man möchte die Art des Artikels genauer definieren:

<article role="document">Ein Artikel, der die Rolle eines Dokumentes hat</article>
<article role="main">Ein Hauptartikel, dem ggf. weitere Artikel folgen</article>

Also auch in Zeiten von HTML5 ist ARIA ein wichtiges Instrument, um Inhalte barrierefrei auszuzeichnen und sie genauer zu definieren. Die Rollen, Eigenschaften und Zustände, die definiert werden können, sind sehr umfangreich und können in so einem Artikel nur exemplarisch vorgestellt werden. Für eine Gesamtübersicht empiehlt sich ein Blick auf die Website der Web Accessibility Initiative (WAI).

Wie wichtig ist euch eine barriefreie Website? Nutzt ihr ARIA oder reicht euch die reine Zugänglichkeit der Inhalte durch Einhaltung vin Webstandards und Verzicht auf JavaScript?

Weiterführende Links zu aktuellen News auf t3n.de:

Finde einen Job, den du liebst zum Thema JavaScript, Webdesign

2 Reaktionen
Stephan
Stephan

An den Autor: "Websites barrierefrei zu gestalten, ist an sich nicht schwieirig, wenn man sich an Webstandards hält und auf Techniken wie JavaScript weitestgehend verzichtet".
Ich habe vor einiger Zeit die WAI/WCAG Richtlinien überflogen und konnte dazu nichts finden. Daher denke ich, dass das ein weit verbreiteter Irrtum ist. Könntest du das referenzieren? Wo steht, dass man für barierefreie websites auf Javascript verzichten muss?

Antworten
Thomas Quensen

Hier mal ein Link zur HTML-Spec, in der die in den HTML5-Elementen "eingebauten" ARIA-Semantiken zu finden sind:
http://dev.w3.org/html5/spec-author-view/wai-aria.html#wai-aria

Antworten
Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden