4.1.2 Name, Role, Value

WCAG – Definition

Für alle Benutzeroberflächen-Komponenten (wie Formularelemente, Links, Widgets, Custom Controls) müssen Name, Rolle und – wenn zutreffend – Wert, Zustände und Eigenschaften programmatisch ermittelbar sein. Außerdem müssen diese Informationen vom Code aus aktualisiert werden können, wenn sich etwas ändert.

Das bedeutet: Screenreader & andere Assistenztechnologien müssen jederzeit wissen:

  • Name → was ist das für ein Element? (z. B. Label "E-Mail-Adresse")

  • Rolle → welche Funktion hat es? (z. B. Eingabefeld, Button, Checkbox)

  • Wert/Zustand → welcher Inhalt oder Status liegt an? (z. B. "ausgewählt", "5 von 10", "Slider auf 50%").

Bedeutung

Warum ist das wichtig?

  • Ohne eindeutigen Namen weiß ein Screenreader-Nutzer nicht, was er eingibt.

  • Ohne Rolle ist nicht klar, ob etwas ein Button, ein Link oder ein Schalter ist.

  • Ohne Wert/Zustand kann ein Nutzer keine Interaktionen nachvollziehen (z. B. ob eine Checkbox aktiv ist).

Das Erfolgskriterium ist eine Grundvoraussetzung für barrierefreie Interaktion – besonders, wenn eigene JavaScript-Widgets oder UI-Komponenten gebaut werden.

Ausreichende Techniken

Native HTML-Elemente nutzen

Die meisten Standard-HTML-Elemente bringen Name, Rolle und Wert schon automatisch mit:

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email">

  • Name: kommt vom <label>

  • Rolle: ist automatisch „textbox“

  • Wert: ist der eingegebene Text

ARIA-Rollen & -Attribute korrekt einsetzen (wenn nötig)

Für selbstgebaute Komponenten (z. B. ein eigenes Dropdown) muss man ARIA einsetzen:

<div role="combobox" aria-expanded="false" aria-haspopup="listbox">
  <input type="text" aria-autocomplete="list" aria-controls="options" aria-activedescendant="option-1">
</div>

<ul id="options" role="listbox">
  <li id="option-1" role="option" aria-selected="true">Option 1</li>
  <li id="option-2" role="option">Option 2</li>
</ul>

  • role="combobox" → Rolle definiert

  • aria-expanded="false" → aktueller Zustand

  • aria-selected="true" → Wert (Option ausgewählt)

Dynamische Änderungen programmatisch kommunizieren

Wenn sich ein Zustand ändert (z. B. Modal öffnet), muss das AT mitbekommen:

const modal = document.getElementById("dialog");
modal.setAttribute("aria-hidden", "false");

Oder bei einem Custom-Button:

button.setAttribute("aria-pressed", "true");

Accessible Name berechnen

Der „Name“ kann aus verschiedenen Quellen kommen:

  • <label>

  • alt bei Bildern

  • aria-label

  • aria-labelledby

<button aria-label="Schließen">
  <svg aria-hidden="true">…</svg>
</button>

Beratungstechniken

Wenn du Kund:innen oder Entwickler:innen berätst:

  • Empfehle Native HTML-Elemente: Sie sind fast immer sicherer als Custom ARIA-Widgets.

  • Teste mit Screenreader (NVDA/VoiceOver): Wenn man nicht hört, was passieren soll, ist 4.1.2 verletzt.

  • Dokumentiere Zustände: Für jedes UI-Element muss klar sein: „Wie bekommt AT den Namen, die Rolle, den Wert?“

  • ARIA nur wenn nötig: Sag immer „First rule of ARIA: Don’t use ARIA, unless you have to“.

Fehler

  • Fehlendes Label bei Formularfeldern:
  • Nicht beschriftete Buttons mit nur Icons
  • Custom Widgets ohne ARIA: Ein selbstgebauter Slider, der nur visuell funktioniert, aber keine Rolle/Wert hat.
  • Dynamische Zustände nicht aktualisiert: Accordion klappt auf, aber aria-expanded bleibt auf false.