Barrierefreie Karussells

Karussells, auch bekannt als Slideshows, sind ein beliebtes Mittel auf Websites, um eine Reihe von Elementen in einer kompakten, visuell ansprechenden Weise zu präsentieren. Solche Slideshows sehen zwar elegant aus, haben aber auch einige Probleme mit der Zugänglichkeit.

Wenn man versucht, durch ein Karussell zu navigieren, das sich automatisch dreht, ohne dass eindeutige Steuerelemente oder die Möglichkeiten da sind, es anzuhalten, ist das sehr frustrierend. Für viele, vor allem für diejenigen, die auf Bildschirmlesegeräte oder Tastaturnavigation angewiesen sind, können Karussells schnell zu einem Hindernis werden, statt zu einem hilfreichen Werkzeug.

Recherchiert man zu dem Thema, stößt man immer wieder auf Aussagen wie „Wenn du kannst, lass die Finger von einer Slideshow“ oder „Vermeide den Einsatz von Karusells, wenn möglich“. Jedoch macht man es sich damit ein bißchen einfach, denn sie haben durchaus ihre Daseins-Berechtigung: sie schaffen es, relativ viel Inhalt auf kleinem Raum übersichtlich darzustellen und können wichtige Botschaften prominent präsentieren.

Man kann solche Widgets nutzerfreundlich und barrierefrei umsetzen, muss aber eine ganze Reihe von Anforderungen zu berücksichtigen.

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.

Kommen wir zu den einzelnen wichtigen Aspekten. Erklärung zur Terminologie: Zu „Karussell“ kann man auch Slider sagen und zu „Folien“ Slides. Im Artikel wird Karussell und Folien verwendet.

1 Automatisches Rotieren

Ständig wechselnde Inhalte können für alle gelegentlich störend sein, für manche Personen stellen sie sogar Barrieren dar. Menschen lesen Inhalte in unterschiedlichem Tempo, durch kognitive Einschränkungen werden manche Menschen durch die Bewegung abgelenkt oder können es gar nicht ertragen, ein Screenreader bemerkt den Wechsel zu einem anderen Inhalt möglicherweise gar nicht. Daher verlangen die WCAG 2.1 mit dem Erfolgskriterium 2.2.2 Pause, Stop, Hide eine Möglichkeit, die Bewegung stoppen zu können.

2 Visuelle Wahrnehmbarkeit

Dies ist ein entscheidender Punkt für Menschen mit einer Sehschwäche.

• Ausreichende Kontraste: Grafische Elemente müssen genügend Kontrast haben und die beste Lösung ist, die grafischen Elemente außerhalb des Folien zu platzieren.
• Deutlicher Fokus-Indikator: Gut sichtbaren Fokus setzen, auch hier gilt der Mindestkontrast von 3:1 zwischen nicht fokussiert und fokussiert, bzw. andere Formen der Fokussierung (z. B. Rahmen).
• Größe der Steuerelemente beachten: eine gewisse Größe und genügend Abstand sorgt für gute Bedienbarkeit auf Touchgeräten und hilft Menschen mit motorischen Einschränkungen.
• Anzeige der aktuellen Position im Folien-Set: Hilft bei der Orientierung, und zwar am besten, wenn es nicht nur über Farben gelöst wird, sondern farbunabhängig, z. B. ein gefüllter und nicht gefüllter Punkt.

3 Einfache Zeigereingabe

Das Navigieren zwischen den Folien sollte nicht nur per „Wischen“ möglich sein, da manche Menschen oder die verwendete assistive Technlogie dies nicht können. Eine einfache Zeigereingabe (Tippen oder Klicken) ist nötig. Wenn es keine Steuerelemente zum Einblenden bzw. Anspringen der Inhalte (z. B. Bullets) gibt, müssen „Vor“- und „Zurück“-Schaltflächen eingebaut werden.

4 Struktur, Semantik und Beschriftung

Für Screenreader ist die Struktur und Semantik essentiell, da die Inhalte linear gelesen werden. Nutzende müssen über Schaltflächen, Folien und Inhaltsänderungen informiert werden. Durch semantische Auszeichnung und hilfreichen Beschriftungen schafft man gute Orientierungspunkte.

Generell kann man beim Code zwischen „Tabbed Carousel Elements“ und „Group Carousel Elements“ unterscheiden, mehr darüber bei WAI. Beide Ansätze können zum Bauen eines barrierefreien Karussells verwendet werden. Hier folgt jetzt eine genauere Beschreibung des „Group Carousel Elements“-Ansatzes.

Umsetzungsbeispiel mit Group Carousel Elements

<div role="region" aria-roledescription="Karussell" aria-label="Tipps und Techniken">
	<div role="group" aria-label="Karussellsteuerung">
		<button aria-label="Automatische Bewegung anhalten">
			<!-- SVG-Icon -->
		</button>
		<button aria-disabled="true">
			<span class="hide-element">Zeige Folie 1 von 3: Barrierefrei verstecken</span>
			<!-- SVG-Icon -->
		</button>
		<button aria-disabled="false">
			<span class="hide-element">Zeige Folie 2 von 3: Barrierefreie Kontraste</span>
			<!-- SVG-Icon -->
		</button>
		<button aria-disabled="false">
			<span class="hide-element">Zeige Folie 3 von 3: Semantik, WAI-ARIA und assistive Technologien</span>
			<!-- SVG-Icon -->
		</button>
		<button aria-label="Vorherige Folie">
			<!-- SVG-Icon -->
		</button>
		<button aria-label="Nächste Folie">
			<!-- SVG-Icon -->
		</button>
	</div>
	<div role="group" aria-roledescription="Folie" aria-labelledby="carousel-item-1__heading" id="carousel-item-1">
		<h2 id="carousel-item-1__heading">Barrierefrei verstecken</h2>
		<!-- Weitere Inhalte der Folie -->
	</div>
	<div hidden role="group" aria-roledescription="Folie" aria-labelledby="carousel-item-2__heading" id="carousel-item-2">
		<h2 id="carousel-item-2__heading">Barrierefreie Kontraste</h2>
		<!-- Weitere Inhalte der Folie -->
	</div>
	<div hidden role="group" aria-roledescription="Folie" aria-labelledby="carousel-item-3__heading" id="carousel-item-3">
		<h2 id="carousel-item-3__heading">Semantik, WAI-ARIA und assistive Technologien</h2>
		<!-- Weitere Inhalte der Folie -->
	</div>
</div>

Erklärungen zum Beispiel

Grundsätzlich kann man für den Container, in dem das Karussell drin ist, entweder das HTML-Element <section>  oder alternativ einen <div>-Container mit role="region") nehmen, in Kombination mit einem zugänglichen Namen generiert man eine generische Landmark für Screenreadernutzer.

Mit role="group" kennzeichnet man einen Satz zusammen gehörender Elemente als eine Gruppe, dies ist aber keine Landmark und wird für weniger wichtige Bereichen verwendet.

Auch bei role="group" muss die Rolle in Kombination mit einem zugänglichen Namen verwendet werden.

Für beide „roles“ gilt: Der Screenreader übermittelt Namen und Rolle, wenn das erste interaktive Element den Fokus erhält, auch für die Rolle und die Beschriftung des fokusierten Elements.

Es gibt kein spezifisches HTML-Elemnt für Karusselle, aber durch den Code kann man Nutzenden mitteilen, dass es sich um ein Karussell handelt und sie können sich darauf einstellen: role=“region“ + aria-roledescription + zugänglicher Name mit aria-label sorgt für das beste Ergebnis. Aria-roledescription sollte nur für group oder region verwendet werden!

Im Folien-Container kann man auch die Folien ankündigen, sie bilden aber eine kleinere Einheit innerhalb des Karussell-Containers und sollten deshalb keine Landmark sein, also mit role="group" angelegt werden. Zusätzlich auch hier wieder mit aria-roledescription + zugänglicher Name. Der zugängliche Name ist im Beispiel die Headline der Folie, die mithilfe von aria-labelledby referenziert wird. Aria-label würde aber auch gehen.

Die nicht sichbaren Folien sollten verborgen werden, auch vor Screenreadern, das geht per css mit display:none, visibility:hidden oder per html mit dem hidden-Attribut. Dann sollte aber kein Listen-Markup verwendet werden, denn die versteckten Elemente werden vom Screenreader ja ignoriert und die Anzahl der Listenelemente würde falsch wiedergegeben werden.

Der Container für die Steuerelemente wird auch mit role="group" gruppiert und mit einem aria-label mit einem zugänglichen Namen versehen. Als Name eignet sich der Zweck der Bedienelemente, z. B. „Karussell-Steuerung“. Wichtig bei den Steuerelementen ist, dass man immer <button> verwendet: für Vor- und Zurück-Schaltflächen, Pause, und z. B. Bullets. Wenn das nicht geht, muss die entsprechende Semantik über role=“button“ hergestellt werden (mit tabindex=0 für Fokussierbarkeit, zusätzlich ist noch js für die Tastaturbedienbarkeit nötig. Außerdem muss man auf sinnvolle zugängliche Namen der Buttons achten und dass sie die jeweilige Funktion eindeutig vermitteln.

Ein letzter Punkt ist die semantische Auszeichnung des aktivierten Steuerelements, und zwar nicht nur visuell, sondern auch semantisch. Dies kann über aria-disabled="true" passieren. Alternativ ist auch aria-current="true" möglich.

Die Alternative, das „tabbed carousel“, arbeitet mit role="tablist", role="tab", der Folien-Container wird mit role="tabpanel" statt role="group" ausgezeichnet, aria-roledescription entfällt dann. Die ARIA-Eigenschaften entsprechen ebenfalls denen einer Registerkarten-Navigation.

5 Fokusreihenfolge

Eine schlüssige Fokusreihenfolge ist wichtig für die Orientierung der Nutzenden. Standardmäßig wird die sie durch die Reihenfolge der Elemente im Quellcode (genauer gesagt im DOM) bestimmt, welche auch die lineare Lesereihenfolge für den Screenreader bestimmt. 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

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, kann man 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

Der Fokus sollte auf dem Pause- / Abspiel- sowie auf den Zurück- und Vorwärts-Schaltflächen bleiben, 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 carousel“, der einer Registerkarten-Navigation entsprechen. Screenreader-Nutzende können dann aufgrund der Ausgabe die erwartete Bedienung ableiten.

Zusammenfassung:

1. Biete eine Schaltfläche zum Beenden der Bewegung an.
2. Sorge für kontrastreiche Bedienelemente.
3. Sorge für einen deutlich sichtbaren Fokusindikator bei Tastaturbedienung.
4. Das Karussell sollte nicht nur mit Wisch-Gesten bedienbar sein — biete zusätzlich Schaltflächen an.
5. Mach das Karussell als Ganzes, die Folien und bestenfalls auch das Set an Steuerelementen für Screenreader identifizierbar. Verwende 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 kann man alternativ auch eine Landmark (role="region" mit zugänglichem Namen) statt role="group" einsetzen.
6. Mit aria-roledescription kann man die Bedeutung der Container, die mit role="region" oder role="group" ausgezeichnet sind, näher bestimmen.
7. Für das „tabbed carousel“ verwende 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. Sorge 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.

Quellen:
Barrierefreie Karussells – Tollwerk
How to Test and Improve Carousel Accessibility: A Complete Guide