Über den Autor:
Detlef Beyer


Ganz schön dynamisch – ARIA-live in der Praxis
Dynamische Änderungen auf einer Webseite, zum Beispiel ein sich füllender Warenkorb oder Statusmeldungen, müssen für eine barrierefreie Lösung entsprechend aufgefangen werden. Die Änderungen müssen den Nutzer:innen zugänglich gemacht werden. Wenn ein Screen Reader nicht mitteilt, dass ein Formular – nach meiner Eingabe – um drei neue Felder ergänzt wurde, kann ich auf diese Änderung nicht reagieren. Das mentale Bild der Seite stimmt nun nicht mehr mit der Wirklichkeit überein.
Es gibt genau für diesen Zweck eine spezielle ARIA Attribute. ARIA steht hier für Accessible Rich Internet Applications. ARIA stellt zusätzliche Attribute und Rollen für das HTML einer Seite zur Verfügung. Mit ARIA sollen die Inhalte für Menschen mit Einschränkungen zugänglicher gemacht werden. In vielen Fällen klappt das sogar. Trotzdem gilt die erste Regel für die Nutzung von ARIA Attributen weiterhin: „benutze kein ARIA“. Wenn es mit einfachem HTML geht, ist das immer der bessere Weg. Aber es geht nicht immer ohne ARIA und dynamische Änderungen auf einer Webseite sind dafür ein gutes Beispiel.
Das entsprechende ARIA-Attribut nennt sich „aria-live“. Diese sogenannten ARIA Live-Regionen werden verwendet, um assistive Technologien (wie Screen Reader) über dynamische Inhaltsänderungen auf einer Webseite zu informieren. Einfach ausgedrückt: Wenn Browser auf ein Element stoßen, das als Live-Region markiert ist (entweder explizit mit einem aria-live=“…“ Attribut oder mit einer Rolle, die eine implizite Live-Region aufbaut, wie z. B. role=“status“), geben sie diese Informationen an Screen Reader über den accessibility tree weiter.
Aktualisierungen über ARIA-Live
Durch die Verwendung von aria-live in einem HTML-Container können Entwickler:innen sicherstellen, dass Nutzer:innen über Aktualisierungen auf der Seite benachrichtigt werden, ohne ihre aktuelle Aufgabe zu unterbrechen.
Es gibt in den Web Content Accessibility Guidlines (WCAG) mit dem Level AA Kriterium 4.1.3 die passende Richtlinie. Die entsprechend über das Barrierefreiheitsstärkungsgesetz (BFSG) rechtlich vorgeschrieben ist. Diese Regel lässt sich kurz und knackig zusammenfassen: „Machen Sie die Benutzer:innen auf wichtige Änderungen im Inhalt aufmerksam“.
aria-live findet man mittlerweile ziemlich oft auf Webseiten. Nicht immer wird es richtig eingesetzt. Die entscheidenden Kriterien für den Einsatz sind:
- alle relevanten Änderungen werden zur Nutzerin oder zum Nutzer transportiert.
- die Informationen werden so angeliefert, dass sie kurz und verständlich sind.
- die Hinweise stören nicht beim Erfassen von anderen Inhalten der Seite.
ARIA-live in der Praxis
Das hört sich einfacher an, als es in vielen Fällen in der Praxis ist. Der HTML-Container, der mit dem aria-live Attribut versehen wird, muss gut gewählt werden. In der Regel ist dies ein DIV Element, welches den eigentlichen Inhalt, das Formular oder den Warenkorb, umschließt.
<div aria-live=“polite“>…</div>
Mit dem Parameter „polite“ legt man fest, dass diese Meldung nur dann vorgelesen wird, wenn gerade keine anderen Inhalte übermittelt werden. Das ist die übliche Einstellung. Mit „assertive“ würde eine dringende Nachricht unmittelbar übergeben. Das sollte die Ausnahme bleiben. Aber was wird denn eigentlich vom Screen Reader vorgelesen?
Die „ARIA Live-Regionen“ lassen sich weiter konfigurieren. Mit aria-atomic=“true“ kann ich festlegen, dass der gesamte Inhalt des Containers vorgelesen wird. Steht dieser Wert auf „false“, werden nur die Änderungen vorgelesen. Die Nutzer:innen eines Screen Readers haben grundsätzlich mit der großen Menge an Informationen auf einer komplexen Webseite zu kämpfen. Daher sollten ARIA Live-Regions nur wichtige, möglichst klare und kurze Nachrichten übermittelt werden. Mit dem „aria-relevant“ Attribut könnte genauer festgelegt werden, welche Art von Änderung eine Nachricht auslöst. Da diese Attribut von vielen Browsern und Screen Readern ignoriert wird, vergessen wir es gleich wieder.
Statt eine bereits bestehende Struktur zu nutzen, kann alternativ ein gesonderter Bereich für Nachrichten geschaffen werden:
<div id="status-messages" aria-live="polite" aria-atomic="true"></div>
Diese „ARIA Live-Region“ kann anschließend mit Javascript dynamisch gefüllt werden:
document.getElementById('status-messages').textContent = 'Dein Benutzername muss mindestens fünf Zeichen enthalten';
Alternativ könnten wir role=“status“ nutzen. Das entspricht recht genau dem gerade gezeigten HTML Beispiel mit aria-live.
Es geht noch mehr – weitere Optionen für ARIA-live
Im Gegensatz zu dieser sanften Variante können wir eine wirklich wichtige Meldung mit Nachdruck an die Nutzer:innen übermitteln. Dafür würde sich die alertdialog ARIA-Rolle eignen, auf die ich jetzt aber nicht weiter eingehe. Hier gilt, wie bei aria-live=“assertive“, dass wir die Nutzer:innen im Lesefluss unterbrechen und das nur mit Bedacht tun sollten. Weiterhin wäre noch die ARIA-Rolle „log“ zu erwähnen, die ebenfalls eine live-Region aufbaut und in der Regel zusammen mit aria-live=“polite“ genutzt wird. Eine prima Idee für einen Chat.
Ein Sonderfall sind Statusmeldungen, die bereits beim Aufbau einer Seite vorhanden sind. Wenn ich den Hinweis auf einen Rabatt als wichtig erachte, kann ich eine Live-Region nutzen:
<div aria-live=“assertive“> Der Hinweis auf den tollen Rabatt soll mit dem Laden der Seite übermittelt werden. </div>
Das klappt leider nicht, wenn diese Live-Region schon gefüllt beim Aufbau der Seite vorhanden war. Es hat ja keine Änderung auf der Seite gegeben und nur die würde das entsprechende Ereignis auslösen. Wenn stattdessen role=“alert“ genutzt wird, könnte es funktionieren, aber nicht auf allen Plattformen. Der sichere Weg, um mit dem Laden der Seite eine Meldung zu übermitteln, ist ein leerer Container beim Aufbau der Seite und das zeitversetzte Befüllen. Statisch im HTML der Seite:
<div id="statusmeldung" aria-live="assertive"></div>
Und dann ein klein wenig Javascript:
document.addEventListener("DOMContentLoaded", function ()
/* Holen wir uns die Referenz auf den Container */
const statusArea = document.getElementById("statusmeldung");
/* Und jetzt ab mit der Meldung in die Live-Region */
var meineNachricht = document.createTextNode("Ein super toller Rabatt ist heute für Sie da");
statusArea.appendChild(meineNachricht);
});
Fazit
Richtig eingesetzt, können Live-Regionen einer Webseite zu mehr Barrierefreiheit verhelfen. Dazu sollten sie bereits in der Design-Phase berücksichtigt werden. Wir nutzen die Live-Regions um aktiv Informationen an die Nutzer:innen unserer Website zu senden und das häufig nicht als direkte Reaktion auf eine Interaktion. Die Nachrichten sollten daher gut strukturiert sein und nicht zu oft den Lesefluss unterbrechen. Wenn die Summe der Artikel im Warenkorb hoch genug ist und das Porto nun entfällt, könnte das eine Nachricht wert sein. Wenn alle zwei Minuten ein Hinweis auf „die anderen tollen Angebote“ im Shop verkündet wird, ist das eher störend und lenkt die Nutzer ab.
Dein Kommentar
Mehr zu diesem Thema

Allgemein
Ganz schön dynamisch – ARIA-Live in der Praxis
Dynamische Änderungen auf einer Webseite, zum Beispiel ein sich füllender Warenkorb oder Statusmeldungen, müssen für eine barrierefreie Lösung entsprechend aufgefangen werden. Die Änderungen müssen den Nutzer:innen zugänglich gemacht werden.

Werkzeuge
User Stories – ein guter Weg zu einer barrierefreien Lösung
Barrierefreiheit muss von Anfang an in einem Projekt berücksichtigt werden. Das spart Nerven und Budget. Ein Werkzeug kann dabei helfen, das Thema Barrierefreiheit verständlich und recht einfach in die Prozessschritte zu integrieren.

Werkzeuge
Kontrastprogramm – neue Regeln für die Berechnung eines barrierefreien Farbkontrasts
Der Accessibility Perception Contrast Algorithm (APCA) ist eine neue Methode zur Kontrastberechnung, die die menschliche Wahrnehmung genauer berücksichtigt als bisherige Modelle.
