Technik

ARIA-Attribute richtig einsetzen: aria-label, aria-describedby und aria-live erklärt

Q: Brauche ich ARIA wenn ich sauberes HTML schreibe?

Meistens nicht. ARIA ist für Fälle wo natives HTML nicht ausreicht – z.B. Tab-Panels, Custom Widgets, Live-Updates. Bei Standard-Webseiten reicht gutes HTML5 für die meisten BFSG-Anforderungen.

Q: Welche ARIA-Attribute sind für das BFSG am wichtigsten?

Für BFSG-Konformität (WCAG 2.1 AA) sind vor allem aria-label, aria-describedby, aria-expanded, aria-live und die Landmark-Rollen (role='navigation', role='main') relevant. Sie erfüllen die Erfolgskriterien SC 1.3.1, SC 4.1.2 und SC 4.1.3.

Q: Was ist der Unterschied zwischen aria-label und aria-labelledby?

aria-label enthält den zugänglichen Namen direkt als Text-String. aria-labelledby verweist per ID auf ein anderes sichtbares Element, das den Namen liefert. aria-labelledby hat Vorrang und ist oft besser, weil der Name für alle Nutzer sichtbar bleibt.

Q: Wann nutze ich aria-live='polite' vs. 'assertive'?

aria-live='polite' wartet, bis der Screenreader die aktuelle Ausgabe beendet hat – ideal für Statusmeldungen und Warenkorb-Updates. 'assertive' unterbricht sofort und sollte nur für kritische Meldungen wie Fehlermeldungen oder Zeitlimits verwendet werden.

Q: Muss ich ARIA für Cookie-Banner einsetzen?

Oft ja. Cookie-Banner sind modale Dialoge und brauchen role='dialog', aria-modal='true' und aria-labelledby. Der Fokus muss beim Öffnen in den Dialog wandern und beim Schließen zurückkehren – sonst verletzt das WCAG SC 2.4.3 (Fokus-Reihenfolge).

Von Joshua Kantner · April 2026 · bf-check.de

Was ist ARIA und wofür brauche ich es?

ARIA (Accessible Rich Internet Applications) ist eine Sammlung von HTML-Attributen, die von der W3C Web Accessibility Initiative (WAI) entwickelt wurden. Sie liefern Screenreadern zusätzliche semantische Informationen, die über das hinausgehen, was natives HTML allein kommunizieren kann.

ARIA überbrückt die Lücke zwischen dynamischen Web-Anwendungen und assistiven Technologien. Sobald eine Webseite komplexe Widgets wie Tabs, Akkordeons oder modale Dialoge enthält, reicht reines HTML oft nicht aus, um Zustand und Verhalten für Screenreader-Nutzer verständlich zu machen.

Für die BFSG-Konformität ist ARIA relevant, weil das Gesetz auf den technischen Standard EN 301 549 verweist, der wiederum die WCAG 2.1 AA-Kriterien einschließt. Mehrere WCAG-Erfolgskriterien – insbesondere SC 1.3.1 (Info und Beziehungen), SC 4.1.2 (Name, Rolle, Wert) und SC 4.1.3 (Statusmeldungen) – erfordern in der Praxis häufig den Einsatz von ARIA.

Die First Rule of ARIA: Weniger ist mehr

Die wichtigste Regel bei ARIA lautet: Nutze kein ARIA, wenn ein natives HTML-Element das Problem löst. Diese Regel stammt direkt aus der offiziellen WAI-ARIA Authoring Practices und ist kein Vorschlag – sie ist eine Grundvoraussetzung für korrekten ARIA-Einsatz. Weitere Informationen finden Sie im ARIA-Labels Glossar.

Konkret bedeutet das:

Ein <button>-Element ist immer besser als ein <div role="button">.
Ein <nav>-Element ist besser als <div role="navigation">.
Ein <input type="checkbox"> braucht kein role="checkbox".

Warum? Native HTML-Elemente bringen Tastatur-Interaktion, Fokus-Management und semantische Informationen automatisch mit. Bei ARIA müsst ihr all das selbst nachbauen – und jeder fehlende Baustein wird zum Barrierefrei-Problem.

ARIA-Rollen (role): Elemente semantisch definieren

Mit dem role-Attribut weist du einem Element eine semantische Bedeutung zu, die der Screenreader erkennt. Die wichtigsten Kategorien:

Landmark-Rollen

Landmark-Rollen strukturieren die Seite in navigierbare Regionen. Screenreader-Nutzer können direkt zwischen Landmarks springen – das entspricht dem visuellen Überfliegen einer Seite. Gemäß WCAG SC 1.3.1 müssen Informationen und Beziehungen programmatisch bestimmbar sein.

role="banner" – Seitenkopf (entspricht <header> als direktes Kind von <body>)
role="navigation" – Navigationsbereich (entspricht <nav>)
role="main" – Hauptinhalt (entspricht <main>)
role="complementary" – ergänzender Inhalt (entspricht <aside>)
role="contentinfo" – Seitenfuß (entspricht <footer> als direktes Kind von <body>)

Praxis-Tipp: Wenn du HTML5-Elemente (<header>, <nav>, <main>, <footer>) korrekt einsetzt, brauchst du die Landmark-Rollen in modernen Browsern nicht zusätzlich. Das ist die First Rule of ARIA in Aktion.

Widget-Rollen

Für interaktive Komponenten, die kein natives HTML-Pendant haben:

role="tablist", role="tab", role="tabpanel" – Tab-Navigation
role="dialog", role="alertdialog" – Modale Dialoge
role="menu", role="menuitem" – Anwendungsmenüs (nicht für Website-Navigation!)
role="tree", role="treeitem" – Baumstrukturen

ARIA-Eigenschaften: Name und Beschreibung

ARIA-Eigenschaften vermitteln zusätzliche Informationen über ein Element. Sie ändern sich typischerweise nicht während der Nutzung.

aria-label

Gibt einem Element einen zugänglichen Namen, der nur für Screenreader sichtbar ist. Ideal für Icon-Buttons ohne sichtbaren Text:

Vorher (schlecht):

<button onclick="closeDialog()">
  <svg>...</svg>
</button>
<!-- Screenreader: "Schaltfläche" (ohne Namen) -->

Nachher (gut):

<button onclick="closeDialog()" aria-label="Dialog schließen">
  <svg aria-hidden="true">...</svg>
</button>
<!-- Screenreader: "Dialog schließen, Schaltfläche" -->

Dies erfüllt WCAG SC 4.1.2 (Name, Rolle, Wert) und ist für die BFSG-Konformität essenziell.

aria-labelledby

Verweist per ID auf ein sichtbares Element, das den zugänglichen Namen liefert. Hat Vorrang vor aria-label und ist oft die bessere Wahl, weil der Name für alle Nutzer sichtbar bleibt:

<h2 id="cart-heading">Warenkorb</h2>
<section aria-labelledby="cart-heading">
  ...
</section>

aria-describedby

Verknüpft ein Element mit einer zusätzlichen Beschreibung. Besonders nützlich bei barrierefreien Formularen, um Hinweistexte oder Fehlermeldungen an Eingabefelder zu binden:

<label for="pw">Passwort</label>
<input type="password" id="pw" aria-describedby="pw-hint">
<span id="pw-hint">Mindestens 8 Zeichen, ein Sonderzeichen</span>

ARIA-Zustände: Dynamisches Verhalten kommunizieren

ARIA-Zustände ändern sich während der Nutzer-Interaktion und müssen per JavaScript aktualisiert werden. Gemäß WCAG SC 4.1.2 muss der aktuelle Zustand programmatisch bestimmbar sein.

aria-expanded

Zeigt an, ob ein aufklappbarer Bereich geöffnet (true) oder geschlossen (false) ist:

<button aria-expanded="false" aria-controls="faq-1">
  Was kostet der Service?
</button>
<div id="faq-1" hidden>
  Ab 29 € pro Monat...
</div>

Beim Klick muss JavaScript aria-expanded auf true setzen und das hidden-Attribut entfernen.

aria-selected

Markiert das aktuell ausgewählte Element in einer Tab-Liste oder Listbox:

<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel-1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">Tab 2</button>
</div>
<div role="tabpanel" id="panel-1">Inhalt Tab 1</div>
<div role="tabpanel" id="panel-2" hidden>Inhalt Tab 2</div>

aria-checked und aria-pressed

aria-checked für Custom-Checkboxen und Switches, aria-pressed für Toggle-Buttons. Beide kennen true, false und bei aria-checked auch mixed (teilweise ausgewählt).

⚠️

Ist deine Webseite betroffen? Kostenloser BFSG-Schnellcheck – Ergebnis in 30 Sekunden.

Jetzt prüfen →

ARIA-Live-Regionen für dynamische Inhalte

Wenn sich Inhalte auf der Seite ändern ohne Seitenwechsel (AJAX-Updates, Warenkorb-Zähler, Fehlermeldungen), muss der Screenreader informiert werden. Das fordert WCAG SC 4.1.3 (Statusmeldungen) explizit: Statusmeldungen müssen programmatisch bestimmbar sein, ohne den Fokus zu erhalten.

aria-live="polite" wartet, bis der Screenreader die aktuelle Ausgabe beendet hat – ideal für Warenkorb-Updates, Suchfilter-Ergebnisse und Erfolgsbenachrichtigungen.

aria-live="assertive" unterbricht sofort. Nutze es nur für kritische Meldungen: Fehlermeldungen bei Formularvalidierung, Session-Timeouts oder Systemfehler.

Vorher (schlecht):

<div id="status"></div>
<!-- Screenreader bemerkt die Änderung nicht -->

Nachher (gut):

<div id="status" aria-live="polite" aria-atomic="true"></div>
<!-- Screenreader liest den neuen Inhalt vor -->

aria-atomic="true" sorgt dafür, dass der gesamte Inhalt der Region vorgelesen wird – nicht nur die Änderung.

Widget-Patterns: Tabs, Akkordeon und Dialog

Komplexe interaktive Komponenten erfordern ein Zusammenspiel aus ARIA-Rollen, -Eigenschaften und -Zuständen plus korrektem Tastatur-Management. Hier die drei häufigsten Patterns:

Tab-Pattern

Die Tab-Navigation erfordert role="tablist" auf dem Container, role="tab" auf jedem Reiter und role="tabpanel" auf jedem Inhaltsbereich. Zusätzlich braucht ihr:

aria-selected="true/false" auf jedem Tab
aria-controls vom Tab zum zugehörigen Panel
Tastatur: Pfeiltasten zwischen Tabs, Tab-Taste springt in den Panel-Inhalt

Akkordeon-Pattern

Jeder Akkordeon-Trigger braucht:

aria-expanded="true/false"
aria-controls mit der ID des aufklappbaren Bereichs
Der Trigger sollte ein <button> sein (oder <summary> bei <details>)

Dialog-Pattern (Modal)

Modale Dialoge – z.B. Cookie-Banner oder Bestätigungs-Popups – benötigen:

role="dialog" und aria-modal="true"
aria-labelledby auf die Überschrift des Dialogs
Fokus-Falle: Der Fokus muss im Dialog bleiben, bis er geschlossen wird (WCAG SC 2.4.3)
Beim Öffnen: Fokus auf das erste interaktive Element im Dialog
Beim Schließen: Fokus zurück zum auslösenden Element
Escape-Taste zum Schließen

Häufige ARIA-Fehler die schaden statt helfen

Falsches ARIA ist schlimmer als kein ARIA. Hier die Fehler, die in BFSG-Audits am häufigsten auftauchen:

1. Redundante ARIA-Labels: aria-label auf Elemente setzen, die bereits einen sichtbaren Text haben. Der Screenreader liest dann nur das Label, nicht den sichtbaren Text – was zu Verwirrung führt.

2. role="button" auf div statt echtem Button: Ein <div role="button"> hat keine native Tastatur-Interaktion. Ihr müsst tabindex="0" hinzufügen, Enter- und Space-Taste abfangen und den Fokus-Stil definieren. Ein <button> macht das alles von selbst.

3. aria-hidden="true" auf sichtbare Inhalte: Versteckt Elemente komplett für Screenreader. Wenn der Inhalt sichtbar ist, aber aria-hidden="true" hat, existiert er für Screenreader-Nutzer nicht – ein klarer WCAG-SC-4.1.2-Verstoß.

4. Fehlende Zustands-Updates: aria-expanded einmal setzen, aber beim Klick nicht per JavaScript aktualisieren. Der Screenreader zeigt dann dauerhaft "eingeklappt", obwohl der Inhalt sichtbar ist.

5. Übermäßiger ARIA-Einsatz: Zu viele ARIA-Attribute machen die Seite unübersichtlich für Screenreader-Nutzer. Jedes zusätzliche Attribut erzeugt eine zusätzliche Ansage. Setzt ARIA nur dort ein, wo es einen konkreten Mehrwert bringt.

6. role="menu" für Website-Navigation: role="menu" ist für Anwendungsmenüs gedacht (wie in Desktop-Apps), nicht für Website-Navigation. Für die Hauptnavigation verwendet ihr <nav> oder role="navigation".

ARIA und BFSG: Die relevanten WCAG-Kriterien

Das BFSG verweist über § 3 BFSG i.V.m. EN 301 549 auf die WCAG 2.1 AA. Die folgenden Erfolgskriterien sind direkt mit ARIA verknüpft:

SC 1.3.1 – Info und Beziehungen: Struktur und Beziehungen müssen programmatisch bestimmbar sein. Landmark-Rollen und ARIA-Eigenschaften erfüllen dies.
SC 4.1.2 – Name, Rolle, Wert: Alle UI-Komponenten müssen einen zugänglichen Namen, eine Rolle und den aktuellen Zustand haben. Das zentrale Kriterium für ARIA.
SC 4.1.3 – Statusmeldungen: Statusmeldungen müssen ohne Fokus-Verschiebung erkennbar sein. Hier kommen aria-live-Regionen zum Einsatz.
SC 2.4.3 – Fokus-Reihenfolge: Relevant für modale Dialoge mit aria-modal="true".
SC 2.1.1 – Tastatur: Alle Funktionen müssen per Tastatur erreichbar sein – besonders wichtig bei Custom-Widgets mit ARIA-Rollen.

Wie du ARIA-Attribute testen kannst

Bevor ihr eure ARIA-Implementierung als fertig betrachtet, testet sie gründlich:

Browser-DevTools: In Chrome öffnet ihr F12 → Elements → Accessibility-Tab. Dort seht ihr den Accessibility-Tree und könnt prüfen, ob Name, Rolle und Zustand korrekt gesetzt sind.
Screenreader-Test: Testet mit NVDA (kostenlos für Windows) oder VoiceOver (macOS/iOS). Navigiert mit Tab, Pfeiltasten und Screenreader-Shortcuts durch eure Widgets.
Automatisierter BFSG-Scan: Unser Scanner erkennt typische ARIA-Fehler wie fehlende Labels, ungültige Rollen und nicht aktualisierte Zustände.
axe DevTools: Browser-Extension, die ARIA-Fehler im Kontext der WCAG-Kriterien auflistet.

Dieser Artikel ersetzt keine Rechtsberatung. Für verbindliche Aussagen zur BFSG-Konformität eurer Webseite empfehlen wir die Konsultation eines spezialisierten Anwalts.

Häufig gestellte Fragen

Brauche ich ARIA wenn ich sauberes HTML schreibe?

Meistens nicht. ARIA ist für Fälle, wo natives HTML nicht ausreicht – z.B. Tab-Panels, Custom Widgets, Live-Updates. Bei Standard-Webseiten reicht gutes HTML5 für die meisten BFSG-Anforderungen.

Was ist die First Rule of ARIA?

Die erste Regel lautet: Verwende kein ARIA, wenn ein natives HTML-Element oder -Attribut die gewünschte Semantik und das Verhalten bereits mitbringt. Ein echtes <button>-Element ist immer besser als ein <div> mit role="button".

Welche ARIA-Attribute sind für das BFSG am wichtigsten?

Für BFSG-Konformität (WCAG 2.1 AA) sind vor allem aria-label, aria-describedby, aria-expanded, aria-live und die Landmark-Rollen (role="navigation", role="main") relevant. Sie erfüllen die Erfolgskriterien SC 1.3.1, SC 4.1.2 und SC 4.1.3.

Was ist der Unterschied zwischen aria-label und aria-labelledby?

aria-label enthält den zugänglichen Namen direkt als Text-String. aria-labelledby verweist per ID auf ein anderes sichtbares Element, das den Namen liefert. aria-labelledby hat Vorrang und ist oft besser, weil der Name für alle Nutzer sichtbar bleibt.

Kann zu viel ARIA schaden?

Ja. Überflüssige ARIA-Attribute erzeugen doppelte Ansagen im Screenreader, widersprüchliche Informationen und erhöhen die Wartungskomplexität. Falsches ARIA ist schlimmer als kein ARIA.

Wann nutze ich aria-live='polite' vs. 'assertive'?

aria-live="polite" wartet, bis der Screenreader die aktuelle Ausgabe beendet hat – ideal für Statusmeldungen und Warenkorb-Updates. "assertive" unterbricht sofort und sollte nur für kritische Meldungen wie Fehlermeldungen oder Zeitlimits verwendet werden.

Muss ich ARIA für Cookie-Banner einsetzen?

Oft ja. Cookie-Banner sind modale Dialoge und brauchen role="dialog", aria-modal="true" und aria-labelledby. Der Fokus muss beim Öffnen in den Dialog wandern und beim Schließen zurückkehren – sonst verletzt das WCAG SC 2.4.3 (Fokus-Reihenfolge).

Wie teste ich ob meine ARIA-Attribute korrekt sind?

Nutze den Accessibility-Tree in den Browser-DevTools (Chrome: F12 → Elements → Accessibility), teste mit einem Screenreader (NVDA ist kostenlos) und lasse einen automatisierten BFSG-Scan laufen, der ARIA-Fehler erkennt.

Weiterlesen

Technik
Alt-Texte richtig schreiben Technik
Farbkontraste prüfen Leitfaden
BFSG 2025: Der komplette Leitfaden

Ist deine Webseite BFSG-konform?

Finde es in 30 Sekunden heraus – kostenloser Schnellcheck mit sofortigem Ergebnis.

Jetzt kostenlos prüfen →