Beschriftung im Namen: Warum sichtbares Label und zugänglicher Name zusammengehören

Label und Name: zwei Dinge, ein Steuerelement

Auf dem Bildschirm siehst du bei einem Button das Wort „Senden". Das ist das sichtbare Label. Daneben trägt derselbe Button einen zugänglichen Namen(englisch accessible name ), den Hilfstechnologien auslesen. In den meisten Fällen sind beide gleich, sie müssen es aber nicht sein, und genau da entsteht das Problem.

Wer eine Spracherkennung nutzt, navigiert über das, was sichtbar ist. Der Befehl lautet „Klick Senden". Die Software vergleicht das gesprochene Wort mit dem zugänglichen Namen des Buttons. Stimmt der Name nicht mit dem sichtbaren Label überein, schlägt der Befehl fehl, obwohl die Person genau das gesagt hat, was auf dem Button steht. Auch Screenreader-Nutzer:innen profitieren: Was sie hören, sollte zu dem passen, was daneben sitzende Sehende vorlesen.

Was das Kriterium verlangt

Der Wortlaut ist kompakt: Bei Steuerelementen mit einer Beschriftung, die Text oder Bilder von Text enthält, muss der Name den visuell dargestellten Text enthalten. „Enthalten" heißt: Der sichtbare Text muss im zugänglichen Namen vorkommen, am besten wortgleich und in derselben Reihenfolge. Als beste Praxis empfiehlt das W3C, dass der zugängliche Name mit dem sichtbaren Label beginnt.

Ein Sonderfall ist wichtig: Fehlt einem Steuerelement der zugängliche Name komplett, obwohl ein sichtbares Textlabel da ist, verstößt es gleichzeitig gegen 2.5.3 und gegen 4.1.2 „Name, Rolle, Wert". Ohne Namen gibt es nichts, das den sichtbaren Text enthalten könnte.

Wie der zugängliche Name entsteht

Der zugängliche Name wird nicht willkürlich gewählt, sondern nach der Accessible Name and Description Computation berechnet, einer eigenen W3C-Spezifikation. Sie legt fest, welche Quellen in welcher Reihenfolge zählen. Sobald eine höher priorisierte Quelle einen Namen liefert, werden die darunterliegenden ignoriert. Das ist der Grund, warum ein aria-label ein sichtbares Label verdecken kann.

Ein Detail mit großer Wirkung: aria-describedby fließt nicht in den Namen ein, sondern in die Beschreibung. Kontext wie Hilfetexte, Überschriften oder Gruppen-Beschriftungen gehören also in die Beschreibung, nicht in den Namen. So bekommen Screenreader-Nutzer:innen die Zusatzinfo, ohne dass der Name für Sprachnutzer:innen unbrauchbar wird.

Die häufigste Falle: aria-label

Der mit Abstand häufigste Verstoß, dokumentiert als Fehler F96, entsteht aus guter Absicht: Ein Team will den Namen „aussagekräftiger" machen und hängt ein aria-label an, das vom sichtbaren Text abweicht. Damit ist das sichtbare Label für die Sprachsteuerung verschwunden.

 <!-- ✕ Verstoß (F96): Name enthält das Label „Senden" nicht --> 
<button aria-label="Formular absenden">Senden</button> <!-- ✓ Ideal: kein aria-label nötig, Text ist der Name --> 
<button>Senden</button> <!-- ✓ Erlaubt: Name beginnt mit dem sichtbaren Label --> 
<button aria-label="Senden und zur Übersicht">Senden</button>

Die offiziellen ausreichenden Techniken des W3C heißen G208(den Text des sichtbaren Labels in den Namen aufnehmen) und G211(den Namen an das sichtbare Label angleichen). Beide laufen auf dieselbe Faustregel hinaus: Wenn ein sichtbares Label existiert, lass den nativen Mechanismus arbeiten und übersteuere ihn nur dann mit ARIA, wenn du den sichtbaren Text vollständig übernimmst.

Sonderfälle: Symbole, Satzzeichen, Klammern

Nicht jeder sichtbare Buchstabe ist ein Label im Sinn dieses Kriteriums. Entscheidend ist, ob der Text etwas in menschlicher Sprache ausdrückt. Die wichtigsten Sonderfälle:

Ein Mythos

Auf einen Blick

So prüfst du ein Steuerelement schnell gegen 2.5.3:

Den Namen liest du am einfachsten mit dem Accessibility-Inspector des Browsers oder eines Screenreaders aus. Den genauen Berechnungsweg beschreibt die Accessible-Name-Spezifikation des W3C.