Technisch

ARIA verstehen: Wann es hilft, wann es schadet

ARIA ist mächtig – und gefährlich. Es kann Barrierefreiheit deutlich verbessern, aber bei falscher Anwendung sogar verschlechtern. Diese Übersicht erklärt die Grundlagen, die fünf zentralen Regeln und die wichtigsten Patterns.

  • 14 Minuten Lesezeit
  • Stand: Mai 2026

Was ARIA ist – und was nicht

ARIA steht für Accessible Rich Internet Applications und ist eine W3C-Spezifikation, die HTML um zusätzliche semantische Informationen erweitert. Ziel: Webinhalte – besonders dynamische und interaktive Komponenten – für assistive Technologien zugänglich machen, wo HTML allein nicht ausreicht.

Konkret stellt ARIA drei Werkzeuge zur Verfügung: Attribute, mit denen du beschreiben kannst, was ein Element ist(z.B. role="button" ), in welchem Zustand es sich befindet(z.B. aria-expanded="true" ) und welche Eigenschaften es hat(z.B. aria-label="Suche" ).

Die wichtigste Wahrheit über ARIA

Kein ARIA ist besser als falsches ARIA.

Diese Aussage stammt aus der W3C ARIA Authoring Practices Guide. Sie klingt provokant, ist aber ernst gemeint: Falsch eingesetztes ARIA verschlechtert die Barrierefreiheit aktiv – oft mehr, als wenn man gar nichts gemacht hätte.

Warum? Weil ARIA Versprechungen an assistive Technologien macht. Wenn ein <div> mit role="button" ausgezeichnet wird, sagt der Code: „Das hier ist ein Button." Wenn dieser <div> dann aber nicht per Tastatur bedienbar ist, keinen Fokus annimmt und nicht auf Enter reagiert, ist das eine kaputte Versprechung. Nutzer:innen finden ein Versprechen vor, das nicht eingehalten wird.

„No ARIA is better than bad ARIA." — W3C ARIA Authoring Practices Guide

Praktisch heißt das: Bevor du ARIA einsetzt, prüfe immer zuerst, ob du nicht mit nativem HTML dieselbe Funktion erreichen kannst. Ein echtes <button> bringt Tastatur-Unterstützung, Fokus-Verhalten, Screenreader-Kopplung und das richtige Verhalten in Formularen kostenlos mit – kein ARIA kann das nachbauen, ohne dass etwas vergessen wird.

Die fünf Regeln von ARIA

Der W3C ARIA Authoring Practices Guide formuliert fünf Regeln, die als Leitlinie für jeden ARIA-Einsatz dienen. Wer sie konsequent anwendet, vermeidet die meisten ARIA-bedingten Barrieren.

1

Wenn natives HTML reicht, nutze HTML.

ARIA ist kein Ersatz für HTML. Ein <button> ist immer besser als <div role="button"> . Native HTML-Elemente bringen Rolle, Tastaturbedienung, Fokus und Screenreader-Unterstützung automatisch mit. Erst wenn HTML wirklich nicht ausreicht, kommt ARIA ins Spiel.

2

Native Semantik nicht überschreiben.

Wer einer Überschrift per role="button" die Rolle eines Buttons gibt, zerstört die Überschrift-Semantik. Screenreader listen sie nicht mehr als Überschrift auf. Wenn du eine andere Rolle brauchst, baue ein neues Element drumherum – überschreibe nicht das alte.

3

Alle interaktiven ARIA-Elemente müssen tastaturzugänglich sein.

Wer role="button" auf ein <div> setzt, übernimmt die volle Verantwortung: tabindex="0" muss gesetzt sein, Enter und Leertaste müssen das Klick-Event auslösen, der Fokus muss sichtbar sein. Ohne diese Arbeit ist die ARIA-Auszeichnung eine reine Lüge.

4

Sichtbare Elemente nicht vor assistiven Technologien verstecken.

role="presentation" oder aria-hidden="true" dürfen nicht auf fokussierbare Elemente angewendet werden. Wer das tut, schafft Elemente, die per Tab erreicht werden können, aber von Screenreadern komplett ignoriert werden – Nutzer:innen landen auf einem unsichtbaren Ziel.

5

Interaktive Elemente brauchen einen zugänglichen Namen.

Jeder Button, jedes Eingabefeld, jeder Link muss einen accessible name haben – über ein Label, sichtbaren Text oder als letztes Mittel über aria-label . Wer das vergisst, erzeugt für Screenreader-Nutzer:innen leere, zwecklose Bedienelemente.

Roles, States und Properties

ARIA-Attribute lassen sich in drei Kategorien einteilen. Wer die Logik dahinter versteht, weiß schnell, welches Attribut wann sinnvoll ist.

Roles

Rolle: Was ist es?

Roles definieren, welche Art von UI-Komponente ein Element darstellt. Sie verändern, wie assistive Technologien das Element interpretieren.

role="navigation"
role="dialog"
role="alert"
States

Zustand: Wie ist es gerade?

States beschreiben den aktuellen Zustand eines Elements – ein Zustand kann sich während der Nutzung ändern (z.B. „auf-/zugeklappt").

aria-expanded="true"
aria-checked="false"
aria-disabled="true"
Properties

Eigenschaft: Welche Beziehung?

Properties beschreiben Eigenschaften und Beziehungen, die meist statisch sind – etwa zu welchem anderen Element gehört dieses?

aria-label="Suche"
aria-labelledby="titel"
aria-describedby="info"

Die wichtigsten ARIA-Attribute im Alltag

Aus der Liste der ARIA-Attribute begegnen einem im Praxisalltag immer wieder dieselben. Diese Handvoll deckt einen Großteil der Anwendungsfälle ab:

  • aria-label – gibt einem Element einen unsichtbaren Namen, wenn kein sichtbares Label möglich ist
  • aria-labelledby – verweist auf ein anderes Element, das den Namen liefert
  • aria-describedby – verknüpft eine zusätzliche Beschreibung
  • aria-expanded – Zustand auf-/zugeklappt (für Menüs, Akkordeons)
  • aria-hidden – versteckt Elemente vor assistiven Technologien
  • aria-current – markiert das aktuelle Element in einer Gruppe (z.B. aktive Navigation)
  • aria-live – meldet dynamische Änderungen an Screenreader
  • aria-invalid – markiert ein Feld als fehlerhaft

Die wichtigsten ARIA-Patterns

Die W3C ARIA Authoring Practices Guide dokumentiert dutzende Komponenten-Patterns mit konkreten Code-Beispielen. Vier davon begegnen einem in fast jeder Web-Anwendung:

Landmarks

Strukturelle Bereiche markieren

Landmarks geben einer Seite eine klare Struktur. Screenreader nutzen sie, um schnell zwischen Hauptinhalt, Navigation, Suche oder Footer zu springen. HTML5 bringt die wichtigsten Landmarks bereits mit – ARIA ist nur dann nötig, wenn HTML nicht ausreicht.

✗ Veraltet (ARIA nötig) HTML 
  <div 
 role= 
 "navigation" 
 > 
… </div>
✓ Modern (ohne ARIA) HTML 
  <nav> 
… </nav>

Wichtig: Wenn mehrere Landmarks vom gleichen Typ existieren (z.B. zwei Navigationsbereiche), bekommen sie zur Unterscheidung aria-label : <nav aria-label="Hauptnavigation"> und <nav aria-label="Footer-Navigation"> .

Live Regions

Dynamische Änderungen ankündigen

Wenn sich Inhalte ohne Seitenneuladen ändern – etwa eine Erfolgs-Meldung nach dem Speichern oder ein Live-Suchergebnis – müssen Screenreader das mitbekommen. ARIA-Live-Regions sind dafür gedacht.

Live-Region für Status-Updates HTML 
  <div 
 aria-live= 
 "polite" 
 aria-atomic= 
 "true" 
 > 
Drei Suchergebnisse gefunden. </div>

Vorsicht: aria-live="assertive" unterbricht die Screenreader-Ausgabe – nur für wirklich kritische Meldungen (Fehler, Warnungen). Für die meisten Updates ist "polite" die richtige Wahl.

Disclosure

Ein-/ausklappbare Bereiche

Akkordeons, Dropdown-Menüs, Details-Sections – alles, was sich auf- und zuklappen lässt, braucht aria-expanded . Damit weiß der Screenreader, ob der Bereich gerade offen oder geschlossen ist.

Akkordeon-Button HTML 
  <button 
 aria-expanded= 
 "false" 
 aria-controls= 
 "abschnitt-1" 
 > 
Versandinformationen </button> 
 <div 
 id= 
 "abschnitt-1" 
 hidden 
 > 
… </div>

Wichtig: Das aria-expanded -Attribut muss per JavaScript aktualisiert werden, wenn sich der Zustand ändert. Statisch auf "false" stehenlassen ist schlechter als gar nichts.

Dialog

Modale Dialoge

Modal-Fenster sind eines der komplexesten ARIA-Patterns – Fokus-Management, Tastatur-Verhalten, Hintergrund-Inertheit. Der einfachste Weg ist heute meist das native <dialog> -Element. Wenn du selbst bauen musst, brauchst du role="dialog" , aria-modal="true" und sorgfältiges Fokus-Management.

Custom-Dialog (vereinfacht) HTML 
  <div 
 role= 
 "dialog" 
 aria-modal= 
 "true" 
 aria-labelledby= 
 "dialog-titel" 
 > 
 <h2 
 id= 
 "dialog-titel" 
 > 
Bestellung bestätigen </h2> 
… <button> 
Schließen </button> 
 </div>

Empfehlung: Modal-Dialoge selbst zu bauen ist eine der größten ARIA-Fallen. Wenn irgend möglich, nutze das native <dialog> -Element oder eine etablierte Bibliothek, die das Pattern getestet umgesetzt hat.

Häufige ARIA-Fehler

Fehler 1: role doppelt auf nativen Elementen

✗ Redundant HTML 
  <button 
 role= 
 "button" 
 > 
Senden </button>
✓ Reicht HTML 
  <button> 
Senden </button>

Ein <button> ist bereits ein Button – die explizite role="button" ist überflüssig und macht den Code unleserlich. Das Gleiche gilt für role="link" auf <a> , role="heading" auf <h2> und so weiter.

Fehler 2: aria-label auf sichtbar beschrifteten Elementen

Wenn ein Button schon einen sichtbaren Text hat, braucht er kein aria-label . Schlimmer noch: ein abweichender aria-label überschreibt den sichtbaren Text – Screenreader-Nutzer:innen und sehende Nutzer:innen hören dann unterschiedliche Dinge. Sprach-Steuerung funktioniert nicht mehr („Klick Bestellen" findet nichts, weil der Button eigentlich „submit-button-1" heißt).

Fehler 3: aria-hidden auf interaktiven Elementen

Das Versteckt-Attribut darf nicht auf Elemente angewendet werden, die fokussiert werden können. Sonst können Tastatur-Nutzer:innen das Element erreichen, aber der Screenreader gibt keine Information darüber.

Fehler 4: Veraltete Rollen für Landmarks

role="navigation" , role="banner" , role="contentinfo" sind durch HTML5-Elemente überflüssig geworden. <nav> , <header> und <footer> übernehmen diese Rollen automatisch.

Fehler 5: Statische aria-expanded -Werte

Wer aria-expanded="false" setzt und vergisst, das per JavaScript zu aktualisieren, lügt aktiv: Egal ob das Akkordeon offen oder zu ist, der Screenreader sagt immer „eingeklappt". Besser aria-expanded weglassen, als statisch falsch zu setzen.

Häufige Missverständnisse

Was ARIA nicht ist

Wenige Themen in der Barrierefreiheit produzieren so viele Mythen wie ARIA. Vier davon sind besonders verbreitet – und besonders folgenreich, wenn man sie glaubt.

„Mehr ARIA bedeutet bessere Barrierefreiheit."

Das Gegenteil ist oft der Fall. Studien des W3C zeigen, dass Seiten mit viel ARIA häufig mehr Barrierefreiheits-Fehler haben als Seiten ohne ARIA. Der Grund: ARIA ist komplex und wird häufig falsch eingesetzt.

„ARIA macht <div> -Konstrukte zu echten HTML-Elementen."

ARIA beschreibt nur, was ein Element ist – es verändert nicht das Verhalten. Ein <div role="button"> bleibt ein <div> – ohne Tastatur-Support, ohne Submit-Verhalten, ohne automatischen Fokus. Diese Eigenschaften musst du selbst mit JavaScript bauen.

„ARIA ist für die meisten Websites notwendig."

Eine gut gemachte, einfache Website kommt mit fast ganz ohne ARIA aus. Natives HTML bietet alles, was man für Navigation, Formulare, Listen und Buttons braucht. ARIA wird erst bei komplexen Komponenten relevant – Tabs, Akkordeons, Dialoge, Live-Updates.

„Wenn ARIA da ist, ist die Seite barrierefrei."

Vorhandene ARIA-Attribute sagen nichts über tatsächliche Barrierefreiheit aus. Es kommt auf die korrekte Anwendung an. Eine Seite kann hunderte ARIA-Attribute haben und trotzdem für Screenreader-Nutzer:innen unbenutzbar sein – wenn die Attribute falsch gesetzt sind.

Wann ARIA vermeiden?

Hier eine ehrliche Liste von Situationen, in denen ARIA fast immer ein Fehler ist – und was die bessere Alternative wäre:

  • Wenn du einen Button bauen willst: Nutze <button> . Nicht <div role="button"> .
  • Wenn du einen Link bauen willst: Nutze <a href> . Nicht <span role="link"> .
  • Wenn du eine Überschrift willst: Nutze <h1> – <h6> . Nicht role="heading" auf einem <div> .
  • Wenn du eine Liste willst: Nutze <ul> oder <ol> . Nicht role="list" auf einem <div> .
  • Wenn du Hauptnavigation, Header, Footer willst: Nutze <nav> , <header> , <footer> – nicht die alten Landmark-Rollen.
  • Wenn du Tabellen willst: Nutze <table> mit <th> und <td> . Tabellen mit <div> nachzubauen, ist eine ARIA-Hölle.

ARIA ist ein wertvolles Werkzeug für genau die Fälle, in denen HTML an seine Grenzen stößt: komplexe Widgets, dynamische Updates, eigene Komponenten. Aber es ist kein Aufpoliermittel für mittelmäßiges HTML. Wer das verstanden hat, nutzt ARIA seltener, aber besser – und genau darum geht es.