ARIA und die Accessibility-API veröffentlicht in 2002/2015

Die Barrierefreiheit einer Anwendung ist davon abhängig, wie sie über eine Accessibility-API den Accessibility-Tree mit Informationen befüllt. Das gilt unabhängig von der Plattform oder der Programmiersprache und ebenso gilt das für beliebige Anwendungen — sei es ein Browser oder eine andere Anwendung.

Damit es keine Missverständnisse gibt: Barrierefreiheit beschränkt sich keinesfalls alleine auf die technische Zugänglichkeit einer Anwendung und wie der Accessibility-Tree zusammengestellt wird. Die Barrierefreiheit ist im Kontext eines Accessibility-Trees allerdings auf den technischen Zugriff beschränkt, d.h. es geht dabei um Hilfsmittel wie Screenreader, Vergrößerungssysteme oder Spracheingaben, die auf die Schnittstelle des Betriebssystems für Barrierefreiheit angewiesen sind. Insbesondere geht es dabei um die Übertragung von Intern: Name, Rolle und Wert der Komponenten auf einer Website in den Accessibility-Tree.

Accessibility-API

Für die verschiedenen Betriebssysteme existieren unterschiedliche Accessibility-APIs. Diese umfassen beispielsweise Extern, englischsprachig: Microsoft Active Accessibility (MSAA) mit entweder UIA oder IAccessible2 auf Windows, Extern, englischsprachig: Linux Accessibility Toolkit und Extern, englischsprachig: Assistive Technology - Service Provider Interface auf Linux oder Extern, englischsprachig: Mac OS X Accessibility Protocol auf OS X und iOS. Nicht zu verschweigen ist auch die Java Accessibility API — immerhin ist Java mittlerweile die wichtigste Sprache für Fach- und 3-Schicht-Anwendungen.

Die Accessibility-APIs sind zwar keine neue Entwicklung, aber erst in den letzten Jahren wird zunehmend auf die Accessibility-API als primäre Informationsquelle für Hilfsmittel und insbesondere Screenreader gesetzt, wenn es um die Zugänglichkeit von Webseiten geht. Woher Hilfsmittel ihre Informationen tatsächlich erhalten, ist unterschiedlich. Für Inhalte, die im Browser angezeigt werden, gibt es drei grundsätzliche Möglichkeiten:

Screenreader setzen zwar nach wie vor auf das Off screen model, aber die Extern, englischsprachig: Tendenz geht eindeutig zum Accessibility-Tree.

Obwohl die Accessibility-API für verschiedene Hilfsmittel relevant sein kann, so ist sie vor allem für Screenreader entscheidend. Andere Hilfsmittel wie Vergrößerungssysteme und Spracheingaben werden in den folgenden Ausführungen nicht weiter behandelt, zumal sie derzeit (Januar 2015) keine überzeugende Auswertung des Accessibility-Trees aufweisen.

Accessibility-API und Browser

Die Accessibility-APIs waren für die Webentwicklung lange Zeit ein Randthema. Zunächst gab es die Accessibility-API nur auf Windows-Systemen; bereits der Internet Explorer 4 unterstützte Microsoft Active Accessibility (MSAA) unter Windows 95. Mit ungefähr 10 Jahren Verzögerung zog Apple nach und auch Google bietet inzwischen eine funktionierende Accessibility-API für Android.

Als einer der ersten großen Software-Anbieter neben Microsoft begann auch Adobe die MSAA-Schnittstelle zu unterstützen. Der Adobe Reader 5 (2001) läutete den Beginn von tagged PDF ein und Adobe Flash konnte ab der Version 6 (2002) zumindest in Ansätzen zugänglich gestaltet werden. Ob Adobe, Apple, Google oder Oracle, das Konzept des Accessibility-Trees hat sich überall als Bestandteil von Anwendungen durchgesetzt. Inzwischen verfügt jedes Betriebssystem auf Desktop-Rechnern oder mobilen Geräten über eine oder mehrere Accessibility-APIs und die Voraussetzung für barrierefreie Anwendungen ist seitens der Betriebssysteme gegeben.

Bei interaktiven Elementen (Komponenten) wie Formularelemente, Links und Widgets können Hilfsmittel auf den Accessibility-Tree des Betriebssystems zurückgreifen. Allerdings holen Hilfsmittel wie Screenreader weitere Informationen nach wie vor aus dem DOM oder ermitteln sie anhand des Off screen models, um sie für Nutzer aufzubereiten.

Die herkömmlichen Verfahren zur Informationsgewinnung funktionieren aber nicht immer. Für moderne, interaktive Widgets sind die Informationen, die in dem Accessibility-Tree abgelegt werden, entscheidend für die Zugänglichkeit. Damit Semantik und Text korrekt in dem Accessibility-Tree abgelegt werden können, ist ARIA erforderlich. Die Webentwicklung erhält mit ARIA eine unmittelbare Beziehung zur Accessibility-API.

Bedeutung von ARIA

ARIA steht für Accessible Rich Internet Applications und ist ein Extern, englischsprachig: Webstandard des W3C seit Anfang 2014. Mit den ARIA-Attributen können u.a. Komponenten, die in HTML und anderen Auszeichnungssprachen nicht spezifiziert sind, so angereichert werden, dass der Browser damit den Accessibility-Tree sinnvoll befüllen kann.

Auch wenn ARIA viel mehr als ein Satz von Attributen ist, so sind die meisten Anforderungen doch an Hersteller von Browsern und Hilfsmitteln gerichtet. Für die Webentwicklung umfasst ARIA insbesondere das role-Attribut sowie die zahlreichen Zustände und Eigenschaften, die Komponenten zugewiesen werden können. ARIA-Attribute können wie sonstige Attribute in HTML genutzt werden:

Hintergrund insbesondere für den letzten Punkt ist, dass Webseiten oft Komponenten enthalten, die den Desktop-Komponenten nachgeahmt sind. Semantisch handelt es sich aber in der Regel um einfache HTML-Elemente wie Links oder Listen. An dieser Stelle setzt ARIA an und ermöglicht es Webentwicklern, die Semantik einer Liste beispielsweise von "Listeneintrag" in ein "Register" oder die Semantik einer Grafik in ein Kontrollkästchen umzuwandeln. ARIA spezifiziert neben den semantischen Rollen auch semantische Zustände und semantische Eigenschaften, die in vielen Fällen überhaupt nicht in HTML vorgesehen sind.

Beim Einsatz von ARIA darf nicht vergessen werden, dass ARIA zwar die Zugänglichkeit in Hilfsmitteln fördern kann, aber ARIA löst nicht alle Probleme der Barrierefreiheit. Darüber hinaus muss die Webentwicklung verantwortungsvoll mit den ARIA-Attributen umgehen, denn ARIA erlaubt es, das HTML umzudefinieren und zwar ohne die Darstellung oder das Verhalten im Browser zu verändern. Wenn die Resultate nicht überprüft werden, werden mögliche Probleme nicht am Bildschirm oder durch Fehlfunktionen in Erscheinung treten, sondern bestenfalls in einem Screenreader.

Beeinflussung des Accessibility-Trees

Im Folgenden dient ein Kontrollkästchen als Beispiel, um den Accessibility-Tree zu demonstrieren. Wenn eine Checkbox unter dem Windows-Betriebssystem in der Accessibility-Tree analysiert wird, kann festgestellt werden, dass sie dort mit Namen, Eigenschaften und Zuständen dargestellt wird. Im nachstehenden Screenshot befindet sich eine Checkbox mit der Beschriftung "Browserverlauf beim Beenden löschen" in einem Dialogfenster.

Dialogfenster der Windows Internetoptionen mit dem Fokus auf ein Kontrollkästchen

Folgende Attribute können in der Accessibility-Tree angezeigt werden:

  1. Es handelt sich um eine Komponente mit der Rolle "Kontrollkästchen"
  2. Die Bezeichnung (Name) lautet "Browserverlauf beim Beenden löschen".
  3. Weitere Eigenschaften sind "aktiviert", "markierbar" und "gehovert".

Screenshot vom Accessibility-Tree mit den zuvor genannten Angaben Darstellung mit Microsoft Active Accessibility Object Inspector

Genau die gleichen Daten übermittelt der Browser für beschriftete Kontrollkästchen in HTML:

<p><input type="checkbox" checked id="test" />
<label for="test">Browserverlauf beim Beenden löschen</label></p>

Der Browser überträgt im Übrigen nicht zwingend die sichtbare Beschriftung an die Accessibility-Tree, sondern die Bezeichnung (bzw. den Namen) der Komponente. Gibt es keine verknüpfte Beschriftung, liefert der folgende Code ebenfalls das gewünschte Ergebnis an den Accessibility-Tree:

<p>
  <input type="checkbox" checked id="test" title="Browserverlauf beim Beenden löschen" />
</p>

Mit ARIA gibt es auch weitere Möglichkeiten, den Accessibility-Tree mit korrekten Daten zu bestücken:

<p>
  <input type="checkbox" checked id="test" aria-label="Browserverlauf beim Beenden löschen" />
</p>

oder

<p>
  <img src="meinecheckbox.png" role="checkbox" aria-checked="false" alt="Browserverlauf beim Beenden löschen" />
</p>

Hinweis: Obwohl die drei letzten Beispiele den Accessibility-Tree mit den notwendigen Daten bestücken, so sind sie zunächst nur für Screenreader zugänglich, aber nicht notwendigerweise barrierefrei, denn jede Komponente benötigt Intern: eine sichtbare Beschriftung oder Anweisung.

Wenn die HTML-Kontrollkästchen im Accessibility-Tree untersucht werden, kann festgestellt werden, dass die Eigenschaften übereinstimmen und außerdem identisch mit den Eigenschaften des ersten Kontrollkästchens aus der Windows-Systemsteuerung sind. Im Übrigen zeigt das letzte Beispiel, wie Intern: Grafiken mit ARIA eine neue semantische Rolle als Checkbox erhalten können.

Der Accessibility-Tree

Im Fall von Webinhalten, die in einem Browser angezeigt werden, ist der Accessibility-Tree eine Teilmenge des DOM. Der Accessibility-Tree ist eine hierarchische Repräsentation der Benutzungsoberfläche. Grob gesagt werden alle Komponenten aus dem DOM, die für Hilfsmittel zugänglich sein müssen, im Accessibility-Tree parallel aufbereitet.

Die Aktualisierung des Accessibility-Trees ist Aufgabe der Anwendung, also z.B. des Browsers. Genauer gesagt, ermittelt der Browser anhand des DOM, welche Informationen an den Accessibility-Tree weitergegeben werden, und der Screenreader leitet Funktionen und Informationen daraus für den Nutzer ab.

Es gibt Intern: Tools zur Überwachung des Accessibility-Trees, wobei der Accessibility-Tree in verschiedenen Browsern unterschiedlich zusammengesetzt wird — abhängig vom Browser und verwendete Accessibility-API.

Die Webentwicklung hat keinen direkten Zugriff auf den Accessibility-Tree. Sie kann ihn nur beeinflussen durch semantisch richtigen Code und darüber hinaus durch das setzen einiger weiterer Attribute aus der ARIA-Spezifikation.