Statusmeldungen

Was gefordert wird

Wenn die Seite eine Rückmeldung gibt — „Artikel in den Warenkorb gelegt“, „3 Ergebnisse gefunden“, „Verbindung unterbrochen“, „Speichern…“ — muss diese Meldung Screenreader-Nutzende erreichen, ohne dass der Fokus verschoben wird. Die Information muss programmgesteuert als Statusmeldung bestimmbar sein, damit assistive Technologie sie aufnehmen und vorlesen kann.

WCAG nennt drei Kategorien:

• Erfolg / Abschluss — „Profil gespeichert“, „E-Mail gesendet.“
• Ergebnis einer Aktion — „12 Ergebnisse“, „Keine Treffer gefunden.“
• Anwendungszustand — „Speichern…“, „Verbindung wird wiederhergestellt“, „Upload 40 %.“

Umsetzung

• Beim Laden der Seite sollte ein Live-Bereich im DOM platziert werden — ein leeres Element mit role="status" (höflich) oder role="alert" (unterbrechend). Bei einer Aktualisierung wird der neue Text eingefügt.
• Für unkritische Bestätigungen und Ergebnisanzahlen empfiehlt sich role="status" oder aria-live="polite". Screenreader warten, bis die nutzende Person inaktiv ist, und lesen dann vor.
• Bei kritischen Meldungen — Fehler bei der Formularübermittlung, Verbindungsabbruch, bevorstehender Sitzungsablauf — sollte role="alert" oder aria-live="assertive" verwendet werden. Die Ankündigung unterbricht die laufende Ausgabe.
• Toast-Benachrichtigungen benötigen einen Live-Bereich. Der Toast-Container muss vor dem Erscheinen des Toasts im DOM vorhanden sein und aria-live gesetzt haben; der Toast-Text wird anschließend als Kindelement eingefügt.
• aria-live sollte mit aria-atomic="true" kombiniert werden, wenn der gesamte Bereich bei jeder Aktualisierung neu vorgelesen werden soll — nicht nur die geänderten Knoten.
• Bei Formularfehlern kann die eingebettete Fehlermeldung role="alert" verwenden; alternativ kann der Fokus auf eine Zusammenfassung am Seitenanfang verschoben werden — beides zusammen ist jedoch zu vermeiden, da die Meldung nur einmal gehört werden muss.

Typische Fehler

• Toast-Benachrichtigungen, die in ein Element gerendert werden, das vor dem Toast nicht existierte — der Live-Bereich-Listener wird nie angehängt, es wird nichts vorgelesen.
• Ein Erfolgs-Banner, das eingefügt wird, aber außerhalb jedes aria-live-Bereichs liegt — sehenden Nutzenden sichtbar, für Screenreader-Nutzende unsichtbar.
• Die Suchergebnisanzahl („12 von 340 angezeigt“), die nach dem Filtern stillschweigend aktualisiert wird. Nutzende navigieren in die Ergebnisse zurück, ohne zu wissen, ob sich etwas verändert hat.
• Formularvalidierung, die ein eingebettetes <span class="error"> ohne role="alert" oder aria-live aktualisiert — der Fehler erscheint, der Screenreader bleibt stumm.
• aria-live="assertive" für jede Statusmeldung. Ständige Unterbrechungen führen dazu, dass Screenreader-Nutzende die Seite stumm schalten.
• Fokus auf eine Statusmeldung verschieben, die weder eine Überschrift noch ein interaktives Element ist — der Fokus landet auf einem nicht fokussierbaren Element, und Tastaturnutzende verlieren ihre Position.
• „Speichern…“ / „Gespeichert“-Indikatoren, die eine CSS-Klasse umschalten, ohne den Textinhalt innerhalb eines Live-Bereichs zu aktualisieren.

Warum es wichtig ist

Statusmeldungen sind die Schwachstelle moderner Single-Page-Anwendungen. Die Seite lädt nie neu, der Fokus bewegt sich selten, und so ist das einzige Signal, dass etwas passiert ist, eine visuelle Änderung — für alle, die nicht auf den Bildschirm schauen, wertlos. 4.1.3 erzwingt Gleichwertigkeit: Wenn sehende Nutzende „In den Warenkorb gelegt“ sehen können, können Screenreader-Nutzende es hören. Die Lösung ist fast immer kostengünstig (ein Live-Bereich, der bei Aktualisierung befüllt wird), und das Fehlen bricht fast immer zentrale Abläufe — Checkout, Suche, Formularübermittlung, Echtzeit-Chat.