WCAG 2.2 · Level A · RobustBarrierefreiheit als Cloud-Service

4.1.2 Name, Rolle, Wert

Jedes Bedienelement auf einer Website — ein Button, ein Schalter, eine Checkbox — muss sich selbst richtig beschreiben können. Und zwar auf eine Weise, die nicht nur Menschen mit Augen sehen, sondern die auch Hilfsprogramme wie Screenreader an blinde Nutzer weitergeben können.

Jetzt testen Alle Kriterien

Auf einen Blick

Was bedeutet dieses Kriterium?

Kurz gesagt

Bedienelemente müssen sich selbst vorstellen

Aufwand

Einfach umzusetzen, schnell erledigt

Betrifft Rolle

Entwicklung

Konformitätsstufe

Level A

EN 301 549

Abschnitt 9.4.1.2 · BITV 2.0 · BFSG

Verständlich erklärt

Was heißt 4.1.2 für die Praxis?

Konkret braucht jedes Bedienelement drei Informationen: wie es heißt (Name), was es ist (ein Button? Ein Schalter? Ein Eingabefeld?) und in welchem Zustand es gerade ist (angeklickt? ausgewählt? leer?).

Wenn eine dieser drei Informationen fehlt, ist das Element für blinde oder motorisch eingeschränkte Nutzer unbrauchbar — oft sogar komplett unsichtbar.

Wer ist betroffen?

Ein Alltagsbeispiel

Maria ist blind und nutzt einen Screenreader. Sie möchte auf einer Versicherungsseite ein Formular ausfüllen. Der Entwickler hat die 'Ich stimme den AGB zu'-Checkbox als einfaches klickbares Kästchen programmiert, statt als echte Checkbox. Marias Screenreader erkennt das Element nicht als Bedienelement — sie hört nur den Text 'Ich stimme den AGB zu', aber weiß nicht, dass sie etwas anklicken muss. Das Formular lässt sich ohne das Häkchen nicht abschicken. Maria kann die Versicherung nicht abschließen.

Betroffen sind insbesondere: Blinde Menschen, Sehbehinderte Menschen, Menschen mit motorischen Einschränkungen, Menschen, die Sprachsteuerung nutzen.

Die Lösung

So setzen Sie es richtig um

Nutzen Sie für Bedienelemente die Standard-Bausteine, die HTML von Haus aus mitbringt. Ein Button ist ein Button, eine Checkbox ist eine Checkbox — und damit funktionieren sie automatisch mit allen Hilfsprogrammen.

Die allermeisten Probleme mit diesem Kriterium entstehen, weil Entwickler aus ästhetischen Gründen eigene Bedienelemente bauen, statt die Standard-Bausteine zu verwenden. Das ist nicht nötig — jedes HTML-Element lässt sich stylen. Ein Standard-Button kann aussehen wie ein individuell gestalteter Button, bleibt aber für Hilfsprogramme ein Button.

Umsetzung

Schritt für Schritt

Konkrete Anleitung zur praktischen Umsetzung dieses Kriteriums.

1
Prüfen Sie Ihre interaktiven Elemente
Gehen Sie durch Ihre Website und schauen Sie sich alles an, was man anklicken oder ausfüllen kann. Buttons, Links, Checkboxen, Dropdowns, Schieberegler, Menüs. Für jedes dieser Elemente gilt: Wurde es mit dem richtigen HTML-Baustein umgesetzt?
2
Standard-HTML-Elemente bevorzugen
Ein Button sollte ein <button> sein, kein <div onclick>. Eine Checkbox sollte ein <input type="checkbox"> sein, kein klickbares Bild. Ein Link sollte ein <a href> sein, kein JavaScript-Handler auf einem Textabsatz. Diese Standard-Elemente bringen Name, Rolle und Zustand automatisch mit.
3
Jedes Bedienelement hat einen sichtbaren oder vorgelesenen Namen
Ein Icon-Button ohne Text (z.B. nur mit einem Papierkorb-Symbol) braucht einen unsichtbaren Namen für Screenreader. Das geht mit dem Attribut aria-label="Eintrag löschen". Wichtig: Der Name sollte die Aktion beschreiben, nicht nur das Symbol.
4
Komplexe Bedienelemente mit ARIA ergänzen
Wenn Sie wirklich etwas bauen, das HTML nicht als Standard-Baustein hat — etwa einen aufklappbaren Baum oder ein komplexes Tab-System — dann ergänzen Sie die Rollen und Zustände mit ARIA-Attributen. Zum Beispiel role="tab" und aria-selected="true". Aber: Das ist die Ausnahme, nicht die Regel.
5
Testen Sie mit einem Screenreader
Schalten Sie VoiceOver (Mac) oder NVDA (Windows) ein und navigieren Sie mit der Tab-Taste durch Ihre Seite. Hören Sie bei jedem Element: einen Namen, eine Rolle, einen Zustand? Wenn der Screenreader nur stumm bleibt oder einen generischen Text vorliest, haben Sie ein Problem.

Praxisbeispiele

So nicht — sondern so

So nicht

<div class="checkbox" onclick="toggle()">AGB akzeptieren</div>

Sondern so

<label>
  <input type="checkbox" name="agb"> AGB akzeptieren
</label>

Warum?

Im schlechten Beispiel ist das Kästchen nur ein klickbares div. Screenreader erkennen es nicht als Bedienelement. Der Nutzer hört zwar den Text 'AGB akzeptieren', weiß aber nicht, dass er etwas anklicken soll — und kann auch nicht erfahren, ob es bereits angehakt ist. Die korrekte Lösung nutzt das Standard-HTML-Element für Checkboxen, das automatisch Name (AGB akzeptieren), Rolle (checkbox) und Zustand (angehakt/nicht angehakt) vermittelt.

So nicht

<div class="btn" onclick="delete()">
  <svg><!-- Papierkorb-Icon --></svg>
</div>

Sondern so

<button type="button" onclick="delete()" aria-label="Eintrag löschen">
  <svg aria-hidden="true"><!-- Papierkorb-Icon --></svg>
</button>

Warum?

Ein Lösch-Button mit nur einem Icon hat für sehende Nutzer einen klaren Zweck — das Papierkorb-Symbol ist eindeutig. Für blinde Nutzer ist er ohne aria-label völlig namenlos: der Screenreader sagt nur 'Button, ohne Name'. Die korrekte Version nutzt einen echten <button> (Rolle), versteckt das dekorative Icon vor Hilfsprogrammen (aria-hidden) und gibt dem Button einen aussagekräftigen Namen (aria-label="Eintrag löschen").

Typische Fehler

Das wird häufig falsch gemacht

Diese Fehler sehen wir in der Praxis besonders oft — und wie Sie sie vermeiden.

Klickbare divs statt echter Buttons

Der häufigste Fehler. Entwickler bauen einen 'Button' als <div>, weil sie die Standard-Button-Formatierung nicht wollen. Aber: Sie können einen <button> genauso stylen wie ein div. Der einzige Grund, ein div zu verwenden, wäre pure Bequemlichkeit — und die kostet blinde Nutzer den Zugang zur Website.

Icon-Buttons ohne Label

Ein Button, der nur aus einem Icon besteht (Mülleimer, Bleistift, Lupe), muss entweder sichtbaren Text bekommen oder ein aria-label. Ohne Label hören Screenreader-Nutzer nur 'Button', ohne zu wissen, was er tut.

Zustandsänderungen werden nicht kommuniziert

Ein Akkordeon-Eintrag kann 'zugeklappt' oder 'aufgeklappt' sein. Ein Stern-Icon kann 'favorisiert' oder 'nicht favorisiert' sein. Diese Zustände müssen für Screenreader-Nutzer hörbar sein — etwa mit aria-expanded oder aria-pressed.

ARIA statt echter HTML-Elemente

Manche Entwickler bauen <div role="button"> statt einfach <button>. Das ist nicht falsch, aber unnötig kompliziert — und vergisst man, auch die Tastaturbedienung selbst zu programmieren, ist der vermeintliche 'Button' trotzdem nicht bedienbar. Die erste Regel von ARIA lautet: 'Keine ARIA ist besser als schlechte ARIA.'

Selbst prüfen

So testen Sie dieses Kriterium

Mit diesen Methoden können Sie selbst prüfen, ob Ihre Webseite das Kriterium erfüllt.

Tastatur-Test

Legen Sie die Maus beiseite und navigieren Sie mit der Tab-Taste durch Ihre Seite. Jedes Bedienelement muss Tastaturfokus bekommen können. Mit Enter oder Leertaste muss es auslösbar sein. Wenn ein Element nicht anwählbar ist oder nicht auf Tastatureingaben reagiert, haben Sie ein Problem.

Screenreader-Test

Schalten Sie VoiceOver (Mac: Cmd+F5), NVDA (Windows) oder TalkBack (Android) ein. Navigieren Sie durch Ihr Formular oder Ihre Menüs. Bei jedem Element müssen Sie Name, Rolle und Zustand hören — etwa 'AGB akzeptieren, Checkbox, nicht angehakt'.

Automatisierter Test

Tools wie axe DevTools, WAVE oder Pa11y können viele Verstöße gegen dieses Kriterium automatisch finden. Sie erkennen aber nicht alle Probleme — manuelle Tests bleiben wichtig.

Häufige Fragen

Fragen und Antworten

Warum kann ich nicht einfach ein <div> als Button verwenden?▾

Weil ein <div> für Hilfsprogramme nur ein neutraler Container ohne Bedeutung ist. Ein Screenreader sagt nicht 'Button' — er liest höchstens den enthaltenen Text vor, ohne zu erwähnen, dass man darauf klicken kann. Außerdem ist ein <div> standardmäßig nicht per Tastatur erreichbar. Sie müssten tabindex, Tastatur-Handler, Fokus-Stile und ARIA-Rollen alles manuell programmieren — während Sie mit <button> nichts davon tun müssen, weil es automatisch funktioniert.

Wann sollte ich ARIA verwenden?▾

ARIA ist ein Werkzeug für den Fall, dass HTML allein nicht reicht. Das ist seltener, als man denkt. Die meisten Bedienelemente lassen sich mit Standard-HTML umsetzen: Buttons, Checkboxen, Radio-Buttons, Dropdowns, Formularfelder. ARIA brauchen Sie erst bei komplexen Custom-Widgets wie Tabs, Akkordeons, Baum-Navigationen oder Drag-and-Drop. Faustregel: Wenn HTML einen passenden Baustein hat, nutzen Sie diesen.

Mein Design erlaubt keinen Standard-Button. Was tun?▾

Das ist ein Missverständnis — <button> lässt sich mit CSS vollständig umgestalten. Sie können Hintergrund, Rand, Schatten, Schriftart, Größe, Form und Verhalten beim Hover oder Klick frei festlegen. Ein Standard-Button kann so aussehen wie ein Card, ein Icon, ein Link oder alles andere, was Sie möchten. Fangen Sie immer mit dem semantisch richtigen Element an und stylen Sie es dann.

Reicht es, aria-label zu setzen?▾

Nein. aria-label liefert zwar einen Namen, aber nicht die Rolle oder den Zustand. Ein <div aria-label="Senden"> bleibt für Screenreader ein namensbehaftetes div — keinen Button. Nutzer können auch nicht per Tastatur darauf zugreifen. Sie brauchen entweder ein echtes <button> ODER eine Kombination aus role="button", tabindex="0", aria-label, und Tastatur-Handlern. Letzteres ist deutlich mehr Arbeit und fehleranfälliger.

Wie prüfe ich, ob mein Custom-Widget korrekt ist?▾

Drei Tests: (1) Tab-Taste — wird das Element angewählt? (2) Screenreader — hören Sie Name, Rolle und Zustand? (3) Tastatur — können Sie das Element nur mit der Tastatur bedienen? Wenn alle drei Tests bestanden sind, ist Ihr Widget robust.

Verwandte Kriterien

Weiterführende Erfolgskriterien

Diese Kriterien stehen in engem Zusammenhang mit 4.1.2 und sollten gemeinsam betrachtet werden.

1.3.1A

Info und Beziehungen

Struktur im Code muss der visuellen Darstellung entsprechen.

4.1.3AA

Statusmeldungen

Statusmeldungen werden ohne Fokuswechsel vom Screenreader angesagt.