Wird geladen...

aria-label in HTML: So nutzen Sie es richtig

Ein Warenkorb-Icon ohne Erklärung bleibt für Screenreader-Nutzende unsichtbar. Mit dem richtigen aria-label wird daraus ein klar verständlicher Button. Erfahren Sie, wie Sie aria-label in HTML sinnvoll einsetzen – für barrierefreie, rechtskonforme und nutzerfreundliche Webseiten.

aria label in weißer Box, darunter Tastatur und links Überschrift

aria-label in HTML: So nutzen Sie es richtig

Stellen Sie sich vor, Sie besuchen einen Onlineshop und sehen nur ein Warenkorb-Icon. Sehende Nutzende verstehen sofort die Bestellfunktion. Für Nutzende, die auf Bildschirmlesegeräte angewiesen ist, bleibt die Schaltfläche jedoch unverständlich. Erst durch ein aria-label  wie „In den Warenkorb legen“ wird sie klar beschrieben und barrierefrei nutzbar.

Digitale Barrierefreiheit beginnt im Code. Semantisches HTML bildet die Grundlage, aria-label ergänzt nur dort, wo Standard-Elemente nicht ausreichen. Davon profitieren nicht nur Institutionen, sondern auch Unternehmen – besonders Onlineshops, in denen eindeutige Buttons und Formularfelder den reibungslosen Bestellprozess sichern.

Was ist ein aria-label?

Das aria-label-Attribut ist Teil der ARIA-Spezifikation (Accessible Rich Internet Applications) des W3C (World Wide Web Consortium). Das W3C ist das internationale Gremium, das offene Standards für das Web entwickelt, darunter auch die Richtlinien für Barrierefreiheit (WCAG).

aria-label fügt HTML-Elementen unsichtbare Beschriftungen hinzu, die Screenreader auslesen, wenn sichtbare Labels fehlen oder unklar sind. So schließt es die Lücke zwischen Design und technischer Zugänglichkeit und macht Interfaces für alle verständlich.

Warum ARIA-Attribute wichtig sind

ARIA-Attribute wurden entwickelt, um Barrierefreiheit dort sicherzustellen, wo HTML an seine Grenzen stößt. Moderne Webseiten mit dynamischen Inhalten – etwa JavaScript-Elementen, Custom-Widgets oder komplexen visuellen Designs – bringen Herausforderungen mit sich. Hier sorgt ein ARIA-Attribut wie aria-label dafür, dass auch solche Benutzeroberflächen von Screenreadern korrekt interpretiert werden.

Unterschied zu sichtbaren Labels im UI

Ein wesentlicher Unterschied zwischen aria-label und sichtbaren Labels liegt in ihrer Zielgruppe: Während sichtbare Labels allen Nutzenden zur Verfügung stehen, richtet sich das aria-label ausschließlich an assistive Technologien.

Sichtbare Labels sind ganz normale Beschriftungen, die man in der Interface sieht – zum Beispiel der Text „E-Mail-Adresse“ über oder neben einem Eingabefeld:

<label for="email">Email address</label>  

<input type="email" id="email" name="email">

Alle Nutzenden erkennen sofort, was sie in das Feld eintragen sollen, und auch Screenreader lesen diesen Text vor. Wenn so ein sichtbarer Hinweis fehlt, kann ein aria-label genutzt werden. Es fügt unsichtbar eine Beschriftung hinzu, die nur Screenreader wahrnehmen:

<input type="email" id="email" name="email" aria-label="Email address">

Damit bleibt das Feld auch ohne sichtbare Beschriftung verständlich und barrierefrei nutzbar.

aria-label in der Mitte, .sr-only und aria-labelledby in den Ecken.

Wie funktioniert ein aria-label in HTML?

Screenreader ermitteln den zugänglichen Namen eines Elements in fester Reihenfolge:

  1. aria-labelledby– verweist auf sichtbaren Text im Code

  2. aria-label – unsichtbare Beschriftung

  3. sichtbares <label> – bei Formularfeldern

  4. Textinhalt – z. B. Button-Text

  5. title-Attribut – letzte Möglichkeit

Ein Such-Icon-Button wird ohne Zusatz nicht erkannt. Mit aria-label="Search" liest der Screenreader „Suche“ vor – eindeutig und nutzbar.

Beispiel:

Ein Button mit einem Lupen-Symbol für die Suche hat keinen sichtbaren Text. Ohne zusätzliche Angaben wäre er für Screenreader unverständlich. Wird jedoch ein aria-label="Search" ergänzt, liest der Screenreader „Suche“ vor und ignoriert alle anderen möglichen Quellen.

Beispiele für aria-label bei Buttons und Links

Ein typischer Einsatz von aria-label sind Buttons, die nur ein Icon enthalten. Für sehende Nutzende ist ein Lupensymbol sofort als Suchfunktion erkennbar, für Screenreader dagegen bleibt es ohne Bedeutung. Mit aria-label wird der Button auch für assistive Technologien verständlich:

<button aria-label="Start search">

   <svg aria-hidden="true" width="24" height="24">…</svg>

</button>

Ein weiteres Praxisbeispiel sind Listen. Viele Onlineshops nutzen Symbol-Listen, etwa für Kategorien mit Icons. Screenreader würden hier nur „Liste mit 5 Einträgen“ vorlesen. Mit aria-label="Product categories" wird sofort deutlich, welche Inhalte die Liste enthält.

Links wiederum sollten klar beschreiben, wohin sie führen. Ein rein allgemeiner Text wie „Mehr erfahren“ ist nicht barrierefrei, da er ohne Kontext unklar bleibt. Mit aria-label lässt sich das verbessern:

<a href="/artikel/barrierefreiheit"

aria-label="Artikel über digitale Barrierefreiheit lesen">

Artikel über digitale Barrierefreiheit lesen

</a>

aria-label für Formularelemente

Formulare sind ein zentraler Bestandteil fast jeder Website. Damit sie barrierefrei nutzbar sind, sollte jedes Formularfeld einen eindeutigen Namen haben. Normalerweise geschieht das über ein sichtbares <label>-Element:

<label for="email">E-Mail-Adresse</label>  

<input type="email" id="email" name="email">

Der Vorteil: Alle Nutzenden sehen das Label „E-Mail-Adresse“ und Screenreader lesen es zusätzlich vor. Außerdem können Nutzende auf das Label klicken, um das Feld automatisch zu fokussieren.

Manchmal wird aus gestalterischen Gründen kein sichtbares Label eingesetzt, zum Beispiel wenn nur ein Platzhalter (Placeholder) im Feld angezeigt wird. Für Menschen, die Bildschirmleseprogramme nutzen, ist das problematisch, da Platzhalter nicht als offizielles Label gewertet werden. Genau hier kann aria-label helfen:

<input type="email" 

       aria-label="E-Mail-Adresse" 

       placeholder="example@domain.com">

Für Sehende wirkt das Feld wie gewohnt, Screenreader-Nutzende hören jedoch „E-Mail-Adresse“. So bleibt das Feld auch ohne sichtbares Label verständlich.

Ein weiteres Beispiel sind Eingabefelder, die zusätzliche Hinweise benötigen – etwa bei Passwörtern. Hier reicht ein einfaches Label nicht aus. Mit aria-describedby lässt sich das Feld mit weiterführenden Informationen verknüpfen:

<input type="password" 

       aria-label="Passwort" 

       aria-describedby="pwd-hilfe">  

<div id="pwd-help">Mindestens 8 Zeichen, davon eine Zahl</div>

Screenreader lesen in diesem Fall zuerst „Passwort“ und danach die Ergänzung „Mindestens 8 Zeichen, davon eine Zahl“.

Wichtig: aria-label bei Formularen sollte eher die Ausnahme bleiben. Ein sichtbares <label> ist fast immer die bessere Lösung – es ist klar für alle erkennbar, erleichtert die Bedienung und erfordert weniger Zusatzlogik. Aria-label dient hier also vor allem als Rettungsanker, wenn Labels aus Design- oder Layoutgründen nicht sichtbar sind.

ARIA-Rollen und ihr Zusammenspiel mit Labels

ARIA-Rollen beschreiben die Funktion eines Elements, während aria-label dessen Namen definiert. Diese Kombination ist besonders bei Custom-Widgets wichtig, die über die Standard-Semantik von HTML hinausgehen:

<div role="button"

aria-label="Newsletter abonnieren" tabindex="0">

    <svg>...</svg>

    Anmelden

</div>

Für interaktive Widgets wie Menüs sind weitere relevante Attribute wichtig. aria-expanded zeigt an, ob ein Menü ausgeklappt ist, während aria-haspopup angibt, dass ein Element ein Popup oder Menü auslöst:

<button aria-label="Hauptmenü öffnen"

        aria-expanded="false" 

        aria-haspopup="true" 

        aria-controls="main-menu">

    ☰

</button>

<ul id="main-menu" role="menu" hidden>

    <li role="menuitem"><a href="#home">Startseite</a></li>

    <li role="menuitem"><a href="#about">Über uns</a></li>

</ul>

Jedoch gilt die erste ARIA-Regel: Verwenden Sie natives HTML, wann immer möglich. Ein echtes <button>-Element ist einem <div> mit role="button" immer vorzuziehen, da es bereits alle erforderlichen Funktionalitäten mitbringt.

Frau beim Online-Shopping am Laptop.

aria-label vs. Alt-Text

Ein häufiger Irrtum ist die Verwechslung von aria-label und alt-Text. Beide dienen der Barrierefreiheit, haben aber unterschiedliche Anwendungsbereiche:

Alt-Text ist speziell für Bilder gedacht und beschreibt den visuellen Inhalt eines Bildes. Er wird angezeigt, wenn das Bild nicht geladen werden kann, und von Screenreadern vorgelesen.

aria-label hingegen kann auf nahezu alle HTML-Elemente angewendet werden und gibt Screenreadern zusätzliche Informationen über die Funktion oder Bedeutung eines Elements.

<!-- Korrekt: Alt-Text für Bilder -->

<img src="produktbild.jpg" 

     alt="Laptop mit geöffnetem Bildschirm">

<!-- Korrekt: aria-label für Button ohne Text -->

<button aria-label="In den Warenkorb">

    <svg aria-hidden="true">...</svg>

</button>

Bei Bildern folgt die Priorität der Accessible Name Computation: aria-labelledby überschreibt aria-label, welches wiederum das alt-Attribut überschreibt. Ein aria-label="Alternativtext" anstelle des alt-Attributs ist bei Grafiken jedoch nicht zielführend – das alt-Attributsollte die erste Wahl bleiben.

Die Verwendung von SVG-Icons erfordert besondere Aufmerksamkeit. Dekorative Icons sollten mit aria-hidden="true" vor Screenreadern verborgen werden, während funktionale Icons ein aussagekräftiges aria-label benötigen.

Best Practices für die Nutzung von aria-label

Die effektive Nutzung von aria-label folgt klaren Richtlinien, die sowohl die Zugänglichkeit als auch die Wartung des Codes sicherstellen. Entwickler müssen dabei verschiedene Aspekte berücksichtigen, um Verwirrung bei den Nutzenden zu vermeiden.

  • Verwenden Sie aria-label sparsam: Setzen Sie das Attribut nur ein, wenn native HTML-Elemente oder sichtbare Beschriftungen nicht ausreichen. Elemente, die bereits durch ihren Textinhalt oder andere HTML-Attribute einen aussagekräftigen Namen haben, benötigen kein zusätzliches aria-label.

  • Formulieren Sie klare, prägnante Beschreibungen: Das aria-label muss für sich allein verständlich sein und den Zweck des Elements präzise beschreiben. Vermeiden Sie technische Beschreibungen oder interne Bezeichnungen, die für Nutzende nicht verständlich sind.

  • Kombinieren Sie mit semantischem HTML: ARIA ergänzt HTML, ersetzt es aber nicht. Nutzen Sie semantische HTML-Elemente wie <button>,<nav> oder <main> als Grundlage und erweitern Sie diese bei Bedarf mit ARIA-Attributen.

    <!-- FALSCH: redundantes aria-label -->

    <button aria-label="Anmelden">Sign in</button>

    <!-- RICHTIG: kein aria-label nötig -->

    <button>Anmelden</button>

  • Berücksichtigen Sie das Fokus-Management: Bei interaktiven Widgets ist wichtig, dass der Fokus korrekt gesteuert wird. Popup-Fenster und Dialogfenster müssen den initialen Fokus auf das erste fokussierbare Element setzen und beim Schließen wieder zur auslösenden Stelle zurückkehren.

Typische Fehler beim ARIA Labeling

Die häufigsten Implementierungsfehler entstehen durch mangelndes Verständnis der ARIA-Hierarchie und falsche Nutzung:

Widersprüchliche Labels: Wenn aria-label nicht mit dem sichtbaren Text übereinstimmt, entstehen Verwirrungen für Benutzerinnen und Benutzer von Spracheingabe-Software. Eine Person sieht „Vorname" als Beschriftung, der Screenreader liest aber „First Name" vor – Sprachbefehle funktionieren dann nicht.

Übermäßiger ARIA-Einsatz: Jedes Element mit aria-label zu versehen, verschlechtert die Zugänglichkeit. Screenreader-Nutzende werden mit redundanten Informationen überlastet, anstatt schneller an ihr Ziel zu gelangen.

Fehlende Aktualisierung dynamischer Inhalte: Bei JavaScript-gesteuerten Elementen muss sichergestellt werden, dass aria-label-Werte bei Zustandsänderungen entsprechend aktualisiert werden. Dies gilt besonders für Widgets mit wechselnden Zuständen.

Unzutreffende Labels: Labels, die nicht mehr der aktuellen Funktion entsprechen, führen zu falschen Erwartungen und erschweren die Navigation.

Checkliste für Entwickler*innen und Designer*innen

  1. Prüfen Sie die Notwendigkeit: Braucht das Element wirklich ein aria-label oder reicht semantisches HTML?

  2. Testen Sie mit Bildschirmleseprogrammen: Verwenden Sie NVDA (Windows), VoiceOver (Mac) oder andere Screenreader zur Überprüfung

  3. Validieren Sie die Accessible Name Computation: Nutzen Sie Browser-Entwicklertools, um zu prüfen, welcher Name tatsächlich berechnet wird

  4. Achten Sie auf Konsistenz: Verwenden Sie einheitliche Formulierungen für ähnliche Elemente auf der Website

  5. Dokumentieren Sie ARIA-Implementierungen: Erklären Sie im Code, warum und wie ARIA-Attribute verwendet werden

  6. Berücksichtigen Sie alle Eingabemethoden: Stellen Sie sicher, dass Widgets sowohl per Tastatur als auch per Touch bedienbar sind

  7. Prüfen Sie Listen und Navigation: Verwenden Sie semantische HTML-Tags für Listen und Navigationslinks, und ergänzen Sie diese bei Bedarf mit ARIA-Attributen

Fazit: So setzen Sie aria-label sinnvoll ein

Das aria-label-Attribut ist ein wichtiges Werkzeug für barrierefreie Webseiten, erfordert aber durchdachte Implementierung. Es schließt die Lücke zwischen visueller Gestaltung und semantischer Zugänglichkeit, sollte aber immer als Ergänzung zu semantischem HTML verstanden werden, nicht als Ersatz.

Die Wirksamkeit von aria-label zeigt sich besonders bei Icon-Buttons, Custom-Widgets und Situationen, in denen sichtbare Beschriftungen den visuellen Eindruck stören würden. Gleichzeitig erfordern die gesetzlichen Vorgaben des BFSG und der WCAG 2.1 eine systematische Herangehensweise an ARIA-Labels.

Die wesentliche Komponente erfolgreicher ARIA-Implementierung ist das Verständnis, dass Barrierefreiheit von Websites ein wichtiger Schritt in Richtung digitaler Teilhabe für alle Menschen ist – unabhängig von ihren individuellen Fähigkeiten oder Einschränkungen.

FAQs

Sollte man aria-label immer nutzen oder nur bei Bedarf?

aria-label sollte nur verwendet werden, wenn native HTML-Elemente oder sichtbare Beschriftungen nicht ausreichen. Übermäßiger Einsatz führt zu redundanten Informationen und verschlechtert die Benutzererfahrung für Screenreader-Nutzende.

Wie teste ich, ob mein aria-label funktioniert?

Verwenden Sie Screenreader wie NVDA (Windows) oder VoiceOver (Mac/iOS) für realistische Tests. Browser-Entwicklertools zeigen im Accessibility-Tab die berechneten Properties und den tatsächlich verwendeten Namen an.

Welche Screenreader unterstützen aria-label?

Moderne Screenreader wie NVDA, JAWS, VoiceOver und TalkBack unterstützen aria-label umfassend. Die Unterstützung kann jedoch je nach Browser und Version variieren, weshalb Tests mit verschiedenen Kombinationen empfehlenswert sind.

Was passiert, wenn ein Element kein aria-label hat?

Screenreader verwenden den nächsten verfügbaren Namen in der Accessible Name Computation-Hierarchie: aria-labelledby, sichtbarer Textinhalt oder das title-Attribut. Ohne jegliche Beschriftung können interaktive Elemente für assistive Technologien unverständlich bleiben.

Prüfen Sie kostenlos die Barrierefreiheit Ihrer Website!

Wird geladen...
Wird geladen...
Wird geladen...
Wird geladen...

Sie benötigen weitere Informationen?

Schreiben Sie uns und wir helfen Ihnen gerne weiter.

A man and a woman look at a monitor and laugh