Name, Rolle und Zustand sind die drei Angaben, die jedes Bedienelement einer Webseite an Hilfsmittel wie Screenreader liefern muss: wie es heißt, was es ist und wie es gerade eingestellt ist. Festgelegt ist das im WCAG Erfolgskriterium 4.1.2 Name, Role, Value auf Stufe A.
Der Browser sammelt diese Angaben im Accessibility Tree. Das ist eine zweite Sicht auf die Seite, parallel zum DOM. Screenreader und Sprachsteuerung greifen auf genau diesen Baum zu. Fehlt dort eine Angabe, fehlt sie für alle, die so surfen.
Die gute Nachricht: Natives HTML liefert Name, Rolle und Zustand meist von selbst. Ein echtes button Element ist ein Button. Ein Label gibt dem Feld seinen Namen. Eine Checkbox meldet, ob sie angehakt ist.
Ein Tag inhouse mit Roland Golla, offizieller Cypress Ambassador und seit über 20 Jahren in Testing und Refactoring zu Hause. Auf unserem YouTube Kanal zeigt er in über 70 Live Coding Tutorials, wie Cypress in echten Projekten läuft. Dazu kommt unser Open Source Plugin NCA TESTIFY: Basistests für jede Website, mit einer Zeile im CI/CD Setup. Im Workshop lernt euer Team Setup, stabile Selektoren, Custom Commands und Tests in der Pipeline.
Ob ein Button seinen Namen hat, entscheidet sich im Frontend Code. Genau dort arbeiten wir jeden Tag: Komponenten in Astro, React und Vue, Inhalte aus Sulu, Tests mit Cypress und Cypress Cloud in GitHub Actions oder GitLab CI. Bleibt ein Icon Button stumm oder vergisst ein Menü seinen Zustand, finden wir die Stelle in der Komponente und schützen sie mit einem Test.
Im barrierefreien Webdesign setzen wir von Anfang an auf semantisches HTML, damit Name und Rolle ohne Extra Code stimmen. Bei bestehenden Seiten zeigt ein Accessibility Audit, welche Bedienelemente im Accessibility Tree Lücken haben. Danach landen die Prüfungen im Accessibility Testing eurer Pipeline. Besonders oft betroffen sind barrierefreie Formulare und eigene Widgets, die auch per Keyboard Navigation funktionieren müssen.
Stell dir eine Party vor, auf der du nichts siehst. Eine Freundin stellt dir die Gäste vor. Bei jedem Gast willst du drei Dinge wissen: Wie heißt er? Was macht er hier? Wie geht es ihm gerade?
Genau so stellt ein Screenreader die Elemente einer Seite vor:
Ein Gast ohne Namensschild, der wie ein Kellner aussieht, aber keine Getränke bringt, sorgt für Chaos. Ein div mit Klick Handler ist genau dieser Gast. Er sieht aus wie ein Button und verrät dem Screenreader trotzdem nichts.
Der Name. Wie ein Element heißt, regelt die W3C Spezifikation Accessible Name and Description Computation. Vereinfacht prüft der Browser diese Quellen der Reihe nach und nimmt die erste, die etwas liefert:
Die Rolle. Jedes HTML Element bringt eine eingebaute Rolle mit. a mit href ist ein Link, button ein Button, input type checkbox eine Checkbox. Ein role Attribut überschreibt diese Rolle. Ein div oder span hat keine Rolle, die etwas über Bedienung verrät.
Zustand und Wert. Native Elemente melden ihren Zustand selbst: checked, disabled, das open Attribut bei details. Bei eigenen Widgets übernehmen ARIA Attribute wie aria-expanded, aria-pressed, aria-checked oder aria-selected diese Aufgabe. Der Wert gehört bei Schiebereglern und Eingabefeldern dazu.
Wichtig ist der letzte Teil von 4.1.2: Ändert sich etwas, muss der Browser die Änderung an Hilfsmittel melden können. Ein Zustand, der nur beim Laden stimmt, reicht nicht. Wann ARIA überhaupt nötig ist, erklärt die Seite zu ARIA. Wie DOM und Accessibility Tree zusammenhängen, zeigt die Seite zum Document Object Model.
Zwischen einem stummen Element und einem Button, der alles sagt, liegen vier Stufen. Die Tabelle zeigt, was bei Hilfsmitteln ungefähr ankommt und woran es meist liegt. Die genaue Ansage hängt vom Screenreader ab.
Das Markup. Ein Menü Button mit echtem button Element. Name und Rolle liefert HTML von selbst. Für den Zustand sorgt aria-expanded, das euer Script bei jedem Klick umschaltet. Ein Button zum Stummschalten nutzt dafür aria-pressed.
<button type="button" aria-expanded="false" aria-controls="hauptmenue">
Menü
</button>
<ul id="hauptmenue" hidden>
<li><a href="/leistungen">Leistungen</a></li>
</ul>
<button type="button" aria-pressed="false">Ton aus</button>
Zustand nach dem Klick prüfen. Der Test schaut, ob der Button einen Namen hat und nach jedem Klick den neuen Zustand meldet. Fällt das Umschalten bei einem Refactoring weg, wird der Build rot.
describe('Menü Button: Name, Rolle, Zustand', () => {
beforeEach(() => {
cy.visit('/')
})
it('hat einen Namen und meldet ausgeklappt', () => {
cy.get('button[aria-controls="hauptmenue"]').as('menue')
cy.get('@menue').should(($btn) => {
const name = $btn.attr('aria-label') || $btn.text().trim()
expect(name, 'Accessible Name').to.not.be.empty
})
cy.get('@menue').should('have.attr', 'aria-expanded', 'false')
cy.get('@menue').click()
cy.get('@menue').should('have.attr', 'aria-expanded', 'true')
cy.get('#hauptmenue').should('be.visible')
cy.get('@menue').click()
cy.get('@menue').should('have.attr', 'aria-expanded', 'false')
})
it('meldet gedrückt beim Toggle Button', () => {
cy.contains('button', 'Ton aus')
.should('have.attr', 'aria-pressed', 'false')
.click()
cy.contains('button', 'Ton aus')
.should('have.attr', 'aria-pressed', 'true')
})
})
Alle Namen auf einmal prüfen. Mit cypress-axe laufen genau die axe Regeln, die fehlende Namen bei Buttons, Links, Feldern und ARIA Widgets finden. Alle tragen in axe den Tag für Kriterium 4.1.2. Ein Test mit Screenreader bleibt trotzdem nötig, denn ob ein Name verständlich ist, prüft kein Tool.
describe('Bedienelemente haben Namen', () => {
it('besteht die axe Regeln zu Name, Role, Value', () => {
cy.visit('/')
cy.injectAxe()
cy.checkA11y(null, {
runOnly: {
type: 'rule',
values: [
'button-name',
'link-name',
'input-button-name',
'label',
'select-name',
'aria-command-name',
'aria-toggle-field-name',
'aria-input-field-name'
]
}
})
})
})
Elements, particularly interactive elements, need names.
ARIA 2026: Was Rollen, Zustände und Eigenschaften leisten, wann natives HTML reicht, typische ARIA Fehler und ein Reiter Beispiel mit Cypress Test. Im NCA Glossar.
Mehr erfahrenWenn wir eine Komponente bauen oder prüfen, stellen wir ihr dieselben drei Fragen wie einem Gast an der Tür: Wie heißt du? Was machst du? Wie geht es dir gerade? Kann der Accessibility Tree alle drei beantworten, ist der wichtigste Teil geschafft. Den Rest klären Tests mit Tastatur und Screenreader.
Name, Rolle und Zustand gehören zum Prinzip Robustheit, einem der vier Grundprinzipien POUR der WCAG. Den Namen eines Elements siehst du schnell mit dem Bookmarklet ANDI, das genau dafür gebaut wurde.
Bei Bildern übernimmt der Alternativtext die Rolle des Namens. Bei Symbolen hilft die Seite zu barrierefreien Icons. Und wer per Spracherkennung durch eine Seite steuert, braucht Namen, die zum sichtbaren Text passen. Sonst findet der Sprachbefehl sein Ziel nicht.
Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.
Accessible Name, Accessibility Tree, ARIA Zustände und Tests: die wichtigsten Antworten rund um Kriterium 4.1.2.
Name, Rolle und Zustand sind die drei Angaben, die jedes Bedienelement an Hilfsmittel liefern muss: wie es heißt, was es ist und wie es gerade eingestellt ist. Das verlangt das WCAG Erfolgskriterium 4.1.2 Name, Role, Value. Auch 2026 ist es eines der Kriterien, an denen eigene Widgets am häufigsten scheitern.
Kriterium 4.1.2 Name, Role, Value gehört zur Stufe A, also zur Grundstufe. Wer Konformität nach Stufe AA anstrebt, muss es deshalb auch 2026 vollständig erfüllen. Es steht in WCAG 2.0, 2.1 und 2.2 und gehört zum Prinzip Robustheit. Es gilt für alle Bedienelemente, auch für Komponenten aus Frameworks.
Meist nicht. Native HTML Elemente wie button, a mit href, input mit label oder details liefern Name, Rolle und Zustand von selbst. ARIA brauchst du 2026 vor allem bei eigenen Widgets, für die es kein passendes HTML Element gibt, etwa Tabs oder ein Menü Button mit aria-expanded.
Mit cypress-axe kannst du gezielt die axe Regeln laufen lassen, die fehlende Namen finden, etwa button-name, link-name oder aria-toggle-field-name. Zustände prüfst du mit eigenen Cypress Tests, die nach einem Klick aria-expanded oder aria-pressed abfragen. Einen Test mit echtem Screenreader ersetzt das 2026 nicht.
Der Text von Kriterium 4.1.2 ist in WCAG 2.2 gleich geblieben. Weggefallen ist das Nachbarkriterium 4.1.1 Parsing, das als veraltet entfernt wurde. Für dich heißt das 2026: Name, Rolle und Zustand bleiben Pflicht, die Prüfung auf sauberes HTML Parsing ist kein eigenes Kriterium mehr.
Der Accessibility Tree ist eine Sicht auf die Seite, die der Browser parallel zum DOM aufbaut. Er enthält für jedes relevante Element Name, Rolle, Zustand und Wert. Screenreader und andere Hilfsmittel lesen diesen Baum über Schnittstellen des Betriebssystems. In den DevTools von Chrome und Firefox kannst du ihn dir ansehen.
Der Accessible Name ist der Name, den Hilfsmittel für ein Element ansagen. Der Browser berechnet ihn nach der W3C Spezifikation Accessible Name and Description Computation. Quellen sind unter anderem aria-labelledby, aria-label, das label Element, der alt Text oder der Inhalt eines Buttons. Die erste passende Quelle gewinnt.
Zustände ändern sich während der Nutzung, etwa aria-expanded, aria-pressed oder aria-checked. Eigenschaften bleiben meist gleich, etwa aria-controls oder aria-haspopup. Kriterium 4.1.2 verlangt, dass Änderungen an Zuständen an Hilfsmittel gemeldet werden können. Deshalb muss dein Script den Zustand bei jeder Änderung im Markup aktualisieren.
Nur als Notlösung. Das title Attribut steht in der Berechnung des Accessible Name ganz hinten und wird nur genutzt, wenn sonst nichts da ist. Der Tooltip erscheint nicht bei Tastatur oder Touch, und manche Hilfsmittel lesen ihn nicht zuverlässig vor. Sichtbarer Text oder ein Label sind die bessere Wahl.
Ein div hat keine Rolle, die Bedienung verrät, keinen Namen aus einem Label und keinen Platz in der Tab Reihenfolge. Ein Screenreader kündigt es nicht als Button an, die Tastatur erreicht es nicht. Ein echtes button Element bringt Rolle, Fokus und Bedienung mit Enter und Leertaste von selbst mit.
Ja, wenn das Element sichtbaren Text hat. Das Kriterium 2.5.3 Label in Name verlangt, dass der sichtbare Text im Accessible Name enthalten ist. Wer per Sprachsteuerung „Senden“ sagt, soll den Button mit der Aufschrift Senden auch treffen. Am besten beginnt der Name direkt mit dem sichtbaren Text.
Am schnellsten über die DevTools deines Browsers. In Chrome und Firefox zeigt der Bereich Accessibility für jedes Element Name, Rolle und Zustände an. Das Werkzeug ANDI blendet den Accessible Name direkt auf der Seite ein. Für den echten Eindruck lohnt sich zusätzlich ein Durchlauf mit einem Screenreader.
