2.5.3 Label in Name

1. Was ist das Ziel dieses Kriteriums?

Stell dir vor, du willst per Sprachbefehl einen "Absenden"-Button aktivieren – aber der Computer reagiert nicht, obwohl du das Wort deutlich auf dem Bildschirm siehst. Frustrierend, oder? Genau diese Situation erleben täglich Menschen, die Sprachsteuerung nutzen, wenn sichtbare Labels nicht mit den programmatischen Namen übereinstimmen.

Das Ziel von Erfolgskriterium 2.5.3 der WCAG ist daher eindeutig: Was Nutzer sehen, soll auch das sein, was die Technologie versteht. Konkret bedeutet das: Der sichtbare Text eines Bedienelements muss auch in dessen zugänglichem Namen enthalten sein.

2. Was fordert das Erfolgskriterium genau?

Ganz konkret geht es um alle Benutzeroberflächen-Komponenten mit Labels, die Text oder Textbilder enthalten:

Der zugängliche Name muss den visuell dargestellten Text enthalten. Das bedeutet nicht, dass beide identisch sein müssen – aber der sichtbare Text sollte im programmatischen Namen vorkommen.

Best Practice: Der sichtbare Text steht am Anfang des zugänglichen Namens. Wenn du einen Button "Kaufen" siehst, sollte der zugängliche Name "Kaufen" oder "Kaufen: Produkt XY für 29,99 €" lauten – aber nicht "Produkt XY kaufen".

Ausnahmen: Das Kriterium gilt nur für Komponenten, die tatsächlich sichtbare Textlabels haben. Reine Icon-Buttons ohne Beschriftung fallen nicht darunter.

Ein praktisches Beispiel: Ein "Anmelden"-Button ist für sichtbare Nutzer klar beschriftet. Nutzer von Sprachsteuerung sagen "Anmelden" – und erwarten, dass genau dieser Button aktiviert wird. Steht im Code aber aria-label="Einloggen", funktioniert der Sprachbefehl nicht.

3. Warum ist das wichtig für Barrierefreiheit?

Stell dir vor, du versuchst, per Sprache durch eine Website zu navigieren, aber die Hälfte der sichtbaren Buttons reagiert nicht auf deine Befehle. Oder du nutzt einen Screenreader und hörst völlig andere Bezeichnungen als die, die du auf dem Bildschirm siehst.

Label in Name schafft Barrierefreiheit, weil es:

Sprachsteuerungs-Nutzern ermöglicht, Elemente durch das zu aktivieren, was sie sehen – ein "Senden"-Button wird durch "Senden" aktiviert, nicht durch einen versteckten Code.

Screenreader-Nutzern hilft, die gleichzeitig sehen können – sie hören das, was sie auch visuell wahrnehmen, was die Navigation deutlich intuitiver macht.

Menschen mit kognitiven Einschränkungen entlastet, da sie sich nicht merken müssen, dass sie andere Befehle sprechen sollen als das, was sie lesen.

Konsistenz schafft zwischen verschiedenen Eingabemethoden – egal ob Maus, Tastatur, Sprache oder Touch.

Und: Es macht die Nutzung für alle vorhersagbarer und weniger verwirrend, auch für Menschen ohne Einschränkungen, die gelegentlich Sprachsteuerung nutzen.

4. So setzt du das Kriterium erfolgreich um

Die gute Nachricht: In den meisten Fällen passiert die richtige Umsetzung automatisch, wenn du semantisch korrekt entwickelst. Hier die wichtigsten Praxis-Tipps:

Semantische HTML-Elemente nutzen:

  • <button>Absenden</button> funktioniert automatisch richtig
  • <label for="name">Name:</label> <input id="name"> erstellt die korrekte Verbindung
  • <a href="/home">Startseite</a> braucht keine zusätzlichen Attribute

Bei custom Elements vorsichtig sein:

  • Wenn du aria-label verwendest, sorge dafür, dass es den sichtbaren Text enthält
  • Nutze aria-labelledby, um auf sichtbare Labels zu verweisen
  • Vermeide aria-label, wenn bereits ein sichtbares Label existiert

Die Reihenfolge beachten:

  • Sichtbarer Text sollte am Anfang des zugänglichen Namens stehen
  • "Kaufen: iPhone 15 Pro" ist besser als "iPhone 15 Pro kaufen", wenn der Button "Kaufen" zeigt

Testing-Tools:

  • Browser-Entwicklertools zeigen den computed accessible name an
  • Screenreader-Software zum Testen verwenden (NVDA ist kostenlos)
  • Sprachsteuerungs-Software wie Windows Spracherkennung oder Voice Control (macOS/iOS) testen

Häufige Fallstricke vermeiden:

  • Placeholder-Text ist kein Label-Ersatz
  • Bilder mit Text brauchen passenden Alt-Text
  • Icon-Buttons ohne sichtbare Labels richtig beschriften

5. Warum dieses Erfolgskriterium für Unternehmen relevant ist

Auch bei Erfolgskriterium 2.5.3 gilt: Barrierefreiheit ist kein Selbstzweck – sondern bringt handfeste Vorteile für dein Business.

1. Zielgruppe erweitern

Sprachsteuerung ist längst nicht mehr nur ein Hilfsmittel für Menschen mit Behinderungen. Millionen nutzen sie am Smartphone, Smart Speaker oder am Computer – für Multitasking, in lauten Umgebungen oder einfach aus Bequemlichkeit. Mit konsistenten Labels machst du deine Website für alle diese Nutzergruppen problemlos bedienbar.

2. Voice-First-Zeitalter vorbereiten

Sprachgesteuerte Interfaces werden immer wichtiger. Websites, die heute schon sprachfreundlich sind, haben einen klaren Vorsprung gegenüber der Konkurrenz. Konsistente Labels sind die Grundlage für zukünftige Voice-Commerce und sprachbasierte Interaktionen.

3. Usability generell verbessern

Wenn sichtbare und programmatische Labels übereinstimmen, funktionieren auch automatisierte Tests besser, die Übersetzung wird präziser und die Qualitätssicherung wird einfacher. Konsistente Beschriftungen reduzieren Verwirrung und Support-Anfragen.

Und nicht zuletzt: Rechtssicherheit und Fördermöglichkeiten. Viele öffentliche Projekte fordern digitale Barrierefreiheit bereits verpflichtend – wer vorbereitet ist, hat klare Vorteile bei Ausschreibungen und Förderanträgen.

6. Das Erfolgskriterium im Wortlaut der W3

Success Criterion 2.5.3 Label in Name (Level A)

For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

Note: A best practice is to have the text of the label at the start of the name.

← Zurück zur WCAG-Übersicht