ARIA Live Regions: Dynamische Inhalte für Screenreader zugänglich machen

Moderne Webseiten aktualisieren Inhalte ständig – Warenkörbe ändern sich, Benachrichtigungen erscheinen, Formulare zeigen Fehlermeldungen. Sehende Nutzer nehmen diese Änderungen visuell wahr. Screenreader-Nutzer hingegen erfahren von dynamischen Änderungen nur, wenn der Bereich als Live Region gekennzeichnet ist. Das Attribut <code>aria-live</code> und seine Begleiter <code>aria-atomic</code> und <code>aria-relevant</code> bilden das Fundament für diese Kommunikation. EN 301 549 Abschnitt 11.4.1.3 übernimmt die WCAG-Anforderung an Statusmeldungen vollständig.

aria-live: polite, assertive und off

Das Attribut aria-live kennt drei Werte, die bestimmen, wann ein Screenreader die Änderung ankündigt: aria-live="polite" wartet, bis der Nutzer seine aktuelle Aktion beendet hat (z. B. bis er aufhört zu tippen), bevor die Änderung vorgelesen wird. Dies ist der Standardwert für die meisten Anwendungsfälle – Statusmeldungen, Suchergebnisse, Warenkorbaktualisierungen. aria-live="assertive" unterbricht sofort die aktuelle Screenreader-Ausgabe. Verwenden Sie dies nur für zeitkritische Informationen wie Fehlermeldungen, Sicherheitswarnungen oder Session-Timeouts. Übermäßiger Einsatz von assertive frustriert Nutzer, da jede Änderung den Lesefluss unterbricht. aria-live="off" deaktiviert die Live-Ankündigung. Dies ist der Standardwert aller Elemente und wird verwendet, um eine zuvor aktivierte Live Region temporär stumm zu schalten. Gemäß WCAG 4.1.3 müssen Statusmeldungen programmatisch bestimmbar sein – aria-live erfüllt genau diese Anforderung.

aria-atomic und aria-relevant

aria-atomic steuert, wie viel vorgelesen wird: Mit aria-atomic="true" wird der gesamte Inhalt der Live Region vorgelesen, auch wenn sich nur ein Teil geändert hat. Mit aria-atomic="false" (Standard) wird nur der geänderte Teil vorgelesen. Beispiel: Bei einem Warenkorb-Counter mit aria-atomic="true" und dem Text „Warenkorb: 3 Artikel" wird bei einer Änderung der gesamte Text vorgelesen – nicht nur die Zahl. aria-relevant definiert, welche Arten von Änderungen angekündigt werden: additions – neue Elemente wurden hinzugefügt. removals – Elemente wurden entfernt. text – Textinhalt hat sich geändert. all – alle Änderungen. Der Standardwert ist additions text. Für eine Chat-Anwendung ist aria-relevant="additions" sinnvoll, da nur neue Nachrichten vorgelesen werden sollen. Für eine Fehlerliste kann aria-relevant="additions removals" nützlich sein, damit auch das Beheben eines Fehlers kommuniziert wird.

Implizite Live Regions durch ARIA-Rollen

Bestimmte ARIA-Rollen erzeugen automatisch Live Regions, ohne dass aria-live explizit gesetzt werden muss: role="alert" entspricht aria-live="assertive" und aria-atomic="true". Ideal für Fehlermeldungen und Warnungen. role="status" entspricht aria-live="polite" und aria-atomic="true". Geeignet für Statusmeldungen wie „Ihre Änderungen wurden gespeichert". role="log" entspricht aria-live="polite". Geeignet für Chat-Verläufe und Aktivitätsprotokolle. role="marquee" und role="timer" haben ebenfalls implizite Live-Region-Eigenschaften. Empfehlung: Verwenden Sie bevorzugt die semantischen Rollen statt manueller aria-live-Attribute. Sie kommunizieren die Bedeutung besser und haben konsistentere Screenreader-Unterstützung. EN 301 549 Abschnitt 11.4.1.3 empfiehlt den Einsatz semantischer Rollen für Statusmeldungen ausdrücklich.

Häufige Fehler bei Live Regions

1. Live Region zu spät ins DOM einfügen: Ein Screenreader registriert eine Live Region nur, wenn sie beim Seitenladen bereits im DOM existiert. Fügen Sie die Region leer ins HTML ein und befüllen Sie sie später per JavaScript. 2. Zu viele assertive Regionen: Wenn mehrere aria-live="assertive"-Bereiche gleichzeitig aktualisiert werden, gehen Informationen verloren oder überlagern sich. 3. Gesamten Seiteninhalt als Live Region markieren: Dies führt dazu, dass jede Textänderung vorgelesen wird – eine Flut an Ankündigungen. 4. aria-live auf ausgeblendeten Elementen: Wenn ein Element mit display: none als Live Region markiert ist und dann eingeblendet wird, beachten manche Screenreader die Änderung nicht. Besser: Das Element sichtbar lassen, aber leer, und dann den Inhalt einfügen. 5. Fehlende Testung mit echten Screenreadern: NVDA, JAWS und VoiceOver interpretieren Live Regions unterschiedlich. Testen Sie mit mindestens zwei Screenreadern, um BFSG-Konformität sicherzustellen.

Implementierungsbeispiele

Hier einige praxisnahe Muster: Warenkorb-Counter: <span aria-live="polite" aria-atomic="true">Warenkorb: 3 Artikel</span> – bei Änderung wird der gesamte Text vorgelesen. Formular-Fehlermeldung: <div role="alert">Bitte geben Sie eine gültige E-Mail-Adresse ein.</div> – wird sofort vorgelesen. Suchvorschläge: <div aria-live="polite">5 Ergebnisse gefunden</div> – informiert nach Abschluss der Eingabe. Toast-Benachrichtigung: <div role="status">Änderungen gespeichert</div> – höfliche Bestätigung. Für alle Muster gilt: Platzieren Sie den Container vor dem dynamischen Inhalt im DOM, idealerweise beim Seitenladen, und aktualisieren Sie nur den Textinhalt per JavaScript.