Was ist ARIA? Rollen, Landmarks und Live-Regionen

Was ARIA ist — und was nicht

ARIA steht für Accessible Rich Internet Applications. Es ist ein Satz von Attributen, definiert von der Web Accessibility Initiative (WAI) des W3C, mit dem Entwicklerinnen und Entwickler Bedeutung und Zustand von Oberflächenelementen an assistive Technologien wie Screenreader kommunizieren können.

Die wichtigste Regel zu ARIA ist zugleich die am häufigsten missachtete: Verwenden Sie ARIA nicht, wenn natives HTML die Aufgabe erledigen kann. Ein <button>-Element kündigt sich bereits als Schaltfläche an und reagiert auf Tastaturereignisse. Ein <nav>-Element vermittelt Screenreadern bereits einen Navigations-Landmark. Einem <div> role="button" hinzuzufügen und sein Verhalten dann per Skript nachzubauen, ist schwerer zu pflegen, leichter kaputtzumachen und für die Barrierefreiheit meist schlechter, als von vornherein das richtige Element zu verwenden.

ARIA tut Folgendes nicht:

• Inhalte sichtbar oder interaktiv machen — es ändert nur, was assistive Technologie ansagt
• Kaputten Tastaturzugang reparieren — Sie brauchen weiterhin tabindex und Event-Listener
• Gut strukturiertes semantisches HTML ersetzen

Wirklich hilfreich ist ARIA dort, wo natives HTML kein Element für das bietet, was Sie bauen: ein Datumsauswahlfeld, ein Banner für Live-Benachrichtigungen, eine eigene Combobox, eine Baumansicht. In diesen Fällen erlaubt ARIA es Ihnen, die Semantik zu vermitteln, die HTML nicht abbilden kann.

ARIA-Rollen

Eine Rolle teilt assistiver Technologie mit, mit welcher Art von Element sie es zu tun hat. Jedes interaktive Element hat eine implizite Rolle, die sich aus seinem HTML-Tag ergibt. Das <a>-Element hat die Rolle link. Das Element <input type="checkbox"> hat die Rolle checkbox. Das <h2>-Element hat die Rolle heading.

Wenn Sie ein eigenes Element bauen, für das es kein HTML-Äquivalent gibt, weisen Sie ihm eine explizite Rolle zu:

<!-- Ein eigener Umschalter, aufgebaut aus einem div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Dunkelmodus
</div>

Der Screenreader kündigt dies nun als Schalter an und spricht dessen Zustand aus. Ohne die Rolle würde es als reiner Text angesagt, und die nutzende Person hätte keine Ahnung, dass es interaktiv ist.

Häufige Rollen und wann man sie verwendet

Widget-Rollen beschreiben interaktive Steuerelemente:

Rolle	Verwenden, wenn
button	Ein eigenes anklickbares Element, für das es kein besseres HTML-Tag gibt
checkbox	Eigener Mehrfachauswahl-Umschalter
combobox	Ein Texteingabefeld kombiniert mit einer Listbox-Auswahl
dialog	Ein modales Overlay (nur wenn nicht das native <dialog>-Element verwendet wird)
listbox	Eine eigene Auswahlliste
slider	Ein eigenes Bereichs-Steuerelement
switch	Ein Ein/Aus-Umschalter
tab, tablist, tabpanel	Eine Oberfläche mit Registerkarten
tooltip	Eine kurze Beschreibung, die bei Hover oder Fokus erscheint

Rollen zur Dokumentstruktur beschreiben nicht interaktive Inhalte:

• article — ein in sich geschlossener Inhaltsblock
• figure — ein Bild mit Bildunterschrift
• list, listitem — wenn Listensemantik auf Nicht-Listen-Elementen benötigt wird
• presentation / none — entfernt die implizite Rolle eines Elements (selten und mit Bedacht einsetzen)

Ein kritischer Fehler: Rollen ohne Verhalten hinzufügen

Jede Rolle trägt einen Vertrag in sich, dessen Einhaltung Screenreader- und Tastaturnutzende erwarten. Ein role="button" muss sowohl auf Enter als auch auf Leertaste reagieren. Ein role="checkbox" muss bei Leertaste umschalten. Ein role="link" muss bei Enter navigieren.

Wenn Sie die Rolle hinzufügen, aber nicht das zugehörige Verhalten, führen Sie Nutzende assistiver Technologie aktiv in die Irre. Sie hören, dass ein Steuerelement angesagt wird, versuchen mit dem erwarteten Tastaturkürzel damit zu interagieren — und nichts passiert. Das ist schlimmer als gar kein ARIA.

ARIA-Landmarks

Landmarks sind das navigatorische Skelett einer Seite. Sie erlauben Screenreader-Nutzenden, zwischen den wichtigsten Bereichen zu springen, ohne alles dazwischen zu lesen — das Gegenstück dazu, dass sehende Nutzende das Seitenlayout mit einem Blick erfassen.

HTML5 hat semantische Elemente eingeführt, die direkt auf Landmark-Rollen abgebildet werden. Verwenden Sie sie, und die Landmarks gibt es gratis dazu:

HTML-Element	Landmark-Rolle	Zweck
<header>	banner	Seitenweiter Kopfbereich (nur wenn es der oberste Header ist, nicht innerhalb von <article>)
<nav>	navigation	Ein Navigationsmenü
<main>	main	Der primäre Seiteninhalt
<aside>	complementary	Ergänzender Inhalt mit Bezug zum Hauptinhalt
<footer>	contentinfo	Seitenweite Fußzeile
<form>	form	Ein Formular (nur wenn es einen zugänglichen Namen hat)
<section>	region	Ein benannter Abschnitt (nur wenn er über aria-label oder aria-labelledby einen zugänglichen Namen hat)

Sie müssen einem <main>-Element kein role="main" hinzufügen — das ist redundant. ARIA-Landmark-Rollen werden nur dann gebraucht, wenn Sie das semantische HTML-Element nicht verwenden können, zum Beispiel in einer Altcodebasis, die <div class="sidebar"> erzeugt:

<div class="sidebar" role="complementary" aria-label="Verwandte Artikel">
  <!-- Inhalt der Seitenleiste -->
</div>

Landmarks beschriften, wenn es mehr als einen gibt

Wenn eine Seite mehrere Instanzen desselben Landmarks enthält — zwei <nav>-Elemente, zwei <section>-Elemente mit role="region" —, muss jede einen eindeutigen zugänglichen Namen haben, damit Nutzende sie unterscheiden können:

<nav aria-label="Hauptnavigation">...</nav>
<nav aria-label="Navigation in der Fußzeile">...</nav>

Ohne Beschriftungen sagt ein Screenreader beide schlicht als „Navigation” an. Mit Beschriftungen hören Nutzende „Hauptnavigation, Navigations-Landmark” und „Navigation in der Fußzeile, Navigations-Landmark” und können die richtige aus einer Landmark-Liste auswählen.

ARIA-Live-Regionen

Eine Live-Region ist ein Seitenbereich, dessen Inhalt sich dynamisch aktualisiert und dessen Aktualisierungen Screenreader-Nutzenden automatisch angesagt werden sollen, ohne dass sie den Fokus bewegen müssen.

Das zentrale Attribut ist aria-live. Es akzeptiert drei Werte:

• off — Aktualisierungen werden nicht angesagt (Standard für alle Elemente)
• polite — Aktualisierungen werden angesagt, nachdem die nutzende Person ihre aktuelle Aufgabe beendet hat
• assertive — Aktualisierungen unterbrechen sofort, was der Screenreader gerade sagt

<!-- Ein Statusmeldungsbereich, der nach dem Absenden eines Formulars gefüllt wird -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Ihre Nachricht wurde gesendet.';
</script>

Wenn sich der Textinhalt ändert, wartet ein Screenreader bei aria-live="polite" auf eine Sprechpause und sagt dann den neuen Inhalt an. Verwenden Sie polite für die überwiegende Mehrheit dynamischer Aktualisierungen. Reservieren Sie assertive ausschließlich für kritische Fehler — einen Zahlungsfehler, eine Warnung vor Sitzungsablauf —, bei denen die Information dringend genug ist, um die Unterbrechung zu rechtfertigen.

Rollen als Abkürzung für Live-Regionen

Zwei Rollen bündeln die aria-live-Semantik in einem einzigen Attribut:

• role="status" — entspricht aria-live="polite". Für Erfolgsmeldungen, Ladezustände und nicht dringende Aktualisierungen.
• role="alert" — entspricht aria-live="assertive" und impliziert zusätzlich aria-atomic="true". Für Fehlermeldungen und kritische Fehler.

<!-- Fehler wird sofort angesagt und unterbricht die laufende Sprachausgabe -->
<div role="alert" id="payment-error"></div>

<!-- Statusaktualisierung wird höflich nach der laufenden Sprachausgabe angesagt -->
<div role="status" id="cart-count">3 Artikel im Warenkorb</div>

Häufige Fehler bei Live-Regionen

Inhalte hinzufügen, bevor das Element im DOM ist. Der Browser registriert die Live-Region, wenn das Element erstmals geparst wird. Wenn Sie das Element einfügen und gleichzeitig seinen Textinhalt setzen, verpassen manche Screenreader die Ansage vollständig. Nehmen Sie den Container der Live-Region immer ins initiale HTML auf und aktualisieren Sie seinen Inhalt später per JavaScript.

assertive für alles verwenden. Assertive Live-Regionen unterbrechen alles, was die nutzende Person gerade tut, einschließlich anderer Ansagen. Eine Trefferanzahl, die sich beim Tippen aktualisiert, rechtfertigt kein role="alert". Der übermäßige Einsatz von assertive erzeugt für Screenreader-Nutzende eine feindselige Erfahrung.

Die Live-Region zu häufig aktualisieren. Wenn ein Fortschrittsindikator seine Live-Region alle 100 Millisekunden aktualisiert, läuft die Sprachwarteschlange über und Nutzende hören nichts Brauchbares. Aktualisieren Sie Live-Text nur bei sinnvollen Meilensteinen — 25 %, 50 %, 75 %, fertig — oder entprellen Sie die Aktualisierungen mit einem Timer.

aria-atomic vergessen. Standardmäßig wird nur der geänderte Textknoten innerhalb einer Live-Region angesagt. Wenn Sie möchten, dass die gesamte Region erneut vorgelesen wird (nicht nur das geänderte Fragment), fügen Sie aria-atomic="true" hinzu:

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> Artikel verbleibend
</div>

Ohne aria-atomic sagt ein Screenreader möglicherweise nur „2” an, wenn die Zahl von 3 auf 2 wechselt. Mit dem Attribut wird die vollständige Formulierung „2 Artikel verbleibend” gesprochen, was fast immer das ist, was Sie wollen.

Weitere wesentliche ARIA-Attribute

aria-label — liefert einen zugänglichen Namen, wenn kein sichtbarer Text angemessen ist:

<button aria-label="Dialog schließen">✕</button>

aria-labelledby — verweist auf ein anderes Element, dessen Text als zugänglicher Name dient. Gegenüber aria-label vorzuziehen, wenn der Beschriftungstext auf der Seite ohnehin sichtbar ist:

<h2 id="billing-heading">Rechnungsadresse</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — verweist auf ergänzenden Text, der ein Element über seinen Namen hinaus beschreibt:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Muss mindestens 12 Zeichen lang sein und ein Sonderzeichen enthalten.</p>

aria-expanded — zeigt an, ob ein aufklappbares Element (Dropdown, Akkordeon, Menü) geöffnet oder geschlossen ist. Aktualisieren Sie es in JavaScript bei jeder Zustandsänderung:

<button aria-expanded="false" aria-controls="nav-menu">Menü</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — entfernt ein Element aus dem Barrierefreiheitsbaum. Für dekorative Symbole, doppelten Text oder visuelle Elemente, die für Screenreader-Nutzende nur Rauschen wären:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 von 5 Sternen</span>

aria-disabled="true" — kennzeichnet ein Steuerelement als deaktiviert, ohne es aus der Fokusreihenfolge zu entfernen. Nützlich, wenn Nutzende erfahren sollen, dass das Steuerelement existiert, und verstehen sollen, warum es nicht verfügbar ist, statt dass es stillschweigend übersprungen wird:

<button aria-disabled="true">Absenden (zuerst alle Felder ausfüllen)</button>

ARIA in der Praxis testen

ARIA-Attribute zu schreiben ist unkompliziert. Sie richtig hinzubekommen erfordert Tests. Automatisierte Scanner erkennen eindeutig kaputte Muster — ein role="button" ohne zugänglichen Namen, ein aria-labelledby, das auf eine nicht existierende ID verweist, eine Live-Region mit einem ungültigen aria-live-Wert. Sie können Ihnen nicht sagen, ob der angesagte Text im Kontext Sinn ergibt oder ob sich ein komplexes eigenes Widget korrekt verhält, wenn man es allein mit der Tastatur bedient.

Kombinieren Sie für praxisnahe Tests mindestens zwei Kombinationen aus Screenreader und Browser:

• NVDA + Chrome unter Windows — kostenlos, weit verbreitet, nahe an der realen Screenreader-Nutzerschaft
• VoiceOver + Safari unter macOS oder iOS — integriert, unverzichtbar für mobile Barrierefreiheitstests
• JAWS + Chrome oder Edge unter Windows — kostenpflichtig, aber der am weitesten verbreitete Screenreader in Unternehmensumgebungen

Navigieren Sie Ihre interaktiven Komponenten ausschließlich mit der Tastatur. Hören Sie genau hin, was angesagt wird, wenn Sie ein Menü öffnen, ein Formular mit einem Validierungsfehler absenden oder eine Aktualisierung einer Live-Region auslösen. Ist die Ansage mehrdeutig oder irreführend, ist die ARIA-Umsetzung falsch — unabhängig davon, was irgendein automatisiertes Werkzeug meldet.

Die Regel, die alles abdeckt

Die ARIA-Spezifikation enthält fünf Regeln für Autorinnen und Autoren. Die erste ist die wichtigste:

Wenn Sie ein natives HTML-Element oder -Attribut verwenden können, in dem die benötigte Semantik und das benötigte Verhalten bereits eingebaut sind, statt ein Element umzuwidmen und ihm eine ARIA-Rolle, einen ARIA-Zustand oder eine ARIA-Eigenschaft hinzuzufügen, um es barrierefrei zu machen, dann tun Sie das.

Bauen Sie mit semantischem HTML. Greifen Sie erst dann zu ARIA, wenn HTML an seine Grenzen stößt. Testen Sie mit einem echten Screenreader. Damit ist nahezu jede Situation abgedeckt, der Sie begegnen werden.

Für eine praktische Überprüfung, wie ARIA-Attribute auf Ihrer gesamten Website umgesetzt sind, umfassen unsere manuellen Barrierefreiheits-Audits Screenreader-Tests durch Menschen, die assistive Technologie täglich nutzen und subtile ARIA-Probleme erkennen, die automatisierten Werkzeugen entgehen.