Blog

Was bedeuten ARIA-Rollen im Barrierefreiheits-Test?

Herausgegeben von Decareto

4 Minuten lesen

September 29, 2026

ARIA-Rollen sind semantische Attribute, die HTML-Elementen mitteilen, welche Funktion sie für assistive Technologien wie Screenreader erfüllen. Im Barrierefreiheits-Test werden sie daraufhin geprüft, ob sie korrekt gesetzt, sinnvoll verwendet und mit dem tatsächlichen Verhalten des Elements konsistent sind. Fehlerhafte oder fehlende ARIA-Rollen zählen zu den häufigsten technischen Barrieren, die automatisierte Tools wie ein Barrierefreiheit-Test-Tool zuverlässig erkennen können. Die folgenden Abschnitte beantworten die wichtigsten Fragen rund um ARIA-Rollen und ihre Bedeutung für WCAG-Konformität.

Wie werden ARIA-Rollen im Barrierefreiheits-Test ausgewertet?

Im Barrierefreiheits-Test werden ARIA-Rollen durch automatisierte Analyse des HTML-Codes jeder einzelnen Seite ausgewertet. Das Testwerkzeug prüft, ob die zugewiesenen Rollen gültig sind, ob sie im richtigen Kontext verwendet werden und ob die zugehörigen ARIA-Attribute (wie aria-label, aria-expanded oder aria-required) korrekt gesetzt sind. Gefundene Verstöße werden nach Schweregrad klassifiziert und mit konkreten Hinweisen zur Behebung ausgegeben.

Technisch gesehen liest das Testwerkzeug das DOM (Document Object Model) jeder gescannten Unterseite und vergleicht die vorgefundenen ARIA-Attribute mit den Regeln der WCAG sowie der ARIA-Spezifikation des W3C. Dabei werden unter anderem folgende Aspekte geprüft:

Ob eine Rolle überhaupt für das verwendete HTML-Element erlaubt ist
Ob Pflichtattribute für eine bestimmte Rolle vorhanden sind (z. B. aria-checked bei role=“checkbox“)
Ob Elemente mit interaktiven Rollen per Tastatur erreichbar sind
Ob Landmark-Rollen wie role=“main“ oder role=“navigation“ korrekt strukturiert sind

Die Ergebnisse werden im Accessibility-Report nach WCAG-Kriterium und Schweregrad gefiltert dargestellt, sodass Entwickler und Berater gezielt priorisieren können, welche Probleme zuerst behoben werden sollten.

Welche ARIA-Rollen werden am häufigsten falsch eingesetzt?

Zu den am häufigsten falsch eingesetzten ARIA-Rollen gehören role=“button“, role=“dialog“, role=“alert“ und Landmark-Rollen wie role=“banner“ oder role=“contentinfo“. Fehler entstehen meist dadurch, dass Rollen ohne die erforderlichen Begleitattribute gesetzt werden oder dass sie auf Elemente angewendet werden, die das entsprechende Verhalten gar nicht umsetzen.

Häufige Fehler bei interaktiven Rollen

role=“button“ wird oft auf ein <div>– oder <span>-Element gesetzt, ohne dass dieses per Tastatur fokussierbar ist oder auf Tastatureingaben reagiert. Ein Screenreader kündigt das Element zwar als Schaltfläche an, aber Nutzer, die ausschließlich die Tastatur verwenden, können es nicht aktivieren. Ähnliches gilt für role=“dialog“: Ohne korrektes Fokusmanagement und die Attribute aria-modal sowie aria-labelledby ist ein Modal für Screenreader-Nutzer kaum bedienbar.

Häufige Fehler bei Landmark-Rollen

Landmark-Rollen wie role=“navigation“ oder role=“main“ werden mitunter mehrfach auf einer Seite ohne unterscheidende aria-label-Attribute verwendet. Das führt dazu, dass Screenreader-Nutzer nicht zwischen verschiedenen Navigationsbereichen unterscheiden können. Auch role=“banner“ und role=“contentinfo“ sollten jeweils nur einmal pro Seite vorkommen und nicht innerhalb von Sektionselementen geschachtelt werden.

Was passiert, wenn ARIA-Rollen fehlen oder falsch gesetzt sind?

Wenn ARIA-Rollen fehlen oder falsch gesetzt sind, erhalten assistive Technologien wie Screenreader keine oder irreführende Informationen über die Funktion eines Elements. Das kann dazu führen, dass Nutzer mit Behinderungen wesentliche Funktionen einer Website gar nicht oder nur mit erheblichem Mehraufwand nutzen können. Im schlimmsten Fall ist eine grundlegende Funktion wie ein Login-Formular oder eine Navigation vollständig unzugänglich.

Konkret äußern sich solche Probleme auf verschiedene Weisen:

Screenreader lesen Elemente mit falscher Bezeichnung vor, was zu Verwirrung führt
Interaktive Elemente ohne korrekte Rolle werden von Screenreadern möglicherweise vollständig ignoriert
Fehlende Landmark-Rollen erschweren die schnelle Navigation per Tastatur, da Nutzer nicht direkt zum Hauptinhalt springen können
Falsch verwendete Rollen wie role=“alert“ ohne tatsächliche Statusmeldung können Screenreader zu unnötigen Ankündigungen veranlassen

Aus WCAG-Perspektive betreffen solche Fehler vor allem die Erfolgskriterien 4.1.2 (Name, Rolle, Wert) und 1.3.1 (Informationen und Beziehungen), die zu den meistgeprüften Kriterien im Rahmen einer BITV-Prüfung und eines WCAG-Tests gehören.

Wie unterscheiden sich ARIA-Rollen von nativen HTML-Semantiken?

Native HTML-Elemente wie <button>, <nav> oder <main> bringen ihre Semantik bereits eingebaut mit: Browser und assistive Technologien verstehen ihre Funktion ohne zusätzliche Attribute. ARIA-Rollen hingegen sind ein Ergänzungsmechanismus, der die Semantik von Elementen überschreiben oder ergänzen kann, wenn natives HTML nicht ausreicht oder nicht verwendet wird.

Die wichtigste Faustregel lautet: Natives HTML hat Vorrang vor ARIA. Die erste Regel der ARIA-Spezifikation des W3C besagt ausdrücklich, keine ARIA-Rolle zu verwenden, wenn ein natives HTML-Element mit der gewünschten Semantik existiert. Ein <button>-Element ist immer besser als ein <div role="button">, weil das native Element automatisch tastaturzugänglich ist, Fokus erhält und das korrekte Verhalten mitbringt.

ARIA-Rollen sind dann sinnvoll, wenn:

Komplexe Widgets wie Akkordeons, Tabs oder Baumansichten umgesetzt werden, für die es kein natives HTML-Äquivalent gibt
Bestehende Strukturen aus technischen Gründen nicht auf natives HTML umgestellt werden können
Dynamisch erzeugte Inhalte (z. B. per JavaScript) semantisch ausgezeichnet werden müssen

Im Barrierefreiheits-Test werden Seiten sowohl auf fehlende native Semantik als auch auf inkorrekte ARIA-Verwendung geprüft, da beide Szenarien zu Barrieren führen können.

Welche ARIA-Rollen sind für WCAG-Konformität besonders relevant?

Für die WCAG-Konformität sind vor allem Landmark-Rollen, Rollen für interaktive Steuerelemente und Rollen für Live-Regionen besonders relevant. Sie decken die WCAG-Erfolgskriterien ab, die am häufigsten bei einem Web-Accessibility-Check beanstandet werden, insbesondere die Kriterien 1.3.1, 2.1.1 und 4.1.2.

Die praktisch bedeutsamsten ARIA-Rollen im Kontext eines WCAG-Tests sind:

Landmark-Rollen: role=“main“, role=“navigation“, role=“banner“, role=“contentinfo“, role=“search“ und role=“complementary“ ermöglichen es Screenreader-Nutzern, schnell zwischen Seitenbereichen zu navigieren.
Widget-Rollen: role=“button“, role=“checkbox“, role=“dialog“, role=“tablist“ und role=“tooltip“ sind für interaktive Komponenten essenziell und erfordern jeweils spezifische Begleitattribute.
Live-Region-Rollen: role=“alert“, role=“status“ und role=“log“ teilen Screenreadern mit, dass sich Inhalte dynamisch ändern, und steuern, wie dringend diese Änderungen vorgelesen werden.
Dokumentstruktur-Rollen: role=“heading“, role=“list“ und role=“figure“ ergänzen die Struktur dort, wo natives HTML nicht verwendet wurde.

Wer eine Website auf Barrierefreiheit prüfen möchte, sollte sicherstellen, dass alle diese Rollenkategorien korrekt implementiert sind, bevor ein formaler WCAG-Test oder eine BITV-Prüfung durchgeführt wird.

Wann reicht ein automatisierter Scan für ARIA-Rollen-Prüfungen aus?

Ein automatisierter Scan reicht für ARIA-Rollen-Prüfungen aus, wenn es darum geht, technisch eindeutige Fehler zu identifizieren: ungültige Rollenwerte, fehlende Pflichtattribute oder strukturell falsche Verschachtelungen. Diese Fehlerklassen lassen sich zuverlässig durch automatisierte Analyse des HTML-Codes erkennen. Für qualitative Aspekte wie die inhaltliche Sinnhaftigkeit eines aria-label oder das korrekte Fokusmanagement in komplexen Widgets ist ein manueller Test notwendig.

Schätzungen aus der Accessibility-Forschung, unter anderem einer Übersicht der Universität Bielefeld, gehen davon aus, dass automatisierte Tests typischerweise etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme abdecken. Für ARIA-Rollen bedeutet das konkret:

Automatisiert gut prüfbar: Fehlende Pflichtattribute, ungültige Rollenwerte, doppelte Landmark-Rollen ohne Beschriftung, falsche Eltern-Kind-Beziehungen (z. B. role=“listitem“ außerhalb einer Liste)
Nur manuell prüfbar: Ob ein aria-label den Inhalt sinnvoll beschreibt, ob das Fokusmanagement in einem Dialog korrekt funktioniert, ob dynamische Inhalte zum richtigen Zeitpunkt angekündigt werden

Ein automatisierter Scan ist daher ein sinnvoller erster Schritt, der grobe Fehler schnell aufdeckt und einschätzen lässt, ob ein anschließender manueller Test überhaupt ein gutes Ergebnis liefern könnte. Er ersetzt den manuellen Test nicht, aber er hilft, Prioritäten zu setzen und den Aufwand für die manuelle Prüfung zu reduzieren.

Wie decareto Sie bei der ARIA-Prüfung unterstützt

Wir bei decareto haben unsere Barrierefreiheits-Software so entwickelt, dass ARIA-Fehler strukturiert, priorisiert und handlungsorientiert dargestellt werden. Konkret bietet decareto folgende Unterstützung:

Automatisierter WCAG-Scan: Wir prüfen Ihre Website auf ARIA-Fehler gemäß WCAG 2.1 und 2.2, einschließlich fehlender Pflichtattribute, ungültiger Rollenwerte und struktureller Fehler in Landmark-Bereichen.
Schweregrad-Priorisierung: Jedes gefundene Problem wird nach Schweregrad eingestuft, sodass Sie sofort erkennen, welche ARIA-Fehler grundlegende Funktionen blockieren und welche weniger dringend sind.
Konkrete Handlungsempfehlungen: Zu jedem Problem liefern wir klare Hinweise zur Behebung, verständlich für Entwickler und nachvollziehbar für Berater.
Manuelle Tests ergänzen: Probleme, die automatisiert nicht erkannt werden können, lassen sich direkt im Report manuell erfassen und dokumentieren, sodass ein vollständiges Bild entsteht.
Dauerhafte Überwachung: Hunderte Websites lassen sich kontinuierlich überwachen; bei Änderungen erhalten Sie automatische Benachrichtigungen, damit neue ARIA-Fehler nicht unbemerkt bleiben.
Report teilen: Fertige Accessibility-Reports können direkt mit Kunden geteilt werden, auch unter eigenem Logo dank Whitelabel-Funktion.

Testen Sie jetzt, wie viele ARIA-Fehler auf Ihren Websites vorliegen: Jetzt kostenlos starten und einen ersten automatisierten Barrierefreiheits-Scan durchführen.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.