Toast- und Statusmeldungen: role="status" richtig einsetzen

Du legst einen Artikel in den Warenkorb. Unten erscheint kurz „Hinzugefügt“, während der Fokus auf dem Button bleibt. Wer die Meldung nicht sieht, braucht ebenfalls eine Rückmeldung. Eine sichtbare Textzeile allein stellt das noch nicht sicher.

Für gewöhnliche Erfolgs- und Ergebnismeldungen eignet sich eine bereits vorhandene Region mit role="status". Aktualisiere nach der Aktion ihren Text. Ob die Nachricht verständlich und zum richtigen Zeitpunkt angesagt wird, prüfst Du mit einem Screenreader.

Welche Rückmeldung braucht Deine Aktion?

WCAG 4.1.3 Statusmeldungen behandelt Informationen über Ergebnis, Wartezustand, Fortschritt oder Fehler, die ohne Kontextwechsel erscheinen. „12 Treffer“ nach einer Suche ist ein solches Beispiel. Die ganze neue Trefferliste ist damit nicht automatisch eine Statusmeldung.

Wähle die Rückmeldung nach ihrer Aufgabe:

• Gespeichert, Artikel hinzugefügt, Trefferzahl geändert: Nutze meist role="status". Die implizite Live-Einstellung polite soll die laufende Ausgabe nicht unnötig unterbrechen.
• Wichtige, zeitkritische Warnung: role="alert" ist eine Möglichkeit. Die Rolle hat die implizite Live-Einstellung assertive. Verwende sie sparsam; eine gewöhnliche Erfolgsmeldung braucht diese Dringlichkeit nicht.
• Korrektur im Formular erforderlich: Ordne Fehler den Feldern zu und plane den Weg dorthin. Eine fokussierte Fehlerübersicht kann helfen. Das ist eine eigene Entscheidung über den Ablauf, kein Grund, jeden Feldfehler als Alert auszugeben.

Die Rollen beschreibt WAI-ARIA 1.2. Das W3C-Alert-Muster sieht für eine reine Warnmeldung keinen Fokuswechsel vor. Muss jemand unmittelbar handeln, brauchst Du einen passenden Dialogablauf.

Warum kann eine neu eingefügte Meldung stumm bleiben?

Diese React-Variante erzeugt Region und Nachricht gleichzeitig:

{saved && <p role="status">Einstellungen gespeichert.</p>}

Der Screenreader muss die Region erst kennenlernen. Auf ihre schon vorhandenen Inhalte als Änderung zu vertrauen, ist riskant. TetraLogical beschreibt diesen Einfügeablauf und eigene Browser-Screenreader-Tests von 2024. Für alert sieht WAI-ARIA ein eigenes Ereignis beim Erzeugen der Meldung vor, sofern das Betriebssystem dies unterstützt. Daraus folgt kein Grund, Erfolgsmeldungen auf alert umzustellen.

Im folgenden synthetischen Beispiel wird nach jedem Hinzufügen eine neue, bereits gefüllte Statusregion erzeugt. Probiere es mit Deiner Browser-Screenreader-Kombination aus.

Prüfergebnis zum Muster: Die Region ist vor der ersten Aktion nicht vorhanden. Damit besteht sie den ersten Prüfschritt der W3C-Technik ARIA22 nicht. Das beschreibt den Aufbau; eine tatsächlich ausgebliebene Ansage ist hier noch nicht nachgewiesen.

Die Region bleibt, ihr Text ändert sich

Rendere die leere Region zusammen mit der Seite. Die folgende lokale Simulation aktualisiert sie nach dem Hinzufügen. Bei einer echten Speicherung meldest Du Erfolg erst, wenn die Speicherung erfolgreich abgeschlossen ist:

import { useState } from "react";

function WarenkorbStatus() {
  const [count, setCount] = useState(0);
  return (
    <>
      <button type="button" onClick={() => setCount(value => value + 1)}>
        Artikel im Beispiel hinzufügen
      </button>
      <p role="status" aria-atomic="true">
        {count > 0 ? `Im Beispiel-Warenkorb: ${count} Artikel.` : ""}
      </p>
    </>
  );
}

aria-atomic="true" beschreibt die ganze Nachricht als zusammengehörige Ausgabe. ARIA22 empfiehlt die explizite Angabe auch wegen unterschiedlicher Unterstützung. Verstecke die leere Region nicht mit display: none oder hidden, wenn sie bereits für Meldungen bereitstehen soll.

Prüfergebnis zum Muster: Die leere Statusregion ist vor der Aktion vorhanden und erhält danach den Text. Das erfüllt die hier gezeigten Strukturprüfschritte von ARIA22. Eine bestandene Strukturprüfung belegt weder die gesprochene Ansage noch die Barrierefreiheit des ganzen Formulars.

Beide Beispiele lassen den Fokus auf dem Hinzufügen-Button und behalten die Meldung bis zur nächsten Aktion oder zum Zurücksetzen. Die Artikelzahl ändert sich bei jeder Aktion. Das prüft noch nicht, ob eine identische Nachricht bei wiederholtem Speichern erneut gesprochen wird. Teste diesen Fall separat; eine unveränderte Zeichenfolge erzeugt möglicherweise keine neue Inhaltsänderung.

Wie lange muss der Toast bleiben?

Prüfe bei einer kurzen Meldung, ob die benötigte Information oder Aktion auch danach erreichbar bleibt. WCAG 2.2.1 erklärt den Unterschied: Ein kurz eingeblendeter Hinweis kann unkritisch sein, wenn dieselbe Information oder Funktion weiterhin ohne Zeitbegrenzung anders erreichbar ist. Ohne diesen Zugang muss die Zeitbegrenzung die Anforderungen des Kriteriums erfüllen, sofern keine Ausnahme greift.

Für einen Warenkorb kann der neue Inhalt dauerhaft sichtbar bleiben. Bietet ein Toast „Rückgängig“ an, halte dieselbe Aktion auch nach dem Ausblenden an anderer Stelle bereit. Andernfalls muss die Zeitbegrenzung WCAG 2.2.1 erfüllen, etwa durch eine Möglichkeit zum Abschalten, Anpassen oder Verlängern, sofern keine Ausnahme greift. Dass der Button kurz per Tastatur erreichbar ist, reicht allein nicht.

Was prüfst Du im Browser, was mit dem Screenreader?

Prüfe zuerst den Ablauf per Tastatur. Danach wiederholst Du ihn mit eingeschaltetem Screenreader:

1. Lade die Seite neu. Ist die leere Statusregion schon vorhanden?
2. Löse die Aktion aus. Erscheint die passende Nachricht, während der Fokus am Auslöser bleibt?
3. Löse die Aktion ein zweites Mal aus. Prüfe geänderte und identische Nachrichten getrennt.
4. Notiere den gehörten Wortlaut, die Verzögerung und mögliche Unterbrechungen. Dokumentiere Browser, Screenreader und Versionen.
5. Bei kurz sichtbaren Toasts: Prüfe den Zustand, solange die Meldung erscheint, und nach dem Ausblenden. Sind dieselbe Information und angebotene Aktionen wie „Rückgängig“ weiterhin ohne Zeitdruck erreichbar? Falls nicht: Erfüllt die Zeitbegrenzung WCAG 2.2.1?

Scanne Ausgangszustand und Meldungszustand getrennt, etwa lokal mit dem Workflow aus dem Entwickler-Leitfaden. Ein DOM-Scan kann Rollen und andere maschinell prüfbare Eigenschaften untersuchen. Er hört keine Sprachausgabe. Eine fehlende Ansage oder störende Wiederholung wird durch einen Scan ohne Befunde nicht ausgeschlossen.

Die Beispiele zeigen zwei Einfügeabläufe, keine aktuelle Vergleichsmatrix für NVDA, JAWS oder VoiceOver. Eigene Sprachtests stehen noch aus. Die Grundlagen für Labels und zugeordnete Fehler findest Du im Formular-Leitfaden.