Chapitre 10.5 — Tooltips, carrousels & Cie

⏱️ TL;DR — Restent quelques composants piégeux : le tooltip (doit apparaître au survol et au focus, et se lier via aria-describedby), le carrousel (contrôlable, avec pause — un des patterns les plus difficiles, souvent à éviter), les tableaux interactifs / data grids, et les toasts (annoncés via live region). Le fil conducteur de tout ce chapitre : plus un composant est complexe, plus la bonne question est « en ai-je vraiment besoin ? ». La simplicité est une stratégie d’accessibilité.

🎯 Objectifs

Faire un tooltip accessible (survol + focus, aria-describedby) et distinguer tooltip et toggletip.
Connaître les exigences (et les dangers) d’un carrousel.
Situer les tableaux interactifs / data grids et les toasts.
Adopter le réflexe « le composant le plus accessible est celui qu’on ne construit pas ».

Un tooltip affiche une info complémentaire au survol d’un élément. Deux pièges classiques : il n’apparaît qu’à la souris (pas au clavier), et son texte n’est pas rattaché à l’élément pour le lecteur d’écran.


<!-- ❌ Survol souris seulement, texte non associé -->
<button onmouseover="showTip()">Aide</button>
<div class="tip">Ton mot de passe doit faire 12 caractères.</div>
 
<!-- ✅ Apparaît au survol ET au focus, lié via aria-describedby -->
<button aria-describedby="tip-mdp">Aide</button>
<div id="tip-mdp" role="tooltip">Ton mot de passe doit faire 12 caractères.</div>

Règles d’un bon tooltip : il s’affiche au survol et au focus ; il reste affiché tant que le pointeur ou le focus y est ; il se ferme avec Échap ; il ne contient que du texte (jamais d’élément interactif — sinon on ne peut pas l’atteindre). S’il contient un lien ou un bouton, ce n’est plus un tooltip mais un toggletip ou un petit popover, qui s’ouvre au clic et dont le contenu est annoncé via une live region.

⚠️ Piège — Le tooltip au survol uniquement : invisible pour qui navigue au clavier, et souvent illisible au tactile. Si une information n’existe que dans un tooltip souris, elle est perdue pour une partie des utilisateurs. Mieux vaut souvent afficher l’aide en permanence sous le champ (texte lié par aria-describedby).

Le carrousel : à manier avec méfiance

Le carrousel (diaporama défilant) cumule les difficultés d’accessibilité : défilement automatique, plusieurs vues empilées, contrôles multiples. Le critère de contenu en mouvement l’impose : s’il défile tout seul, il faut un moyen de mettre en pause / arrêter (voir aussi le mouvement).

Exigences minimales : boutons précédent / suivant accessibles au clavier et nommés ; un bouton pause si l’avance est automatique ; les diapositives hors écran retirées de l’ordre de tabulation (ou inert) ; annoncer le changement de diapositive discrètement. C’est beaucoup — d’où le conseil : avant de faire un carrousel, demande-toi s’il apporte vraiment quelque chose (les études d’usage montrent qu’ils sont souvent ignorés). Une grille ou une liste est presque toujours plus simple et plus accessible.

💡 Réflexe — Le composant le plus accessible est celui qu’on ne construit pas. Devant un carrousel, un méga-menu ou un data grid custom, la première question n’est pas « comment le rendre accessible ? » mais « puis-je résoudre le besoin plus simplement ? ». Réduire la complexité, c’est réduire la surface de bugs d’accessibilité.

Tableaux interactifs & data grids

Un tableau de données classique (tri, pagination) reste basé sur un <table> sémantique (voir 3.5) : les contrôles de tri sont des <button> dans les <th>, avec aria-sort pour annoncer l’état. Un data grid pleinement interactif (navigation cellule par cellule aux flèches, édition en ligne) est un pattern APG lourd (role="grid", gestion clavier bidimensionnelle) : réserve-le aux vrais tableurs, et privilégie une lib éprouvée.

Les toasts (notifications éphémères)

Un toast apparaît brièvement (« Enregistré », « Erreur réseau »). Pour un lecteur d’écran, il doit être annoncé sans voler le focus : on l’insère dans une live region (role="status" pour l’informatif, role="alert" pour l’urgent) — voir les live regions. Piège : un toast qui disparaît trop vite est illisible pour qui lit lentement ; laisse le temps de lire, ou offre un historique.

🧭 Sur A11yLearn — Sur la page d’accueil d’A11yLearn, on hérite d’un carrousel de « cours à la une ». Plutôt que de bricoler son accessibilité, on le remplace par une grille de cartes navigable au clavier : moins de code, aucun problème de pause/annonce, et une meilleure expérience pour tout le monde. Le toast « Progression enregistrée », lui, passe par une role="status".

✏️ Exercices

Exercice 1 — Corrige ce tooltip. Qu’est-ce qui cloche, et comment le rendre accessible ?


<span class="icon-info" onmouseover="show()" onmouseout="hide()">i</span>
<div class="tip">Format attendu : JJ/MM/AAAA</div>

✅ Solution

Trois problèmes : (1) le déclencheur est un <span> non focusable → invisible au clavier ; (2) l’info n’apparaît qu’au survol souris ; (3) elle n’est pas liée pour le lecteur d’écran. Correctif : mettre le déclencheur sur un élément focusable (le champ lui-même ou un <button>), afficher au focus et au survol, fermer avec Échap, et lier via aria-describedby="tip-date" avec id="tip-date" sur la bulle. Encore mieux ici : afficher « Format : JJ/MM/AAAA » en texte permanent sous le champ.

Exercice 2 — Faut-il un carrousel ? Un client veut un carrousel auto-défilant de 6 témoignages en page d’accueil. Que proposes-tu ?

✅ Solution

Je questionne le besoin : un carrousel auto est souvent ignoré et pénible (mouvement non désiré, contenu masqué). Alternative : afficher 2-3 témoignages en grille visible, avec un lien « voir tous les avis ». Si le carrousel est maintenu, il faut au minimum : pause/lecture, navigation clavier nommée, respect de prefers-reduced-motion (pas d’auto-défilement), et diapositives hors-champ retirées du focus. La version grille est plus simple et plus accessible.

🧠 Quiz de révision

1. Quelles sont les deux exigences de base d’un tooltip accessible ?

Il doit apparaître au survol ET au focus (pas seulement à la souris), et son texte doit être lié au déclencheur via aria-describedby. Il se ferme avec Échap et ne contient que du texte.

2. Quelle est la différence entre un tooltip et un toggletip ?

Un tooltip ne contient que du texte descriptif et s’affiche au survol/focus. Un toggletip s’ouvre au clic et peut contenir du contenu plus riche (parfois interactif) ; son contenu est annoncé via une live region. Un élément interactif ne doit jamais vivre dans un tooltip.

3. Pourquoi le carrousel est-il déconseillé ?

Parce qu’il cumule les difficultés (défilement auto à mettre en pause, vues empilées, contrôles multiples, diapositives à retirer du focus) pour un bénéfice d’usage souvent faible. Une grille ou une liste est en général plus simple et plus accessible.

4. Comment un toast doit-il être annoncé ?

Via une live region (role="status" pour l’informatif, role="alert" pour l’urgent), sans voler le focus. Il doit rester affiché assez longtemps pour être lu, ou être consultable ensuite.

5. Quel réflexe résume ce chapitre ?

« Le composant le plus accessible est celui qu’on ne construit pas. » Devant un composant complexe (carrousel, data grid, méga-menu), demande-toi d’abord si une solution plus simple répond au besoin — réduire la complexité réduit les risques d’accessibilité.

Partie suivante : Accessibilité en React & Next.js — appliquer tout ce qu’on a vu à ta stack quotidienne.