ARIA-Live-Regionen: Statusmeldungen ansagen
Also called: aria-live, Live-Region, Statusmeldung
Definition
Eine ARIA-Live-Region ist ein Seitenbereich, der mit aria-live oder einer Live-Rolle wie status oder alert ausgezeichnet ist. Ändert sich sein Inhalt, sagt der Screenreader den neuen Text an, ohne dass der Fokus dorthin wandern muss.
ARIA-Live-Regionen sind Bereiche einer Seite, die assistiver Technologie signalisieren: „Änderungen hier bitte ansagen“. Legt jemand einen Artikel in den Warenkorb, liefert die Suche Treffer oder erscheint neben einem Feld eine Fehlermeldung, sehen Sehende das sofort. Wer mit einem Screenreader arbeitet, erfährt davon nur, wenn die Meldung in einer Live-Region steht – sonst passiert die Änderung lautlos.
Was es bedeutet
WCAG 4.1.3 Statusmeldungen (Stufe AA, WCAG 2.2) verlangt, dass Statusmeldungen über Rolle oder Eigenschaften programmatisch ermittelbar sind. Assistive Technologie muss sie ausgeben können, ohne dass die Meldung den Fokus erhält. Das W3C definiert eine Statusmeldung als Inhaltsänderung ohne Kontextwechsel, die über das Ergebnis einer Aktion, einen Wartezustand, den Fortschritt eines Vorgangs oder vorhandene Fehler informiert.
Typische Beispiele aus der W3C-Erläuterung: „5 Ergebnisse gefunden“ nach einer Suche, ein aktualisierter Warenkorb-Zähler, ein Hinweis „Ungültige Eingabe“ neben einem Feld, eine Ladeanzeige und eine Bestätigung nach dem Absenden eines Formulars.
ARIA bietet dafür mehrere Auszeichnungen:
| Auszeichnung | Ansage | Geeignet für |
|---|---|---|
role="status" |
Höflich – wartet, bis der Screenreader fertig ist | Treffer, Bestätigungen, Warenkorb-Zähler (W3C-Technik ARIA22) |
role="alert" |
Bestimmt – unterbricht sofort | Fehler und Warnungen, die jetzt wichtig sind (ARIA19) |
role="log" |
Höflich, neue Einträge der Reihe nach | Chatnachrichten, Aktivitätsverläufe (ARIA23) |
aria-live="polite" / "assertive" |
Wie oben, auf beliebigem Container | Eigene Komponenten ohne passende Rolle |
Das W3C nennt auch einen Fehler: role="alert" oder aria-live="assertive" für Inhalte, die weder wichtig noch zeitkritisch sind. Ständige Unterbrechungen machen eine Seite anstrengend.
Praxisbeispiele
<!-- Gut: Die Region existiert von Anfang an, der Text kommt später -->
<p role="status" id="warenkorb-status"></p>
<script>
document.getElementById('warenkorb-status').textContent = '3 Artikel im Warenkorb';
</script>
<!-- Gut: ein Fehler, der sofort Aufmerksamkeit braucht -->
<p role="alert">Zahlung fehlgeschlagen. Bitte prüfen Sie die Kartennummer.</p>
<!-- Schlecht: nur optische Änderung, wird nie angesagt -->
<span class="badge">3</span>Legen Sie die Live-Region beim Laden der Seite an und ändern Sie danach nur ihren Text. Halten Sie Meldungen kurz („Gespeichert“), verwenden Sie für die meisten Fälle role="status" und reservieren Sie role="alert" für echte Fehler.
Fügen Sie die Live-Region nicht erst zusammen mit der Meldung ein – viele Screenreader verpassen sie dann. Markieren Sie keine großen Bereiche wie eine ganze Produktliste als live, und verlassen Sie sich nicht allein auf Farbe oder ein Badge.
So prüfen Sie ARIA-Live-Regionen
Häufige Fragen
Was ist der Unterschied zwischen aria-live polite und assertive?
polite wartet, bis der Screenreader seine aktuelle Ausgabe beendet hat, und liest dann die Änderung vor. assertive unterbricht sofort. Nutzen Sie fast immer polite und assertive nur für dringende Fehler oder Warnungen.
Ist role="status" dasselbe wie aria-live="polite"?
Fast. role="status" bringt implizit aria-live="polite" und aria-atomic="true" mit, die ganze Meldung wird also vorgelesen. Zusätzlich erfährt die assistive Technologie, dass es sich um eine beratende Statusinformation handelt.
Warum sagt mein Screenreader die Live-Region nicht an?
Meist wurde die Region gemeinsam mit ihrem Text in die Seite eingefügt. Browser melden nur Änderungen in Regionen, die bereits existieren. Legen Sie beim Laden einen leeren Container an und befüllen Sie ihn später. Container mit display: none werden ebenfalls nicht angesagt.
Brauchen Fehlermeldungen in Formularen eine Live-Region?
Fehler, die ohne Fokuswechsel erscheinen, sind Statusmeldungen im Sinne von WCAG 4.1.3 und brauchen role="alert" oder eine Live-Region. Springt der Fokus stattdessen zu einer Fehlerübersicht, liest der Screenreader sie ohnehin vor. Verknüpfen Sie jede Meldung zusätzlich mit ihrem Feld, wie bei Formular-Beschriftungen beschrieben.
Related terms
ARIA: Rollen, Zustände und Eigenschaften erklärt
ARIA (WAI-ARIA, Accessible Rich Internet Applications) ist eine W3C-Spezifikation für HTML-Attribute – Rollen, Zustände und Eigenschaften –, die assistiven Technologien mitteilen, was ein eigenes Element ist, wie es heißt und in welchem Zustand es sich befindet.
Read definition: ARIA: Rollen, Zustände und Eigenschaften erklärtScreenreader: So lesen blinde Menschen Websites
Ein Screenreader ist eine assistive Software, die Inhalte und Bedienelemente des Bildschirms vorliest oder auf einer Braillezeile ausgibt. Er ist auf die Namen, Rollen und Zustände angewiesen, die eine Website über den Barrierefreiheitsbaum des Browsers bereitstellt.
Read definition: Screenreader: So lesen blinde Menschen WebsitesZugänglicher Name: Was er ist und woher er kommt
Der zugängliche Name ist der Text, den der Browser an assistive Technologien weitergibt, um ein Element zu benennen – etwa die Worte, die ein Screenreader für einen Button, Link oder ein Formularfeld ansagt. WCAG 4.1.2 verlangt für jedes Bedienelement einen programmatisch ermittelbaren Namen.
Read definition: Zugänglicher Name: Was er ist und woher er kommtaria-label: Elemente richtig benennen
aria-label ist ein ARIA-Attribut, das den zugänglichen Namen eines Elements als Text festlegt. Screenreader sagen diesen Namen statt des Elementinhalts an – deshalb wird es vor allem für Bedienelemente ohne sichtbaren Text verwendet, etwa Icon-Buttons.
Read definition: aria-label: Elemente richtig benennen