Ein Kriterium der Stufe A: Bei Bedienelementen mit sichtbarer Textbeschriftung muss der zugängliche Name diesen Text enthalten – idealerweise übereinstimmend und mit ihm beginnend.

Warum ist das wichtig?

Nutzer von Spracherkennung sprechen die sichtbare Beschriftung aus, um ein Element zu aktivieren. Weicht der zugängliche Name davon ab, schlägt der Sprachbefehl fehl.

Was ist ein typischer Verstoß?

Eine Schaltfläche mit der Aufschrift `Suchen`, aber aria-label='Abfrage absenden' – das sichtbare Wort `Suchen` fehlt im zugänglichen Namen und die Sprachsteuerung scheitert.

Erfolgskriterien

WCAG 2.5.3 Beschriftung im Namen

Erfolgskriterium 2.5.3 verlangt, dass für Benutzeroberflächen-Komponenten mit sowohl einer sichtbaren Textbeschriftung als auch einem barrierefreien Namen der barrierefreie Name den sichtbaren Beschriftungstext enthält. Es ist ein Kriterium der Stufe A unter Richtlinie 2.5 (Eingabemodalitäten), hinzugefügt in WCAG 2.1.

Wen dies schützt, und warum die Diskrepanz wichtig ist

Spracheingabesoftware (Dragon NaturallySpeaking, Voice Control, Voice Access) lässt Nutzer eine Oberfläche bedienen, indem sie die sichtbare Beschriftung dessen sagen, womit sie interagieren möchten – "klicke Absenden", "tippe Suche". Dies funktioniert nur, wenn der barrierefreie Name des Steuerelements (das, was assistive Technologie, einschließlich Spracherkennungssoftware, tatsächlich liest) dem entspricht oder es enthält, was visuell auf der Schaltfläche steht. Wenn eine Schaltfläche visuell "Absenden" sagt, ihr barrierefreier Name (über aria-label gesetzt) aber tatsächlich "Formulardaten senden" ist, findet ein Sprachsteuerungsnutzer, der "klicke Absenden" sagt, keine Übereinstimmung, die die Software erkennt – der Befehl scheitert lautlos.

Die häufige Ursache: Überschreiben barrierefreier Namen mit unbezogenem Text

<!-- Sichtbarer Text sagt "Suchen", aber der barrierefreie Name ist völlig anders -->
<button aria-label="Artikel in unserem Katalog finden">Suchen</button>

Ein Screenreader-Nutzer hört "Artikel in unserem Katalog finden", ein sehender Nutzer sieht "Suchen", und ein Sprachsteuerungsnutzer, der "klicke Suchen" sagt, erhält überhaupt keine Übereinstimmung – drei verschiedene, unverbundene Erfahrungen derselben Schaltfläche.

Die Lösung

Stellen Sie sicher, dass jedes aria-label (oder aria-labelledby), das auf ein Element angewendet wird, das auch sichtbaren Text hat, entweder genau diesem sichtbaren Text entspricht oder ihn zumindest als Teilzeichenkette enthält:

<!-- Barrierefreier Name (aria-label) enthält den sichtbaren Text -->
<button aria-label="In unserem Katalog suchen">Suchen</button>

Warum dies oft ein leicht vermeidbarer Fehler ist

Dieser Verstoß passiert meist, wenn ein Entwickler ein aria-label hinzufügt, um zusätzlichen Kontext bereitzustellen, ohne zu erkennen, dass es den aus sichtbarem Text berechneten barrierefreien Namen vollständig ersetzt statt zu ergänzen. Wenn das Ziel nur zusätzlicher Kontext über die sichtbare Beschriftung hinaus ist, erfüllt es beide Ziele gleichzeitig, den sichtbaren Text als Anfang des aria-label beizubehalten (wie in der obigen Lösung).

Offizielle Referenzen

Deque University: label-content-name-mismatch

Häufige Fragen

Was ist WCAG 2.5.3?: Ein Kriterium der Stufe A: Bei Bedienelementen mit sichtbarer Textbeschriftung muss der zugängliche Name diesen Text enthalten – idealerweise übereinstimmend und mit ihm beginnend.
Warum ist das wichtig?: Nutzer von Spracherkennung sprechen die sichtbare Beschriftung aus, um ein Element zu aktivieren. Weicht der zugängliche Name davon ab, schlägt der Sprachbefehl fehl.
Was ist ein typischer Verstoß?: Eine Schaltfläche mit der Aufschrift `Suchen`, aber aria-label='Abfrage absenden' – das sichtbare Wort `Suchen` fehlt im zugänglichen Namen und die Sprachsteuerung scheitert.