Karussell BFSG-konform: eine Schritt-für-Schritt-Anleitung für Web-Entwickler
Informationen zum Artikel
Autor: Dmitry Dugarev
Die folgende Anleitung zeigt Dir die Anforderungen, damit Dein Karussell die Barrierefreiheitsstandards erfüllt. Zu jedem Abschnitt gibt's ein Codebeispiel und eine Checkliste zum Abhaken.
Hier siehst Du ein Beispiel für ein Karussel, das alle Anforderungen erfüllt:
Live-Demo
Karussell mit 4 Folien. Verwende die Schaltflächen "Weiter" und "Zurück" oder wähle einen Punkt aus. Die automatische Rotation kann mit der Schaltfläche angehalten werden. Drücke jederzeit die Escape-Taste, um anzuhalten.
Grundstruktur fürs Karussell
Das ganze Karussell sollte als eigene Region auf der Seite erkennbar sein [1]. Ohne diese Kennzeichnung ist es für Nutzer, die über Landmarks navigieren, schwer zu finden und der Zweck bleibt unklar [2].
Textbeschreibung für "Schematische Darstellung der Grundstruktur eines
barrierefreien Karussells" öffnen
Dieses Diagramm zeigt die wesentlichen Komponenten, aus denen ein barrierefreies Karussell aufgebaut ist. Alle Elemente sind innerhalb einer Hauptregion angeordnet.
-
Hauptregion: Eine Sektion mit einer eindeutigen ID und dem Attribut
aria-roledescription. -
Überschrift: Eine Überschrift mit einer eindeutigen ID, die mit der Hauptregion über
aria-labelledbyverknüpft ist. -
Folienliste: Eine Liste, die die Folien enthält.
- Folien: Jede Folie ist ein Listenelement, das den eigentlichen Inhalt (z. B. in einem
article-Element) enthält. Verborgene Folien sind mitaria-hidden="true"markiert.
- Folien: Jede Folie ist ein Listenelement, das den eigentlichen Inhalt (z. B. in einem
-
Steuerelemente:
- Eine Liste mit Pfeil-Schaltflächen (für sequenzielle Navigation).
- Eine Radio-Gruppe mit Punkten (für direkte Auswahl).
- Eine Pause-Schaltfläche (für die Steuerung der automatischen Rotation).
- Eine Region für Statusmeldungen (für Screenreader).
Hier zeig' ich Dir ein Beispiel für die Grundstruktur:
<section
id="carousel-section"
class="carousel"
aria-roledescription="Karussell"
aria-labelledby="carousel-heading"
>
<h2 id="carousel-heading">Aktuelle Angebote</h2>
</section>
Wir packen das Karussell in eine <section> [1]. Mit aria-labelledby [3] zeigst Du auf eine sichtbare Überschrift (die <h2>), was die <section> zu einer benannten Region macht. aria-roledescription="Karussell" [4] flüstert dem Screenreader, was das hier genau ist (nämlich ein 'Karussell'), und das am besten in der Sprache des Nutzers [5].
Checkliste für die Grundstruktur:
- Hast Du das Karussell in einem
<section>-Element [1] mitaria-roledescription="Karussell"[4] zur Beschreibung für Screenreader umschlossen? - Falls Deine Website mehrsprachig ist, ist der Wert von
aria-roledescriptionin der Sprache des Benutzers lokalisiert? [5] - Hat Dein Karussell eine Überschrift mit einer eindeutigen ID? [6]
- Hat die Karussell-Sektion ein
aria-labelledby-Attribut, das auf die ID der Überschrift verweist? [3]
Folien-Container
Die Folien sind ja eine Gruppe von Dingen, die zusammengehören. Also solltest Du sie als Liste auszeichnen [7]. Wenn Du die Folien einfach nur in <div>s packst, können Screenreader weder die Anzahl erkennen noch kapieren, wie sie zusammenhängen [8].
Hier ist ein Beispiel für die Struktur des Folien-Containers:
<ul class="slides-container" aria-label="Folien">
<li></li>
<li></li>
</ul>
Du strukturierst die Folien als Listenelemente (<li>) in einer ungeordneten Liste (<ul>) [7]. So können Screenreader die Anzahl der Folien erkennen und ihre Beziehung verstehen [8].
Checkliste für den Folien-Container:
- Befinden sich Deine Karussell-Folien in einem
<ul>-Element, wobei jeder Slide in einem<li>-Element eingeschlossen ist? [7], [8] - Hat das
<ul>-Element einaria-label, um die Liste der Folien zu beschreiben [9]?
Inhalt der Folien
Jede Folie solltest Du als eigenen Abschnitt mit 'ner klaren Struktur und den korrekten ARIA-Attributen bauen, damit ihre Rolle und Position im Karussell klar rüberkommt [8].
Hier ist ein Beispiel für die Struktur der Folien in einem Karussell:
<ul class="slides-container" aria-label="Folien">
<li>
<article
class="slide active"
id="slide-1"
aria-roledescription="Folie"
aria-labelledby="slide-heading-1"
aria-posinset="1"
aria-setsize="3"
aria-hidden="false"
tabindex="-1"
>
<h3 id="slide-heading-1" tabindex="-1">Exclusive Summer Offer</h3>
<p>Discover our new summer collections with up to 30% off.</p>
<a href="#" class="cta-button">
<span class="visually-hidden">Exclusive Summer Offer — </span>Learn more
</a>
</article>
</li>
<li>
<article
class="slide"
id="slide-2"
aria-roledescription="Folie"
aria-labelledby="slide-heading-2"
aria-posinset="2"
aria-setsize="3"
aria-hidden="true"
tabindex="-1"
inert
>
<h3 id="slide-heading-2" tabindex="-1">New: Our Outdoor Gear</h3>
<p>Perfect for your next outdoor adventure. Sturdy and durable.</p>
<a href="#" class="cta-button">
<span class="visually-hidden">New: Our Outdoor Gear — </span>Learn more
</a>
</article>
</li>
</ul>
Der Inhalt jeder Folie steckt in einem <article>-Element, das gibt dem Ganzen eine semantische Struktur [1]. Jedes <article> sollte die Attribute aria-roledescription="Folie" [4], aria-posinset und aria-setsize [8] haben.
Damit kommunizierst Du die Rolle und Position. Das machst Du, weil manche Browser und Screenreader aria-posinset und aria-setsize nicht automatisch aus der <ul>-Liste schnallen, besonders wenn Du Folien dynamisch änderst oder das CSS die Liste verbiegt. Versteckte Folien markierst Du mit aria-hidden="true" und inert, damit sie aus dem Accessibility Tree fliegen [10].
Checkliste für den Folieninhalt:
- Hast Du den Folieninhalt in einem
<article>-Element platziert, um eine semantische Struktur bereitzustellen? [1] - Hat jede Folie das Attribut
aria-roledescription="Folie", um seine Beschreibung für Screenreader anzusagen? [4] - Falls Deine Website mehrsprachig ist, ist der Wert von
aria-roledescriptionin der Sprache des Benutzers lokalisiert? [5] - Hat jede Folie eine Überschrift mit einer eindeutigen ID [6]?
- Hat jede Folie ein
aria-labelledby-Attribut, das auf die ID der Überschrift verweist, um sie zu einer benannten Region zu machen [3]? - Hat jede Folie die Attribute
aria-posinsetundaria-setsize, um seine Position und die Gesamtzahl der Folien zusätzlich zu kommunizieren? [8] - Sind verborgene Folien mit den Attributen
aria-hidden="true"undinertoderdisplay: nonemarkiert, um zu verhindern, dass sie von Screenreadern und Tastaturbenutzern angesagt oder mit ihnen interagiert werden kann? [10]
Fokusmanagement
Ein sauberes Fokusmanagement sorgt dafür, dass Nutzer wissen, wo sie sind, wenn eine Folie wechselt [11]. Das ist super wichtig für alle, die assistive Technologien nutzen.
Nach jedem manuellen Folienwechsel musst Du den Fokus per Script auf das erste Element der neuen Folie setzen (zum Beispiel auf die Überschrift in der Folie) [12].
Textbeschreibung für "Logik des Fokusmanagements nach Folienwechsel" öffnen
Dieses Ablaufdiagramm beschreibt die Schritte, die für ein korrektes Fokusmanagement nach einem manuellen Folienwechsel in einem Karussell erforderlich sind.
- Der Benutzer löst den Wechsel aus (z. B. "Benutzer klickt „Weiter“").
- Ein JavaScript-Ereignis startet den Slide-Wechsel ("JavaScript-Event: Slide-Wechsel starten").
- Die visuelle Animation läuft ("Animation läuft").
- Die Animation ist abgeschlossen ("Animation abgeschlossen").
- Der neue Slide wird programmatisch als aktiv markiert ("Neuer Slide wird aktiv markiert (.active)").
- Das erste fokussierbare Element des neuen Slides (z. B. die Überschrift
<h3>) wird gesucht ("Erstes fokussierbares Element finden"). - Der Fokus wird mithilfe der Methode
.focus()auf dieses Element gesetzt ("Fokus per .focus() setzen"). - Der Screenreader liest den Inhalt des neuen Slides vor ("Screenreader liest neuen Slide-Inhalt vor").
Hier ist ein Schnipsel, wie das in JavaScript aussehen könnte:
// Beispiel-Logik nach dem Wechsel zur neuen Folie
const newSlide = document.querySelector('.slide.active');
const focusableElement = newSlide.querySelector('h3');
focusableElement.focus();
Checkliste für das Fokusmanagement:
- Bewegt sich der Fokus nach dem Klick auf eine Navigationsschaltfläche auf die Überschrift der aktuellen Folie, damit sie vom Screenreader angesagt werden kann? [12], [11]
- Wenn ein Folienwechsel stattfindet, bewegt sich der Fokus erst nach Abschluss der Wechselanimation auf die neue Folie und nicht schon vorher, um eine Unterbrechung der Ansage zu vermeiden? [13]
Steuerung für die automatische Rotation
Eine Rotation, die Du nicht kontrollieren kannst, lenkt total ab und gibt den Leuten nicht genug Zeit, den Inhalt zu lesen. Das verstößt direkt gegen die WCAG [14]. Deswegen müssen alle Karussells mit Auto-Rotation diese Dinger hier erfüllen:
- Pause/Play-Button: Du brauchst einen sichtbaren und tastaturbedienbaren Button zum Anhalten und Fortsetzen der Animation [15]. Sein
aria-labelmuss sich dynamisch ändern (z.B. "Animation anhalten" / "Animation starten").
- Pause bei Interaktion: Die Rotation muss automatisch pausieren, sobald Du mit der Maus über das Karussell fährst (
mouseenter) oder ein Element darin fokussierst (focusin) [14]. prefers-reduced-motionrespektieren: Die Animation sollte von Anfang an deaktiviert sein, wenn der Nutzer in seinem Betriebssystem reduzierte Bewegung wünscht.
Textbeschreibung für "Zustände der automatischen Rotation" öffnen
Dieses Zustandsdiagramm zeigt die verschiedenen Zustände der automatischen Rotation eines Karussells und die Übergänge zwischen diesen Zuständen.
- Der Startzustand ist Idle (Rotation aus).
- Von Idle wechselt das System zu AutoRotate (Rotation aktiv) durch die Aktion "Start Rotation".
- Von AutoRotate kann das System in zwei Zustände wechseln:
- Zu Paused (angehalten) durch die Aktionen "Klick auf Pause" oder "Fokus oder Maus über Karussell".
- Zu RespectReducedMotion (Bewegung reduziert) durch die Aktion "prefers-reduced-motion aktiv".
- Von Paused wechselt das System zurück zu AutoRotate durch die Aktion "Klick auf Play".
- Der Zustand RespectReducedMotion wechselt bei Bedarf zurück zu Paused.
Außerdem muss die automatische Rotation pausieren, wenn Du mit dem Karussell interagierst:
Checkliste für die Steuerung der automatischen Rotation:
- Gibt es eine Möglichkeit, die automatische Rotation anzuhalten, z. B. eine "Pause"-Schaltfläche? [14], [15]
- Ist die Schaltfläche für die automatische Rotation als
<button>-Element [10] mitaria-label- [9] undtitle-Attributen [16] für die Screenreader-Ansage und Tooltips implementiert? - Hat die Schaltfläche für die automatische Rotation ein
aria-pressed-Attribut, um ihren Zustand (an/aus) anzuzeigen, mit entsprechend aktualisierten Beschriftungen und Titeln? [17] - Ist die Schaltfläche für die automatische Rotation fokussierbar und mit der Tastatur (über
EnteroderLeertaste) bedienbar? [18] - Hat die Schaltfläche für die automatische Rotation einen unterscheidbaren Fokus-Stil [19] mit einem Kontrastverhältnis von mindestens 3:1 zum Hintergrund? [20]
- Hat die Schaltfläche für die automatische Rotation ein Kontrastverhältnis von mindestens 3:1 zum Hintergrund für die Sichtbarkeit? [20]
- Hat die Schaltfläche für die automatische Rotation eine ausreichende Größe (mindestens 44x44 Pixel), um die Bedienung zu erleichtern? [21]
- Stoppt die automatische Rotation, wenn Du mit der Maus über den aktuellen Slide fährst oder ihn fokussierst, um eine ununterbrochene Interaktion mit dem Inhalt zu ermöglichen? [14]
- Stoppt die automatische Rotation, wenn eine der Folien-Steuerungsschaltflächen des Karussels mit der Maus überfahren wird oder den Fokus erhält? [14]
- Respektiert die automatische Rotation die
prefers-reduced-motion-Einstellung des Benutzers und deaktiviert Animationen entsprechend? [14]
Pfeil-Schaltflächen
Mit Pfeil-Buttons navigierst Du im Karussell. Die "Weiter"- und "Zurück"-Buttons musst Du als echte Buttons umsetzen. Viel zu oft sehe ich <a>-Tags mit href="#", die dafür missbraucht werden. Das ist semantisch falsch [22], funktioniert per Tastatur nicht zuverlässig (speziell in Safari) und geht nicht mit der Leertaste [18]. Deshalb: Nimm <button>-Elemente. Wichtig ist, dass Du sie klar beschriftest und zugänglich machst [10].
Hier ist ein Beispiel für die Struktur der Pfeil-Schaltflächen:
<ul class="carousel-navigation" aria-label="Sequenzielle Navigation">
<li>
<button
type="button"
id="prev-btn"
class="carousel-btn"
aria-label="Vorherige Folie"
title="Vorherige Folie"
></button>
</li>
<li>
<button
type="button"
id="next-btn"
class="carousel-btn"
aria-label="Nächste Folie"
title="Nächste Folie"
></button>
</li>
</ul>
Wir nehmen native <button>-Elemente. Die sind von Haus aus fokussierbar und bedienbar [18]. Ein aria-label [9] gibt ihnen einen zugänglichen Namen, der ihre Funktion beschreibt (z.B. "Nächste Folie"). Icons (SVG oder <img>) versteckst Du mit aria-hidden="true", da sie ja nur Deko sind [23].
Checkliste für die Pfeil-Schaltflächen:
- Sind Deine Pfeil-Navigationsschaltflächen als
<ul>-Element [7] mit einemaria-label[9] implementiert, um die Steuerelemente zu beschreiben? - Sind die Pfeil-Navigationsschaltflächen für einen einfachen Zugang konsistent am Anfang oder Ende des Karussells vor der Punktnavigation platziert? [24]
- Sind die Pfeil-Navigationsschaltflächen als
<button>-Elemente [10] mitaria-label- [9] undtitle-Attributen [16] für die Screenreader-Ansage und Tooltips implementiert, falls sie keine sichtbaren Textbeschriftungen haben? - Sind die Pfeil-Navigationsschaltflächen fokussierbar und mit der Tastatur (über
EnteroderLeertaste) bedienbar? [18] - Haben die Pfeil-Navigationsschaltflächen einen unterscheidbaren Fokus-Stil [19] mit einem Kontrastverhältnis von mindestens 3:1 zum Hintergrund? [20]
- Haben die Pfeil-Navigationsschaltflächen ein Kontrastverhältnis von mindestens 3:1 zum Hintergrund für die Sichtbarkeit? [20]
- Haben die Pfeil-Navigationsschaltflächen eine ausreichende Größe (mindestens 44x44 Pixel), um die Bedienung zu erleichtern? [21]
- Falls die Pfeil-Schaltflächen Icons verwenden, sind diese Icons dekorativ und mit
aria-hidden="true"markiert? [23]
Punktnavigation
Mit der Punktnavigation können Deine Nutzer bestimmte Slides auswählen. Diese Funktion musst Du natürlich auch barrierefrei bauen.
Hier geht's nicht nur um einen Klick, sondern um die Auswahl einer Option aus einer Gruppe. Wenn Du das als einfache <div>s oder <button>s baust, fehlt die Semantik einer Auswahlgruppe [8], in der nur eine Option gewählt werden kann. Die Tastaturnavigation mit Pfeiltasten geht dann nicht [18], und der aktuelle Zustand wird auch nicht gemeldet [10].
Die semantisch sauberste und robusteste Lösung ist, das Ganze als Radio-Button-Gruppe zu implementieren. Radio-Buttons bringen von Haus aus die richtige Semantik [10] und Tastaturnavigation mit.
- Du packst die Gruppe in ein
<fieldset>mit einer<legend>[25], um die Auswahlgruppe zu kennzeichnen. - Jeder Punkt ist ein
<input type="radio">mit einem zugehörigen<label>[26]. - Damit Du das stylen kannst, versteckst Du die echten Radio-Buttons visuell (
visually-hidden) und gestaltest die<label>-Elemente als klickbare Punkte. - Und damit Screenreader nicht beides vorlesen (doppelte Ansage), kriegt der
inputein klaresaria-label(z.B. "Folie 1") [9] und daslabelversteckst Du mitaria-hidden="true"für Screenreader.
Hier ist ein Beispiel für die Struktur der Punktnavigation:
<fieldset class="carousel-dots">
<legend class="visually-hidden">Folienauswahl</legend>
<input
type="radio"
id="dot-1"
name="carousel-dots"
class="visually-hidden"
aria-label="Folie 1"
checked
/>
<label for="dot-1" class="carousel-dot-label" aria-hidden="true">
<span class="visually-hidden">Folie 1</span>
</label>
<input
type="radio"
id="dot-2"
name="carousel-dots"
class="visually-hidden"
aria-label="Folie 2"
/>
<label for="dot-2" class="carousel-dot-label" aria-hidden="true">
<span class="visually-hidden">Folie 2</span>
</label>
</fieldset>
Checkliste für die Punktnavigation:
- Sind die Navigationspunkte in einem
<fieldset>-Element mit einem entsprechenden<legend>-Element platziert, um eine Beschriftung bereitzustellen, die von Screenreadern angesagt wird? [25], [8] - Sind die Navigationspunkte als Radio-Buttons implementiert [10], um die Auswahl und die Tastaturnavigation (z. B. mit den Pfeiltasten) zu unterstützen? [18]
- Unterstützen die Navigationspunkte die Tasten
HomeundEnd, um zum ersten und letzten Slide zu navigieren, und optional die TastenArrowDownundArrowUpzur Navigation zum nächsten/vorherigen Slide? [18] - Haben die Navigationspunkte ein
aria-label-Attribut [9] oder eine entsprechende Textbeschriftung [26] für die Screenreader-Ansage? - Sind die Navigationspunkte bei Fokussierung visuell unterscheidbar [19], mit einem Fokus-Stil, der ein Mindestkontrastverhältnis von 3:1 zum Hintergrund aufweist? [20]
- Ist der aktuell aktive Punkt visuell hervorgehoben und wird von Screenreadern angesagt? [10]
- Ist der aktuell aktive Punkt programmatisch unterscheidbar? [10]
Folienwechsel für Screenreader ansagen
Wenn ein Nutzer manuell die Folie mit den Pfeil-Buttons wechselt, kriegt er bisher keine Rückmeldung, welche Folie jetzt aktiv ist.
Dafür brauchen wir eine "Live Region", die Änderungen ankündigt [13]. Ein visuell verstecktes Element mit aria-live="polite" und aria-atomic="true" füllst Du per JavaScript mit dem neuen Status (z.B. "Folie 2 von 3"). Das sollte als Statusmeldung kommuniziert werden.
Wichtig: Mach das nur bei manuellen Wechseln durch die Pfeil-Buttons, um eine Reizüberflutung bei automatischer Rotation oder bei der bewussten Auswahl über die Dots zu vermeiden.
Hier ist ein Beispiel für eine Live-Region:
<div
id="slide-change-region"
class="visually-hidden"
role="status"
aria-live="polite"
aria-atomic="true"
></div>
Checkliste für die Ansage von Folienwechseln:
- Gibt es ein visuell verstecktes Element mit
aria-live="polite"undaria-atomic="true", das den aktuellen Folienstatus (z. B. "Folie 2 von 5") ansagt? [13] - Hat die Live-Region ein
role="status", um Screenreader zu informieren, dass es sich um eine Statusmeldung handelt? [28] - Wird die Ansage der Live-Region ausgelöst, nachdem der Fokus auf den neuen Slide verschoben wurde, um sicherzustellen, dass der Screenreader den Inhalt korrekt und ohne Unterbrechung ansagt? [13]
- Vermeidest Du es, den aktuellen Slide während der automatischen Rotation anzusagen, da der Benutzer nicht aktiv navigiert? [13]
- Wird die Live-Region nur bei manuellen Folienwechseln (z. B. durch Pfeil-Schaltflächen) aktualisiert, um eine Reizüberflutung zu vermeiden? [13]
Visueller und Tastatur-Fokus
Es ist echt entscheidend, dass alle Deine interaktiven Elemente einen klaren visuellen Fokusindikator haben [19]. Das hilft Tastatur- und Screenreader-Nutzern enorm.
Checkliste für den visuellen und Tastatur-Fokus:
- Haben alle interaktiven Steuerelemente (Navigationspunkte, Pfeil-Schaltflächen, Pause-Schaltfläche) einen unterscheidbaren Fokus-Stil [19] mit einem Kontrastverhältnis von mindestens 3:1 zum Hintergrund? [20]
- Haben alle interaktiven Steuerelemente (Navigationspunkte, Pfeil-Schaltflächen, Pause-Schaltfläche) ein Kontrastverhältnis von mindestens 3:1 zum Hintergrund für die Sichtbarkeit? [20]
Anleitungen zur barrierefreien Interaktion
Wenn Du Anleitungen zur Interaktion mit dem Karussell bereitstellst [29], verbesserst Du die Barrierefreiheit, weil Du Nutzern von assistierenden Technologien Orientierung gibst.
Checkliste für Anleitungen zur Interaktion:
- Gibt es im Karussell ein Textelement, das Anleitungen zur Interaktion enthält? Du kannst es visuell verstecken. [29]
- Ist die Anleitung über
aria-describedbymit dem Karussell verbunden, sodass sie angesagt wird, wenn das Karussell fokussiert wird? [30] - Ist die Anleitung über
aria-describedbymit jedem Slide verbunden, sodass sie angesagt wird, wenn der Slide fokussiert wird? [30]
Fazit
Barrierefreie Karussells sind kein „Nice-to-have“, sondern eine knallharte Voraussetzung für eine inklusive Nutzererfahrung und die Einhaltung der WCAG-2.2-Anforderungen. Dieser Leitfaden zeigt Dir hoffentlich, dass sich Barrierefreiheit nicht auf ein bisschen Kosmetik reduzieren lässt: Sie entsteht aus einer semantisch korrekten Struktur [8], vollständiger Tastaturbedienbarkeit [18], verlässlichem Fokusmanagement [11], kontrollierbarer Animation [14], klaren Statusmeldungen [13] und durchdachter Nutzerführung.
Der zentrale Punkt ist: Karussells sind komplexe, interaktive Komponenten mit vielen Zuständen. Erst die Kombination aus Landmark-Struktur (also section mit benannter Überschrift [2]), einer klaren Rollenbeschreibung (aria-roledescription [4]), sichtbaren und programmatisch erkennbaren Zuständen (z. B. aktive Folie, pausierte Rotation) [10], sowie robusten Navigationsmustern (Buttons statt missbrauchter Links [22], Radio-Gruppe für Dots [25]) macht es assistiven Technologien möglich, die Interaktion verlässlich zu vermitteln.
Für die Praxis sind außerdem Progressive Enhancement (stell sicher, dass es auch ohne JavaScript grob funktioniert), Internationalisierung (lokalisierte Labels, besonders aria-roledescription) [5], Respekt für Systempräferenzen (prefers-reduced-motion) [14] und ein prüfbares Testdesign wichtig. Wenn Du diese Aspekte systematisch umsetzt, baust Du Barrieren ab, erhöhst die Zufriedenheit aller Nutzer – und senkst langfristig Deine Wartungs- und Supportkosten.
Nutze diese Checkliste, um Deine Karussell-Implementierung zu checken und nötige Anpassungen zu machen. Regelmäßiges Testen mit echten Benutzern, inklusive Menschen mit Behinderungen, kann Dir auch mega wertvolle Einblicke geben, wie Dein Karussell so ankommt.
Häufig gestellte Fragen (FAQ) zu barrierefreien Karussells
Warum ist das Fokusmanagement bei Karussells so wichtig?
Das Fokusmanagement sorgt dafür, dass assistive Technologien wie Screenreader bei einem Slide-Wechsel den neuen Slide ansagen können, ohne dass Du manuell dorthin zurücknavigieren musst. Das ist entscheidend für Benutzer, die auf Tastaturnavigation oder Screenreader angewiesen sind, um den Inhalt des Karussells zu verstehen [11].
Wie kann ich testen, ob mein Karussell barrierefrei ist?
Das Testen ist echt 'ne Herausforderung, da automatisierte Tools wie WAVE oder Axe oft nicht in der Lage sind, dynamische Inhalte wie Karussells vollständig zu bewerten. Du musst manuell testen, also Tastaturnavigation checken (Tab, Pfeiltasten, Enter) [18], die Screenreader-Ansagen (z. B. VoiceOver, JAWS) [10] prüfen und sicherstellen, dass Du alle interaktiven Elemente ohne Maus bedienen kannst.
Welche Rolle spielt aria-roledescription in einem Karussell?
Das Attribut aria-roledescription [4] hilft dabei, eine spezifischere Beschreibung für die Rolle des Karussells zu liefern. Das macht es für Screenreader-Benutzer klarer, dass es sich hier um ein Karussell handelt. Du könntest zum Beispiel "Bilderkarussell" oder "Produktkarussell" verwenden, um Kontext zum Inhalt zu geben. Es wird vom Screenreader vorgelesen, wie es da steht, und Du solltest es in die Sprache des Nutzers übersetzen [5].
Sollte ich Radio-Buttons oder reguläre Schaltflächen für die Punktnavigation in einem Karussell verwenden?
Radio-Buttons sind die bessere Wahl für die Punktnavigation, da sie eine einfache Tastaturnavigation ermöglichen [18] und das Konzept der Auswahl eines bestimmten Slides vermitteln [8]. Sie unterstützen auch von Haus aus Tastaturinteraktionen wie PfeilLinks, PfeilRechts und Enter zur Auswahl, was sie zugänglicher macht als normale Buttons.
Wenn das mit den Radio-Buttons aber echt nicht klappt, kannst Du auch normale Buttons nehmen. Stell sicher, dass Du sie in eine <ul>-Liste mit <li>-Elementen packst [7] und dass sie fokussierbar und mit der Tastatur bedienbar sind [18]. Jede Schaltfläche sollte ein aria-label haben, um ihre Funktion zu beschreiben, wie z. B. "Gehe zu Slide 1", "Gehe zu Slide 2" usw. [9].
Warum sollte die automatische Rotationsfunktion eines Karussells steuerbar sein?
Die automatische Rotation sollte mit einer Pause/Wiedergabe-Schaltfläche steuerbar sein [15], damit Du die Rotation nach Wunsch anhalten oder starten kannst. Das ist unerlässlich für Benutzer, die mehr Zeit brauchen, um mit dem Inhalt zu interagieren, und stellt sicher, dass die Rotation nicht stört [14].
Was ist der beste Weg, das Fokusmanagement für aktive Slides in einem Karussell zu implementieren?
Wenn ein Benutzer mit Steuerelementen (Pfeilen oder Punkten) zu einem neuen Slide navigiert, solltest Du den Fokus auf die Überschrift des aktiven Slides verschieben [12]. Das hilft sicherzustellen, dass assistive Technologien wie Screenreader den Inhalt des aktiven Slides ansagen [11].
Wie gehe ich damit um, dass die automatische Rotation stoppt, wenn der Benutzer mit dem Karussell interagiert?
Die automatische Rotation sollte stoppen, wenn Du mit dem Karussell interagierst, indem Du ein Element fokussierst oder mit der Maus über den Inhalt fährst. Das verhindert unerwartete Slide-Wechsel, während Du gerade mit dem Inhalt beschäftigt bist [14]. Die Rotation sollte nur dann weitergehen, wenn Du sie explizit über die Pause/Wiedergabe-Schaltfläche wieder startest.
Wofür werden aria-live und aria-atomic in Karussells verwendet?
Das Attribut aria-live sagt Screenreadern, dass sie Änderungen dynamisch ansagen sollen, z. B. wenn sich die Karussell-Slides ändern [13]. Mit aria-live="polite" stellst Du sicher, dass die Änderung angesagt wird, ohne Deine aktuelle Aufgabe zu unterbrechen. Das Attribut aria-atomic="true" sorgt dafür, dass das gesamte Update angesagt wird, nicht nur die letzte Änderung.
Sollte ich Slide-Wechsel während der automatischen Rotation ansagen?
Nein, das ist nicht nötig. Slide-Wechsel während der Auto-Rotation musst Du nicht ansagen, da das ein Hintergrundprozess ist, der nicht Deine Aufmerksamkeit erfordert. Wenn Du jedoch manuell navigierst (z. B. mit den Buttons oder Punkten), sollte die Änderung angesagt werden [13].
Wie kann ich sicherstellen, dass Navigationsschaltflächen barrierefrei sind?
Navigationsschaltflächen (wie "Zurück" und "Weiter") solltest Du als <button>-Elemente mit aria-label-Attributen implementieren, um ihre Funktion zu beschreiben [9]. Das stellt sicher, dass sie fokussierbar, mit der Tastatur (über Enter oder Leertaste) bedienbar [18] und von Screenreadern korrekt angesagt werden [10].
Warum sollten verborgene Slides mit aria-hidden="true" markiert werden?
Verborgene Slides solltest Du mit aria-hidden="true" markieren, damit sie nicht von Screenreadern angesagt oder per Tastatur fokussierbar sind [10]. Das verhindert Verwirrung und stellt sicher, dass nur der aktive Slide interaktiv ist und angesagt wird.
Wie gehe ich mit Slide-Übergängen um, um Race Conditions zu vermeiden?
Um "Race Conditions" während der Übergänge zu vermeiden (z. B. dass das Karussell einen Slide überspringt), solltest Du das Fokusmanagement verzögern, bis der Übergang fertig ist. Das kannst Du mit setTimeout in JavaScript erreichen, um sicherzustellen, dass der Fokus erst nach Abschluss der Animation auf den aktiven Slide springt [11].
Warum sollte ich aria-posinset und aria-setsize auf jedem Slide implementieren?
Die Verwendung von aria-posinset und aria-setsize hilft, die Position und die Gesamtzahl der Slides im Karussell zu kommunizieren [8]. Das verbessert die Navigation für Screenreader-Benutzer. Zum Beispiel lässt "Folie 1 von 5" die Benutzer wissen, wie viele Slides es gibt und welcher gerade sichtbar ist.
Wie stelle ich sicher, dass das Karussell semantisch korrekt ist?
Stell sicher, dass Deine Karussell-Struktur semantische HTML-Elemente verwendet, wie <section> für den Container [1], <ul> und <li> für Slides [7] und <article> für den Inhalt in jedem Slide [1]. Verwende passende ARIA-Attribute wie aria-roledescription [4], aria-labelledby [3] und aria-hidden, um die Barrierefreiheit zu verbessern.
Sollte ich display: none oder inert für verborgene Slides verwenden?
Der empfohlene Weg, um Slides zu verbergen, ist die Nutzung von inert und aria-hidden="true". Das entfernt den Slide aus dem Accessibility Tree [10], während Animationen trotzdem möglich sind. Vermeide display: none für Slides, die eine Animation brauchen, da das nicht animierbar ist. Wenn Du keine Animationen brauchst, ist display: none okay, um Slides komplett auszublenden.
Sei aber vorsichtig mit dem inert-Attribut, da es vielleicht nicht in allen Browsern unterstützt wird. Wenn Du ältere Browser unterstützen musst, könntest Du visibility: hidden zusammen mit aria-hidden="true" nutzen, um den Inhalt auszublenden und ihn aus dem Accessibility Tree und der Tastaturnavigation zu entfernen. Das einzige Problem dabei: visibility: hidden entfernt den Slide nicht aus dem DOM, was zu Performance-Problemen führen kann, wenn Du viele Slides gleichzeitig versteckst.
Was bedeutet die Unterstützung der Tasten Home und End für Karussell-Punkte?
Wenn Du die Tasten Home und End in der Punktnavigation unterstützt, ermöglichst Du es Benutzern, schnell zum ersten oder letzten Slide zu springen. Das verbessert die Navigation für Tastaturbenutzer [18].
Zusätzlich kannst Du die Tasten Pfeil nach unten und Pfeil nach oben unterstützen, um jeweils zum nächsten oder vorherigen Slide zu navigieren, was eine intuitivere Navigation ermöglicht.
Was soll ich tun, wenn die Animation des Karussells Probleme mit den Screenreader-Ansagen verursacht?
Stell sicher, dass Screenreader-Ansagen während der Slide-Übergänge nicht unterbrochen werden. Um das zu vermeiden, verzögere die Ansage, bis der Übergang abgeschlossen ist, oder verwende aria-live="polite", um Inhaltsänderungen sanft anzusagen, ohne die User Experience zu stören [13].
Haftungsausschluss
Der Inhalt dieses Leitfadens dient ausschließlich zu Informationszwecken und stellt keine Rechtsberatung dar. Obwohl ich mich bemühe, genaue und aktuelle Informationen bereitzustellen, übernehme ich keine Gewähr für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Informationen. Die Einhaltung der Barrierefreiheitsstandards kann je nach spezifischem Kontext und Anwendungsfall variieren. Es wird empfohlen, bei der Implementierung von barrierefreien Karussells professionelle Beratung in Anspruch zu nehmen und regelmäßige Tests mit echten Benutzern durchzuführen, um sicherzustellen, dass die Anforderungen der WCAG-2.2-Richtlinien erfüllt werden. Ich hafte nicht für Schäden oder Verluste, die sich aus der Nutzung oder dem Vertrauen auf die in diesem Leitfaden enthaltenen Informationen ergeben.
Über den Autor