4.1.2 Name, Rolle, Wert

1. Was ist das Ziel dieses Kriteriums?

Ein Screenreader versucht, einen Button zu beschreiben, aber alles, was er findet, ist ein <div> ohne Namen – wie ein Fremder, der an die Tür klopft, aber keinen Namen nennt. Menschen, die auf assistive Technologien angewiesen sind, stehen vor einem Rätsel: Was macht dieses Element? Wie kann ich es bedienen?

Das Ziel von Erfolgskriterium 4.1.2 der WCAG ist daher klar: Alle Bedienelemente müssen für assistive Technologien verständlich sein. Sie brauchen einen Namen (Wie heiße ich?), eine Rolle (Was für ein Element bin ich?) und Informationen über ihren aktuellen Zustand und Wert (In welchem Zustand befinde ich mich?).

Kurz gesagt: Der Code muss die Sprache sprechen, die assistive Technologien verstehen.

2. Was fordert das Erfolgskriterium genau?

Ganz konkret geht es um alle Bedienkomponenten – von Formularelementen über Links bis hin zu selbst programmierten Widgets:

Name und Rolle sind programmatisch ermittelbar:

• Jedes Bedienelement braucht einen Namen, den assistive Technologien auslesen können
• Die Rolle (Button, Link, Eingabefeld, Checkbox …) muss eindeutig erkennbar sein
• Das gilt auch für per Skript erzeugte Komponenten

Zustände, Eigenschaften und Werte sind verfügbar:

• Zustände, Eigenschaften und Werte, die du als Nutzer:in ändern kannst, müssen auch programmatisch setzbar sein
• Änderungen daran müssen an Browser und assistive Technologien gemeldet werden
• Beispiele: ob eine Checkbox aktiviert ist, ob ein Menü aufgeklappt ist, welchen Wert ein Schieberegler hat, welcher Tab ausgewählt ist

Gut zu wissen: Standard-HTML-Elemente erfüllen dieses Kriterium bereits, wenn sie gemäß Spezifikation verwendet werden. Probleme entstehen meist bei selbst programmierten Widgets oder wenn HTML-Elemente zweckentfremdet werden.

3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du benutzt ein Navigationssystem, aber alle Straßenschilder sind leer – so fühlt es sich an, wenn assistive Technologien keine Informationen über Bedienelemente erhalten.

Name, Rolle und Wert schaffen Klarheit, weil sie:

• Screenreader-Nutzer:innen ermöglichen, zu verstehen, was ein Element macht und wie sie es bedienen können
• Sprachsteuerung erlauben, Elemente gezielt anzusprechen („Klicke auf Senden“)
• Menschen, die mit Schaltern oder anderen alternativen Eingabegeräten arbeiten, die Bedienelemente zuverlässig anbieten
• Screenreader-Nutzer:innen über Zustände informieren, etwa ob ein Menü offen oder eine Option gewählt ist
• kognitiv unterstützen, weil Elemente klar und einheitlich bezeichnet sind

Und nicht zuletzt: Sie machen Websites robuster und wartungsfreundlicher – auch für Entwicklerwerkzeuge und automatisierte Tests.

4. So setzt du das Kriterium erfolgreich um

Die gute Nachricht: Wenn du semantisches HTML verwendest, bist du bereits auf dem richtigen Weg. Hier die wichtigsten Tipps:

Verwende natives HTML, wo möglich:

• <button> statt <div onclick="…"> für Buttons
• <input> mit verknüpftem <label> für Eingabefelder
• <a href="…"> für Links
• <select> für Auswahlmenüs

Für eigene Widgets nutze ARIA – aber vollständig:

• role="button" für einen nachgebauten Button – dann aber auch mit tabindex="0" und Bedienung per Enter und Leertaste (siehe Tastatur). Einfacher ist fast immer ein echtes <button>.
• aria-label="Beschreibung" für Elemente ohne sichtbaren Text, etwa Icon-Buttons
• aria-labelledby="id", um auf eine sichtbare Beschriftung zu verweisen
• aria-expanded="true" bzw. "false" für auf- und zuklappbare Bereiche
• aria-checked nur bei eigenen Elementen mit role="checkbox" oder role="switch" – native Checkboxen bringen ihren Zustand selbst mit

Halte Namen prägnant und funktional:

• „Senden“ statt „Hier klicken“
• „Hauptmenü öffnen“ statt nur ein Burger-Icon ohne Namen
• „Preis aufsteigend sortieren“ statt „Sortieren“
• Bei sichtbarer Beschriftung muss der zugängliche Name diese enthalten (siehe Beschriftung im Namen)

Denk an Zustandsänderungen:

• Aktualisiere Attribute wie aria-expanded, aria-pressed oder aria-selected per Skript, sobald sich der Zustand ändert
• Bei Formularvalidierung verwende aria-invalid und aria-describedby
• Für Meldungen über Änderungen ohne Fokuswechsel gibt es Live-Regionen – das regelt Statusmeldungen

Werkzeuge für die Überprüfung:

• Browser-Entwicklertools (Bereich Barrierefreiheit bzw. Accessibility Tree)
• Screenreader wie NVDA, JAWS oder VoiceOver zum Testen
• Automatisierte Werkzeuge wie axe-core oder Lighthouse

5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

Auch bei Erfolgskriterium 4.1.2 gilt: Barrierefreiheit ist kein Selbstzweck – sondern bringt handfeste Vorteile für dein Business.

1. Zielgruppe erweitern

Gut benannte und strukturierte Bedienelemente sind nicht nur für Menschen mit Behinderungen wichtig. Sie verbessern die Nutzbarkeit für alle – auch für Menschen, die per Spracheingabe navigieren oder in stressigen Situationen schnell das richtige Element finden müssen.

2. Saubere Semantik – auch für Maschinen

Barrierefreiheit ist kein direkter Google-Rankingfaktor. Semantisch korrektes HTML macht Inhalte aber für alle Programme besser lesbar – für assistive Technologien genauso wie für Crawler, Browser-Funktionen oder Testautomatisierung.

3. Code-Qualität und Wartbarkeit steigern

Sauberer, semantischer Code mit klaren Bezeichnungen ist einfacher zu warten, zu testen und zu debuggen. Viele Testwerkzeuge finden Elemente sogar direkt über Rolle und Namen – gute Barrierefreiheit erleichtert also auch automatisierte Tests.

Und nicht zuletzt die rechtliche Seite: Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele digitale Angebote für Verbraucher:innen, etwa Online-Shops und Bankdienstleistungen. Technischer Maßstab ist die EN 301 549, die für Webinhalte auf WCAG 2.1 Level AA verweist – 4.1.2 gehört dazu. Öffentliche Stellen sind über die BITV 2.0 bzw. Landesrecht ohnehin verpflichtet. Dieser Abschnitt informiert allgemein und ersetzt keine Rechtsberatung.

6. Das Erfolgskriterium im Wortlaut des W3C

Success Criterion 4.1.2 Name, Role, Value (Level A)

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Note: This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

Kurz gesagt: Für jedes Bedienelement sind Name und Rolle maschinenlesbar, veränderbare Zustände und Werte lassen sich programmatisch setzen, und Änderungen werden an assistive Technologien gemeldet.