html-einfach.de

Barrierefreie Komponenten · Interaktive Widgets

Slider & Karussells barrierefrei

Von Zuletzt geändert am

Ich fange mit einer offenen Meinung an: Das barrierefreieste Karussell ist oft gar keins. Automatisch rotierende Bilderslider im Seitenkopf sehen in Mockups gut aus, doch die Nutzungsdaten geben ihnen selten recht – meist wird nur die erste Folie wahrgenommen, der Rest zieht ungesehen vorbei. Bevor ich ein Karussell baue, frage ich deshalb, ob eine schlichte Reihe von Inhalten denselben Zweck nicht besser erfüllt.

Wenn es aber ein Slider sein soll, dann richtig. Drei Themen entscheiden über die Zugänglichkeit: Bewegung kontrollierbar machen, mit der Tastatur bedienbar sein und Bewegungsempfindlichkeit respektieren.

Bewegung muss kontrollierbar sein

Sobald sich etwas automatisch bewegt, länger als fünf Sekunden läuft und neben anderem Inhalt steht, verlangen die WCAG eine Möglichkeit zum Pausieren, Stoppen oder Ausblenden (Kriterium 2.2.2). Ein automatisch weiterspringendes Karussell braucht also einen klar erreichbaren Pause-Button – und zwar einen echten <button>: 

<section aria-roledescription="Karussell" aria-label="Aktuelle Angebote">
  <button type="button" class="karussell-pause" aria-pressed="false">
    Automatischen Wechsel pausieren
  </button>
  …
</section>

Bewegung, die sich nicht anhalten lässt, ist nicht nur ein WCAG-Verstoß – sie kann Menschen mit Aufmerksamkeits- oder Gleichgewichtsstörungen aktiv stören. Der Pause-Button ist deshalb für mich keine Option, sondern Pflicht.

Bewegungsempfindlichkeit respektieren

Manche Menschen reagieren auf Animationen mit Schwindel oder Übelkeit. Das Betriebssystem kennt dafür eine Einstellung, die der Browser als prefers-reduced-motion weitergibt. Ein Karussell sollte sie ernst nehmen und bei aktivierter Reduktion nicht von selbst loslaufen:

@media (prefers-reduced-motion: reduce) {
  .karussell {
    scroll-behavior: auto;
  }
}
const reduziert = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
if (!reduziert) startAutoplay();

Mein Standard ist: Auto-Rotation startet nur, wenn keine Reduktion gewünscht ist – und selbst dann mit Pause-Button. Animation ist eine Einladung, keine Zwangsmaßnahme.

Tastatur und Fokus

Auch der Rest muss ohne Maus funktionieren:

  • Vor / Zurück sind echte Buttons, mit der Tastatur erreichbar und auslösbar.
  • Verdeckte Folien sind nicht fokussierbar. Links oder Buttons auf ausgeblendeten Slides gehören per hidden oder inert aus der Tab-Reihenfolge genommen – sonst tabbt man ins Leere.
  • Kein Auto-Wechsel bei Fokus oder Hover im Slider. Wer gerade liest oder bedient, sollte nicht von der nächsten Folie überrascht werden.

Worauf es bei Fokusreihenfolge und Sichtbarkeit grundsätzlich ankommt, steht unter Tastaturbedienung & sichtbarer Fokus.

Folienwechsel ankündigen

Wechselt der Inhalt durch Nutzerklick, hilft eine dezente Ansage, welche Folie nun zu sehen ist. Der APG-Ansatz beschreibt das Karussell per aria-roledescription="Karussell" und jede Folie als „X von N“. Wer Wechsel hörbar machen will, kann den Folienbereich als sanfte Live-Region (aria-live="polite") auszeichnen – sparsam, damit es nicht zur Dauerbeschallung wird.

Performance nicht vergessen

Karussells laden gern viele große Bilder auf einmal – das schadet der Ladezeit. Bilder unterhalb der ersten Folie lassen sich faul laden (loading="lazy"), und width/height beugen Layout-Sprüngen vor. Das Thema gehört eng zu den Core Web Vitals; ein schwergewichtiges Karussell ist überraschend oft die Ursache schlechter Werte.

Häufige Fehler

  • Auto-Rotation ohne Pause. Verstößt gegen WCAG 2.2.2 und stört.
  • prefers-reduced-motion ignoriert. Animation läuft, obwohl das System Reduktion signalisiert.
  • Verdeckte Folien bleiben fokussierbar. Tab landet auf unsichtbaren Elementen.
  • Pfeile als <div>. Ohne echten Button keine Tastaturbedienung.
  • Wechsel bei Hover/Fokus. Reißt Nutzende aus dem, was sie gerade tun.

Häufige Fragen

Sind Karussells grundsätzlich nicht barrierefrei?

Doch, sie lassen sich zugänglich bauen – es ist nur aufwendig, alles richtig zu machen. Meine ehrliche Empfehlung bleibt trotzdem, vorher zu prüfen, ob ein statisches Layout den Zweck nicht einfacher erfüllt.

Reicht ein Pause-Button, oder muss man auch stoppen können?

Pausieren genügt der WCAG-Anforderung. Wichtig ist, dass der Mechanismus sichtbar, erreichbar und eindeutig beschriftet ist.

Wie kennzeichne ich die aktive Folie in der Punkt-Navigation?

Die „Dots“ sind Buttons; der aktive bekommt einen erkennbaren Zustand, etwa aria-current="true" oder aria-pressed. Verlasse dich nicht allein auf die Farbe – ein Formunterschied hilft allen.

Fazit

Ein barrierefreies Karussell lässt sich pausieren, startet bei prefers-reduced-motion nicht von selbst, ist vollständig per Tastatur bedienbar und hält verdeckte Folien aus der Fokusreihenfolge. Das ist machbar – aber genug Aufwand, dass sich die Eingangsfrage lohnt: Braucht es das Karussell überhaupt, oder tut es eine ruhige Reihe von Inhalten nicht besser?