Ein Kriterium der Stufe A, das verlangt, dass jedes interaktive Element seinen Namen (Beschriftung), seine Rolle (Art des Bedienelements) und seinen aktuellen Zustand oder Wert programmatisch bereitstellt.

Was verstößt typischerweise gegen 4.1.2?

Eigene Widgets aus generischen div- oder span-Elementen ohne Rolle oder ARIA – ein Screenreader kündigt sie dann als bedeutungslosen Text an statt als Schaltfläche, Kontrollkästchen und so weiter.

Wie erfülle ich das Kriterium?

Bevorzugen Sie native HTML-Elemente (button, input) oder vergeben Sie beim Bau eigener Komponenten korrekte ARIA-Rollen, -Namen und -Zustände.

Erfolgskriterien

WCAG 4.1.2 Name, Rolle, Wert

Erfolgskriterium 4.1.2 verlangt, dass für jede Benutzeroberflächen-Komponente ihr Name und ihre Rolle programmatisch bestimmt werden können, ihre Zustände/Eigenschaften/Werte (soweit zutreffend) vom Nutzer gesetzt werden können, und jede Änderung daran assistiver Technologie mitgeteilt wird. Es ist ein Kriterium der Stufe A unter Richtlinie 4.1 (Kompatibel) – und nach Regelanzahl das mit Abstand am stärksten vertretene Kriterium im gesamten Regelwerk von axe-core (Dutzende einzelner Regeln lassen sich auf genau diese eine Anforderung zurückführen).

Warum es als drei separate Dinge formuliert ist

Name – wie das Steuerelement genannt wird (der barrierefreie Name einer Schaltfläche, der Zweck eines Links, die Beschriftung eines Formularfelds).

Rolle – welche Art von Steuerelement es ist (Schaltfläche, Link, Kontrollkästchen, Tab) – automatisch von echten HTML-Elementen mitgeteilt, aber etwas, das ein benutzerdefiniertes, auf <div> basierendes Widget ausdrücklich über die ARIA-role deklarieren muss.

Wert (und Status) – bei Steuerelementen, die einen Wert oder Status halten (angekreuzt/nicht angekreuzt, erweitert/eingeklappt, ausgewählt), muss dieser Status offengelegt und bei Änderungen synchron gehalten werden.

Eine Komponente, der eines dieser drei Elemente fehlt, ist gegenüber assistiver Technologie unvollständig beschrieben, selbst wenn die anderen beiden in Ordnung sind.

Wo dieses Kriterium tatsächlich auftritt

Da "Name, Rolle, Wert" eine so grundlegende Anforderung ist, sind eine große Zahl spezifischerer, leichter benennbarer Verstöße im Kern tatsächlich 4.1.2-Fehler:

Eine reine Symbol-Schaltfläche ohne barrierefreien Namen – siehe Leere Links und Schaltflächen
ARIA-Attribute, die falsch geschrieben, ungültig sind oder erforderliche Begleiter fehlen – siehe Ungültige ARIA-Attribute
Ein iframe ohne title, das eingebetteten Inhalt unbenannt lässt – siehe Fehlende iframe-Titel
Ein Formularfeld ohne programmatische Beschriftung – siehe Fehlende Formularbeschriftungen
Ein benutzerdefinierter Umschalter/eine Checkbox, gebaut aus einem <div>, das aria-checked nie aktualisiert, wenn sich sein Status ändert

Die vereinheitlichende Lösung: natives HTML bevorzugen

Fast jeder 4.1.2-Verstoß lässt sich auf dieselbe Grundursache zurückführen – das Verhalten eines nativen HTML-Steuerelements auf einem generischen Element nachzubauen, statt das echte zu verwenden. Ein echtes <button>, <input type="checkbox"> oder <select> erfüllt Name/Rolle/Wert automatisch, kostenlos, ganz ohne benötigtes ARIA. Dies ist die praktische Bedeutung von "verwenden Sie kein ARIA, wenn natives HTML den Job bereits erledigt" – 4.1.2 ist das Kriterium, zu dessen Schutz diese Regel existiert.

Häufige Fragen

Was ist WCAG 4.1.2?: Ein Kriterium der Stufe A, das verlangt, dass jedes interaktive Element seinen Namen (Beschriftung), seine Rolle (Art des Bedienelements) und seinen aktuellen Zustand oder Wert programmatisch bereitstellt.
Was verstößt typischerweise gegen 4.1.2?: Eigene Widgets aus generischen div- oder span-Elementen ohne Rolle oder ARIA – ein Screenreader kündigt sie dann als bedeutungslosen Text an statt als Schaltfläche, Kontrollkästchen und so weiter.
Wie erfülle ich das Kriterium?: Bevorzugen Sie native HTML-Elemente (button, input) oder vergeben Sie beim Bau eigener Komponenten korrekte ARIA-Rollen, -Namen und -Zustände.