Konzepte

Live-Region

Auch: aria-live, ARIA live region

Ein von ARIA verwalteter Bereich, der Screenreader-Nutzenden dynamische Inhaltsänderungen ankündigt, ohne den Fokus zu verschieben. Das Attribut `aria-live` macht einen DOM-Abschnitt für Benachrichtigungen im Accessibility-Tree `polite` oder `assertive`.

Eine Live-Region ist ein Teil des DOM, dessen Inhaltsänderungen Screenreader-Nutzenden automatisch angekündigt werden — ohne den Fokus zu verschieben, ohne dass die Nutzenden dorthin navigieren müssen und ohne dass sie die Seite aktualisieren müssen.

Live-Regionen sind der Mechanismus hinter jeder „Toast: Artikel in den Warenkorb gelegt“-Benachrichtigung, jeder Formularvalidierungsmeldung „Fehler: E-Mail-Adresse ist erforderlich“ und jeder Aktualisierung der Suchergebnisanzahl, die Screenreader-Nutzende tatsächlich hören.

Das grundlegende Attribut

Die einfachste Live-Region ist ein div mit aria-live="polite":

<div aria-live="polite" id="status">
  <!-- Inhalte hier werden bei Änderungen angekündigt -->
</div>

Wenn JavaScript Text in #status einfügt, kündigt der Screenreader den neuen Text bei der nächsten natürlichen Pause an — ohne zu unterbrechen, was die Nutzenden gerade lesen.

Polite vs. Assertive

aria-live hat zwei operative Werte:

  • polite — warten, bis die Nutzenden inaktiv sind, dann ankündigen. Für die meisten Benachrichtigungen verwenden: Bestätigungen, Suchergebnisanzahl, Statusmeldungen.
  • assertive — die aktuelle Lektüre der Nutzenden unterbrechen und sofort ankündigen. Nur für wirklich dringende Meldungen verwenden: kritische Fehler, Warnungen zum Sitzungsablauf, zeitkritische Hinweise.

Übermäßiger assertive-Einsatz ist der bei Weitem häufigste Live-Regionen-Fehler. Jeder geringfügige Toast mit assertive macht den Screenreader zu einem ständigen Unterbrecher und bringt die Nutzenden dazu, die Live-Region vollständig zu deaktivieren.

ARIA-abgeleitete Alternativen

Mehrere ARIA-Rollen implizieren aria-live automatisch:

  • role="alert" → verhält sich wie aria-live="assertive".
  • role="status" → verhält sich wie aria-live="polite".
  • role="log" → polite, mit dem konzeptuellen Hinweis auf ein nur-anhängendes Protokoll (Chat-Verlauf, Konsolenausgabe).
  • role="timer" → polite, für Countdowntimer.

Eine Rolle zu wählen ist oft klarer als direkt einen aria-live-Wert festzulegen — sie dokumentiert den Zweck der Region.

Was in der Praxis schiefläuft

  • Live-Region wird gleichzeitig mit dem Inhalt hinzugefügt. ARIA kündigt nur Änderungen an Live-Regionen an, die bereits im DOM vorhanden waren. Das Einfügen von <div aria-live="polite">Geladen</div> als einzelner Block kündigt nichts an — Region und Inhalt kamen zusammen. Lösung: die leere Live-Region vom Seitenaufbau an im DOM belassen und erst später befüllen.
  • Zu schnelle Aktualisierungen. Wird Text mehrmals pro Sekunde in eine Live-Region eingefügt, wird die vorherige Ankündigung unterbrochen, bevor sie abgeschlossen ist. Die Nutzenden hören Fragmente. Aktualisierungen drosseln oder per Debounce verzögern.
  • Modal-verwaltete Ankündigungen, bei denen stattdessen Fokusverschiebung besser wäre. Wenn eine Aktion der Nutzenden die Meldung ausgelöst hat, ist das Verschieben des Fokus auf die Meldung (oder ein verwandtes Steuerelement) oft besser als eine Live-Regionen-Ankündigung. Live-Regionen sind für passive Benachrichtigungen gedacht.
  • Dekorativer Lärm in der Live-Region. Eine Live-Region, die neben der Meldung auch Ladespinner, Symbole und Zeitstempel enthält, veranlasst den Screenreader, bei jeder Aktualisierung alles davon vorzulesen. Den Inhalt der Region auf die eigentliche Meldung beschränken.