Name, Rolle, Wert

Was gefordert wird

Jedes interaktive Element auf der Seite — Schaltflächen, Links, Formularfelder, Tabs, Schieberegler, benutzerdefinierte Widgets — muss der assistiven Technologie drei Informationen bereitstellen:

• Name — wie heißt dieses Steuerelement? („Absenden“, „Dialog schließen“, „Lautstärke“)
• Rolle — um welche Art von Steuerelement handelt es sich? (button, link, checkbox, tab, slider)
• Wert / Zustand — für Komponenten, bei denen dies zutrifft: Ist es gedrückt, ausgeklappt, ausgewählt, angekreuzt? Welcher Wert ist aktuell eingestellt?

Die Bereitstellung muss programmgesteuert erfolgen — im DOM festgelegt, nicht per CSS aufgemalt. Screenreader, Braillezeilen, Sprachsteuerungssoftware und Schalter-Scanner lesen den Barrierefreiheitsbaum, nicht Pixel.

Umsetzung

• Das native HTML-Element sollte verwendet werden, wann immer eines vorhanden ist. <button> liefert die korrekte Rolle, Fokusbehandlung, Tastatursteuerung und einen barrierefreien Namen aus dem Textinhalt — kostenlos.
• Für Schaltflächen mit ausschließlich grafischem Inhalt sollte aria-label (oder visuell versteckter Text) ergänzt werden. <button aria-label="Schließen">×</button>.
• Bei Formulareingaben sollte ein <label for> mit der id des Eingabefelds verknüpft werden. Alternativ kann die Eingabe innerhalb des <label> verschachtelt werden. Platzhaltertext ist kein Label.
• Wird ein benutzerdefiniertes Widget aus <div> und <span> aufgebaut, sind role="…", tabindex, Enter- und Leerzeichen-Handler sowie die Zustandsspiegelung mit aria-pressed, aria-expanded, aria-checked, aria-selected und aria-valuenow erforderlich.
• Die gerenderte Seite sollte mit dem Barrierefreiheitsbaum-Inspector des Browsers überprüft werden (Chrome DevTools → Elemente → Barrierefreiheit): Jedes Steuerelement sollte mit Name, Rolle und Zustand ausgegeben werden.

Typische Fehler

• <div onclick="…"> als Schaltfläche gestaltet — keine Rolle, keine Tastatursteuerung, kein Name. Screenreader überspringen es. Sprachsteuerung kann „Klick auf Speichern“ nicht ausführen.
• <div role="button"> ohne tabindex="0" und ohne Enter-/Leerzeichen-Handler — sieht barrierefrei aus, ist es nicht.
• Schaltflächen mit ausschließlich grafischem Inhalt (<button><svg /></button>) ohne aria-label, aria-labelledby oder visuell versteckten Text. Ausgabe: bloßes „Schaltfläche“.
• Benutzerdefinierte Dropdowns aus <div> und JavaScript, denen role="combobox", aria-expanded, aria-controls sowie die Rollen listbox und option fehlen.
• Umschalt-Schaltflächen (Stummschalten, Favorisieren, Folgen), die den Zustand visuell ändern, ohne aria-pressed zu aktualisieren. Sehende Nutzende sehen die Änderung; Screenreader-Nutzende hören keinen Unterschied.
• Formulareingaben mit einem visuellen Label daneben, aber ohne for/id-Verknüpfung oder umschließendes <label>.
• Benutzerdefinierte Checkboxen aus <svg> mit verstecktem nativem Input, der :checked nie in der sichtbaren Benutzeroberfläche widerspiegelt — Screenreader- und visueller Zustand laufen auseinander.

Warum es wichtig ist

Dies ist das am häufigsten zitierte Erfolgskriterium der Spezifikation. Fast jede Beschwerde der Art „diese Website ist mit einem Screenreader nicht nutzbar“ lässt sich auf einen 4.1.2-Fehler zurückführen — meistens ein <div>, das als Schaltfläche getarnt ist, oder eine Schaltfläche mit grafischem Inhalt ohne Namen. Hier zeigt sich auch der Preis benutzerdefinierter Widgets: Jedes native HTML-Steuerelement erfüllt 4.1.2 bereits; jedes handgemachte <div>-Widget muss es Zeile für Zeile erarbeiten. Die schnellste 4.1.2-Prüfung besteht darin, die Seite mit einem Screenreader mit der Tabulatortaste zu durchlaufen und zu hören — alles, was als „leer“ oder bloß „Schaltfläche“ ausgegeben wird, ist ein Befund.