Dans l’univers du webdesign, les sliders, aussi appelés carrousels ou bannières rotatives, ont longtemps servi à présenter plusieurs messages dans un espace réduit. Ils règlent surtout un problème de réunion : quand trois services se disputent la page d’accueil, faire défiler évite de trancher. Une analyse sérieuse, du point de vue de l’accessibilité, de l’expérience utilisateur, de la performance et de l’éco-conception, révèle des inconvénients qui dépassent largement leur intérêt.
Un carrousel est un composant qui affiche une série d’éléments un par un dans un même cadre, avec des contrôles de navigation et, le plus souvent, une rotation automatique. Cette définition simple cache trois mécanismes coûteux : du contenu chargé mais invisible, du mouvement que le visiteur n’a pas demandé, et du JavaScript qui s’exécute en continu. Chacun de ces mécanismes a un effet mesurable sur les Core Web Vitals, et un effet documenté sur l’accessibilité.
Cet article examine en détail pourquoi les carrousels sont à éviter dans la conception de sites modernes, en s’appuyant sur les critères WCAG, sur les données d’interaction publiées et sur la documentation des métriques de Google, puis ce qu’il faut mettre à la place. Combien de vos visiteurs voient réellement la deuxième diapositive, et ce qu’elle leur coûte avant même de s’afficher ?
Pourquoi un carrousel pose-t-il un problème d’accessibilité ?
Parce qu’il cumule du mouvement automatique, du contenu masqué et une navigation complexe, trois points que les WCAG encadrent explicitement. Le critère 2.2.2 impose un mécanisme de pause pour tout contenu qui bouge automatiquement plus de cinq secondes, et le critère 2.3.1 interdit plus de trois flashs par seconde. Un carrousel par défaut enfreint le premier et flirte avec le second.
Le mouvement automatique, un critère de niveau A
Le critère 2.2.2 Pause, Stop, Hide des WCAG 2.2 est précis : pour toute information qui bouge, clignote ou défile, qui démarre automatiquement, dure plus de cinq secondes et s’affiche en parallèle d’un autre contenu, l’utilisateur doit disposer d’un mécanisme pour la mettre en pause, l’arrêter ou la masquer. La documentation ajoute qu’une animation qui ne s’arrête que tant que le focus reste dessus ne compte pas comme un mécanisme de pause. Un carrousel qui tourne toutes les cinq secondes sans bouton de pause visible échoue à un critère de niveau A, le plus bas des trois.
Le mouvement est aussi un problème de santé. Les contenus clignotants peuvent induire des crises chez les personnes épileptiques photosensibles, ce que borne le critère 2.3.1 : rien ne doit flasher plus de trois fois par seconde. Les transitions rapides entre diapositives contrastées s’en approchent. Et pour les personnes atteintes de troubles vestibulaires, MDN rappelle que la media query prefers-reduced-motion existe précisément pour détecter qu’un utilisateur a demandé à réduire les animations non essentielles. La plupart des bibliothèques de carrousel l’ignorent, et notre guide sur les préférences utilisateur montre qu’elle coûte deux lignes de CSS.
Le clavier, le focus et les technologies d’assistance
Les personnes qui naviguent au clavier, à la commande vocale ou au suivi oculaire rencontrent une seconde difficulté : les contrôles du carrousel. Le tutoriel de la Web Accessibility Initiative exige que toute fonctionnalité, y compris la navigation entre les éléments, soit utilisable au clavier, et que la position du focus soit gérée de façon raisonnable et compréhensible.
Dans la pratique, le focus part souvent sur une diapositive masquée, puis sur des boutons qui se chevauchent, pendant que le contenu change sous les doigts de l’utilisateur. Le même tutoriel note que les carrousels sont contestés du point de vue de l’utilisabilité, parce que leur contenu est difficile à découvrir.
Ces exigences ne sont plus seulement des recommandations. Le référentiel français, que détaille notre guide sur le RGAA et l’accessibilité numérique, reprend les critères WCAG de niveau A et AA, et l’obligation légale s’est étendue en juin 2025 à une large part des services privés. Un carrousel non conforme n’est donc plus un détail d’ergonomie, c’est un point de non-conformité dans un audit réglementaire, et l’un des plus faciles à retirer.
Les visiteurs cliquent-ils vraiment sur un carrousel ?
Presque jamais. L’étude d’Erik Runyon sur le site de l’université Notre Dame, publiée le 22 janvier 2013 et toujours la référence sur le sujet, relève qu’environ 1 % des visiteurs cliquent sur un élément du carrousel, et que 84 % de ces clics vont à la première diapositive. Les quatre suivantes se partagent 16 % d’un pour cent.
Ce que disent les chiffres d’interaction
Les statistiques de Runyon ont été relevées de mi-octobre 2012 au 22 janvier 2013 sur plusieurs sites de l’université : 28 928 clics sur les éléments mis en avant, 315 665 changements manuels de diapositive, et une concentration massive sur la position 1, les autres se partageant environ 4 % chacune. Une précision de méthode que l’on omet souvent : ces chiffres concernent un carrousel à défilement manuel. Le seul carrousel à rotation automatique de l’étude faisait mieux, 8,8 % de visiteurs cliquant, dont 40 % sur la première position, ce qui reste un rendement dérisoire pour l’élément le plus visible de la page.
Le phénomène a un nom, la cécité aux bannières, ou banner blindness : les visiteurs ignorent instinctivement les zones qu’ils associent à de la publicité, et un carrousel en ressemble à s’y méprendre. Jakob Nielsen l’avait formulé dès la même semaine de janvier 2013, dans un article du Nielsen Norman Group qui n’a pas été contredit depuis.
Les accordéons et les carrousels ne devraient afficher un nouveau panneau que lorsque les utilisateurs le demandent.
Jakob Nielsen, cofondateur du Nielsen Norman Group, dans son article Auto-Forwarding Carousels and Accordions Annoy Users and Reduce Visibility, publié le 19 janvier 2013
Lisibilité et surcharge cognitive
Le défilement automatique perturbe la capacité à lire et à absorber l’information : le texte change avant que le visiteur ait fini, et il ne peut ni revenir en arrière simplement ni prévoir la suite. La présence de plusieurs messages dans un même espace entraîne en outre une surcharge cognitive, qui rend difficile de se concentrer sur une information ou une action. Sur tablette et sur mobile, les gestes de défilement de page et de changement de diapositive entrent en conflit, et une partie des lecteurs se retrouve avec une interface encore moins lisible.
Le carrousel brouille enfin la hiérarchie visuelle. Une page efficace guide vers une information ou une action principale ; avec cinq diapositives qui se disputent l’attention, personne ne sait plus quel est le message important. Cette confusion diminue l’efficacité de la communication, et c’est précisément le contraire de ce pour quoi le carrousel a été posé. Reste que le coût le plus objectif, celui qui se mesure, est technique.
Comment un carrousel dégrade-t-il les Core Web Vitals ?
Sur les trois métriques à la fois. Un carrousel à rotation automatique peut déplacer l’élément LCP à chaque changement de diapositive, produire ce que web.dev appelle un CLS infini, et faire tourner du JavaScript en continu dans la fenêtre de mesure de l’INP. Google documente ces trois effets dans ses bonnes pratiques pour les carrousels, dont la première recommandation tient en trois mots : ne pas utiliser l’autoplay.
Le LCP, une cible mouvante
Le Largest Contentful Paint retient le plus grand élément peint dans la fenêtre, et cesse de considérer de nouveaux candidats dès que l’utilisateur interagit. La documentation de Google en tire une conséquence directe : dans un carrousel à rotation automatique, n’importe quelle diapositive peut devenir l’élément LCP final, alors que dans un carrousel statique seule la première est candidate.
Chaque rotation avant la première interaction repousse donc potentiellement le LCP, et Google recommande, si l’autoplay est inévitable, de donner à toutes les diapositives la même taille intrinsèque. Notre guide sur le LCP et comment l’optimiser explique pourquoi une image qui arrive après le premier rendu coûte toujours plus qu’une image présente dès le HTML.
Le CLS, potentiellement infini
Un décalage de mise en page est compté chaque fois qu’un élément visible change de position sans interaction de l’utilisateur dans les 500 ms précédentes. Une diapositive qui glisse d’elle-même est exactement cela, et la documentation de Google prévient que sur les pages à carrousel automatique, cela peut produire un CLS infini, puisque la métrique se cumule sur toute la vie de la page.
Les transitions qui n’utilisent que transform échappent à ce comptage, celles qui modifient left, margin ou la largeur des éléments non. Notre article sur le CLS et comment l’optimiser détaille cette distinction, que beaucoup de bibliothèques anciennes ne respectent pas.
Le DOM, les images et le chargement par JavaScript
Chaque diapositive ajoute ses nœuds au DOM, ses images à la file de téléchargement et ses écouteurs d’événements au thread principal, alors que par définition une majorité de ces écrans ne sont pas visibles au chargement. Google identifie comme la plus grande erreur de performance des carrousels le fait d’initier le chargement de leur contenu par JavaScript, ce qui retarde les images et dégrade le LCP.
À l’inverse, les bibliothèques qui posent toutes les images dans le HTML les téléchargent toutes en priorité haute, comme sur les démonstrations officielles de Swiper ci-dessous. Les deux extrêmes sont mauvais, et le bon réglage, première image en priorité et suivantes différées, n’est presque jamais celui par défaut.
L’INP et le coût du mouvement permanent
Les animations continues d’un carrousel reposent sur du JavaScript qui s’exécute à intervalle fixe, souvent plusieurs fois par seconde pour les transitions. Ce travail occupe le thread principal, celui qui doit répondre aux clics, et il tombe donc dans la fenêtre de mesure de l’Interaction to Next Paint chaque fois qu’un visiteur interagit pendant une transition. Le Total Blocking Time de Lighthouse en capte une partie au chargement, l’INP de terrain le capte pendant toute la visite.
Notre guide sur l’INP et comment l’optimiser rappelle que le seuil est de 200 ms sur la pire interaction : un carrousel qui anime pendant que le visiteur clique ailleurs suffit à le franchir sur un mobile d’entrée de gamme.
Votre site est-il aussi rapide que vos visiteurs l’espèrent ?
Un carrousel a-t-il un coût environnemental ?
Oui, et il est documenté. Le référentiel des 115 bonnes pratiques d’éco-conception web du collectif GreenIT.fr consacre sa bonne pratique n°10 à limiter le recours aux carrousels, pour trois raisons cumulées : des images téléchargées pour rien, du JavaScript exécuté en continu, et de l’énergie consommée sur des millions de terminaux pour des diapositives que 1 % des visiteurs regardent.
Dans le contexte de la conception web écoresponsable que nous encourageons, tout ce qui précède se traduit en consommation. Les images des diapositives invisibles sollicitent la bande passante, donc les réseaux et les centres de données, ce qui pèse d’abord sur les visiteurs aux connexions limitées ou coûteuses. Les animations sollicitent le processeur, donc la batterie, sur des appareils que leurs propriétaires gardent de plus en plus longtemps. Le coût est payé à chaque visite, par chaque visiteur, pour un bénéfice que les chiffres d’interaction ne confirment pas.
La bonne nouvelle est que l’éco-conception et la performance convergent ici sans arbitrage. Retirer un carrousel réduit le poids de la page, le nombre de requêtes, le temps d’exécution et l’empreinte, en une seule décision. Notre guide sur l’optimisation des images montre que la même logique vaut pour chaque visuel : l’image la plus légère est celle qu’on ne charge pas, et un carrousel en charge quatre pour rien.
Quelles alternatives à un carrousel sur un site web ?
Un carrousel se remplace selon ce qu’il tentait de résoudre. S’il servait à départager plusieurs services sur la page d’accueil, la réponse est éditoriale : trancher plutôt que faire défiler. S’il servait à présenter un catalogue, une grille convient mieux. S’il servait à animer, une image de qualité et une typographie soignée produisent le même effet. Trois formes couvrent la quasi-totalité des cas :
- un visuel statique unique, avec un titre et un appel à l’action, qui concentre l’attention sur le message principal et devient un élément LCP présent dès le HTML ;
- une grille de plusieurs éléments tous visibles simultanément, qui répond au besoin de montrer plusieurs offres sans en masquer quatre sur cinq derrière une temporisation ;
- une section défilante horizontale contrôlée par le visiteur, en CSS pur, qui conserve l’idée d’une série dans un espace réduit mais laisse l’initiative à la personne.
Aucune de ces trois formes ne déplace le contenu automatiquement, ce qui règle d’un coup l’accessibilité, le CLS et l’INP. La grille mérite une mention particulière, parce qu’elle répond au motif qui justifie la plupart des carrousels, montrer plusieurs produits ou services sur le même espace, et qu’elle les affiche tous en même temps au lieu de parier sur une rotation que personne n’attend.
Le défilement horizontal contrôlé est le compromis intermédiaire, et Google note que l’API Scroll Snap permet d’implémenter des transitions de type carrousel avec du HTML et du CSS seulement. Le résultat est accessible au clavier par construction, respecte les préférences de mouvement, ne charge que ce qui est visible si les images sont en loading="lazy", et ne coûte pas une ligne de JavaScript :
<ul class="galerie">
<li><img src="produit-1.jpg" width="600" height="400" alt="Description du produit 1"></li>
<li><img src="produit-2.jpg" width="600" height="400" alt="Description du produit 2" loading="lazy"></li>
<li><img src="produit-3.jpg" width="600" height="400" alt="Description du produit 3" loading="lazy"></li>
</ul>
<style>
.galerie {
display: flex; gap: 1rem; padding: 0; list-style: none;
overflow-x: auto; /* le visiteur fait defiler, rien ne bouge seul */
scroll-snap-type: x mandatory; /* chaque element s'aligne proprement */
overscroll-behavior-x: contain;
}
.galerie li { flex: 0 0 80%; scroll-snap-align: start; }
.galerie img { width: 100%; height: auto; display: block; }
@media (prefers-reduced-motion: no-preference) {
.galerie { scroll-behavior: smooth; } /* l'animation, seulement pour qui l'accepte */
}
</style>Comment limiter les dégâts d’un carrousel imposé ?
En retirant la rotation automatique, en ne chargeant en priorité que la première image, en réservant les dimensions du conteneur et en rendant les contrôles accessibles au clavier. Google recommande, si l’autoplay est vraiment imposé, de l’interrompre au survol ; les WCAG exigent un bouton de pause. Un carrousel maîtrisé coûte bien moins qu’un carrousel par défaut, et ces réglages tiennent en quelques lignes.
Le cas existe, quand la direction ou la charte l’impose, et il vaut mieux le traiter que le subir. Le premier geste est de désactiver l’autoplay, ou au minimum de le conditionner à prefers-reduced-motion et de l’arrêter au survol et au focus. Le deuxième est de donner à la première image un fetchpriority="high" et aux suivantes un loading="lazy", pour que l’élément LCP soit découvert dès le HTML et que le reste attende.
Le troisième est de fixer width et height sur chaque image et une hauteur sur le conteneur, pour que rien ne se décale quand les diapositives arrivent :
<!-- Premiere diapositive : c'est l'element LCP, il doit etre decouvert dans le HTML -->
<img src="hero-1.jpg" width="1200" height="600" alt="..." fetchpriority="high">
<!-- Diapositives suivantes : differees tant qu'elles ne sont pas visibles -->
<img src="hero-2.jpg" width="1200" height="600" alt="..." loading="lazy">
<img src="hero-3.jpg" width="1200" height="600" alt="..." loading="lazy">
<script>
// Autoplay seulement si le visiteur n'a pas demande a reduire le mouvement,
// et jamais pendant qu'il survole ou a le focus dans le carrousel
var reduit = matchMedia('(prefers-reduced-motion: reduce)').matches;
if (!reduit) {
var el = document.querySelector('.carrousel');
var timer = setInterval(suivant, 7000); // jamais moins de 5 s (WCAG 2.2.2)
['pointerenter', 'focusin'].forEach(function (ev) {
el.addEventListener(ev, function () { clearInterval(timer); });
});
document.querySelector('.carrousel-pause').addEventListener('click', function () {
clearInterval(timer); // le mecanisme de pause exige par les WCAG
});
}
</script>Ces réglages ne rendent pas le carrousel utile, ils le rendent inoffensif. Les chiffres d’interaction restent ceux de Runyon, et les quatre diapositives suivantes resteront invisibles pour l’immense majorité des visiteurs. Mais la page cesse de payer pour elles, et l’audit d’accessibilité cesse de les relever. C’est le minimum défendable, pas l’objectif.
Que reste-t-il à décider ?
Remplacer un carrousel par un contenu statique et focalisé n’est pas seulement un choix de design, c’est un arbitrage éditorial que le carrousel permettait d’esquiver. Il oblige à répondre à la question que la rotation automatique laissait ouverte : quel est le message principal de cette page, et vers quelle action doit-elle conduire. Une image de haute qualité, un titre net et un appel à l’action clair y répondent mieux que cinq diapositives qui se succèdent devant des visiteurs qui ne les regardent pas.
Le minimalisme dans le design web n’est pas qu’une esthétique épurée, c’est une stratégie de performance : moins d’éléments, c’est un DOM plus léger, des temps de chargement plus courts, une accessibilité plus simple à tenir et un message mieux compris.
Le carrousel est souvent le premier élément que nous recommandons de retirer lors d’un audit de performance web, parce qu’il cumule à lui seul les trois métriques et les trois familles de critères. Ce qui se joue ensuite, dans une optimisation de performance, c’est de remplacer un réflexe de mise en page par une décision, et c’est rarement la partie technique qui prend le plus de temps.
