Karussell und Slider barrierefrei gestalten

Karusselle gehören zu den umstrittensten UI-Patterns im Web – und zu den am häufigsten fehlerhaft umgesetzten. Aus Barrierefreiheitssicht sind sie besonders anspruchsvoll: Auto-rotierende Inhalte können Nutzer desorientieren, Tastaturnavigation wird oft vergessen, und Screenreader-Nutzer verstehen ohne korrekte ARIA-Auszeichnung nicht, dass sie sich in einem Karussell befinden. Trotzdem sind Karusselle aus vielen Websites nicht wegzudenken – Produktbilder, Testimonials, Hero-Banner. Die gute Nachricht: Mit dem W3C APG Carousel Pattern und den richtigen WCAG-Maßnahmen lassen sich auch Karusselle barrierefrei umsetzen.

WCAG-Anforderungen für Karusselle

Mehrere WCAG-Kriterien betreffen Karusselle direkt. WCAG 2.2.2 „Pause, Stop, Hide" (Level A) fordert, dass automatisch rotierende Inhalte pausiert, gestoppt oder ausgeblendet werden können. Das bedeutet: Jedes auto-rotierende Karussell braucht einen sichtbaren Pause-Button. WCAG 2.1.1 „Keyboard" (Level A) verlangt vollständige Tastaturzugänglichkeit – Vor/Zurück-Navigation, Slide-Auswahl und Pause müssen per Tastatur bedienbar sein. WCAG 1.3.1 „Info and Relationships" fordert, dass die Struktur programmatisch ermittelbar ist – Screenreader müssen verstehen, dass es sich um ein Karussell handelt und welches Slide aktiv ist. WCAG 4.1.2 „Name, Role, Value" verlangt, dass der Zustand jedes Slides kommuniziert wird. Und WCAG 2.3.3 „Animation from Interactions" (Level AAA) bedeutet, dass die Auto-Rotation bei `prefers-reduced-motion: reduce` deaktiviert werden sollte. Bei Bildkarussellen gelten zusätzlich die Anforderungen an Alternativtexte (WCAG 1.1.1).

ARIA-Markup nach dem W3C Carousel Pattern

Das W3C APG (ARIA Authoring Practices Guide) definiert ein Carousel Pattern mit klarer Rollenverteilung. Der Container erhält `role="region"`, `aria-roledescription="carousel"` und ein `aria-label` wie „Produktbilder" oder „Kundenstimmen". Jedes Slide wird als `role="group"` mit `aria-roledescription="slide"` und `aria-label="Slide 1 von 5"` ausgezeichnet. Nicht sichtbare Slides erhalten `aria-hidden="true"` und `inert`, damit Screenreader sie nicht vorlesen und Tastaturnutzer nicht hineintabben. Der Pause-Button zeigt seinen Zustand an – `aria-label="Rotation pausieren"` bzw. „Rotation fortsetzen". Paginierungs-Dots (Slide-Indikatoren) sind eine Liste von Buttons mit `aria-label="Slide 1"` und `aria-current="true"` für den aktiven Slide. Navigations-Pfeile erhalten `aria-label="Vorheriges Slide"` und „Nächstes Slide". Eine Live-Region mit `aria-live="polite"` kann optional den Slide-Wechsel ankündigen, sollte aber nur bei manuellem Wechsel aktiv sein, nicht bei Auto-Rotation.

Tastatursteuerung und Auto-Rotation

Die Tastatursteuerung eines Karussells sollte intuitiv und konsistent sein. Tab navigiert zu den Steuerungselementen (Pause, Vor, Zurück, Paginierung), nicht durch die Slides selbst – es wäre frustrierend, durch 10 Slides tabben zu müssen, um zum nächsten Seitenabschnitt zu gelangen. Innerhalb der Slide-Indikatoren (Dots) navigieren Pfeiltasten zwischen den Optionen. Enter oder Leertaste auf einem Indikator wechselt zum entsprechenden Slide. Die Auto-Rotation muss stoppen, wenn der Nutzer mit dem Karussell interagiert – per Tastatur, Maus oder Touch. Sie sollte ebenfalls stoppen, wenn der Nutzer mit der Maus über das Karussell hovert oder wenn ein Element innerhalb des Karussells den Fokus erhält. Die Rotation darf erst wieder starten, wenn der Nutzer explizit den Play-Button drückt. Setzen Sie die Rotationsgeschwindigkeit nicht zu schnell an – mindestens 5 Sekunden pro Slide, damit Nutzer den Inhalt lesen können. Bei `prefers-reduced-motion: reduce` sollte die Auto-Rotation standardmäßig deaktiviert sein.

Alternative Patterns und die Frage: Brauchen Sie ein Karussell?

Bevor Sie ein Karussell implementieren, stellen Sie die Frage: Ist ein Karussell wirklich die richtige Lösung? Studien zeigen, dass nur etwa 1-2 Prozent der Nutzer mit Auto-Karussellen interagieren, und davon klicken fast alle nur auf das erste Slide. Alternativen, die oft besser funktionieren: Ein statisches Hero-Bild mit dem wichtigsten Inhalt. Eine Grid-Ansicht, die alle Optionen gleichzeitig zeigt. Ein Akkordeon für textlastige Inhalte. Tabs für kategorisierte Informationen. Ein vertikaler Scroll mit allen Inhalten untereinander. Wenn ein Karussell dennoch die richtige Wahl ist – etwa für Produktbilder oder Portfolios – bevorzugen Sie manuelle Karusselle ohne Auto-Rotation. Der Nutzer entscheidet selbst, wann er weitergehen möchte. Verwenden Sie etablierte, barrierefreie Karussell-Bibliotheken wie Splide.js oder Flickity statt Eigenentwicklungen, und prüfen Sie deren Barrierefreiheit vor dem Einsatz.

Testing-Checkliste für barrierefreie Karusselle

Prüfen Sie Ihr Karussell systematisch gegen diese Checkliste: Gibt es einen sichtbaren Pause-Button? Stoppt die Auto-Rotation bei Hover, Fokus und Tastaturinteraktion? Funktioniert die Navigation per Tastatur (Tab zu Steuerungselementen, Pfeiltasten zwischen Indikatoren, Enter zum Aktivieren)? Kommuniziert ein Screenreader die Rolle „Karussell", die Slide-Nummer und die Gesamtanzahl? Sind nicht sichtbare Slides für Screenreader verborgen und nicht per Tab erreichbar? Haben Bilder in Slides Alternativtexte? Sind die Navigations-Buttons groß genug (mindestens 44×44px)? Haben die Steuerungselemente sichtbare Fokus-Indikatoren? Respektiert das Karussell `prefers-reduced-motion`? Funktioniert das Karussell bei deaktiviertem JavaScript (Fallback)? Haben die Paginierungs-Dots ausreichenden Kontrast und Größe? Kehrt der Fokus nach dem letzten Slide sinnvoll zurück? Testen Sie mit mindestens zwei Screenreadern (NVDA und VoiceOver) und per reiner Tastaturnavigation.