Liste der ARIA-Rollen: Beste Referenzen im Vergleich

Die vollständige Liste der ARIA-Rollen besteht aus 82 Werten, die in der WAI-ARIA 1.2-Spezifikation des W3C definiert sind und in sechs funktionale Kategorien unterteilt sind: Dokumentrollen, Landmark-Rollen, Widget-Rollen, Strukturrollen, Fensterrollen und abstrakte Rollen. Die Wahl der richtigen Referenz hängt davon ab, ob Sie eine schnelle Tabelle, eine Dokumentation mit Codebeispielen oder einen Entscheidungsleitfaden zur Anwendung der einzelnen Rollen benötigen.

Die wichtigsten Erkenntnisse

• Die WAI-ARIA 1.2-Spezifikation definiert 82 Rollen, aber in der täglichen Praxis einer barrierefreien XHTML/CSS-Seite wird nur eine kleine Teilmenge verwendet.
• Die erste Regel von ARIA gilt weiterhin: Wenn es ein natives HTML-Element mit der benötigten Semantik gibt, verwenden Sie dieses anstatt eine Rolle hinzuzufügen.
• Abstrakte Rollen (wie role="widget" oder role="input") dürfen niemals im Markup geschrieben werden; sie dienen nur als taxonomische Basis.
• Eine nützliche Referenz für das Front-End sollte die Rolle, ihre obligatorischen ARIA-Attribute, die zulässigen Zustände und ein reales Markup-Beispiel enthalten.
• Landmark- und Widget-Rollen konzentrieren die meisten Fehler, die von automatischen Auditoren wie axe-core oder Lighthouse erkannt werden.

Was ist eine ARIA-Rolle und warum benötigen Sie eine zuverlässige Liste

Eine ARIA-Rolle ist ein Wert, der einem Element über das Attribut role zugewiesen wird, um assistiven Technologien mitzuteilen, welche Art von Komponente es darstellt. Der Browser gibt diese Rolle über den Accessibility Tree (Barrierefreiheitsbaum) aus, und ein Screenreader wie NVDA, JAWS oder VoiceOver übersetzt sie in eine konkrete Ansage: „Schaltfläche“, „Registerkarte“, „Region“, „Dialogfeld“.

Die WAI-ARIA-Spezifikation, die vom W3C innerhalb der ARIA-Arbeitsgruppe gepflegt wird, definiert jede Rolle zusammen mit den zulässigen Zustands- und Eigenschaftsattributen. Die Version 1.2 ist die aktuelle stabile Empfehlung, und ARIA 1.3 befindet sich in der Entwicklung. Für einen Entwickler, der mit XHTML und CSS arbeitet, ist die Rollenliste kein dekorativer Katalog: Jeder falsch angewendete Wert erzeugt einen Konflikt zwischen der nativen Semantik des Elements und der erklärten, und Screenreader lösen diesen Konflikt je nach Browser unterschiedlich auf.

Die offizielle Dokumentation der ARIA-Rollen auf MDN (Mozilla Developer Network) ist die am häufigsten konsultierte technische Referenz in Spanisch und Englisch, aber nicht die einzige. Es gibt Referenzblätter, Musterleitfäden und Validierungswerkzeuge, die unterschiedliche Bedürfnisse abdecken. Ein Vergleich hilft dabei, diejenige auszuwählen, die am besten in Ihren Workflow passt.

Die sechs Kategorien der ARIA-Rollen

Die offizielle Taxonomie gruppiert die Rollen nach ihrer Funktion. Die Kenntnis der Kategorien verhindert die Suche in der falschen Liste.

Dokumentrollen. Beschreiben die Struktur einer Seite oder eines Abschnitts: article, document, feed, heading, img, list, listitem, math, none, note, presentation, row, separator, table, term, toolbar, tooltip. Viele duplizieren native HTML-Elemente und werden daher selten manuell geschrieben.

Verwandte: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Landmark-Rollen. Definieren navigierbare Bereiche der Seite: banner, complementary, contentinfo, form, main, navigation, region, search. Diese werden am häufigsten auf Websites mit unvollständiger HTML-Semantik verwendet.

Widget-Rollen. Stellen interaktive Steuerelemente dar: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, progressbar, radio, scrollbar, searchbox, slider, spinbutton, switch, tab, tabpanel, textbox, treeitem. Erfordern Fokus- und Tastaturmanagement.

Strukturrollen. Zu den Organisations-Widgets gehören: application, grid, group, listbox, menu, menubar, radiogroup, tablist, tree, treegrid, rowgroup, columnheader, rowheader.

Einen Blick wert: AudioEye — Zugriffsmöglichkeit: Kombinierte Automatisierung mit menschlicher Revision.

Fensterrollen. Verwaltung von überlagerten oder modalen Inhalten: alertdialog, dialog.

Abstrakte Rollen. Keine Elemente werden im Markup geschrieben: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget, window. Sie dienen der Spezifikation, um Eigenschaften zwischen Rollen zu vererben.

Vergleich: Die besten ARIA-Rollen-Referenzen

Die folgende Tabelle vergleicht die von Entwicklern am häufigsten verwendeten Referenzen anhand praktischer Kriterien.

Referenz	Typ	Sprachen	Codebeispiele	Ideal für
MDN Web Docs (ARIA-Rollen)	Offizielle Dokumentation	Mehrsprachig (inkl. Spanisch)	Ja, pro Rolle	Tiefe technische Abfrage
WAI-ARIA 1.2 (W3C)	Normative Spezifikation	Englisch	Nein	Überprüfung des exakten Verhaltens
WAI-ARIA Authoring Practices Guide	Musterleitfaden	Englisch	Ja, vollständige Muster	Implementierung von Widgets mit Tastatur
Referenzblatt (Cheat Sheet)	Zusammenfassungstabelle	Englisch	Minimal	Schneller Rückblick im Editor
accessibility.build (ARIA-Referenz)	Praktische Referenz	Englisch	Ja	Lernen mit kommentierten Beispielen
Auditoren (axe-core, Lighthouse)	Werkzeug	Mehrsprachig	Nein	Erkennung ungültiger Rollen

Die Wahl hängt vom Moment ab. Während des Schreibens des Markups gewinnt ein kompaktes Referenzblatt an Geschwindigkeit. Beim Debuggen eines Widgets, das seinen Zustand nicht korrekt ansagt, sind die W3C-Spezifikation und der WAI-Musterleitfaden die Quellen, die die Zweifel lösen.

Wie man entscheidet, welche Rolle anzuwenden ist: Praktische Kriterien

Die richtige Entscheidung beginnt fast immer damit, ARIA auszuschließen. Diese Kriterien, in dieser Reihenfolge, vermeiden die meisten Fehler.

1. Gibt es ein natives HTML-Element? Ein <button> hat bereits die implizite Rolle eines button. Das Hinzufügen von role="button" ist redundant und kann Konflikte verursachen.
2. Erfordert die Rolle obligatorische Attribute? role="checkbox" erfordert aria-checked. role="slider" erfordert aria-valuenow, aria-valuemin und aria-valuemax. Wenn Sie diese Zustände nicht aufrechterhalten können, schadet die Rolle mehr, als sie hilft.
3. Beinhaltet die Rolle eine Tastaturverwaltung? Widget-Rollen erfordern eine Navigation mit Pfeiltasten, Home, End und Esc, je nach Muster. Eine role="tablist" ohne Pfeiltasten-Steuerung ist schlimmer, als sie gar nicht zu haben.
4. Ist die Rolle abstrakt? Wenn sie in der Liste der abstrakten Rollen steht, sollte sie nicht geschrieben werden.
5. Ist die Rolle veraltet oder nicht mehr im Gebrauch? Einige Werte wurden zwischen ARIA 1.0 und 1.2 geändert. Konsultieren Sie immer die aktuelle Version.

Die erste Regel für die Verwendung von ARIA, die im W3C-Technikleitfaden anerkannt wird, ist das Prinzip: Verwenden Sie nach Möglichkeit natives HTML. ARIA ist ein Patch für den Fall, dass HTML nicht ausreicht, kein Ersatz.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

Häufige Fehler beim Konsultieren und Anwenden der Rollenliste

Ein häufiger Fehler besteht darin, eine Rolle von einem Referenzblatt zu kopieren, ohne die erforderlichen Attribute zu prüfen. role="combobox" hat sich in ARIA 1.2 gegenüber 1.0 geändert und erwartet nun aria-expanded sowie eine Beziehung zu einer listbox über aria-controls. Die Anwendung der alten Version führt zu fehlerhaften Ansagen in aktualisierten Screenreadern.

Es ist ebenfalls üblich, role="presentation" oder role="none" zu verwenden, um die Semantik zu „bereinigen“, ohne zu verstehen, dass dies das Element aus dem Accessibility Tree entfernt, in einigen Fällen einschließlich seiner Kinder. Dies tritt auch häufig bei role="application" auf, wodurch die gesamte Tastatursteuerung an das Widget übertragen und Screenreader-Kurzbefehle deaktiviert werden; dies ist für komplexe Webanwendungen reserviert, nicht für Formulare.

Duplizierte Landmark-Rollen erzeugen Verwirrung: zwei role="main" auf derselben Seite oder ein role="banner" innerhalb eines <article> führen zu einer inkohärenten Regionsnavigation. Die Validierung mit axe-core oder den Barrierefreiheits-Tools des Browsers erkennt viele dieser Fälle, obwohl kein automatisches Tool den Test mit einem echten Screenreader ersetzt.

Einen Blick wert: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

Werkzeuge zur Validierung von Rollen in Ihrem Markup

Die Überprüfung von Rollen kombiniert manuelle Inspektion und Automatisierung. Die DevTools von Chrome und Firefox enthalten ein Accessibility-Panel, das den Baum so anzeigt, wie das Betriebssystem ihn empfängt, mit der berechneten Rolle jedes Knotens. Dies ist der direkteste Weg, um zu sehen, ob eine erklärte Rolle bestehen bleibt oder durch die native Semantik überschrieben wird.

axe-core, integriert in Lighthouse und als Erweiterung verfügbar, markiert ungültige Rollen, fehlende obligatorische Attribute und widersprüchliche Kombinationen. Die Erweiterung Accessibility Insights for Web, basierend auf den axe-Regeln, fügt geführte Prüfungen hinzu. Für Tests mit echten Benutzern bieten NVDA unter Windows und VoiceOver unter macOS die endgültige Verifizierung: Kein Validator erkennt, ob die Ansage im Kontext verständlich ist.

Die Barrierefreiheits-Dokumentation von MDN und der WAI-ARIA-Musterleitfaden des W3C sind die zwei Quellen, die man während der Entwicklung geöffnet haben sollte. Die erste erklärt jede Rolle; die zweite zeigt, wie sie in vollständigen Komponenten kombiniert werden.

Sources & Further Reading

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) is a technical specification published by the World Wide Web Consortium (W3C) that…

Häufig gestellte Fragen

Wie viele ARIA-Rollen gibt es?

Die W3C WAI-ARIA 1.2-Spezifikation definiert insgesamt 82 Rollen, aufgeteilt in Dokument-, Landmark-, Widget-, Struktur-, Fenster- und abstrakte Rollen. In diesem Zusammenhang wird in der üblichen Entwicklung nur ein Bruchteil verwendet: Abstrakte Rollen werden nie geschrieben und viele Dokumentrollen duplizieren native HTML-Elemente.

Was ist der Unterschied zwischen einer ARIA-Rolle und einem ARIA-Attribut?

Eine ARIA-Rolle beschreibt, was ein Element ist, während ARIA-Attribute seinen Zustand oder seine Eigenschaften beschreiben. Zum Beispiel identifiziert role="checkbox" die Komponente und aria-checked="true" kommuniziert, ob sie aktiviert ist. Rollen werden mit dem Attribut role zugewiesen; Zustände und Eigenschaften verwenden das Präfix aria-.

Sollte ich ARIA verwenden, wenn ich bereits semantisches HTML nutze?

In der Mehrheit der Fälle nein. Semantisches HTML stellt bereits implizite Rollen bereit: <nav> entspricht role="navigation" und <main> entspricht role="main". Das explizite Hinzufügen der Rolle ist redundant und kann Konflikte erzeugen. ARIA ist für Komponenten reserviert, die HTML nicht abdeckt, wie Registerkarten, Bäume oder komplexe Menüs.

Welche ARIA-Rollen sollte ich niemals im Markup schreiben?

Abstrakte Rollen sollten niemals erscheinen: command, composite, input, landmark, range, roletype, section, sectionhead, select, structure, widget und window. Sie existieren nur, damit die Spezifikation die Vererbung von Eigenschaften zwischen Rollen definieren kann. Ihr Schreiben erzeugt eine ungültige Rolle, die von Validatoren markiert wird.

Wie überprüfe ich, ob eine ARIA-Rolle korrekt funktioniert?

Die Verifizierung kombiniert drei Schritte: Überprüfung des Accessibility Trees in den DevTools des Browsers, um die berechnete Rolle zu bestätigen, Nutzung eines Validators wie axe-core, um fehlende obligatorische Attribute zu erkennen, und Testen mit einem echten Screenreader wie NVDA oder VoiceOver. Nur der letzte Schritt bestätigt, dass die Ansage für eine Person verständlich ist.

Ändern sich ARIA-Rollen zwischen den Versionen der Spezifikation?

Ja. ARIA 1.1 fügte Rollen wie feed und switch hinzu, und ARIA 1.2 änderte das Verhalten von combobox und konsolidierte andere Werte. ARIA 1.3 befindet sich in der Entwicklung. Die Konsultation der jeweils aktuellen Version der Spezifikation verhindert die Anwendung veralteter Muster, die von modernen Screenreadern anders interpretiert werden.