WCAG 2.2 · Level AA · RobustBarrierefreiheit als Cloud-Service
4.1.3 Statusmeldungen
Statusmeldungen werden ohne Fokuswechsel vom Screenreader angesagt.
Auf einen Blick
Was bedeutet dieses Kriterium?
Kurz gesagt
Statusmeldungen werden ohne Fokuswechsel vom Screenreader angesagt.
Aufwand
Mittel umzusetzen, schnell erledigt
Betrifft Rolle
Entwicklung
Konformitätsstufe
Level AA
EN 301 549
Abschnitt 9.4.1.3 · BITV 2.0 · BFSG
Verständlich erklärt
Was heißt 4.1.3 für die Praxis?
Statusmeldungen werden ohne Fokuswechsel vom Screenreader angesagt.
Erfolgsmeldungen, Warnungen und Fortschrittsanzeigen mit aria-live='polite' oder role='status' auszeichnen, damit Screenreader sie automatisch vorlesen.
Technisch formuliert: Statusmeldungen können programmatisch bestimmt werden, sodass sie von assistiven Technologien präsentiert werden können, ohne den Fokus zu erhalten.
Wer ist betroffen?
Ein Alltagsbeispiel
Nicht jeder Nutzer öffnet Ihre Seite im neuesten Chrome auf dem Desktop. Screenreader, Sprachsteuerungen, ältere Browser, Tablets oder Spezial-Hardware sollen die Seite alle gleich gut darstellen können. Dieses Kriterium stellt sicher, dass das funktioniert. Besonders betroffen sind: Blinde Menschen.
Die Lösung
So setzen Sie es richtig um
Erfolgsmeldungen, Warnungen und Fortschrittsanzeigen mit aria-live='polite' oder role='status' auszeichnen, damit Screenreader sie automatisch vorlesen.
Statusmeldungen können programmatisch bestimmt werden, sodass sie von assistiven Technologien präsentiert werden können, ohne den Fokus zu erhalten.
Umsetzung
Schritt für Schritt
Konkrete Anleitung zur praktischen Umsetzung dieses Kriteriums.
- 1
Statusmeldungen identifizieren
'Erfolgreich gespeichert', 'Fehler aufgetreten', 'Wird geladen...' — all das sind Statusmeldungen.
- 2
aria-live oder role='status' setzen
<div role='status' aria-live='polite'>Erfolgreich gespeichert</div>
Praxisbeispiele
So nicht — sondern so
So nicht
Erfolgsmeldung erscheint visuell, wird aber nicht von Screenreadern vorgelesen.
Sondern so
<div role="status">Ihre Nachricht wurde erfolgreich gesendet.</div>
Warum?
role='status' sorgt für automatische Screenreader-Ansage
Typische Fehler
Das wird häufig falsch gemacht
Diese Fehler sehen wir in der Praxis besonders oft — und wie Sie sie vermeiden.
ARIA als Allheilmittel
ARIA wird oft eingesetzt, wo einfaches HTML ausreichen würde. Falsche ARIA ist schlimmer als keine ARIA.
Nur in einem Browser testen
Verschiedene Browser und Hilfsprogramme interpretieren Code unterschiedlich. Tests in mindestens 2 Browsern mit mindestens einem Screenreader sind Pflicht.
Selbst prüfen
So testen Sie dieses Kriterium
Mit diesen Methoden können Sie selbst prüfen, ob Ihre Webseite das Kriterium erfüllt.
Mit verschiedenen Browsern testen
Chrome, Firefox, Safari — alle sollten die Seite gleich interpretieren. Unterschiede weisen oft auf falsches HTML oder ARIA hin.
Screenreader-Kompatibilität prüfen
VoiceOver, NVDA und JAWS verhalten sich unterschiedlich. Testen Sie mit mindestens einem, idealerweise zwei.
HTML validieren
Der W3C Validator zeigt strukturelle Fehler im HTML. Valides HTML ist die Grundlage für robuste Barrierefreiheit.
Häufige Fragen
Fragen und Antworten
Ist Level AA für mich relevant?▾
Wie kann ich prüfen, ob meine Seite dieses Kriterium erfüllt?▾
Welche anderen Kriterien hängen damit zusammen?▾
Verwandte Kriterien
Weiterführende Erfolgskriterien
Diese Kriterien stehen in engem Zusammenhang mit 4.1.3 und sollten gemeinsam betrachtet werden.