WCAG 4.1.2 Name, Rolle, Wert

Aktualisiert am 14. Oktober 2026 · Lesezeit: 3 Min.

Stufe: A · WCAG 2.0
EN 301 549: 9.4.1.2
Was der Check prüft: Teilweise automatisch: Klickbare Bildbereiche haben keine Beschreibung, Barrierefreiheits-Attribute stehen an den falschen Elementen, Einige Elemente haben eine Braille-Beschriftung, aber keinen normalen Namen, Selbst gebaute Schaltflächen haben keinen Namen, Barrierefreiheits-Attribute werden in der falschen Situation verwendet, Einige Elemente verwenden veraltete Barrierefreiheits-Rollen, Die ganze Seite ist für Screenreader ausgeblendet, Versteckte Elemente sind per Tastatur weiterhin erreichbar, Selbst gebaute Eingabefelder haben keine Beschriftung, Einige Beschriftungen stehen dort, wo Screenreader sie ignorieren, Selbst gebauten Bedienelementen fehlen nötige Angaben, Einige Elemente haben eine Rolle, die es nicht gibt, Einige Schalter und Kontrollkästchen haben keinen Namen, Einige Tooltips sind leer, Barrierefreiheits-Attribute sind falsch geschrieben, Barrierefreiheits-Attribute haben falsche Werte, Einige Schaltflächen haben keinen Namen, Manche Beschriftungen verweisen auf das falsche Element, Eingebettete Inhalte haben keinen Namen, Mehrere eingebettete Rahmen haben denselben Namen, Manche Formular-Schaltflächen haben keinen Namen, Eine Bild-Schaltfläche hat keine Textbeschreibung, Formularfelder haben keine Beschriftung, Einige Links sagen nicht, wohin sie führen, Klickbare Elemente sind ineinander verschachtelt, Ein Auswahlmenü hat keine Beschriftung, Aufklappbare Bereiche haben keinen Namen
Offizieller Text: Understanding 4.1.2 Name, Role, Value (W3C, auf Englisch)

Das Erfolgskriterium 4.1.2 sorgt dafür, dass Screenreader, Sprachsteuerung und andere assistive Technologien jedes Bedienelement einer Seite verstehen und bedienen können. Ein Screenreader-Nutzer hört „Schalter, In den Warenkorb“; ein Nutzer von Sprachsteuerung sagt „klicke auf In den Warenkorb“. Hat ein Bedienelement keinen Namen, die falsche Rolle oder einen Zustand, der sich nie aktualisiert, können diese Nutzer nicht einkaufen. Es gehört zur Konformitätsstufe A und steht in EN 301 549 als Abschnitt 9.4.1.2. Das BFSG verweist über die harmonisierte Norm EN 301 549 auf diese Anforderungen.

Was das Erfolgskriterium verlangt

Für alle Komponenten der Benutzeroberfläche — unter anderem Formularelemente, Links und per Skript erzeugte Komponenten — gilt:

Name und Rolle sind programmatisch ermittelbar;
Zustände, Eigenschaften und Werte, die der Nutzer einstellen kann, lassen sich programmatisch setzen;
Benachrichtigungen über Änderungen dieser Elemente stehen User Agents einschließlich assistiver Technologien zur Verfügung.

Das W3C weist darauf hin, dass sich das Kriterium vor allem an Autoren richtet, die eigene Komponenten bauen oder per Skript steuern. Standard-HTML-Bedienelemente, die gemäß Spezifikation verwendet werden, erfüllen es bereits. Eigene Widgets — Menüs, Tabs, Akkordeons, Slider, eigene Auswahllisten — brauchen Rollen und Zustände über ARIA, und diese Zustände müssen sich mit dem Widget ändern.

Typische Fehler in Onlineshops

reine Icon-Buttons (Warenkorb, Suche, Schließen, Wunschzettel-Herz) ohne Text und ohne aria-label;
Produktbild-Links mit einem Bild ohne Alternativtext, sodass der Link keinen Namen hat;
eine Größen- oder Farbauswahl aus div-Elementen mit Klick-Handlern, ohne Rolle und ohne Auswahlzustand;
ein mobiler Menü-Button, dessen aria-expanded auf „false“ bleibt, wenn das Menü geöffnet ist;
Formularfelder ohne Label oder eine Auswahlliste ohne Namen;
mit aria-hidden="true" verborgene Elemente, die trotzdem den Tastaturfokus erhalten;
iframes für Video, Karten oder Zahlung ohne title;
ARIA-Attribute, die falsch geschrieben, für die Rolle nicht erlaubt sind oder ungültige Werte haben.

So prüfen Sie es

Automatisch: Unser Checker führt für dieses Kriterium viele Regeln aus, darunter button-name, link-name, label, select-name, input-button-name, frame-title, aria-hidden-focus, nested-interactive, aria-required-attr, aria-valid-attr-value und die übrigen ARIA-Regeln (siehe Regelliste). Er meldet jedes fehlerhafte Element mit seinem Selektor. Ob ein Name aussagekräftig ist oder ob sich Zustände bei der Bedienung aktualisieren, kann er nicht beurteilen.

Manuell: Nutzen Sie einen Screenreader (NVDA unter Windows, VoiceOver unter macOS oder iOS) und gehen Sie Header, Produktseite und Checkout durch. Achten Sie bei jedem Bedienelement auf einen sinnvollen Namen, die richtige Rolle und den aktuellen Zustand. Öffnen und schließen Sie Menüs, Akkordeons und Variantenauswahlen und prüfen Sie, ob die Zustandsänderungen angesagt werden.

So beheben Sie es

Verwenden Sie native Elemente: <button> für Aktionen, <a href> für Links, <input>, <select> mit <label>.
Geben Sie reinen Icon-Bedienelementen einen zugänglichen Namen, mit visuell verborgenem Text oder aria-label.
Folgen Sie bei eigenen Widgets dem Muster der ARIA Authoring Practices und aktualisieren Sie aria-expanded, aria-checked, aria-selected zusammen mit der Oberfläche.
Platzieren Sie nie fokussierbare Elemente in aria-hidden-Inhalten; geben Sie jedem iframe einen title.

Häufige Fragen

Was bedeutet Name, Rolle, Wert?

Der Name ist, wie ein Bedienelement heißt („In den Warenkorb“), die Rolle, was für ein Bedienelement es ist (Button, Link, Checkbox), und der Wert oder Zustand seine aktuelle Einstellung (angehakt, aufgeklappt, 3 Artikel). Assistive Technologien brauchen alle drei.

Erfüllen Standard-HTML-Elemente 4.1.2?

Ja, wenn sie gemäß Spezifikation verwendet werden. Ein echter Button, Link, ein input oder select mit Label meldet Name, Rolle und Wert. Probleme entstehen meist bei eigenen Bedienelementen aus div- und span-Elementen.

Kann ein automatischer Checker Probleme mit 4.1.2 finden?

Er findet viele davon: Buttons und Links ohne Namen, Formularfelder ohne Label, ungültige oder fehlende ARIA-Attribute, versteckte Elemente, die trotzdem den Fokus erhalten können. Ob ein Name aussagekräftig ist oder ob sich Zustände bei der Bedienung korrekt aktualisieren, kann er nicht erkennen.

Ist ARIA hinzuzufügen immer die Lösung?

Nein. Ein natives HTML-Element ist meist robuster als ARIA an einem div. Fehlerhaftes ARIA kann ein Bedienelement schlechter machen als gar kein ARIA.