--- title: "Statusmeldungen" url: "https://barrierefreihochzwei.de/de/wcag/4-1-3-statusmeldungen" language: "de" description: "WCAG 4.1.3 verlangt, dass Statusmeldungen wie „Artikel hinzugefügt“ ohne Fokuswechsel vorgelesen werden – hier lernst du, wie du Live-Regionen einsetzt." published: "2025-01-01T08:00:00+01:00" updated: "2026-10-15T09:42:01+02:00" --- # Statusmeldungen Wenn Updates sprechen lernen müssen. - **Erfolgskriterium:** 4.1.3 - **Prinzip:** Robust - **Konformitätsstufe:** Level AA - **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/stat...](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) Erfolgskriterium 4.1.3 # 4.1.3 Statusmeldungen Level AARobust Wenn Updates sprechen lernen müssen. ## 1. Was ist das Ziel dieses Kriteriums? Du kennst das: Du füllst ein Online-Formular aus, klickst auf „Senden“ – und plötzlich erscheint oben auf der Seite „Erfolgreich übermittelt!“. Oder du suchst nach einem Produkt und siehst „5 Ergebnisse gefunden“. Für sehende Menschen sind solche Rückmeldungen selbstverständlich. Aber was ist mit Menschen, die einen Screenreader verwenden? Das Ziel von Erfolgskriterium 4.1.3 der WCAG ist klar: Wichtige Statusmeldungen müssen auch für Nutzer:innen assistiver Technologien wahrnehmbar sein – ohne dass die Meldung dafür den Fokus erhält und die aktuelle Arbeit unterbricht. Kurz gesagt: Wenn sich der Status einer Anwendung ändert, sollen alle davon erfahren – nicht nur die, die es sehen können. ## 2. Was fordert das Erfolgskriterium genau? Ganz konkret geht es um Statusmeldungen – also Inhalte, die über Ergebnisse, Wartezustände, Fortschritte oder Fehler informieren, ohne dass sich der Kontext ändert. **Statusmeldungen müssen programmatisch ermittelbar sein** – über passende Rollen oder Eigenschaften, damit Screenreader sie automatisch vorlesen können, ohne dass der Fokus dorthin springt. **Zwei Merkmale machen eine Statusmeldung aus:** - Die Meldung informiert über Erfolg oder Ergebnis einer Aktion, einen Wartezustand, den Fortschritt eines Prozesses oder das Vorliegen von Fehlern - Die Meldung erscheint, ohne den Kontext zu ändern (kein neues Fenster, kein Fokuswechsel) **Typische Beispiele für Statusmeldungen:** - „5 Suchergebnisse gefunden“ - „Artikel zum Warenkorb hinzugefügt“ - „Formular erfolgreich übermittelt“ - „Bitte eine gültige Postleitzahl eingeben“, wenn die Meldung ohne Fokuswechsel erscheint - „Wird geladen …“ - „Upload zu 75 % abgeschlossen“ **Keine Statusmeldungen sind:** - Die Suchergebnisse selbst (nur die Anzahl ist eine Statusmeldung) - Dialoge oder Pop-ups, die den Fokus erhalten - Aufklappbare Menüs oder Akkordeon-Bereiche - Neue Inhalte, die durch einen Kontextwechsel erscheinen **Level AA:** Dieses Kriterium gehört zur Konformitätsstufe AA. Es kam mit WCAG 2.1 hinzu. ## 3. Warum ist das wichtig für Barrierefreiheit? Stell dir vor, du sitzt vor deinem Computer, hörst aber nur über Kopfhörer, was der Screenreader vorliest. Du suchst nach einem Produkt, drückst Enter – und dann? Stille. Du weißt nicht, ob die Suche läuft, ob Ergebnisse gefunden wurden oder ob ein Fehler aufgetreten ist. Statusmeldungen schaffen Barrierefreiheit, weil sie: - blinden und sehbehinderten Menschen dieselben Informationen liefern wie sehenden - Rückmeldung über Aktionen geben, ohne die aktuelle Arbeit zu unterbrechen - Menschen mit kognitiven Einschränkungen helfen, den aktuellen Zustand einer Anwendung zu verstehen - Klarheit über Erfolg oder Misserfolg von Aktionen schaffen - den Arbeitsfluss verbessern, weil klar ist, wann es weitergehen kann Und nicht zuletzt: Sie schaffen Vertrauen in die Anwendung, weil du immer weißt, was gerade passiert. ## 4. So setzt du das Kriterium erfolgreich um Die gute Nachricht: Die technische Umsetzung ist meist einfach – ARIA macht’s möglich. Hier die bewährtesten Tipps: **Für Erfolgs- und Ergebnismeldungen:** - Verwende `role="status"` für höfliche, nicht unterbrechende Meldungen - Ideal für: Bestätigungen, Anzahl der Suchergebnisse, Warenkorb-Updates - Beispiel: `
Artikel hinzugefügt
` **Für Warnungen und Fehler:** - Verwende `role="alert"` für wichtige, zeitkritische Meldungen - Ideal für: Formularfehler, kritische Systemmeldungen - Beispiel: `
Ungültige E-Mail-Adresse
` **Für Fortschritt und fortlaufende Meldungen:** - Verwende `role="log"` für fortlaufende Einträge wie Chatverläufe oder Protokolle - `role="progressbar"` mit `aria-valuenow` stellt den Fortschritt dar; für Ansagen bei wichtigen Zwischenständen ergänzt du eine Meldung mit `role="status"` - Ideal für: Upload-Status, mehrstufige Prozesse **Weitere Tipps aus der Praxis:** - Die Live-Region muss schon im Dokument vorhanden sein, bevor sich ihr Inhalt ändert – füge also den Text in ein bestehendes Element ein, statt das Element samt Rolle erst neu zu erzeugen - Verwende `aria-atomic="true"`, wenn immer der gesamte Text vorgelesen werden soll - `aria-live="polite"` bzw. `aria-live="assertive"` sind eine Alternative zu den Rollen - Halte Statusmeldungen kurz und prägnant - Teste immer mit echten Screenreadern (NVDA, JAWS, VoiceOver) **Was du vermeiden solltest:** - Statusmeldungen nur visuell anzeigen, ohne passende Rolle oder Eigenschaft - `role="alert"` für unwichtige Meldungen verwenden – das macht Anwendungen „geschwätzig“ und unterbricht ständig - Live-Regionen erst zusammen mit der Meldung einfügen – viele Screenreader bekommen das nicht mit Verwandt sind [Name, Rolle, Wert](https://barrierefreihochzwei.de/de/wcag/4-1-2-name-rolle-wert) für Zustände von Bedienelementen und [Fehlererkennung](https://barrierefreihochzwei.de/de/wcag/3-3-1-fehlererkennung) für Fehlermeldungen in Formularen. ## 5. Warum dieses Erfolgskriterium für Unternehmen relevant ist Auch bei Erfolgskriterium 4.1.3 gilt: Barrierefreiheit ist kein Selbstzweck – sondern bringt handfeste Vorteile für dein Business. **1. Nutzungserlebnis für alle verbessern** Gute Statusmeldungen machen deine Anwendung für alle nutzbarer. Auch sehende Menschen profitieren von klaren, eindeutigen Rückmeldungen – sie reduzieren Verwirrung und Unsicherheit. **2. Weniger Abbrüche, zufriedenere Kund:innen** Klare Rückmeldungen über Erfolg oder Misserfolg von Aktionen verhindern Abbrüche. Wer weiß, wo er steht und was als Nächstes zu tun ist, schließt Prozesse eher erfolgreich ab. **3. Support-Anfragen reduzieren** Eindeutige Statusmeldungen beantworten Fragen, bevor sie entstehen. „Wurde meine Bestellung wirklich übermittelt?“ „Läuft der Upload noch?“ – solche Unsicherheiten führen zu unnötigen Support-Anfragen, die du mit guten Statusmeldungen vermeidest. Und nicht zuletzt die rechtliche Seite: Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele digitale Angebote für Verbraucher:innen, etwa Online-Shops und Bankdienstleistungen. Technischer Maßstab ist die EN 301 549, die für Webinhalte auf WCAG 2.1 Level AA verweist – 4.1.3 gehört dazu. Öffentliche Stellen sind über die BITV 2.0 bzw. Landesrecht ohnehin verpflichtet. Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung. ## 6. Das Erfolgskriterium im Wortlaut des W3C > **Success Criterion 4.1.3 Status Messages (Level AA)** > > In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus. Kurz gesagt: Statusmeldungen sind über Rolle oder Eigenschaften maschinenlesbar ausgezeichnet, sodass assistive Technologien sie ansagen können, ohne dass sie den Fokus erhalten. **Offizielle Erklärung beim W3C** Das W3C erklärt jedes Erfolgskriterium ausführlich – mit Absicht, Beispielen und Techniken (auf Englisch). [Understanding 4.1.3](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html) ## Weitere Kriterien aus „Robust“ [ 4.1.1 Obsolet ### Syntaxanalyse (obsolet) Wenn ein Kriterium in Rente geht. ](https://barrierefreihochzwei.de/de/wcag/4-1-1-syntaxanalyse-obsolet) [ 4.1.2 Level A ### Name, Rolle, Wert Wenn der Code mit Assistenztechnologien spricht. ](https://barrierefreihochzwei.de/de/wcag/4-1-2-name-rolle-wert)