- Stufe
- AA
- Seit
- WCAG 2.1
4.1.3 Statusmeldungen
Meldungen, die ohne Fokuswechsel über ein Ergebnis, eine Wartezeit, einen Fortschritt oder einen Fehler informieren, müssen so ausgezeichnet sein, dass ein Screenreader sie ansagen kann.
/ Was es verlangt
Eine Statusmeldung ist eine Änderung des Inhalts, die kein Kontextwechsel ist und die Nutzende über Erfolg oder Ergebnis einer Aktion, den Wartezustand einer Anwendung, den Fortschritt eines Prozesses oder das Vorliegen von Fehlern informiert. Sehende bemerken, dass am Rand ihres Blickfelds „18 Ergebnisse“, „Gespeichert“ oder „5 Fehler auf der Seite“ erscheint. Screenreader-Nutzende hören nichts, solange die Meldung nicht über eine Rolle oder Eigenschaft zugänglich ist, etwa role="status", role="alert" oder einen aria-live-Bereich, damit assistive Technologie sie ausgeben kann, ohne dass die Meldung den Fokus erhält.
Der Anwendungsbereich ist eng. Inhalt, der mit einem Kontextwechsel kommt, etwa ein Fehler in einem Dialog, der den Fokus übernimmt, wird bereits angesagt und fällt nicht darunter. Ebenso wenig Inhalt, den eine von Nutzenden bediente Komponente zeigt oder verbirgt, etwa ein Akkordeon oder ein Tab, was 4.1.2 abdeckt, und neuer Inhalt, der kein Status ist, etwa die Liste der Suchergebnisse selbst oder zusätzliche Fragen in einem Formular. Das Kriterium verlangt nicht, Meldungen zu erzeugen, sondern nur, die gezeigten zugänglich zu machen. W3C merkt an, dass auch andere programmatische Wege zählen, bis hin zum direkten Aufruf von Barrierefreiheitsschnittstellen.
/ Woran Seiten scheitern
- Eine Suche aktualisiert sich an Ort und Stelle und schreibt „Keine Ergebnisse“ in ein einfaches div, sodass Screenreader-Nutzende davon nichts hören.
- Eine Benachrichtigung „Gespeichert“ wird ans Ende des body angehängt, ohne role="status" oder aria-live, und blendet nach drei Sekunden aus.
- Das Hinzufügen eines Artikels ändert den Warenkorbzähler von 0 auf 1 in einem span, der kein Live-Bereich ist.
- Eine Validierungsmeldung erscheint beim Verlassen eines Feldes darüber, außerhalb jedes Live-Bereichs.
- Das Skript, das eine Meldung zeigt, erzeugt den Live-Bereich im selben Moment, in dem es den Text hineinschreibt, sodass manche Kombinationen aus Browser und Screenreader nichts ansagen.
/ So prüfen Sie es selbst
- Lösen Sie jede dynamische Meldung aus: Suche und Filter, in den Warenkorb legen, Speichern, ein Formular mit und ohne Fehler absenden, Datei-Upload, jede Ladeanzeige.
- Notieren Sie, ob sich der Fokus bewegt. Bleibt er, wo er war, und erscheint Text, ist dieser Text eine Statusmeldung.
- Untersuchen Sie das Element mit der Meldung in den Entwicklerwerkzeugen. Es selbst oder ein Vorfahre braucht role="status", role="alert", role="log", aria-live="polite" oder "assertive" oder ein output-Element, und der Bereich sollte im DOM stehen, bevor die Meldung hineingeschrieben wird.
- Wiederholen Sie die Aktion mit NVDA in Firefox oder Chrome oder mit VoiceOver auf dem Mac und hören Sie auf die Meldung, ohne den Fokus zu bewegen.
- Prüfen Sie, ob die Ansage für sich verständlich ist, etwa „3 Artikel im Warenkorb“ statt nur „3“.
/ So beheben Sie es
- Legen Sie beim Laden einen leeren Container mit role="status" in die Seite und schreiben Sie die Meldung hinein, sobald das Ergebnis vorliegt.
- Verwenden Sie role="alert" nur für Fehler und Warnungen, die jetzt zählen, denn es unterbricht. Für Ergebnisse und Bestätigungen dient role="status", das höflich ist.
- Schreiben Sie bei einem Warenkorbzähler oder einer Trefferzahl den ganzen Satz in den Bereich oder setzen Sie aria-atomic="true", damit der Screenreader „3 Artikel“ sagt und nicht „3“.
- Verwenden Sie für eine laufende Folge von Aktualisierungen, etwa Chatnachrichten oder die Schritte eines langen Vorgangs, role="log".
- Rendern Sie in einem Komponenten-Framework einen Live-Bereich im Layout und schicken Sie die Meldungen dorthin, statt mit jeder Benachrichtigung einen neuen Bereich einzuhängen.
/ Was unser Scanner prüft
Hier ist eine Prüfung zugeordnet, live-region-missing, und sie läuft nur in unserer Browsererweiterung, nie im anonymen Website-Scan. Bei eingeschalteter Seitenbeobachtung erfasst ein MutationObserver hinzugefügte Elemente; gemeldet wird ein sichtbares Element mit bis zu 400 Zeichen Text außerhalb jedes aria-live-, status-, alert- oder log-Bereichs, das nach Klasse, ID oder Kürze wie eine Meldung aussieht. Der Formulartest tut dasselbe für Meldungen, die beim Verlassen eines Feldes sichtbar werden. Text, der sich in einem bestehenden Element ändert, sieht sie nicht, jeden aria-live-Wert, auch „off“, wertet sie als Ansage, und was ein Screenreader tatsächlich sagt, hört sie nicht.
/ Wer es verletzt, nach unseren eigenen Messungen
Der wöchentliche Index hat für dieses Kriterium keine Zahlen, weil keine Prüfung des Website-Scans es testen kann. Ein Mensch beurteilt es, und genau dafür gibt es ein manuelles Audit.
Eine Seite je Stelle, automatisch im Wochenrhythmus gemessen. Behebungen seit dem letzten Durchlauf erscheinen beim nächsten, und jede Eintragsseite bietet ein Recht auf Gegendarstellung.
/ Fragen zu diesem Kriterium
Brauchen Suchergebnisse einen Live-Bereich?
Die Ergebnisse nicht, die Statusmeldung dazu schon. W3C schreibt, dass die Ergebnisliste keine Statusmeldung ist, ein kurzer Text wie „18 Ergebnisse gefunden“ oder „Keine Ergebnisse“ dagegen schon, wenn er erscheint, ohne den Fokus zu übernehmen. Dieser Text gehört in ein Element mit role="status".
role="alert" oder role="status": was ist richtig?
role="status" für Ergebnisse, Bestätigungen und Fortschritt, die ein Screenreader ansagt, sobald er mit dem Vorlesen fertig ist. role="alert" für Fehler und Warnungen, die jetzt zählen, denn es unterbricht. W3C nennt role="alert" oder aria-live="assertive" bei Inhalten, die weder wichtig noch zeitkritisch sind, als häufigen Fehler.
Ist eine Meldung in einem modalen Dialog eine Statusmeldung?
Nein. Ein Dialog, der den Fokus übernimmt, ist ein Kontextwechsel, und schon die Fokusverschiebung lässt den Screenreader ihn ansagen, 4.1.3 greift also nicht. Das Kriterium gehört zur Stufe AA und kam mit WCAG 2.1 hinzu, eine Prüfung nach WCAG 2.0 enthält es daher nicht.