Status-Meldungen (WCAG 4.1.3): aria-live und role="status" richtig nutzen

Kurz erklärt: Status-Meldungen (WCAG 4.1.3 Status Messages) sind Informationen, die dem Nutzer ohne Fokuswechsel präsentiert werden – z. B. Erfolgs-/Fehlermeldungen, Warenkorb-Updates oder Ladefortschritte. Sie müssen per ARIA-Live-Region auch für Screenreader-Nutzer wahrnehmbar sein. Dieses Level-AA-Kriterium ist BFSG-pflichtig.

Wenn ein sehender Nutzer auf „In den Warenkorb" klickt und eine grüne Meldung sieht, bekommt ein Screenreader-Nutzer davon nichts mit – es sei denn, die Meldung ist als ARIA-Live-Region ausgezeichnet. WCAG 4.1.3 stellt sicher, dass dynamische Status-Informationen programmatisch erfasst werden können, ohne den Fokus des Nutzers zu unterbrechen. Das BFSG fordert dies über EN 301 549.

Welche Meldungen sind betroffen?

WCAG 4.1.3 betrifft alle Meldungen, die: (1) nicht durch eine Fokusänderung ausgelöst werden und (2) dem Nutzer eine Zustandsänderung mitteilen. Typische Beispiele: Erfolgsmeldungen: „Artikel wurde dem Warenkorb hinzugefügt" Fehlermeldungen: „E-Mail-Adresse ist ungültig" (wenn ohne Seitenneuladung angezeigt) Fortschrittsanzeigen: „Upload 75 % abgeschlossen" Suchergebnisse: „12 Ergebnisse gefunden" Warenkorbzähler: „3 Artikel im Warenkorb" Nicht betroffen sind Änderungen, die den Fokus verschieben (z. B. ein modaler Dialog, der sich öffnet).

Technische Umsetzung mit ARIA

Die primären Techniken für WCAG 4.1.3 sind: role="status": Für allgemeine Status-Informationen. Impliziert aria-live="polite" – der Screenreader liest die Meldung vor, sobald der Nutzer in einer Sprechpause ist. <div role="status">3 Ergebnisse gefunden</div> role="alert": Für dringende Meldungen. Impliziert aria-live="assertive" – der Screenreader unterbricht sofort. Sparsam einsetzen! aria-live="polite": Direkte Variante ohne Rolle – für benutzerdefinierte Live-Regionen. role="log": Für chronologische Meldungen (Chat-Verläufe, Aktivitätsprotokolle). Wichtig: Die Live-Region muss vor dem Einfügen des Inhalts im DOM existieren. Ein dynamisch erstelltes Element mit role="status" wird beim ersten Laden oft nicht vorgelesen.

Häufige Fehler

Fehlende Live-Region: Meldungen werden visuell angezeigt, aber ohne ARIA – Screenreader-Nutzer bemerken sie nicht. Übermäßiger Einsatz von role="alert": Jede Kleinigkeit als Alert – der Screenreader unterbricht ständig und nervt. Dynamisch eingefügte Live-Region: Die Region wird zusammen mit dem Inhalt ins DOM eingefügt – viele Screenreader ignorieren das. Zu viele gleichzeitige Updates: Mehrere Live-Regionen, die gleichzeitig aktualisiert werden, führen zu einer Flut von Ansagen. aria-atomic fehlt: Bei Updates in einer bestehenden Region sollte aria-atomic="true" gesetzt sein, damit der gesamte Inhalt vorgelesen wird, nicht nur die Änderung.

WCAG-Bezug

WCAG 4.1.3 Status Messages ist ein Level-AA-Kriterium, eingeführt mit WCAG 2.1. Die EN 301 549, Abschnitt 11.4.1.3, übernimmt es direkt für das BFSG. Es ergänzt WCAG 4.1.2 (Name, Role, Value) – während 4.1.2 die programmatische Identifikation von UI-Elementen fordert, regelt 4.1.3 die programmatische Kommunikation von Zustandsänderungen. Auch WCAG 3.3.1 (Error Identification) ist verwandt: Fehlermeldungen bei Formularen müssen sowohl identifiziert (3.3.1) als auch als Status-Meldung an den Screenreader kommuniziert (4.1.3) werden.

Wird geprüft: bf-check erkennt dynamisch eingefügte Meldungen und prüft, ob sie in einer ARIA-Live-Region oder mit role="status"/role="alert" ausgezeichnet sind.

Wie steht deine Webseite in diesem Punkt da?

Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. Status-Meldungen-Check.

Jetzt Webseite prüfen →

Ratgeber zum Thema

Aria Attribute Richtig Einsetzen → Javascript Barrierefreiheit Dynamische Inhalte →