Webkrauts

ARIA 1.0, HTML5 und der Weg zur Barrierefreiheit

Ein Attribut für eine Live-Region

Es ist im barrierefreien Webdesign wichtig, dass Nutzer dynamische Veränderungen wahrnehmen können. Am Bildschirm gibt es dafür genügend Möglichkeiten, die Veränderungen zu verdeutlichen. Screenreadernutzer stehen hier gleich vor zwei Problemen, die aber beide mit einem einzigen Attribut gelöst werden können.

Wenn Screenreadernutzer z.B. in einem Formular Eingaben vornehmen und an anderer Stelle der Seite Fehlerhinweise oder andere, damit zusammenhängende Informationen angezeigt werden, erfahren sie diese Information normalerweise nicht, weil der Tastaturfokus nicht dort steht. Dabei geht es um zwei Probleme: Zum einen muss der Screenreader erfahren, dass sich überhaupt etwas auf der Seite geändert hat, und zum anderen sollte die Information für Screenreadernutzer zugänglich sein, ohne dass sie die komplette Seite lesen müssen. Abhilfe verschafft das aria-live-Attribut.

HTML bietet Webentwicklern kaum die passenden Techniken, dynamische Veränderungen auf Webseiten Screenreadern mitzuteilen. Dieses Problem greift Accessible Rich Internet Applications (ARIA) 1.0 mit der Einführung von vier Attributen für Live-Regionen auf:

• aria-live
• aria-relevant
• aria-atomic
• aria-busy

Mit diesen Attributen können Bereiche von Webseiten so gekennzeichnet werden, dass Screenreader über eine Veränderung der Inhalte informiert werden oder auch nicht. Das entscheidende Attribut ist aria-live, mit dem ein Element als Live-Region ausgezeichnet wird.

Als Live-Region wird dabei jede Region einer Webseite verstanden, die

• entweder durch eine Nutzeraktion (z.B. Eingabe)
• oder automatisch (z.B. eine fortlaufende Zeitangabe)

dynamisch aktualisiert wird.

Das Attribut aria-live kann die Werte "off", "polite" oder "assertive" annehmen. Der übliche Wert ist "polite", d.h. der Screenreader teilt dem Nutzer die Aktualisierung mit, wenn eine Tätigkeit beendet (z.B. Lesen oder Tippen) wurde. Bei Verwendung von "assertive" informiert der Screenreader den Nutzer sofort und unterbricht beispielsweise das Lesen. Der Wert "off" deaktiviert die automatische Benachrichtigung.

Die Attribute für Live-Regionen können einem beliebigen Element zugewiesen werden, in dem Aktualisierungen stattfinden, z.B.

Außerdem können mehrere Live-Regionen auf einer Webseite vorkommen.

Zusätzliche Attribute für Live-Regionen

Für das Fine-Tuning einer Live-Region gibt es drei Attribute. Außerdem können (und sollen) zusätzliche Attribute für die Tastaturbedienung oder zur Bezeichnung der Komponenten genutzt werden.

Mit folgenden Attributen steuert ihr, welche Aktualisierungen mitgeteilt werden:

• Das Attribut aria-relevant kann die Werte additions, removals, text, all oder eine Kombination der Werte annehmen.

  Nicht alle Änderungen in einer Live-Region sind wichtig für den Nutzer; meist sind nur neue Inhalte relevant. Dabei kann die Ausgabe hinzugefügter Inhalte auf veränderte Textknoten (aria-relevant="text") oder auf hinzugefügte Knoten (aria-relevant="additions") beschränkt werden. Der Standardwert ist aria-relevant="additions text".

  Das Entfernen von Knoten aus der Live-Region kann mit aria-relevant="removals" ebenfalls protokolliert werden und mit aria-relevant="all" können alle Aktualisierungen an Screenreader weitergegeben werden.

  Die Werte "removals" und "all" sollten nur eingesetzt werden, wenn das Entfernen eines Textes für den Nutzer wirklich wichtig ist. Abgesehen davon funktionieren diese Werte nicht im Internet Explorer und nicht gut in Firefox.

• Das Attribut aria-atomic kann die Werte false oder true annehmen.

  Manche Aktualisierungen sind nur in einem Kontext gut nachvollziehbar. Wenn in einer Live-Region ein Fußballergebnis auf »7:1« aktualisiert wird, dann sollten die Mannschaften ebenfalls ausgegeben werden. Erhält eine Live-Region das Attribut aria-atomic="true", wird bei jeder Aktualisierung die komplette Live-Region mitgeteilt. Mit aria-atomic="false" wird die Mitteilung über Aktualisierung auf die Inhalte beschränkt, die mit aria-relevant vorgegeben werden.

• aria-busy kann ebenfalls die Werte false und true annehmen.

  Normalerweise werden Aktualisierungen in einer Live-Region unmittelbar ausgegeben. Manchmal entstehen aber längere Ladevorgänge oder Berechnungszeiten und die Inhalte der Live-Region sollen erst dann ausgegeben werden, wenn alle Inhalte verfügbar sind. Für solche Fälle ist aria-busy="true" vorgesehen, wodurch die Mitteilungen an Screenreader unterlassen werden, bis aria-busy="false" gesetzt wird; dann erst sollten die gesammelten Aktualisierungen zusammenhängend ausgegeben werden. Derzeit wird das jedoch weder unter Internet Explorer 11 noch Firefox 33 unterstützt (JAWS 15/NVDA 2014.3).

Ein weiteres für Live-Regionen sinnvolles Attribut ist aria-controls. Wenn Aktualisierungen einer Live-Region durch Nutzereingaben bewirkt werden, dann sollte das Steuerelement das Attribut erhalten:

Mit aria-controls="[id]" erhalten Screenreadernutzer die Möglichkeit, direkt zu einem »kontrollierten« Element zu springen. In diesem Fall wird ein Steuerelement genutzt, um irgendetwas zu tun und das Ergebnis wird in einer Live-Region angezeigt. Weil die Aktualisierung der Live-Region nur einmal vom Screenreader vorgelesen wird und der Nutzer diese Information möglicherweise nochmal lesen muss, kann der direkte Sprung zur Live-Region sinnvoll sein. Allerdings ist die Unterstützung (auf Windows-Systemen) auf die Kombination des Screenreaders JAWS mit dem Browser Firefox beschränkt. Kontrolliert eine Komponente einen anderen Inhalt, kann bei dieser Browser-Screenreader-Kombination über JAWS+Alt+M direkt zum Inhalt gesprungen werden.

Ferner benötigen Live-Regionen eine Bezeichnung. Die semantische Kennzeichnung von Inhalten erfolgt normalerweise durch die Verwendung entsprechender HTML-Elemente (z.B. Überschriften) oder ARIA-Rollen (siehe unten). Mit ARIA stehen außerdem die Attribute aria-labelledby, aria-label und aria-describedby zur Verfügung.

ARIA-Rollen und HTML-Elemente

In der ARIA-Spezifikation wurden zahlreiche Rollen definiert, um vor allem komplexe Widgets semantisch zu identifizieren und in einigen Fällen das Verhalten zu bestimmen. Einige Rollen schließen die Semantik und Verhalten von Live-Regionen ein. Außerdem sind einige Rollen der ARIA-Spezifikation auch in der HTML5-Spezifikation zu finden.

Zunächst sei auf die fünf Regeln für ARIA hingewiesen. Die erste Regel lautet, dass wenn ein natives HTML-Element oder ein HTML-Attribut eine passende Semantik und ein passendes Verhalten bieten, dann ist HTML statt ARIA einzusetzen.

Des Weiteren sei auf die vordefinierten Rollen in ARIA 1.0 hingewiesen. Im roles-Modell werden einige Rollen spezifiziert, die bereits als Live-Region dienen.

Vordefinierte Live-Regionen

Die ARIA-Spezifikation definiert mehrere Rollen, die ein Browser als Live-Region identifizieren soll. Erhält ein Element eine dieser Rollen

• soll das Verhalten (Ausgabe der Aktualisierungen) vom Browser übernommen werden und
• soll die Live-Region in einem Screenreader identifiziert werden können.

Rollen haben im Übrigen oft keine HTML-Entsprechung. Für zwei der ARIA-Rollen, die Live-Regionen definieren, gibt es allerdings korrelierende HTML5-Elemente.

Wenn Live-Regionen mit den nachstehenden HTML5-Elementen oder den ARIA-Rollen ausgezeichnet werden, dann ist eine explizite Kennzeichnung mit dem aria-live-Attribut nicht erforderlich - so steht es zumindest geschrieben. In der Praxis gibt es noch etwas Nachholbedarf, wie weiter unten verdeutlicht wird (die Angaben beziehen sich auf Firefox 33/Internet Explorer 11 mit JAWS 15/NVDA 2014.3).

role="alert"

Diese Rolle ist für eingeblendete (und nicht fokussierte) Inhalte gedacht, die nur für eine bestimmte Zeit angezeigt werden und wichtige Informationen für den Nutzer enthalten (z.B. eine wichtige Benachrichtigung, dass eine Session gleich abläuft). Der Browser sollte bei dieser Rolle die Eigenschaften aria-live="assertive" und aria-atomic="true" an die Accessibility-API des Betriebssystems übertragen.

Hinweis: Unterstützung ist in Firefox gegeben, aber nicht im Internet Explorer. Für Internet Explorer müssen aria-live und aria-atomic explizit gesetzt werden.

Hinweis: Wenn die eingeblendeten Inhalte fokussiert werden sollen (z.B. weil die Inhalte durch einen Button geschlossen werden müssen), handelt es sich nicht um eine Live-Region und es ist z.B. role="alertdialog" einzusetzen.

role="log"

role="log" ist für protokollartige Inhalte vorgesehen, d.h. Inhalte, die nach und nach eingeblendet werden, während ältere Inhalte ausgeblendet werden (z.B. ein Chat).

Ergänzt werden sollte sie mit aria-live="polite". Unterstützung ist in Firefox gegeben, aber nicht im Internet Explorer. Für Internet Explorer muss aria-live explizit gesetzt werden.

role="marquee"

Mit role="marquee" werden für durchlaufende, für den Nutzer nicht essentielle Inhalte geboten (z.B. scrollender Text in einem Ticker). Hier sollte eine aria-live="off"-Eigenschaft ergänzt werden, damit diese Inhalte nicht störend in den Vordergrund geschoben werden.

role="progressbar" (= HTML-Element <progress>)

Interessant ist role="progressbar" für Bereiche mit wechselnden Inhalten, die den Status einer länger andauernden Aufgabe anzeigen (z.B. ein Fortschrittsbalken). aria-live="polite" sollte automatisch vom Browser gesetzt werden.

Hinweis: Mit <progress> werden Angaben korrekt weitergegeben, allerdings ist das nicht immer »elegant«. Autoren müssen für die Rolle die Attribute aria-valuemin, aria-valuenow und aria-valuemax setzen.

role="status"(= = HTML-Element <output>)

Für Bereiche mit wechselnden Inhalten, die durch die Ergebnisse von Nutzeraktionen aktualisiert werden (z.B. eine Statuszeile oder die Ergebnisse einer Berechnung) wird die Rolle status verwendet. Für ein bessers Handling sollten aria-live="polite" und aria-atomic="true" ergänzt werden.

Hinweis: Für <output> ist Unterstützung in Firefox gegeben, aber nicht im Internet Explorer. Für Internet Explorer müssen aria-live und aria-atomic explizit gesetzt werden.

role="timer"

Für Bereiche mit wechselnden Inhalten, die die verstrichene oder verbleibende Zeit darstellen (z.B. die verbleibende Zeit in einer Auktion) kann die Rolle timer eingesetzt werden. Diese sollte, wie die Rolle marquee, mit aria-live="off" ergänzt werden.

Die Rollen sind bislang in aktuellen Browser-Screenreader-Kombinationen oft nicht vollständig implementiert, d.h. in Screenreadern werden Live-Regionen i.d.R. semantisch nicht identifiziert und dynamische Veränderungen werden sehr unterschiedlich ausgegeben. Folglich müssen ARIA-Attribute wie aria-live zur Erzielung einer maximalen Kompatibilität mit Screenreadern nach wie vor eingesetzt werden:

Lediglich Live-Regionen, die die Rolle "log" besitzen, werden überall semantisch identifiziert. Das gilt auch für Fortschrittsbalken mit <progress>.

Das HTML5-Element <output> soll von Browsern noch mit der Rolle "status" ausgestattet werden – allerdings konnte das bislang nur in keinem Browser erfolgreich getestet werden. Wenn das Element zusätzlich das Attribut aria-live="polite" erhält, dann werden die aktualisierten Inhalte zuverlässiger von Screenreadern erfasst:

Auch das <progress> Element besitzt eine Rolle für eine Live-Region: role="progressbar". Die Zugänglichkeitsunterstützung ist bei diesem Element etwas besser als bei <output>, aber mit aria-live="polite" funktioniert es auch hier besser:

Auch wenn ARIA und HTML5 seit diesem Jahr W3C-Webstandards sind, gibt es noch Lücken in der Kompatibilität.

Konsequenzen

Es gilt immer die folgende Vorgehensweise:

1. Wenn die Live-Region ein Statusbereich oder ein Fortschrittsbalken ist, dann sind die HTML5-Elemente <output> und <progress> einzusetzen. ARIA-Attribute können für <progress> als obsolet angesehen werden, nicht aber für <output>.
2. Wenn die Live-Region semantisch mit einer der Rollen "alert", "log", "marquee" oder "timer" richtig identifiziert werden kann, dann muss die Live-Region die passende Rolle erhalten. Dies reichert die Live-Region semantisch an (z.B. ein Alert wird im Internet Explorer und dem Screenreader JAWS als »Hinweis« identifiziert).
3. Live-Regionen mit ARIA benötigen immer ein aria-live-Attribut. Gegebenenfalls müssen sie zusätzlich mit aria-atomic und aria-relevant ausgezeichnet werden. aria-busy wird derzeit in den getesteten Browser-Screenreader-Kombinationen nicht unterstützt.

Links

• In der HTML5-Spezifikation steht, welche ARIA-Rollen ein Element unterstützt etwa für <output> und <progress>.
• Wie gut HTML-Elemente in Browsern und Screenreadern unterstützt werden, könnt ihr auf www.html5accessibility.com nachlesen.
• Auf der Seite Using WAI-ARIA in HTML stehen die Grundregeln für ARIA sowie die Angabe, ob HTML5-Elemente mit ARIA ergänzt werden müssen oder nicht.
• Weitere Hinweise auf deutsch zum barrierefreien Einsatz von Live-Regionen werden im Artikel Alive and Kicking gegeben.