Es klingt wie ein Widerspruch, und doch belegen es die Daten Jahr für Jahr: Websites, die ARIA-Attribute einsetzen, sind im Schnitt weniger barrierefrei als solche ohne. Das Werkzeug, das die Zugänglichkeit verbessern soll, verschlechtert sie in der Praxis – weil es falsch verwendet wird. Kaum ein Attribut steht dabei so im Zentrum wie das aria-label. Ich sehe es in fast jedem Audit, und in der Mehrzahl der Fälle richtet es mehr Schaden an, als es nützt. In diesem Leitfaden zeige ich Ihnen, was WAI-ARIA leistet, wann ein aria-label das richtige Mittel ist und wann nicht, die fünf Regeln, an denen sich jede ARIA-Entscheidung messen lassen muss – und warum ARIA-Fehler die unangenehme Eigenschaft haben, bei jedem Deployment zurückzukehren.

Was ist WAI-ARIA – und welches Problem löst es?

WAI-ARIA steht für „Accessible Rich Internet Applications“ und ist ein Standard des W3C, der die Lücke zwischen modernen Weboberflächen und assistiven Technologien schließt. Die aktuelle verbindliche Fassung ist WAI-ARIA 1.2, seit 2023 offizielle Empfehlung; eine Version 1.3 befindet sich noch im Entwurfsstadium. Das Grundproblem, das ARIA löst, ist schnell erklärt: HTML bietet von Haus aus nicht für jede Komponente die passende Semantik. Für einen Link, einen Button oder ein Eingabefeld gibt es ein natives Element – für ein Tab-Panel, ein Akkordeon oder eine sich dynamisch aktualisierende Benachrichtigung jedoch nicht.

Genau hier setzt ARIA an. Es reichert HTML um zusätzliche Informationen an, die ein Screenreader auswerten kann. Diese Informationen fallen in drei Kategorien: Rollen sagen, was ein Element ist (etwa role="dialog"), Zustände beschreiben seine dynamische Lage (etwa aria-expanded="false"), und Eigenschaften liefern ergänzende Informationen. Das aria-label ist eine solche Eigenschaft – es gibt einem Element einen barrierefreien Namen, den ein Screenreader vorliest. Es ist mächtig, weit verbreitet und leider auch das Attribut, das am häufigsten falsch eingesetzt wird.

Das ARIA-Paradox: Warum mehr aria-label oft mehr Barrieren bedeutet

Bevor wir zur richtigen Anwendung kommen, müssen Sie verstehen, warum ARIA so oft scheitert. Die jüngste WebAIM-Million-Analyse von 2026 ist eindeutig: Startseiten mit ARIA wiesen im Durchschnitt 59,1 erkennbare Fehler auf, solche ohne ARIA nur 42. Mehr ARIA korreliert also mit mehr Barrieren, nicht mit weniger. Das liegt nicht an ARIA selbst, sondern an einem Denkfehler über seine Wirkungsweise.

Und die Tendenz verschärft sich: 82,7 Prozent der untersuchten Startseiten setzen inzwischen ARIA ein, nach 79,4 Prozent im Vorjahr. Die Verbreitung von aria-label, aria-labelledby und aria-describedby stieg allein im letzten Jahr um 28 Prozent – auf durchschnittlich 31,4 solcher Attribute pro Seite. Je mehr ARIA auf einer Seite liegt, desto mehr Fehler sind statistisch zu erwarten. Die Botschaft des W3C bringt es auf den Punkt: Keine ARIA ist besser als schlechte ARIA.

Der entscheidende Punkt, den viele Entwickler übersehen: ARIA verändert nur, was eine assistive Technologie ansagt – nicht das tatsächliche Verhalten des Elements. Ein <div role="button"> wird einem Screenreader als Schaltfläche gemeldet. Aber es bekommt dadurch weder Tastaturfokus noch reagiert es auf die Eingabetaste, noch sieht es aus wie ein Button. Diese Eigenschaften müssten Sie alle manuell in JavaScript nachbauen. Tun Sie das nicht, haben Sie eine Barriere geschaffen, die schlimmer ist als gar kein ARIA: Der Screenreader verspricht einem blinden Nutzer eine Schaltfläche, die sich nicht bedienen lässt. Ein ARIA-Attribut ist immer ein Versprechen – und ein Versprechen, das Sie nicht einlösen, ist eine Lüge gegenüber der assistiven Technologie.

Der Anstieg der Fehler in den letzten Jahren hat eine zusätzliche Ursache, die ich in der Praxis täglich sehe: Oberflächen werden zunehmend mit KI-Werkzeugen generiert, die ARIA großzügig, aber unsauber verteilen. Ein aria-label hier, ein role dort – ohne Verständnis für die dahinterliegende Mechanik. Das Ergebnis ist Code, der auf den ersten Blick zugänglich wirkt und es in Wahrheit nicht ist.

Die fünf Regeln des ARIA-Gebrauchs

Das W3C hat fünf Regeln formuliert, an denen sich jede ARIA-Entscheidung messen lassen muss. Wenn Sie nur eine Sache aus diesem Artikel mitnehmen, dann diese Tabelle – sie ist die Checkliste, die ich jedem Entwicklungsteam an die Hand gebe.

Die erste Regel ist die wichtigste, und sie fasst meine Grundhaltung zusammen: Keine ARIA ist besser als schlechte ARIA. Ein natives <button> bringt Rolle, Tastaturbedienung, Fokus und Klickverhalten von selbst mit – fehlerfrei und in jedem Browser. Erst wenn HTML eine Komponente wirklich nicht abbilden kann, kommt ARIA ins Spiel. Und dann gilt Regel drei: Semantik allein genügt nie, die Bedienbarkeit müssen Sie selbst sicherstellen.

Native Landmarks statt ARIA-Rollen für die Seitenstruktur

Die ersten beiden Regeln gelten nicht nur für einzelne Bedienelemente, sondern auch für die Grobstruktur Ihrer Seite. Screenreader-Nutzer springen mithilfe von Landmarken zwischen den großen Bereichen – Navigation, Hauptinhalt, Suche. Früher mussten diese Bereiche mit ARIA-Rollen wie role="navigation" ausgezeichnet werden. Heute liefert HTML5 dafür native Elemente, die dieselbe Landmarke automatisch erzeugen.

<!-- Umständlich: ARIA-Rolle auf neutralem div -->
<div role="navigation"> ... </div>
<div role="main"> ... </div>

<!-- Besser: native Elemente, Landmarke inklusive -->
<nav> ... </nav>
<main> ... </main>

Das <nav>-Element erzeugt die Navigations-Landmarke von selbst, <main> die Hauptinhalts-Landmarke, <header> und <footer> ihre jeweiligen Bereiche. Sie sparen sich die Rolle und vermeiden zugleich einen klassischen Fehler – mehrere role="main" auf einer Seite, was die Orientierung zerstört. Die Regel bleibt dieselbe: erst das native Element, ARIA nur als Ergänzung dort, wo HTML an seine Grenzen stößt.

Wann ein aria-label das richtige Werkzeug ist – und wann nicht

Kommen wir zum Kern. Das aria-label vergibt einen barrierefreien Namen, der den sichtbaren Inhalt eines Elements für assistive Technologien ersetzt. Genau darin liegt seine Stärke und seine Gefahr. Es gibt einen klaren Anwendungsfall – und mehrere verbreitete Fehlanwendungen.

Das aria-label ist berechtigt, wenn ein interaktives Element keinen sichtbaren Textinhalt hat. Der klassische Fall ist ein Icon-Button: eine Schaltfläche, die nur ein Lupensymbol zeigt. Ohne Namen sagt der Screenreader bloß „Schaltfläche“. Hier schafft ein aria-label Klarheit:

<!-- Falsch: namenlos, Screenreader sagt nur "Schaltfläche" -->
<button><svg ...></svg></button>

<!-- Richtig: das aria-label liefert den Namen -->
<button aria-label="Suche starten"><svg ...></svg></button>

Problematisch wird es, sobald ein Element bereits sichtbaren Text hat. Ein aria-label überschreibt diesen Text vollständig. Schreiben Sie ein abweichendes aria-label auf einen Button, der sichtbar „Absenden“ heißt, entsteht ein gefährlicher Bruch: Ein Nutzer der Sprachsteuerung sagt „Klick Absenden“, weil er das Wort sieht – aber das System kennt nur den aria-label-Namen und reagiert nicht. Das verletzt WCAG-Erfolgskriterium 2.5.3 (Beschriftung im Namen). Die Regel lautet deshalb: Wenn sichtbarer Text vorhanden ist, lassen Sie ihn den Namen bilden, oder beziehen Sie ihn per aria-labelledby ein – statt ihn mit einem aria-label zu überschreiben.

Eine letzte, häufige Falle: Ein aria-label auf einem nicht-interaktiven Element ohne Rolle – etwa einem schlichten <div> oder <span> – wird von vielen Screenreadern schlicht ignoriert. Das Attribut steht im Code, suggeriert Barrierefreiheit, hat aber keine Wirkung. Genau solche stillen Fehlannahmen machen einen automatischen Test so trügerisch: Der Scanner sieht ein vorhandenes Attribut und meldet keinen Fehler.

aria-hidden: das dekorative Icon und das Geisterelement

Das Gegenstück zum aria-label ist aria-hidden – es entfernt ein Element aus dem, was die assistive Technologie wahrnimmt. Richtig eingesetzt, ist es nützlich: Ein rein dekoratives Icon neben einem ohnehin beschrifteten Text soll nicht doppelt vorgelesen werden. Auch dieses Attribut breitet sich rasant aus: Die WebAIM-Million-Analyse 2026 zählte im Schnitt 23,3 aria-hidden="true"-Attribute pro Startseite – ein Plus von 30 Prozent gegenüber dem Vorjahr und mehr als das Zweieinhalbfache seit 2020. Mit der schieren Menge steigt die Wahrscheinlichkeit, dass eines davon versehentlich auf einem bedienbaren Element landet.

<!-- Richtig: dekoratives Icon wird ausgeblendet -->
<span aria-hidden="true"><svg ...></svg></span> Warenkorb

<!-- Falsch: verbirgt ein fokussierbares Element -->
<a href="/hilfe" aria-hidden="true">Hilfe</a>

Der gefährliche Fall ist der zweite. Setzen Sie aria-hidden="true" auf ein fokussierbares Element wie einen Link oder Button, entsteht ein Geisterelement: Ein Tastaturnutzer landet beim Durchtabben darauf, sein Screenreader aber schweigt – der Fokus steht auf etwas, das offiziell nicht existiert. Das ist einer der verwirrendsten Zustände überhaupt und genau der Grund für die vierte ARIA-Regel. Faustregel: aria-hidden gehört nur auf rein Dekoratives, niemals auf etwas, das man anklicken oder anfokussieren kann.

Drei Muster, die in jedem zweiten Audit brechen

Aus hunderten Prüfungen kristallisieren sich Muster heraus, die immer wieder dieselben Probleme erzeugen. Drei davon, jeweils mit dem Fehler und der Lösung.

Der selbstgebaute Button

Das mit Abstand häufigste Anti-Pattern. Ein klickbares <div> sieht im Browser aus wie ein Button, ist aber für die Tastatur eine Sackgasse.

<!-- Falsch: kein Fokus, keine Tastatur, keine Rolle -->
<div class="btn" onclick="submit()">Absenden</div>

<!-- Richtig: das native Element bringt alles mit -->
<button type="submit">Absenden</button>

Aus der Praxis: Bei einem Reiseportal war das gesamte Buchungsmenü aus solchen <div>-Konstrukten gebaut – mit der Maus tadellos, per Tastatur komplett tot. Das verletzte gleich zwei WCAG-Kriterien: 2.1.1 (Tastatur) und 4.1.2 (Name, Rolle, Wert). Der nachträgliche Umbau auf native Elemente kostete das Team mehrere Wochen. Mit einem nativen <button> von Anfang an wäre kein einziger dieser Fehler entstanden.

Das Akkordeon ohne Zustand

Aufklappbare Bereiche sind allgegenwärtig – und melden ihren Zustand oft nicht. Ein Screenreader-Nutzer muss wissen, ob ein Bereich gerade offen oder geschlossen ist. Genau dafür existiert aria-expanded.

<!-- Falsch: Zustand unsichtbar für AT -->
<button class="toggle">Versanddetails</button>

<!-- Richtig: Zustand wird angesagt und per JS aktualisiert -->
<button aria-expanded="false" aria-controls="panel-1">Versanddetails</button>
<div id="panel-1" hidden> ... </div>

Der entscheidende Punkt: Das aria-expanded darf nicht statisch sein. Es muss per JavaScript zwischen true und false umgeschaltet werden, sobald der Bereich auf- oder zuklappt. Ein fest auf „false“ stehendes Attribut ist ebenso irreführend wie gar keines.

Die Statusmeldung, die niemand hört

Das unterschätzteste Problem moderner Anwendungen. Wenn sich Inhalte ändern, ohne dass die Seite neu lädt – ein Artikel landet im Warenkorb, eine Formularvalidierung schlägt an –, bemerkt ein Screenreader das nicht automatisch. Sie müssen den Bereich als Live-Region auszeichnen.

aria-live: der blinde Fleck im Single-Page-Zeitalter

Mit React, Vue und ähnlichen Frameworks ist es zur Norm geworden, Inhalte dynamisch nachzuladen, ohne die Seite zu wechseln. Für sehende Nutzer ist das komfortabel. Für blinde Nutzer ist es ein Problem, denn ihr Screenreader liest, was beim Laden da war – nachträgliche Änderungen entgehen ihm, sofern Sie ihn nicht aktiv darauf hinweisen. Das Werkzeug dafür ist das Attribut aria-live.

<!-- Höfliche Ansage: wartet, bis der Nutzer pausiert -->
<div aria-live="polite">Artikel wurde in den Warenkorb gelegt.</div>

<!-- Dringende Ansage für Fehler: unterbricht sofort -->
<div role="alert">Bitte geben Sie eine gültige E-Mail-Adresse ein.</div>

Der Unterschied ist wichtig: aria-live="polite" sagt eine Änderung an, sobald der Nutzer gerade nichts anderes tut – ideal für Bestätigungen. role="alert" (das intern aria-live="assertive" nutzt) unterbricht sofort und ist Fehlermeldungen vorbehalten. Wer alles auf „assertive“ setzt, bombardiert den Nutzer mit Unterbrechungen; wer Fehler nur „polite“ meldet, riskiert, dass sie untergehen. Diese Abwägung treffen Scanner nicht für Sie – sie erkennen die Region, aber nicht, ob ihre Dringlichkeit zum Inhalt passt.

Aus der Praxis: Bei einem Online-Shop bestätigte das System „In den Warenkorb gelegt“ nur visuell als kurz eingeblendete Meldung. Ein blinder Tester legte denselben Artikel viermal in den Korb, weil ihm keine Rückmeldung gegeben wurde – er war schlicht unsicher, ob sein Klick angekommen war. Eine einzige aria-live-Region löste das Problem vollständig.

Warum ARIA-Fehler bei jedem Deployment zurückkommen

Hier liegt der Unterschied zwischen ARIA und vielen anderen Barrierefreiheitsthemen, und er entscheidet darüber, wie Sie das Problem dauerhaft in den Griff bekommen. Ein einmal korrekt gesetztes aria-label bleibt nicht von selbst korrekt. ARIA lebt im interaktiven, sich ständig ändernden Teil Ihrer Anwendung – genau dort, wo Entwickler täglich neue Komponenten bauen, bestehende umschreiben und Frameworks aktualisieren.

Jedes neue Feature, jedes Refactoring, jedes Update einer Komponentenbibliothek kann frische ARIA-Fehler einschleusen. Ein Akkordeon, dessen aria-expanded heute sauber umschaltet, verliert diese Logik beim nächsten Umbau vielleicht unbemerkt. Eine Live-Region verschwindet, weil jemand das Markup vereinfacht hat. Im Gegensatz zu einem statischen Kontrastfehler, den Sie einmal beheben, ist ARIA ein bewegliches Ziel. Und das automatische Werkzeug, das viele dagegen einsetzen, hat eine fundamentale Grenze: Ein Scanner prüft, ob ein Attribut vorhanden ist – nicht, ob es inhaltlich stimmt. Ein aria-label="Button" besteht jeden automatischen Test und sagt dem Nutzer trotzdem nichts.

Deshalb reicht eine einmalige Prüfung bei ARIA nicht aus. Die zuverlässige Beurteilung, ob ein selbstgebautes Widget wirklich funktioniert, erfordert einen Menschen mit Screenreader – Browser-Simulatoren bilden das echte Verhalten von JAWS, NVDA oder VoiceOver nicht verlässlich ab. Was Sie zwischen diesen Tiefenprüfungen brauchen, ist ein kontinuierliches Sicherheitsnetz, das anschlägt, sobald ein Deployment neue Fehler einführt.

ARIA im Entwickler-Workflow absichern

Aus all dem folgt eine klare Konsequenz für die Arbeitsweise: Barrierefreiheit im interaktiven Teil einer Anwendung gehört in den Entwicklungsprozess, nicht in eine jährliche Sonderprüfung. Sie wollen den Moment erwischen, in dem ein Fehler entsteht – im Pull Request, beim Deployment –, nicht Monate später in einer Beschwerde.

In der Praxis arbeiten Sie dafür in Schichten. Ein Linter im Editor – etwa eslint-plugin-jsx-a11y – markiert grobe ARIA-Schnitzer schon beim Tippen, und ein Prüfwerkzeug wie axe-core im Continuous-Integration-Lauf kann einen Pull Request blockieren, der eine fehlende Beschriftung oder eine ungültige Rolle einführt. Diese statischen Prüfungen sind wertvoll, stoßen aber an dieselbe Grenze wie jeder Scanner: Sie sehen, ob ein aria-expanded im Markup existiert, nicht, ob es zur Laufzeit tatsächlich umschaltet – und sie greifen nur dort, wo das Team sie eingebaut hat, nicht im fertig ausgelieferten, sich ständig ändernden System.

Genau dafür haben wir Access Guard gebaut. Guard überwacht Ihre Anwendung kontinuierlich, crawlt nach jedem Deployment und meldet neue Barrieren in Echtzeit – direkt dorthin, wo Ihr Team ohnehin arbeitet, etwa nach Jira, Slack oder Teams. Zu jedem gefundenen Problem liefert Guard einen konkreten Lösungsvorschlag samt Code, sodass auch Entwickler ohne tiefe WCAG-Kenntnisse die Korrektur umsetzen können. So wird aus dem beweglichen Ziel ARIA ein beherrschbarer, überwachter Zustand.

Eines sage ich dabei ehrlich dazu: Ein Monitoring ersetzt kein menschliches Tiefen-Audit. Die feine Frage, ob die Dringlichkeit einer Live-Region zum Inhalt passt oder ob ein komplexes Widget für einen echten Nutzer wirklich bedienbar ist, beantwortet nur ein Mensch mit assistiver Technologie – das leistet unser zertifiziertes Audit Access Ready. Access Guard ist das Sicherheitsnetz dazwischen, das verhindert, dass zwischen zwei Audits unbemerkt neue Fehler in Produktion gehen. Den schnellsten ersten Anhaltspunkt, wie es um die maschinell prüfbaren ARIA-Fehler Ihrer Seite steht, liefert Ihnen dabei unser kostenloser Access Score. Wenn Sie ARIA-Barrieren danach nicht immer wieder neu beheben, sondern dauerhaft vermeiden wollen, ist das kontinuierliche Monitoring von Access Guard der richtige Hebel – anders als ein einmal eingebauter Linter, der nach dem nächsten Refactoring schweigt, schlägt es auch dann noch an, wenn ein Deployment Monate später eine neue Barriere einschleust. Wo die Grenzen rein automatischer Werkzeuge liegen, habe ich im Vergleich der Test-Tools aufgeschlüsselt.