Das ARIA role-Attribut: Semantik für assistive Technologien
Jedes HTML-Element hat eine implizite Rolle – ein <code><button></code> hat die Rolle „button", ein <code><nav></code> die Rolle „navigation". Das ARIA <code>role</code>-Attribut erlaubt es, diese Semantik zu überschreiben oder nicht-semantischen Elementen eine Bedeutung zu geben. Screenreader und andere assistive Technologien nutzen diese Rollen, um Nutzern den Zweck und die Interaktionsmöglichkeiten eines Elements zu kommunizieren. EN 301 549 Abschnitt 11.4.1.2 verlangt, dass Name, Rolle und Wert aller UI-Komponenten programmatisch bestimmbar sind.
Landmark Roles – Seitenstruktur kommunizieren
Landmark Roles definieren die Hauptbereiche einer Webseite und ermöglichen Screenreader-Nutzern die schnelle Navigation: role="banner" – der Kopfbereich der Seite (implizit bei <header> als direktes Kind von <body>). role="navigation" – Navigationsbereiche (implizit bei <nav>). role="main" – der Hauptinhalt (implizit bei <main>). role="complementary" – ergänzende Inhalte (implizit bei <aside>). role="contentinfo" – der Fußbereich (implizit bei <footer> als direktes Kind von <body>). role="search" – Suchfunktionalität (seit HTML 5.3 auch als <search>-Element). role="form" – ein benanntes Formular (implizit bei <form> mit aria-label oder aria-labelledby). Best Practice: Verwenden Sie bevorzugt die nativen HTML5-Elemente statt expliziter Landmark Roles. WCAG 1.3.1 (Info und Beziehungen) verlangt, dass Strukturinformationen programmatisch verfügbar sind.
Widget Roles – Interaktive Komponenten
Widget Roles beschreiben interaktive UI-Komponenten. Sie werden benötigt, wenn kein passendes natives HTML-Element existiert. Einfache Widget Roles: role="button", role="checkbox", role="link", role="textbox", role="slider", role="switch". Zusammengesetzte Widget Roles: role="tablist" mit role="tab" und role="tabpanel" – für Tab-Interfaces. role="menu" mit role="menuitem" – für Anwendungsmenüs (nicht für Navigationsmenüs!). role="tree" mit role="treeitem" – für Baumstrukturen. role="listbox" mit role="option" – für benutzerdefinierte Auswahllisten. Wichtig: Widget Roles erfordern immer die entsprechende Tastaturinteraktion gemäß WAI-ARIA Authoring Practices. Ein role="tablist" muss Pfeiltasten-Navigation unterstützen. WCAG 2.1.1 (Tastatur) und 4.1.2 (Name, Rolle, Wert) sind hier die maßgeblichen Kriterien.
Document Structure und Abstract Roles
Document Structure Roles beschreiben die inhaltliche Struktur: role="heading" mit aria-level – definiert eine Überschriftsebene. role="list" und role="listitem" – für benutzerdefinierte Listen. role="table", role="row", role="cell" – für benutzerdefinierte Tabellen. role="article" – für eigenständige Inhaltsblöcke. role="definition" und role="term" – für Glossareinträge. role="note" – für Anmerkungen und Hinweise. role="presentation" oder role="none" – entfernt die semantische Bedeutung eines Elements aus dem Accessibility Tree. Abstract Roles wie roletype, widget, command und composite sind Basisrollen der ARIA-Taxonomie und dürfen niemals direkt im HTML verwendet werden. Sie dienen ausschließlich der Spezifikation als Vererbungshierarchie.
Implizite vs. explizite Rollen
HTML-Elemente besitzen implizite ARIA-Rollen, die automatisch gelten: <button> → role="button", <a href="..."> → role="link", <input type="checkbox"> → role="checkbox", <select> → role="listbox" oder role="combobox". Die erste Regel von ARIA lautet: Wenn ein natives HTML-Element mit der richtigen Semantik existiert, verwenden Sie es anstelle eines ARIA-Attributs. Das bedeutet: <button>Senden</button> statt <div role="button" tabindex="0">Senden</div>. Native Elemente bringen Tastaturunterstützung, Fokusverhalten und semantische Informationen von Haus aus mit. Explizite Rollen sind nur dann nötig, wenn das Design ein Custom Control erfordert, für das kein natives Element existiert. WCAG 4.1.2 verlangt in jedem Fall die korrekte Kommunikation von Name, Rolle und Wert – ob implizit oder explizit.
Häufige Fehler und Validierung
1. role="menu" für Navigationsmenüs: role="menu" ist für Anwendungsmenüs gedacht (wie in Desktop-Apps), nicht für Website-Navigation. Verwenden Sie <nav> mit einer Liste von Links. 2. Rollen ohne Tastaturunterstützung: Ein role="button" ohne Enter/Space-Handler ist nutzlos. 3. Rollen-Konflikte: Ein <button role="heading"> erzeugt widersprüchliche Semantik. 4. Fehlende Kinder-Rollen: role="tablist" ohne role="tab"-Kinder ist invalide. 5. role="presentation" auf fokussierbaren Elementen: Browser ignorieren role="presentation" auf Elementen, die fokussierbar sind oder globale ARIA-Attribute haben. Validieren Sie Ihre ARIA-Rollen mit dem W3C ARIA Validator und testen Sie mit einem Screenreader. Die EN 301 549 Tabelle A.1 listet alle relevanten WCAG-Kriterien, die durch korrekte Rollen erfüllt werden.
Wie steht deine Webseite in diesem Punkt da?
Kostenloser Scan gegen 15 WCAG-2.1-AA-Kriterien – inkl. ARIA role-Attribut-Check.
Jetzt Webseite prüfen →