Web 2.0 Anwendungen sind aufgrund der beschränkten Möglichkeiten von (X)HTML oft nicht barrierefrei oder haben Usability-Probleme. Der Standard-Entwurf des W3C für Accessible Rich Internet Applications (ARIA) überbrückt diese Beschränkungen. Er schafft neue Wege zur Kommunikation von Bedeutung, Relevanz, Beziehungen, füllt die Lücken in den (X)HTML Spezifikationen und steigert die Usability für alle Nutzer, indem er vertraute Navigationsmodelle des Desktops übernimmt. Und das Beste: man kann ARIA sofort einsetzen, um die Zugänglichkeit von Webseiten zu verbessern.

Diese Erweiterung wurde zuerst von Richard Schwerdtfeger von IBM vorgeschlagen. Er ist Mitglied der WAI Protocols and Formats Working Group und der HTML Working Group. Ebenso beteiligt war Becky Gibson, die in der WAI WCAG Working Group aktiv ist. Zusammen mit Aaron Leventhal haben sie diese und andere barrierefreie Techniken in Firefox 1.5-3.0 und verschiedenen assistiven Technologien implementiert.

Natürlich ist das alles illegal, erwiderte Joe Clark, und während ich voll zustimme, dass Standards nicht missachtet werden dürfen und dass es dringendere Themen gäbe, war es eine pragmatische Lösung zur rechten Zeit. Im August 2005 spendete IBM eine große Menge Quellcode, um die Barrierefreiheit des Mozilla Browsers zu verbessern. Kurz nach Clark’s Kritik wurden die ersten Standardentwürfe des W3C für Roles sowie States and Properties für Accessible Rich Internet Applications (ARIA) veröffentlicht. Fast ein Jahr später wurde das role-Attribut als XHTML 1.1 Modul eingeführt. Das „X“ in „XHTML“ steht schließlich für „extensible“ (erweiterbar), aber mehr dazu später. Die Vorschläge wurden mit ungewöhnlichem Tempo durch die W3C-Prozeduren gepuscht und sollen im zweiten vierten Quartal 2007 Standard-Status erlangen. Phantastisch, wie effizient das W3C unter den richtigen Bedingungen arbeiten kann

Semantischer Zuckerguss

Zeitgemäße Web-Programmierung verwendet Aufzählungslisten (li) für die Navigation oder den Brotkrumenpfad, und es gibt verschiedene Bereiche in einer Seite für den Textinhalt oder die Marginalspalte. Zudem kann in Web 2.0 Anwendungen alles ein Button oder ein Bedienelement sein (etwa ein Schieberegler). Das Problem mit der Barrierefreiheit ist, dass Screenreader bislang keine Möglichkeit haben festzustellen, welche Funktionalität diese Elemente besitzen. Das XHTML role-Attribut füllt diese Lücke, indem es semantischen Zuckerguss hinzufügt:

<ul role="navigation"> […] </ul>

Das stellt ein semantisches, maschinenlesbares role-Attribut zur Verfügung, das ein Browser auf die zugrundeliegende Accessibility API des Betriebssystems mappen kann. Das Attribut verleiht dem Element semantische Informationen, die von Maschinen und Menschen im Quellcode gelesen werden können. Assistive Technologien wie Screenreader können aufgrund dieser Informationen das Element korrekt interpretieren.

Rollen gibt es in zwei Geschmacksrichtungen: XHTML und WAI-ARIA. Ein Basisset ist im XHTML 1.1 Role Attribute Modul definiert. Es wird erweitert durch die WAI ARIA-Role RDF Taxonomie. WAI ARIA-Rollen haben das wairole Präfix, wie in role="wairole:slider".

Rollen werden darüber hinaus unterschieden in Widgets und strukturelle Rollen. Widget-Rollen beinhalten progressbar, slider, button, tree, textfield, checkbox, alert oder dialog. Wenn man also lieber einen Layer anstelle einer schnöden Dialogbox verwenden möchte, kann man das dem Screenreader über role="dialog" mitteilen. Weitere Beispiele für Widgets bietet mozilla.org.

Gängige strukturelle Rollen beinhalten main, secondary, group, section, liveregion (in der Inhalte durch AJAX oder vergleichbare Techniken verändert werden), tab, navigation, menubar, toolbar, breadcrumbs, search, oder banner.

Bedeutung schaffen

Das role Attribut vermittelt Informationen, was das Objekt ist. Das States and Properties Modul (ARIA-State) fügt Bedeutung hinzu, schafft Beziehungen zwischen Objekten und vermittelt ihren aktuellen Status:

<input type="text" name="email" aaa:required="true" />

<div role="wairole:button" aaa:controls="price">Sortierung ändern</div> <h2 id="price" aaa:sort="descending">price</h2>

Andere Status umfassen checked, disabled, expanded, haspopup, invalid, readonly, describedby und labelledby, den level eines Elements in einer Baumstruktur, valuenow, valuemin und valuemax eines Schiebereglers, oder ob ein Menüpunkt gerade aktiv ist.

Wo bin ich?

Assistive Technologien müssen wissen, mit welchem Objekt sie gerade arbeiten und welches Element den Fokus hat. Derzeit können nur Links und Formular-Elemente den Fokus bekommen. ARIA-State erweitert gängige Textcontainer um das tabindex Attribut, so dass der Fokus entweder durch Scripting oder durch die Tabulatortaste gesetzt werden kann.

Derzeit kann beispielsweise eine editierbare Überschrift bei flickr nur den Fokus erlangen, wenn man mit der Maus darauf klickt. Mit tabindex="0" würde es zugänglich per Tastatur.

Außerdem kann der Wert nun negativ sein. Elemente mit einem negativen Tabindex können den Fokus per JavaScript erhalten, werden aber in der Tabulator-Reihenfolge ausgelassen. Dieses Feature wurde von Microsoft im Internet Explorer 5.01 eingeführt und ist in Firefox ab Version 1.5 implementiert.

Zur Auffrischung eine Tabelle mit den Werten und dem Browserverhalten von tabindex:

fokusierbarTab navigierbarkein tabindexGrundeinstellung (nur Formular-Elemente und Links)Grundeinstellungtabindex="-1"JaNein, Autoren müssen element.focus() für den onkeydown-Event von Pfeil- und anderen Tasten programmierentabindex="0"JaJa, in der Reihenfolge, in der die Elemente im Quellcode auftauchenpositiv, z.B. tabindex="100"JaJa, der tabindex bestimmt die Tabulator-Reihenfolge der Elemente. Diese Elemente erhalten den Fokus vor allen anderen Elementen mit tabindex="0" oder ohne tabindex.

Anwendung

Das ist ja schön und gut, aber müssen wir jetzt nochmal zehn Jahre warten, bis andere Browser diese Techniken unterstützen? Nicht wirklich. Man kann Roles, States und Properties sofort einsetzen. Zwar werden sie derzeit lediglich von Firefox 1.5 und späteren Versionen sowie drei großen Screenreadern unterstützt (Window Eyes 5.5+, Jaws 7.0+, ZoomText), aber die zusätzlichen Attribute tun den anderen Browsern nicht weh.

Einige der neuen Attribute sind schon in XHTML 2 enthalten, XHTML 1.x müssen wir aber erweitern. Es gibt drei Wege, die Attribute dranzudübeln:

1. XML Schema Namespaces
2. DOM Scripting
3. DTD Erweiterung

XML Schema Namespaces

Die gängigste Methode, XHTML zu erweitern, ist durch Namespaces. Das ist ziemlich einfach:

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/ » GUIRoleTaxonomy#" xmlns:x2="http://www.w3.org/2002/06/xhtml2" xmlns:aaa="http://www.w3.org/2005/07/aaa">

Firefox 2.0 erkennt bereits das role-Attribut, darum muss man es nicht unbedingt über den XHTML 2 Namespace einbringen (Zeile 3), aber ich würde es zur Rückwärtskompatibilität beibehalten.

Beachte den irreführenden historischen Namen für das States & Properties Modul: hier steht aaa nicht für maximale Barrierefreiheit gemäß Web Content Accessibility Guidelines, sondern für „Accessible Adaptable Applications“, später bekannt als „Accessible Rich Internet Applications“ (ARIA).

Leider wirft der W3C Validator einen Fehler aus, sobald man Namespaces hinzufügt. Warum ist das so? In XHTML 1.0 besitzt das xmlns-Attribut einen festen (fixed) Datentyp und ist definiert

mit dem Wert www.w3.org/1999/xhtml. Punkt. Ohne Ausnahme. In XHTML 1.1 sollte es eigentlich funktionieren, trotzdem gibt es einen Fehler im Validator.

Vorteil: einfach zu implementieren.

Nachteil: validiert nicht als XHTML 1.0

DOM Scripting

HTML 4 unterstützt keine Namespaces, um Attribute zu erweitern. DOM 2 allerdings unterstützt Namespaces, selbst in HTML 4. Also können wir DOM Scripting verwenden, um Rollen, Status und Eigenschaften hinzuzufügen.

Bei diesem Workaround werden Rollen- und Status-Informationen im class-Attribut eingebettet. IBM hat eine gut dokumentierte JavaScript Bibliothek veröffentlicht, um das class-Attribut in entsprechende Attribute im Namespace des Elements umzuwandeln. axs wird als Trennzeichen erkannt, gefolgt von der Rolle und nachfolgenden State-Property Paaren.

<body> <div id="slider" class="myslider myselector2 axs slider » valuemin-0 valuemax-50 valuenow-33" tabindex="0"></div> <script type="text/javascript" src="enable.js"></script> <script type="text/javascript">initApp();</script> </body>

Vorteile: Progressive Enhancement; der einzige Weg, Rollen und Status in HTML 4 zu implementieren.

Nachteile: funktioniert nur mit JavaScript (7.4 KB); jedes Element kann nur mit einer einzigen Rolle versehen werden, nicht mit mehreren; unterstützt ausschließlich Werte der WAI ARIA-Role and ARIA-State Taxonomie; der generische Funktionsname ohne Object Literal Notation kann zu Konflikten mit anderen initApp Funktionen gleichen Namens führen.

DTD Erweiterung

Wir wissen alle, dass XHTML 1.1 modular und erweiterbar ist, aber nur ein paar Über-Geeks scheinen zu wissen, wie man die DTD erweitert (glücklicherweise gibt es Validatoren, um eigene DTDs zu debuggen). Zuerst wird das Role Attribute Modul geladen, dann erweitert man Common Elemente mit dem role-Attribut, und schließlich lädt man das States and Properties Modul mit dem XHTML 1.1 Treiber. Hier eine Beispiel-DTD.

Die angepasste DTD wird wie üblich eingebaut. Man muss nur den URI-Pfad und seinen eigenen Namen als pflegende Instanz anpassen („BlueMars“ in dem Beispiel):

<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//BlueMars//DTD XHTML 1.1 for » Accessible Adaptable Applications with Role Attribute 1.0//EN" » "

learningtheworld.eu/dtd/xhtml-role-state.dtd

"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

Dann müssen wir noch die WAI ARIA-Role Taxonomie einbringen. Wenn man Namespaces vermeiden möchte, geht das auch über ein link Element im head:

<link rel="meta" href="http://www.w3.org/2005/01/wai-rdf/ » GUIRoleTaxonomy#" type="application/rdf+xml" » title="WAI ARIA-Role Taxonomy" />

Ich möchte hier nicht die alte MIME-Type Debatte aufgreifen, aber wenn man sich dafür entscheidet, seine Seiten mit dem XHTML MIME-Type auszuliefern, sollte man HTML Entities vermeiden. Browser wie Firefox laden nicht die DTD. Stattdessen prüfen sie den DTD URI auf bekannte Zeichenketten, und wenn sie etwas wiedererkennen, dann bekommt man XHTML in seiner ganzen Pracht. Anderenfalls ist es bloß XML. Leider sind die einzigen bekannten Entities in XML &lt;, &gt;, &amp; und &quot;, alle anderen verursachen Fehler. Verwende stattdessen Numerische Character References (NCR):   wird also zu &#160; etc. (Ich verwende ein PHP-Script zur Übersetzung.)

Die Bündelung von ARIA-State mit dem XHTML-Treiber ist keine schlechte Idee, aber auch inkonsistent mit der Funktionsweise aller anderen Module, die einzeln angeboten werden. Es kompliziert zudem die Implementierung von XHTML-Role zusammen mit ARIA-State. Hingegen ist es relativ einfach, eine eigene, validierende DTD nur für das role-Attribut zu erstellen. Ich bin jedoch zuversichtlich, dass diese Probleme bis zum Status der Candidate Recommendation gelöst werden können, da die W3C Protocols and Formats Working Group recht aufgeschlossen gegenüber Anregungen ist.

Vorteile: validiert einfach mit XHTML Role; validiert mit ein paar Anpassungen von ARIA-State

Nachteile: zum Zeitpunkt dieses Artikels noch übermäßig kompliziert; nur eine Option mit XHTML 1.1.

Schlussbemerkung

Ob man gleich beginnt, mit den neuen Attributen zu experimentieren oder wartet, bis die Entwürfe Standard werden: Jetzt ist die Gelegenheit, sich damit zu befassen und sich darauf einzustellen. Tatsächlich ist es so früh, dass man noch die Implementierung der Erweiterungen mitgestalten kann:

Firefox stellt diese Rollen zur Orientierung von assistiven Technologien zur Verfügung, und sie befinden sich im DOM. Während derzeit noch keine der assistiven Technologien irgendetwas mit den Rollen anfängt, wäre es doch möglich. Wir haben derzeit keine Pläne, irgendetwas damit in Gecko / Firefox zu machen, aber wir sind offen für Ideen. Wenn du eine solide Idee hast, was wir mit Rollen machen sollen, erstelle bitte einen RFE (Request For Enhancement) Bug auf bugzilla.mozilla.org, Product = Core, Component = Disability Access.

Aaron Leventhal (IBM / Mozilla)

Übersetzung mit freundlicher Genehmigung des A List Apart Magazins.

Weiterführende Literatur

• Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)
• XHTML Role Attribute Module
• Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)
• States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties)
• Accessible DHTML
• Authoring Tips for Key-Navigable Custom DHTML Widgets
• Embedding Accessibility Role and State Metadata in HTML Documents