ARIA Roles für barrierefreie Karusselle: role=region und role=group erklärt

Screenreader wie NVDA lesen Websites nicht visuell, sie lesen das Markup, und das ist viel zu oft nicht für Nutzer:innen konzipiert, die sich Text vorlesen lassen. Was vorgelesen wird, hängt fast ausschließlich davon ab, was im Code steht. Fehlt die Semantik, fehlt der Kontext. Nutzer:innen werden orientierungslos gelassen.

Das Karussell ist dafür ein Paradebeispiel. Visuell ist sofort klar, was es ist und wie es funktioniert. Semantisch ist es ohne die richtigen ARIA-Attribute ein unsortierter Haufen Code. Dieser Teil zeigt, welche Attribute meistens vergessen werden, und was passiert, wenn sie gesetzt sind.

Warum ein Karussell ohne role="region" für Screenreader unsichtbar ist

Screenreader bieten ihren Nutzer:innen eine Funktion, die visuellen Nutzer:innen verborgen bleibt: Landmark-Navigation. NVDA springt mit R zur nächsten Region, JAWS mit ;, VoiceOver öffnet mit VO+U einen Rotor über alle Landmarks der Seite. Landmarks sind strukturelle Elemente, die eine Webseite in logische Abschnitte unterteilen. So können Nutzer:innen eine Seite überfliegen, und gezielt entscheiden, was sie lesen wollen und was sie überspringen.

Ein Karussell ohne Landmark ist für diese Navigation unsichtbar. Nutzer:innen müssen sich mit der Pfeiltaste durch jeden einzelnen Slide-Inhalt arbeiten, ohne zu wissen, dass sie sich in einer zusammengehörigen Komponente befinden. Das ist der erste und häufigste Fehler.

Die Lösung ist ein einziges Attribut:

<!-- ❌ Häufiger Fehler: kein Landmark, kein Label -->
<div class="carousel">...</div>

<!-- ✅ So wird es gemacht -->
<div role="region" aria-roledescription="Karussell" aria-label="Beliebteste Produkte">
  <!-- Slides -->
</div>

role="region" macht den Container zur navigierbaren Landmark, einem Wegweiser, der zur Navigation eingesetzt wird. aria-roledescription überschreibt die generische Rollenbezeichnung „Region" eines Elementes mit role Attribut mit einem sprechenden Begriff wie "Karussell". aria-label gibt einer Landmark einen Namen, ohne ihn wird das Landmark von manchen Screenreadern sogar ignoriert.

Ein wichtiges Detail: Das Wort „Karussell" gehört nicht in aria-label. Da aria-roledescription den Typ bereits ankündigt, würde ein Label wie „Produkt-Karussell" zu einer redundanten Ausgabe führen: „Produkt-Karussell, Karussell". Der Label benennt den Inhalt, die Roledescription benennt den Typ.

Wie role="group" und aria-label Screenreadern Kontext geben

Selbst wenn der Container korrekt ausgezeichnet ist, bleibt ein typisches Problem: Die einzelnen Slides sind für Screenreader nicht voneinander unterscheidbar. Kein Kontext, keine Position, keine Gesamtzahl.

Jede Slide braucht eine eigene semantische Identität:

<div role="group" aria-roledescription="Slide" aria-label="3 von 8">
  <!-- Slide-Inhalt -->
</div>

role="group" markiert Inhalte als zusammenhängende Objekte, die jedoch nicht in die Seitenzusammenfassung mit aufgenommen werden. aria-roledescription="Slide" definiert ihr einen sprechenden Typ. aria-label="3 von 8" liefert Position und Gesamtzahl, die einzige Information, die Nutzer:innen sagt, wo sie sich im Karussell befinden und wie viel noch kommt.

Das Ergebnis ist ein klarer, konsistenter Screenreader-Output bei jedem Slide-Wechsel:

Ohne diese Attribute hört eine NVDA-Nutzerin beim Navigieren schlicht: „Gruppe", oder gar nichts.

Wann das Tab-Pattern die bessere Wahl ist

Das W3C APG beschreibt neben dem Region-Pattern eine zweite Variante: Tab-basierte Slides. Dabei übernimmt ein Slide-Picker, häufig als Dot-Navigation umgesetzt, die Rolle einer Tabnavigation. tablist deklariert ein Element als den Container einer Gruppe an Tabs, und tabpanel markiert eine Seite innerhalb einer Tabliste.

<div role="tablist" aria-label="Produkt-Slides">
  <button role="tab" aria-selected="true" aria-label="Slide 1">●</button>
  <button role="tab" aria-selected="false" aria-label="Slide 2">○</button>
</div>
<div role="tabpanel" aria-label="Slide 1">
  <!-- Slide-Inhalt -->
</div>

Vorteil: Tastatur-Nutzer:innen kennen das Tab-Pattern. ArrowLeft und ArrowRight wechseln zwischen Tabs, Tab verlässt die Liste. Das ist ein etabliertes Interaktionsmodell, keine neue Konvention, die gelernt werden muss.

Nachteil: Es eignet sich nur, wenn ein Slide-Picker vorhanden ist. Ein Karussell ohne sichtbare Dot- oder Thumbnail-Navigation sollte beim Region-Pattern bleiben.

Was das in der Praxis bedeutet

Semantik ist unsichtbar, genau deshalb wird sie so oft vergessen. Ein Karussell ohne role="region" und ohne Slide-Labels sieht exakt gleich aus wie eines mit. Kein visueller Test zeigt das Problem. Kein Screenshot-basiertes Audit schlägt an.

Sichtbar wird es erst, wenn man mit einem Screenreader durch die Seite navigiert. Dann ist der Unterschied zwischen einer gut strukturierten und einer schlecht strukturierten Komponente der Unterschied zwischen Orientierung und Desorientierung.

Das ist der Kern dieses Fehlers, und der Grund, warum er so häufig unentdeckt bleibt.

Was als Nächstes kommt

Semantik ist die Grundlage. Aber eine korrekt ausgezeichnete Komponente ist noch nicht bedienbar, wenn Tastatur-Nutzer:innen keinen Zugriff auf die Navigation haben oder der Fokus beim Slide-Wechsel an unerwartete Stellen springt.

Teil 3 widmet sich genau diesem Problem: Tastaturnavigation, Fokus Management und das inert-Attribut, der häufig übersehene Mechanismus, der Off-Screen-Slides aus dem Accessibility Tree entfernt.

➔ Tastatur & Fokus management: Selbstbestimmung als Designprinzip

Quellen: W3C APG, Carousel Pattern · W3C APG, Carousel with Tabs · WCAG 2.2