ARIA-Rollen-Beispiele: Ein vollständiger Leitfaden

Die ARIA-Rollenbeispiele zeigen, wie Rollen-Attribute Oberflächenelemente dem Accessibility Tree zuordnen, und die WAI-ARIA 1.2-Spezifikation definiert 6 Rollenkategorien – Widget, Dokumentstruktur, Landmark, Live-Region, Fenster und Abstract –, die mehr als 80 konkrete Rollen abdecken. Dieser Leitfaden präsentiert kopierfertige praktische Beispiele für jede Kategorie sowie die Regeln, die bestimmen, wann eine Rolle hilft und wann sie aktiv schadet.

Wichtige Erkenntnisse

• ARIA-Rollen sagen der assistiven Technologie, was ein Element ist; sie fügen niemals von alleine Verhalten, Fokus oder Tastaturunterstützung hinzu.
• Die erste Regel bei der Verwendung von ARIA ist, native HTML-Elemente zu bevorzugen, die bereits implizite Rollen, Zustände und eine Tastaturverwaltung mitbringen.
• Die sechs WAI-ARIA 1.2 Rollenkategorien sind Widget, Dokumentstruktur, Landmark, aktive Region, Fenster und Zusammenfassung — abstrakte Rollen sollten niemals in Ihrem Markup erscheinen.
• Landmark-Rollen sind die kosteneffizientesten und risikoärmsten ARIAs, die Sie einer bestehenden XHTML/CSS-Seite hinzufügen können.
• Widget-Rollen erfordern fast immer eine JavaScript-Zuordnung für die Tastaturinteraktion und Statusbehandlung, andernfalls schaffen sie eine schlechtere User Experience als einfaches HTML.
• Validieren Sie jede Rolle mit einem Screenreader und einem automatisierten Checker; eine in der Spezifikation gültige Rolle kann für Ihren Inhalt dennoch falsch sein.

Was ARIA-Rollen tatsächlich tun

ARIA-Rollen sind Token, die Sie im role-Attribut platzieren, um die semantische Identität eines Elements im Accessibility Tree zu ersetzen oder bereitzustellen. Ein <div role="button"> weist einen Screenreader an, „Button“ anzukündigen, aber der Browser behandelt es immer noch als generischen Container: Es ist nicht fokussierbar, reagiert nicht auf Enter oder Leertaste und hat keinen deaktivierten Zustand.

Diese Lücke zwischen beworbener Semantik und tatsächlichem Verhalten ist die häufigste Ursache für ARIA-Fehler. Dies sind gängige ARIA-Rollenbeispiele dafür, wie Semantik vom Verhalten abweichen kann.

Die WAI-ARIA-Spezifikation, die von der Accessible Rich Internet Applications Working Group des W3C gepflegt wird, definiert Rollen sowie Zustände und Eigenschaften. Rollen sind die „Was ist es“-Ebene; Zustände und Eigenschaften wie aria-expanded, aria-checked und aria-label sind die „In welchem Zustand befindet es sich“-Ebene. Eine Rolle ohne ihre erforderlichen Zustände ist unvollständig — role="checkbox" erfordert aria-checked und role="combobox" erfordert aria-expanded plus eine gesteuerte Listbox.

Native HTML-Elemente tragen implizite Rollen. <button> entspricht der Button-Rolle, <nav> der Navigation, <h1> bis <h6> der Überschrift und <input type="checkbox"> dem Kontrollkästchen. Da der Browser automatisch die Rolle, das Tastaturverhalten und den Zustand bereitstellt, besteht die erste Regel für die Verwendung von ARIA — dokumentiert im ARIA Authoring Practices Guide des W3C — darin, native Semantik zu verwenden, wann immer ein gleichwertiges Element existiert. Suchen Sie nur dann nach expliziten Rollen, wenn kein natives Element geeignet ist, wie etwa bei einer benutzerdefinierten Baumansicht oder einem Tab-Panel, das aus <div>-Elementen aufgebaut ist.

Die sechs WAI-ARIA-Rollenkategorien

WAI-ARIA 1.2 organisiert Rollen in sechs Kategorien, und wenn Sie wissen, welcher Kategorie eine Rolle angehört, wissen Sie, wie viel JavaScript Sie dafür implementieren müssen. Hier sind einige gängige ARIA-Rollenbeispiele:

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

Kategorie	Zweck	Beispielrollen	JavaScript erforderlich?
Widget	Interaktive Steuerelemente	button, checkbox, tab, slider, combobox	Ja — Tastatur + Zustand
Dokumentstruktur	Inhaltsorganisation	heading, list, listitem, table, article	Nein
Landmark	Seitenbereiche zur Navigation	banner, main, navigation, complementary	Nein
Live-Region	Dynamische Updates ankündigen	alert, status, log, timer	Meistens — um Updates auszulösen
Fenster	Unterfenster und Dialoge	dialog, alertdialog	Ja — Fokusverwaltung
Abstract	Superklassen-Rollen, nie im Code verwendet	widget, input, section, landmark	N/A — nicht verwenden

Abstrakte Rollen existieren nur, um die Taxonomie zu organisieren. Das Schreiben von role="input" oder role="section" in Ihrem HTML ist ein Validierungsfehler und führt zu unvorhersehbaren Ansagen, da diese Rollen kein definiertes Verhalten für assistive Technologien haben.

Landmark-Rollenbeispiele

Landmark-Rollen sind die sichersten und wirkungsvollsten ARIA-Rollenbeispiele, die Sie einer älteren XHTML/CSS-Seite hinzufügen können, da sie kein JavaScript benötigen und direkt auf Regionen mappen, die Sie bereits haben. Ein typisches Seitenskelett:

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

Jede Landmark-Rolle entspricht einem nativen Element — banner zu <header> auf der obersten Ebene, main zu <main>, navigation zu <nav>, complementary zu <aside>, contentinfo zu <footer>. Wenn Sie das native Element verwenden, ist die Rolle impliziert und Sie sollten sie nicht wiederholen. Das explizite role-Attribut ist nur dann gerechtfertigt, wenn Sie an ein <div>-Markup gebunden sind, das Sie nicht ändern können, was bei älteren Templates und CMS-Ausgaben häufig vorkommt.

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

Zwei Vorbehalte sind hier angebracht. Erstens müssen banner, main und contentinfo nur einmal pro Seite erscheinen; mehrere main-Landmarks stören die Navigation. Zweitens: Wenn mehrere Landmarks desselben Typs existieren – sagen wir drei <nav>-Elemente – geben Sie jedem ein separates aria-label, damit Screenreader-Nutzer sie in der Landmark-Liste unterscheiden können. Ein nicht beschriftetes nav wird genauso angekündigt wie seine Geschwister, was den Zweck zunichte macht.

Widget-Rollenbeispiele

Bei Widget-Rollen wird ARIA gleichermaßen mächtig wie gefährlich. Jede Widget-Rolle hat einen impliziten Vertrag: spezifische Tastaturtasten, spezifische Zustände und ein spezifisches Fokusverhalten. Der ARIA Authoring Practices Guide veröffentlicht das vollständige Muster für jede Rolle. Diese ARIA-Rollenbeispiele illustrieren die damit verbundene Komplexität.

Ein Toggle-Button benötigt beispielsweise aria-pressed, um seinen Ein-/Aus-Zustand zu kommunizieren:

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

Das <button>-Element liefert die Rolle, den Fokus und die Enter/Leertaste-Handhabung; JavaScript schaltet lediglich aria-pressed zwischen "false" und "true" um. Dies ist die ideale Form der ARIA-Nutzung — natives Element, minimales ARIA, kleines Skript.

Eine benutzerdefinierte Tab-Schnittstelle aus <div>-Elementen ist der gegenteilige Fall. Sie benötigt role="tablist" am Container, role="tab" für jeden Tab, role="tabpanel" für jedes Panel, aria-selected für den aktiven Tab, aria-controls zur Verknüpfung von Tab und Panel sowie die Pfeiltasten-Navigation zwischen den Tabs.

Wenn Sie eines davon vergessen, kündigt sich das Widget als Tabs an, verhält sich aber wie statischer Text. Das Gleiche gilt für role="slider" (erfordert aria-valuenow, aria-valuemin, aria-valuemax und Pfeiltasten), role="combobox" (erfordert aria-expanded und eine gesteuerte Listbox) und role="tree" (erfordert aria-expanded und vollständige Pfeiltasten-Traversal).

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

Eine nützliche Entscheidungsregel: Wenn es ein natives Element gibt, das den Job erledigt — <button>, <input type="checkbox">, <select>, <details> — verwenden Sie es und ignorieren Sie die Widget-Rolle vollständig. Reservieren Sie benutzerdefinierte Widget-Rollen für wirklich neuartige Steuerelemente und planen Sie das JavaScript für die vollständige Tastatursteuerung ein, bevor Sie live gehen.

Beispiele für Dokumentstruktur und Live-Regionen

Dokumentstruktur-Rollen beschreiben Inhaltsbeziehungen, wenn native Elemente nicht verfügbar sind. Diese ARIA-Rollenbeispiele beinhalten role="heading" mit aria-level, was die klassische Rettung für ein gestyltes <div> ist, das als Überschrift fungiert:

<div role="heading" aria-level="2">Novedades del mes</div>

Das Attribut aria-level ist hier obligatorisch — eine Überschriftenrolle ohne Level wird ohne Rang angekündigt, was die Dokumentengliederung zerstört. Ähnlich stellen role="list" und role="listitem" die Listen-Semantik wieder her, wenn CSS wie list-style: none oder ein Flex-Container sie in einigen Browsern entfernt, und role="table", role="row", role="columnheader" und role="cell" bauen eine Datentabelle aus <div>-Markup auf. In der Praxis erfordert die Umstrukturierung in tatsächliche <ul>, <ol> und <table>-Elemente fast immer weniger Arbeit als die Pflege eines vollständigen Satzes von Strukturrollen.

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

Live-Region-Rollen kündigen sich ändernde Inhalte ohne Neuladen der Seite an. role="alert" unterbricht den Screenreader sofort und ist für Fehlermeldungen und dringende Benachrichtigungen gedacht; role="status" wartet höflich und ist für Bestätigungen wie „Guardado“ geeignet; role="log" passt zu Chat- und Aktivitätsfeeds; role="timer" entspricht Countdowns. Das kritische Detail ist, dass der Live-Region-Container im DOM existieren muss, bevor sich der Inhalt ändert — das gleichzeitige Einfügen eines neuen Elements mit role="alert" und dessen Text führt oft zu keiner Ansage, da die Region nicht vorhanden war, um überwacht zu werden. Erstellen Sie beim Laden der Seite ein leeres <div role="status"> und aktualisieren Sie später dessen Text.

Häufige ARIA-Rollenfehler

Redundante Rollen stehen an erster Stelle. Diese ARIA-Rollenbeispiele, wie <button role="button"> und <nav role="navigation">, fügen nichts hinzu und überladen das Markup; die implizite Rolle existiert bereits. Die gleiche Redundanz tritt auf, wenn Entwickler role="heading" zu einem <h2> hinzufügen.

Fehlende erforderliche Zustände kommen an zweiter Stelle. role="checkbox" ohne aria-checked, role="slider" ohne aria-valuenow und role="combobox" ohne aria-expanded führen zu unvollständigen Ansagen, die Nutzer irreführen. Die Spezifikation listet die erforderlichen Zustände und Eigenschaften für jede Rolle auf, und automatisierte Checker markieren deren Fehlen.

Der Rollenmissbrauch am falschen Element steht an dritter Stelle. Das Setzen von role="button" auf ein <a href> überschreibt die Link-Semantik und bricht das erwartete Verhalten, wie das Öffnen in einem neuen Tab.

Das Setzen von role="presentation" oder role="none" auf ein fokussierbares Element entfernt dessen Semantik, lässt es aber in der Tab-Reihenfolge, wodurch ein fokussierbares Element ohne angekündigte Identität entsteht. Und die Verwendung abstrakter Rollen wie role="widget" oder role="input" ist immer ein Fehler.

Schließlich können ARIA-Rollen einen kaputten DOM nicht reparieren. Ein role="tabpanel", das in seinem eigenen role="tab" verschachtelt ist, erzeugt einen unsinnigen Baum, egal wie viele Attribute Sie hinzufügen. Reparieren Sie zuerst die Struktur und legen Sie dann ARIA darüber.

So testen Sie ARIA-Rollen

Das Testen von ARIA-Rollen erfordert mehrere Methoden, da automatisierte Tools zwar Validierungsfehler, aber keine semantischen Diskrepanzen erkennen. Beginnen Sie mit einem Accessibility-Checker — axe DevTools, WAVE oder Lighthouse —, um ungültige Rollen, fehlende erforderliche Attribute und abstrakte Rollen in Ihrem Markup zu finden. Diese Tools sind schnell und erkennen mechanische Fehler.

Folgen Sie dies mit einem Durchgang mit Screenreadern. NVDA mit Firefox unter Windows, JAWS mit Chrome und VoiceOver mit Safari unter macOS stellen den Accessibility Tree jeweils unterschiedlich dar, und eine Rolle, die in einem korrekt angekündigt wird, tut dies in einem anderen möglicherweise nicht. Navigieren Sie per Landmark und per Überschrift, um zu bestätigen, dass Ihre Strukturrollen die erwartete Gliederung erzeugen, und tabben Sie dann durch jedes Widget, um zu prüfen, ob die angekündigte Rolle, der Zustand und das Tastaturverhalten übereinstimmen.

Inspizieren Sie den Accessibility Tree direkt in den Chrome- oder Firefox-DevTools, wo das „Accessibility“-Panel die berechnete Rolle und den Namen eines beliebigen Elements anzeigt. Dies offenbart die Lücke zwischen der von Ihnen geschriebenen Rolle und der Rolle, die der Browser tatsächlich ausgibt — der schnellste Weg, um eine Rolle zu erkennen, die von einem Elternteil überschrieben oder vollständig ignoriert wird.

Quellen & Weiterführende Literatur

• WAI-ARIA — Wikipedia: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) ist eine vom World Wide Web Consortium (W3C) veröffentlichte technische Spezifikation, die…

Häufig gestellte Fragen

Was sind ARIA-Rollen und wie funktionieren sie?

ARIA-Rollen sind Werte im role-Attribut, die die Identität eines Elements im Accessibility Tree definieren, damit Screenreader es korrekt ankündigen. Sie ändern nur die Semantik, nicht das Aussehen, den Fokus oder das Tastaturverhalten. Die WAI-ARIA 1.2-Spezifikation definiert sechs Rollenkategorien und mehr als 80 konkrete Rollen, jeweils mit erforderlichen Zuständen und Eigenschaften.

Wann sollte ich ARIA-Rollen anstelle von nativem HTML verwenden?

Verwenden Sie ARIA-Rollen nur, wenn kein natives HTML-Element die benötigte Semantik bereitstellt. Native Elemente wie <button>, <nav> und <input type="checkbox"> bringen implizite Rollen sowie integrierte Tastaturunterstützung und Zustandsverwaltung mit. Die erste Regel der ARIA-Nutzung ist, native Semantik zu bevorzugen und explizite Rollen nur für benutzerdefinierte Widgets oder Legacy-Markup hinzuzufügen, das Sie nicht umstrukturieren können.

Was ist der Unterschied zwischen ARIA-Rollen und ARIA-Attributen?

ARIA-Rollen beantworten die Frage „Was ist dieses Element“, während ARIA-Attribute wie aria-expanded, aria-checked und aria-label beantworten, „in welchem Zustand befindet es sich“ oder „wie heißt es“. Die Rollen und ihre erforderlichen Attribute arbeiten zusammen: Als ARIA-Rollenbeispiel ist role="checkbox" ohne aria-checked unvollständig, und role="combobox" benötigt aria-expanded plus eine gesteuerte Listbox.

Kann ich ARIA-Rollen auf jedem HTML-Element verwenden?

ARIA-Rollen können auf die meisten Elemente angewendet werden, aber einige Kombinationen sind ungültig oder schädlich. Abstrakte Rollen wie widget und input sollten niemals im Code verwendet werden. Die Änderung der Rolle eines Links zu role="button" bricht das erwartete Verhalten des Links, und role="presentation" an einem fokussierbaren Element entfernt dessen Semantik, während es in der Tab-Reihenfolge bleibt.

Funktionieren ARIA-Rollen ohne JavaScript?

Dokumentstruktur und Landmark-Rollen funktionieren ohne JavaScript, da sie nur die Semantik ändern. Widget-Rollen wie tab, slider und combobox erfordern JavaScript, um die Tastaturinteraktion zu implementieren und Zustände zu aktualisieren — ohne dieses kündigt sich das Element als Steuerelement an, verhält sich aber nicht wie eines, was schlimmer ist als einfaches HTML.

Wie überprüfe ich, ob meine ARIA-Rollen korrekt sind?

Kombinieren Sie automatisierte und manuelle Tests. Führen Sie axe DevTools, WAVE oder Lighthouse aus, um ungültige Rollen und fehlende erforderliche Attribute zu erkennen, und testen Sie dann mit NVDA, JAWS und VoiceOver, um Ansagen und Tastaturverhalten zu bestätigen. Das Bedienfeld „Barrierefreiheit“ (Accessibility) in den Chrome- und Firefox-DevTools zeigt die berechnete Rolle an und macht so deutlich, welche Rollen der Browser überschreibt oder ignoriert.