Construire un carrousel sans une ligne de JavaScript : c'est la promesse de CSS Overflow Module Level 5, désormais implémentée dans Chrome et Edge depuis la version 135 (mars 2025). Avec scroll-marker-group, ::scroll-marker et ::scroll-button(), le navigateur génère lui-même les points de pagination et les flèches de navigation d'un slider, à partir d'une liste HTML toute simple.

C'est séduisant sur le papier : moins de JS à charger, moins de bugs de synchronisation entre le scroll et l'état visuel, et une sémantique qui reste celle d'une liste. Mais en 2026, l'histoire est plus nuancée. Le support reste cantonné à Chromium, et les premières implémentations ont buté sur de vrais problèmes d'accessibilité que Chrome a dû corriger après coup.

Voici ce qui fonctionne réellement aujourd'hui, ce qui manque encore, et comment adopter ces propriétés sans casser l'expérience des visiteurs sur Safari ou Firefox.

La mécanique : trois pseudo-éléments pour un carrousel complet

Le principe de base : tu pars d'une liste scrollable classique, et tu laisses CSS générer les contrôles autour.

<ul class="carousel">
  <li>Slide 1</li>
  <li>Slide 2</li>
  <li>Slide 3</li>
</ul>

.carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  /* place le groupe de marqueurs après le conteneur */
  scroll-marker-group: after;
}

.carousel li {
  scroll-snap-align: center;
}

/* un point par slide, généré automatiquement */
.carousel li::scroll-marker {
  content: ""; /* content est obligatoire, sinon rien ne s'affiche */
  width: 10px;
  height: 10px;
  border-radius: 50%;
  background: #ccc;
}

/* le point correspondant à la slide visible */
.carousel li::scroll-marker:target-current {
  background: #111;
}

La propriété scroll-marker-group (valeurs none, before ou after, none par défaut) indique au navigateur de créer un conteneur regroupant tous les ::scroll-marker. Ce groupe ne prend qu'un seul arrêt de tabulation dans la page : une fois dedans, on navigue entre les points avec les flèches du clavier, pas avec Tab répété. C'est un vrai gain d'accessibilité clavier par rapport à la plupart des implémentations JS maison.

Les flèches avec ::scroll-button()

Même logique pour les boutons précédent/suivant, générés directement sur le conteneur :

.carousel::scroll-button(left) {
  content: "◀";
}

.carousel::scroll-button(right) {
  content: "▶";
}

/* désactive visuellement le bouton en bout de course */
.carousel::scroll-button(right):disabled {
  opacity: 0.3;
}

Le navigateur gère lui-même l'état désactivé en fin de scroll, via le pseudo-état :disabled — plus besoin de calculer manuellement si on a atteint la dernière slide.

Le support réel en 2026 : Chromium seul pour l'instant

C'est le point à retenir avant de se lancer en production : seuls Chrome et Edge (à partir de la version 135) supportent ces pseudo-éléments, ainsi qu'Opera et Samsung Internet à partir de versions équivalentes. Ni Safari ni Firefox ne les implémentent à ce jour. La spécification elle-même, CSS Overflow Module Level 5, est toujours au stade de brouillon au sein du W3C — des points comme la gestion du focus continuent d'être discutés en groupe de travail.

Bonne nouvelle : l'essentiel du carrousel — le défilement horizontal avec accroche sur chaque slide — repose sur scroll-snap-type et scroll-snap-align, qui sont stables et largement supportés depuis 2024. Sur Safari ou Firefox, en l'absence de ::scroll-marker et ::scroll-button(), ton carrousel reste donc parfaitement utilisable : il se scrolle et s'accroche normalement, simplement sans les points ni les flèches générés automatiquement.

Ce que ça change vraiment côté performance et maintenance

Au-delà de l'aspect « gadget », le gain concret se mesure en poids de dépendances. Les librairies de carrousel JS les plus courantes pèsent souvent plusieurs dizaines de kilo-octets une fois minifiées, sans compter le CSS additionnel qu'elles embarquent. Avec ::scroll-marker et ::scroll-button(), le rendu, l'état actif et la gestion du focus clavier sont entièrement pris en charge par le moteur de rendu : zéro script à télécharger, zéro écouteur d'événement scroll à débouncer, zéro risque de décalage entre l'état visuel et la position réelle de défilement.

C'est aussi un gain de maintenance à long terme. Un carrousel JS maison accumule vite des correctifs ad hoc pour gérer le resize, le swipe tactile, le focus trap ou la synchronisation des points — autant de code applicatif que l'équipe doit continuer à faire vivre. En confiant cette logique au navigateur, ces bugs deviennent la responsabilité du moteur de rendu, et non plus la tienne.

Le vrai piège : l'accessibilité, pas le support navigateur

Le support partiel n'est pas le problème le plus sérieux. La consultante en accessibilité Sara Soueidan a publié début 2025 une analyse détaillée concluant que les carrousels CSS, dans leur implémentation initiale, n'étaient pas prêts pour la production — pas uniquement à cause du support navigateur, mais en raison de défauts d'accessibilité concrets.

Chrome a depuis corrigé plusieurs de ces défauts, documentés dans un billet de suivi publié en septembre 2025 : par exemple, tous les ::scroll-marker étaient annoncés par les lecteurs d'écran comme « sélectionné », quelle que soit la slide active, et le marqueur ne reprenait pas automatiquement de nom accessible depuis sa valeur content. Sans texte alternatif explicite, un lecteur d'écran peut encore annoncer quelque chose d'aussi peu parlant que « sélectionné, tab, 1 sur 5 » — à toi de fournir un contenu plus clair via content ou un attribut ARIA.

Retiens cette leçon : une fonctionnalité qui « marche visuellement » dans Chrome ne veut pas dire qu'elle est accessible par défaut. Teste systématiquement au clavier et avec un lecteur d'écran avant de remplacer un carrousel JS existant.

Dans ce domaine, une spécification qui bouge encore au sein du groupe de travail W3C veut dire des correctifs réguliers — pas seulement de nouvelles fonctionnalités, mais aussi des changements de comportement sur l'existant. Si tu adoptes ces propriétés dès maintenant, prévois de revérifier ton implémentation à chaque mise à jour majeure de Chrome, et pas uniquement au moment où tu l'as écrite.

Adopter ces propriétés sans rien casser

La bonne approche en 2026 consiste à traiter ces pseudo-éléments comme un progressive enhancement, jamais comme une dépendance :

Garde scroll-snap-type et scroll-snap-align comme base fonctionnelle sur tous les navigateurs.
Ajoute scroll-marker-group, ::scroll-marker et ::scroll-button() en couche supplémentaire : là où ils sont supportés, l'expérience s'enrichit ; ailleurs, elle reste intacte.
Vérifie le support avec @supports selector(::scroll-marker) si tu dois adapter d'autres styles en fonction de leur présence.
Donne toujours un content explicite et testable par un lecteur d'écran aux marqueurs — jamais une simple forme vide sans alternative textuelle.
Ne mise pas encore sur le défilement en boucle (looping carousel) : il n'est pas couvert par la spécification actuelle et reste un sujet de discussion pour les futures révisions.

@supports selector(::scroll-marker) {
  .carousel .fallback-dots {
    display: none; /* masque tes points JS si le CSS natif prend le relais */
  }
}

Pour un carrousel d'images décoratif à faible enjeu (une galerie promotionnelle, par exemple), ces propriétés permettent déjà de supprimer une dépendance JS entière sur Chrome et Edge, qui couvrent une large majorité du trafic desktop. Pour un composant critique — navigation produit, étapes d'un tunnel d'achat — garde une librairie JS éprouvée ou un carrousel scroll-snap maison tant que Safari et Firefox n'ont pas rattrapé le train, et tant que les retours d'accessibilité sur les nouvelles implémentations ne sont pas stabilisés.

En résumé : ::scroll-marker et ::scroll-button() méritent d'être testés dès maintenant sur des cas non critiques, avec @supports en garde-fou et un audit clavier/lecteur d'écran systématique — mais ils ne remplacent pas encore, à eux seuls, une solution JS pour tout composant où l'accessibilité ne tolère pas l'approximation.

Carrousels CSS natifs : ::scroll-marker, le piège accessibilité