Hinweis: Dies ist die deutsche Übersetzung des Artikels „Introduction to WAI ARIA“ von Gez Lemon.

Einführung in WAI ARIA

Von Gez Lemon · 1 Aug, 2008
übersetzt von Stefan Walter

Dieser Artikel ist für diejenigen, denen ARIA noch unbekannt ist. Vorausgesetzt werden das Verständnis von HTML und Kenntnisse der potentiellen Schwierigkeiten, auf die Leuten mit Behinderungen im Internet treffen können. Es ist hilfreich mit einigen Rich Internet Applications aus Benutzersicht vertraut zu sein

Nach dem Lesen dieses Artikels werden Sie verstehen, wozu ARIA gut ist, wie Sie es in Ihre bestehenden Seiten integrieren können und wie sie auch die simpelsten Seiten zugänglicher machen können.

Dieser Artikel ist ebenfalls in Spanisch (Introducción a WAI-ARIA von David Martin und Französisch (Introduction à WAI ARIA von Pierre Bertet) übersetzt worden.

Update 8. Oktober 2008: Die Liste der Dokumenten-Landmark-Rollen wurde aktualisiert, um den Änderungen in der Spezifikation zu entsprechen.

Update 1. April 2009: Der Abschnitt über aria-channel und aria-live="rude" wurde entfernt, um die Änderungen in der Spezifikation wiederzuspiegeln. Beide wurden aus der Spezifikation entfernt.

Einleitung

Die „HyperText Markup Language“ (HTML) wurde ursprünglich nicht entwickelt, um Web-Applikationen zu erstellen. HTML hat einen limitierten Vorrat von Interface-Elementen und wurde um ein sequentielles Client-Server-Modell herum entwickelt. Um diese Limitationen zu umgehen haben Entwickler von Web-Applikationen eigene Komponenten (Widgets) entwickelt und diesen dann mit JavaScript das korrekte Verhalten beigebracht.

Unglücklicherweise waren diese Methoden um die Limitation zu umgehen nicht zugänglich. Auch wenn diese Widgets so aussahen und sich so verhielten wie normale Widgets von Desktop-Applikationen (wie beispielsweise ein Widget, das eine Baumansicht zeigt) waren die Rolle (was das Widget tut), der Status (der Zustand, wie beispielsweise „checked” bei einer Checkbox) und andere wichtige Eigenschaften nicht zugänglich für assistive Technologien, z.B. Screenreader. Das entspricht in etwa dem Anpassen des Aussehens von einfachem Text via CSS um so auszusehen wie eine Überschrift, anstatt direkt ein Überschriften-Element zu benutzen – der Text mag aussehen wie eine Überschrift, aber dies bleibt assistiven Technologien verborgen.

Aktualisierungen des Inhalts werden oft von Nutzern assistiver Technologien nicht wahrgenommen. Assistive Technologien erwarten üblicherweise, dass sich der Inhalt der Webseite als Reaktion auf ein Navigations-Ereignis ändert, wie beispielsweise das Klicken auf einen Link oder das Absenden eines Formulars. Web-Applikationen benutzen Techniken wie AJAX um Inhalte „versteckt" auszutauschen, was manchmal von assistiven Technologien nicht erkannt wird. Auch wenn diese eventuell von Änderungen des Inhaltes etwas mitbekommen, kann es sein, dass der Benutzer dies nicht mitbekommt oder nicht weiß, wo er diesen aktualisierten Inhalt lokalisieren soll.

WAI-ARIA ist eine Spezifikation, die Hilfen anbietet diese Rollen, Zustände und Eigenschaften dieser selbst entwickelten Widgets zu beschreiben, um sie so für Nutzer assistiver Technologien erkenn- und benutzbar zu machen. WAI-ARIA stellt ebenfalls Mechanismen zur Verfügung, um diese Nutzer auch auf Aktualisierungen des Inhaltes der Applikation hinzuweisen.

Eine kurze Geschichte von HTML

HTML wurde ursprünglich als Hypertext-System, um verknüpfte Dokumente zu strukturieren und eine gemeinsame Nutzung zu ermöglichen, entwickelt. Frühe HTML-Entwürfe definierten Elemente wie beispielsweise Überschriften, Absätze, Listen oder Textanker um text-basierten Dokumenten eine Struktur zu geben. Der erste Vorschlag einer HTML-Spezifikation der IETF beinhaltete auch das img-Element um Grafiken in Texten anzuzeigen. Die erste offizielle HTML-Spezifikation war HTML 2, welches auf den frühen HTML-Entwürfen basierte. Diese Spezifikation führte Formulare und einen kleinen Teil von Interface-Komponenten ein, um z.B. edit boxes, Buttons, Checkboxen, Radio-Buttons und Dropdown-Listen zu erstellen. Dieser kleine Satz in HTML 2 definierter Interface-Elemente, hat sich – vergleicht man ihn mit den Elementen aus HTML 4.01 welche wir zur Zeit benutzen – kaum verändert.

Das Kommunikationsmodell von HTML basiert auf dem Client-Server-Modell. In diesen schickt der Client Anfragen und empfängt die Antworten. Der Server wartet auf Anfragen, verarbeitet diese und schickt die Antworten zurück an den Client. Da HTML keine Verhaltensschicht (behaviour layer) kennt, war diese sequentielle Kommunikation beabsichtigt – der Client fragt eine Seite auf dem Server an, der Server verarbeitet diese Anfrage und schickt diese Seite an den Client.

Web-Applikationen

Web-Applikationen versuchen reguläre Desktop-Applikationen zu emulieren – mit dem Unterschied, dass Web-Applikationen bereits in einer anderen Desktop-Applikation laufen: einem Browser. Es existieren auch noch zwei fundamentale Unterschiede zwischen HTML und dessen Kommunikationsmodell und einer normalen Desktop-Applikation:

Echte Desktop-Applikationen haben eine Verhaltensschicht, die nicht abhängig ist von Anfragen zu einem Server.
Echte Desktop-Applikationen haben einen weitaus größeren Satz von Interface-Komponenten zur Verfügung.

Emulation von Desktop-Applikationen

Server-Anfragen im Hintergrund

Um eine Desktop-Applikation zu emulieren benutzen Web-Applikationen JavaScript um die notwendige Verhaltensschicht hinzuzufügen. Beispielsweise wird JavaScript benutzt, um ein Menü-Element aus- und wieder einzuklappen, wenn der Benutzer damit interagiert. Bisweilen werden auch Daten vom Server benötigt. Beispielsweise muss die Applikation Datensätze aus einer Datenkbank holen um Inhalte auf der aktuellen Seite zu aktualisieren. Wenn die Applikation mit dem Server interagieren mus, benutzen Web-Applikationen Methoden wie AJAX oder versteckte IFrame-Elemente um versteckt im Hintergrund mit dem Server zu kommunizieren.

Emulation von komplexeren Komponenten

Da HTML nur sehr wenige Interface-Elemente zur Verfügung hat, müssen Web-Applikationen manchmal komplexere Widgets erstellen (beispielsweise Checkboxen mit 3 Zuständen oder einen Schieberegler). Das Look-and-Feel dieser Widgets wird üblicherweise dadurch erreicht, dass das Widget selbst als Grafik erstellt wird und mittels Javascript benutzt wird, damit sich das Widget wie eine native Komponente verhält.

Drei Checkboxen; nicht aktiviert, aktiviert und teilweise aktiviert

Abbildung 1 — Ein Dialog mit einer Checkbox mit drei Zuständen.

Schieberegler mit einzelnen Werten um die Qualität einer Dienstleistung zu beurteilen

Abbildung 2 — Ein Schieberegler, der dazu benutzt werden könnte, um die Qualität einer Dienstleistung zu beurteilen.

Zugänglichkeitsprobleme dieser „Look-and-Feel“-Emulationen

Visuell schaffen diese emulierten, komplexeren Komponenten eine besseres Nutzungserlebnis. Unglücklicherweise resultiert dies aber auch in Zugänglichkeitsproblemen, die besonders Nutzer assistiver Technologien, wie z.B. Screenreader, betreffen.

Widgets dieser Art sind selten per Tastatur nutzbar.
Die Rolle/Aufgabe des Widgets ist Nutzern assistiver Technologie nicht ersichtlich.
Status und Eigenschaften des Widgets sind Nutzern assistiver Technologien nicht zugänglich.
Aktualisierungen und deren Auffinden werden assistiven Technologien nicht mitgeteilt.

WAI-ARIA als Retter

Glücklicherweise können alle oben genannten Probleme mit der Web Accessibility Initiative’s Accessible Rich Internet Applications (WAI-ARIA)-Spezifikation (im Rest dieses Artikels nur noch ARIA genannt) gelöst werden. ARIA ist eine positive Technologie die etwas ermöglicht — statt Entwicklern vorzuschreiben, was sie nicht tun können, erlaubt ARIA den Entwicklern komplexe Web-Applikationen zu bauen. ARIA ist auch sehr einfach zu implementieren.

Tastatur-Navigation

Neben dem Anbieten von alternativem Text für Nicht-Text-Objekte ist das interagieren mit Interface-Elementen allein über die Tastatur eine der grundlegenden Maßnahmen um Zugänglichkeit zu gewährleisten. Entwickler, die sich mit Zugänglichkeit auskennen, könnten eigene Widgets mit Elementen erstellen, welche per Tastatur ausgewählt werden können, wie beispielsweise das input-Element mit dem type-Attributwert image (<input type="image" ...>). Leider sind die meisten Widgets mit Elementen gebaut, die nicht per Tastatur zugänglich sind, sondern aus Elementen wie dem img-Element bestehen oder auch aus mehreren Elementen zusammengesetzt wurden und in einem Container-Element liegen (wie einem div), welches nicht per Tastatur ausgewählt werden kann.

HTML 4 führte das tabindex-Attribut für die Elemente a, area, button, input, object, select und textarea ein. Das tabindex-Attribut von HTML 4 akzeptiert einen positiven Wert im Bereich zwischen 0 und 32767. Die Navigation startet mit dem Element mit der niedrigsten Zahl und führt bis zum Element mit der höchsten Zahl fort. Elemente mit einem Wert von 0 werden in der Reihenfolge, in der sie im Quelltext vorkommen angesteuert. Wenn das Markup eine logische Struktur hat, ist das tabindex-Attribut nicht erforderlich für Elemente, die sich schon in der Tab-Reihenfolge befinden.

ARIA erweitert das tabindex-Attribut, so dass es auf alle sichtbaren Elemente angewendet werden kann. ARIA erlaubt es auch Elementen negative Werte zuzuweisen, die nicht in der Tab-Reihenfolge auftauchen sollen, jedoch eventuell per JavaScript-Anweisung fokussiert werden sollen. Da der eigentliche Wert der negativen Zahl keine Rolle spielt (das Element erhält ja nie per Tastatur den Fokus), wird typischerweise der Wert -1 für diese Elemente die nicht in der Tab-Reihenfolge auftauchen sollen benutzt – die jedoch per Skript möglicherweise fokussiert werden können. Beispielsweise könnten Sie ein Menü-Widget erstellen, bei dem das Menü selbst in der Tab-Reihenfolge auftaucht, die Menü-Elemente aber nicht. Jedoch könnten die Menü-Elemente so erstellt werden, dass durch diese mit den Pfeiltasten navigiert werden kann. So muss ein Benutzer nicht per Tabulator-Taste durch alle Elemente in einem Menü springen und kann das Dokument somit besser navigieren. Dies trifft für alle Widgets zu, die aus einer Reihe von Komponenten bestehen, die Tastaturzugriff benötigen, wie beispielsweise eine Tree-Komponente.

Zusätzlich zur regulären Tab-Reihenfolge

Das folgende Beispiel benutzt ein tabindex-Attributwert von 0, um ein div-Element in die Tab-Reihenfolge zu bringen, so dass ein Nutzer mit der Tastatur zu diesem Element navigieren kann.

<div tabindex="0">
...
</div>

Negativer Tabindex

Das folgende Beispiel benutzt einen negativen tabindex-Attributwert, so dass dem Element per JavaScript Fokus zugewiesen werden kann.

<div id="progaccess" tabindex="-1">
...
</div>

In diesem Beispiel befindet sich das div-Element nicht in der regulären Tab-Reihenfolge, aber da es ein tabindex-Attributwert von -1 hat. Dies bedeutet aber, dass dem Element per Skript Fokus zugewiesen werden kann. Der folgende kleine JavaScript-Abschnitt wählt zuerst ein Element aus und fokussiert dieses dann per focus-Methode.

var objDiv = document.getElementById('progaccess');

// Focus on the element
objDiv.focus();

Was bin ich?

ARIA führt das role-Attribut ein, um Widgets genauer zu spezifizieren (bspw. Schieberegler) und um die Seitenstruktur genauer kennzeichnen zu können (bspw. die Navigation). Eines der Hauptprobleme von Web-Applikationen ist, dass jedes Element bei der Erstellung eines Widgets benutzt werden kann. HTML-Elemente haben bereits eine vordefinierte Rolle. Die Rolle eines Elements besagt, was es tut – den Part, den es in der Struktur spielt. Die Rolle einer Überschrift wird beispielsweise sehr gut von assistiven Technologien verstanden. Wenn Widgets mit existierenden Elementen erstellt werden, wird die Rolle des Elements von den assistiven Technologien erkannt und nicht etwa das, was es visuell im Widget darstellen soll. Wenn beispielsweise der Anfasser in einem Schieberegler-Element mit einem Bildelement mit dem entsprechendem Alternativtext realisiert wurde, dann wird ein Screenreader aller Voraussicht nach diesen Anfasser als "Bild, Regler" vorlesen und nicht etwa als etwas aussagekräftigeres wie "Schieberegler, Wert 16 Prozent".

Abbildung 3 — Der Anfasser eines typischen Schiebereglers.

Die Rolle die durch die role-Eigenschaft festgelegt wird überschreibt die Rolle des eigentlichen Elements. Im folgenden Beispiel hat ein input-Element die role-Eigenschaft slider (später werden noch einige andere ARIA-Eigenschaften vorgestellt) — die Rolle, die nun für assistive Technologien erkennbar ist, ist slider, nicht etwa input.

<input type="image"
src="thumb.gif" 
alt="Effectiveness" 
role="slider"
aria-valuemin="0" 
aria-valuemax="100"
aria-valuenow="42"
aria-valuetext="42 percent"
aria-labelledby="leffective">

Wenn dieses Element nun den Fokus bekommt, erkennt ein Screenreader welche Rolle dieses Widget hat. Die ARIA-Spezifikation enthält eine ganze Reihe von Rollen..

Dokumenten-Landmark-Rollen

So wie es Rollen gibt, die ein Widget detailliert beschreiben gibt es auch Rollen, die helfen die Struktur eines Dokuments näher zu beschreiben. Dokumenten-Landmarken sind eine Untermenge normaler Rollen, die Screenreader-Nutzern helfen, die eigentliche Bedeutung einer Sektion zu verstehen und sich im Dokument zurechtzufinden.

Page Structure

Abbildung 4 — Eine typische Seite mit Seitenkopf, Seitenleiste und einem Inhaltsbereich.

ARIA definiert die folgenden Landmark-Rollen

article: Inhalt, der eigenständig Sinn ergibt, beispielsweise ein Blogeintrag, ein Kommentar in einem Blog, ein Eintrag in einem Forum, usw.
banner: Site-spezifischer Inhalt, beispielsweise der Titel der Seite und das Logo.
complementary: Unterstützender Inhalt für den Hauptinhalt, aber auch für sich alleinstehend wenn er vom Hauptinhalt getrennt wird. Beispielsweise das angezeigte Wetter auf einem Portal
contentinfo: Fußnoten, Copyright-Hinweise, Voreinstellungen, rechtliche Hinweise, und ähnliches
main: Inhalt mit direktem Bezug zum Hauptinhalt oder Inhalt der zum zentralen Inhalt des jeweiligen Dokuments führt.
navigation: Inhalt, der Links enthält, um durch das Dokument und/oder zu ähnlichen Dokumenten zu navigieren.
search: Diese Sektion enthält die Suchfunktion um die Website zu durchsuchen.

Das folgende Beispiel spezifiziert die Landmark-Rollen banner, navigation, und main, um die Seitenstruktur aus Abbildung 4 zu erstellen.

<div role="banner">
...
</div>
<div role="navigation">
...
</div>
<div role="main">
...
</div>

ARIA Zustände und Eigenschaften

ARIA Zustände und Eigenschaften ermöglichen es, assistiven Technologien zusätzliche Informationen über das Widget zur Verfügung zu stellen, um dem Benutzer zu verdeutlichen wie er mit dem Widget interagieren kann. Der Zustand bestimt eine eindeutige Informationsstruktur eines Objekts. Die aria-checked-Eigenschaft hat drei Zustandswerte: true, false und mixed.

Im obigen Schieberegler-Beispiel wurden diverse ARIA-Eigenschaften benutzt, die helfen assistiven Technologien das Widget genauer zu beschreiben.

aria-valuemin: Speichert den niedrigsten Wert eines Wertebereichs.
aria-valuemax: Speichert den höchsten Wert eines Wertebereichs.
aria-valuenow: Speichert den aktuellen Wert eines Wertebereichs.
aria-valuetext: Speichert lesbare Informationen um dem Nutzer den Kontext verstehen zu helfen. Beispielsweise "30 dollars".
aria-labelledby: Speichert das id-Attribut eines Textlabels, welches eine passende Beschreibung für dieses Widget darstellt.

Einige Eigenschaften können per JavaScript aktualisiert werden, beispielsweise würden die beiden Eigenschaften aria-valuenow und aria-valuetext unseres Schieberegler-Widgets aktualisiert werden, sobald der Anfasser verschoben wird.

// Die ARIA-Eigenschaftswerte aktualisieren 
// wenn der Anfasser bewegt wurde
objThumb.setAttribute('aria-valuenow', iValue);
objThumb.setAttribute('aria-valuetext', iValue + ' %');

Das Hinzufügen von ARIA-Rollen und ARIA-Attributen verhindern das validieren gegen HTML 4.01 oder XHTML 1.0, das ist aber insofern in Ordnung, da ARIA wichtige Informationen zu Spezifikationen hinzufügt die vor langer Zeit festgelegt wurden. Abhilfe ist aber bereits unterwegs, durch die Definition einer DTD die in modularem XML, z.B. XHTML 1.1, benutzt werden kann. Es exisitiert auch eine vollständige Liste von Zuständen und Eigenschaften in der ARIA-Spezifikation, die helfen zugängliche Widgets zu erstellen.

Live-Regionen

Live-Regionen erlauben es, dass Elemente eines Dokuments mitteilen wenn sie verändert wurden, ohne dass der der Benutzer den Fokus auf seine derzeitige Aktivität verliert. Das bedeutet, dass Benutzer über Änderungen informiert werden ohne den derzeitigen Ort im Dokument zu verlassen. Ein Beispiel verdeutlicht das: Eine Chat-Applikation kann die Antwort eines anderen Nutzers mitteilen ohne dass der Fokus vom eigenen Eingabefeld genommen wird.

aria-live

Die Entdeckbarkeit von aktualisiertem Inhalt ist eine der größten Hürden für Benutzer von Screenreadern. ARIA stellt die aria-live-Eigenschaft zur Verfügung, die mit einem Wert die „Änderungswarscheinlichkeit“ einer Region angibt. Im folgenden die Werte, die die aria-live-Eigenschaft annehmen kann.

off

Das ist der Standardwert und gibt an, dass in dieser Regionen keine Änderungen erwartet werden.

<ul aria-live="off">

polite

Dies ist der Standardwert und das erwartete Verhalten für Live-Regionen. Ein Eigenschaftswert von polite gibt an, dass keine Antwort des Nutzers nötig ist solange er seine derzeitige Aktivität nicht abgeschlossen hat.

<ul aria-live="polite">

assertive

Dieser Wert hat eine höhere Priorität als normal, unterbricht den Benutzer aber nicht sofort in seiner Tätigkeit.

<ul aria-live="assertive">

Es gibt noch einige andere wichtige Eigenschaften, die für Live-Regionen wichtig sind, die im nun kurz zusammengefasst werden.

Die `aria-atomic`-Eigenschaft

Die aria-atomic-Eigenschaft ist eine optionale Eigenschaften für Live-Regionen und kann die Werte true oder false annehmen (false ist auch der Standardwert, falls die Eigenschaft nicht explizit angegeben wird). When diese Region aktualisiert wird, wird die aria-atomic-Eigenschaft dazu benutzt anzugeben ob dem Nutzer die ganze oder nur die geänderten Teile der Region mitgeteilt werden sollen. Falls diese Eigenschaft auf true gesetzt wurde, sollen assistive Technologien die komplette Region ausgeben, ansonsten nur den geänderten Teil.

Im folgenden Beispiel werden immer alle Elemente der ungeordneten Liste vorgelesen, solange nicht ein anderes Element tiefer in der Struktur die aria-atomic-Eigenschaft überschreibt.

<ul aria-atomic="true"
    aria-live="polite">

Die `aria-busy`-Eigenschaft

Die aria-busy-Eigenschaft ist eine optionale Eigenschaft für Live-Regionen und kann die Werte true oder false annehmen (false ist auch der Standardwert, falls die Eigenschaft nicht explizit angegeben wird). Wenn mehrere Bereiche geladen sein müssen, bevor Änderungen daran an den Benutzer gemeldet werden, kann die aria-busy-Eigenschaft solange auf true gesetzt werden bis diese komplett geladen sind und dann schließlich auf false gesetzt werden. Diese Eigenschaft verhindert, dass assistive Technologien Änderungen verarbeiten und ausgeben bevor alle Aktualisierungen komplett abgeschlossen sind.

<ul aria-atomic="true"
    aria-busy="true"
    aria-live="polite">

Die `aria-relevant`-Eigenschaft

Die aria-relevant-Eigenschaft ist eine optionale Eigenschaft für Live-Regionen, die angibt welche Änderungen innerhalb einer Region relevant sind. Die aria-relevant-Eigenschaft akzeptiert eine leerzeichengetrennte Liste der folgenden Eigenschaftswerte:

additions: Knoten werden dem DOM hinzugefügt.
removals: Knoten werden aus dem DOM entfernt.
text: Text wurde hinzugefügt oder entfernt.
all: Alles obenstehende (hinzufügen, entfernen, Text) gilt für die Region.

Falls die aria-relevant-Eigenschaft nicht explizit angegeben wurde, wird angenommen, dass Textänderungen und -additionen vorkommen können (aria-relevant="text additions"). Das folgende Beispiel würde Änderungen nur mitteilen, falls Knoten innerhalb der Region hinzugefügt würden. Bei Textänderungen oder falls Knoten entfernt würden, würde der Benutzer nicht informiert.

<ul aria-relevant="additions" 
    aria-atomic="true"
    aria-live="polite">

Ab wann können wir ARIA benutzen?

Es gibt keine negativen Seiteneffekte wenn man jetzt ARIA benutzt, also kann man jetzt auch damit beginnen. Alle vier der großen Browser haben ARIA-Unterstützung implementiert oder planen diese Unterstützung einzubauen. Opera 9.5 und Firefox 1.5+ unterstützen bereits ARIA. Die Beta vom Internet Explorer 8 unterstützt ARIA und WebKit, das quelloffene Applikations-Framework hinter Safari hat angekündigt, dass mit der Unterstützung von ARIA begonnen wurde.

ARIA wird auch von einer Vielzahl der assistiven Technologien unterstützt. JAWS 7.1+, Window-Eyes 5.5+, NVDA, Zoomtext 9+ und andere haben bereits grundlegende Unterstützung implementiert und diese Unterstützung wird in großen Schritten ausgebaut.

Nutzen Sie ARIA schon jetzt

Da keine negativen Seiteneffekte bei der Nutzung von ARIA auftreten und die Unterstützung durch Browser, Screenreader, ... bereits mehr oder weniger gegeben ist, haben Sie nichts zu verlieren aber viel zu gewinnen. Auch wenn Sie nur eine kleine, einfach aufgebaute Website haben können Sie bereits document landmark roles einbauen um Ihren Benutzern bei der Navigation und Orientierung in den Inhalten der Website behilflich zu sein.

Benutzen Sie document landmark roles

Auf meiner eigenen Website habe ich die document landmark roles für main, navigation, search and secondary benutzt. Schauen Sie sich folgende Dokumentenstruktur an:

<div id="ads">
...
</div>
<div id="nav">
    <form id="searchform" ...>
    ...
    </form>
...
</div>
<div id="content">
...
</div>

Man könnte die role-Eigenschaft für die document landmarks direkt ins Markup schreiben:

<div id="ads" role="banner">
...
</div>
<div id="nav" role="navigation">
    <form id="searchform" role="search" ...>
    ...
    </form>
...
</div>
<div id="content" role="main">
...
</div>

Da die meisten Seiten ja bereits per CSS gestylt werden, ist es sehr warscheinlich, dass viele Seitenbereiche bereits mit id-Attributen ausgezeichnet wurden, die an eine JavaScript-Funktion übergeben werden könnten. Nachfolgend ein Beispiel einer einfachen JavaScript-Funktion, die das id-Attribut eines Elements und einen Rollenwert als Parameter akzeptiert und das role-Attribut dann beim entsprechenden Element setzt.

function addARIARole(strID, strRole)
{
    // Find the element to add a role property to
    var objElement = document.getElementById(strID);

    if (objElement)
    {
        // Add the role property to the element
        objElement.setAttribute('role', strRole);
    }
}

Die Funktion kann dann mit der id der Sektion und der Dokumenten-Landmark-Rolle der Sektion aufgerufen werden. Betrachtet man die obige Dokumentenstruktur, kann man diese JavaScript-Funktion benutzen um das passende role-Attribut zu setzen, statt es direkt ins Markup zu schreiben.

function setupARIA()
{
    // Add ARIA roles to the document
    addARIARole('content', 'main');
    addARIARole('nav', 'navigation');
    addARIARole('searchform', 'search');
    addARIARole('ads', 'banner');
}

window.onload = setupARIA;

Kennzeichnung von erforderlichen Formularelementen

Wenn Sie ein Formular mit erforderlichen Elementen haben, können Sie die aria-required-Eigenschaft benutzen. Die aria-required-Eigenschaft weist darauf hin, dass eine Nutzereingabe an diesem Element erforderlich ist, bevor das Formular abgesendet werden kann. Das folgende Beispiel fügt die aria-required-Eigenschaft zu einem normalen input-Element hinzu.

<label for="contactname">Name</label>
<input type="text"
       id="contactname" 
       name="contactname"
       size="30"
       aria-required="true">

Wordpress hat damit begonnen, das aria-required-Attribut für erforderliche Felder im Kommentarbereich für Blogeinträge zu benutzen.

Fügen Sie andere relevante Eigenschaften hinzu

Es gibt viele ARIA-Eigenschaften, die selbst bei den einfachsten Websites benutzt werden können, wie beispielsweise aria-labelledby und aria-describedby. Die aria-labelledby-Eigenschaft zeigt auf ein oder mehrere Elemente, die als Kennzeichnung für ein Element gilt und die aria-describedby-Eigenschaft zeigt auf ein oder mehrere Elemente, die als Beschreibung für das Element gilt.

<h2 id="limg">Paragliding</h2>
<p id="dimg">
A long description of our paragliding trip ...
</p>

<div>
<img src="takeoff.png"
     alt="Getting ready to take off"
     aria-labelledby="limg"
     aria-describedby="dimg">
</div>

Priorität der Auszeichnung

ARIA-Auszeichnungen hat Vorrang vor der eigentlichen Auszeichnungssprache. Das bedeutet, dass wenn Sie aria-labelledby zusätzlich zu dem HTML-Element <label for="">…</label> benutzen, hat aria-labelledby Vorrang. Das label-Element wird immer noch für ältere Browser unterstützt, die ARIA nicht interpretieren. Eine einfache Methode um Kollisionen zu vermeiden ist, das aria-labelledby-Attribut zu benutzen, um auf ein label zu verweisen — dies stellt sicher, dass das label verfügbar ist, ungeachtet der Unterstützung von ARIA.

<label id="lblef" for="effectiveness">Effectiveness</label>

<input type="image"
       role="slider"
       id="effectiveness"
       aria-labelledby="lblef"
       ...>

Schauen Sie sich die komplette Auflistung der Zustände und Eigenschaften an, damit Sie erkenne, wie ARIA helfen kann Ihren Inhalt zugänglicher zu machen.

Nochmal zusammengefasst

HTML wurde ursprünglich nicht entwickelt um damit Web-Applikationen zu erstellen, aber Entwickler haben diese trotzdem erstellt – mit eigenentwickelten Widgets, denen sie per JavaScript „Leben einhauchten”. Das Problem dabei ist, dass die Rolle, der Zustand und die Eigenschaften von Widgets und Inhalte, die beispielsweise per AJAX aktualisiert werden und diese Informationen somit unzugänglich für assistive Technologien sind. Die ARIA-Spezifikation beseitigt diese Probleme indem sie Entwicklern die Möglichkeit bietet ihre eigenen Widgets im Detail zu beschreiben, die Dokumentenstruktur genau zu definieren und ebenso Bereiche der Webseite zu kennzeichnen, die sich live verändern.

Ob Sie nun ausgewachsene Webapplikationen mit komplexen Widgets und Live-Sektionen oder eine kleine, einfache Website entwickeln – in jedem Fall können Sie jetzt schon ARIA integrieren, damit Nutzer mit Behinderungen davon profitieren.