vendredi 25 septembre 2026

À propos

Contact

Accessibilité

Rendre accessible un carrousel d’accueil sans le supprimer, retour d’expérience

Le client tenait à son carrousel d'accueil, malgré nos réserves. Voici comment nous l'avons rendu accessible sans le supprimer, et ce que ce compromis nous a appris.

Par Clément Hadrot • 13 octobre 2020 • 4 min de lecture • Aucun commentaire
Rendre accessible un carrousel d'accueil sans le supprimer, retour d'expérience

« Le carrousel reste, c’est non négociable » : cette phrase a ouvert la réunion de cadrage avec un client du secteur du tourisme, propriétaire d’un site vitrine construit sur un thème premium truffé de widgets décoratifs. Notre recommandation initiale était de le remplacer par une simple image statique avec un titre accrocheur — les études d’usage sur les carrousels d’accueil montrent depuis longtemps un taux de clic dérisoire au-delà de la première diapositive. Mais le client y tenait pour des raisons de communication interne : chaque service voulait sa slide.

Plutôt que d’insister sur un combat perdu d’avance, nous avons proposé un compromis : réduire le nombre de slides et rendre le carrousel réellement accessible, plutôt que de le laisser tel quel. Ce retour d’expérience détaille ce qui a été négocié, ce qui a été codé, et ce qui reste, à mon sens, un pis-aller assumé.

Ce qui a été négocié avant le code

Cinq slides prévues à l’origine sont devenues trois : une pour l’offre phare, une pour la marque, une pour l’actualité en cours. Ce chiffre n’est pas arbitraire — au-delà de trois ou quatre slides, le temps nécessaire pour parcourir l’ensemble du carrousel au clavier devient rédhibitoire, même avec une navigation soignée.

Le bouton pause, condition non négociable de notre côté

Le critère de succès WCAG 2.2.2 (« Pause, Stop, Hide ») exige qu’un contenu qui bouge automatiquement puisse être mis en pause par l’utilisateur. Ce n’était pas négociable de notre côté : le bouton pause est visible dès le chargement de la page, pas caché derrière un survol, avec un état clairement annoncé :

<button type="button" class="carrousel-pause" aria-pressed="false">
  <span class="visually-hidden">Mettre en pause le carrousel</span>
</button>
bouton.addEventListener('click', () => {
  const enPause = bouton.getAttribute('aria-pressed') === 'true';
  bouton.setAttribute('aria-pressed', String(!enPause));
  bouton.querySelector('.visually-hidden').textContent = enPause
    ? 'Mettre en pause le carrousel'
    : 'Reprendre le défilement du carrousel';
  enPause ? demarrerDefilement() : arreterDefilement();
});
L'essentiel à retenir : Bouton pause visible et fonctionnel dès le chargement ; Navigation clavier complète entre les slides ; aria-live désactivé une fois en pause

Le carrousel devait aussi être parcourable entièrement au clavier, sans dépendre du défilement automatique : boutons précédent et suivant, plus des puces de navigation directe vers chaque slide, chacune annoncée avec sa position :

<button aria-label="Aller à la diapositive 2 sur 3" aria-current="false"></button>

L’attribut aria-current="true" est basculé dynamiquement sur la puce correspondant à la slide affichée, ce qui permet à un lecteur d’écran de savoir où l’utilisateur se trouve sans avoir à compter les puces une par une.

La région aria-live, activée puis volontairement coupée

Notre première version annonçait chaque changement de slide via une région aria-live="polite". Résultat en test utilisateur avec une personne aveugle : une gêne réelle, le carrousel continuant à interrompre la lecture du reste de la page toutes les six secondes tant qu’il n’était pas mis en pause. Nous avons donc coupé l’annonce automatique par défaut, en ne l’activant que lorsque l’utilisateur met le carrousel en pause et navigue manuellement — un compromis qui n’est décrit dans aucun guide officiel, mais qui répondait au retour de terrain.

Ce que ce projet nous a appris

  • Un compromis assumé et documenté vaut mieux qu’un refus de principe qui n’aboutit à rien : le client aurait gardé cinq slides inaccessibles si nous avions campé sur la suppression pure.
  • Tester avec un vrai utilisateur de lecteur d’écran a changé une décision technique (l’aria-live permanent) qu’aucune checklist n’aurait remise en cause seule.
  • Réduire le nombre de slides est souvent le levier le plus efficace, avant même le code : moins de contenu à parcourir, c’est moins de friction pour tout le monde, pas seulement pour les utilisateurs de technologies d’assistance.

Pour aller plus loin

Le motif de conception du carrousel accessible est documenté par le W3C ARIA Authoring Practices Guide, qui détaille aussi la gestion du focus quand le carrousel change de slide pendant que l’utilisateur y navigue au clavier.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi