BFSG 2025: Warum Karusselle so oft bei Barrierefreiheit scheitern

Wie die DSGVO 2018 hat das BFSG 2025 das Potenzial, den deutschen Onlinemarkt grundlegend zu verändern — denn barrierefreie Websites sind seit dem 28. Juni 2025 gesetzlich vorgeschrieben. Fast jeder, der online Dienstleistungen anbietet, ist betroffen. Die meisten merken es erst, wenn die ersten Abmahnungen kommen — und dann ist die Frage nicht mehr ob man investiert, sondern wie viel.

Diese Serie ist ein praxisnaher Guide durch die häufigsten Fehler beim Bau barrierefreier Websites — was WCAG und BFSG konkret fordern, und wo Umsetzungen in der Realität immer wieder scheitern. Als roter Faden dient das Karussell: eine Komponente, die fast überall im Web zu finden ist und dabei so viele typische Accessibility-Fehler auf einmal vereint wie kaum eine andere.

Wir bei typedigital entwickeln seit Jahren digitale Produkte — Web- und Applikationen für Startups, Mittelständler und etablierte Unternehmen. Barrierefreiheit begegnet uns dabei in fast jedem Projekt: als nachträgliche Anforderung, als übersehenes Audit-Ergebnis, als Grund für eine Projektverschiebung. Diese Serie entstand aus genau diesen Erfahrungen — und aus der Überzeugung, dass die meisten Fehler vermeidbar wären, wenn man wüsste, wo sie entstehen.

Das BFSG: Was sich geändert hat

Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) hat Deutschland den European Accessibility Act in nationales Recht umgesetzt. Wer über eine Website elektronische Dienstleistungen erbringt — Online-Shops, Buchungsformulare, Kontaktmöglichkeiten — ist seither gesetzlich zur Barrierefreiheit verpflichtet.

Der technische Maßstab ist die europäische Norm EN 301 549, die für Websites direkt auf die WCAG 2.1 Level AA verweist. Bei Verstößen drohen Bußgelder bis 100.000 Euro, Abmahnungen durch Mitbewerber und Verbraucherverbände sowie die behördliche Untersagung des Angebots. Letzteres bedeutet im Extremfall: Der Online-Shop geht offline.

Ausgenommen sind nur Kleinstunternehmen mit weniger als zehn Beschäftigten und unter zwei Millionen Euro Jahresumsatz — aber nur, wenn sie Dienstleistungen erbringen. Wer Produkte herstellt, ist auch als Kleinstunternehmen trotzdem nicht sicher. Alle Produkte und Dienstleistungen, die unter das BFSG fallen, sind in §1 Abs. 2 und 3 des BFSG aufgelistet.

Wer kämpft mit schlechten Karussellen?

Die betroffene Gruppe ist größer als oft angenommen:

Tastatur-Nutzer:innen können eine Komponente ohne fokussierbare Navigationselemente schlicht nicht bedienen. Das betrifft nicht nur Menschen mit dauerhaften motorischen Einschränkungen, sondern jeden, der die Maus gerade nicht zur Hand hat.

Screenreader-Nutzer:innen erleben automatisch rotierende Karusselle als akustisches Chaos — oder als vollständiges Schweigen, wenn keinerlei Zustandsänderungen kommuniziert werden.

Menschen mit vestibulären Störungen oder Epilepsie können durch Animationen Schwindel oder schlimmeres erleiden. CSS kennt dafür heute prefers-reduced-motion — aber die wenigsten Karusselle respektieren diese Einstellung.

Ältere Nutzer:innen kombinieren oft mehrere dieser Aspekte: reduzierte Sehschärfe, langsamere Reaktionszeit, verringerte Feinmotorik. Touch-Targets von 8 Pixeln Durchmesser sind für sie keine Kleinigkeit.

Laut Statistischem Bundesamt leben in Deutschland rund 7,8 Millionen Menschen mit einer anerkannten Schwerbehinderung. Dazu kommen Millionen mit temporären Einschränkungen und eine wachsende ältere Bevölkerung. Die Summe übersteigt bei weitem die Zahl derer, die dauerhaft auf assistive Technologien angewiesen sind.

Was WCAG 2.2 konkret fordert

Drei Kriterien sind für Karusselle besonders relevant:

Bedienbarkeit ohne Maus (WCAG 2.1.1, Level A): Alle Funktionen müssen über die Tastatur erreichbar sein — Navigation zwischen Slides, Kontrolle der Rotation, Interaktion mit Slide-Inhalten.

Kontrolle über bewegte Inhalte (WCAG 2.2.2, Level A): Automatisch rotierende Inhalte, die länger als fünf Sekunden laufen, brauchen einen Mechanismus zum Pausieren oder Stoppen. Ein Karussell ohne Pause-Button erfüllt dieses Kriterium nicht.

Ausreichende Touch-Targets (WCAG 2.5.8, Level AA): Mindestens 24 × 24 Pixel, empfohlen 44 × 44 Pixel. Die Punkte einer typischen Dot-Navigation liegen meistens weit darunter.

Warum Karusselle strukturell schwer zu machen sind

Ein Button hat eine Rolle, einen Zustand, ein Label — und das war es. Ein Karussell ist ein zusammengesetztes System: ein Container mit Landmark-Semantik, individuelle Slides mit Positionsinformation, Navigationsbuttons mit dynamischen Labels, eine Live-Region für Zustandsankündigungen, und ein Fokus-Management, das über das gesamte System konsistent funktionieren muss.

Jede dieser Schichten hat eigene ARIA-Anforderungen. Und sie interagieren miteinander: Was angekündigt wird, hängt davon ab, ob gerade automatisch rotiert wird. Welche Slides fokussierbar sind, hängt davon ab, welche gerade sichtbar sind. Das sind echte Edge Cases, die in realen Implementierungen immer wieder scheitern.

Deshalb ist „nachträgliche Barrierefreiheit" bei Karussellen besonders kostspielig. Eine Komponente, die von Grund auf zugänglich gebaut wurde, sieht aus wie jede andere — und funktioniert für alle. Eine, die nachträglich angepasst werden soll, muss oft strukturell neu gebaut werden. In der Praxis bedeutet das: Wer Barrierefreiheit nicht von Anfang an einplant, zahlt sie später doppelt — in Entwicklungszeit, in Projektbudget und im schlechtesten Fall als Bußgeld.

Was als Nächstes kommt

Diese Serie arbeitet das Thema Schicht für Schicht auf:

Teil 2 — Wie erkennt ein Screenreader ein Karussell? ARIA-Rollen, Slide-Struktur, konkrete Screenreader-Ausgaben mit NVDA, JAWS und VoiceOver.

Teil 3 — Tastaturnavigation und Fokus Management: welche Tasten, welche Reihenfolge, und was das inert-Attribut damit zu tun hat.

Teil 4 — aria-live, Autoplay und das Ankündigungsproblem: wann soll ein Screenreader sprechen, wann nicht.

Teil 5 — Touch Targets, Swipe-Gesten und prefers-reduced-motion: Karusselle für alle Eingabegeräte.

Teil 6 — faceless-carousel: eine Open-Source Web Component, die alles aus dieser Serie accessible by design umsetzt — ohne dem Entwickler gestalterische Freiheit zu nehmen.

→ Teil 2 lesen: Semantik zuerst — ARIA Roles & Slide-Struktur

Quellen: W3C APG — Carousel Pattern · WCAG 2.2 · Nielsen Norman Group — Auto-Forwarding · Statistisches Bundesamt — Schwerbehinderte Menschen