4.1.2 Name, Rolle, Wert
Jedes Bedienelement teilt Hilfsmitteln mit, wie es heißt, was es ist und in welchem Zustand es ist, etwa „Menü, Schalter, ausgeklappt“.
Stufe APrinzip 4: Robust
Was bedeutet das?
Ein Screenreader muss bei jedem Link, Button, Feld oder eigenen Bedienelement drei Dinge erfahren: den Namen („Menü“), die Rolle („Schalter“) und den aktuellen Zustand oder Wert („ausgeklappt“, „ausgewählt“, „angehakt“). Ändert sich der Zustand, muss auch diese Information aktualisiert werden.
Standard-HTML-Elemente wie <button>, <a href> oder <input> bringen das von selbst mit. Probleme entstehen meist bei selbst gebauten Menüs, Tabs, Akkordeons oder Schaltern aus <div>-Elementen. Hier müssen Rolle und Zustand mit ARIA ergänzt werden – oder besser, man nutzt gleich das passende HTML-Element.
Wem hilft das?
- Blinde Menschen, die mit Screenreader arbeiten
- Menschen, die Sprachsteuerung nutzen und Elemente beim Namen ansprechen
- Menschen, die mit Schaltern oder anderen Eingabehilfen bedienen
Typische Fehler
- Ein Menü-Button aus einem <div> mit Klick-Skript, ohne Rolle und ohne Tastaturbedienung.
- Ein Akkordeon klappt auf, aber der Screenreader erfährt nicht, ob es offen oder geschlossen ist.
- Ein Symbol-Button ohne Text und ohne zugänglichen Namen, der nur als „Schalter“ angesagt wird.
- Ein eigener Ein/Aus-Schalter zeigt seinen Zustand nur durch Farbe an.
- Ein eingebettetes Iframe hat keinen title.
So prüfen wir das
- axe-core Automatisch: axe-core findet typische Verstöße. Ein Verstoß wird als „nicht erfüllt“ vorausgefüllt.
Prüffrage: Eigene Bedienelemente (Menüs, Tabs, Akkordeons, Schalter) geben Name, Rolle und Zustand an Hilfsmittel weiter. Mit Screenreader prüfen.
Entschieden wird jedes Kriterium von einem Menschen. Kein Kriterium gilt automatisch als erfüllt.
So beheben Sie es
<div class="menu-toggle" onclick="toggleMenu()">☰</div>
<ul id="menu" hidden>…</ul><button type="button" aria-expanded="false" aria-controls="menu">Menü</button>
<ul id="menu" hidden>…</ul>
<script type="module">
const btn = document.querySelector('[aria-controls="menu"]');
btn.addEventListener('click', () => {
const open = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!open));
document.getElementById('menu').hidden = open;
});
</script>Der echte Button ist per Tastatur bedienbar und meldet dem Screenreader Name, Rolle und den Zustand „ausgeklappt“ oder „eingeklappt“.
Praxistipps
- Greifen Sie zuerst zu nativen Elementen wie <button>, <details> oder <input type="checkbox">. ARIA ist nur für den Rest nötig.
- Prüfen Sie eigene Bedienelemente mit einem Screenreader, etwa NVDA unter Windows oder VoiceOver auf dem Mac.
Ratgeber und Muster dazu
- Der richtige Alternativtext in fünf FragenEin guter Alternativtext ersetzt, was das Bild auf dieser Seite leistet, nicht was darauf zu sehen ist. Mit fünf Fragen finden Sie für jedes Bild die passende Lösung.
- In 30 Minuten zum ersten Screenreader-TestEin Screenreader zeigt schonungslos, ob Ihre Seite sauber aufgebaut ist. Mit dieser Anleitung testen Sie Ihre wichtigsten Seiten selbst, mit kostenlosen Werkzeugen und ohne Vorkenntnisse.
- BFSG-Prüfung: So lassen Sie Ihre Website auf Barrierefreiheit prüfenDas BFSG verlangt barrierefreie Angebote, aber kein bestimmtes Prüfverfahren. Hier steht, welche Prüfung was leistet, wie ein Audit abläuft, was es bei uns kostet und was Sie danach in der Hand haben.
- Cookie-Banner, die niemanden aussperrenDer Cookie-Banner ist oft das Erste, was Besucher sehen, und für manche das Letzte: Wer ihn mit Tastatur oder Screenreader nicht bedienen kann, kommt nicht weiter. So machen Sie ihn für alle bedienbar.
Offizielle Quelle
Understanding WCAG 2.2 beim W3C (Englisch): 4.1.2 Name, Role, Value
Wie steht Ihre Website bei diesem Kriterium?
Der kostenlose Check prüft Ihre Startseite automatisch, das Audit entscheidet alle 55 Kriterien.