WCAG 4.1.2: Name, Rolle, Wert

WCAG 4.1.2 verlangt, dass alle Benutzeroberflächenkomponenten einen programmatisch bestimmbaren Namen und eine programmatisch bestimmbare Rolle haben und dass Zustände, Eigenschaften und Werte sowohl von unterstützenden Technologien ausgelesen als auch gesetzt werden können. Dies stellt sicher, dass Screenreader und andere Werkzeuge jedes Element auf der Seite korrekt identifizieren, beschreiben und mit ihm interagieren können.

Was diese Regel bedeutet

WCAG 4.1.2 — Name, Rolle, Wert ist ein Erfolgskriterium der Stufe A unter dem Prinzip „Robust“. Es verlangt, dass für jede Benutzeroberflächenkomponente – einschließlich Formularelementen, Schaltflächen, Links, benutzerdefinierten Widgets, Frames und interaktiven Steuerelementen – die folgenden drei Dinge zutreffen:

Name: Jede Komponente muss einen zugänglichen Namen haben, den unterstützende Technologien vorlesen oder über eine Braillezeile ausgeben können. Der Name kann aus dem Elementinhalt stammen (z. B. der Text innerhalb eines <button>), aus einem label-Element, einem aria-label-Attribut, einem aria-labelledby-Verweis oder einem title-Attribut.
Rolle: Jede Komponente muss eine Rolle haben, die ihren Zweck gegenüber unterstützenden Technologien kommuniziert. Native HTML-Elemente tragen implizite Rollen (ein <button> hat die Rolle button, ein <input type='checkbox'> hat die Rolle checkbox). Benutzerdefinierte Widgets, die aus generischen Elementen wie <div> oder <span> gebaut sind, müssen explizit eine Rolle über das ARIA-Attribut role deklarieren.
Wert (Zustände und Eigenschaften): Jeder aktuelle Zustand oder Wert, der für die Nutzerin oder den Nutzer bedeutungsvoll ist – ob ein Kontrollkästchen aktiviert ist, ob ein Disclosure-Widget aufgeklappt ist, ob ein Feld erforderlich ist – muss programmatisch exponiert werden, damit unterstützende Technologien ihn melden können und damit Nutzende ihn, wo zutreffend, ändern können.

Eine Komponente besteht dieses Kriterium, wenn ihr zugänglicher Name nicht leer ist, ihre Rolle gültig und semantisch angemessen ist und alle relevanten Zustände (wie aria-checked, aria-expanded oder aria-required) korrekt angewendet und mit der visuellen UI synchron gehalten werden. Eine Komponente verfehlt das Kriterium, wenn eines dieser drei Elemente fehlt, falsch ist oder nicht synchron ist – zum Beispiel eine benutzerdefinierte Umschalt-Schaltfläche, die sich visuell farblich ändert, aber ihren aria-pressed-Zustand nie aktualisiert.

Die offizielle WCAG-Ausnahme betrifft Komponenten, die absichtlich nicht gegenüber Accessibility-APIs exponiert werden – zum Beispiel rein dekorative Elemente oder Inhalte, die mit aria-hidden='true' verborgen werden. Das Verbergen aktiver oder fokussierbarer Inhalte mit aria-hidden (etwa wenn es auf das <body>-Element angewendet wird) stellt jedoch selbst einen Verstoß dar, weil dadurch der gesamte Seiteninhalt aus dem Accessibility Tree entfernt wird.

Warum das wichtig ist

Weltweit haben laut Weltgesundheitsorganisation etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung. Für blinde und sehbehinderte Nutzende, die auf Screenreader wie JAWS, NVDA oder VoiceOver angewiesen sind, sind der zugängliche Name und die Rolle jeder interaktiven Komponente das primäre – und oft einzige – Mittel, um zu verstehen, was ein Steuerelement tut und wie es zu verwenden ist. Wenn eine Schaltfläche keinen zugänglichen Namen hat, hört ein Screenreader-Nutzender nur „button“, ohne Hinweis auf ihren Zweck. Wenn ein benutzerdefiniertes Dropdown keine Rolle hat, kann die Person es nicht von statischem Text unterscheiden.

Motorisch beeinträchtigte Nutzende, die Software über Switch-Zugänge, Sprachsteuerungswerkzeuge wie Dragon NaturallySpeaking oder Tastaturnavigation bedienen, sind ebenfalls auf dieses Kriterium angewiesen. Sprachsteuerungssoftware ordnet gesprochene Befehle („Klicke Absenden“) zugänglichen Namen zu. Wenn der zugängliche Name einer Schaltfläche nicht mit ihrer sichtbaren Beschriftung übereinstimmt, schlagen Sprachbefehle vollständig fehl.

Kognitive Barrierefreiheit ist gleichermaßen relevant. Konsistente, vorhersehbare Beschriftungen reduzieren die kognitive Belastung für Menschen mit Dyslexie, Gedächtnisbeeinträchtigungen oder aufmerksamkeitsspezifischen Behinderungen. Wenn Zustandsänderungen – etwa das Öffnen eines Modals oder das Pflichtwerden eines Formularfelds – nicht von unterstützenden Technologien angekündigt werden, können Nutzende desorientiert werden und Aufgaben nicht abschließen.

Betrachten wir ein konkretes Szenario aus der Praxis: Eine türkische E‑Commerce-Plattform zeigt eine „In den Warenkorb“-Schaltfläche, die als <div> mit einem Click-Handler und einem Einkaufswagen-Icon gebaut ist. Visuell sieht sie wie eine Schaltfläche aus. Da sie jedoch kein role='button', keinen zugänglichen Namen und kein tabindex='0' hat, trifft eine Screenreader-Nutzerin, die per Tastatur navigiert, auf nichts – das Element ist für ihre unterstützende Technologie vollständig unsichtbar. Sie kann keine Produkte in ihren Warenkorb legen und wird damit faktisch von der gesamten Einkaufserfahrung ausgeschlossen.

Über die Barrierefreiheit hinaus verbessern korrekt benannte und strukturierte Komponenten die SEO, weil Suchmaschinen-Crawler auf semantisches Markup angewiesen sind, um die Seitenstruktur und die interaktive Intention zu verstehen. Sie verbessern auch die Testbarkeit, da automatisierte Testframeworks Elemente mit sinnvollen Rollen und Beschriftungen zuverlässiger finden und mit ihnen interagieren können.

Wie man testet

Automatischer Scan mit axe DevTools oder Lighthouse: Installieren Sie die Browser-Erweiterung axe DevTools (Chrome oder Firefox) oder führen Sie in den Chrome DevTools unter dem Tab „Accessibility“ ein Lighthouse-Audit aus. Aktivieren Sie den Vollseiten-Scan und filtern Sie die Ergebnisse nach dem Tag WCAG 4.1.2. Achten Sie speziell auf Verstöße gegen button-name, frame-title, aria-required-attr, aria-roles und aria-input-field-name. Jeder Fund enthält das fehlerhafte Element, eine Beschreibung des Fehlers und einen vorgeschlagenen Fix. Exportieren Sie die Ergebnisse und priorisieren Sie zunächst Einträge mit der Schwere „Critical“ und „Serious“.
Tastaturnavigationstest: Trennen Sie Ihre Maus und navigieren Sie die gesamte Seite mit der Tab-Taste. Bestätigen Sie, dass jedes fokussierbare Element einen sichtbaren Fokus erhält, dass der native Fokusindikator des Browsers (oder ein benutzerdefinierter) klar sichtbar ist und dass Sie alle Steuerelemente mit Enter oder Leertaste aktivieren können. Jedes Element, das Sie erreichen und das Sie nicht allein aus dem Kontext heraus – ohne auf den Bildschirm zu schauen – identifizieren können, deutet auf einen wahrscheinlichen Fehler beim zugänglichen Namen hin.
Screenreader-Tests mit NVDA und Firefox: Öffnen Sie NVDA (Windows, kostenlos), starten Sie Firefox und navigieren Sie die Seite mit Tab durch interaktive Elemente und mit der NVDA-Elementliste (Einfügen+F7), um alle Schaltflächen, Links und Formularfelder zu durchsuchen. Hören Sie bei jedem interaktiven Element darauf, was NVDA ankündigt. Es sollte den Namen des Elements, seine Rolle und jeden relevanten Zustand vorlesen (z. B. „Abonnieren, button“ oder „E‑Mail-Adresse, erforderlich, edit text“). Markieren Sie jedes Element, das ohne Namen oder mit einer falschen Rolle angekündigt wird.
Screenreader-Tests mit VoiceOver und Safari (macOS/iOS): Aktivieren Sie VoiceOver (Befehl+F5 auf macOS), öffnen Sie Safari und verwenden Sie VO+Rechtspfeil, um durch die Elemente zu navigieren. Nutzen Sie den VoiceOver-Rotor (VO+U), um alle Formularsteuerelemente und Schaltflächen aufzulisten. Überprüfen Sie, ob die Namen aussagekräftig sind, die Rollen angemessen sind und die Zustände dynamisch aktualisiert werden, wenn Sie interagieren (zum Beispiel sollte das Umschalten eines benutzerdefinierten Akkordeons dazu führen, dass VoiceOver „expanded“ oder „collapsed“ ankündigt).
Screenreader-Tests mit JAWS und Chrome: Starten Sie JAWS und öffnen Sie Chrome. Verwenden Sie die Tab-Taste, um durch interaktive Elemente zu navigieren, und den JAWS Virtual Cursor (Einfügen+F3 für eine Liste der Formularfelder), um Beschriftungen zu überprüfen. Achten Sie besonders auf benutzerdefinierte Widgets, die mit ARIA gebaut sind – bestätigen Sie, dass Zustandsänderungen, die durch Tastaturinteraktion ausgelöst werden, in dem, was JAWS in Echtzeit ankündigt, reflektiert werden.
Überprüfung von Zuständen bei benutzerdefinierten Widgets: Interagieren Sie bei jedem benutzerdefinierten Widget (Akkordeon, Tab-Panel, Combobox, Modal) vollständig nur mit der Tastatur. Überprüfen Sie bei jedem Schritt, dass der Screenreader die korrekte Zustandsaktualisierung ankündigt – das Öffnen eines Disclosure-Widgets sollte zum Beispiel eine Ankündigung „expanded“ auslösen, und das Schließen sollte „collapsed“ ankündigen. Wenn sich der visuelle Zustand ändert, der Screenreader aber stumm bleibt, fehlt aria-expanded entweder oder wird nicht programmatisch umgeschaltet.

Wie man es behebt

Nur-Icon-Schaltfläche ohne zugänglichen Namen — Falsch

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Nur-Icon-Schaltfläche ohne zugänglichen Namen — Richtig

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

Benutzerdefiniertes Toggle-Widget ohne Rolle oder Zustand — Falsch

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

Benutzerdefiniertes Toggle-Widget ohne Rolle oder Zustand — Richtig

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

Unbeschriftetes iframe — Falsch

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

Unbeschriftetes iframe — Richtig

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

Benutzerdefinierte Fortschrittsanzeige ohne erforderliche ARIA-Attribute — Falsch

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

Benutzerdefinierte Fortschrittsanzeige ohne erforderliche ARIA-Attribute — Richtig

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

Häufige Fehler

Verwendung von role='button' auf einem <div> ohne Hinzufügen von tabindex='0' — das Element wird von Screenreadern als Schaltfläche angekündigt, bleibt aber über die Tab-Tastaturnavigation unerreichbar und ist damit für reine Tastaturnutzende unbenutzbar.
Anwenden von aria-label auf ein nicht interaktives Element — das Hinzufügen von aria-label zu einem <div> oder <span> ohne Rolle hat keine Wirkung; das Label wird von den meisten Browsern ignoriert, weil das Element keine Rolle hat, die benannt werden könnte.
Belassen von aria-expanded als statisch nach der Implementierung eines Disclosure-Widgets — wenn aria-expanded='false' im HTML gesetzt und nie mit JavaScript umgeschaltet wird, ist das Attribut nach dem ersten Klick immer falsch und kündigt Screenreader-Nutzenden den gegenteiligen Zustand an.
Verwendung von aria-hidden='true' auf einem Container, der fokussierbare Elemente enthält — dies verbirgt den Container im Accessibility Tree, nicht aber vor der Tastaturfokussierung, sodass Screenreader-Nutzende per Tab in Elemente gelangen können, die sie nicht hören, was zu extremer Verwirrung führt.
Bereitstellung eines placeholder als einziges Label für ein <input> — Placeholder-Text verschwindet bei Eingabe, wird nicht von allen Screenreadern zuverlässig als Label angekündigt und erfüllt die Anforderung eines zugänglichen Namens für Formularfelder nicht.
Verwendung einer ungültigen oder abstrakten ARIA-Rolle wie role='widget' oder role='structure' — dies sind Basisrollen in der ARIA-Spezifikation und nicht für die direkte Verwendung vorgesehen; sie liefern keine sinnvolle semantische Information und können von unterstützenden Technologien ignoriert werden oder Fehler verursachen.
Verweis auf eine nicht existierende Element-ID in aria-labelledby — wenn die von aria-labelledby referenzierte ID im DOM nicht existiert, schlägt die Berechnung des zugänglichen Namens fehl und das Element bleibt ohne Namen.
Verwendung von value statt aria-label für <input type='image'> — Image-Input-Schaltflächen benötigen ein alt-Attribut für ihren zugänglichen Namen; das value-Attribut wird bei Image-Inputs für die Namensberechnung ignoriert.
Weglassen des title-Attributs bei <iframe>-Elementen, die Inhalte Dritter laden — Entwickelnde gehen oft davon aus, dass bekannte Einbettungen (Karten, Zahlungs-Widgets, Videoplayer) selbsterklärend sind, aber Screenreader-Nutzende müssen über den Zweck des Frames informiert werden, bevor sie entscheiden, ob sie ihn betreten.
Vergessen, zugängliche Namen dynamisch zu aktualisieren, wenn sich Inhalte ändern — wenn sich die Beschriftung einer Schaltfläche visuell von „Play“ zu „Pause“ ändert, das aria-label aber „Play“ bleibt, erhalten Screenreader-Nutzende falsche Informationen über den aktuellen Zustand und die Aktion.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die digitale Barrierefreiheit fest, die an WCAG 2.2 ausgerichtet sind. WCAG 4.1.2 — Name, Rolle, Wert ist ein Kriterium der Stufe A, was bedeutet, dass es auf der grundlegendsten Konformitätsstufe angesiedelt ist. Nach der Verfügung ist Konformität auf Stufe A nicht optional – sie ist die Basis, die alle erfassten Stellen erreichen müssen.

Die Verfügung gilt für eine breite Palette von Akteurstypen, die in der Türkei tätig sind. Öffentliche Institutionen – einschließlich Ministerien, Gemeinden und staatlicher Behörden – müssen innerhalb von einem Jahr nach dem Veröffentlichungsdatum der Verfügung Konformität erreichen. Private Sektorunternehmen – einschließlich E‑Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und private Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind – müssen innerhalb von zwei Jahren Konformität erreichen.

WCAG 4.1.2 ist für türkische Organisationen besonders folgenschwer, weil so viele moderne türkische Websites auf benutzerdefinierte interaktive Komponenten setzen – Produktkarussells, FAQ-Akkordeons, schrittweise Checkout-Flows und Banking-Dashboards –, die häufig ohne korrekte ARIA-Rollen, Namen oder Zustandsverwaltung implementiert werden. Eine benutzerdefinierte Checkout-Schaltfläche ohne zugänglichen Namen oder ein Kreditrechner-Slider ohne aria-valuenow ist nicht nur eine schlechte User Experience: Nach der Verfügung stellt dies einen rechtlichen Konformitätsverstoß dar.

Für Banken und E‑Commerce-Plattformen, die der Verfügung unterliegen, sind Verstöße gegen WCAG 4.1.2 in transaktionskritischen Abläufen – Zahlungsformulare, Authentifizierungsmodals, Kontodashboards – besonders risikoreich. Eine visuell gestaltete benutzerdefinierte Combobox zur Auswahl einer Bankfiliale, die kein korrektes ARIA-Markup hat, kann verhindern, dass eine Screenreader-Nutzerin eine Transaktion überhaupt abschließen kann, und setzt das Institut sowohl regulatorischen Maßnahmen als auch Diskriminierungsklagen aus.

Organisationen, die das Accsible-Overlay-SDK verwenden, können von der automatisierten Erkennung und Laufzeitbehebung vieler Verstöße gegen Name, Rolle, Wert profitieren – einschließlich des Einfügens fehlender zugänglicher Namen, der Korrektur ungültiger ARIA-Rollen bei bekannten Widget-Mustern und der Synchronisierung von Zustandsattributen bei interaktiven Komponenten. Organisationen sollten die automatisierte Overlay-Unterstützung jedoch als Ergänzung und nicht als Ersatz für korrektes semantisches HTML betrachten, insbesondere bei komplexen benutzerdefinierten Widgets, bei denen die programmatische Zustandsverwaltung von Anfang an in die Anwendungslogik eingebettet sein muss.