Wann ein Screenreader sprechen soll — und wann nicht: aria-live und Autoplay

A11y (Accessibility) Semantik wie aria-live fehlt noch viel zu häufig in Webanwendungen. Ohne diese ARIA-Eigenschaften erfährt ein Screen Reader nicht, wenn sich der Inhalt ändert. Nutzer:innen, die sich Texte vorlesen lassen, bekommen keinen Hinweis, dass gerade eine neue Slide erschienen ist.

Für Karusselle mit automatischer Rotation gibt es dabei einen Fehler, der so häufig gemacht wird, dass er fast die Regel ist.

Die konkrete Forderung

Automatisch rotierende Inhalte, die länger als fünf Sekunden laufen und parallel zu anderen Inhalten angezeigt werden, brauchen zwingend einen Mechanismus zum Pausieren oder Stoppen. Das ist WCAG 2.2.2, Level A, also keine optionale Empfehlung.

Für ein Karussell mit Autoplay bedeutet das vier konkrete Anforderungen:

Der Play/Pause-Button braucht außerdem ein, über JavaScript dynamisch veränderbares, Label, das den aktuellen Zustand beschreibt, nicht die Aktion:

<!-- Rotation läuft -->
<button aria-label="Automatische Rotation aktiv">⏸</button>

<!-- Rotation gestoppt -->
<button aria-label="Automatische Rotation gestoppt">▶</button>

Das klingt nach einem Detail. Für Screenreader-Nutzer:innen ist es der Unterschied zwischen „ich weiß, was gerade passiert" und „ich weiß nicht, ob mein Klick etwas bewirkt hat".

Ankündigungen

Das ARIA-Attribut aria-live definiert Live-Regionen im HTML-Code, um Screenreadern dynamische Inhaltsänderungen barrierefrei zu melden. Die Steuerung, zu welchem Zeitpunkt und mit welcher Priorität diese Ankündigung erfolgt, wird über die Werte polite und assertive geregelt.

<!-- Automatisch rotierendes Karussell -->
<div class="slides" aria-live="off" aria-atomic="false">
  <!-- Slides -->
</div>

<!-- Manuell gesteuertes Karussell -->
<div class="slides" aria-live="polite" aria-atomic="false">
  <!-- Slides -->
</div>

aria-live="polite" wird verwendet, um Änderungen dann anzukündigen, wenn Nutzer:innen nicht aktiv sind. Der häufigste Fehler: es wird pauschal gesetzt, auch bei Autoplay. Das bedeutet, der Screenreader kündigt bei jedem automatischen Slide-Wechsel den neuen Inhalt an. Alle paar Sekunden. Mitten in dem, was der Nutzer gerade liest. Das ist kein barrierefreies Karussell, das ist akustisches Chaos.

aria-live="off" schaltet das Ankündigen von Änderungen im DOM durch Screenreader aus. Die richtige Logik ist also: Wenn die Rotation läuft, ist aria-live aus. Wenn der Nutzer selbst navigiert, schaltet es auf aria-live="polite". Das bedeutet, der Wert muss dynamisch per JavaScript zwischen beiden Zuständen wechseln, gekoppelt an den Play/Pause-Button.

aria-atomic="false" weist den Screenreader an, nur den geänderten Teil des Containers vorzulesen, nicht den gesamten Inhalt. Bei aria-atomic="true" würde nach jedem Slide-Wechsel der komplette Container neu vorgelesen: Slide-Position, Titel, Beschreibung, Link, alles auf einmal.

Paginierte Karusselle

Ein weiterer Sonderfall: Karusselle, die mehrere Slides gleichzeitig anzeigen. Wenn bei einem Wechsel drei neue Slides gleichzeitig in den sichtbaren Bereich rücken, führt aria-live="polite" zu drei simultanen Ankündigungen, verwirrend und nicht steuerbar.

Für paginierte Karusselle empfiehlt Chrome Developers, aria-live ganz wegzulassen und stattdessen auf das Fokus Management zu setzen: Der Screenreader erfährt von der Änderung, weil der Nutzer aktiv navigiert, nicht weil eine Live-Region feuert.

Ein UX-Argument, das man kennen sollte

Websites barrierefrei zu bauen bedeutet manchmal auch, schlechte Design-Entscheidungen zu hinterfragen. Autoplay ist eine davon.

Die Nielsen Norman Group hat in mehreren Studien gezeigt, dass automatisch rotierende Karusselle von Nutzer:innen überdurchschnittlich häufig ignoriert werden, weil die Bewegung unbewusst mit Werbebannern assoziiert wird. Gleichzeitig lenkt sie vom Rest der Seite ab. Das Paradoxe: Autoplay macht wichtige Inhalte weniger sichtbar, nicht mehr.

Autoplay ist also fast immer die falsche Entscheidung. Das ist nicht nur Accessibility-Argument, das ist UX-Grundlage. Das belegen Nielsen Norman Group und web.dev unabhängig voneinander. Wer Autoplay trotzdem einsetzt, sollte zumindest wissen, was er damit aufgibt.

Was als Nächstes kommt

Live Regions und Autoplay sind gelöst. Was noch fehlt: die physische Interaktion. Wie groß müssen Buttons sein? Wie wird eine Wisch-Geste barrierefrei umgesetzt? Und wie schützt man Nutzer:innen vor vestibulären Problemen durch Animationen? Teil 5 gibt Antworten zu Touch Targets, Swipe-Gesten und prefers-reduced-motion.

➔ Touch Targets, Swipe-Gesten & prefers-reduced-motion

Quellen: W3C APG, Carousel Pattern · WCAG 2.2.2, Pause, Stop, Hide · Chrome, Accessible Carousel · Nielsen Norman Group, Auto-Forwarding · web.dev, Carousel Best Practices