CSS-Karussell ohne JavaScript: der schlanke Slider

Der Kunde will auf der Startseite einen Slider: drei Angebote, die durchrotieren, mit Pfeilen und Punkten zum Weiterklicken. Ein Klassiker. Und fast reflexartig greifst du zur bewährten Lösung – eine JavaScript-Bibliothek wie Swiper oder Slick, schnell eingebunden, fertig. Der Preis dafür fällt erst später auf: ein paar hundert Kilobyte zusätzliches JavaScript, eine weitere Abhängigkeit, die du im Wartungsvertrag pflegen musst, und ein Skript, das beim Laden ruckelt, bis es sich initialisiert hat. Seit Chrome 135 gibt es für genau diesen Alltagsfall eine Alternative, die ohne eine einzige Zeile JavaScript auskommt.

Native CSS-Karussells verlagern die komplette Logik – Weiterblättern, Navigationspunkte, Tastaturbedienung – in den Browser. Das klingt nach einer Spielerei für Technik-Enthusiasten, ist aber ein handfester Hebel für kleine Agenturen: weniger Code, weniger Wartung, bessere Barrierefreiheit. Dieser Beitrag zeigt dir, wie es funktioniert, wo der Haken liegt und wann du es im Kundenprojekt einsetzen kannst.

CSS-Karussell ohne JavaScript: das steckt dahinter

Die Grundlage ist die Spezifikation CSS Overflow Module Level 5, die zwei neue Werkzeuge mitbringt. Beide bauen auf einem Fundament auf, das du wahrscheinlich schon kennst: scroll-snap. Damit rastet ein horizontal scrollbarer Container an definierten Punkten ein, sodass immer sauber ein Element im Bild steht statt einer halb abgeschnittenen Kachel. Das allein ergibt schon eine berührungsfreundliche, wischbare Galerie – aber ohne Pfeile und ohne Punkte.

Genau diese fehlenden Bedienelemente liefern die beiden Neuerungen. Das Pseudo-Element ::scroll-button() erzeugt echte, vom Browser verwaltete Schaltflächen, die einen Ausschnitt weiterblättern. Und ::scroll-marker() erzeugt die Navigationspunkte, mit denen Besucher direkt zu einer bestimmten Position springen können – jene kleinen Punkte unter dem Slider, die den aktuellen Stand anzeigen. Das Entscheidende: Beide sind keine Attrappen. Der Browser weiß, dass es sich um Navigationselemente handelt, und stattet sie automatisch mit den richtigen Rollen, der korrekten Tab-Reihenfolge und Screenreader-Unterstützung aus.

Wie wenig Code dafür nötig ist

Der Reiz der Lösung liegt in ihrer Schlankheit. Der Ausgangspunkt ist eine simple Liste – semantisch sauberes HTML, das auch ohne jedes Styling Sinn ergibt:

<ul class="karussell">
  <li>Angebot 1</li>
  <li>Angebot 2</li>
  <li>Angebot 3</li>
</ul>

Aus dieser Liste wird mit wenigen CSS-Regeln ein scrollbarer Streifen mit Einrastpunkten:

.karussell {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
}
.karussell > li {
  flex: 0 0 100%;
  scroll-snap-align: center;
}

Bis hierhin funktioniert das Wischen auf dem Smartphone bereits. Erst die neuen Pseudo-Elemente ergänzen die klassische Bedienung mit Pfeilen und Punkten:

/* Vor- und Zurück-Schaltflächen */
.karussell::scroll-button(left)  { content: "◀"; }
.karussell::scroll-button(right) { content: "▶"; }

/* Navigationspunkte unter dem Karussell */
.karussell { scroll-marker-group: after; }
.karussell > li::scroll-marker { content: ""; }
.karussell > li::scroll-marker:target-current { background: #0b5; }

Bemerkenswert daran ist, was du nicht tust: Du fügst keine <button>-Elemente ins HTML ein, du schreibst keine Klick-Handler, du verwaltest keinen Zustand, welcher Punkt gerade aktiv ist. Der Browser erledigt das. Erreicht die Schaltfläche das Ende des Streifens, deaktiviert er sie sogar automatisch, sodass du auch dafür keine Sonderbehandlung programmieren musst. Der Chrome-Entwicklerblog fasst das Prinzip treffend als „do less, reach more, faster" zusammen.

Der eigentliche Gewinn: Barrierefreiheit und Wartung

Warum lohnt sich der Umstieg über die Neugier hinaus? Zwei Argumente wiegen im Agentur-Alltag besonders schwer.

Das erste ist die Barrierefreiheit. Selbstgebaute JavaScript-Slider sind eine notorische Fehlerquelle für Screenreader und Tastaturnutzer: Oft fehlen die richtigen ARIA-Rollen, die Tab-Reihenfolge springt, oder die Pfeile lassen sich nur mit der Maus bedienen. Beim nativen Karussell kümmert sich der Browser um diese Details, weil er weiß, was ein Scroll-Button und was ein Scroll-Marker ist. Gerade seit dem Barrierefreiheitsstärkungsgesetz ist das kein akademischer Punkt mehr, sondern für viele Kundenseiten eine Pflicht – Hintergründe dazu liefert der Beitrag zur barrierefreien Website-Pflicht.

Das zweite Argument ist die Wartung. Jede JavaScript-Bibliothek, die du einbindest, ist Fremdcode: Sie will aktualisiert werden, kann Sicherheitslücken enthalten und bricht im schlimmsten Fall nach einem Framework-Update. Fällt eine solche Abhängigkeit weg, verschwindet eine Fehlerquelle aus jedem Wartungsvertrag. Weniger Drittanbieter-Code zahlt zugleich auf Tempo und Datenschutz ein – warum das zusammenhängt, vertieft der Beitrag Third-Party-Skripte reduzieren. Und weil kein Skript erst laden und sich initialisieren muss, entfällt das typische Nachrucken des Layouts, das die Core Web Vitals belastet.

Wofür sich das native Karussell im Kundenprojekt eignet

Nicht jeder Slider ist gleich, und die native Lösung spielt ihre Stärken vor allem dort aus, wo Besucher selbst blättern. Eine Logo-Leiste mit Referenzkunden, eine Reihe von Kundenstimmen, eine Produktgalerie oder die typischen „Das könnte dich auch interessieren"-Kacheln unter einem Blogartikel – all das sind Fälle, in denen der Nutzer die Kontrolle über das Tempo behält. Genau hier ist das CSS-Karussell der JavaScript-Bibliothek überlegen, weil es leichter, robuster und barrierefreier ist.

Wo die native Variante an Grenzen stößt, ist der automatisch rotierende Hero-Slider, der alle paar Sekunden von selbst weiterspringt. Ein solches Auto-Play lässt sich mit reinem CSS bislang nicht sauber umsetzen und bräuchte doch wieder ein kleines Skript. Das ist aber kein großer Verlust: Automatisch rotierende Hero-Slider gelten aus gutem Grund als problematisch, weil sie Inhalte wegnehmen, bevor Besucher sie erfassen konnten, und die Klickraten auf den einzelnen Bannern meist enttäuschen. Der Verzicht darauf ist oft die bessere Entscheidung – nicht nur die technisch einfachere.

Der Haken: der Browser-Support

So elegant die Lösung ist – hier kommt die notwendige Ehrlichkeit. Native CSS-Karussells sind noch kein sicherer Standard. ::scroll-button() und ::scroll-marker() werden derzeit von Chrome und Edge ab Version 135 unterstützt, also von den Chromium-basierten Browsern. Firefox und Safari haben die Funktion zum Zeitpunkt dieser Analyse noch nicht implementiert. Die globale Unterstützung liegt damit bei rund 72 Prozent – ordentlich, aber eben nicht flächendeckend. Den Baseline-Status, der ein Feature als browserübergreifend sicher ausweist, hat das Karussell also noch nicht erreicht. Was dieser Status genau bedeutet, erklärt der Beitrag Baseline 2026.

Das klingt zunächst nach einem Ausschlusskriterium, ist aber keins – vorausgesetzt, du gehst richtig damit um. Der Schlüssel heißt Progressive Enhancement, und das native Karussell ist dafür wie geschaffen.

Warum du es trotzdem heute nutzen kannst

Der Trick liegt darin, wie die Lösung aufgebaut ist. Das Fundament – die scrollbare Liste mit scroll-snap – funktioniert in allen modernen Browsern, auch in Firefox und Safari. Ein Besucher mit Safari sieht also weiterhin einen sauber einrastenden, wischbaren Streifen; er kann alle Inhalte erreichen, indem er wischt oder mit dem Trackpad scrollt. Was ihm fehlt, sind allein die zusätzlichen Pfeile und Punkte, die über die Pseudo-Elemente kommen. Der Inhalt bleibt vollständig zugänglich, nur die Komfort-Bedienung ist reduziert.

Das ist der Kern von Progressive Enhancement: Du baust eine Basis, die überall funktioniert, und legst die schicke Verbesserung obendrauf für die Browser, die sie beherrschen. Fällt sie weg, bleibt die Seite benutzbar – niemand steht vor einem kaputten Element. Für einen Kunden mit moderner, Chrome-lastiger Zielgruppe kannst du die native Variante damit heute schon guten Gewissens einsetzen. Für ein Projekt, dessen Besucher zu großen Teilen Safari auf dem iPhone nutzen, entscheidest du bewusst, ob dir der reine Scroll-Streifen als Fallback genügt – oder ob du für diese Zielgruppe vorerst bei einer bewährten Lösung bleibst und das native Karussell erst nachrüstest, wenn Firefox und Safari nachgezogen haben. Diese Zielgruppen-Frage beantwortest du am besten mit einem Blick in die Browser-Statistik des jeweiligen Kunden.

Fazit

Native CSS-Karussells sind eines dieser Features, das eine wiederkehrende, lästige Aufgabe aus dem Agentur-Alltag verschlanken kann: Statt eine JavaScript-Bibliothek einzubinden und zu pflegen, überlässt du dem Browser die Arbeit – mit besserer Barrierefreiheit als Zugabe. Der Preis ist der noch lückenhafte Browser-Support, doch weil sich die Lösung sauber als Verbesserung über einer funktionierenden Basis aufbauen lässt, musst du auf sie nicht warten. Wer das Fundament aus scroll-snap richtig legt und die neuen Pseudo-Elemente als Bonus obendrauf setzt, liefert schon heute schlankere, robustere Kundenseiten – und ist vorbereitet, wenn das Feature in ein, zwei Jahren zum Standard wird.