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 der Tür klopft, aber keinen Namen sagt. Menschen, die auf Assistenztechnologien 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 interaktiven Elemente müssen für Assistenztechnologien verständlich sein. Sie brauchen einen Namen (was bin ich?), eine Rolle (was für ein Element bin ich?) und Informationen über ihren aktuellen Zustand (in welchem Status befinde ich mich?).

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

2. Was fordert das Erfolgskriterium genau?

Ganz konkret geht es um alle Benutzeroberflächen-Komponenten – von Formularelementen über Links bis hin zu selbst programmierten Widgets:

Name und Rolle müssen programmatisch bestimmbar sein:

• Jedes interaktive Element braucht einen Namen, den Assistenztechnologien auslesen können
• Die Rolle (Button, Link, Eingabefeld, etc.) muss klar erkennbar sein
• Das gilt auch für per Script erzeugte Komponenten

Zustände und Werte müssen verfügbar sein:

• Eigenschaften, die Nutzer ändern können, müssen auch programmatisch setzbar sein
• Änderungen an diesen Elementen müssen an Assistenztechnologien weitergegeben werden
• Beispiele: Ob eine Checkbox aktiviert ist, ob ein Menü ausgeklappt ist, welchen Text ein Eingabefeld enthält

Wichtige Ausnahme: Standard-HTML-Elemente erfüllen dieses Kriterium bereits automatisch, wenn sie korrekt verwendet werden. Das Problem entsteht 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 Assistenztechnologien keine Informationen über Interface-Elemente erhalten.

Name, Rolle und Wert schaffen Klarheit, weil sie:

• Screenreader-Nutzern ermöglichen, zu verstehen, was jedes Element macht und wie sie es bedienen können
• Sprachsteuerungssoftware erlauben, Elemente gezielt anzusprechen ("Klicke auf Senden-Button")
• Menschen mit motorischen Einschränkungen helfen, die richtige Eingabemethode zu wählen
• Tastaturnutzern zeigen, welche Elemente fokussierbar und bedienbar sind
• Kognitiven Unterstützung bieten durch klare, konsistente Element-Bezeichnungen

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

4. So setzt du das Kriterium erfolgreich um

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

Verwende natives HTML wo möglich:

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

Für benutzerdefinierte Widgets nutze ARIA:

• role="button" für selbstgebastelte Buttons aus DIV-Elementen
• aria-label="Beschreibung" für unsichtbare Namen
• aria-labelledby="id" um auf sichtbare Labels zu verweisen
• aria-expanded="false/true" für ausklappbare Menüs
• aria-checked="true/false" für Checkboxen

Halte Namen prägnant und funktional:

• "Senden" statt "Hier klicken"
• "Hauptmenü öffnen" statt nur ein Hamburger-Icon
• "Preis aufsteigend sortieren" statt "Sortieren"

Denk an Zustandsänderungen:

• Wenn sich der Inhalt ändert, aktualisiere auch aria-live Bereiche
• Bei Formularvalidierung verwende aria-invalid und aria-describedby
• Fokusänderungen sollten für Screenreader nachvollziehbar sein

Tools für die Überprüfung:

• Browser-Entwicklertools (Accessibility-Tab)
• Screenreader wie NVDA oder JAWS zum Testen
• Automatisierte Tools 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 Interface-Elemente sind nicht nur für Menschen mit Behinderungen wichtig. Sie verbessern die Usability für alle – auch für Menschen, die per Spracheingabe navigieren oder in stressigen Situationen schnell das richtige Element finden müssen.

2. Suchmaschinenoptimierung verbessern

Suchmaschinen verstehen semantisch korrekt aufgebaute Websites besser. Klare Elementnamen und -rollen helfen dabei, Inhalte richtig zu kategorisieren und in Suchergebnissen besser zu präsentieren.

3. Code-Qualität und Wartbarkeit steigern

Sauberer, semantischer Code mit klaren Bezeichnungen ist einfacher zu warten, zu testen und zu debuggen. Entwicklerteams arbeiten effizienter, wenn Interface-Elemente eindeutig benannt und ihre Funktionen klar dokumentiert sind.

Und nicht zuletzt: Rechtssicherheit und Fördermöglichkeiten. Viele öffentliche Projekte fordern digitale Barrierefreiheit bereits verpflichtend – wer vorbereitet ist, hat klare Vorteile bei Ausschreibungen und Förderanträgen.

6. Das Erfolgskriterium im Wortlaut der W3

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.

← Zurück zur WCAG-Übersicht