WCAG 4.1.2: Name, Rolle, Wert

WCAG 4.1.2 verlangt, dass für jedes Bedienelement Name und Rolle programmatisch ermittelbar sind, dass Zustände und Werte programmatisch gesetzt werden können und dass assistive Technologien über jede Änderung benachrichtigt werden. Kurz: Die Maschine muss wissen, was ein Element ist, wie es heißt und in welchem Zustand es sich befindet.

(Englisch: Name, Role, Value.)

Das Wichtigste in Kürze

• Drei Bausteine: Name (wie heißt es), Rolle (was ist es), Wert/Zustand (wie steht es gerade) – plus die Pflicht, Änderungen zu melden.
• Mit nativem HTML ist das Kriterium fast automatisch erfüllt. <button>, <a href>, <input> mit <label>, <select>, <details> liefern alle drei Angaben frei Haus.
• Verstöße entstehen beim Nachbau: das klickbare <div> ohne Rolle, der Custom-Toggle ohne Zustand, das gestylte Dropdown, das nur optisch offen ist.
• Der Zustand muss mitgeführt werden. Ein aria-expanded="false", das beim Öffnen nicht aktualisiert wird, ist schlimmer als keines – es sagt aktiv das Falsche.
• 4.1.2 ist die Existenzgrundlage assistiver Technologien: Screenreader, Sprachsteuerung und Switch-Systeme sprechen Elemente über genau diese Daten an.
• Im BITV-Test heißt der Prüfschritt „4.1.2 Name, Rolle, Wert verfügbar“. Geprüft wird jedes Bedienelement, das nicht mit Standard-HTML gebaut ist.
• Seit WCAG 2.2 ist 4.1.1 Parsing entfallen – die Anforderungen an gültiges Markup gehen in 4.1.2 auf.

Was heißt „programmatisch ermittelbar“?

Der Normtext richtet sich an alle Komponenten der Benutzerschnittstelle: Name und Rolle müssen programmatisch ermittelbar sein; Zustände, Eigenschaften und Werte, die von Nutzenden gesetzt werden können, müssen programmatisch setzbar sein; und Änderungen daran müssen assistiven Technologien mitgeteilt werden. Am Beispiel eines Aufklapp-Buttons:

• Name: „Filter anzeigen“ – aus dem Textinhalt, aus einem <label> oder notfalls aus aria-label (das den sichtbaren Text enthalten muss).
• Rolle: „Schalter“ – aus dem Element <button> oder, wenn es gar nicht anders geht, aus role="button".
• Wert/Zustand: „ausgeklappt“ oder „eingeklappt“ – aus aria-expanded, das bei jeder Änderung aktualisiert wird.

Die vierte Anforderung – Änderungen müssen gemeldet werden – wird am häufigsten übersehen. Es genügt nicht, aria-expanded beim Laden korrekt zu setzen; das Attribut muss bei jedem Umschalten mitgeführt werden. Andernfalls bekommt der Screenreader einen veralteten Zustand gemeldet, und das ist schlimmer als gar keine Angabe: Statt zu schweigen sagt er das Gegenteil dessen, was auf dem Bildschirm passiert.

Wortlaut und Techniken stehen im Understanding-Dokument des W3C zu 4.1.2; die erwarteten Muster für jedes Widget führen die ARIA Authoring Practices auf.

Wen betrifft es besonders?

Für Nutzerinnen von Screenreadern ist dieses Kriterium die Grundlage von allem: Angesagt wird ausschließlich, was über Name, Rolle und Zustand bekannt ist. Ein Element ohne Rolle wird nicht als Bedienelement erkannt, taucht in keiner Elementliste auf und lässt sich nicht gezielt ansteuern.

Sprachsteuerungs-Systeme brauchen den Namen als Befehl: „Klicke Filter anzeigen“ funktioniert nur, wenn genau dieser Name im Accessibility-Baum steht. Switch-Systeme springen von Bedienelement zu Bedienelement – und was keine Rolle hat, ist für sie kein Bedienelement.

Und es trifft eine Gruppe, die man nicht sieht: Automatisierte Tests, Browser-Erweiterungen, Vorlesefunktionen und zunehmend KI-Assistenten, die Oberflächen bedienen sollen, lesen denselben Baum. Ein sauberer Accessibility-Baum ist damit auch eine Wartbarkeits- und Automatisierungsfrage.

Richtig & falsch im Code

<!-- Falsch: Toggle ohne Rolle, ohne Namen, Zustand nur optisch -->
<div class="toggle active" onclick="toggleFilter()"></div>

<!-- Falsch: Rolle da, Zustand fehlt -->
<div role="button" tabindex="0" onclick="toggleFilter()">Nur verfügbare</div>

<!-- Richtig: natives Element mit gepflegtem Zustand -->
<button type="button" aria-pressed="false">Nur verfügbare Artikel</button>

// Zustand bei jeder Änderung mitführen – sonst lügt die Ansage
btn.addEventListener('click', () => {
  const gedrueckt = btn.getAttribute('aria-pressed') === 'true';
  btn.setAttribute('aria-pressed', String(!gedrueckt));
  filterAnwenden(!gedrueckt);
});

Der zweite Standardfall ist das Aufklapp-Muster – hier gehören aria-expanded und aria-controls zusammen:

<!-- Richtig: Zustand und Zusammenhang sind ausgezeichnet -->
<button type="button" aria-expanded="false" aria-controls="filter-panel">
  Filter anzeigen
</button>
<div id="filter-panel" hidden>…</div>

btn.addEventListener('click', () => {
  const offen = panel.hidden;
  panel.hidden = !offen;
  btn.setAttribute('aria-expanded', String(offen));
});

Und der Fall, der in Audits am häufigsten auffällt – der Icon-Button ohne Namen:

<!-- Falsch: der Screenreader sagt nur „Schalter" -->
<button type="button"><svg><!-- Papierkorb --></svg></button>

<!-- Richtig: sichtbar bleibt das Icon, der Name kommt trotzdem an -->
<button type="button">
  <svg aria-hidden="true" focusable="false"><!-- Papierkorb --></svg>
  <span class="visually-hidden">Eintrag löschen</span>
</button>

Die verfügbaren Werkzeuge erklärt Rollen, States & Properties; wann man sie besser gar nicht braucht, die erste Regel von ARIA. Für aria-live-Meldungen ohne Fokuswechsel ist 4.1.3 Statusmeldungen zuständig.

So testest du es

1. Automatisch vorsortieren: axe findet fehlende Namen und Rollen sehr zuverlässig – Regeln wie button-name, link-name, aria-toggle-field-name und aria-required-attr decken die groben Fälle ab.
2. Accessibility-Panel öffnen: In den DevTools von Chrome oder Firefox jedes eigene Widget anklicken und Name, Rolle und Zustand ablesen. Stimmen sie mit dem überein, was das Element optisch darstellt?
3. Zustand umschalten und erneut ablesen: Ändert sich aria-expanded, aria-pressed, aria-checked oder aria-selected tatsächlich mit? Das ist der Schritt, der die meisten Funde bringt.
4. Screenreader-Probe: Mit NVDA oder VoiceOver jedes Custom-Widget bedienen. Wird der Zustandswechsel angesagt, ohne dass man den Fokus bewegt?
5. Elementliste prüfen: In NVDA mit NVDA + F7 die Schaltflächen auflisten – fehlt eines deiner Widgets dort, hat es keine Rolle.

Links und Buttons ohne zugänglichen Namen sowie iframes ohne title findet der Struktur-Check automatisch.

Häufiger Fehler in der Praxis

Der häufigste Befund ist der Icon-Button ohne Namen. In modernen Oberflächen bestehen halbe Werkzeugleisten aus Symbolen: Stift, Papierkorb, Herz, drei Punkte. Optisch aufgeräumt – im Screenreader sechsmal „Schalter“. Das ist ein Fund, der sich mit einer Zeile pro Button beheben lässt und trotzdem in fast jedem Audit auftaucht.

Der zweite ist der eingefrorene Zustand: aria-expanded="false" steht im Markup, wird beim Öffnen aber nie aktualisiert. Der Screenreader meldet dann „eingeklappt“, während das Panel offen daneben steht. Wer nachfragen kann, wird irritiert; wer nicht sieht, gibt auf. Das passiert besonders leicht in Frameworks, in denen der Zustand im JavaScript-Store lebt und das Attribut nur beim ersten Rendern gesetzt wurde.

Der dritte ist der überflüssige Nachbau. Ein <select> wird durch ein Custom-Dropdown ersetzt, weil sich das native Element nicht stylen lässt – und dann fehlen Rolle, Tastaturbedienung, Zustand und die Ansage der Auswahl. Das native Element hätte das alles mitgebracht. Wenn du wirklich nachbauen musst, nimm ein fertiges, geprüftes Muster statt einer eigenen Idee; die Erwartungen sind standardisiert, und Nutzerinnen kennen sie besser als jede neue Erfindung.

Häufige Fragen

Erfüllt natives HTML 4.1.2 automatisch?

Fast. Ein <button> mit Textinhalt, ein <a href> mit Linktext, ein <input> mit verknüpftem <label> liefern Name, Rolle und Zustand von selbst. Lücken entstehen dort, wo der Name fehlt – ein Button, der nur ein Icon enthält, ein Feld ohne Label. Die Rolle stimmt dann, der Name nicht.

Wann brauche ich aria-label?

Nur, wenn ein Element keinen sichtbaren Text hat und auch keinen bekommen kann – etwa ein Icon-Button in einer sehr engen Werkzeugleiste. Besser ist meist ein visually-hidden-Text im Element: Er landet im Namen, taucht in der Textsuche auf und geht bei Übersetzungen nicht verloren. Und wenn sichtbarer Text vorhanden ist, muss aria-label ihn enthalten, sonst funktioniert die Sprachsteuerung nicht mehr.

Was ist der Unterschied zwischen 4.1.2 und 1.3.1?

1.3.1 regelt die Struktur des Inhalts – Überschriften, Listen, Tabellen, Beziehungen. 4.1.2 regelt die Bedienelemente. In der Praxis überschneiden sie sich bei Formularen: Ein Feld ohne Label verstößt gegen beide, weil sowohl die Beziehung Feld–Beschriftung als auch der zugängliche Name fehlt.

Gilt 4.1.2 auch für nicht-interaktive Elemente?

Nein, das Kriterium spricht von Komponenten der Benutzerschnittstelle, also von Bedienelementen. Für reine Textinhalte gilt 1.3.1, für Bilder 1.1.1. Sobald etwas anklickbar oder fokussierbar ist, ist es allerdings ein Bedienelement – auch wenn es aussieht wie ein Absatz.

Was ist mit 4.1.1 Parsing passiert?

Es wurde mit WCAG 2.2 als überholt gestrichen. Die ursprüngliche Anforderung (eindeutige IDs, korrekt geschlossene Tags) stammt aus einer Zeit, in der Browser unterschiedlich mit fehlerhaftem Markup umgingen; heute ist die Fehlerkorrektur vereinheitlicht. Was praktisch relevant blieb – doppelte IDs, die eine Label-Zuordnung zerstören –, wird nun über 1.3.1 und 4.1.2 erfasst. HTML validieren bleibt trotzdem sinnvoll.

Verwandte Themen

• Die erste Regel von ARIA – natives HTML zuerst
• Rollen, States & Properties – wenn ARIA doch nötig ist
• 4.1.3 Statusmeldungen – Änderungen melden ohne Fokuswechsel
• Toggles & Custom Controls – die häufigsten Nachbauten sauber gelöst
• 2.5.3 Beschriftung im Namen – warum aria-label den sichtbaren Text enthalten muss