Zum Hauptinhalt springen
Niquelao Web-Barrierefreiheit und Front-End-Entwicklung auf Spanisch: WCAG-Standards, barrierefreie Widgets und Firefox-Erweiterungen, erklärt mit echtem Code.

Einige Links auf dieser Website sind Affiliate-Links: Wenn Sie über diese kaufen, erhalten wir unter Umständen eine Provision, ohne dass für Sie zusätzliche Kosten entstehen. Dies beeinflusst niemals unsere Empfehlungen. Details finden Sie in unserer Affiliate-Offenlegung. Offenlegung der Affiliate-Partnerschaft.

ARIA-Rollen-Spickzettel: Beste Auswahl im Vergleich

Ein ARIA-Roles Cheat Sheet ist eine Referenz, die jede ARIA-Rolle ihrem entsprechenden nativen HTML-Element, ihrer Kategorie (Widget, Landmark, Struktur, Live-Region oder Fenster) sowie den dazugehörigen Eigenschaften und Zuständen zuordnet. WAI-ARIA 1.2 definiert 82 Rollen, wobei die meisten Projekte nur 15 bis 20 davon regelmäßig benötigen. Dieser Vergleich stellt die besten im Jahr 2026 verfügbaren Referenzblätter vor und erklärt, welches je nach Workflow am besten geeignet ist.

Warum ein Cheat Sheet für ARIA-Rollen immer noch notwendig ist

Spezifikationen wie WAI-ARIA 1.2 und deren Nachfolger WAI-ARIA 1.3 sind dichte Dokumente, die für Browser-Implementierer und Entwickler von assistiven Technologien geschrieben wurden, nicht für jemanden, der an einem Dienstagnachmittag ein Formular erstellt. Die erste Regel von ARIA — immer natives HTML zu verwenden, sofern es existiert — löst die meisten Fälle, aber es gibt Muster, für die es kein natives Äquivalent gibt: Tabs, Bäume, interaktive Grids, Comboboxen mit Autovervollständigung, Menüs mit Untermenüs. Hier spart ein Referenzblatt Zeit und vermeidet vor allem Fehler.

Der häufigste Fehler ist nicht das Vergessen einer Rolle, sondern das Hinzufügen einer unnötigen. Ein <button> mit role="button" bringt keinen Mehrwert und kann das native Verhalten in einigen Screenreadern beeinträchtigen. Ein gut gemachtes Cheat Sheet markiert explizit, welche Rollen auf nativen Elementen redundant sind, welche Rollen eine Fokusverwaltung per JavaScript erfordern und welche Attribute obligatorisch gegenüber optionalen sind.

Der zweite Grund ist die Verifizierung. Rollen haben Eigenschaftsbeziehungen: aria-labelledby verweist auf eine id, aria-activedescendant setzt voraus, dass das referenzierte Element existiert und sichtbar ist, aria-owns ist nur gerechtfertigt, wenn die DOM-Reihenfolge nicht mit der visuellen Reihenfolge übereinstimmt. Eine Tabelle, die Rollen, erforderliche Attribute und verbotene Attribute gegenüberstellt, erkennt Fehler, bevor sie in einem Audit auffallen.

Was ein gutes ARIA-Roles Cheat Sheet enthalten sollte

Ein nützliches Referenzblatt für die Front-End-Entwicklung erfüllt fünf Kriterien. Ich liste sie auf, da dies genau die Kriterien sind, die ich zur Bewertung der Optionen in diesem Vergleich verwendet habe.

  • Abdeckung aller fünf Rollenkategorien. WAI-ARIA gruppiert Rollen in Zusammenfassungen, Widgets, Dokumentstruktur, Landmarks und Live-Regionen. Zusammenfassungen (roletype, widget, input) werden im Framework nicht direkt verwendet; ein guter Verweis auf sichtbare Formdaten ist essenziell.
  • Natives HTML-Äquivalent für die Rolle. Ohne diese Spalte regt die Referenz dazu an, ARIA dort einzusetzen, wo es nicht nötig wäre.
  • Erforderliche, unterstützte und verbotene Attribute. role="checkbox" erfordert aria-checked; role="heading" erfordert aria-level; role="presentation" ist nicht erlaubt.
  • Zugehöriges Tastaturmuster. Eine Rolle ohne Tastaturverwaltung ist ein leeres Versprechen. role="tablist" impliziert die Steuerung über Pfeiltasten, Home und End.
  • Durchsuchbares Format. Suchfunktion, Filter nach Kategorie, Spezifikationsversion und die Möglichkeit, Codefragmente zu kopieren.

Vergleich: Die besten ARIA-Rollen-Referenzen im Jahr 2026

Die folgende Tabelle fasst die solidesten Optionen zusammen. Keine davon ist kostenpflichtig; alle werden aktiv gepflegt und geben die Version der Spezifikation an, die sie abdecken.

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

RessourceAnsatzAbgedeckte KategorienNatives ÄquivalentTastaturmusterIdeal für
WAI-ARIA Authoring Practices Guide (APG), W3CVollständige Muster mit BeispielenWidgets, Landmarks, Struktur, Live-RegionsJa, in jedem MusterJa, detailliertImplementierung eines konkreten Widgets
MDN Web Docs, ARIA-Rollen-ReferenzSteckbrief pro RolleAlle, inklusive abstrakteJaTeilweiseNachschlagen einer einzelnen Rolle
ARIA Authoring Practices, RollenindexTabelle Rolle $\rightarrow$ AttributeWidgets und StrukturTeilweiseNeinÜberprüfung erforderlicher Attribute
Deque University, ARIA referenceSteckbriefe mit Support-NotizenWidgets und LandmarksJaTeilweiseKenntnis des realen Screenreader-Supports
A11Y Project ChecklistChecklisteÜbergreifendNicht anwendbarNeinAudit vor der Veröffentlichung
HTML-ARIA (W3C), ÄquivalenztabelleErlaubte Rolle pro ElementAlleJa, das ist der ZweckNeinEntscheidung, ob ARIA notwendig ist

WAI-ARIA Authoring Practices Guide (APG)

Die APG des W3C ist die kanonische Referenz für Muster. Jedes Muster enthält die HTML-Struktur, Rollen, Zustände, Tastaturinteraktion und ein funktionales Beispiel. Ihr Stärke liegt darin, dass sie nicht nur Rollen auflistet, sondern das erwartete Verhalten erklärt. Ihr Schwachpunkt ist, dass sie keine schnelle Tabelle ist; um zu prüfen, „welche Attribute role="slider" benötigt“, muss man zum entsprechenden Muster navigieren.

Die APG gruppiert die häufigsten Widgets: Accordion, Alert, Breadcrumb, Button, Checkbox, Combo Box, Dialog, Disclosure, Feed, Grid, Link, List Box, Menu, Menu Bar, Radio Group, Slider, Rotary Knob, Switch, Table, Tab List, Toolbar, Tooltip, Grid Tree und Tree View. Wenn Ihr Projekt eines davon verwendet, ist dies die richtige Quelle.

MDN Web Docs: Die Referenz pro Rolle

MDN pflegt eine Seite für jede ARIA-Rolle mit Beschreibung, erforderlichen Attributen, zulässigen Attributen, damit verbundenen Barrierefreiheits-Problemen und Links zur Spezifikation. Dies ist die schnellste Option, wenn man weiß, wonach man sucht. Die Abdeckung umfasst abstrakte Rollen und in Gebrauch befindliche Rollen, obwohl einige Details weggelassen werden.

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

Ein praktisches Detail: MDN markiert, welche Rollen veraltet sind oder in zukünftigen Versionen der Spezifikation entfernt werden könnten. Diese Markierung zu beachten, verhindert die Einführung einer Rolle, die bald verschwinden wird.

HTML-ARIA: Die Tabelle, die unnötiges ARIA vermeidet

Die HTML-ARIA-Spezifikation des W3C definiert für jedes HTML-Element, welche ARIA-Rollen angewendet werden können und welche redundant sind. Dies ist das entscheidende Werkzeug, wenn man zwischen einem nativen Element oder einem div mit Rolle schwankt. Wenn die gewünschte Rolle für dieses Element als redundant aufgeführt ist, lautet die Antwort: nicht hinzufügen.

Deque University und A11Y Project

Deque University bietet Rollen-Steckbriefe mit Notizen zum realen Support in Screenreadern, etwas, das die Spezifikation nicht abdeckt, da dies nicht ihr Auftrag ist. Die A11Y Project Checklist ist kein Cheat Sheet für Rollen, funktioniert aber als Checkliste vor der Veröffentlichung und ergänzt die anderen Quellen gut.

Wie Sie je nach Fall wählen

Die Entscheidung hängt von drei Fragen ab. Erstens: Wissen Sie bereits, welche Rolle Sie benötigen? Wenn ja, ist MDN der kürzeste Weg. Zweitens: Bauen Sie ein Widget mit komplexer Interaktion? Dann benötigen Sie die APG, da die Rolle allein das Tastaturverhalten nicht beschreibt. Drittens: Zweifeln Sie zwischen nativem HTML und ARIA? Konsultieren Sie HTML-ARIA vor jeder anderen Quelle.

Für Teams, die mit XHTML und CSS ohne Frameworks arbeiten, ist die effizienteste Kombination meist: HTML-ARIA zur Entscheidung, APG zur Implementierung und MDN zur Überprüfung der Attribute. Ein einseitiges Cheat Sheet dient als Kurzzeitgedächtnis, ersetzt aber nicht diese drei Quellen bei Grenzfallen.

Ein zusätzliches Kriterium: Wenn eine Rolle JavaScript erfordert, um korrekt zu funktionieren (Fokusverwaltung, Aktualisierung von aria-expanded, Synchronisation von aria-selected), behandeln Sie dies als Architekturentscheidung, nicht als dekoratives Attribut. Widget-Rollen ohne die zugehörige Logik schaffen mehr Barrieren als das Fehlen einer Rolle.

Verwandte: — Die erfordert Erfahrung und Zugang.

Häufige Fehler, die kein Cheat Sheet allein verhindert

Doppelte Landmark-Rollen verwirren die Navigation durch Regionen. Ein role="main" auf einem <main> ist redundant; zwei role="navigation" ohne unterscheidendes Label sind mehrdeutig. Die Lösung ist aria-label oder aria-labelledby bei jedem wiederholten Landmark.

Widget-Rollen auf nicht fokussierbaren Elementen unterbrechen die Interaktion. role="button" auf einem <div> erfordert tabindex="0" sowie die Behandlung von Enter und Leertaste. Ohne dies kündigt die Rolle einen Button an, der nicht per Tastatur aktiviert werden kann.

Nicht synchronisierte Zustände sind die häufigste Ursache für Barrieren. Ein aria-expanded, das sich nicht ändert, wenn ein Akkordeon geöffnet wird, ein aria-selected, das sich nicht aktualisiert, wenn der Tab wechselt, oder ein statisches aria-checked in einer role="switch". Keine Tabelle erkennt dies: Es ist ein Test mit der Tastatur und einem echten Screenreader erforderlich.

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

Die Verwendung abstrakter Rollen im Markup ist grundsätzlich ein Fehler. role="widget", role="input" oder role="section" dürfen nicht im HTML erscheinen; sie existieren nur für die Hierarchie der Spezifikation.

Key Takeaways

  • WAI-ARIA 1.2 definiert 82 Rollen, aber die meisten Projekte nutzen nur 15 bis 20 davon regelmäßig.
  • Die erste Regel von ARIA — natives HTML verwenden, wenn vorhanden — macht die HTML-ARIA-Tabelle des W3C zur wichtigsten Referenz vor dem Schreiben jeder Rolle.
  • Die APG des W3C ist unübertroffen für Widget-Muster, da sie die Tastaturinteraktion enthält; MDN ist schneller für die Abfrage einer konkreten Rolle.
  • Eine Rolle ohne Fokusverwaltung und Zustandsaktualisierung erzeugt mehr Barrieren als der Verzicht auf ARIA.
  • Kein Cheat Sheet ersetzt den Test mit Tastatur und Screenreader: Desynchronisierte Zustände werden nur im realen Gebrauch erkannt.

Häufig gestellte Fragen

Wie viele ARIA-Rollen gibt es?

WAI-ARIA 1.2 definiert 82 Rollen, aufgeteilt in fünf Kategorien: abstrakt, Widgets, Dokumentstruktur, Landmarks und Live-Regions. Abstrakte Rollen werden niemals im Markup angewendet; sie dienen der Organisation der Spezifikationshierarchie. In der Praxis verwendet ein typisches Projekt zwischen 15 und 20 verschiedene Rollen.

Welches ist das beste ARIA-Roles Cheat Sheet?

Das hängt von der Nutzung ab. Für die Implementierung eines Widgets mit Tastatursteuerung ist die WAI-ARIA Authoring Practices Guide des W3C die vollständigste Referenz. Zum Nachschlagen der Attribute einer konkreten Rolle ist MDN Web Docs schneller. Um zu entscheiden, ob eine Rolle auf einem HTML-Element notwendig ist, ist die HTML-ARIA-Tabelle des W3C die entscheidende Quelle.

Sollte ich ARIA verwenden, wenn es ein natives HTML-Element gibt?

Nein. Die erste Regel von ARIA besagt, dass wenn ein HTML-Element mit der benötigten Semantik und dem Verhalten existiert, dieses Element anstelle eines div mit Rolle verwendet werden soll. Das Hinzufügen von role="button" zu einem <button> ist redundant und kann das native Verhalten in einigen Screenreadern verändern.

Was ist der Unterschied zwischen einer Widget-Rolle und einer Landmark-Rolle?

Widget-Rollen beschreiben interaktive Steuerelemente — button, checkbox, slider, tablist — und erfordern Fokus- und Tastaturverwaltung. Landmark-Rollen beschreiben Regionen der Seite — main, navigation, banner, contentinfo — und dienen der Navigation durch Regionen. Ein Element sollte nicht beide Funktionen gleichzeitig erfüllen.

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

Ja. WAI-ARIA 1.2 fügte Rollen wie blockquote, caption, code, deletion, emphasis, insertion, meter, paragraph, strong, subscript und superscript hinzu. Einige Rollen sind in späteren Versionen veraltet. Es empfiehlt sich, in MDN oder in der Spezifikation selbst zu prüfen, ob eine Rolle noch aktuell ist, bevor man sie übernimmt.

Reicht ein ARIA-Roles Cheat Sheet aus, um WCAG zu erfüllen?

Nein. ARIA-Rollen sind nur ein Teil des Kriteriums 4.1.2 (Name, Rolle, Wert), aber WCAG 2.2 umfasst viele weitere Anforderungen: Kontrast, sichtbarer Fokus, Zielgröße, Alternativtexte, Überschriftenstruktur. Ein Cheat Sheet hilft dabei, Rollen korrekt zu implementieren, aber nicht dabei, die Gesamtheit der Konformitätskriterien zu erfüllen.

Sources & Further Reading

  • Cheat sheet — Wikipedia: A cheat sheet (also cheatsheet) or crib sheet or job aid is a concise set of notes used for quick reference. Cheat sheets were historically used by students without…

In 5 Minuten zugänglich

Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können