WCAG 4.1.3: Statusmeldungen

WCAG 4.1.3 verlangt, dass Statusmeldungen – „12 Treffer gefunden“, „Zum Warenkorb hinzugefügt“, „Wird gespeichert …“ – assistiven Technologien programmatisch mitgeteilt werden, ohne dass sie den Fokus erhalten. Umgesetzt wird das mit einer Live-Region, die leer im Markup steht und in die der Meldungstext später hineingeschrieben wird.

(Englisch: Status Messages.)

Das Wichtigste in Kürze

• Statusmeldung heißt: Information ohne Kontextwechsel. Sobald der Fokus wandert, greift 4.1.3 nicht mehr – dann ist es ein Dialog oder ein Seitenwechsel, und ein anderes Kriterium ist zuständig.
• Die Live-Region muss vor der Meldung im DOM stehen, und zwar leer. Werden Container und Text im selben Schritt eingefügt, sagen viele Screenreader nichts.
• role="status" ist der Normalfall – es bringt aria-live="polite" und aria-atomic="true" schon mit –, role="alert" die Ausnahme für Dringendes. alert unterbricht die laufende Sprachausgabe – das nervt, wenn es für „Gespeichert“ eingesetzt wird.
• Gleicher Text wird nicht erneut angesagt. Zweimal „1 Treffer“ hintereinander bleibt beim zweiten Mal stumm, wenn die Region nicht zwischendurch geleert wird.
• Betroffen sind mehr Stellen als gedacht: Filter-Trefferzahlen, Warenkorb-Zähler, Autosave-Hinweise, Ladezustände, Formularfehler ohne Seiten-Neuladen, Fortschrittsanzeigen.
• Stufe AA, Teil der WCAG seit 2.1 (2018) und über die EN 301 549 in Deutschland verbindlich. Im BIK-BITV-Test heißt der Prüfschritt „4.1.3 Statusmeldungen programmatisch verfügbar“.
• Automatische Tests finden das nicht. axe kann eine fehlende Live-Region nicht von einer bewusst stummen Meldung unterscheiden – hier hilft nur der Hördurchgang.

Wie sage ich „12 Treffer gefunden“ an?

Eine Statusmeldung im Sinne der Norm ist eine Information über den Erfolg oder das Ergebnis einer Aktion, über den Wartezustand einer Anwendung oder über den Fortschritt eines Vorgangs – und zwar eine, die keinen Kontextwechsel auslöst. Genau diese Abgrenzung ist der Kern: Ein modaler Dialog übernimmt den Fokus und wird deshalb ohnehin vorgelesen; er fällt nicht unter 4.1.3. Der Toast, der oben rechts erscheint und nach drei Sekunden wieder verschwindet, fällt darunter – und bleibt ohne Live-Region unbemerkt.

Die Rollen, die dafür zur Verfügung stehen:

Der Normtext verlangt ausdrücklich nur, dass die Meldung über Rollen oder Eigenschaften bestimmbar ist – nicht, dass ein bestimmtes ARIA-Attribut zum Einsatz kommt. Ein natives <output>-Element erfüllt das Kriterium ebenso, weil es die Rolle status mitbringt. Die Feinheiten stehen im Understanding-Dokument des W3C zu 4.1.3, das deutsche Prüfvorgehen im Prüfschritt „4.1.3 Statusmeldungen programmatisch verfügbar“.

Wen betrifft es besonders?

Blinde Nutzerinnen und Nutzer stehen sonst vor einer Anwendung, die stumm reagiert. Der Filter wird gesetzt, die Liste darunter ändert sich – und akustisch passiert nichts. Die typische Reaktion ist nicht Ärger, sondern Unsicherheit: Hat der Klick gewirkt? Muss ich noch einmal? Wo steht jetzt das Ergebnis?

Nutzer von Bildschirmvergrößerung sehen bei 400 % Zoom vielleicht ein Sechzehntel der Seite. Der Toast oben rechts liegt garantiert außerhalb ihres Ausschnitts. Eine Live-Region hilft ihnen, weil Vergrößerungssoftware häufig mit Sprachausgabe zusammen läuft.

Und Menschen mit Aufmerksamkeitseinschränkungen profitieren davon, dass eine Meldung überhaupt an einer festen, erwartbaren Stelle erscheint statt an wechselnden Bildschirmecken.

Richtig & falsch im Code

<!-- Falsch: Meldung wird samt Container ins DOM geworfen -->
<script>
  const el = document.createElement('div');
  el.setAttribute('role', 'status');
  el.textContent = '12 Treffer gefunden.';
  document.body.append(el);   // Screenreader hat die Region nie gesehen
</script>

<!-- Richtig: leere Region im initialen Markup, Text später hinein -->
<div role="status" class="visually-hidden" id="suchstatus"></div>

<script>
  const status = document.getElementById('suchstatus');

  function meldeTreffer(anzahl) {
    status.textContent = '';                   // alten Text räumen
    requestAnimationFrame(() => {              // eigener Tick
      status.textContent = `${anzahl} Treffer gefunden.`;
    });
  }
</script>

Das Leeren vor dem Setzen ist kein Aberglaube: Screenreader melden nur Änderungen. Wer zweimal hintereinander „1 Treffer gefunden“ hineinschreibt, hört die Meldung genau einmal – beim zweiten Mal hat sich der Textknoten nicht verändert.

<!-- Falsch: role=alert für Alltägliches – unterbricht mitten im Satz -->
<div role="alert">Entwurf gespeichert.</div>

<!-- Richtig: höfliche Rolle für höfliche Nachrichten -->
<div role="status">Entwurf gespeichert.</div>

Für Formulare gibt es einen Sonderfall, der oft übersehen wird: Wenn die Prüfung ohne Neuladen läuft, ist die Fehlermeldung eine Statusmeldung. Sie muss also angesagt werden und zusätzlich die Anforderungen aus 3.3.1 Fehlererkennung erfüllen. Die vollständigen Muster stehen unter Live-Regionen und Status, Fortschritt & Benachrichtigungen.

So testest du es

1. Inventur anlegen. Alle Stellen notieren, an denen sich ohne Seitenwechsel etwas meldet: Suche, Filter, Warenkorb, Speichern, Login-Fehler, Upload, „Mehr laden“, Cookie-Zustimmung.
2. NVDA starten und den Sprachbetrachter öffnen (Werkzeuge → Sprachbetrachter). Dort steht jede Ansage als Text – das ist deutlich belastbarer, als beim Zuhören mitzuschreiben.
3. Jede Aktion einzeln auslösen und im Sprachbetrachter prüfen: Kommt die Meldung an? Springt dabei der Fokus? Beides zusammen wäre ein Verstoß.
4. Dieselbe Aktion zweimal hintereinander auslösen. Wird die Meldung beim zweiten Mal wieder angesagt? Wenn nicht, fehlt das Leeren der Region.
5. Im DOM-Inspektor nachsehen, ob der Meldungscontainer schon vor dem Auslösen existiert und role="status" beziehungsweise aria-live trägt.
6. Gegenprobe mit VoiceOver, weil sich die Screenreader beim Timing unterschiedlich verhalten.

Häufiger Fehler in der Praxis

Der mit Abstand häufigste Befund ist die zu spät erzeugte Region. Frameworks verleiten dazu: Eine Komponente rendert erst, wenn eine Meldung existiert, also erscheinen Container und Text gemeinsam. Optisch stimmt alles, im Sprachbetrachter bleibt es leer. Der Ausweg ist banal – die leere Region gehört ins Layout, nicht in die Meldungskomponente. Ich hab mir angewöhnt, genau einen globalen Status-Container ins Grundgerüst zu legen und alle Meldungen dort hineinzuschreiben.

Der zweite ist role="alert" als Standardeinstellung. Irgendwann merkt jemand, dass alert zuverlässiger ansagt als status, und seitdem ist alles ein Alert. Für Screenreader-Nutzer bedeutet das: Jede Trefferzahl unterbricht den Satz, den sie gerade hören. Nach zehn Minuten schaltet man solche Seiten weg.

Der dritte ist der Toast mit Ablaufzeit. Drei Sekunden reichen für einen Blick, aber nicht für jemanden, der die Ansage erst abwarten und dann noch dorthin navigieren muss. Wenn die Meldung eine Aktion enthält – „Rückgängig“ –, gehört sie nicht in einen Toast, sondern an eine Stelle, die bleibt. Zeitliche Grenzen regelt davon unabhängig 2.2.1 Zeitbegrenzungen anpassbar.

Häufige Fragen

Was zählt überhaupt als Statusmeldung?

Alles, was über Erfolg, Ergebnis, Wartezustand oder Fortschritt informiert, ohne den Fokus zu verschieben: Trefferzahlen nach einer Filterung, „In den Warenkorb gelegt“, „Wird hochgeladen … 40 %“, „Verbindung getrennt“, Fehlermeldungen bei Prüfung ohne Neuladen. Nicht darunter fallen Meldungen, die den Fokus bekommen – etwa in einem modalen Dialog –, weil sie ohnehin vorgelesen werden.

Ist aria-live="polite" dasselbe wie role="status"?

Fast. role="status" bringt zusätzlich aria-atomic="true" mit, die Region wird also immer komplett vorgelesen und nicht nur der geänderte Teil. Für kurze Meldungen ist das genau richtig. Bei fortlaufenden Listen – Chatverlauf, Protokoll – passt role="log" besser, weil dort nur der neue Eintrag angesagt wird.

Warum sagt mein Screenreader die Meldung nicht an?

Drei Ursachen decken fast alle Fälle ab: Die Region wurde gleichzeitig mit dem Text erzeugt, der Text hat sich nicht wirklich geändert, oder die Region ist mit display: none versteckt statt visuell ausgeblendet. Für Letzteres brauchst du eine Hilfsklasse mit clip-path, nicht display: none – siehe Live-Regionen.

Muss die Statusmeldung auch sichtbar sein?

4.1.3 regelt nur die Ansage für assistive Technik. Eine rein visuelle Meldung ohne Live-Region verstößt gegen 4.1.3; eine rein akustische ohne sichtbaren Text verstößt gegen das Prinzip der Wahrnehmbarkeit. Die saubere Lösung meldet beides: einen sichtbaren Hinweis und dieselbe Information in der Live-Region.

Gilt 4.1.3 auch, wenn die Seite komplett neu lädt?

Nein. Nach einem Neuladen ist die Meldung Teil der neuen Seite und wird beim Durchgehen ganz normal gelesen – dann greifen stattdessen 2.4.2 Seitentitel und eine sinnvolle Überschriftenstruktur. 4.1.3 ist das Kriterium für alles, was sich innerhalb der bestehenden Seite ändert.

Verwandte Themen

• Live-Regionen (aria-live) – das Werkzeug im Detail
• Status, Fortschritt & Benachrichtigungen – Muster für Toasts und Spinner
• 4.1.2 Name, Rolle, Wert – der Nachbar im Prinzip „Robust“
• 3.3.1 Fehlererkennung – Fehlermeldungen als Sonderfall
• Mit NVDA testen – Sprachbetrachter und Einstieg