Ihre Anfrage wurde erfolgreich gesendet, 3 Produkte zum Warenkorb hinzugefügt — solche oder ähnliche Meldungen vermitteln den Erfolg oder das Ergebnis einer Aktion, zeigen den Fortschritt eines Prozesses an oder kommunizieren fehlerhafte Eingaben. Sie sind das Ergebnis von dynamischen Änderungen einer Seite, ohne dass diese neu lädt. Interaktionen von Nutzenden, aber auch externe Ereignisse, können der Auslöser für eine Aktualisierung sein — man denke bei Letzterem an laufend aktualisierte Nachrichten oder Sport-Ergebnisse. Für Menschen, die einen Screenreader nutzen, sind solche Aktualisierungen, die irgendwo auf der Seite passieren, nicht leicht wahrnehmbar — weiterhelfen kann in diesen Fällen die Umsetzung als ARIA-Live-Region …

 

Was sind ARIA-Live-Regionen?

Sehende Menschen nehmen neue, dynamisch aktualisierte Informationen meist über das periphere Sehen war, also eher nebenbei. Menschen, die eine Webseite nicht visuell nutzen, steht dieses Wahrnehmungsprinzip nicht in gleicher Weise zur Verfügung, denn der Fokus der assistiven Technologie kann sich immer nur auf einem Element befinden. Liegt der Fokus eines Screenreaders auf einer Schaltfläche, kann er also nicht gleichzeitig bei einer Meldung an anderer Stelle sein. Der Screenreader bekommt demnach nicht ohne Weiteres die dynamisch eingeblendete Mitteilung mit, sie kann leicht verpasst werden.

In dieser Situation kann der Einsatz von WAI-ARIA-Attributen für eine ähnliche Erfahrung wie die der Sehenden sorgen. Man spricht von sogenannten ARIA-Live-Regionen (ARIA live regions). Technisch betrachtet ist eine Live-Region ein (leerer) Container, der mit dem entsprechenden Attribut angereichert ist. Er wartet darauf, dass Text (mit Hilfe von JavaScript) hinzugefügt wird. Der Browser und die Barrierefreiheits-Schnittstelle (Accessibility API) wissen von dem vorhandenen Live-Container und sobald die Live-Inhalte eingefügt werden, wird die Änderung an die assistiven Technologie weitergegeben: Der Screenreader übersetzt dies in eine Ansage.

Die Herausforderung von Live-Regionen

Menschen, die mit einem Screenreader eine Seite erkunden, navigieren von einem Element zum nächsten. Es stehen ihnen dafür eine Reihe von Tastaturbefehlen zur Verfügung. Sie springen von Überschrift zu Überschrift, von Absatz zu Absatz, und können sich, wenn nötig, Wörter mehrfach ausgeben lassen oder Buchstabe für Buchstabe lesen. Auf diese Weise haben sie die Kontrolle darüber, wie sie mit dem Inhalt interagieren und was sie sich von der assistiven Technologie ausgeben, das heißt vorlesen lassen.

Live-Regionen entziehen den Nutzenden in gewisser Weise diese Kontrolle und legen sie in die Hände der Web-Autorinnen und -Autoren. Sie entscheiden mit der entsprechenden ARIA-Auszeichnung, wann und wie der Screenreader die Aktualisierung vorliest. Sie können dadurch für eine bessere Zugänglichkeit sorgen, tragen damit aber auch eine gewisse Verantwortung: Im besten Fall erfahren die Nutzenden von allen wichtigen Meldungen und Aktualisierungen, werden aber nicht von unkontrolliertem „Geplapper“ gestört.

ARIA-Rollen und -Attribute für Live-Regionen

In der ARIA-Spezifikation (WAI-ARIA 1.2) des W3C finden Sie verschiedene Rollen und Attribute für die Umsetzung von Live-Regionen.

Das aria-live-Attribut

aria-live gehört zu den sogenannten ARIA-Eigenschaften (properties). Das Attribut sorgt für das gewünschte Verhalten der Live-Region: Der Screenreader erfährt von einer Änderung und gibt sie aus, ohne dass sie den Fokus hat. Die Ausgabe erfolgt, je nach Wert des Attributs, unterschiedlich dringend. Es gibt:

  • Ausgeschaltete Live-Regionen (aria-live="off"): Sie verhalten sich, als wäre das Attribut nicht vorhanden. Aktualisierungen werden den Nutzenden nicht präsentiert.
  • Höfliche Live-Regionen (aria-live="polite"): Die Ausgabe erfolgt nach dem Motto: Entschuldige bitte — oh, du bist gerade beschäftigt, ich kann warten. Wenn du fertig bist, möchte ich dir was sagen. Der Screenreader gibt die Meldung erst aus, wenn die derzeitige Ausgabe oder Aktion beendet ist.
  • Durchsetzungsstarke Live-Regionen (aria-live="assertive"): Hier geht es weniger gemächlich zu. Die Ausgabe ist dringender, im Sinne von: Hey, pass auf, ich muss dir was Wichtiges sagen, und zwar jetzt! — was auch immer der Screenreader gerade vorliest, er bricht die Ausgabe für die Live-Mitteilung ab.
<div id="content" aria-live="polite">
    <!-- Inhalt, der mit JavaScript aktualisiert wird -->
</div>
<button onclick="document.getElementById('content').textContent = 'Hallo, ich möchte dir etwas mitteilen!'">
    Mitteilung auslösen
</button>
<div id="content" aria-live="polite">
    Hallo, ich möchte dir etwas mitteilen!
</div>

Die Aktivierung der Schaltfläche Mitteilung auslösen fügt den Text Hallo, ich möchte dir etwas mitteilen! in die Live-Region ein. Gleichzeitig gibt der Screenreader die Mitteilung aus.

ARIA-Attribute für die Feinabstimmung

Weitere Attribute definieren gemäß Spezifikation, was genau von der Aktualisierung kommuniziert wird. Insbesondere aria-relevant und aria-busy werden jedoch relativ schlecht von manchen Screenreader-Browser-Kombinationen unterstützt:

  • Das Attribut aria-atomic bestimmt, ob der Screenreader den gesamten Inhalt der Live-Region (einschließlich zusätzlicher verschachtelter Elemente) ausgibt, oder nur den Teil, der sich geändert hat. aria-atomic kann zwei mögliche Werte haben: true und false. Ein klassischer Anwendungsfall wäre der Warenkorb eines Online-Shops. Bei Auszeichnung der Live-Region mit aria-atomic="true" gibt der Screenreader den gesamten Container aus, das könnte sich beispielsweise so anhören: Ihr Warenkorb enthält 3 Artikel, anstatt nur 3 (den geänderten Text). Umgekehrt kann der Wert "false" bei Chats Sinn machen, in denen nur die neue Nachricht ausgegeben werden soll.
  • aria-relevant ist gedacht, um die Art der Änderungen zu kommunizieren, vereinfacht gesagt, ob etwas hinzugefügt oder entfernt wird. Die möglichen Werte von aria-relevant sind additions, removals, text und all. Die Unterstützung für dieses Attribut ist jedoch recht schlecht und die Notwendigkeit wird von Fachleuten wie Aaron Leventhal und Rob Dodson in dem Artikel Why authors should avoid aria-relevant kritisch betrachtet. Sie empfehlen, aria-relevant nicht zu nutzen und auf das Standardverhalten der Live-Region zu setzen (der Screenreader liest alle neuen Inhalte vor). Auch das Entfernen eines Objekts könnte man beispielsweise über eine Statusmeldung in Kombination mit verstecktem Text kommunizieren (Beispiel: Luca hat den Chat verlassen).
  • Im Gegensatz zu den ARIA-Eigenschaften aria-atomic und aria-relevant gehört aria-busy zu den sogenannten ARIA-Attributen für Zustände (states). Sie geben den Zustand eines Elements wieder. aria-busy mit dem Wert true zeigt assistiven Technologien an, dass sich der Bereich einer Seite gerade ändert und der Screenreader mit der Ausgabe so lange warten kann, bis die Änderungen abgeschlossen sind (gemäß dem Motto Schau da nicht hin, das ist noch nicht so weit.). Ein Beispiel aus der Praxis wäre ein Ladevorgang. Ist der Ladevorgang abgeschlossen, wird der Wert von aria-busy mittels JavaScript von true auf false geändert.

ARIA-Rollen für Live-Regionen

Mit ARIA-Rollen (roles) können wir nicht semantischen Elementen eine semantische Bedeutung geben. Das heißt, wir können damit den Element-Typ definieren, beispielsweise einen Dialog oder eine Register-Navigation. Sie helfen, semantische Lücken in HTML zu schließen.

Das bereits beschriebene aria-live -Attribut ist nur für das Verhalten zuständig und zählt daher nicht zu den ARIA-Rollen. Im Gegensatz dazu handelt es sich bei role="status" und role="alert" um zwei häufig eingesetzte ARIA-Rollen für die Umsetzung von bedeutungstragenden Live-Regionen.

role="status"

role="status" ist für Statusmeldungen oder Benachrichtigungen gedacht.

  • Das Attribut role="status" hat implizit die Eigenschaft aria-live="polite". Das bedeutet, es verhält sich äquivalent dazu, trägt jedoch im Gegensatz zu der generischen Live-Region (aria-live="polite") eine semantische Bedeutung (Statusmeldung). Screenreader geben die beiden Umsetzungen allerdings nicht unbedingt in unterschiedlicher Weise aus.
  • role="status" hat gemäß ARIA-Standard außerdem das implizite Verhalten, als wäre die Live-Region mit aria-atomic="true" ausgezeichnet. Die Ausgabe eines zusätzlichen Kontextes (aufgrund der Eigenschaft aria-atomic) kann entscheidend sein, wenn geänderte Texte allein nicht gleichwertig zum visuellen Erlebnis sind.

Auch wenn role="status" gemäß Spezifikation aria-atomic="true" mitbringt, sollten Sie (aufgrund von Lücken in der Unterstützung bestimmter Screenreader-Browser-Kombinationen) besser das Attribut zusätzlich setzen — zumindest, wenn der praktische Anwendungsfall das entsprechende Verhalten erfordert.

Die ARIA-Technik "Using role=status to present status messages" (ARIA22) der Web Content Accessibility Guidelines (WCAG 2.1) beschreibt beispielsweise den Einsatz von role="status" für die Aktualisierung eines Warenkorbs (Beispiel 2). Damit die Ausgabe mit dem Screenreader NVDA in Firefox funktioniert, muss derzeit aria-atomic="true" ergänzt werden (auch wenn dies die Technik aktuell nicht formuliert).

role="alert"

role="alert" ist eine spezialisierte Form der Statusmeldung. Diese Art der Live-Region ist sinnvoll für Meldungen, die für Nutzende unmittelbar wichtig sein können und die sofortige Aufmerksamkeit erfordern, etwa Warnmeldungen.

  • Die Rolle alert bringt die Eigenschaft "aria-live="assertive" und auch aria-atomic="true" mit.
  • Die Screenreader-Ausgabe erfolgt bei dieser Rolle im Gegensatz zu role="status" meist mit einem vorangestellten Zusatz Benachrichtigung.
  • Wenn eine Warnmeldung (alert) interaktive Steuerelemente bietet (zum Beispiel eine OK-Schaltfläche, welche die Warnmeldung schließt), sollten Sie stattdessen die Rolle alertdialog verwenden.

role="log|marquee|timer"

role="log", role="marquee" und role="timer" sind weitere ARIA-Rollen für Live-Regionen, doch insbesondere marquee und timer werden schlecht von assistiven Technologien unterstützt:

  • role="log" ist gedacht für fortlaufend sich ändernde Informationen in einer sequenziellen, bedeutungstragenden Reihenfolge. Ein Anwendungsbeispiel wäre ein Chat. Die Rolle bringt die Eigenschaften aria-live="polite" mit.
  • role="marquee" ist für Inhalte, die sich häufig ändern, scrollen und in keiner bedeutungstragenden Reihenfolge stehen, z.B. ein Nachrichtenticker oder ein Banner.
  • role="timer" passt für Live-Regionen, die einen Zähler enthalten. Der Zähler zeigt die verstrichene Zeit ab einem Startpunkt oder die verbleibende Zeit bis zu einem Endpunkt an.

Sowohl role="marquee" wie auch role="timer" bringen implizit die Eigenschaft aria-live="off" mit. Das bedeutet, dass in diesem Fall Screenreader Änderungen überhaupt nicht ankündigen sollen. Es wäre viel zu lästig und störend, wenn jede Sekunde (oder was auch immer das Intervall sein mag) eine Ausgabe stattfände. Die Nutzenden müssten in diesem Fall zum Timer (oder den Nachrichtenticker) navigieren und sich den Text anhören. Semantisch gesehen ist das Setzen von role="timer" und role="marquee" richtig, es hat aber (derzeit) keinen wirklichen Einfluss auf die Barrierefreiheit.

Hinweise und Tipps für die Umsetzung von Live-Regionen

  • Wichtig für eine möglichst gute Unterstützung in unterschiedlichen Umgebungen: Sorgen Sie dafür, dass beim Laden der Seite ein (leerer) Container im DOM vorhanden und als Live-Region ausgezeichnet ist. Erst wenn die Aktualisierung ausgelöst wird, sollte die Textänderung in den vorhandenen Container eingefügt oder aktualisiert werden. Der Screenreader gibt die Aktualisierung nur aus, wenn die Barrierfreiheits-Schnittstelle sie auch als solche wahrnehmen kann. Bereits vorhandener Text wird nicht als Änderung registriert.
  • Halten Sie die Meldungen so kurz und präzise wie möglich und so ausführlich wie nötig. Screenreader verfügen (derzeit) nicht über eine Option, die Live-Ansage erneut auszugeben. Die Nutzenden sollten sie daher unmittelbar erfassen und leicht verstehen können.
  • Zeichnen Sie nicht das gesamte User Interface als Live-Region aus. Eine dynamisch erzeugte Liste von Suchergebnisse sollte beispielsweise nicht komplett in einer Live-Region eingebettet sein, die Ausgabe aller Ergebnisse wäre viel zu ausführlich. Ausreichend ist in diesem Zusammenhang eine kurze Live-Mitteilung wie zum Beispiel 8 Ergebnisse gefunden.
  • Bedenken Sie, dass semantische Informationen, die in Live-Regionen enthalten sind, nicht ausgegeben werden. Ist ein Link oder eine Schaltfläche in der Live-Region vorhanden, liest der Screenreader nur den Text vor, nicht aber wie sonst üblich, Link oder Schaltfläche. Hinzu kommt, dass das interaktive Element sowieso nicht ohne Weiteres aktiviert werden könnte, der Fokus befindet sich ja ganz woanders. Sind solche interaktiven Elemente in einem bestimmten Kontext wichtig, sollte über eine andere Umsetzung nachgedacht werden.
  • Fokus-Versetzung auf den neuen Inhalt oder eine Live Region? Die Kombination von beidem mag in sehr seltenen Fällen nicht ausgeschlossen sein, die Empfehlung lautet jedoch: Entscheiden Sie sich kontextabhängig für das eine oder das andere. Versetzen Sie den Fokus, wenn Nutzende dies erwarten, zum Beispiel bei Dialogen oder wenn ein kompletter Teil einer Seite ausgetauscht wird. Sie legen dann den neuen Inhalt in die Hände der Nutzenden und Bedienelemente stehen in einer schlüssigen Tab-Reihenfolge. Verwenden Sie Live-Regionen hingegen für Mitteilungen, die Nutzende einfach nur wissen lassen, was gerade vor sich geht oder die über ein Ereignis informieren. In diesem Fall wollen Sie den Fokus nicht unnötig entführen.
  • Es gibt benutzerdefinierte Bedienelemente (Custom Controls), die von assistiven Technologien schlecht unterstützt werden. Zusätzliche Hinweise (oft visuell versteckter Text), die mit Hilfe von Live-Regionen umgesetzt werden, sollen in mancher Umsetzung für mehr Verständlichkeit der Komponente sorgen. Das kann grundsätzlich Sinn machen, man sollte sich jedoch bewusst sein, dass bereits die Ausgangssituation (das schlecht unterstützte User Interface) sehr fragil ist. Man setzt in diesem Fall auf eine zusätzliche fragile Technik und sollte die Ausgabe des Screenreaders gut testen.
  • Geht es einfacher? Live-Regionen sind nicht immer die beste Lösung. Alternative Umsetzungen sind möglicherweise robuster und weniger fehleranfällig.
  • Für die visuelle Nutzung (ohne Screenreader) ist wichtig, dass die Meldungen nicht automatisch verschwinden. Es gibt Menschen, die aus unterschiedlichen Gründen mehr Zeit brauchen, um die Meldung wahrnehmen zu können und sie zu lesen. Dies könnte zum Beispiel seheingeschränkte Menschen betreffen, die eine Vergrößerungssoftware nutzen (die Nutzenden sehen je nach Vergrößerungsstufe nur einen kleinen Ausschnitt der Seite), oder auch Menschen mit kognitiven Einschränkungen.

Zusammenfassung

Live-Regionen sorgen dafür, dass Screenreader automatisch über Aktualisierungen informiert werden und Textänderungen ausgeben (egal wo sich der Fokus in diesem Augenblick befindet). Die Umsetzung ist jedoch fehleranfällig, nicht alle Attribute werden von allen Screenreader-Browser-Kombinationen optimal unterstützt. Um sicher zu gehen, testen Sie die Umsetzung in unterschiedlichen Umgebungen. Wie bei allen ARIA-Techniken gilt auch hier: Setzen Sie Live-Regionen bewusst ein und sorgfältig um.

Ressourcen

Weiterführende Informationen, darunter Links auf zusätzliche Ressourcen, bieten unter anderem diese englischsprachigen Artikel: