Stell dir einen Aufzug vor, in dem die Tasten keine Beschriftung haben. Nur Pfeile, die irgendwie nach „auf“ und „zu“ aussehen. Mit etwas Übung findest du dich zurecht. Wer die Symbole nicht sehen kann, hat ohne Braille-Punkte keine Chance.
Auf Websites passiert genau das ständig. Ein Button mit drei Strichen für das Menü, eine Lupe für die Suche, ein X zum Schließen. Für sehende Besucher ist das klar. Ein Screenreader findet dort nur „Schalter“, ohne zu sagen, was der Schalter tut. Hier kommt aria-label ins Spiel.
Was aria-label macht
aria-label ist ein HTML-Attribut aus dem Standard WAI-ARIA. Es gibt einem Element einen Namen, den sogenannten zugänglichen Namen. Diesen Namen lesen Screenreader vor, und Sprachsteuerungen nutzen ihn, wenn jemand „Klick auf Menü“ sagt.
Auf der Seite selbst ist aria-label nicht zu sehen. Es ändert weder das Aussehen noch das Verhalten eines Elements. Es beschreibt nur.
<!-- Screenreader: "Schalter" -->
<button>
<svg aria-hidden="true">…</svg>
</button>
<!-- Screenreader: "Menü öffnen, Schalter" -->
<button aria-label="Menü öffnen">
<svg aria-hidden="true">…</svg>
</button>Das aria-hidden am Icon sorgt dafür, dass der Screenreader die Grafik selbst überspringt. Den Namen liefert der Button.
Die erste Regel, erst HTML, dann ARIA
Die Fachleute beim W3C, die ARIA entwickeln, sagen es selbst deutlich. Wenn ein normales HTML-Element das Gewünschte schon kann, nimm das HTML-Element. ARIA ist für die Fälle gedacht, in denen HTML allein nicht reicht.
Für aria-label heißt das: Ein sichtbarer Text ist fast immer besser. Er hilft allen Besuchern, auch denen, die ein Icon nicht verstehen, und er wird von Übersetzungs-Werkzeugen zuverlässiger erfasst.
<!-- braucht kein aria-label, der Text ist der Name -->
<button>Menü</button>
<!-- Icon und Text zusammen, das Icon ist nur Schmuck -->
<button>
<svg aria-hidden="true">…</svg>
Suche
</button>Wann du aria-label brauchst
Buttons und Links, die nur aus einem Icon bestehen
Das ist der häufigste und wichtigste Fall. Menü, Suche, Schließen, Teilen, Warenkorb, Social-Media-Links im Footer. Wenn kein sichtbarer Text da ist, braucht das Element einen Namen.
<a href="https://www.linkedin.com/in/…" aria-label="LinkedIn-Profil von Lisa Berger">
<svg aria-hidden="true">…</svg>
</a>Beschreibe dabei die Funktion, nicht das Aussehen. „Schließen“ statt „X“, „Suche“ statt „Lupe“.
Mehrere Navigationen auf einer Seite
Viele Websites haben ein Hauptmenü oben und ein Menü im Footer. Screenreader können direkt zu Navigationsbereichen springen und zeigen sie als Liste an. Ohne Namen heißen sie dort alle nur „Navigation“.
<nav aria-label="Hauptmenü">…</nav>
<nav aria-label="Rechtliches">…</nav>Das Wort „Navigation“ gehört nicht in den Namen, der Screenreader sagt es ohnehin dazu.
Ein Menü-Button, der auf- und zuklappt
Bei einem Menü-Button kommt zum Namen noch der Zustand dazu. Dafür gibt es aria-expanded. Der Name bleibt gleich, der Zustand wechselt per JavaScript zwischen true und false.
<button aria-label="Menü" aria-expanded="false" aria-controls="hauptmenue">
<svg aria-hidden="true">…</svg>
</button>
<nav id="hauptmenue" aria-label="Hauptmenü" hidden>…</nav>NVDA sagt dann zum Beispiel „Menü, Schalter, reduziert“ und nach dem Öffnen „erweitert“. So weiß jeder, ob das Menü gerade offen ist.
Wann du aria-label nicht brauchst
Wenn schon ein sichtbarer Text da ist
Ein Button mit der Aufschrift „Termin buchen“ hat bereits einen Namen. Ein zusätzliches aria-label wäre im besten Fall überflüssig. Im schlechtesten Fall widerspricht es dem sichtbaren Text, denn aria-label ersetzt ihn für den Screenreader.
Auf div und span ohne Rolle
Ein div oder span hat für Hilfsmittel keine Bedeutung. Ein aria-label darauf wird je nach Browser und Screenreader ignoriert. Wenn etwas klickbar ist, sollte es ein echter Button oder Link sein. Dann funktionieren auch Tastatur und Fokus von allein.
<!-- schlecht: kein Fokus, keine Tastatur, Name wird oft ignoriert -->
<div class="close" aria-label="Schließen" onclick="schliessen()">×</div>
<!-- gut -->
<button type="button" aria-label="Schließen">×</button>Für lange Beschreibungen
aria-label ist für einen kurzen Namen gedacht, nicht für Erklärungen. Für Hilfetexte und Fehlermeldungen an Formularfeldern gibt es aria-describedby. Es verweist auf einen sichtbaren Text, den der Screenreader nach dem Namen vorliest.
<label for="telefon">Telefon</label>
<input id="telefon" type="tel" aria-describedby="telefon-hilfe">
<p id="telefon-hilfe">Nur für Rückfragen zu deinem Termin.</p>Sichtbarer Text muss im Namen stecken
Ein Fehler, der oft übersehen wird: Ein Link zeigt „Mehr erfahren“, das aria-label lautet aber „Details zur Website-Betreuung“. Für Screenreader ist das sogar besser. Wer aber Sprachsteuerung nutzt, sagt „Klick auf Mehr erfahren“, und nichts passiert, weil der Name ganz anders lautet.
Die WCAG verlangen deshalb, dass der sichtbare Text im zugänglichen Namen enthalten ist, am besten am Anfang.
<!-- schlecht: sichtbarer Text fehlt im Namen -->
<a href="/leistungen/website-betreuung/" aria-label="Details zur Website-Betreuung">Mehr erfahren</a>
<!-- besser: sichtbarer Text am Anfang des Namens -->
<a href="/leistungen/website-betreuung/" aria-label="Mehr erfahren über Website-Betreuung">Mehr erfahren</a>
<!-- am besten: ein Linktext, der für sich allein verständlich ist -->
<a href="/leistungen/website-betreuung/">Mehr zur Website-Betreuung</a>aria-labelledby und versteckter Text
Gibt es den passenden Text schon sichtbar auf der Seite, etwa eine Überschrift, kannst du mit aria-labelledby darauf verweisen. Der Vorteil: Ändert sich die Überschrift, ändert sich der Name mit.
<section aria-labelledby="preise-titel">
<h2 id="preise-titel">Preise und Pakete</h2>
…
</section>Eine dritte Möglichkeit ist Text, der nur für Screenreader sichtbar ist. Er steht im HTML, wird aber per CSS optisch versteckt. Viele Frameworks bringen dafür eine Klasse mit, oft sr-only oder visually-hidden genannt. Anders als aria-label wird dieser Text von Übersetzungs-Werkzeugen zuverlässig mit übersetzt.
<a href="/kontakt/">
<svg aria-hidden="true">…</svg>
<span class="sr-only">Kontakt</span>
</a>So prüfst du den Namen eines Elements
Du musst nicht raten, was ein Screenreader vorliest. In den Entwicklertools von Chrome und Firefox gibt es einen Bereich für Barrierefreiheit. Wähle ein Element aus, und du siehst seinen berechneten Namen und seine Rolle.
Für die ganze Seite auf einmal eignet sich die kostenlose Erweiterung axe DevTools. Sie meldet Buttons und Links ohne Namen als eigenen Fehler. Bei allen Websites, die ich baue, läuft diese Prüfung vor dem Start, im hellen und im dunklen Design.
Wie du deine Seite außerdem selbst mit einem Screenreader testest, steht im Beitrag Website mit Screenreader testen. Für Bilder statt Buttons gilt das gleiche Prinzip, nur mit dem alt-Attribut. Dazu mehr im Beitrag Alt-Texte für Bilder schreiben.
Kurz zusammengefasst
aria-label gibt Elementen ohne sichtbaren Text einen Namen. Nutze es für Icon-Buttons, Icon-Links und um mehrere Navigationen zu unterscheiden. Wo ein sichtbarer Text möglich ist, ist er die bessere Lösung. Und wenn ein Element sichtbaren Text hat, muss dieser Text im Namen vorkommen.
Einen ausführlichen Überblick über ARIA insgesamt, mit Rollen, Zuständen und Live-Regionen, habe ich im Beitrag ARIA richtig nutzen bei gehirngerecht.digital (öffnet in neuem Tab) geschrieben. Ob dein Unternehmen nach dem Barrierefreiheitsstärkungsgesetz handeln muss, klärt der Ratgeber zum BFSG.
Titelbild: Foto von Nils R. Barth über Wikimedia Commons, Lizenz CC0 (öffnet in neuem Tab).
