Verständnis von Accessibility-Rollen in HTML

Accessibility-Rollen teilen assistiven Technologien mit, was ein Element ist, nicht wie es aussieht. Wenn ein Screenreader auf einen Button trifft, muss er wissen, dass es sich um einen Button handelt – egal ob es sich um ein natives <button>-Element oder eine benutzerdefinierte Komponente mit role="button" handelt. Wenn Sie dies falsch machen, können Millionen von Nutzern Ihre Benutzeroberfläche nicht effektiv bedienen.

Dieser Leitfaden erklärt, wie Accessibility-Rollen in den umfassenderen Accessibility-Tree passen, wann ARIA-Rollen gegenüber semantischem HTML verwendet werden sollten und welche Best Practices Ihren Code sowohl zugänglich als auch wartbar halten.

Wie Rollen im Accessibility-Tree funktionieren

Jede Webseite hat zwei Bäume: den DOM-Baum, den Sie kennen, und den Accessibility-Tree, den assistive Technologien tatsächlich auslesen. Der Accessibility-Tree folgt einem einfachen Modell: Jedes Element hat einen Namen, eine Rolle und einen Wert/Zustand.

<!-- DOM-Element -->
<button aria-pressed="true">Mute</button>

<!-- Accessibility-Tree-Darstellung -->
Name: "Mute"
Role: button
Value/State: pressed=true

Der Browser erstellt diesen Accessibility-Tree automatisch aus Ihrem HTML und ordnet semantische Elemente ihren impliziten Rollen zu. Ein <nav>-Element wird zu einem Navigation-Landmark, ein <button> zu einem Button-Widget. ARIA-Rollen ermöglichen es Ihnen, diesen Baum zu modifizieren, wenn natives HTML nicht ausreicht – aber sie sollten Ihr letzter Ausweg sein, nicht Ihre erste Wahl.

Die vier Hauptkategorien von Rollen

Landmark-Rollen

Landmark-Rollen definieren Seitenbereiche für die Navigation. Modernes HTML5 bietet die meisten davon nativ:

• <header> → banner-Rolle (wenn nicht innerhalb von <article> oder <section>)
• <nav> → navigation-Rolle
• <main> → main-Rolle
• <aside> → complementary-Rolle
• <footer> → contentinfo-Rolle (wenn nicht innerhalb von <article> oder <section>)

Best Practice: Verwenden Sie semantische HTML-Elemente anstelle von <div role="navigation">. Die Redundanz von <nav role="navigation"> bringt keinen Mehrwert – das Element hat diese Rolle bereits implizit.

Widget-Rollen

Widget-Rollen beschreiben interaktive Steuerelemente. Diese sind entscheidend für benutzerdefinierte Komponenten, die keine nativen Elemente verwenden können:

<!-- Gut: Benutzerdefinierte Tab-Oberfläche -->
<div role="tablist">
  <button role="tab" aria-selected="true">Einstellungen</button>
  <button role="tab" aria-selected="false">Profil</button>
</div>

<!-- Schlecht: Unnötiges ARIA -->
<button role="button">Klick mich</button> <!-- Redundant -->

Document-Structure-Rollen

Diese Rollen beschreiben die Inhaltsorganisation: Überschriften, Listen, Artikel und Trennelemente. Auch hier gilt: Bevorzugen Sie semantisches HTML:

<!-- Bevorzugen Sie dies -->
<article>
  <h2>Artikeltitel</h2>
</article>

<!-- Gegenüber diesem -->
<div role="article">
  <div role="heading" aria-level="2">Artikeltitel</div>
</div>

Abstrakte Rollen

Abstrakte Rollen wie command oder composite sind grundlegende Vorlagen in WAI-ARIA. Verwenden Sie diese niemals direkt – sie existieren nur, damit die Spezifikation andere Rollen definieren kann.

Moderne Best Practices für ARIA-Rollen

Bevorzugen Sie zuerst semantisches HTML

Die erste Regel von ARIA lautet: Verwenden Sie kein ARIA. Native HTML-Elemente verfügen über integrierte Tastaturunterstützung, Fokusverwaltung und Accessibility-Semantik:

<!-- Bevorzugen Sie immer dies -->
<button onclick="submit()">Absenden</button>

<!-- Gegenüber diesem Anti-Pattern -->
<div role="button" tabindex="0" onclick="submit()">Absenden</div>

Die <div>-Version erfordert zusätzliches JavaScript für Tastaturunterstützung, Fokus-Styling und ordnungsgemäße Aktivierung – Arbeit, die der native Button automatisch erledigt.

Vermeiden Sie redundante Landmark-Rollen

Seit HTML5 ist das Hinzufügen expliziter Rollen zu semantischen Elementen unnötig und kann Verwirrung stiften:

<!-- Tun Sie dies nicht -->
<main role="main">
<nav role="navigation">
<header role="banner">

<!-- Diese Elemente haben bereits implizite Rollen -->
<main>
<nav>
<header>

Überschreiben Sie niemals native interaktive Rollen

Das Ändern der Rolle eines Buttons bricht sein erwartetes Verhalten:

<!-- Tun Sie dies niemals -->
<button role="heading">Abschnittstitel</button>

<!-- Dies zerstört die Tastaturinteraktion und die Erwartungen von Screenreadern -->

Wann benutzerdefinierte Rollen sinnvoll sind

Benutzerdefinierte Komponenten benötigen manchmal tatsächlich ARIA-Rollen. Hier sind gültige Anwendungsfälle:

Benutzerdefiniertes Dialog-Pattern

<div role="dialog" aria-labelledby="dialog-title" aria-modal="true">
  <h2 id="dialog-title">Aktion bestätigen</h2>
  <button>Abbrechen</button>
  <button>Bestätigen</button>
</div>

Benutzerdefinierte Tab-Oberfläche

<div role="tablist" aria-label="Benutzereinstellungen">
  <button role="tab" aria-selected="true" aria-controls="panel-1">Allgemein</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">Datenschutz</button>
</div>
<div role="tabpanel" id="panel-1">Allgemeine Einstellungen</div>

Umgang mit Beschreibungen und Labels

Für zugängliche Namen und Beschreibungen folgen Sie dieser Hierarchie:

1. Sichtbarer Text (am besten für alle Nutzer)
2. aria-labelledby (verweist auf sichtbaren Text an anderer Stelle)
3. aria-describedby (fügt ergänzende Informationen hinzu)
4. aria-label (wenn sichtbarer Text nicht möglich ist)

<button aria-describedby="help-text">Löschen</button>
<span id="help-text">Diese Aktion kann nicht rückgängig gemacht werden</span>

Hinweis: aria-description ist in WAI-ARIA 1.3 im Entstehen, hat aber begrenzte Unterstützung. Bleiben Sie bei aria-describedby für Produktionscode.

Häufige Anti-Patterns, die Sie vermeiden sollten

Div-basierte Buttons: Erstellen von <div role="button">, wenn <button> perfekt funktioniert
Role-Überflutung: Hinzufügen von Rollen zu jedem Element „für alle Fälle”
Widersprüchliche Semantik: <h2 role="button"> vermischt Struktur und Interaktion
Redundante Rollen: <nav role="navigation"> bringt keinen Mehrwert

Testen Ihrer Implementierung

Überprüfen Sie Rollen immer mit tatsächlichen assistiven Technologien. Browser-DevTools enthalten jetzt Accessibility-Tree-Inspektoren – verwenden Sie diese, um genau zu sehen, was Screenreader wahrnehmen. Testen Sie mit NVDA unter Windows oder VoiceOver unter macOS, um sicherzustellen, dass Ihre Rollen in eine nutzbare Erfahrung übersetzt werden.

Fazit

Accessibility-Rollen existieren, um zu beschreiben, was etwas ist, nicht wie es aussieht. Natives semantisches HTML bietet die meisten Rollen implizit – verwenden Sie es zuerst. Reservieren Sie ARIA-Rollen für wirklich benutzerdefinierte Komponenten, bei denen HTML nicht ausreicht. Wenn Sie ARIA verwenden, stellen Sie sicher, dass es mit den WCAG-Richtlinien übereinstimmt, und testen Sie mit echten assistiven Technologien. Denken Sie daran: Kein ARIA ist besser als schlechtes ARIA.

Häufig gestellte Fragen

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.