Statusmeldungen (WCAG-Kriterium 4.1.3)
Was bedeutet dieses Kriterium und was sind die häufigsten Barrieren?
Was bedeutet das Kriterium?
Wenn wichtige Änderungen am Inhalt passieren, die nicht fokussiert sind, dann müssen alle Nutzer:innen in angemessener Weise darüber informiert werden, damit sie die Änderungen auch direkt wahrnehmen können. Solche Informationen können sein: Auskunft über den Erfolg oder die Ergebnisse einer Aktion, über den Wartezustand einer Anwendung, über den Fortschritt eines Prozesses oder über vorliegende Fehler. Das Kriterium betrifft keine Meldungen, die im Rahmen von Kontextänderungen passieren, z. B. wenn eine Seite neu lädt oder ein Dialogfenster geöffnet wird.
Warum und für wen ist das Kriterium wichtig?
In erster Linie richtet sich dieses Kriterium an blinde und sehbehinderte Nutzer:innen, die assistierende Technologien (Screenreader) verwenden. Über Statusmeldungen können sie über Änderungen informiert werden, die sonst nur visuell kommuniziert werden würden. Drei Beispiele dafür:
- Wenn nach Aktivierung eines „Suchen“-Buttons der Inhalt der Seite aktualisiert wird, um die Suchergebnisse unterhalb der Suchfunktion anzuzeigen mit einer dazugehörigen Information „7 Suchergebnisse gefunden“. Dann muss dieser Text entsprechend als Statusmeldung ausgezeichnet werden, damit ein Screenreader „7 Suchmeldungen gefunden“ ausgibt und die Nutzer:innen über diese Inhaltsänderung informiert sind.
- Wenn ein Eingabefeld für eine E-Mail-Adresse fehlerhaft ausgefüllt wird und über dem Feld dann ein Hinweis wie „E-Mail-Adresse, ungültige Eingabe“ angezeigt wird, muss auch ein Screenreader „Ungültige Eingabe“ oder „E-Mail-Adresse, ungültige Eingabe“ ausgeben.
- Wenn Nutzer:innen einen länger dauernden Prozess (wie bspw. eine Berechnung) starten und visuell ein Icon erscheint, welches „in Arbeit“ oder „wird geladen“ symbolisiert, dann muss ein Screenreader auch eine passende Meldung wie „wird geladen“ oder „Berechnung in Arbeit“ ausgeben. Sonst ist für Screenreader-Nutzer:innen nicht erkennbar, dass der Prozess erfolgreich in Gang gesetzt worden ist.
Was sind die häufigsten Fehler bei diesem Kriterium und wie können sie behoben bzw. vermieden werden?
Keine Statusmeldungen zu fehlerhaften Eingaben vorhanden:
Werden während des Ausfüllens von Formularfeldern Fehlermeldungen zu fehlerhaften Angaben eingeblendet oder wird nach dem Abschicken eines fehlerhaft ausgefüllten Formulars eine Fehlermeldung zum existierenden Formular hinzugefügt, dann müssen diese Informationen auch via Statusmeldungen für Screenreader zur Verfügung gestellt werden.
Keine Statusmeldungen zu Suchergebnissen vorhanden:
Nach der Aktivierung eines „Suchen“-Buttons werden die Suchergebnisse und die Information über die Anzahl der gefundenen Suchergebnisse unterhalb der Suchfunktion eingeblendet. Die Information zur Anzahl der gefundenen Suchergebnisse muss auch als Statusmeldung für Screenreader ausgegeben werden, damit sie allen Nutzer:innen zur Verfügung steht.
Keine Statusmeldungen zu angewendeten Filtern:
Wenn sich vorhandene Inhalte dynamisch ändern, weil sie gefiltert wurden, dann müssen Informationen darüber auch via Statusmeldung an Screenreader-User:innen kommuniziert werden, beispielsweise die Anzahl der Inhalts-Elemente, die nach der Anwendung des Filters verfügbar sind.
Eingabe-Vorschläge werden nicht für Screenreader ausgegeben:
Bei Eingabefeldern, bei denen Eingabe-Vorschläge angezeigt werden, sobald Zeichen eingegeben wurden, müssen diese Informationen auch als Statusmeldungen zur Verfügung stehen, damit auch Screenreader-Nutzer:innen die Eingabe-Vorschläge wahrnehmen und nutzen können. Eine beispielhafte Umsetzung findet sich unter „Predictive Text“ auf der Website der Deque University (externer Link).