Ein Entwicklerleitfaden zu ARIA-Labels, die wirklich helfen

ARIA-Labels sind für Namen da, nicht für Entschuldigungen

ARIA ist nützlich, wird aber oft als Reparatur für unklaren HTML-Code verwendet. Genau dort geraten Teams in Schwierigkeiten.

Das häufigste Beispiel ist aria-label. Es wirkt harmlos: eine Zeichenkette hinzufügen, einen Linter zufriedenstellen, weitermachen. Aber ein barrierefreier Name ist keine Dekoration. Es ist der Name, den viele assistive Technologien Nutzerinnen und Nutzern ausgeben, wenn sie über Buttons, Links, Formularfelder, Überschriften, Orientierungspunkte und Bedienelemente navigieren.

Wenn dieser Name vage, doppelt, veraltet oder anders als das sichtbare Label ist, wird die Oberfläche schwieriger zu bedienen. Manchmal sogar schlimmer: aria-label kann besseren Text überschreiben, der bereits im DOM vorhanden war.

Das Ziel ist nicht, mehr ARIA hinzuzufügen. Das Ziel ist, Name, Rolle, Zustand und Zweck jedes Oberflächenelements klar zu machen.

Der barrierefreie Name, einfach erklärt

Die meisten interaktiven Elemente haben einen barrierefreien Namen. Screenreader verwenden diesen Namen, um anzusagen, was das Element ist.

Zum Beispiel:

<button>Save changes</button>

Ein Screenreader kann etwa ansagen: „Save changes, button.“ Die Rolle kommt vom nativen button-Element. Der Name kommt aus dem Text darin.

Das ist der Idealfall: Sichtbarer Text und barrierefreier Name stimmen überein.

ARIA-Labeling-Attribute werden nützlich, wenn die sichtbare Oberfläche keinen vollständigen Namen bereitstellt oder wenn der Name von einem anderen Element kommen muss. Die wichtigsten Attribute sind:

• aria-label: stellt eine Zeichenkette direkt auf dem Element bereit.
• aria-labelledby: verweist auf ein oder mehrere Elemente, deren Text zum Namen wird.
• aria-describedby: verweist auf unterstützenden Beschreibungstext, nicht auf den Hauptnamen.

Diese drei hängen zusammen, sind aber nicht austauschbar.

Erste Regel: Native HTML-Elemente und sichtbare Labels bevorzugen

Wenn Sie sichtbaren Text auf dem Bedienelement platzieren können, tun Sie das zuerst.

Das ist besser:

<button>Delete invoice</button>

Als das hier:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Das zweite Muster ist für einen reinen Icon-Button gültig. Wenn das Design aber sichtbaren Text zulässt, hilft sichtbarer Text allen: Screenreader-Nutzenden, Nutzerinnen und Nutzern von Spracherkennung, Menschen mit kognitiver Belastung, Menschen, die schnell scannen, und Menschen, die Übersetzungswerkzeuge verwenden.

Das ist ein wiederkehrendes Thema in der Barrierefreiheitsarbeit. Native HTML-Elemente und sichtbare Hinweise lösen mehr Probleme als versteckte Metadaten. Dasselbe Prinzip gilt allgemeiner für Button-Semantik; wenn Ihr Team UI-Bedienelemente prüft, ist unsere Checkliste für barrierefreie Web-Buttons eine gute Ergänzung zu diesem Leitfaden.

Wann aria-label das richtige Werkzeug ist

Verwenden Sie aria-label, wenn ein Element einen barrierefreien Namen braucht und es keinen geeigneten sichtbaren Text gibt, auf den verwiesen werden kann.

Der klassische Fall ist ein reiner Icon-Button:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Das ist sinnvoll. Das sichtbare Icon deutet Suche an, aber der SVG-Pfad selbst liefert keinen verlässlichen Namen. aria-label stellt einen bereit.

Weitere gute Fälle sind:

• Ein Schließen-Button, der nur durch ein „X“ dargestellt wird.
• Ein Navigations-Landmark, der einen spezifischeren Namen braucht, etwa aria-label="Product".
• Ein wiederholtes Bedienelement, bei dem der sichtbare Kontext nicht Teil des Button-Texts ist.

Zum Beispiel:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Beide sind Navigations-Landmarks, aber ihre Labels helfen Nutzenden, sie bei der Navigation über Landmarks zu unterscheiden.

Wann aria-label das falsche Werkzeug ist

Fügen Sie aria-label nicht nur hinzu, weil ein Test sagt, dass ein Element ein Label braucht. Korrigieren Sie zuerst das Markup.

Schlecht:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Besser:

<button>Submit</button>

Das erste Beispiel erzeugt unnötige Arbeit. Sie müssen nun Tastaturverhalten, deaktivierte Zustände, Formularverhalten und Erwartungen nachbauen, die native Buttons bereits mitbringen.

Vermeiden Sie außerdem, aria-label zu verwenden, um sichtbaren Text so umzubenennen, dass sich die Bedeutung ändert.

<button aria-label="Delete invoice">Remove</button>

Das wirkt geringfügig, kann aber Nutzerinnen und Nutzer verwirren, die auf Spracheingabe angewiesen sind. Wenn ein sichtbarer Button „Remove“ sagt, sein barrierefreier Name aber „Delete invoice“ ist, erhält eine Person, die „click Remove“ sagen möchte, möglicherweise nicht das erwartete Ergebnis. Die WCAG-Anforderung „Label in Name“ existiert genau aus diesem Grund: Sichtbarer Text sollte im Allgemeinen im barrierefreien Namen enthalten sein.

Eine bessere Version:

<button aria-label="Remove invoice">Remove</button>

Oft noch besser:

<button>Remove invoice</button>

Greifen Sie zu aria-labelledby, wenn sichtbarer Text bereits vorhanden ist

Wenn der Label-Text bereits auf der Seite steht, ist aria-labelledby meist besser als aria-label.

Beispiel:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Der barrierefreie Name des Abschnitts kommt nun aus der sichtbaren Überschrift. Sie vermeiden doppelte Zeichenketten, was Übersetzungsfehler und veraltete Labels reduziert.

Das ist besonders nützlich für Formulargruppen:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

In vielen Fällen reicht das native legend ohne ARIA aus. Der Punkt ist: Sichtbare Labels sollten führen. ARIA sollte vorhandene Bedeutung verbinden, nicht eine zweite private Version davon erstellen.

Verwenden Sie aria-describedby für Hilfetext, nicht für den Namen

Eine Beschreibung ist kein Label.

Betrachten Sie dieses Feld:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Der barrierefreie Name ist „Password“. Die Beschreibung ist „Use at least 12 characters.“ Ein Screenreader kann beides ansagen, aber beide erfüllen unterschiedliche Zwecke.

Tun Sie nicht Folgendes:

<input type="password" aria-label="Use at least 12 characters">

Das benennt das Feld nach der Anweisung, nicht nach dem Konzept. Wer durch ein Formular navigiert, möchte zuerst wissen, was das Feld ist, und danach, welche Einschränkungen gelten.

Diese Unterscheidung ist auch bei Fehlerzuständen wichtig:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Das Label bleibt stabil. Die Fehlermeldung wird unterstützender Kontext.

Wiederholte Bedienelemente brauchen eindeutige Namen

Listen und Cards sind Bereiche, in denen ARIA-Labels oft notwendig werden.

Schlecht:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Eine Screenreader-Nutzerin oder ein Screenreader-Nutzer, der über Buttons navigiert, hört möglicherweise dreimal „Delete, button“ ohne Kontext.

Gut:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Das ist eine legitime Verwendung von aria-label: Der sichtbare Text bleibt knapp, während der barrierefreie Name das Objekt einschließt.

Verwenden Sie dieses Muster aber sorgfältig. Wenn der Objektname in der Nähe sichtbar ist, ist aria-labelledby möglicherweise wartbarer:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Der barrierefreie Name wird zu „Delete Q4 revenue“. So wird vermieden, den Berichtstitel in einem Attribut zu duplizieren.

Nicht alles labeln

Nicht jedes Element braucht ein ARIA-Label.

Statischer Text normalerweise nicht. Dekorative Icons nicht. Container nicht, sofern sie keine sinnvolle Landmark- oder Widget-Rolle haben. Übermäßiges Labeling kann eine Seite laut und schwieriger navigierbar machen.

Für Bilder verwenden Sie das bildspezifische Modell: Bedeutungsvolle Bilder brauchen nützliches alt; dekorative Bilder brauchen leeres alt="". Verwenden Sie ARIA-Labels nicht als Ersatz für guten Bildtext. Wenn Ihr Team diese Konzepte vermischt, lesen Sie pragmatischen Alt-Text für Bilder erneut und trennen Sie Bildalternativen von Namen für Bedienelemente.

Ein häufiger Fehler ist, jedem SVG ein aria-label zu geben. Wenn das SVG in einem Button liegt und der Button bereits einen Namen hat, sollte das Icon für assistive Technologien normalerweise verborgen werden:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Andernfalls hört die Nutzerin oder der Nutzer je nach Kombination aus Browser und assistiver Technologie möglicherweise redundante oder seltsame Ansagen.

Prüfen Sie den berechneten Namen, nicht nur den Code

Barrierefreiheitsfehler überstehen Code-Reviews oft, weil das Markup plausibel aussieht.

Moderne Browser-Entwicklertools können den berechneten Accessibility Tree anzeigen. In Chrome, Edge, Firefox und Safari inspizieren Sie das Element und suchen nach Barrierefreiheitsinformationen wie Rolle, Name und Beschreibung. Sie prüfen drei Dinge:

1. Ist die Rolle das, was Sie erwarten?
2. Ist der barrierefreie Name klar und spezifisch?
3. Ist die Beschreibung hilfreich, ohne den Namen zu ersetzen?

Testen Sie dann einige Abläufe mit einem echten Screenreader. Sie müssen keine Vollzeit-Fachperson für assistive Technologien werden, um die Grundlagen zu erkennen. Auf macOS ist VoiceOver integriert. Unter Windows ist NVDA weit verbreitet und kostenlos. Auf Mobilgeräten testen Sie, wo relevant, mit VoiceOver auf iOS und TalkBack auf Android.

Automatisierte Werkzeuge sind nützlich, können aber nicht verlässlich beurteilen, ob „Open“, „Read more“ oder „Delete“ ausreichend kontextbezogen ist. Behandeln Sie Automatisierung als Netz, nicht als Richter. Das ist ähnlich wie bei Performance-Audits: Ein Bericht kann Sie auf verdächtige Bereiche hinweisen, aber Sie müssen die Auswirkungen trotzdem interpretieren. Derselbe ruhige Ansatz, den wir für das Lesen eines Lighthouse-Berichts ohne Panik empfehlen, gilt auch hier.

Eine praktische Review-Checkliste

Bevor Sie ARIA-Labels ausliefern, fragen Sie:

• Könnte dies stattdessen natives HTML sein?
• Gibt es sichtbaren Text, der als Label verwendet werden sollte?
• Falls sichtbarer Text existiert: Enthält der barrierefreie Name ihn?
• Sind wiederholte Bedienelemente eindeutig, wenn außerhalb des visuellen Kontexts navigiert wird?
• Ist Hilfetext mit aria-describedby verbunden, statt ins Label gezwungen zu werden?
• Sind dekorative Icons vor assistiver Technologie verborgen?
• Hat jemand den berechneten barrierefreien Namen in den Browser-Entwicklertools geprüft?
• Wurde für den kritischen Ablauf mindestens ein Durchgang mit einem echten Screenreader durchgeführt?

Diese Checkliste fängt die meisten Label-Probleme ab, bevor sie zu Nutzerproblemen werden.

Die leise Disziplin guten ARIA-Einsatzes

Gute ARIA-Arbeit ist selten dramatisch. Sie besteht vor allem aus Zurückhaltung.

Verwenden Sie echte Buttons. Verwenden Sie echte Labels. Halten Sie sichtbare und barrierefreie Namen im Einklang. Fügen Sie aria-label nur hinzu, wenn es keine bessere sichtbare Quelle gibt. Verwenden Sie aria-labelledby, wenn die Seite bereits den richtigen Text enthält. Verwenden Sie aria-describedby für unterstützende Anweisungen und Fehler.

Die Webplattform gibt Entwicklerinnen und Entwicklern viel kostenlos mit, wenn wir sie direkt nutzen. ARIA ist für die Lücken da. Die Kompetenz besteht darin zu erkennen, wann es tatsächlich eine Lücke gibt.