aria-live

Wann zu verwenden

Wenn ein Teil der Seite asynchron aktualisiert wird und Screenreader-Nutzerinnen und -Nutzer darüber informiert werden sollen, ohne den aktuellen Lesefluss zu unterbrechen. Typische Einsatzfälle sind Formularvalidierungszusammenfassungen, Suchergebniszählungen, Toast-Benachrichtigungen, Chat-Stream-Nachrichten und Warenkorbanzeigen.

Der Höflichkeitslevel sollte bewusst gewählt werden:

• aria-live="polite" — Ankündigung erfolgt, sobald der Nutzer nicht mehr aktiv ist. Dies sollte in fast allen Fällen verwendet werden: Statusmeldungen, geladene Ergebnisse, Hinzufügen eines Artikels zum Warenkorb.
• aria-live="assertive" — Unterbricht den Nutzer sofort. Nur für wirklich dringende Informationen reservieren — Sitzung läuft in 30 Sekunden ab, Formularübermittlung fehlgeschlagen, Zahlung abgelehnt. Übermäßiger Einsatz lässt die Seite unangenehm wirken.
• aria-live="off" (Standard) — keine Ankündigungen.

Die nativen Rollen role="status" (implizit polite) und role="alert" (implizit assertive) bündeln aria-live mit sinnvollen Standardwerten. Diese sollten bevorzugt werden, wenn sie passen; aria-live auf einem benutzerdefinierten Container kommt nur zum Einsatz, wenn sie nicht ausreichen.

Synchronisierung aufrechterhalten

Die wichtigste Regel: Der Live-Bereich muss beim initialen Rendern im DOM vorhanden sein. Browser und assistive Technologien richten die „Beobachtung“ des Bereichs ein, wenn er zum ersten Mal im Accessibility Tree erscheint. Wird der Bereich erstellt und gleichzeitig im selben JavaScript-Tick mit Inhalt befüllt, wird die Ankündigung häufig nicht ausgelöst.

Das empfohlene Muster:

<div id="status" aria-live="polite"></div>

Den leeren Container beim Seitenaufruf rendern. Später per JavaScript Text hineinschreiben. Der Screenreader kündigt die Änderung an.

Weitere Regeln:

• Aktualisierung durch Setzen von textContent; beim Ersetzen des gesamten äußeren HTML des Bereichs kann die Beobachtung unterbrochen werden.
• Wiederholte Ankündigungen erfordern eine Inhaltsänderung — das zweite Schreiben desselben Strings erzeugt oft keine erneute Ankündigung. Ein Zähler, ein Zeitstempel oder kurzes Leeren des Bereichs helfen dabei.
• Bei mehrstufigen Aktualisierungen aria-busy="true" setzen, um Teilankündigungen zu vermeiden.
• aria-atomic kombinieren, um zu steuern, ob nur die Differenz oder der gesamte Bereich angekündigt wird.

Häufige Fehler

• Den Live-Bereich im selben Tick wie den Inhalt erstellen — keine Ankündigung.
• aria-live="assertive" für alles verwenden. Nutzerinnen und Nutzer stummschalten den Tab.
• aria-live auf einem fokussierbaren Steuerelement setzen. Live-Bereiche sind für Statusaktualisierungen gedacht, nicht für interaktive Widgets.
• Den Live-Bereich mit display: none ausblenden. Per CSS ausgeblendete Bereiche sind auch für den Accessibility Tree unsichtbar und erzeugen keine Ankündigung; stattdessen sollte die Visually-Hidden-Technik (clip / sr-only) verwendet werden.
• Sehr langen Inhalt (ganze Textabsätze) auf einmal in einen Live-Bereich schreiben — Nutzerinnen und Nutzer können ihn nicht überfliegen.
• Den Bereich nach dem Lesen der Meldung nicht leeren, sodass identische nachfolgende Aktualisierungen keine Ankündigung erzeugen.

Beispiel

<form>
  <label for="zip">ZIP code</label>
  <input id="zip" name="zip" />
  <button type="submit">Look up</button>
</form>

<!-- Immer beim initialen Rendern vorhanden -->
<div id="lookup-status" aria-live="polite" class="sr-only"></div>

<script>
  document.querySelector('form').addEventListener('submit', async (e) => {
    e.preventDefault();
    const status = document.getElementById('lookup-status');
    status.textContent = 'Looking up location…';
    const place = await lookup(document.getElementById('zip').value);
    status.textContent = `Location: ${place}`;
  });
</script>