Barrierefreie Karussells

#"Should I use a carousel?"

So häufig sie auch eingesetzt werden, bei vielen UX-Fachleuten haben Karussell-Widgets einen schlechten Ruf. Sie werden von Nutzenden ignoriert (Nielsen Norman Group), lediglich 1% interagiert überhaupt mit einem Karussell und 89% davon nur mit der ersten Folie (Eric Runyon). Jared Smith beantwortet die Frage "Should I use A Carousel?" sogar sinngemäß mit der Aussage: „Wenn du die Wahl hast, dann lass die Finger davon“. Andere sagen, man müsse unterschiedliche Faktoren, wie Funktion, Gestaltung, Plattform (Desktop oder Mobil) und vor allem auch den Kontext bei der Einschätzung dieser Frage mit einbeziehen. Warum auch immer Sie ein Karussell auf einer Webseite einbinden, sorgen Sie für eine nutzerfreundliche und zugängliche Umsetzung.

#Barrierefreie Umsetzung

Für die Zugänglichkeit eines Karussells ist entscheidend, dass alle Nutzenden das Karussell und dessen Komponenten wahrnehmen und mit der Maus, Touch-Gesten, einer Tastatur, einem Screenreader und jeder anderen Hilfstechnologie mühelos steuern können. Das Rotieren der Folien darf Nutzende weder bei der Bedienung des Karussells, noch bei der Nutzung der Webseite insgesamt beeinträchtigen.

Die WAI-ARIA-Arbeitsgruppe des W3C bietet in dem ARIA Authoring Practices Guide einen möglichen Ansatz für eine barrierefreie Umsetzung. Der vorliegende Artikel orientiert sich an diesen Empfehlungen, will jedoch ausführlicher auf die eingesetzten Attribute und deren Auswirkung auf die praktische Nutzung eingehen.

#Automatisches Rotieren

Wir alle empfinden ständig wechselnde Inhalte vermutlich gelegentlich als störend. Für verschiedene Personengruppen kann ein unkontrolliertes Rotieren jedoch eine absolute Barriere sein:

• Menschen lesen Inhalte in unterschiedlichem Tempo. Reicht die vorgegebene Zeit nicht aus, kann das Karussell schnell zu einem frustrierenden Erlebnis werden. Es ist ziemlich unbefriedigend, wenn man den Text lediglich überfliegen kann, bevor ungefragt der nächste Inhalt erscheint.
• Bestimmte Personen, insbesondere Menschen mit kognitiven Einschränkungen wie beispielsweise Aufmerksamkeitsstörungen, empfinden bewegte Inhalte als ablenkend. Die Bewegung erschwert die Konzentration und damit auch die Interaktion mit dem Rest der Webseite. Menschen aus dem autistischen Spektrum müssen eine solche Seite vielleicht sogar ganz verlassen.
• Menschen, die einen Screenreader nutzen, bemerken die Bewegung möglicherweise nicht. Es kann passieren, dass eine Person mit einem Screenreader eine Überschrift auf „Folie 1“ liest und den Tastatur-Befehl für „nächstes Element lesen“ ausführt. Anstatt das nächste Element auf „Folie 1“ zu hören, liest der Screenreader einen Text von „Folie 2“ vor — und zwar ohne dass die Person weiß, dass das soeben vorgelesene Element aus einem völlig neuen Kontext stammt.

Die WCAG 2.1 verlangen daher mit dem Erfolgskriterium 2.2.2 Pause, Stop, Hide eine Möglichkeit, Bewegung gezielt stoppen zu können.

• Bieten Sie eine Pause- oder Stopp-Schaltfläche an, sofern Sie auf das automatische Rotieren nicht verzichten wollen. Die Schaltfläche zum Anhalten der Rotation ist die minimale Lösung (wenn die Bewegung nicht nach 5 Sekunden automatisch endet).

Usability-Fachleute empfehlen zusätzlich:

• Pausieren Sie die Bewegung, solange Nutzende mit der Maus über eine Folie fahren. Es besteht meist ein Zusammenhang zwischen der Mausposition und dem Interesse der Nutzenden an einem Inhalt. Riskieren Sie nicht einen Folienwechsel, wenige Millisekunden bevor eine Person einen Link aktiviert und dann auf der falschen Seite landet.
• Beenden Sie das Rotieren dauerhaft, wenn Nutzende interaktive Elemente mit der Tastatur fokussieren oder mit dem Karussell interagieren. Auch eine Aktion wie das aktive Wechseln der Folien signalisiert ein Interesse an dem Inhalt. Es ist möglich, dass sich eine Person zeitweilig anderen Bereichen der Seite zuwendet, aber wieder zurückkehren möchte. Außerdem erleichtern Sie Tastaturnutzenden die Bedienung, wenn das Karussell anhält, sobald ein Steuerelement den Fokus erhält.

#Visuelle Wahrnehmbarkeit

Elemente, die wir gut wahrnehmen können, sind für uns alle intuitiv besser nutzbar. Ganz entscheidend ist dieser Aspekt jedoch für Menschen mit einer Sehschwäche.

• Sorgen Sie für ausreichende Kontraste. Üblicherweise werden grafische Elemente für die Navigation des Widgets eingesetzt: Einfache Pfeile zum Weiterblättern der Folien sowie die weit verbreiteten „Punkte“ für das gezielte Einblenden. Häufig haben diese grafischen Elemente jedoch zu wenig Kontrast zum Hintergrund, insbesondere, wenn sie auf Bildern platziert werden. Sie können Kontrastprobleme am einfachsten vermeiden, indem Sie die Grafiken außerhalb der Folien positionieren.
• Bieten Sie einen deutlichen Fokusindikator an. Menschen, die mit der Tastatur navigieren, müssen sehen können, welches interaktive Element sie gerade ansteuern. Oft sieht das Design (wenn überhaupt) nur einen leichten und schlecht wahrnehmbaren Farbwechsel des Icons vor. Wechselt lediglich die Farbe, so müssen die eingesetzten Farbzustände (nicht fokussiert und fokussiert) zueinander einen Kontrast von mindestens 3,0:1 erfüllen. Dieser Mindestkontrast gilt gleichzeitig auch für das Icon in Bezug auf dessen Hintergrund sowie für andere Formen der Fokushervorhebung (zum Beispiel ein Rahmen um eine Schaltfläche).
• Auch die Größe der Steuerelemente beeinflusst die Wahrnehmbarkeit. Mit einer gewissen Größe in Kombination mit genügend Umraum reduzieren Sie zudem die Gefahr, dass Menschen mit feinmotorischen Einschränkungen versehentlich eine benachbarte Schaltfläche aktivieren. Nutzende von Touch-Geräten profitieren ebenfalls davon.
• Zeigen Sie die aktuelle Position innerhalb des Folien-Sets an. Meist erfolgt dies mit einer Hervorhebung eines von mehreren Steuerelementen. Damit auch farbfehlsichtige Menschen dies wahrnehmen können, sollte die Hervorhebung nicht allein über eine veränderte Farbe geschehen. Setzen Sie ein farbunabhängiges Unterscheidungsmerkmal ein, zum Beispiel ein gefüllter und nicht gefüllter Punkt.

#Aktivierung mit einer einfachen Zeigereingabe

Viele Menschen sind es gewohnt, auf Touch-Geräten die Folien durch horizontales Wischen zu wechseln. Es gibt jedoch auch Menschen, die diese Geste aufgrund ihrer Einschränkung oder aufgrund der verwendeten assistiven Technologie nicht ausführen können. Ermöglichen Sie diesen Menschen zusätzlich eine alternative Art der Navigation (siehe Erfolgskriterium 2.5.1 Pointer Gestures).

Ermöglichen Sie die Interaktion mit einer einfachen Zeigereingabe (zum Beispiel einfaches Klicken oder Tippen). Sind keine Steuerelemente vorhanden, mit denen die Inhalte direkt eingeblendet werden können, sind „Vor“- und „Zurück“-Schaltflächen erforderlich.

#Struktur, Semantik und Beschriftung

Das Karussell-Widget ist vorrangig auf eine zweidimensionale, visuelle Wahrnehmung ausgerichtet. Für Nutzende, die das Karussell nicht als Ganzes sehen (sie erkunden mit dem Screenreader im Lesemodus Inhalte linear), ist es sehr viel schwieriger, die Beziehung zwischen Bedienelementen und den Inhalten zu verstehen. Der Wechsel der Inhalte macht die Sache nicht einfacher. Die Herausforderung besteht also darin, Nutzende über das Gebilde von Schaltflächen und Folien verständlich zu informieren. Mit einer semantischen Auszeichnung der verschiedenen Bereiche sowie hilfreichen Beschriftungen schaffen Sie gute Orientierungsmöglichkeiten.

#Regionen und Gruppierungen

Grundsätzlich können Sie mit dem HTML-Element <section> (alternativ role="region") in Kombination mit einem zugänglichen Namen eine generische Landmark und damit einen Orientierungspunkt auch für kleinere Regionen einer Seite setzen. Screenreader-Nutzende können diese Bereiche in einem Inhaltsverzeichnis anzeigen und sie mit bestimmten Tastaturbefehlen für Landmarks erreichen.

Der Screenreader gibt beim Navigieren zu diesem Bereich den Namen und die Art des Bereichs (Region) aus, also: „[Name] — Region“. Im Lesemodus (Navigation mit Pfeiltasten) informiert der Screenreader Nutzende über den Anfang und das Ende des Bereichs: „[Name] — Region“ beziehungsweise „Region Ende“ (diese Ausgabe im Lesemodus wird derzeit vom Screenreader NVDA gut unterstützt, von JAWS leider nur, wenn Nutzende bestimmte Einstellungen im Screenreader vornehmen).

Mit role="group" kennzeichnen Sie einen Satz zusammen gehörender Elemente als eine Gruppe. Es handelt sich dabei nicht um eine Landmark. Im Unterschied zu der Auszeichnung mit role="region" verwenden Sie diese Rolle für weniger wichtige Bereiche. Sie können role="group" beispielsweise auch zur Gruppierung von (benutzerdefinierten) Formularelementen einsetzen (vergleiche <fieldset> und <legend> in HTML) — der Einsatz ist aber nicht darauf begrenzt.

Auch bei role="group" ist wichtig, dass Sie die Rolle in Kombination mit einem zugänglichen Namen verwenden. Der Screenreader kommuniziert auch hier beim Erreichen und Verlassen (in diesem Fall auch JAWS in der Standardeinstellung) den Anfang und das Ende der Gruppe („[Name] — Gruppierung“ beziehungsweise „Gruppierung Ende“).

Für role="region" und role="group" gilt: Erhält das erste interaktive Element innerhalb der Region oder Gruppe den Fokus, übermittelt der Screenreader ebenfalls den Namen und die Rolle, zusätzlich die Rolle und Beschriftung des fokussierten interaktiven Elements.

#Der Karussell-Container

Es gibt derzeit weder ein spezifisches HTML-Element, noch eine ARIA-Rolle für die Auszeichnung eines Karussells. Sie können dennoch semantisch vermitteln, dass ein Karussell vorhanden ist. Nutzende werden sich daraufhin auf das Widget und dessen Interaktionsmuster besser einstellen können.

#role="region|group" + zugänglicher Name

Am einfachsten kennzeichnen Sie ein Karussell mit Hilfe einer Landmark oder als Gruppe: Zeichnen Sie dafür den Container, der alle Karussell-Elemente enthält (einschließlich der Karussell-Steuerelemente und Folien) mit dem <section>-Element (alternativ role="region") oder mit role="group" aus und verwenden Sie einen zugänglichen Namen, der das Karussell als solches kennzeichnet.

#role="region|group" + aria-roledescription + zugänglicher Name

Mit aria-roledescription sorgen Sie zusätzlich für eine noch spezifischere Ausgabe des Screenreaders. Sie definieren damit die Bedeutung des Containers noch genauer.

#Der Folien-Container

Genau wie Sie das Karussell ankündigen können, ist das auch in Bezug auf die Folien möglich. Die einzelnen Folien bilden innerhalb des Gebildes „Karussell“ jeweils eine kleinere Einheit mit Inhalten.

#role="group" + aria-roledescription + zugänglicher Name

Verwenden Sie für die Folien daher keine Landmark (role="region"), sondern role="group" mit aria-roledescription sowie einem zugänglichen Namen.

#Die Folien

Verbergen Sie die nicht sichtbaren Folien, und zwar nicht nur visuell, sondern auch vor Screenreadern. Sie können dies mit Hilfe der CSS-Anweisungen display: none oder visibility: hidden oder mit Hilfe des HTML hidden-Attributs umsetzen.

Wenn Sie die nicht eingeblendeten Folien komplett verstecken, sollten Sie kein Listen-Markup für das Folien-Set einsetzen. Screenreader geben zwar grundsätzlich die Anzahl der Listenelemente einer Liste aus (was hilfreich erscheinen mag), aber ignorieren ​versteckte Elemente. Das bedeutet, in unserem Fall würde eine Listenauszeichnung nicht zu einer Ausgabe der tatsächlichen Anzahl der Listenelemente führen.

#role="group" + zugänglicher Name

Auch das Set von Steuerelementen können Sie mit role="group" gruppieren und gleichzeitig für diese Gruppe eine Gruppenbeschriftung übergeben.

#Die Steuerelemente

Mit den Steuerelementen blenden Nutzende eine bestimmte Folie ein. Sie dienen auch als visuelle Indikatoren für die Gesamtzahl der Folien und der aktuellen Position innerhalb des Sets. Sie werden grafisch häufig mit Hilfe von „Punkten“ umgesetzt.

#Tastaturbedienbare Steuerelemente

Zeichnen Sie alle Bedienelemente des gruppierten Karussells ("grouped carousel") mit dem <button>-Element aus. Das gilt für die Vor- und Zurück-Schaltflächen, den Pause-Schalter, sowie für die Steuerelemente, welche die Folien einblenden.

Natives HTML ist dabei die erste Wahl. Sollte dies nicht möglich sein, muss die Semantik mittels der entsprechenden ARIA-Rolle (role="button") abgebildet werden. Die Fokussierbarkeit stellen Sie in diesem Fall mit tabindex="0" sicher, für die Tastaturbedienbarkeit mit Leer- und Eingabetaste müssen Sie mit entsprechendem JavaScript sorgen.

#Der zugängliche Name der Steuerelemente

Wählen Sie für die grafischen Steuerelemente einen zugängliche Namen (Textalternative), der im Zusammenhang mit der Gruppenbeschriftung Sinn macht. Im Beispiel gibt der Screenreader beim Fokussieren des ersten Steuerelements der Gruppe aus: „Karussell Steuerung — Gruppierung — Zeige Folie 1 von 4“ — Schalter (oder „Karussellsteuerung — Gruppierung — Pause — Schalter“, sofern das erste Steuerelement der Pause-Schalter ist).

Lautet die Gruppenbeschriftung „Wählen Sie eine Folie“, so wäre in dieser Kombination auch die jeweilige Überschrift der Folie eine sinnvolle Beschriftung der Schaltflächen. Sie können die Beschriftung auch mit visuell verborgenem Text bereitstellen.

Denken Sie auch an eine Textalternative für die grafischen „Vor“- und „Zurück“-Schaltflächen.

Achten Sie darauf, dass die Textalternative der Stopp- beziehungsweise Abspiel-Schaltfläche je nach Zustand die jeweilige Funktion der Schaltfläche eindeutig vermittelt (zum Beispiel „Bewegung anhalten“, „Bewegung starten“).

#Semantische Auszeichnung des aktivierten Steuerelements

Vermitteln Sie nicht nur visuell, sondern auch semantisch, welches Bedienelement gerade aktiviert ist. Dafür können Sie aria-disabled="true" einsetzen. aria-disabled ist in diesem Fall dem HTML-Attribut disabled vorzuziehen, da die Schaltfläche im Gegensatz zu disabled in der Fokusreihenfolge enthalten bleibt. Alternativ ist auch aria-current="true" möglich.

#Fokusreihenfolge

Eine weitere wichtige Voraussetzung für die Bedienung von Webinhalten mit der Tastatur und assistiven Technologien ist eine schlüssige Fokusreihenfolge. Das ist die Reihenfolge, in der Sie interaktive Elemente mit der Tabulator-Taste ansteuern. Eine schlüssige Reihenfolge bedeutet im Allgemeinen, dass sie dem visuellen Fluss der Seite folgt. Nutzende können in einer hervorsehbaren und sinnvollen Weise navigieren, ohne dabei die Orientierung zu verlieren.

Die Tabulatorfolge wird standardmäßig durch die Reihenfolge der Elemente im Quellcode (genauer gesagt im DOM) bestimmt. Das heißt, die Reihenfolge, in der Sie das HTML schreiben, ist maßgebend für die Fokusreihenfolge bei der Navigation mit der Tastatur. Die DOM-Reihenfolge bestimmt auch die Lesereihenfolge für den Screenreader — also die Reihenfolge, in der Screenreader-Nutzende im Lesemodus mit den Pfeiltasten Inhalte (auch nicht interaktive) linear erkunden.

Die DOM- und damit die Fokusreihenfolge sollten möglichst mit der visuellen Reihenfolge übereinstimmen, damit sehende Tastaturnutzende die Abfolge gut nachvollziehen können.

Finden dynamische Inhaltsänderungen vor dem auslösenden Element statt, ergibt sich folgendes Problem: Screenreader-Nutzende werden nichts von solchen Änderungen erfahren (abgesehen von dynamisch eingeblendeten Status-Meldungen, die mit Hilfe von Live-Regionen umgesetzt sind). Außerdem ist es ungünstig, wenn Nutzende rückwärts navigieren müssen, etwa um interaktive Elemente zu erreichen.

#Eine schlüssige Fokusreihenfolge für das Karussell

Bei sehr vielen Karussell-Umsetzungen sind visuell die Steuerelemente unterhalb der Folien positioniert:

1. Zurück
2. Folie
3. Vorwärts
4. Pause
5. Steuerelemente

Entspricht dies auch der Reihenfolge der Elemente im DOM, so wird sowohl die Aktivierung von „Vorwärts“ als auch der Steuerelemente eine Änderung der Inhalte (Wechsel der Folie), vor dem auslösenden Element bewirken. Will man mit dem Screenreader den Inhalt der Folie erkunden beziehungsweise einem Link der Folie folgen, müsste man rückwärts navigieren.

#Die Reihenfolge im DOM

Die Fokusreihenfolge ist sehr viel nutzerfreundlicher, wenn die Bedienelemente (zumindest die Pause-Schaltfläche sowie die Steuerelemente) im DOM vor den wechselnden Folien positioniert sind. Wenn die Bedienelemente visuell weiterhin unterhalb des Karussells positioniert sein sollen, können Sie das mit CSS lösen. Eine gute Fokus- und Lesereihenfolge ist hier im Zweifel wichtiger, als die optimale Übereinstimmung mit der visuellen Reihenfolge:

1. Pause
2. Steuerelemente
3. Zurück
4. Folie
5. Vorwärts

oder

1. Pause
2. Steuerelemente
3. Zurück
4. Vorwärts
5. Folie

Für Menschen, die mit einer Vergrößerungssoftware arbeiten, ist der Pause-Schalter schneller auffindbar, wenn er auch visuell zu Beginn des Karussells positioniert ist. Sie sehen — je nach Vergrößerungsstufe — das Karussell nicht als Ganzes, sondern erkunden den Inhalt, indem sie einen Ausschnitt durch Bewegung des Tastaturfokus oder der Maus verschieben.

#Pause- und Pfeil-Schaltflächen

Lassen Sie den Fokus auf dem Pause- / Abspiel- sowie auf den Zurück- und Vorwärts-Schaltflächen, wenn Nutzende diese aktivieren. Sehende Tastaturnutzende können auf diese Weise wiederholt die Schaltfläche aktivieren und den wechselnden Inhalt wahrnehmen.

#Die Tastaturbedienung des "tabbed carousel"

Werden die Steuerelemente nach dem Muster einer Registerkarten-Navigation umgesetzt ("tabbed carousel"), erfolgt die Navigation innerhalb des Sets von Steuerelementen mit den Pfeiltasten. Bei dieser Umsetzung muss die ARIA-Auszeichnung, anders als beim hier erläuterten "grouped caroursel", der einer Registerkarten-Navigation entsprechen. Screenreader-Nutzende können dann aufgrund der Ausgabe die erwartete Bedienung ableiten.

#In aller Kürze

1. Bieten Sie eine Schaltfläche zum Beenden der Bewegung an.
2. Sorgen Sie für kontrastreiche Bedienelemente.
3. Sorgen Sie für einen deutlich sichtbaren Fokusindikator bei Tastaturbedienung.
4. Das Karussell sollte nicht nur mit Wisch-Gesten bedienbar sein — bieten Sie zusätzlich Schaltflächen an.
5. Machen Sie das Karussell als Ganzes, die Folien und bestenfalls auch das Set an Steuerelementen für Screenreader identifizierbar. Verwenden Sie für das Umsetzungs-Muster "grouped carousel" role="group" in Kombination mit einem aria-label oder aria-labelledby-Attribut. Für das Karussell als Ganzes können Sie alternativ auch eine Landmark (role="region" mit zugänglichem Namen) statt role="group" einsetzen.
6. Mit aria-roledescription können Sie die Bedeutung der Container, die mit role="region" oder role="group" ausgezeichnet sind, näher bestimmen.
7. Für das "tabbed carousel" verwenden Sie die ARIA-Attribute für eine Registerkarten-Navigation. Die Navigation innerhalb der Steuerelemente erfolgt mit den Pfeiltasten.
8. Alle Bedienelemente müssen tastaturbedienbar sein und benötigen eine aussagekräftige Textalternative (sofern grafisch umgesetzt).
9. Sorgen Sie für eine schlüssige Fokusreihenfolge. Sinnvoll ist, zumindest Pause- und Steuerelemente im DOM vor den Folien zu positionieren, auch wenn diese Reihenfolge eventuell von der visuellen Tab-Reihenfolge abweicht.

#Zusammenfassung

Dieser Artikel beschreibt eine mögliche barrierefreie Umsetzung von Karussell-Widgets. Selbst W3C-Arbeitsgruppen vermitteln in den ARIA Authoring Practices Guide und im W3C Accessbility Tutorial unterschiedliche Ansätze (siehe dazu auch eine Diskussion auf Github beziehungsweise den Kommentar von Jason Web hinsichtlich Nutzertests von "tabbed carousels" und Fokusversetzung). Wichtig ist:

• Machen Sie sich mit den Möglichkeiten der semantischen Auszeichnungen und den damit verbundenen Auswirkungen bei der Nutzung vertraut.
• Das Ziel ist eine vorhersehbare, verständliche Bedienung, auch bei nicht visueller Nutzung.
• Testen Sie mit der Tastatur und mit dem Screenreader. Die praktische Erfahrung zeigt am deutlichsten, ob Sie Ihr Ziel erreicht haben.
• Sollten Sie keine Ressourcen für die zugängliche Umsetzung eines Karussells haben, entscheiden Sie sich besser für ein alternatives Design und die damit verbundenen Vorteile.

#Ressourcen

Weiterführende Informationen, darunter Links auf zusätzliche Ressourcen, bieten unter anderem diese englischsprachigen Artikel:

• ARIA Authoring Practices Guide, Caroursel, W3C Web Accessibility Inititative, Mai 2020
• How to build a more accessible carousel or slider, Jason Web, zuletzt aktualisiert am 25. Mai 2021
• The Unbearable Inaccessibility of Slideshows, Gian Wild, zuletzt aktualisiert am 23. Februar 20
• Using the aria-roledescription-Attribut, Léonie Watson, zuletzt aktualisiert am 13. Dezember 2018
• Carousel/slider design best practices (with examples) YouTube, Vitaly Friedman, 05. Oktober 2021
• 5 Alternatives to Using a Carousel on Your Website Homepage und More Alternatives to Using a Carousel on Your Website, Mightybytes, zuletzt aktualisiert am 04. April 2020
• Carousels Tutorial, W3C Web Accessibility Initiative, zuletzt aktualisiert am 13. April 2017