Erfolgskriterien

WCAG 4.1.3 Statusmeldungen

Erfolgskriterium 4.1.3 verlangt, dass Statusmeldungen programmatisch über Rolle oder Eigenschaften so bestimmt werden können, dass sie dem Nutzer von assistiver Technologie präsentiert werden können, ohne den Fokus zu erhalten. Es ist ein Kriterium der Stufe AA unter Richtlinie 4.1 (Kompatibel), hinzugefügt in WCAG 2.1.

Das Problem, das dies löst

Viele moderne Web-Interaktionen aktualisieren die Seite ohne vollständiges Neuladen – "Artikel zum Warenkorb hinzugefügt", "3 neue Benachrichtigungen", "Ihre Änderungen wurden gespeichert", eine Live-Suchergebniszahl, die sich beim Tippen aktualisiert. Ein sehender Nutzer sieht diese visuell erscheinen. Ein Screenreader-Nutzer, dessen Fokus sich nirgendwo hin bewegt hat, hat keine Möglichkeit zu wissen, dass die Aktualisierung überhaupt stattgefunden hat, es sei denn, die Seite kündigt sie ausdrücklich an – die Aktualisierung kann vollständig außerhalb seiner Wahrnehmung erscheinen und verschwinden.

Warum "ohne den Fokus zu erhalten" wichtig ist

Das Kriterium verlangt dies ausdrücklich, OHNE den Tastaturfokus zu bewegen, denn den Fokus zwangsweise zu jeder Statusaktualisierung zu bewegen wäre selbst ein störender Verstoß (es würde unterbrechen, was der Nutzer gerade tat, ähnlich dem Problem, vor dem 3.2.1 Bei Fokus und 3.2.2 Bei Eingabe schützen). Der richtige Mechanismus kündigt die Meldung neben dem an, was der Nutzer gerade tut, ohne seine Aufmerksamkeit umzulenken.

Die Lösung: ARIA-Live-Regionen

<div role="status" aria-live="polite">
  Artikel zum Warenkorb hinzugefügt
</div>

aria-live="polite" teilt assistiver Technologie mit, den Inhalt dieses Bereichs anzukündigen, wenn er sich ändert, ohne das zu unterbrechen, was der Nutzer gerade tut – die Ansage reiht sich höflich ein, statt laufende Sprachausgabe abzuschneiden. role="status" (oder role="alert" für dringendere Meldungen, das aria-live="assertive" verwendet und sofort unterbricht) sind Kurzform-Rollen, die das passende Live-Regionen-Verhalten automatisch implizieren.

Häufige Stellen, an denen dies fehlt

  • Toast-/Snackbar-Benachrichtigungen ("Erfolgreich gespeichert"), die visuell erscheinen und sich automatisch schließen, ganz ohne Live-Regionen-Ansage
  • Live-Suchergebnisse, die eine Ergebniszahl beim Tippen des Nutzers aktualisieren, ohne die neue Zahl anzukündigen
  • Formularvalidierungs-Zusammenfassungen, die nach der Übermittlung erscheinen, ohne in eine Live-Region eingebunden zu sein, und sich nur auf die visuelle Platzierung nahe dem oberen Formularrand verlassen

Ein Hinweis zur Übernutzung

Live-Regionen lassen sich leicht übernutzen – zu viele kleinere UI-Aktualisierungen speziell in aria-live="assertive" einzubinden kann eine Flut von Unterbrechungen erzeugen, die schlimmer ist als gar keine Ansage. Reservieren Sie Live-Regionen für tatsächlich bedeutsame Statusänderungen, und verwenden Sie standardmäßig polite statt assertive, es sei denn, die Meldung ist wirklich dringend.

Häufige Fragen

Was ist WCAG 4.1.3 Statusmeldungen?
Ein Kriterium der Stufe AA: Meldungen über Status (Erfolg, Fehler, Fortschritt, Trefferzahl) müssen programmatisch bereitgestellt werden, damit Screenreader sie ansagen, ohne dass Nutzer den Fokus bewegen.
Wie setze ich 4.1.3 um?
Verwenden Sie einen passenden ARIA-Live-Bereich (aria-live, role='status' oder role='alert'), damit Aktualisierungen automatisch angesagt werden.
Was ist ein typischer Verstoß?
Eine Meldung wie `3 Treffer gefunden` oder `Artikel in den Warenkorb gelegt`, die nur visuell erscheint und nie angesagt wird, sodass Screenreader-Nutzer die Änderung nicht bemerken.

Möchten Sie sehen, wie Ihre eigene Website abschneidet?

Kostenlosen Barrierefreiheitsscan durchführen