Was ist der Accessible Name? - Der Name für assistierende Technologien

Stell Dir vor, Du kommst in einen Raum voller Schalter, aber keiner davon ist beschriftet. Du wüsstest nicht, welcher Schalter das Licht anmacht, welcher die Lüftung startet oder welcher den Alarm auslöst.

Ziemlich unpraktisch, oder?

Genau so fühlen sich Nutzer von assistierenden Technologien (AT), wie zum Beispiel Screenreadern, wenn interaktive Elemente auf einer Webseite keinen Namen haben. Der Accessible Name (auf Deutsch: barrierefreier Name) ist diese entscheidende Beschriftung für die digitale Welt. Er gibt einem Element eine Identität, die von Software programmatisch ausgelesen und Nutzern vermittelt werden kann.

Ohne ihn ist ein Button nur ein "Button" und ein Eingabefeld nur ein "Eingabefeld" – ohne jeden Kontext, was sie tun oder wofür sie da sind.

Was ist der Accessible Name?

Die offizielle Spezifikation "Accessible Name and Description Computation 1.1" des W3C definiert den Accessible Name wie folgt:

The accessible name is the programmatic name of a user interface element that is presented to an accessibility API. The accessible name is used by assistive technologies to identify and refer to an object. [1]

Übersetzt bedeutet das: Der Accessible Name ist der programmatische Name eines Elements der Benutzeroberfläche, der einer Accessibility API zur Verfügung gestellt wird. Der Accessible Name wird von assistierenden Technologien verwendet, um ein Objekt zu identifizieren und sich darauf zu beziehen.

Ausführliche Erklärung

Der Accessible Name ist ein zentrales Konzept der digitalen Barrierefreiheit. Er ist die textliche Repräsentation eines Elements, die an den Accessibility Tree (deutsch: Baum der Barrierefreiheit) übergeben wird. Dieser Baum ist eine spezielle, von Browsern erstellte Repräsentation der Webseite, die für assistierende Technologien optimiert ist. Ein Screenreader liest nicht direkt den HTML-Code (DOM), sondern interagiert mit diesem Accessibility Tree.

Der Browser berechnet den Accessible Name für jedes relevante Element nach einer festgelegten Prioritätenliste. Wenn Du als Entwickler die Mechanismen kennst, kannst Du gezielt steuern, wie Deine UI-Elemente von Screenreadern und anderen Tools wahrgenommen werden. Die Berechnung ist erstaunlich logisch und folgt einer Kaskade, die sicherstellt, dass die robusteste Methode Vorrang hat.

Das folgende Diagramm veranschaulicht diesen Entscheidungsprozess stark vereinfacht:

Vereinfachte Hierarchie der Accessible Name Berechnung

Textbeschreibung für das Schema "Vereinfachte Hierarchie der Accessible Name Berechnung"

Das Flussdiagramm beginnt mit der Feststellung, dass ein Element einen Namen benötigt. Der erste Prüfschritt ist, ob ein aria-labelledby-Attribut vorhanden ist. Wenn ja, wird der Inhalt der Elemente, auf die es verweist, als Accessible Name verwendet, und der Prozess endet. Wenn nein, wird geprüft, ob ein aria-label-Attribut existiert. Wenn ja, wird dessen Wert zum Accessible Name. Wenn nein, wird nach einer nativen HTML-Beschriftung gesucht, wie einem <label>-Element für ein Eingabefeld oder einem alt-Attribut für ein Bild. Ist eine solche vorhanden, wird ihr Inhalt zum Accessible Name. Wenn nicht, wird geprüft, ob das Element selbst Textinhalt hat, wie bei einem Button. Wenn ja, ist dieser Text der Accessible Name. Als letzte Möglichkeit wird geprüft, ob ein title-Attribut vorhanden ist. Wenn ja, wird dessen Wert als Fallback genutzt. Wenn keine dieser Bedingungen erfüllt ist, hat das Element keinen Accessible Name, was ein Barrierefreiheitsproblem darstellt.

Wichtig ist zu verstehen, dass diese Kaskade bei der ersten erfolgreichen Methode abbricht. Ein aria-label überschreibt also immer den Textinhalt eines Buttons. Das kann nützlich sein, ist aber auch eine häufige Fehlerquelle.

Wofür wird es eingesetzt?

Der Accessible Name ist für praktisch jedes interaktive oder bedeutungstragende Element auf einer Webseite unerlässlich. Seine Hauptaufgaben sind:

• Identifikation von Steuerelementen: Buttons, Links, Eingabefelder, Checkboxen, Radio-Buttons und andere Formularelemente benötigen einen klaren Namen, damit Nutzer wissen, welche Aktion sie auslösen oder welche Information erwartet wird.
• Beschreibung von Bildern: Bei Bildern, die Informationen vermitteln, dient der alt-Text als Accessible Name. Er beschreibt, was auf dem Bild zu sehen ist, und ermöglicht blinden Nutzern, den visuellen Inhalt zu verstehen.
• Kontext für Regionen und Landmarks: ARIA-Landmarks wie <nav>, <main> oder <aside> können ebenfalls einen Accessible Name erhalten (z.B. via aria-label="Hauptnavigation"), um Nutzern zu helfen, sich auf der Seite zu orientieren, besonders wenn mehrere gleiche Landmarks vorhanden sind.
• Erfüllung von WCAG-Kriterien: Ein korrekter Accessible Name ist eine Grundvoraussetzung, um zahlreiche Erfolgskriterien der Web Content Accessibility Guidelines (WCAG) zu erfüllen, insbesondere unter den Prinzipien "Wahrnehmbar" und "Bedienbar".

Beispiele aus der Praxis

Hier sind einige typische Beispiele, die den Unterschied zwischen einem Element mit und ohne Accessible Name verdeutlichen.

Gutes Beispiel

Button mit sichtbarem Text und Icon

<!--
  Gutes Beispiel: Der Text "Profil löschen" ist direkt im Button enthalten.
  Er dient als robuster, sichtbarer und barrierefreier Name.
-->
<button type="button">
  <svg aria-hidden="true" focusable="false" ...>
    <!-- ... Icon-Pfad ... -->
  </svg>
  Profil löschen
</button>

Icon-Button mit aria-label

<!--
  Gutes Beispiel: Der Button hat keinen sichtbaren Text.
  `aria-label` gibt ihm einen klaren Accessible Name für Screenreader.
-->
<button type="button" aria-label="Einstellungen öffnen">
  <svg aria-hidden="true" focusable="false" ...>
    <!-- ... Zahnrad-Icon ... -->
  </svg>
</button>

Eingabefeld mit nativem Label

<!--
  Gutes Beispiel: Das <label> ist via `for`-Attribut fest mit dem <input> verbunden.
  Das ist die beste Methode für Formularfelder.
-->
<label for="username">Benutzername</label>
<input type="text" id="username" name="username" />

Schlechtes Beispiel

Button nur mit Icon ohne Namen

<!--
  Schlechtes Beispiel: Dieser Button hat weder Textinhalt noch ein ARIA-Label.
  Ein Screenreader würde nur "Button" ansagen – die Funktion ist unklar.
-->
<button type="button">
  <svg aria-hidden="true" focusable="false" ...>
    <!-- ... Zahnrad-Icon ... -->
  </svg>
</button>

Eingabefeld nur mit Platzhalter

<!--
  Schlechtes Beispiel: Der `placeholder` ist kein Ersatz für ein <label>.
  Er verschwindet bei der Eingabe und wird von manchen Browser/AT-Kombinationen
  nicht zuverlässig als Accessible Name verwendet.
-->
<input type="text" name="username" placeholder="Benutzername" />

Link um ein Bild ohne Alt-Text

<!--
  Schlechtes Beispiel: Der Link umschließt ein Bild ohne alt-Attribut.
  Screenreader könnten den Dateinamen des Bildes vorlesen ("logo.png")
  oder nur "Link", was nicht hilfreich ist.
-->
<a href="/startseite">
  <img src="/logo.png" />
</a>

Best Practices & Empfehlungen

Um sicherzustellen, dass Deine Elemente immer einen korrekten und nützlichen Accessible Name haben, solltest Du einige Grundregeln beachten.

Nutze immer sichtbare Beschriftungen, wenn möglich

Die beste Beschriftung ist die, die alle Nutzer sehen können [2]. Verwende den Textinhalt eines Buttons oder Links direkt als dessen Namen. Für Formularfelder ist das <label>-Element, das mit dem for-Attribut mit der id des Feldes verknüpft ist, die robusteste und bevorzugte Methode.

aria-label nur als letzte Rettung für unsichtbare Labels

Wenn ein Design partout kein sichtbares Label vorsieht (z.B. bei einem Icon-Button), ist aria-label eine gute Lösung. Aber Vorsicht: Der Inhalt von aria-label ist nur für Nutzer von assistierenden Technologien sichtbar und überschreibt jeden anderen textlichen Inhalt des Elements.

warnung

aria-label wird nicht automatisch von Browser-Übersetzungsdiensten übersetzt. Das kann zu Problemen für internationale Nutzer führen. Eine sichtbare Beschriftung, die per CSS versteckt wird (z.B. mit einer sr-only-Klasse), ist oft die bessere Alternative.

aria-labelledby für komplexe Beschriftungen

Manchmal setzt sich der Name eines Elements aus bereits vorhandenem Text auf der Seite zusammen. Anstatt den Text in einem aria-label zu duplizieren, kannst Du mit aria-labelledby auf die IDs der entsprechenden Textelemente verweisen. Der Browser fügt deren Inhalte dann zum Accessible Name zusammen.

Beispiel: Ein 'Mehr lesen'-Link, der sich auf eine Überschrift bezieht.

<h2 id="article-title">Spannender Artikel über Barrierefreiheit</h2>
<p>Eine kurze Einleitung zum Artikel...</p>
<a href="..." aria-labelledby="read-more-link article-title">
  <span id="read-more-link">Mehr lesen</span>
</a>

Der Accessible Name wäre hier: "Mehr lesen Spannender Artikel über Barrierefreiheit".

Sichtbares Label muss im Accessible Name enthalten sein

Nutzer von Spracherkennungssoftware navigieren, indem sie sagen, was sie sehen. Wenn ein Button sichtbar mit "Senden" beschriftet ist, muss der Accessible Name das Wort "Senden" enthalten [3]. Ein Nutzer sagt "Klicke Senden", aber wenn der Accessible Name "Formular abschicken" ist, wird der Befehl fehlschlagen.

Häufige Missverständnisse

"Das title-Attribut ist ein guter Accessible Name"

Das ist ein weit verbreiteter Irrglaube. Das title-Attribut ist in der Kaskade der Namensberechnung die allerletzte und unzuverlässigste Option. Die Unterstützung durch Browser und Screenreader ist inkonsistent. Oft wird es ignoriert oder nur unter bestimmten Bedingungen (z.B. nach einer Pause) vorgelesen. Verlasse Dich niemals auf das title-Attribut, um wichtige Informationen zu vermitteln. Es ist primär für einen Tooltip bei Maus-Hover gedacht und keine verlässliche barrierefreie Beschriftung.

"placeholder ist ein gutes Label für ein Eingabefeld"

Ein placeholder ist eine Eingabehilfe oder ein Beispielformat, kein Label. Er verschwindet, sobald der Nutzer zu tippen beginnt, und steht dann nicht mehr als Kontext zur Verfügung. Ältere Screenreader lesen Platzhalter oft nicht vor, und sie haben in der Regel einen zu geringen Farbkontrast, um als Label zu gelten. Jedes Eingabefeld braucht ein richtiges, persistentes <label>.

Verwandte Begriffe

• Accessible Description
• ARIA (Accessible Rich Internet Applications)
• Accessibility Tree
• Screenreader
• WCAG (Web Content Accessibility Guidelines)
• Name, Role, Value

Häufig gestellte Fragen

Was ist der Unterschied zwischen Accessible Name und Accessible Description?

Der Accessible Name ist die kurze, prägnante Bezeichnung eines Elements (wie der Text auf einem Button). Die Accessible Description (barrierefreie Beschreibung) liefert zusätzliche, aber nicht-essentielle Informationen. Sie wird typischerweise nach dem Namen und der Rolle vorgelesen, oft mit einer kurzen Pause. Ein Beispiel: Ein Link mit dem Accessible Name "Hilfe-Center" könnte die Accessible Description "Öffnet das Hilfe-Center in einem neuen Tab" haben.

Wann sollte ich aria-label statt <label> verwenden?

Die Faustregel lautet: Nutze <label> immer, wenn es möglich ist, insbesondere bei Standard-Formularelementen. aria-label ist für Fälle gedacht, in denen ein sichtbares Label aus Designgründen nicht vorhanden ist (z.B. Icon-Buttons) oder wenn native HTML-Mechanismen nicht ausreichen.

Kann ein Bild einen Accessible Name haben?

Ja, absolut. Für ein <img>-Element ist der Inhalt des alt-Attributs der Accessible Name. Wenn ein Bild rein dekorativ ist, sollte das alt-Attribut leer gelassen werden (alt=""), damit es von Screenreadern ignoriert wird.

Warum ist WCAG 2.5.3 "Label in Name" so wichtig?

Dieses Erfolgskriterium ist entscheidend für Nutzer von Spracherkennungssoftware. Sie interagieren mit der Seite, indem sie die sichtbaren Beschriftungen aussprechen (z.B. "Klicke auf 'Jetzt kaufen'"). Wenn der Accessible Name des Buttons "In den Warenkorb legen" lautet, aber der sichtbare Text "Jetzt kaufen" ist, kann die Software den Befehl nicht zuordnen. Der sichtbare Text muss also Teil des Accessible Name sein.

Wie kann ich den Accessible Name eines Elements testen?

Die einfachste Methode ist die Verwendung der Entwicklertools Deines Browsers. In Chrome, Edge und Firefox gibt es einen "Accessibility"-Tab. Wenn Du dort ein Element auswählst, zeigt Dir der Browser den berechneten Accessible Name im Accessibility Tree an. Alternativ kannst Du natürlich einen Screenreader wie NVDA (Windows), VoiceOver (macOS) oder TalkBack (Android) verwenden, um die Seite zu testen und zu hören, wie die Elemente angesagt werden.

Hinweis

Dieser Artikel dient der Wissensvermittlung und stellt keine Rechtsberatung dar. Bei der Umsetzung von Barrierefreiheit sind stets die spezifischen gesetzlichen Anforderungen des jeweiligen Landes oder der jeweiligen Region zu berücksichtigen.

1. „Accessible Name and Description Computation 1.2“. W3C, Oktober 2025. Zugegriffen: 6. November 2025. [Online]. Verfügbar unter: https://www.w3.org/TR/accname-1.2/ ⤴
2. W3C, „H44: Using label elements to associate text labels with form controls“, 2023, [Online]. Verfügbar unter: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
3. W3C, „Success Criterion 2.5.3 Label in Name“, 2023, [Online]. Verfügbar unter: https://www.w3.org/TR/WCAG22/#label-in-name ⤴