BITV 2.0 – Priorität I WCAG 2.2: 4.1 EN 301 549: 9.4.1

Anforderung 4.1: Kompatibel

Anforderung 4.1 der BITV 2.0 betrifft ARIA, Screenreader-Kompatibilität, Name Rolle Wert und Statusmeldungen, damit technische Schnittstellen sauber mit Hilfstechnologien zusammenarbeiten. Wenn Bedienelemente nicht korrekt benannt, zugeordnet oder aktualisiert werden, können Screenreader ihren Zweck nicht zuverlässig ausgeben. WCAG 4.1 und EN 301 549 geben deshalb Regeln für die programmatisch erkennbare Struktur und für dynamische Rückmeldungen vor. Wichtig ist auch: 4.1.1 Syntaxanalyse ist in WCAG 2.2 als obsolet markiert und wurde aus dem Normkern entfernt; für die Praxis bleibt 4.1.2 besonders relevant. Das ist für öffentliche Stellen ebenso wichtig wie für bestimmte Produkte und Dienstleistungen für Verbraucherinnen und Verbraucher im BFSG.

Geltungsbereich: BITV 2.0 gilt für öffentliche Stellen. Das BFSG gilt seit dem 28. Juni 2025 für bestimmte Produkte und Dienstleistungen für Verbraucherinnen und Verbraucher. 4.1.2 und 4.1.3 sind verbindlich; 4.1.1 ist in WCAG 2.2 obsolet und damit nicht mehr Teil des aktuellen Normkerns.

Normtext – BITV 2.0 Anlage 1, Anforderung 4.1

Quelle: BITV 2.0, Anlage 1 (gesetze-im-internet.de) · Einzelkriterien nach WCAG 2.2 Richtlinie 4.1 (w3.org)

Was wird bei Anforderung 4.1 gefordert?

  • 4.1.1 Syntaxanalyse: Obsoletes Kriterium aus früheren WCAG-Fassungen; in WCAG 2.2 als obsolet und entfernt gekennzeichnet.
  • 4.1.2 Name, Rolle, Wert: Komponenten müssen ihren zugänglichen Namen, ihre Rolle und ihren Zustand programmatisch offenlegen.
  • 4.1.3 Statusmeldungen: Dynamische Hinweise sollen von Screenreadern erkannt werden, ohne den Fokus zu verschieben.

4.1.1 Syntaxanalyse

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.4.1.1

Dieses Kriterium ist in WCAG 2.2 als obsolet markiert und wurde aus dem aktuellen Normkern entfernt. Historisch ging es darum, dass HTML und andere Markups sauber geparst werden können, damit Hilfstechnologien die Struktur verstehen. Für heutige Webinhalte ist das Thema weiterhin technisch interessant, aber im WCAG-2.2-Kern nicht mehr als eigenständiges Kriterium geführt. In der Praxis wird der Fokus deshalb auf die aktuellen Anforderungen 4.1.2 und 4.1.3 gelegt.

Umsetzung: Auch wenn 4.1.1 obsolet ist, sollte der Code weiterhin valide und sauber aufgebaut sein. Ein Custom-Button ohne korrektes Markup kann trotzdem Probleme verursachen, selbst wenn das alte Syntaxkriterium nicht mehr im Mittelpunkt steht. Praktisch sinnvoll ist daher ein robustes, semantisches HTML mit möglichst wenig fehleranfälligen Konstruktionen.

4.1.2 Name, Rolle, Wert

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.4.1.2

Bedienelemente müssen ihren Namen, ihre Rolle und ihren Wert bzw. Zustand programmatisch offenlegen. Das ist die Grundlage dafür, dass Screenreader und andere Hilfstechnologien verstehen, was ein Element ist und was es gerade macht. Ein Custom-Button, ein Akkordeon oder ein Checkbox-Widget ist ohne diese Informationen oft nur schwer nutzbar. Die Anforderung sorgt also für Screenreader-Kompatibilität auf technischer Ebene.

Umsetzung: Nutze bei Custom-Buttons passende Rollen und Namen, zum Beispiel aria-label, wenn kein sichtbarer Text vorhanden ist. Ein Warenkorbzähler sollte seinen Zustand programmatisch melden, damit er nicht nur optisch, sondern auch technisch verständlich ist. Bei Schaltern, Tabs oder Akkordeons müssen Name, Rolle und aktueller Zustand immer konsistent bleiben.

4.1.3 Statusmeldungen

BITV 2.0 – Priorität I WCAG A EN 301 549: 9.4.1.3

Statusmeldungen sind dynamische Hinweise wie „Artikel zum Warenkorb hinzugefügt“, „Fehler beim Speichern“ oder „Filter angewendet“. Sie sollen von Hilfstechnologien mitgeteilt werden, ohne dass der Fokus springt oder Nutzer die Stelle verlieren. Das ist besonders wichtig bei SPA-Oberflächen, Formularen und Einkaufsprozessen. Gute Statusmeldungen geben Rückmeldung, ohne den Arbeitsfluss zu stören.

Umsetzung: Nutze für solche Meldungen geeignete Live-Regionen wie aria-live, damit Screenreader Änderungen automatisch ankündigen. Ein Warenkorbzähler kann etwa mitteilen, dass ein Produkt hinzugefügt wurde, ohne den Nutzer von der aktuellen Stelle wegzulenken. Fehler- oder Erfolgsmeldungen sollten kurz, klar und direkt verständlich sein.

Häufige Fragen zu Anforderung 4.1

Was ist ARIA und wann sollte es eingesetzt werden?

ARIA ist ein technisches Mittel, um Rolle, Zustand oder Beschriftung von Bedienelementen für Hilfstechnologien bereitzustellen. Es sollte vor allem dann eingesetzt werden, wenn native HTML-Elemente nicht ausreichen, etwa bei Custom-Widgets. Für einfache Standard-Elemente ist natives HTML meist die bessere Wahl.

Was sind Statusmeldungen und warum brauchen sie aria-live?

Statusmeldungen informieren über Änderungen, ohne dass der Fokus wechseln muss. Mit `aria-live` können Screenreader solche Änderungen automatisch ankündigen. Das ist wichtig bei Warenkorb-Aktionen, Fehlermeldungen oder Filterergebnissen.

Was bedeutet "Name, Rolle, Wert" in der Praxis?

Es bedeutet, dass ein Element für Hilfstechnologien erkennbar sein muss: wie es heißt, was es ist und welchen Zustand es hat. Ein Schalter muss also nicht nur sichtbar, sondern auch technisch als Schalter mit aktuellem Zustand erkannt werden. So funktioniert die Bedienung auch ohne Sichtkontakt.

Einordnung in weitere Normen

Anforderung 4.1 basiert auf WCAG 2.2 Richtlinie 4.1. Im europäischen Standard EN 301 549 sind die normativen Anforderungen unter Abschnitt 9.4.1 verankert.

Offizielle Quellen