WCAG 2.5.3: Beschriftung im Namen

WCAG 2.5.3 verlangt, dass bei Bedienelementen mit sichtbarer Textbeschriftung der zugängliche Name diesen Text wortwörtlich enthält – idealerweise beginnt er damit. Steht auf dem Knopf „Jetzt kaufen“, darf sein aria-label nicht „Bestellung abschließen“ lauten, weil die Sprachsteuerung dann nichts findet.

(Englisch: Label in Name. Der BIK-BITV-Test nennt den Prüfschritt „Sichtbare Beschriftung Teil des zugänglichen Namens“.)

Das Wichtigste in Kürze

• Der sichtbare Text muss vollständig und in derselben Form im zugänglichen Namen vorkommen. Zusätzlicher Text davor oder dahinter ist erlaubt, Ersetzen nicht.
• Der häufigste Verursacher ist ein aria-label auf einem Element, das schon sichtbaren Text hat. ARIA überschreibt den Textinhalt vollständig.
• Betroffen ist alles mit sichtbarer Beschriftung: Links, Schaltflächen, Eingabefelder mit <label>, Kontrollkästchen, Auswahllisten.
• Der eigentliche Zweck ist die Sprachsteuerung. „Klicke Jetzt kaufen“ sucht den gesprochenen Text im zugänglichen Namen; weicht er ab, passiert nichts.
• Der Beginn zählt. Der Normtext empfiehlt, dass der sichtbare Text am Anfang des Namens steht – manche Sprachsteuerungen gleichen nur den Anfang ab.
• Groß- und Kleinschreibung sowie Satzzeichen dürfen abweichen. Ein per CSS in Großbuchstaben gesetzter Knopf ist kein Verstoß.
• Nicht anwendbar ist der Prüfschritt bei Beschriftungen aus mehreren visuellen Bestandteilen – etwa einer Zelle, die sich aus Zeilen- und Spaltenkopf erklärt.
• Häufigste Fundstellen: „Mehr erfahren“-Knöpfe mit ergänzendem aria-label, Icon-plus-Text-Kombinationen, Suchfelder mit Platzhaltertext und übersetzte Oberflächen mit englischen ARIA-Werten.

Muss aria-label zur sichtbaren Beschriftung passen?

Ja – der zugängliche Name muss den sichtbaren Text wortwörtlich enthalten, idealerweise am Anfang.

Der zugängliche Name ist das, was assistive Technik für ein Element ansagt und worüber sie es anspricht. Der Browser berechnet ihn nach einer festen Rangfolge: aria-labelledby schlägt aria-label, das schlägt das zugeordnete <label> oder den Textinhalt, das schlägt title. Wer also ein aria-label setzt, wirft alles darunter weg – auch den Text, der auf dem Knopf steht.

Genau da setzt 2.5.3 an. Es verlangt, dass die sichtbare Beschriftung im zugänglichen Namen enthalten ist. Der BITV-Prüfschritt formuliert es strenger als manche Zusammenfassung: Der Beschriftungstext muss in der gleichen Form vorkommen, also als zusammenhängende Zeichenkette, nicht sinngemäß.

Warum das mehr ist als Kosmetik: Sprachsteuerung funktioniert über den sichtbaren Text. Wer „Klicke Jetzt kaufen“ sagt, erwartet, dass die Software den Knopf findet, auf dem „Jetzt kaufen“ steht. Sie sucht diesen Text aber nicht auf dem Bildschirm, sondern im zugänglichen Namen. Steht dort etwas anderes, ist der Knopf für sie unsichtbar – sichtbar für alle anderen, unerreichbar per Stimme.

Es gibt einen zweiten Grund, der Menschen betrifft, die sehen und hören: Wer mit Screenreader arbeitet und dabei den Bildschirm sieht, bekommt bei abweichenden Namen zwei widersprüchliche Informationen. Der Vorleser sagt „Bestellung abschließen“, auf dem Knopf steht „Jetzt kaufen“. Das kostet Vertrauen und Zeit.

Was ausdrücklich erlaubt ist:

• Ergänzen. aria-label="Jetzt kaufen – 3 Artikel im Warenkorb" ist konform, weil der sichtbare Text vollständig darin steckt und am Anfang steht.
• Abweichende Groß- und Kleinschreibung. Ein Knopf, der per text-transform: uppercase in Versalien erscheint, während im Markup „Jetzt kaufen“ steht, ist unproblematisch.
• Abweichende Satzzeichen. Ein Doppelpunkt oder Auslassungspunkte im sichtbaren Text müssen nicht im Namen auftauchen.

Was nicht anwendbar ist: Bedienelemente, deren Beschriftung sich aus mehreren visuellen Bestandteilen zusammensetzt – etwa ein Kontrollkästchen in einer Matrix, das erst durch Zeilen- und Spaltenüberschrift verständlich wird. Dort greift statt 2.5.3 die Frage nach der programmatischen Zuordnung, also 1.3.1.

Der vollständige Wortlaut steht im Understanding-Dokument des W3C zu 2.5.3; das deutsche Prüfvorgehen beschreibt der Prüfschritt 2.5.3 des BIK BITV-Tests.

Wen betrifft es besonders?

Nutzer von Sprachsteuerung sind die Gruppe, für die dieses Kriterium geschrieben wurde: Dragon NaturallySpeaking unter Windows, die Sprachsteuerung von macOS und iOS, Voice Access unter Android. Menschen mit hoher Querschnittlähmung, mit Amyotropher Lateralsklerose, nach einem Schlaganfall oder mit schwerer Arthritis bedienen den Rechner damit vollständig. Für sie ist ein Knopf mit abweichendem Namen kein Ärgernis, sondern ein Bedienelement, das schlicht nicht existiert.

Die Sprachsteuerung bietet zwar Ausweichwege – ein Zahlenraster über den Bildschirm legen und die Nummer sagen, oder ein Mausraster. Beides kostet mehrere Schritte pro Klick. Wer ein Formular mit zwölf Feldern so ausfüllt, verbringt Minuten mit dem, was per Sprachbefehl Sekunden dauern würde.

Screenreader-Nutzer mit Restsehvermögen und Menschen, die einen Vorleser zusätzlich zum Bildschirm nutzen – etwa bei Legasthenie –, bekommen bei abweichenden Namen widersprüchliche Signale. Sie hören etwas anderes, als sie lesen, und müssen entscheiden, welcher Angabe sie trauen.

Und die Gruppe, die man selten mitzählt: alle, die eine Anwendung telefonisch erklärt bekommen. „Klicken Sie auf Jetzt kaufen“ funktioniert nur, wenn die Beschriftung eindeutig ist – und das ist genau der Zustand, den 2.5.3 herstellt.

Richtig & falsch im Code

Die erste Regel ist keine Regel des Kriteriums, sondern ihre praktische Umsetzung: Setz kein aria-label auf Elemente, die sichtbaren Text haben.

<!-- Falsch: aria-label ersetzt den sichtbaren Text -->
<button aria-label="Bestellung abschließen">Jetzt kaufen</button>

<!-- Falsch: der sichtbare Text kommt im Namen gar nicht vor -->
<a href="/tarife.html" aria-label="Tarifübersicht öffnen">Mehr erfahren</a>

<!-- Richtig: kein ARIA nötig, der Textinhalt ist der Name -->
<button>Jetzt kaufen</button>

<!-- Richtig: sichtbarer Text am Anfang, Ergänzung dahinter -->
<a href="/tarife.html" aria-label="Mehr erfahren über unsere Tarife">
  Mehr erfahren
</a>

Für den Klassiker „mehrere gleich beschriftete Links auf einer Seite“ ist die schönere Lösung ohnehin sichtbarer Text plus ein visuell verstecktes Stück:

<!-- Richtig: der Name ist „Mehr erfahren über den Tarif Basis“,
     sichtbar bleibt „Mehr erfahren“ – und 2.4.4 ist gleich mit erfüllt -->
<a href="/tarife/basis.html">
  Mehr erfahren<span class="visually-hidden"> über den Tarif Basis</span>
</a>

Bei Eingabefeldern entsteht der Verstoß meist durch ein aria-label, das den Platzhalter „ordentlicher“ formulieren soll:

<!-- Falsch: sichtbares Label und Name gehen auseinander -->
<label for="such">Suche</label>
<input id="such" type="search" aria-label="Produkte und Artikel durchsuchen" />

<!-- Richtig: das Label ist der Name, die Ergänzung steht hinten -->
<label for="such">Suche</label>
<input id="such" type="search"
       aria-label="Suche nach Produkten und Artikeln" />

<!-- Noch besser: keine Ergänzung nötig -->
<label for="such">Suche</label>
<input id="such" type="search" />

Bei Icon-und-Text-Kombinationen ist die häufigste Falle ein aria-label auf dem Container. Wenn der Text sichtbar ist, braucht das Icon nur ein aria-hidden:

<!-- Falsch: der Name lautet „Herunterladen“, sichtbar steht „PDF speichern“ -->
<button aria-label="Herunterladen">
  <svg aria-hidden="true">…</svg>
  PDF speichern
</button>

<!-- Richtig: Icon stumm, Text spricht -->
<button>
  <svg aria-hidden="true" focusable="false">…</svg>
  PDF speichern
</button>

Ein Sonderfall, der oft übersehen wird: Wenn der sichtbare Text aus einem ::before- oder ::after-Pseudoelement stammt, zählt er in vielen Browsern zum zugänglichen Namen – in anderen nicht. Wer Beschriftungen über CSS erzeugt, riskiert also Abweichungen zwischen den Browsern. Sichtbarer Text gehört ins Markup.

Wie der zugängliche Name im Detail berechnet wird, steht unter 4.1.2 Name, Rolle, Wert; die Grundregel dazu unter Die erste Regel von ARIA.

So testest du es

1. Automatisch vorfiltern. axe DevTools und Lighthouse prüfen die Regel „label-in-name“ direkt und finden die eindeutigen Fälle. Das ersetzt die manuelle Prüfung nicht, spart aber den ersten Durchgang.
2. Im Accessibility-Panel gegenlesen. In den DevTools von Chrome oder Firefox für jedes beschriftete Bedienelement den berechneten Namen anzeigen lassen und mit dem sichtbaren Text vergleichen.
3. Auf die Zeichenkette achten, nicht auf den Sinn. Der Prüfschritt verlangt, dass der sichtbare Text in gleicher Form im Namen vorkommt. „Kaufen jetzt“ erfüllt das nicht, „Jetzt kaufen – 3 Artikel“ schon.
4. Praxisprobe mit Sprachsteuerung. Voice Control unter macOS oder iOS aktivieren, Voice Access unter Android, und die sichtbaren Beschriftungen ansprechen: „Klicke Jetzt kaufen“. Das ist der Test, der zählt.
5. Formulare gesondert prüfen. Bei Eingabefeldern kommt der Name aus dem <label>, sofern kein ARIA dazwischenfunkt. Fehlt die Verknüpfung ganz, scheitert zusätzlich 3.3.2 Beschriftungen oder Anweisungen.
6. Übersetzte Oberflächen doppelt ansehen. In mehrsprachigen Anwendungen bleiben ARIA-Werte oft in der Ausgangssprache stehen, während der sichtbare Text übersetzt wurde.
7. Im Quelltext nach aria-label suchen und jede Fundstelle danach beurteilen, ob das Element sichtbaren Text hat. Wenn ja, ist es ein Kandidat für einen Befund.

Häufiger Fehler in der Praxis

Der häufigste Fall ist das wohlmeinende aria-label. Jemand hat gelernt, dass „Mehr erfahren“ als Linktext zu unspezifisch ist – was stimmt, das verlangt 2.4.4 Linkzweck im Kontext – und ergänzt deshalb ein aria-label="Tarifübersicht öffnen". Damit ist 2.4.4 gelöst und 2.5.3 gerissen: Der sichtbare Text kommt im Namen nicht mehr vor. Die Lösung, die beides erfüllt, ist der sichtbare Text plus eine visuell versteckte Ergänzung.

Der zweite ist die englische Beschriftung in der deutschen Oberfläche. Der Knopf zeigt „Speichern“, im Markup steht aria-label="Save" – Überbleibsel aus dem Ursprungsprojekt oder aus einer Komponentenbibliothek. Für die deutsche Sprachsteuerung ist der Knopf damit tot. Ich hab mir angewöhnt, bei internationalen Produkten als Erstes im Quelltext nach aria-label= zu suchen und die Treffer gegen die Oberflächensprache zu halten – das findet die halbe Fundliste in fünf Minuten.

Der dritte ist der Platzhalter statt Label. Ein Suchfeld ohne <label>, dafür mit placeholder="Suchbegriff eingeben" und aria-label="Website durchsuchen". Der Platzhalter ist der einzige sichtbare Text – und er kommt im Namen nicht vor. Formal ist der Platzhalter kein Label, aber Nutzer und Prüfer lesen ihn als solches. Mehr dazu unter Labels & Beschriftungen.

Und ein Fall, der oft falsch als Verstoß notiert wird: ein Icon-Knopf ganz ohne sichtbaren Text. Dort ist aria-label genau richtig – 2.5.3 greift nur, wenn eine sichtbare Textbeschriftung existiert. Für Icon-Knöpfe gilt stattdessen 4.1.2: Sie brauchen überhaupt einen Namen.

Häufige Fragen

Muss der zugängliche Name exakt dem sichtbaren Text entsprechen?

Nein, er muss ihn enthalten. Zusätzlicher Text ist erlaubt, solange die sichtbare Beschriftung als zusammenhängende Zeichenkette darin vorkommt. Der Normtext empfiehlt außerdem, dass sie am Anfang steht – manche Sprachsteuerungen gleichen nur den Anfang des Namens ab.

Ist ein Knopf in Großbuchstaben ein Verstoß, wenn im Code Kleinschreibung steht?

Nein. Wenn die Versalien per CSS mit text-transform: uppercase entstehen, bleibt der Textinhalt im Markup unverändert, und Groß- und Kleinschreibung darf ohnehin abweichen. Dasselbe gilt für Satzzeichen. Anders sieht es aus, wenn der sichtbare Text tatsächlich abweichend formuliert ist.

Gilt 2.5.3 auch für Icon-Buttons ohne Text?

Nein. Das Kriterium greift nur, wenn ein Bedienelement eine sichtbare Textbeschriftung hat. Ein Knopf mit reinem Symbol hat keine, also ist 2.5.3 dort nicht anwendbar. Er braucht trotzdem einen zugänglichen Namen – das verlangt 4.1.2 Name, Rolle, Wert.

Zählt der Platzhaltertext als sichtbare Beschriftung?

Formal ist ein Platzhalter kein Label, und er verschwindet beim Tippen. In der Praxis lesen Nutzer ihn als Beschriftung und sprechen ihn entsprechend an. Der saubere Weg ist ein echtes <label>; wenn ein Platzhalter der einzige sichtbare Text ist, sollte der zugängliche Name ihn zumindest enthalten.

Was ist mit Bedienelementen in einer Tabelle, die sich aus mehreren Angaben erklären?

Dort ist der Prüfschritt nicht anwendbar. Wenn sich die Beschriftung eines Kontrollkästchens erst aus Zeilen- und Spaltenüberschrift ergibt, gibt es keine einzelne sichtbare Beschriftung, die im Namen vorkommen müsste. Geprüft wird dann die programmatische Zuordnung nach 1.3.1 Info und Beziehungen.

Verwandte Themen

• Sprachsteuerung – die Nutzerperspektive dahinter
• 4.1.2 Name, Rolle, Wert – woher der zugängliche Name kommt
• 2.4.4 Linkzweck im Kontext – warum „Mehr erfahren“ ergänzt wird
• Die erste Regel von ARIA – weniger ARIA, weniger Probleme
• Labels & Beschriftungen – Beschriftungen, die halten