Barrierefreies Webdesign ein zugängliches und nutzbares Internet gestalten

ARIA und die Accessibility-API veröffentlicht in 2002zuletzt bearbeitet in

ARIA ist Silber, HTML ist Gold

Screenreader und andere Hilfsmittel stehen vor großen Herausforderungen, wenn es um die Bedienung von grafischen Benutzungsoberflächen geht. Anbieter von Betriebssystemen und Anwendungen begegneten diesem Problem dadurch, dass sie Schnittstellen entworfen haben, um heuristische Verfahren zu vermeiden. Solche Schnittstellen heißen Microsoft Active Accessibility (Windows), AT-SPI (Linux) oder Apple Accessibility Toolkit (OS X und iOS). Solche Schnittstellen ermöglichen es Anwendungen wie Browser eine Accessibility-Tree zu erstellen, auf den ein Screenreader oder andere Hilfsmittel zugreifen können.

Der Accessibility-Tree erhält eine große Bedeutung für die Webentwicklung, wenn auf Webseiten Komponenten eingesetzt werden, die mit HTML nicht abgebildet werden können. Damit der Accessibility-Tree vom Browser korrekt befüllt werden kann, muss

Es versteht sich, dass die dritte Variante überflüssig sein sollte. Bevor HTML mit ARIA repariert wird, sollte versucht werden, HTML richtig einzusetzen.

HTML-Elemente

Es kann nicht oft genug betont werden, dass HTML bevorzugt einzusetzen ist. Anstatt:

<span class="button" onclick="tuewas();"></span>

sollte das BUTTON-Element eingesetzt werden. Das gleiche gilt für alle weiteren Formularelemente, Links, Überschriften, Tabellen und sonstige Elemente, für die HTML eine Semantik bietet.

Semantische Rollen, Zustände und Eigenschaften von Komponenten werden von Browsern in den Accessibility-Tree übertragen. Ein einfacher Link

<a href="seite.html">Linktext</a>

sieht in dem Accessibility-Tree von Windows wie folgt aus:

Screenshot des Accessibility Viewers Untersuchung des Accessibility Tree mit Aviewer

Screenreader identifizieren den Link anhand der Rolle und des Namens; ein Link ist außerdem per Tastatur zugänglich. Die Übertragung der semantischen Informationen über HTML-Elemente an den Accessibility-Tree durch die Browser ist unproblematisch ebenso wie die "Abholung" durch Screenreader. Sollten Screenreader die Informationen nicht direkt aus dem Accessibility-Tree verwerten, so stützen sie sich sehr wahrscheinlich noch auf das Document Object Model (DOM).

Bei Elementen, die mit HTML5 neu spezifiziert wurden, ist die Situation nicht ganz so eindeutig:

Wenn die Semantik von HTML5-Elementen nicht an den Accessibility-Tree übertragen wird, kann eine zusätzliche ARIA-Rolle helfen, z.B.:

<main role="main"> ... </main>

In der Regel werden die Rollen aus der ARIA-Spezifikation von Browsern gut unterstützt und vor allem Screenreader können die Informationen verwerten. Beim W3C stehen Hinweise, Extern, englischsprachig: wann welches HTML-Element mit einer expliziten Rolle ergänzt werden sollte und wann darauf verzichtet werden kann.

Zum Verständnis: Viele Dinge der Semantik in HTML5 sind aufgrund der ARIA-Spezifikation entstanden. Browser haben dabei die ARIA-Attribute oft unterstützt, bevor sie die Semantik der HTML5-Elemente unterstützten.

ARIA-Rollen und Attribute

Die ARIA-Spezifikation definiert zahlreiche Rollen sowie Eigenschaften und Zustände. Die Rollen lassen sich unterteilen in

Es gibt darüber hinaus auch abstract roles, die aber für die Webentwicklung nicht vorgesehen sind. Vielmehr dienen die abstract roles der Ontologie im Browser.

Obwohl ARIA vielen Zwecken dient, so sind insbesondere die widget roles auf dynamischen Webseiten unersetzbar. Mit widget roles können komplexere Komponenten der Benutzungsschnittstelle so identifiziert werden, dass Hilfsmittel sie wie standardisierte Komponenten des Betriebssystems aufbereiten können. Die widget roles können genutzt werden beispielsweise für

ARIA bietet dabei keinerlei Funktionalität. Wenn solche Komponenten auf einer Webseite mit ARIA semantisch angereichert werden, dann müssen sie mit JavaScript bedienbar gemacht und mit CSS gestaltet werden. Beispielsweise ist

<span role="link"> ... </span>

in dem Accessibility-Tree zwar ein Link, aber das Element muss noch per Tastatur bedienbar gemacht werden. Mit den ARIA-Attributen wird lediglich die Semantik beigefügt.

Für einige Rollen gibt es keine Entsprechung in HTML. In solchen Fällen kommt ARIA zum Einsatz, z.B.:

Und so kann die Liste beliebig fortgesetzt werden. Eine Baumnavigation muss mit role="tree" als Baumnavigation identifiziert werden, damit Nutzer wissen, dass eine Bedienung mit Pfeiltasten vorgesehen ist, und natürlich muss dabei der selektierte Eintrag gekennzeichnet werden. Benachrichtigungen über Veränderungen in Live-Regions können mit ARIA so gesteuert werden, dass Screenreadernutzer sofort, bei der nächsten Unterbrechung oder gar nicht informiert werden. Bei den meisten Komponenten handelt es sich um das Setzen von wenigen Attributen, die zur Folge haben, dass der Accessibility-Tree vom Browser mit wichtigen Daten für Screenreader gefüllt und aktualisiert werden kann.

ARIA als Reparaturtechnik

Oft gibt es Missverständnisse über den Zweck von ARIA. ARIA beeinflusst weder Gestaltung noch Funktionalität im Browser. ARIA dient dem Zweck, dass Hilfsmittel Komponenten mit ihren Zuständen und Eigenschaften in dem Accessibility-Tree erfassen können und dass Screenreader und andere Hilfsmittel ein erweitertes Bedienkonzept für den Nutzer bereitstellen können.

Einige Rollen bewirken das Gleiche wie HTML-Elemente. Sofern es sich um Komponenten handelt, die erst mit HTML5 eingeführt wurden, sind die Hinweise und Links weiter oben zu beachten. In allen anderen Fällen ist das HTML ausnahmslos bevorzugt einzusetzen.

Wenn ARIA als Reparaturtechnik eingesetzt wird, treten eventuell verschiedene Probleme mit der Zugänglichkeit auf:

  1. ARIA definiert die Semantik neu, aber nicht das Verhalten. Beispielsweise sind Links und Formularelemente in HTML bereits mit der Tastatur bedienbar, aber nicht wenn sie mit ARIA die entsprechende Rolle erhalten haben.
  2. Der Einsatz von ARIA erfordert unterschiedliche Attribute. Über diese Kenntnisse muss die Webentwicklung verfügen.
  3. Die Korrektheit der Auszeichnung muss im Accessibility-Tree (und nicht etwa im DOM) überprüft werden. Es ist zwar keine große Sache, den Accessibility-Tree zu prüfen, aber mit korrektem HTML entfällt dieser Schritt.
  4. Auch wenn der Accessibility-Tree korrekt ausgefüllt ist, ist noch nicht in jeder Situation klar, ob Hilfsmittel die Daten korrekt auswerten. Es müssen Überprüfungen mit verschiedenen Hilfsmitteln auf verschiedenen Browsern auf diverse Betriebssysteme durchgeführt werden.

Es gibt also gute Gründe, HTML von vornherein richtig einzusetzen. Die korrekte Semantik im HTML fördert die Barrierefreiheit und reduziert den Aufwand für die Überprüfung.

Zu solchen offensichtlichen Problemen kommt beim Einsatz von ARIA hinzu, dass es unterschiedliche Ergebnisse geben kann, je nachdem, welcher Browser und welcher Screenreader eingesetzt wird. Auf Windows-Systemen funktioniert JAWS meist besser mit dem Internet Explorer und der Screenreader NVDA funktioniert besser mit Firefox, weil unterschiedliche Accessibility-APIs eingesetzt werden. Deshalb kann es sein, dass eine bestimmte Komponente mit JAWS gut im Internet Explorer funktioniert, aber in Firefox und Chrome nicht. Solche Probleme tauchen eher bei komplexeren Widgets auf (z.B. in Baumnavigationen oder Menüs).

Problematisch ist es auch, wenn zwar semantische HTML-Elemente eingesetzt werden, aber diese eine inkorrekte Semantik aufweisen. Ein Beispiel sind Links, die visuell und funktional als Schaltflächen genutzt werden. Wenn ein einfacher Link

<a href="javascript:tuewas();">Linktext</a>

als Schaltfläche genutzt wird, so könnte ARIA wie folgt eingesetzt werden:

<a role="button" href="javascript:tuewas();">Linktext</a>

Im Accessibility-Tree ist dieser Inhalt jetzt eine Schaltfläche, die im Prinzip so aussieht:

<button href="javascript:tuewas();">Linktext</button>

In Worten ausgedrückt ist das eine verlinkte Schaltfläche.

Der Screenreader ermöglicht es dem Nutzer, das Element mit den Tasten anzusteuern, die für das Anspringen von Formularelementen vorgesehen sind. Im Screenreader JAWS sind das beispielsweise die Tasten F für das nächste Formularelement und B für die nächste Schaltfläche.

Darstellung des Accessibility-Trees mit einer Schaltflächenrolle und mit einer Verknüpfung

Obwohl dieses konkrete Beispiel keine Probleme machen wird, weil sowohl Link als auch Schaltfläche mit den gleichen Events ausgelöst werden, so gibt es in der Praxis doch häufiger erhebliche Probleme. Oft sind es nicht Links, die als Schaltflächen genutzt werden, sondern SPAN-Elemente:

<span role="button" onclick="tuewas();>Linktext</span>

Auch dieser Inhalt ist im Accessibility-Tree eine Schaltfläche und kann mit den Screenreaderbefehlen angesprungen werden, und durch Drücken der Eingabe- oder Leertaste kann sogar die Funktion tuewas() ausgelöst werden, aber im DOM ist der Inhalt lediglich ein Text ohne Funktionalität. Für Tastaturnutzer bzw. durch Betätigen der Tabulatorentaste ist der Inhalt nicht zugänglich und somit nicht barrierefrei. Es ist in diesen beiden Fällen besser, wenn von vorneherein das semantisch richtige BUTTON-Element für die Auszeichnung eingesetzt wird und auf ARIA verzichtet wird.

Zusammengefasst: ARIA nur im Bedarfsfall einsetzen

Normalerweise ist es Aufgabe des Browsers, den Accessibility-Tree zu füllen, aber wenn die erforderliche Semantik auf der Webseite fehlt, muss ARIA zum Einsatz kommen:

ARIA ist eine Ergänzungstechnik. Für viele Situationen sind die ARIA-Attribute redundant und mir fällt keine Situation ein, in der es einfacher wäre, aus einem

<span>Linktext</span>

ein

<span role="link" tabindex="0">Linktext</span>

als ein

<a href="seite.html">Linktext</a>

zu machen. Eine Korrektur mit ARIA ist zwar besser als gar keine Anpassung, aber HTML ist rückwärtskompatibel. ARIA dient vor allem dem Zweck, die Lücke zwischen dem, was mit JavaScript funktional dargestellt wird, und dem, was Nutzer vom Betriebssystem kennen, zu schließen. Es sollte vermieden werden, ARIA als Reparaturtechnik einzusetzen, wenn HTML die erforderliche Semantik bereits bietet.