Les breadcrumbs, c’est typiquement le composant qui passe en review parce que « ça marche ». À la souris, c’est vrai. Sur un écran tactile, au clavier, avec du zoom, c’est une autre histoire. Et le pire, c’est que les problèmes sont souvent minuscules : une icône cliquable trop petite, un dernier item qui est un faux lien, un focus qu’on ne voit pas… ou un conteneur invisible qui intercepte les clics quand la nav est sticky.
Je pars d’un truc très concret vu dans un design system (Duet DS a corrigé exactement ce genre d’irritants), et je te donne une base réutilisable. Pas une dissertation a11y. Des choix HTML/CSS qui évitent les pièges classiques, et une mini routine de test qui te fait gagner du temps.
Pourquoi tes breadcrumbs sont “OK” à la souris… et nazes sur mobile
Le problème n’est pas le concept de fil d’Ariane. Le problème, c’est l’implémentation front qui ment. Visuellement, tu vois des items espacés et un séparateur, donc ton cerveau pense « c’est cliquable facilement ». En réalité, le navigateur n’en a rien à faire de ton ressenti. Il ne clique que sur la boîte du lien.
Et dans les breadcrumbs modernes, il y a un pattern ultra fréquent qui casse tout : le lien “icône-only” (une maison, une flèche retour, un dossier…) qui a un <a> de 16px autour d’un SVG de 14px. À la souris, tu vises et tu touches. Au pouce, tu tapes trois fois, tu ouvres le mauvais niveau, et tu quittes la page en râlant.
Ajoute à ça les séparateurs décoratifs (souvent des chevrons) qui se retrouvent accidentellement dans la zone cliquable, ou au contraire qui prennent de la place et compressent le lien. Résultat : une navigation qui devrait aider devient une source de friction.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Cible tactile : arrête de cliquer sur l’icône, clique sur le lien
Mon principe est simple : si un item de breadcrumb est un lien, alors sa zone cliquable doit être confortable. Pas « pile la taille du pictogramme ». Confortable. En pratique, ça passe par du display: inline-flex, un peu de padding, et une hauteur mini cohérente avec tes autres contrôles.
Tu peux viser grand (44px, standard “mobile friendly”), ou viser WCAG 2.2 minimum (24px) quand tu as une UI dense. Mais dans tous les cas, ton lien ne doit pas être une micro-cible. Ce n’est pas parce que c’est dans un header que ça mérite un traitement « au rabais ».
Le piège à éviter, c’est de tricher en mettant du padding sur un wrapper et de laisser le <a> tout petit. Ça donne l’illusion visuelle… mais la cible réelle reste petite. La règle est bête : c’est le lien qui doit être grand, pas son décor.
La page courante : pas de faux lien, et aria-current qui dit la vérité
Deuxième point qui revient tout le temps : le dernier item. Beaucoup d’équipes le laissent en lien, parfois avec un href vide, parfois avec un #, parfois avec un pointer-events: none. C’est mauvais pour tout le monde. Pour le clavier, tu ajoutes une tabulation inutile. Pour les lecteurs d’écran, tu annonces un lien qui n’en est pas un. Pour les analytics, tu te retrouves avec des clics parasites.
Le pattern propre, c’est : les niveaux précédents sont des liens, la page courante est du texte, et tu annonces explicitement que c’est la page courante. Concrètement, aria-current="page" fait le job.
<nav aria-label="Fil d’Ariane" class="breadcrumbs">
<ol>
<li>
<a href="/" class="crumb">
<span class="crumb__icon" aria-hidden="true">🏠</span>
<span class="sr-only">Accueil</span>
</a>
</li>
<li aria-hidden="true" class="sep">/</li>
<li><a href="/docs" class="crumb">Docs</a></li>
<li aria-hidden="true" class="sep">/</li>
<li><span class="crumb is-current" aria-current="page">Breadcrumbs</span></li>
</ol>
</nav>Oui, j’ai mis un séparateur dans la liste. Ça se discute, mais c’est simple, lisible, et ça marche si tu le rends aria-hidden et non focusable. L’alternative, c’est un séparateur en CSS via ::before ou ::after. Les deux sont OK. Ce qui n’est pas OK, c’est un séparateur qui devient cliquable par accident ou qui perturbe l’ordre de navigation clavier.
Et si tu as un item “icône-only”, pense au nom accessible. Le SVG décoratif doit être caché (aria-hidden) et le lien doit avoir un libellé (texte visible ou .sr-only). Un pictogramme seul n’est pas un nom.
Focus, hover, active : si tu ne le vois pas au clavier, c’est cassé
Un breadcrumb, c’est une navigation. Donc il doit avoir un focus visible, net, et cohérent. Les UI où tu as un hover joli mais un focus inexistant sont encore trop courantes. Et le plus vicieux, c’est quand le focus “existe” mais qu’il est mangé par un overflow hidden, un border-radius, ou une ombre identique au fond.
Le terrain est assez simple : utilise :focus-visible pour éviter de peindre un focus agressif au clic souris, et assure-toi que le style focus n’est pas juste une variation de couleur trop subtile. Sur mobile, l’équivalent est le feedback au tap. Si ton lien ne réagit pas (ou réagit sur une micro-zone), l’utilisateur ne comprend pas ce qui est interactif.
Dernier détail qui fait mal : le “dernier item” en <span> doit visuellement ressembler à du texte courant, pas à un lien désactivé. Un lien désactivé, c’est le meilleur moyen de faire croire que quelque chose ne marche pas.
Le bug sournois : un conteneur invisible qui bouffe tes clics
Celui-là, je l’ai déjà vu en prod et c’est très frustrant à diagnostiquer. Tu as une navigation sticky, un header qui se transforme au scroll, ou un conteneur d’overlay “caché” pour un menu. Visuellement, tout va bien. Mais au-dessus de ta page, tu as un bloc transparent qui traîne, avec un z-index trop haut. Résultat : tu tapes sur un breadcrumb, et rien ne se passe. Ou alors tu cliques une zone, et c’est un autre élément qui prend l’événement.
Le signal typique : au desktop, avec une souris, tu arrives parfois à cliquer “entre deux pixels” et ça marche. Sur mobile, c’est mort. Au clavier, tu tabules et tu arrives à activer le lien, donc tu doutes de toi, tu penses “c’est iOS qui bug”. Non. C’est juste du layout qui bloque les pointer events.
Ce que je fais dans ces cas-là : j’ouvre les DevTools, j’inspecte la zone où je clique, et je regarde quel élément reçoit le click. Souvent, tu découvres un wrapper en position: fixed avec une hauteur qui n’a jamais été remise à zéro. Parfois, c’est un élément “visually hidden” mal fait, qui n’est pas réellement retiré du flux interactif. Le correctif est rarement compliqué, mais il faut accepter d’aller au conflit avec la CSS, pas de patcher le JS.
Une routine de test rapide (vraie vie) pour valider tes breadcrumbs
Tu n’as pas besoin d’un audit a11y complet pour éviter 80% des bugs. Par contre, tu dois sortir du mode “mouse-only”. Je valide un fil d’Ariane en conditions réelles : au clavier, sur mobile, et avec du zoom. Au clavier, je tabule depuis le haut de la page et je vérifie que l’ordre est logique, que le focus est visible, et que je n’ai pas de tab stop inutile sur la page courante. Sur mobile, je teste au pouce, sans précision, surtout sur l’icône d’accueil et sur les liens collés aux séparateurs.
Le test que beaucoup oublient : zoom navigateur à 200%. Là, tu vois tout de suite les problèmes d’overflow et de cibles qui se compactent. Si tes breadcrumbs deviennent une bouillie ou si le focus est coupé, tu le sauras en 10 secondes. Et tant qu’à faire, je jette un œil au HTML rendu. Si ton dernier item est un lien, je veux une bonne raison. Sinon, c’est un <span aria-current="page">, point.
Mon avis : les breadcrumbs, c’est un composant “simple”… donc impitoyable
Un fil d’Ariane n’a pas 300 états, pas de logique business tordue, pas de magie. Du coup, les bugs qu’on y laisse sont difficiles à excuser. Quand c’est pénible à utiliser, c’est rarement un “cas limite”. C’est juste qu’on l’a testé comme un dev, pas comme un utilisateur.
La bonne nouvelle, c’est que les correctifs sont mécaniques. Agrandis la cible réelle des liens, arrête les faux liens sur la page courante, rends le focus évident, et surveille tes couches invisibles quand tu as du sticky. Tu fais ça une fois, tu le mets dans ton design system, et tu arrêtes de te refaire avoir sur chaque projet.
