Dynamische Inhalte auf Websites – Wie man „live regions“ effektiv benutzt

Wie bekommen Nutzer, die einen Screenreader benutzen, eigentlich mit, wenn sich auf einer Website etwas ändert, wie zum Beispiel, wenn ein Formularfeld fehlerhaft ausgefüllt wurde und eine Fehlermeldung zurückkommt? Oder wenn sich die Anzahl der Produkte in einem Warenkorb ändert? Sehende Nutzer nehmen die Änderung sofort wahr (wenn sie gut sichtbar umgesetzt wurde 🙂 ) – Screenreadernutzer müssen sich auf die Ansage verlassen.

Um auch diesen Nutzern mitzuteilen, wenn sich etwas ändert, benutzt man sogenannte „live regions“. Es gibt zwei Wege, die man hier gehen kann und den Unterschied zu verstehen ist wichtig.

Spezielle live region roles (Aria Alerts): Manche ARIA Roles schaffen automatisch live regions, ohne das aria-live Attribut zu brauchen. Diese roles haben ein eingebautes Verhalten (z. B. „status“ oder „alert“) und das macht sie perfekt für manche Situationen.
Das aria-live Attribut: Es kann jedem Element gegeben werden, das man auf Änderungen überwachen möchte. Man bekommt die komplette Kontrolle darüber, wie und wann Updates ausgegeben werden.

In diesem Artikel geht es schwerpunktmäßig um die Aria Alerts, die z. B. mit der role=“alert“ definiert werden. Für mehr Info zu aria-live empfiehlt es sich, den Artikel The Complete Guide to ARIA Live Regions for Developers zu lesen.

Was sind „ARIA Alerts“ eigentlich?

ARIA alerts oder auch ARIA Warnungen sind wie ein leichtes Klopfen auf die Schulter – sie sorgen dafür, dass Nutzer wichtige Infos genau im richtigen Moment bekommen. Man definiert einen ARIA Alert über role="alert".

Es ist jedoch nicht ganz so einfach, ARIA Alerts richtig und effektiv einzusetzen. Werden sie zu oft verwendet, kann man die Nutzer schnell überfordern. Nutzt man sie falsch, kommen wichtige Nachrichten vielleicht nicht bei allen an. Es ist ein bisschen so, wie die richtige Lautstärke für eine Ansage zu finden – ist sie zu leise, bekommt man sie nicht mit, ist sie zu laut, nervt sie. Man kann sich Benachrichtigungen auch wie Textnachrichten vorstellen – sie sollten klar und rechtzeitig sein, aber nicht so häufig, dass man sie irgendwann einfach ignoriert.

Technisches Setup

Platzieren des role="alert" auf dem Element, das die Nachricht enthält, und nicht auf Schaltflächen oder anderen Steuerelementen, die die Meldung auslösen.
JavaScript verwenden, um den Inhalt der Warnmeldung dynamisch zu aktualisieren – so wird sichergestellt, dass Screenreader die Änderung erfassen.
Nicht aria-live=„assertive“ hinzufügen, wenn bereits role="alert" verwendet wird – einige Screenreader könnten die Nachricht doppelt anzeigen.

Code-Beispiel eines Formulars, das eine Warnung abschickt, wenn ein E-mail-Feld nicht oder falsch ausgefüllt wird:

<form id="contactForm"> 
<label for="email">Email:</label>
<input type="email" id="email" name="email">
<button type="submit" onclick="submitForm(event)">Submit</button> 
</form> 
<!-- Alert message after form submission -->
<div role="alert"> 
<span id="error-message" style="display:none;color:red;font-weight:700;">Please provide a valid email address.</span>
</div>

Kurze Erklärung des htmls:

Der Container mit role="alert" ist der Container für die Fehlermeldung, er muss initial leer sein und wird dann entweder per js oder wie hier per css befüllt. Das role="alert" sagt Screenreadern, dass es sich hierbei um eine wichtige Live Region handelt und dass der Inhalt sofort gelesen werden soll.
Der <span> mit der id="error-message" wird für die Nachricht verwendet und wird vorgelesen, wenn der Alert ausgelöst wird.
Der style="display:none;" versteckt den Inhalt initial und wird dann über Javascript eingeblendet.
Die Farbe rot und der Schriftschnitt 700 (fett) hilft dabei, die Fehlermeldung besser erkennbar zu machen.
! In einer produktiven Umgebung sollten die styles in einer externen css-Datei sein

Benötigtes Javascript:

document.addEventListener('DOMContentLoaded', function () {
  const form = document.getElementById('contactForm');
  const emailField = document.getElementById('email');
  const errorMessage = document.getElementById('error-message');

  form.addEventListener('submit', function (event) {
    event.preventDefault();

    const email = emailField?.value.trim();
    const isValidEmail = email && /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);

    if (!isValidEmail) {
      errorMessage.style.display = 'block';
      emailField.setAttribute('aria-invalid', 'true');
    } else {
      errorMessage.style.display = 'none';
      emailField.removeAttribute('aria-invalid');
      alert('Form submitted successfully');
      form.submit();
    }
  });
});

^{*Javascript abgewandelt vom Original-Artikel. Es handelt sich hier um Beispiel-Code, den man nutzen kann, um das Verhalten von Screenreadern zu testen.}

Kurze Erklärung des Javascripts:

Zum Testen wird event.preventDefault(); verwendet, damit kontrolliert werden kann, was nach dem Submit passiert
const emailField und errorMessage holen sich die Referenzen zum Inputfeld und zun Fehlermeldung-Container
const email mit .trim() entfernt Leerzeichen am Anfang/Ende der Eingabe
const IsValidEmail validiert die eingegebene E-Mail Adresse: Statt nur includes('@'), eine einfache Regex-Prüfung, die gängige E-Mail-Formate erkennt.
Abfrage, damit kein Fehler geworfen wird, falls das Element mal nicht im DOM ist.
Ausgabe entsprechend: Wenn die Email nicht valide ist, wird die Fehlermeldung sichtbar, wenn sie valide ist, wird die Erfolgsmeldung ausgegeben (in echt würde das Formular dann per entsprechendem Code gesendet werden können)

Verschiedene Arten von Meldungen

Manchmal ist role="alert" nicht die beste Lösung. Es gibt noch andere:

Für Nutzer-Interaktion: role="alertdialog" (Perfekt für „Bist du sicher, dass du löschen willst?)
Fortschritt zeigen: role="status" (Z. B. Hochladen zu 50% abgeschlossen)
Chat-Applikation: role="log"
Aktien-Ticker: role="marquee"
Countdown: role="timer"

Außerdem sollte man über die Zeit nachdenken. Die alerts müssen lange genug zu sehen sein, in Formularen auf jeden Fall so lange, bis der Fehler behoben ist. Vorübergehenden Meldungen sollte mehrere Sekunden zu sehen sein.

Häufige Fallstricke bei ARIA Alerts und wie man sie vermeidet

Zu viele Alerts. role="alert" sollte wirklich nur für dringende Nachrichten verwendet werden.
Zu schnell verschwindende Alerts. Wenn es wichtig ist, dass eine Meldung länger da ist, sollte role="alertdialog" verwendet werden, dann bleibt sie da bis der Nutzer etwas tut
Der Container role="alert" ist nicht leer, wenn die Seite lädt. Er muss aber leer sein, da der Screenreader nur darauf reagiert, wenn sich der Inhalt dynamisch ändert.
role="alert" ist gepaart mit aria-live="assertive". Dies muss vermieden werden, da die Meldung sonst u. U. doppelt ausgegeben wird.

Quelle: How to Use ARIA Alert Effectively

Exkurs: Erklärung und Unterschiede zwischen ARIA alert und aria-live

Der Unterschied zwischen ARIA Alert (bzw. eigentlich role="alert") und aria-live liegt im Verhalten, der Dringlichkeit und dem beabsichtigten Anwendungsfall für Screenreader-Nutzer:innen. Hier ist eine Gegenüberstellung:

`role="alert"`

Was es ist: Ein spezieller ARIA-Rollenwert, der automatisch aria-live="assertive" mit sich bringt.
Verhalten:
- Wird automatisch angekündigt, sobald der Inhalt erscheint (z. B. dynamisch per JavaScript eingefügt).
- Benötigt keinen Fokus und keine Benutzeraktion.
- Hohe Priorität: Wird sofort vorgelesen, unterbricht sogar andere Screenreader-Ausgaben.
Typische Nutzung:
- Fehlernachrichten („Passwort ist zu kurz“)
- Wichtige Warnungen
- Bestätigungen bei kritischen Aktionen („Änderung gespeichert“)

Merken: role="alert" ist wie ein Notfallruf – laut, direkt und sofort.

`aria-live`

Was es ist: Ein Attribut, das anzeigt, wie dynamische Inhalte angekündigt werden sollen.
Mögliche Werte:
- off (Standard): Keine Ankündigung
- polite: Screenreader wartet, bis Nutzer:innen still sind
- assertive: Wird sofort vorgelesen
Verhalten:
- Muss nicht automatisch ausgelöst werden – funktioniert erst, wenn sich der Inhalt sichtbar ändert.
- Man hat mehr Kontrolle über die Priorität und das Timing.
Typische Nutzung:
- Ladeanzeigen („Daten werden geladen…“)
- Chatnachrichten
- Live-Sportstände oder Börsendaten

Merken: aria-live ist flexibel – du gibst vor, wie höflich oder aufdringlich es sein soll.

Feature	role=“alert“	aria-live
Dringlichkeit	Hoch (`assertive`)	Einstellbar (`off`, `polite`, `assertive`)
Automatische Ankündigung	Ja, bei Hinzufügen zum DOM	Nur bei sichtbarer Änderung
Unterbricht Screenreader	Ja	Nur bei `assertive`
Fokus erforderlich	Nein	Nein
Typische Nutzung	Warnungen, Fehler	Statusupdates, Hinweise