Live-Regionen mit aria-live

Eine Live-Region ist ein Bereich, dessen Inhaltsänderungen ein Screenreader von selbst ansagt, ohne dass der Fokus dorthin springen muss. Damit das klappt, muss der Container schon vor der Meldung im DOM stehen und danach nur noch mit Text befüllt werden – ein Element, das gemeinsam mit seinem Inhalt eingefügt wird, bleibt in der Regel stumm.

Auf einer modernen Seite ändert sich vieles, ohne dass sie neu lädt: Ein Artikel wandert in den Warenkorb, eine Suche liefert „12 Ergebnisse“, ein Entwurf wird automatisch gespeichert. Wer das sieht, bekommt es mit. Wer mit einem Screenreader arbeitet, bemerkt davon erst einmal nichts – der virtuelle Cursor steht woanders, und eine stille DOM-Änderung löst keine Sprachausgabe aus. Genau diese Lücke schließen Live-Regionen, und sie sind einer der wenigen Fälle, in denen ARIA Arbeit übernimmt, die HTML allein nicht leisten kann.

Das Wichtigste in Kürze

• aria-live="polite" ist der Normalfall: Die Ansage wartet, bis der Screenreader gerade nichts vorliest. assertive unterbricht sofort und gehört nur an Meldungen, die einen Abbruch rechtfertigen.
• Die Region muss vor der Meldung existieren. Wird sie zusammen mit ihrem Text eingefügt, kennt die assistive Technik sie noch nicht – die Ansage fällt aus.
• role="status" entspricht aria-live="polite" plus aria-atomic="true", role="alert" entspricht assertive plus atomic. Beides zusammen zu setzen, führt bei manchen Screenreadern zur doppelten Ansage.
• Identischer Text wird nicht wiederholt. Zweimal „Gespeichert“ in dieselbe Region schreiben heißt: einmal hören.
• Versteckt heißt nicht display: none. Eine Region ohne Layout-Box wird nicht vorgelesen; richtig ist eine visually-hidden-Klasse mit Clip-Technik.
• Interaktive Elemente in der Ansage sind wertlos. Ein Link in einer Live-Region wird als Text vorgelesen, nicht als Link – wer ihn braucht, muss ihn selbst suchen.
• Stand Juli 2026: aria-relevant bleibt liegen. Der Standardwert deckt die Praxisfälle ab, die Unterstützung der anderen Werte ist lückenhaft.

Was eine Live-Region tut

Technisch ist eine Live-Region kein besonderes Element, sondern eine Markierung. Browser und Betriebssystem-Schnittstelle merken sich: Dieser Container ist beobachtet. Ändert sich sein Inhalt, meldet der Browser die Änderung als Ereignis an die assistive Technik weiter, und die entscheidet, ob und wann sie es ausspricht.

Der entscheidende Unterschied zu allem anderen auf einer Seite: Der Fokus bleibt, wo er ist. Niemand wird aus dem Suchfeld gerissen, niemand verliert die Stelle im Formular. Das macht Live-Regionen so nützlich – und gleichzeitig so leicht zu missbrauchen, denn eine Ansage ohne Zusammenhang schwebt frei im Raum.

Normativ verankert ist das in WCAG 4.1.3 „Statusmeldungen“ (Stufe AA): Erfolg, Ergebnis, Wartezustand und Fehlerhinweise müssen programmatisch ermittelbar sein, ohne dass sie den Fokus bekommen. Die Live-Region ist der Weg, wie man dieses Kriterium in der Praxis erfüllt.

polite oder assertive

Das zentrale Attribut ist aria-live. Es kennt drei Werte, praktisch relevant sind zwei davon:

<!-- höflich: stört nichts -->
<div aria-live="polite">12 Ergebnisse gefunden</div>

<!-- dringend: unterbricht -->
<div aria-live="assertive">Verbindung verloren – Eingaben werden nicht gespeichert</div>

Der Unterschied klingt nach einer Nuance, ist in der Sprachausgabe aber drastisch:

Meine Faustregel: im Zweifel polite. assertive hebe ich mir für Fälle auf, in denen eine Verzögerung echten Schaden anrichtet. Ich würd an der Stelle lieber einmal zu wenig unterbrechen als dreimal zu viel – wer bei jedem gespeicherten Feld aus dem Satz gerissen wird, dreht den Screenreader irgendwann leiser, statt aufmerksamer zu werden.

Die Rollen status, alert und log

Für die häufigsten Fälle musst du aria-live gar nicht selbst setzen. Mehrere Rollen sind automatisch Live-Regionen und lesen sich im Markup deutlich klarer:

<p role="status">Entwurf gespeichert</p>
<p role="alert">Bitte korrigiere die rot markierten Felder.</p>

role="log" ist der unterschätzte Kandidat: Bei einem Chat willst du genau nicht, dass bei jeder neuen Nachricht der ganze Verlauf vorgelesen wird – und atomic="false" sorgt dafür, dass nur der neue Beitrag ankommt.

Wichtig ist, es bei einer Auszeichnung zu belassen. role="alert" bringt aria-live="assertive" bereits mit; setzt du beides, lesen einzelne Screenreader – vor allem VoiceOver unter iOS – die Meldung zweimal vor.

Die Region muss vorher da sein

Hier scheitern die meisten Versuche, und der Fehler ist tückisch, weil das fertige DOM völlig korrekt aussieht. Ein Screenreader beobachtet Live-Regionen, die er kennt. Ein Element, das gleichzeitig mit seinem Text neu ins Dokument kommt, war im Moment der Änderung noch keine beobachtete Region – die Ansage fällt aus.

// FALSCH: Region und Inhalt entstehen im selben Moment
const el = document.createElement('p');
el.setAttribute('role', 'status');
el.textContent = '12 Treffer';
document.body.append(el);            // bleibt oft stumm

Das bewährte Muster ist deshalb eine dauerhaft vorhandene, optisch versteckte Region, die nur befüllt wird:

<!-- liegt dauerhaft im Layout, anfangs leer -->
<div id="status" aria-live="polite" class="visually-hidden"></div>

// später, wenn etwas passiert:
document.getElementById('status').textContent = 'Artikel zum Warenkorb hinzugefügt.';

Das .visually-hidden blendet die Region optisch aus, hält sie für Screenreader aber präsent – dasselbe Hilfsmittel wie bei versteckten Labels. Entscheidend ist die Technik dahinter: display: none und visibility: hidden nehmen das Element aus dem Accessibility-Baum, dann wird nichts angesagt. Nötig ist eine Klasse, die per clip-path oder clip versteckt, das Element aber im Baum lässt.

Wenn sich die Region wirklich nicht vorab platzieren lässt, hilft ein Umweg: erst den leeren Container einfügen, dann in einem zweiten Schritt – mit etwa 100 Millisekunden Abstand – den Text setzen. Sauber ist das nicht, aber es rettet den Fall.

aria-atomic, aria-relevant, aria-busy

Drei Attribute stellen das Verhalten feiner ein. Nur eines davon brauchst du regelmäßig.

aria-atomic legt fest, ob der gesamte Inhalt der Region vorgelesen wird oder nur der geänderte Teil. Bei „Noch 2 Plätze frei“ willst du genau das – sonst hörst du bloß „2“. Standard ist false, role="status" und role="alert" bringen true schon mit.

<p id="platz" aria-live="polite" aria-atomic="true">Noch 2 Plätze frei</p>

aria-relevant filtert, welche Art von Änderung überhaupt gemeldet wird – Hinzufügen, Textänderung, Entfernen. Der Standardwert additions text deckt die Praxis ab, und die Unterstützung der übrigen Werte ist bis heute lückenhaft. Stand Juli 2026 rate ich dazu, das Attribut wegzulassen.

aria-busy="true" markiert einen Bereich als „gerade in Arbeit“ und unterdrückt Zwischenansagen. Baust du eine Liste in mehreren Schritten auf, schaltest du erst am Ende auf false – dann wird der Endzustand einmal gemeldet statt jeder Zwischenschritt. Wie das mit Ladeindikatoren und Fortschrittsbalken zusammenspielt, steht bei Status, Fortschritt & Benachrichtigungen.

Live-Region oder Fokuswechsel

Nicht jede Änderung braucht eine Ansage, und manche brauchen mehr als das. Die Abgrenzung entscheidet über die halbe Umsetzung:

Der häufigste Denkfehler ist, eine Live-Region für etwas einzusetzen, bei dem der Fokus ohnehin wandert. Ein modaler Dialog wird vom Screenreader von selbst vorgelesen, sobald der Fokus hineinspringt – eine zusätzliche Ansage doppelt nur.

Umgekehrt gilt: Wenn nach der Meldung eine Handlung an anderer Stelle nötig ist, reicht die Ansage nicht. Zehn Formularfehler höflich anzukündigen hilft niemandem, der danach nicht weiß, wohin. Dann gehört der Fokus in eine Fehlerübersicht.

Vier Muster aus der Praxis

Live-Suche. Die Trefferzahl in eine role="status"-Region, nicht die Trefferliste selbst. Und mit Verzögerung: Wer tippt, löst pro Tastendruck eine Anfrage aus – ohne Entprellung von rund 500 Millisekunden entsteht ein Stakkato aus halben Ansagen.

<label for="suche">Suchbegriff</label>
<input id="suche" type="search" />
<p id="suchstatus" role="status" class="visually-hidden"></p>

let timer;
feld.addEventListener('input', () => {
  clearTimeout(timer);
  timer = setTimeout(async () => {
    const treffer = await suchen(feld.value);
    document.getElementById('suchstatus').textContent = `${treffer.length} Ergebnisse gefunden`;
  }, 500);
});

Warenkorb. „Artikel hinzugefügt, 3 Artikel im Warenkorb“ ist besser als „Hinzugefügt“, weil die Zahl den Zustand bestätigt. Bei mehreren gleichen Klicks hintereinander bleibt der Text sonst identisch – und identischer Text löst keine zweite Ansage aus.

Automatisches Speichern. Ein Klassiker für polite. Aber nicht bei jedem Tastendruck: einmal nach dem Speichervorgang, mit Uhrzeit („Gespeichert um 14:02“), damit die Meldung sich vom letzten Mal unterscheidet.

Folienwechsel im Karussell. Dezent per polite und nur die Positionsangabe („Folie 3 von 6“), nicht der ganze Folieninhalt – sonst wird aus einem Karussell eine Dauerbeschallung.

So testest du eine Live-Region

Automatische Prüfwerkzeuge finden hier fast nichts. Ob eine Ansage ankommt, zeigt nur der Test mit echter Software:

1. Screenreader starten und die Aktion auslösen. Unter Windows mit NVDA, auf dem Mac mit VoiceOver – die Einstiege stehen bei Mit NVDA testen.
2. Den Sprachbetrachter öffnen. NVDA blendet unter „Werkzeuge → Sprachbetrachter“ jede Ausgabe als Text ein. So siehst du schwarz auf weiß, was angesagt wurde – und was nicht.
3. Dieselbe Aktion zweimal auslösen. Kommt die Meldung beim zweiten Mal auch? Wenn nicht, ist der Text identisch geblieben.
4. Den Fokus im Blick behalten. Er darf sich nicht bewegen. Springt er, ist es keine Statusmeldung mehr, sondern eine Kontextänderung.
5. Mit einer zweiten Kombination gegenprüfen. NVDA mit Firefox verhält sich nicht identisch zu VoiceOver mit Safari. Was in beiden ankommt, ist belastbar.

Häufige Fehler

• Region erst mit Inhalt eingefügt. Die mit Abstand häufigste Ursache für stumme Meldungen.
• display: none statt visually-hidden. Was keine Layout-Box hat, wird nicht angesagt.
• Alles assertive. Ständige Unterbrechungen machen die Bedienung mühsam.
• Rolle und aria-live doppelt gesetzt. role="alert" plus aria-live="assertive" führt bei einigen Screenreadern zur doppelten Ansage.
• Eine Region für alles. Fehler, Erfolg und Fortschritt in denselben Container zu schreiben, erzeugt abgeschnittene und vermischte Ausgaben.
• Zu viel Text auf einmal. Eine Live-Ansage ist ein Satz, kein Absatz.
• Links und Buttons in der Meldung. Sie werden als reiner Text vorgelesen; wer sie bedienen will, muss sie danach erst suchen.
• Ungebremste Updates. Ohne Entprellung überschreiben sich die Meldungen gegenseitig, und angesagt wird bestenfalls die letzte.

Häufige Fragen

role="alert" oder aria-live="assertive"?

Im Ergebnis fast dasselbe – role="alert" ist die lesbarere Kurzform einer assertiven Region und bringt zusätzlich aria-atomic="true" mit. Für echte Fehler nehme ich die Rolle, weil im Markup sofort erkennbar ist, worum es geht. Beides gleichzeitig zu setzen, bringt nichts und kann eine doppelte Ansage auslösen.

Muss die Region sichtbar sein?

Nein. Oft ist die Meldung ohnehin sichtbar, etwa eine Trefferzahl über der Liste. Wenn nicht, genügt eine optisch versteckte Region – Hauptsache, sie ist im Accessibility-Baum vorhanden. Das schließt display: none und visibility: hidden aus; nötig ist eine Klasse, die den Text per Clip-Technik aus dem Bild nimmt.

Warum höre ich meine Ansage manchmal nicht?

Drei Ursachen decken fast alle Fälle ab: Die Region wurde zu spät eingefügt, der neue Text ist identisch zum vorherigen, oder mehrere Updates folgen so schnell aufeinander, dass nur das letzte übrig bleibt. Ein vierter Kandidat ist eine Region, die in einem versteckten Elternelement liegt.

Kann ich einen Link in eine Live-Region legen?

Technisch ja, praktisch bringt es wenig. Die Ansage gibt den Linktext als Fließtext aus, ohne Rolle und ohne Möglichkeit, ihn direkt zu aktivieren. Wenn eine Handlung folgen soll, ist der Fokuswechsel das richtige Mittel – oder ein Ziel, das sich über die normale Navigation zuverlässig finden lässt.

Werden Meldungen beim Seitenaufbau angesagt?

Nein. Was schon im HTML steht, wenn die Seite fertig geladen ist, gilt nicht als Änderung. Serverseitig gerenderte Erfolgs- oder Fehlermeldungen brauchen deshalb einen anderen Weg – etwa eine Überschrift, die nach dem Laden den Fokus bekommt.

Fazit

Live-Regionen kündigen Änderungen an, die abseits des Fokus passieren: höflich mit aria-live="polite" beziehungsweise role="status", dringend mit assertive beziehungsweise role="alert". Der entscheidende Kniff ist, die Region vorab ins DOM zu legen und danach nur ihren Text zu aktualisieren.

Alles Weitere ist Dosierung: sparsam ankündigen, kurz formulieren, pro Meldungsart eine eigene Region, und bei allem, was eine Handlung nach sich zieht, lieber den Fokus verschieben als zu rufen. So geschrieben, schließen Live-Regionen eine Lücke, die Sehende überhaupt nicht bemerken – und das ist der ganze Sinn der Sache. Wie weit ARIA sonst gehen darf, klärt die erste Regel von ARIA.

Quellen

• WAI-ARIA 1.2: Live Regions (W3C – Definition, implizite Werte von status, alert und log)
• ARIA-Live-Regionen (MDN Web Docs – Verhalten von aria-atomic, aria-relevant und aria-busy)