WCAG 2.5.3: Bezeichnung im Namen

Was diese Regel bedeutet

\n

WCAG 2.5.3 — Label in Name — gilt für jede Benutzeroberflächenkomponente, die eine sichtbare Textbeschriftung hat. Das Kriterium verlangt, dass der zugängliche Name dieser Komponente entweder exakt mit dem sichtbaren Beschriftungstext übereinstimmt oder mindestens den sichtbaren Beschriftungstext als Teilzeichenkette enthält. Dies verhindert eine Situation, in der eine Nutzerin oder ein Nutzer auf dem Bildschirm eine Beschriftung sieht, während ihre bzw. seine unterstützende Technologie oder Spracherkennungssoftware im Hintergrund einen völlig anderen Namen erkennt.

\n

Der zugängliche Name ist der Name, der im Accessibility Tree verfügbar gemacht und von Screenreadern, Sprachsteuerungssoftware und anderen unterstützenden Technologien verwendet wird. Er kann aus verschiedenen Quellen stammen, darunter der sichtbare Textinhalt des Elements, ein aria-label-Attribut, ein aria-labelledby-Verweis, ein title-Attribut oder ein zugeordnetes <label>-Element. Wenn eine Entwicklerin oder ein Entwickler den zugänglichen Namen mit etwas überschreibt, das den sichtbaren Beschriftungstext nicht enthält, entsteht eine Diskrepanz und das Kriterium ist nicht erfüllt.

\n

Betroffene Elemente sind alle interaktiven Komponenten, die Text anzeigen und außerdem einen zugänglichen Namen haben: Schaltflächen, Links, Formulareingaben mit sichtbaren Beschriftungen, Menüpunkte, Tabs, Kontrollkästchen, Optionsfelder und benutzerdefinierte ARIA-Widgets. Nicht interaktive Elemente wie Absätze oder Überschriften fallen nicht unter dieses Kriterium.

\n

Was als bestanden gilt: Der zugängliche Name enthält den sichtbaren Beschriftungstext als durchgehende Teilzeichenkette, wobei führende und nachfolgende Leerzeichen ignoriert werden. Die Übereinstimmung ist nicht case-sensitiv. Wenn beispielsweise eine Schaltfläche „Search Products“ anzeigt, besteht ein zugänglicher Name „Search Products Now“, weil er „Search Products“ enthält. Ein zugänglicher Name „Find Products“ fällt durch, weil er den sichtbaren Text nicht enthält.

\n

Was als nicht bestanden gilt: Der zugängliche Name unterscheidet sich vollständig von der sichtbaren Beschriftung oder der zugängliche Name lässt einen bedeutungsvollen Teil der sichtbaren Beschriftung weg. Eine Schaltfläche, die visuell „Buy Now“ anzeigt, aber aria-label='Purchase item' hat, erfüllt dieses Kriterium nicht. Ebenso fällt ein Link durch, der „Contact Us“ anzeigt, aber in ein Element mit aria-label='Reach our team' eingebettet ist.

\n

Offizielle Ausnahmen laut WCAG: Das Kriterium gilt nicht für Komponenten, bei denen die Beschriftung rein symbolisch oder piktografisch ohne textliches Äquivalent ist (zum Beispiel eine reine Icon-Schaltfläche ohne sichtbaren Text). Es gilt auch nicht, wenn der Text Teil eines rein dekorativen Elements ist, das keine semantische Bedeutung trägt. Mathematische Notation und sprachspezifische Szenarien, in denen die Textdarstellung nicht auf ein gesprochenes Wort abgebildet werden kann, sind ebenfalls ausgenommen. Zusätzlich sind Komponenten konform, bei denen der zugängliche Name absichtlich mit zusätzlichem Kontext erweitert wird — vorausgesetzt, der sichtbare Text ist weiterhin im zugänglichen Namen enthalten.

\n\n

Warum das wichtig ist

\n

Dieses Kriterium schützt in erster Linie Nutzerinnen und Nutzer, die auf Spracherkennungssoftware wie Dragon NaturallySpeaking (jetzt Dragon Professional), Windows Speech Recognition oder Apples Voice Control angewiesen sind. Diese Personen navigieren und aktivieren Interface-Elemente, indem sie die Beschriftung aussprechen, die sie auf dem Bildschirm sehen. Wenn der zugängliche Name nicht mit der sichtbaren Beschriftung übereinstimmt, kann die Software das Zielelement nicht finden, wenn die Person seinen Namen ausspricht, wodurch das Steuerelement ohne Maus oder Tastatur faktisch unerreichbar wird. Für Menschen mit motorischen Beeinträchtigungen — einschließlich Personen mit RSI, Muskeldystrophie, Zerebralparese oder Rückenmarksverletzungen — ist Spracheingabe oft das primäre oder einzige Mittel zur Bedienung eines Computers. Eine Diskrepanz bei einer einzigen Schaltfläche kann den Zugang zu einem gesamten Workflow blockieren.

\n

Auch Screenreader-Nutzerinnen und -Nutzer sind betroffen. Wenn ein Screenreader einen zugänglichen Namen ankündigt, der sich von dem unterscheidet, was auf dem Bildschirm sichtbar ist, führt das zu kognitiver Desorientierung. Eine sehende Person, die zusätzlich einen Screenreader verwendet — zum Beispiel jemand mit Sehrest, der gleichzeitig visuelles und auditives Feedback nutzt — kann etwas anderes hören als das, was sie auf dem Bildschirm liest, was ihr mentales Modell der Benutzeroberfläche stört.

\n

Menschen mit kognitiven Beeinträchtigungen profitieren von Konsistenz zwischen dem, was sie lesen, und dem, was gesprochen oder angekündigt wird. Unerwartete Namensänderungen erhöhen die kognitive Belastung und können zu Verwirrung oder Fehlern führen, insbesondere bei Personen mit Gedächtnisbeeinträchtigungen oder solchen, die ein System zum ersten Mal erlernen.

\n

Ein konkretes Szenario aus der Praxis: Betrachten Sie eine Checkout-Seite im E-Commerce mit einer Schaltfläche, die visuell den Text „Place Order“ anzeigt. Eine Entwicklerin oder ein Entwickler fügt aria-label='Submit purchase form' hinzu, um aus ihrer bzw. seiner Sicht einen beschreibenderen Namen zu bieten. Eine Kundin oder ein Kunde, die bzw. der Dragon NaturallySpeaking verwendet, sagt „Click Place Order“ — Dragon durchsucht den Accessibility Tree, findet kein Element mit dem Namen „Place Order“ und kann die Schaltfläche nicht aktivieren. Die Person kann den Kauf nicht abschließen, ohne auf Maussteuerung umzusteigen, was ihr bzw. ihm möglicherweise nicht möglich ist. Sie brechen den Vorgang ab. Dies ist kein hypothetischer Randfall; es ist ein häufiges Fehlermuster, das in automatisierten Audits auf Einzelhandels- und Bankwebsites gefunden wird.

\n

Laut Weltgesundheitsorganisation leben weltweit über eine Milliarde Menschen mit irgendeiner Form von Behinderung. Der WebAIM Million Report 2023 stellte fest, dass WCAG-2.5.3-Beschriftungsdiskrepanzen in einem bedeutenden Anteil der geprüften Seiten auftraten, häufig verursacht durch gut gemeintes, aber falsch angewendetes ARIA. Über die Barrierefreiheit hinaus verbessert konsistente Beschriftung die SEO, weil Suchmaschinen-Crawler, die Link- und Schaltflächentexte für die Relevanzbewertung indexieren, aussagekräftigere Signale erhalten, wenn zugängliche Namen mit sichtbarem Text übereinstimmen.

\n\n

Verwandte Axe-core-Regeln

\n

\n
• label-content-name-mismatch: Dies ist die primäre automatisierte Regel, die mit WCAG 2.5.3 verknüpft ist. Die Regel prüft interaktive Elemente — wie Schaltflächen, Links und ARIA-Rollen wie role='button', role='link', role='menuitem' und role='tab' —, die sowohl eine sichtbare Textbeschriftung als auch einen zugänglichen Namen haben. Sie markiert jedes Element, bei dem der zugängliche Name den sichtbaren Text nicht als Teilzeichenkette enthält (nicht case-sensitiv). Die Regel zielt speziell auf Elemente ab, bei denen der zugängliche Name durch aria-label oder aria-labelledby in einer Weise überschrieben wird, die vom Text auf dem Bildschirm abweicht. Axe meldet diese als Verstöße mit der Auswirkungsstufe „serious“, weil sie Nutzerinnen und Nutzer von Spracheingabe direkt daran hindern, Steuerelemente zu aktivieren.
\n
• Grenzen der automatisierten Erkennung: Automatisierte Tools wie axe-core können Diskrepanzen zuverlässig erkennen, wenn der sichtbare Text als einfache Textknoten innerhalb des Elements gerendert wird und der zugängliche Name aus einem statischen aria-label- oder aria-labelledby-Attribut stammt. Manuelle Tests sind jedoch erforderlich, wenn: (1) der sichtbare Text über CSS-::before- oder ::after-Pseudoelemente gerendert wird, da diese je nach Browser- und AT-Version möglicherweise nicht im Accessibility Tree enthalten sind; (2) die Beschriftung nach dem Laden der Seite dynamisch per JavaScript eingefügt wird; (3) der sichtbare Text Icons oder bildbasierten Text enthält, bei denen die Textkomponente erschlossen werden muss; (4) der berechnete zugängliche Name des Elements komplexe aria-labelledby-Ketten umfasst, die mehrere Elemente verketten. In diesen Fällen muss eine menschliche Testerin oder ein menschlicher Tester mit einem Screenreader überprüfen, was tatsächlich angekündigt wird im Vergleich zu dem, was sichtbar ist.
\n

\n\n

Wie man testet

\n

\n
1. Automatischer Scan mit axe DevTools oder Lighthouse: Installieren Sie die axe DevTools Browser-Erweiterung (Chrome oder Firefox) oder führen Sie ein Lighthouse-Accessibility-Audit in den Chrome DevTools aus. Starten Sie den Scan auf der vollständig gerenderten Seite — stellen Sie sicher, dass dynamische Inhalte, Modale und aufgeklappte Menüs geöffnet sind, wenn sie interaktive Elemente enthalten. Filtern Sie im axe-Ergebnisbereich nach der Regel-ID label-content-name-mismatch. Jedes markierte Element zeigt seinen berechneten zugänglichen Namen zusammen mit dem sichtbaren Text an, sodass die Diskrepanz sofort erkennbar ist. Notieren Sie den Element-Selektor und untersuchen Sie das DOM, um die Quelle der Überschreibung des zugänglichen Namens zu identifizieren. Lighthouse zeigt dieselben Fehler im Bereich „Accessibility“ mit einem Verweis auf WCAG 2.5.3 an.
\n
2. Manuelle Prüfung mit Browser-DevTools: Öffnen Sie das Accessibility-Panel des Browsers (Chrome DevTools → Elements → Accessibility-Tab oder Firefox DevTools → Accessibility-Tab). Wählen Sie jedes interaktive Element mit sichtbarem Text aus. Prüfen Sie im Abschnitt „Computed Properties“ das Feld Name des Elements. Vergleichen Sie diesen Wert mit der sichtbaren Beschriftung. Wenn der berechnete Name den sichtbaren Beschriftungstext nicht als Teilzeichenkette enthält, besteht das Element 2.5.3 nicht.
\n
3. Screenreader-Test mit NVDA + Firefox: Öffnen Sie Firefox mit laufendem NVDA. Navigieren Sie mit der Tab-Taste zu jedem interaktiven Element. Hören Sie, was NVDA als Namen des Elements ankündigt. Notieren Sie jede Abweichung zwischen dem angekündigten Namen und dem auf dem Bildschirm angezeigten Text. Verwenden Sie NVDA's Element List (Einfg+F7), um alle Links und Schaltflächen zu durchsuchen und die angekündigten Namen in größerem Umfang mit den visuellen Beschriftungen zu vergleichen.
\n
4. Screenreader-Test mit JAWS + Chrome: Öffnen Sie Chrome mit laufendem JAWS. Tabben Sie durch alle interaktiven Steuerelemente. JAWS kündigt den zugänglichen Namen gefolgt von der Rolle an. Wenn der angekündigte Name den sichtbaren Text nicht enthält, notieren Sie das Element. Verwenden Sie zusätzlich den „Browse Mode“ von JAWS und den virtuellen Viewer, um den berechneten zugänglichen Namen für jedes Steuerelement anzuzeigen.
\n
5. Screenreader-Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Befehl+F5 auf macOS). Navigieren Sie mit Tab oder VO+Pfeil rechts durch interaktive Elemente. VoiceOver kündigt den zugänglichen Namen für jedes Steuerelement an. Wischen Sie auf iOS mit einem Finger nach rechts, um durch die Elemente zu gehen, und achten Sie auf Diskrepanzen zwischen Namen und Beschriftungen.
\n
6. Spracherkennungstest mit Voice Control (macOS/iOS) oder Dragon: Aktivieren Sie macOS Voice Control (Systemeinstellungen → Bedienungshilfen → Voice Control). Sagen Sie „Show names“, um Beschriftungen für alle interaktiven Elemente anzuzeigen. Überprüfen Sie, ob die von Voice Control angezeigten Beschriftungen mit dem sichtbaren Text auf dem Bildschirm übereinstimmen. Versuchen Sie, Steuerelemente zu aktivieren, indem Sie den sichtbaren Beschriftungstext aussprechen — jedes Steuerelement, das nicht auf seinen sichtbaren Namen reagiert, ist ein 2.5.3-Verstoß. Wiederholen Sie dies mit Dragon NaturallySpeaking unter Windows, falls verfügbar, mit dem Befehl „Click [label]“.
\n

\n\n

Wie man es behebt

\n\n

Schaltfläche mit überschreibendem aria-label — Falsch

\n

<!-- FAIL: aria-label ersetzt den sichtbaren Text \"Search\"\n     vollständig durch \"Execute query\" und bricht damit die Spracheingabe -->\n<button aria-label='Execute query'>\n  Search\n</button>

\n\n

Schaltfläche mit überschreibendem aria-label — Richtig

\n

<!-- PASS: Entfernen Sie das nicht übereinstimmende aria-label vollständig.\n     Der sichtbare Text \"Search\" der Schaltfläche wird automatisch ihr zugänglicher Name.\n     Sprach-Nutzerinnen und -Nutzer können \"Click Search\" sagen, um sie zu aktivieren. -->\n<button>\n  Search\n</button>\n\n<!-- PASS (Alternative): Wenn zusätzlicher Kontext benötigt wird,\n     stellen Sie sicher, dass der zugängliche Name den sichtbaren Text ENTHÄLT. -->\n<button aria-label='Search products'>\n  Search\n</button>

\n\n

Link mit aria-labelledby, das auf nicht verwandten Text zeigt — Falsch

\n

<!-- FAIL: aria-labelledby verweist auf eine Überschrift \"Our Services\",\n     aber der Link zeigt visuell \"Learn more\",\n     sodass der zugängliche Name \"Our Services\" statt \"Learn more\" ist -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' aria-labelledby='services-heading'>Learn more</a>\n</p>

\n\n

Link mit aria-labelledby, das auf nicht verwandten Text zeigt — Richtig

\n

<!-- PASS: Verwenden Sie aria-labelledby, um den eigenen Text des Links mit der Überschrift zu verketten.\n     Der zugängliche Name wird zu \"Learn more Our Services\",\n     was die sichtbare Beschriftung \"Learn more\" enthält. -->\n<h2 id='services-heading'>Our Services</h2>\n<p>\n  <a href='/services' id='learn-link' aria-labelledby='learn-link services-heading'>\n    Learn more\n  </a>\n</p>\n\n<!-- PASS (Alternative): Machen Sie den sichtbaren Linktext selbsterklärend,\n     sodass keine Überschreibung nötig ist. -->\n<a href='/services'>Learn more about our services</a>

\n\n

Icon-Schaltfläche, bei der aria-label mit sichtbarem Text kollidiert — Falsch

\n

<!-- FAIL: Die Schaltfläche zeigt ein Warenkorb-Icon UND den Text \"Cart\".\n     Das aria-label 'View shopping basket' enthält \"Cart\" nicht,\n     sodass Sprach-Nutzerinnen und -Nutzer, die \"Click Cart\" sagen, keine Reaktion erhalten. -->\n<button aria-label='View shopping basket'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Icon-Schaltfläche, bei der aria-label mit sichtbarem Text kollidiert — Richtig

\n

<!-- PASS: Das aria-label enthält den sichtbaren Text \"Cart\" als Teilzeichenkette.\n     Sprach-Nutzerinnen und -Nutzer können \"Click Cart\" oder \"Click View Cart\" sagen, und beides funktioniert. -->\n<button aria-label='View Cart'>\n  <svg aria-hidden='true'><!-- cart icon --></svg>\n  Cart\n</button>\n\n<!-- PASS (bevorzugt): Entfernen Sie aria-label und blenden Sie das Icon im Tree aus.\n     Der Textinhalt \"Cart\" der Schaltfläche wird direkt zum zugänglichen Namen. -->\n<button>\n  <svg aria-hidden='true' focusable='false'><!-- cart icon --></svg>\n  Cart\n</button>

\n\n

Formulareingabe mit sichtbarer Beschriftung, aber nicht übereinstimmendem aria-label — Falsch

\n\n

(Content truncated due to token limit — please retry this article.)