In der Welt der Webentwicklung gewinnen CSS-Carousels als moderne Möglichkeit, interaktive Bild- und Content-Slider ganz ohne JavaScript umzusetzen, zunehmend an Aufmerksamkeit. Diese innovative Methode verspricht schlankeren Code und performantere Webseiten. Doch mit dem Trend zur Nutzung der neuen CSS Overflow Module 5 Spezifikation stellen sich wichtige Fragen: Sind CSS-Carousels tatsächlich barrierefrei und nutzerfreundlich für Menschen mit Behinderungen? Welche technischen Herausforderungen bestehen und welche Auswirkungen haben die neuartigen scroll-marker Pseudo-Elemente auf die Usability? Eine eingehende Analyse zeigt, dass trotz ihres innovativen Charakters CSS-Carousels gegenwärtig mit erheblichen Barrierefreiheitsproblemen kämpfen und daher bislang für den produktiven Einsatz nicht empfohlen werden können. CSS-Carousels basieren auf einer Reihe experimenteller CSS-Funktionen, die im CSS Overflow Modul Level 5 definiert sind. Diese ermöglichen die Implementierung interaktiver Scroll-Markers, sogenannten ::scroll-marker Pseudo-Elementen, die als Navigationspunkte innerhalb eines überlaufenden Containers fungieren.
Die Kernidee ist, eine JavaScript-freie Alternative für bekannte UI-Muster wie Slider oder Karussells zu schaffen, bei denen Nutzer per Klick oder Tastatur durch Inhalte navigieren können. Innovative Features wie scroll-marker-Gruppen (::scroll-marker-group) und scroll-buttons (::scroll-button()) dienen dabei als visuelle und interaktive Hilfsmittel. Theoretisch ist die Idee hinter diesen Features reizvoll: Entwickler sollen leichter und übersichtlicher intuitiv bedienbare Navigationsmechanismen direkt mittels CSS umsetzen können. Jedoch zeigt die aktuelle Implementierung, die derzeit ausschließlich experimentell unter Chrome Canary mit aktivierten Flags verfügbar ist, wesentliche Schwächen in puncto Barrierefreiheit. Ein entscheidendes Problem besteht darin, dass die durch CSS definierten scroll-marker Pseudo-Elemente nicht echte HTML-Elemente sind, sondern rein visuelle und interaktive Konstrukte, die vom Browser dennoch in der Barrierefreiheitsstruktur (Accessibility Tree) repräsentiert werden müssen.
Der Accessibility Tree spiegelt die Rolle, den Namen, den Status und die Beziehung von Elementen wider, damit Screenreader und andere assistive Technologien für Nutzer verständlich werden. Aktuell interpretiert Chrome diese scroll-marker-Gruppen als sogenannte Tabs Widgets, wobei jedes scroll-marker-Element einem Tab innerhalb einer Tab-Liste (tablist) entspricht. Allerdings ist diese Semantik bei genauerer Betrachtung für die meisten Anwendungsfälle von Carousels unpassend. Klassische Tabs zeichnen sich dadurch aus, dass jeweils nur ein sichtbarer Inhaltspanel angezeigt wird, und andere Panels ausgeblendet sind. Im Gegensatz dazu zeigen Carousels häufig mehrere Elemente gleichzeitig an, was eine Mehrfachauswahl nahelegt.
Diese Diskrepanz führt zu Inkonsistenzen: Obwohl mehrere Inhalte sichtbar sind, wird im Accessibility Tree jeweils nur ein Tab als aktiv (aria-selected=true) markiert. Dies widerspricht gängigen ARIA-Standards und führt zu Verwirrung bei Screenreader-Nutzern, die nicht nachvollziehen können, welche Inhalte gerade sichtbar sind. Darüber hinaus mangelt es den CSS-Carousels vielfach an individuellen, beschreibenden und eindeutigen zugänglichen Namen für die Tabs beziehungsweise scroll-marker. Sichtbare „Punkte“ oder Indikatoren werden oftmals nur mit generischen Texten wie „Carousel item marker“ versehen, die für Blinde und Sehbehinderte keinerlei differenzierende Information liefern. Eine reine Benennung über die CSS-content-Eigenschaft ist nicht nur eine Herausforderung für die Wartbarkeit, sondern wird von Screenreadern teils nur unzureichend umgesetzt.
Dadurch ist die Orientierung stark beeinträchtigt, Nutzer wissen kaum, auf welchen Punkt sie sich bewegen oder was sie erwarten dürfen. Einzigartige und aussagekräftige Labels sind unabdingbar für effektive Barrierefreiheit. Auch das Zusammenspiel mit Keyboard-Navigation zeigt erhebliche Defizite. Die in den CSS-Carousels generierten scroll-marker-Gruppen erhalten zwar einen einzelnen Tab-Stop, innerhalb dessen dann mit den Pfeiltasten navigiert wird – analog einem Tabs-Widget. Allerdings entspricht das nicht der typischen Bedienlogik von Carousels, die häufig ebenfalls Pfeiltasten-Steuerung für das Verschieben einzelner Elemente benötigen.
Zudem werden aktiv sichtbare Inhalte oft nicht korrekt fokussiert, und der Fokus bleibt teilweise sogar auf deaktivierten oder ausgeblendeten Buttons, was eine konsistente und intuitive Bedienung erschwert. Die fehlende Synchronisation zwischen sichtbarem Zustand und semantischer Auszeichnung mindert die Nutzererfahrung erheblich. Darüber hinaus wurden weitere Barrieren beobachtet, zum Beispiel das Fehlen von Rollen für Scroll-Buttons, die oftmals ebenfalls keine eindeutigen, zugänglichen Namen enthalten, sodass deren Funktionalität für Assistive-Technologien-Nutzer unklar ist. Auch das Problem, dass CSS-Carousels Inhalte nicht wirklich ausblenden, sondern nur aus dem Sichtbereich scrollen, führt dazu, dass unsichtbare Elemente noch per Tastatur oder Screenreader erreicht werden können. Das widerspricht der ARIA-Empfehlung bei Tabs, wo inaktive Panels üblicherweise mit aria-hidden versteckt werden, um unnötige Verwirrung zu vermeiden.
Des Weiteren ist problematisch, dass viele der Accessibility-Rollen und Attribute nicht vom Browser automatisch zugewiesen werden, sondern vom Entwickler manuell ins Markup implementiert werden müssen, was bei reinem CSS-Ansatz nicht vorgesehen ist. Beispielsweise fehlen oft die tabpanel-Rollen, die laut ARIA-Spezifikation zwingend zu Tabs dazugehören. Ebenfalls bleibt unklar, wie sich diese semantischen Rollen verhalten, wenn CSS nicht geladen wird, beispielsweise in Reader-Modi oder bei deaktiviertem CSS. So fehlt die nötige Zuverlässigkeit und Robustheit bei der Accessibility-Implementierung. Aus inhaltlicher Sicht stoßen CSS-Carousels damit an Grenzen, die exemplarisch verdeutlichen, dass Barrierefreiheit mehr ist als das Erreichen optischer Interaktion.
Es geht um nachvollziehbare, verständliche und konsistente semantische Strukturen in der Code-Basis. Semantik gehört ins HTML und nicht ins CSS. Die Architektur von Web-Komponenten sollte Separation of Concerns respektieren, damit Inhalte, Präsentation und Bedeutung klar getrennt sind – auch im Sinne der Barrierefreiheit. Deshalb plädieren viele Accessibility-Experten und Entwickler für die Entwicklung nativer HTML-Elemente mit eingebauter barrierefreier Funktionalität für UI-Komponenten wie Tabs, Carousels und Slider. Solche nativen Elemente könnten standardisierte Rollen, Tastaturbedienung und die korrekte Verwaltung von Zuständen und Beschriftungen bereitstellen – eine deutlich robustere Lösung für Entwickler und Nutzer gleichermaßen.
Aktuelle Diskussionen bei Gemeinschaften wie OpenUI erforschen solche nativen Komponenten und bemühen sich um umfassende Nutzerforschung und Barrierefreiheits-Reviews. Langfristig könnte dies für alle Beteiligten zu besseren, sichereren und zugänglicheren Web-Interfaces führen, die nicht nur im modernen Browser glänzen, sondern auch den anspruchsvollen Vorgaben von WCAG und ARIA gerecht werden. Bis dahin empfiehlt sich ein vorsichtiger Umgang mit den experimentellen Features rund um CSS-Carousels. Entwickler sollten sich nicht auf das vermeintliche Accessibility-Handling des Browsers verlassen, sondern aktiv eigene Barrierefreiheitsmaßnahmen einbauen, umfangreiche Tests mit Screenreadern und Tastatur durchführen und im Zweifel auf bewährte, JavaScript-unterstützte Slider-Lösungen zurückgreifen. Es liegt in der Verantwortung der Webentwickler, barrierefreie Nutzererfahrungen zu schaffen und nicht nur optisch funktionierende, sondern auch semantisch saubere und technisch zugängliche Komponenten auszuliefern.
Solange CSS-Carousels diesen Anforderungen nicht gerecht werden, sollten sie nicht unkritisch im produktiven Web eingesetzt werden. Zusammenfassend lässt sich sagen, dass CSS-Carousels trotz ihrer technischen Innovation aktuell ein deutliches Risiko für die Zugänglichkeit von Webseiten darstellen. Sie bergen zahlreiche Stolpersteine besonders bei der Nutzung durch Menschen mit Behinderungen, die auf Assistive Technologien angewiesen sind. Solche Nutzer verlieren häufig den Überblick, erhalten unklare oder inkonsistente Informationen und können das Interface nicht mit den erwarteten Tastaturbefehlen bedienen. Die Zukunft der Barrierefreiheit bei interaktiven Web-Elementen liegt vermutlich in der Kombination aus nativem HTML, konsistentem ARIA-Einsatz und unterstützenden CSS-Visualisierungen.
Die barrierefreien Anforderungen müssen von Anfang an ins Konzept und nicht nachträglich hinzugefügt werden. Nur so ist ein inklusives Web für alle Menschen erreichbar – passend zur großen Bedeutung, die Barrierefreiheit heute im digitalen Raum besitzt.
