ARIA-Rollen erklärt: Wann und wie man ARIA in HTML verwendet

Hier ist eine ernüchternde Zahl: Laut der Analyse von WebAIM zu den Startseiten der eine Million meistbesuchten Websites weisen Seiten, die ARIA-Attribute enthalten, im Durchschnitt deutlich mehr erkennbare Barrierefreiheitsfehler auf als Seiten ganz ohne ARIA. Das ist kein Argument gegen die Verwendung von ARIA – es ist ein Argument dafür, es korrekt zu verwenden. ARIA ist eines der mächtigsten Werkzeuge im modernen Accessibility-Werkzeugkasten, aber auch eines der am meisten missverstandenen. Wenn du es richtig einsetzt, öffnest du deine Website auf sinnvolle Weise für Millionen von Nutzerinnen und Nutzern mit Behinderungen. Wenn du es falsch einsetzt, verschlechterst du ihre Erfahrung aktiv.

Was ist ARIA und warum gibt es das?

ARIA steht für Accessible Rich Internet Applications. Es ist ein Satz von HTML-Attributen, definiert von der Web Accessibility Initiative des W3C, der es Entwicklern ermöglicht, semantische Informationen an unterstützende Technologien wie Screenreader, Braillezeilen und Sprachsteuerungssoftware zu übermitteln. Wenn ein Browser eine Seite rendert, baut er zwei parallele Strukturen auf: den DOM (das, was du siehst) und den Accessibility Tree (das, was unterstützende Technologien lesen). ARIA-Attribute ermöglichen es dir, diesen Accessibility Tree so zu verändern, dass er genau beschreibt, was benutzerdefinierte Komponenten sind und wie sie sich verhalten.

Der Bedarf an ARIA entstand aus einem realen Problem. HTML wurde für Dokumente entwickelt, nicht für Anwendungen. Als sich das Web zu einer Plattform für reichhaltige, interaktive Erlebnisse entwickelte – Registerkarten-Oberflächen, modale Dialoge, Drag-and-drop, Live-Datenfeeds – konnten native HTML-Elemente Screenreadern nicht vermitteln, was diese Komponenten sind oder wie sie funktionieren. ARIA schließt diese Lücke. Wie MDN es formuliert, ergänzt ARIA „HTML, sodass Interaktionen und Widgets, die üblicherweise in Anwendungen verwendet werden, an unterstützende Technologien weitergegeben werden können, wenn es dafür sonst keinen Mechanismus gibt“.

ARIA verändert nicht die visuelle Darstellung. Es fügt kein Verhalten hinzu. Es stellt nicht automatisch Tastaturunterstützung bereit. Es verändert ausschließlich das, was der Accessibility Tree unterstützenden Technologien zur Verfügung stellt. Das ist ein wichtiger Unterschied – und einer, der viele der Fehler verursacht, die Entwickler machen, wenn sie ARIA als Abkürzung einsetzen.

Die Spezifikation wird vom W3C als WAI-ARIA gepflegt, derzeit in Version 1.2, wobei 1.3 aktiv in Entwicklung ist. Sie stellt eine Ontologie von Rollen, Zuständen und Eigenschaften bereit, die zusammen barrierefreie Benutzeroberflächenelemente über das gesamte Spektrum moderner Webmuster hinweg beschreiben.

Die drei Säulen: Rollen, Zustände und Eigenschaften

Bevor du auch nur eine Zeile ARIA schreibst, musst du die drei unterschiedlichen Bausteine verstehen, die die Spezifikation bereitstellt. Sie sind nicht austauschbar, und sie zu vermischen ist eine der häufigsten Fehlerquellen.

Rollen definieren, was ein Element ist. Eine Rolle beantwortet die Frage: Was für eine Art von Ding sehe ich hier? Beispiele sind button, dialog, navigation, tablist und progressbar. Du wendest eine Rolle mit dem Attribut role an: <div role='button'>. Die Rolle kommuniziert den Zweck des Elements an unterstützende Technologien, damit der Nutzer weiß, wie er damit interagieren soll.

Zustände beschreiben den dynamischen Zustand eines Elements – etwas, das sich ändert, während der Nutzer mit der Seite interagiert. Das Attribut aria-expanded teilt einem Screenreader mit, ob ein aufklappbarer Bereich geöffnet oder geschlossen ist. aria-checked spiegelt wider, ob ein benutzerdefiniertes Kontrollkästchen aktiviert ist. Zustände müssen mit JavaScript synchron gehalten werden; ein statisches aria-expanded='false', das sich nie ändert, ist nicht nur nutzlos, sondern aktiv irreführend.

Eigenschaften liefern beschreibende, meist stabilere Informationen über ein Element. aria-label gibt einem Element einen zugänglichen Namen, der seinen sichtbaren Text überschreibt. aria-labelledby verweist auf ein anderes Element, dessen Text als Beschriftung dient. aria-describedby verknüpft ergänzenden beschreibenden Text. aria-required signalisiert, dass ein Formularfeld ausgefüllt werden muss. Während Zustände sich häufig ändern sollen, werden Eigenschaften in der Regel einmal gesetzt und dann in Ruhe gelassen – auch wenn es Ausnahmen gibt.

Rollen definieren, was ein Element ist. Zustände definieren, wie es sich gerade verhält. Eigenschaften liefern zusätzlichen beschreibenden Kontext. Du brauchst alle drei zusammen, um eine vollständig barrierefreie benutzerdefinierte Komponente zu erstellen.

Die goldene Regel – und warum sie wichtiger ist, als du denkst

Die erste Regel des W3C für den Einsatz von ARIA ist unmissverständlich: Wenn du ein natives HTML-Element oder -Attribut verwenden kannst, das die benötigte Semantik und das benötigte Verhalten bereits eingebaut hat, dann verwende es. Greife nicht zuerst zu ARIA. Dies wird manchmal als das Prinzip „kein ARIA ist besser als schlechtes ARIA“ bezeichnet – ein Ausdruck, der die sehr reale Gefahr gut gemeinter, aber falscher ARIA-Nutzung widerspiegelt.

Native HTML-Elemente bringen implizite ARIA-Semantik kostenlos mit. Ein <button>-Element wird im Accessibility Tree bereits als Button exponiert. Es ist bereits per Tastatur fokussierbar. Es reagiert bereits auf Enter- und Leertaste. Es kündigt seine Beschriftung bereits an. In dem Moment, in dem du <div role='button'> schreibst, übernimmst du die Verantwortung, all dieses Verhalten manuell nachzubilden – die Tastaturbehandlung, das Fokus-Management, die Zustandsaktualisierungen – in JavaScript. Das ist kein theoretisches Problem. Die fehlende Tastaturunterstützung bei einem benutzerdefinierten Button ist einer der häufigsten und schädlichsten ARIA-Fehler in produktiven Systemen.

Die Fälle, in denen ARIA wirklich notwendig ist, konzentrieren sich meist auf einige Szenarien: wenn du ein komplexes Widget baust, für das es kein HTML-Äquivalent gibt (ein Karussell, eine Combobox mit Autovervollständigung, eine Baumansicht); wenn du Alt-Markup nachbesserst, bei dem eine Umstrukturierung des DOM zu teuer wäre; wenn du ein Web Component baust, das benutzerdefinierte Semantik exponieren muss; oder wenn die Unterstützung eines nativen Elements durch Browser und unterstützende Technologien so uneinheitlich ist, dass das ARIA-Äquivalent in der Praxis zuverlässiger funktioniert.

Außerhalb dieser Szenarien sollte dein erster Impuls immer semantisches HTML sein. Verwende <nav> statt <div role='navigation'>. Verwende <main> statt <div role='main'>. Verwende <button> statt <div role='button'>. Die nativen Elemente sind robuster, besser unterstützt und erfordern deutlich weniger Wartung.

Ein Rundgang durch die wichtigsten ARIA-Rollenkategorien

Die WAI-ARIA-Spezifikation organisiert Rollen in mehrere Kategorien. Diese Kategorien zu verstehen hilft dir zu wissen, zu welcher Rolle du in welcher Situation greifen solltest.

Landmark-Rollen

Landmark-Rollen kennzeichnen die Hauptbereiche einer Seite und ermöglichen es Screenreader-Nutzern, mit Tastenkombinationen direkt zu wichtigen Abschnitten zu springen. Die am häufigsten verwendeten Landmark-Rollen sind banner, navigation, main, complementary, contentinfo, search und form. Für jede davon gibt es ein direktes natives HTML-Äquivalent: <header>, <nav>, <main>, <aside>, <footer> und so weiter. In der Praxis bedeutet das, dass Landmark-Rollen fast immer überflüssig sind, wenn du modernes semantisches HTML verwendest. Füge sie nur hinzu, wenn du aus strukturellen Gründen an nicht-semantisches Markup gebunden bist.

<!-- Prefer this -->
<header>
  <nav>...</nav>
</header>
<main>...</main>
<footer>...</footer>

<!-- Use ARIA only when you must use divs -->
<div role='banner'>
  <div role='navigation'>...</div>
</div>
<div role='main'>...</div>
<div role='contentinfo'>...</div>

Widget-Rollen

Widget-Rollen beschreiben interaktive Komponenten, die der Nutzer direkt bedient. Hier leistet ARIA seine wichtigste Arbeit, weil es für viele Widget-Muster kein natives HTML-Äquivalent gibt. Häufige Widget-Rollen sind button, checkbox, dialog, menu, menuitem, slider, tablist, tab, tabpanel, tooltip, tree und combobox.

Wenn du eine Widget-Rolle verwendest, übernimmst du die volle Verantwortung für die Tastaturinteraktion. Der WAI-ARIA Authoring Practices Guide (APG) definiert erwartete Tastaturmuster für jeden Widget-Typ – zum Beispiel Pfeiltasten, um zwischen Tabs zu wechseln, Escape zum Schließen eines Dialogs, Pos1 und Ende, um zum ersten und letzten Eintrag in einer Listbox zu springen. Wenn du diese Muster nicht implementierst, ist deine Komponente technisch zwar beschriftet, aber für reine Tastaturnutzer faktisch unbenutzbar.

<!-- A custom tab interface -->
<div role='tablist' aria-label='Account settings'>
  <button role='tab' aria-selected='true' aria-controls='panel-profile' id='tab-profile'>
    Profile
  </button>
  <button role='tab' aria-selected='false' aria-controls='panel-security' id='tab-security' tabindex='-1'>
    Security
  </button>
</div>
<div role='tabpanel' id='panel-profile' aria-labelledby='tab-profile'>
  <p>Profile settings content</p>
</div>
<div role='tabpanel' id='panel-security' aria-labelledby='tab-security' hidden>
  <p>Security settings content</p>
</div>

Live-Region-Rollen

Live-Regionen sind eine der wirklich nützlichen Funktionen von ARIA. Sie ermöglichen es unterstützenden Technologien, dynamische Inhaltsaktualisierungen anzukündigen – Dinge wie Statusmeldungen, Fehlermeldungen, Chat-Nachrichten und Ladeindikatoren – für Nutzer, die die Bildschirmänderung nicht sehen können. Ohne Live-Regionen könnte ein Screenreader-Nutzer, der ein Formular absendet, nie erfahren, ob es erfolgreich war oder fehlgeschlagen ist, sofern der Fokus nicht explizit auf das Ergebnis verschoben wird.

Die zentralen Live-Region-Rollen sind alert, status, log, marquee und timer. Die Rolle alert bringt implizit die Einstellung aria-live='assertive' mit, was bedeutet, dass sie den Nutzer sofort unterbricht – passend für Fehler oder dringende Warnungen. Die Rolle status verwendet aria-live='polite' und wartet, bis der Nutzer seine aktuelle Aufgabe beendet hat, bevor sie etwas ankündigt – ideal für Erfolgsmeldungen und Fortschrittsanzeigen.

<!-- Polite status message for non-urgent feedback -->
<div role='status' aria-live='polite' aria-atomic='true'>
  <!-- Dynamically inject text here with JavaScript -->
</div>

<!-- Assertive alert for errors that demand immediate attention -->
<div role='alert'>
  Please correct the errors below before submitting.
</div>

Der Schlüssel zu Live-Regionen ist, dass der Container im DOM vorhanden sein muss, bevor der dynamische Inhalt eingefügt wird. Eine Live-Region, die gleichzeitig erstellt und befüllt wird, wird von Screenreadern häufig übersehen. Erstelle den Container beim Laden der Seite und befülle ihn mit JavaScript, wenn Ereignisse auftreten.

Dokumentstruktur-Rollen

Dokumentstruktur-Rollen – wie article, list, listitem, table, row, cell, figure und heading – beschreiben die strukturelle Organisation von Inhalten. Die meisten davon werden inzwischen von nativen HTML-Elementen abgelöst, und MDN weist darauf hin, dass die Mehrheit der Dokumentstruktur-Rollen „nicht mehr verwendet werden sollte, da Browser nun semantische HTML-Elemente mit derselben Bedeutung unterstützen“. Die wichtigste Ausnahme ist, wenn du mit benutzerdefinierten Rendering-Umgebungen, Web Components oder SVG-basierten Inhalten arbeitest, in denen native HTML-Elemente nicht verfügbar sind.

Wichtige ARIA-Eigenschaften, die jede Entwicklerin und jeder Entwickler kennen sollte

Über Rollen hinaus tauchen einige ARIA-Eigenschaften in der Praxis ständig in der Barrierefreiheitsarbeit auf. Zu diesen wirst du am häufigsten greifen:

• aria-label: Liefert einen zugänglichen Namen für ein Element, wenn kein sichtbares Textlabel vorhanden ist oder wenn der sichtbare Text nicht ausreicht. Häufige Anwendungsfälle: reine Icon-Buttons, Suchfelder ohne sichtbare Beschriftung und Schließen-Buttons in Modals. Beachte, dass aria-label jeden sichtbaren Text oder jedes native Label überschreibt, verwende es also mit Bedacht bei Elementen, die sichtbaren Text haben.
• aria-labelledby: Verweist auf ein oder mehrere Elemente, deren Textinhalt als zugänglicher Name dient. Für komplexe Fälle robuster als aria-label, weil der Beschriftungstext mit dem sichtbaren Inhalt synchron bleibt. Akzeptiert eine durch Leerzeichen getrennte Liste von Element-IDs, und unterstützende Technologien verketten die referenzierten Texte in dieser Reihenfolge.
• aria-describedby: Verknüpft ergänzenden Beschreibungstext – keinen Namen, sondern zusätzlichen Kontext. Verwende es, um Formularfelder mit ihren Fehlermeldungen zu verbinden oder um ein Tooltip mit dem Element zu verknüpfen, das es beschreibt. Screenreader kündigen dies typischerweise nach dem Namen und der Rolle des Elements an.
• aria-hidden: Entfernt ein Element vollständig aus dem Accessibility Tree. Unschätzbar wertvoll für dekorative Icons, doppelte Inhalte und rein visuelle Elemente, die für Screenreader-Nutzer Lärm erzeugen würden. Wende niemals aria-hidden='true' auf ein fokussierbares Element an – ein Nutzer könnte es weiterhin per Tab erreichen, würde aber keine Informationen darüber erhalten.
• aria-expanded: Kommuniziert, ob ein aufklappbares Element – ein Dropdown, ein Akkordeon oder ein Disclosure-Widget – derzeit geöffnet oder geschlossen ist. Muss dynamisch mit JavaScript umgeschaltet werden; ein statischer Wert ist schlimmer, als das Attribut ganz wegzulassen.
• aria-current: Kennzeichnet das aktuelle Element innerhalb einer Menge, am häufigsten in der Navigation verwendet, um den aktiven Seitenlink (aria-current='page') oder den aktuellen Schritt in einem mehrstufigen Prozess zu markieren.

Häufige ARIA-Fehler, die der Barrierefreiheit tatsächlich schaden

Angesichts der Tatsache, dass Seiten mit ARIA tendenziell mehr Barrierefreiheitsfehler aufweisen als solche ohne, lohnt es sich, explizit zu benennen, was am häufigsten schiefgeht. Das sind keine Randfälle – es sind Muster, die täglich in produktivem Code auftauchen.

ARIA-Rollen auf Elementen mit starker nativer Semantik verwenden. Einige HTML-Elemente haben laut Spezifikation eine „starke native Semantik“ – Bedeutungen, die tief im Browser verankert sind und nicht gefahrlos überschrieben werden können. Eine unpassende Rolle auf ein <button>- oder ein <input>-Element zu setzen, kann dazu führen, dass der Browser die ARIA-Rolle komplett ignoriert oder widersprüchliches Verhalten erzeugt, das unterstützende Technologien verwirrt. Die Rolle, die du deklarierst, muss zur Art des Elements passen, auf das du sie anwendest.

Tastaturunterstützung bei Widget-Rollen vergessen. ARIAs role='button' teilt einem Screenreader mit, dass das Element ein Button ist. Es macht das Element nicht tastaturbedienbar. Wenn du ein <div> mit role='button' verwendest, musst du tabindex='0' hinzufügen, um es fokussierbar zu machen, und du musst Event-Listener sowohl für Enter als auch für Leertaste hinzufügen. Wenn eines dieser Teile fehlt, brichst du die Erfahrung für reine Tastaturnutzer.

<!-- Incomplete and inaccessible -->
<div role='button' onclick='doSomething()'>Submit</div>

<!-- Correct custom button implementation -->
<div
  role='button'
  tabindex='0'
  onclick='doSomething()'
  onkeydown='if(event.key==="Enter"||event.key===" ")doSomething()'
>Submit</div>

<!-- Or, the right answer: just use a button -->
<button onclick='doSomething()'>Submit</button>

aria-hidden auf fokussierbaren Elementen verwenden. Wenn du aria-hidden='true' auf ein fokussierbares Element anwendest, versteckst du es im Accessibility Tree, aber nicht vor der Tastaturnavigation. Ein Tastaturnutzer kann es weiterhin per Tab erreichen, erhält aber keine Informationen darüber und hat keine Möglichkeit zu wissen, was es tut. Das ist ein Verstoß gegen WCAG 2.1, Erfolgskriterium 4.1.2 (Name, Rolle, Wert).

Veraltete ARIA-Zustände. Wenn aria-expanded, aria-checked, aria-selected und ähnliche Zustände nicht aktualisiert werden, wenn sich die UI ändert, bleibt Screenreader-Nutzern ein grundlegend falsches Bild der Oberfläche. Ein Menü, das visuell geöffnet ist, dessen Auslöser aber weiterhin aria-expanded='false' meldet, ist aktiv irreführend.

Redundante Rollen. role='navigation' zu einem <nav>-Element oder role='button' zu einem <button> hinzuzufügen, bringt keinen Nutzen. Es bläht den Code auf und kann in bestimmten Kombinationen von unterstützenden Technologien gelegentlich zu Verwirrung führen. Vertraue den nativen Semantiken.

ARIA und WCAG: Das Zusammenspiel verstehen

ARIA ist nicht WCAG. Es sind separate Spezifikationen, die zusammenarbeiten. WCAG (Web Content Accessibility Guidelines) definiert das Was – die Ergebnisse, die für barrierefreie Inhalte erforderlich sind. ARIA ist Teil des Wie – ein technischer Mechanismus, um einige dieser Ergebnisse zu erreichen. Das relevanteste WCAG-Erfolgskriterium für ARIA ist 4.1.2: Name, Rolle, Wert, das verlangt, dass alle Benutzeroberflächenkomponenten einen Namen haben, ihre Rolle gegenüber unterstützenden Technologien exponieren und ihren Zustand und ihre Eigenschaften programmatisch mitteilen. ARIA ist eines der wichtigsten Werkzeuge, um dieses Kriterium für benutzerdefinierte Komponenten zu erfüllen.

ARIA unterstützt auch mehrere andere Erfolgskriterien. Landmark-Rollen tragen zu 2.4.1 (Blöcke überspringen) bei, indem sie Skip-Navigation ermöglichen. Live-Regionen sind oft das richtige Werkzeug, um 4.1.3 (Statusmeldungen) in WCAG 2.1 zu erfüllen, das verlangt, dass Statusmeldungen programmatisch ermittelbar sind, ohne den Fokus zu erhalten. Der korrekte Einsatz von aria-label und aria-labelledby hilft, 2.4.6 (Überschriften und Beschriftungen) und 1.3.1 (Info und Beziehungen) zu erfüllen.

Es ist erwähnenswert, dass WCAG-Konformität zunehmend eine rechtliche Anforderung ist. Der European Accessibility Act ist im Juni 2025 vollständig in Kraft getreten und erweitert verpflichtende Barrierefreiheitsanforderungen auf eine breite Palette privater digitaler Dienste in den EU-Mitgliedstaaten. In den Vereinigten Staaten wird der ADA zunehmend so ausgelegt, dass er Web-Barrierefreiheit einschließt, und bundesrechtliche Anforderungen nach Section 508 gelten für staatliche und staatlich finanzierte Organisationen. ARIA korrekt zu verstehen ist nicht nur Best Practice – es ist zunehmend Teil deiner Compliance-Pflichten.

Deine ARIA-Implementierung testen

Die einzige Möglichkeit herauszufinden, ob deine ARIA-Implementierung tatsächlich funktioniert, besteht darin, sie mit realen unterstützenden Technologien zu testen. Automatisierte Tools wie axe, WAVE und Lighthouse können strukturelle Verstöße erkennen – eine fehlende erforderliche Eigenschaft, eine ungültige Rolle, ein aria-hidden auf einem fokussierbaren Element – aber sie können dir nicht sagen, ob ein Screenreader dein Modal auf eine sinnvolle Weise ankündigt oder ob die Tastaturnavigation durch dein benutzerdefiniertes Tree-Widget den erwarteten Mustern folgt.

Für manuelle Tests sind die wichtigsten Screenreader JAWS und NVDA unter Windows (zusammen repräsentieren sie den Großteil der Screenreader-Nutzung auf dem Desktop) sowie VoiceOver auf macOS und iOS. TalkBack deckt Android ab. Jede Kombination aus Screenreader und Browser kann sich anders verhalten, daher wird dringend empfohlen, mindestens zwei Kombinationen zu testen. Teste jeden interaktiven Zustand: Öffne den Dialog, klappe das Akkordeon aus, wähle die Option, löse den Alert aus. Bestätige, dass die Ansage dem entspricht, was ein sehender Nutzer aus derselben Oberfläche verstehen würde.

Wenn du benutzerdefinierte Widgets testest, arbeite das Tastaturinteraktionsmodell durch, das im WAI-ARIA Authoring Practices Guide für diesen Widget-Typ definiert ist. Wenn deine Tabliste nicht auf Pfeiltasten reagiert oder dein Dialog den Fokus nicht einfängt, sind das Fehler – unabhängig davon, wie korrekt das ARIA-Markup in einem automatisierten Audit aussieht.

Wesentliche Erkenntnisse

• Bevorzuge immer semantisches HTML gegenüber ARIA. Native Elemente wie <button>, <nav>, <main> und <dialog> bringen eingebaute Accessibility-Semantik mit, die robuster ist und deutlich weniger Code erfordert als ihre ARIA-auf-einem-div-Äquivalente. Greife nur dann zu ARIA, wenn natives HTML wirklich nicht ausreicht.
• ARIA-Rollen sind ein Versprechen, keine Abkürzung. role='button' oder role='dialog' auf ein benutzerdefiniertes Element anzuwenden, verpflichtet dich dazu, das vollständige Tastaturinteraktionsmodell für diesen Widget-Typ zu implementieren. Rollen ohne passendes Verhalten erzeugen Verwirrung und WCAG-Verstöße.
• Halte ARIA-Zustände mit deiner UI synchron. Dynamische Attribute wie aria-expanded, aria-checked, aria-selected und aria-live-Inhalte müssen in JavaScript aktualisiert werden, wenn sich die UI ändert. Ein veralteter Zustand ist aktiv schädlich – er vermittelt dem Nutzer falsche Informationen.
• Verwende Live-Regionen für dynamische Inhaltsaktualisierungen. Jeder Inhalt, der sich ohne Seitenneuladen ändert – Benachrichtigungen, Fehlermeldungen, Ladezustände, Chat-Feeds – benötigt eine aria-live-Region oder eine passende Rolle wie alert oder status, damit Screenreader-Nutzer automatisch dieselben Informationen erhalten wie sehende Nutzer.
• Teste mit realen unterstützenden Technologien, nicht nur mit automatisierten Tools. Automatisierte Scanner erkennen strukturelle ARIA-Fehler, können aber nicht prüfen, ob deine Implementierung eine kohärente, nutzbare Erfahrung erzeugt. Manuelle Tests mit JAWS, NVDA und VoiceOver sind die einzige Möglichkeit, diese Lücke zu schließen.