Audit d'accessibilité RGAA d'une fiche produit : le cas Zadig & Voltaire

Contexte

Depuis le 28 juin 2025, l'European Accessibility Act s'applique aux sites e-commerce. Transposé en droit français, il impose aux boutiques en ligne, hors micro-entreprises, de rendre leurs services accessibles aux personnes en situation de handicap. En France, le RGAA (Référentiel général d'amélioration de l'accessibilité) est le référentiel utilisé pour évaluer l'accessibilité d'un site. Une marque comme Zadig & Voltaire est donc directement concernée.

J'ai choisi d'étudier une fiche produit, car c'est là que se joue l'achat. Si un visiteur qui navigue au clavier ou avec un lecteur d'écran ne peut pas choisir sa taille ou ajouter l'article au panier, la vente est perdue.

Page étudiée : Cardigan femme en cachemire camel col V boutonné.

Méthodologie

• Outil principal : Accessibility Insights for Web version 2.49.0 et Axe-core 4.11.3.
• Compléments : navigation au clavier seul.
• Navigateurs : Google Chrome 156.0 sur ordinateur.
• Référentiel : RGAA 4.1.2.
• Périmètre : bannière des cookies, liens d'évitement, menu de navigation et en-tête, carrousel d'images.
• Hors périmètre : recherche, sélection de la taille et ajout au panier, reste de la page, version mobile, tunnel de commande, audit de conformité complet (taux de conformité).
• Date des constats : 29/10/2026.

Accessibility Insights for Web

Accessibility Insights for Web est une extension gratuite et open source développée par Microsoft pour Chrome et Edge. Son mode FastPass combine des tests automatiques, basés sur le moteur axe-core, et une visualisation de l'ordre de tabulation. Ses outils complémentaires affichent les titres, les grandes zones de la page (landmarks) et les noms accessibles des éléments. Les tests automatiques ne détectent toutefois qu'une partie des problèmes : je les ai donc complétés par une navigation au clavier et au lecteur d'écran.

"Tab Stop" de la partie supérieure

L'ordre de la navigation au clavier est cohérente.

Bannière des cookies

Constats.

La bannière des cookies s'affiche sous la forme d'une fenêtre modale, qui bloque la page tant qu'aucun choix n'est fait. C'est le premier élément que voit un visiteur, et le premier qu'il doit savoir utiliser au clavier.

Ce qui fonctionne.

Sur les critères du RGAA, la bannière est conforme : bien placée dans le DOM, correctement déclarée comme fenêtre modale, avec un focus confiné et plusieurs boutons pour en sortir. Le confinement du focus n'est pas un piège au clavier au sens du critère 12.9, puisque l'utilisateur peut toujours quitter la fenêtre (voir la section Focus trap).

Ma recommandation.

Deux ajustements amélioreraient encore l'expérience, sans relever d'une non-conformité RGAA. D'abord, une fermeture avec la touche Échap, comme le préconise le modèle « dialog » du W3C (elle équivaudrait alors à un refus). Ensuite, placer le focus sur le lien d'évitement à la fermeture, pour que le visiteur au clavier ou au lecteur d'écran sache où il se trouve dans la page.

Liens d'évitement (Skip links)

Constats.

La page contient deux liens d'évitement :

<a href="#main-content" class="skip-link">Aller au contenu principal</a>
<a href="#navigation" class="skip-link">Aller à la navigation</a>

Chacun s'affiche en haut à gauche de la page lorsqu'il reçoit le focus.

Le lien « Aller au contenu principal » fonctionne correctement : il mène à l'élément #main-content, et la tabulation suivante repart bien du contenu principal.

Le lien « Aller à la navigation », en revanche, ne fonctionne pas. Il cible l'élément #navigation, qui est vide :

<div id="navigation" data-v-59ea7562="" data-v-20768872="">
     <!---->
</div>

Le contenu de cet élément n'est généré qu'à l'ouverture du menu par le bouton « Ouvrir le menu de navigation ». Le lien d'évitement, lui, ne déclenche pas cette ouverture : il mène donc vers un conteneur vide.

Une seconde navigation est présente dans le DOM, mais elle n'est jamais atteignable avec la touche Tab :

<nav aria-hidden="true" class="sr-only">
    <ul>
        <!-- <li>68 liens ...</li> -->
    </ul>
</nav>

Masquée visuellement par sr-only et cachée aux technologies d'assistance par aria-hidden="true", elle n'est accessible à aucun visiteur. Elle sert probablement à exposer les liens du menu aux robots d'exploration.

Pourquoi c'est un problème.

Un lien d'évitement qui ne mène nulle part est pire qu'une absence de lien : le visiteur au clavier ou au lecteur d'écran l'active, constate qu'il ne se passe rien, et perd confiance dans les raccourcis de la page.

Ma recommandation.

Faire en sorte que le lien « Aller à la navigation » ouvre le menu et place le focus sur son premier lien, exactement comme le bouton « Ouvrir le menu de navigation ». Une alternative plus simple consiste à faire pointer ce lien vers le bouton d'ouverture du menu lui-même : le visiteur n'a plus qu'à appuyer sur Entrée pour l'ouvrir.

Menu de navigation

Constats.

Le menu principal :

Le menu s'ouvre dans un panneau latéral (drawer) avec le bouton « Ouvrir le menu de navigation ». À l'ouverture, le focus est placé directement sur le premier lien, « Nouveautés ». La tabulation reste ensuite confinée dans le menu, et la touche Échap le referme en replaçant le focus sur le bouton d'ouverture.

Côté code, le panneau est une balise <nav> nommée « Navigation principale » :

<nav id="navigation-l0-panel" role="navigation" aria-label="Navigation principale">
     <div>
          <h2 class="sr-only">Navigation principale</h2>
          <button data-testid="navigation-close" type="button" aria-label="Fermer">...</button>
          ...

Le menu se comporte comme une fenêtre modale (fond flouté, focus confiné), mais il n'est pas déclaré comme tel : il manque un conteneur avec role="dialog" et aria-modal="true". Un utilisateur de lecteur d'écran entre dans une zone de navigation, sans savoir que le reste de la page est devenu inaccessible. Le titre <h2> masqué et l'attribut aria-label sont en revanche corrects. Le role="navigation" est redondant avec la balise <nav>, mais sans conséquence.

Les sous-navigations : aucune sortie visible

Les entrées qui donnent accès à une sous-navigation sont des balises <button>, avec les attributs aria-haspopup et aria-expanded. Ce dernier passe bien à true à l'ouverture. Le focus est alors placé sur le premier lien de la sous-navigation, et reste confiné à l'intérieur.

<nav id="navigation-l1-panel" role="navigation" aria-label="Navigation Niveau 1">
     <ul data-testid="navigation-items" role="list">
          <li><a href="/eu/fr/c/women-collection-see-everything-187">Voir tout</a></li>
          <li><a href="/eu/fr/c/knits-for-women-116">Pulls &amp; cardigans</a></li>
          ...

Deux points posent problème :

• Aucun bouton « Retour » : seule la touche Échap permet de revenir au premier niveau, et rien ne l'indique. Sur ordinateur, le premier niveau reste pourtant affiché à gauche de la sous-navigation, mais il est impossible de l'atteindre avec Tab.
• Un nom générique : chaque sous-navigation est une nouvelle zone <nav>, nommée « Navigation Niveau 1 ». Le lecteur d'écran annonce donc « Navigation Niveau 1 » au lieu de « Femme » ou « Homme ».

« Trouver une boutique » : un bouton qui ouvre un nouvel onglet

<button>Trouver une boutique</button>

Ce bouton ouvre une nouvelle page dans un nouvel onglet, sans qu'aucun élément visuel ne l'indique. Un lecteur d'écran comme NVDA annonce « bouton, Trouver une boutique » : l'utilisateur s'attend à une action sur la page, et non à être emmené vers un autre onglet.

Le sélecteur de pays : un drawer incomplet

<button type="button" data-testid="country-switcher" data-country-code="FR">
     <div>
          <span class="iconify i-flag:fr-1x1" aria-hidden="true"></span>
          <span class="text-black">France</span>
          <span class="text-gray-400">Changer</span>
     </div>
</button>

Ce bouton ouvre un second drawer, intitulé « Pays de livraison ». Plusieurs points posent problème :

• Un intitulé peu clair : le lecteur d'écran annonce « bouton, France Changer ». Rien n'indique qu'il s'agit du pays de livraison.
• Un drawer qui n'est pas déclaré comme fenêtre : il possède un aria-labelledby, mais ni role="dialog", ni aria-modal="true". Sans rôle, le nom donné par aria-labelledby est ignoré par la plupart des lecteurs d'écran, et l'utilisateur n'est pas informé qu'une fenêtre s'est ouverte.
• Un focus perdu à la fermeture : après le bouton « Fermer » ou la touche Échap, plus aucun élément n'a le focus. L'utilisateur doit reprendre son parcours depuis le début de la page.
• Un focus invisible sur « Enregistrer » : le bouton recharge la page, ce qui est attendu, mais sa prise de focus n'est pas perceptible.

Le lien FACIL'iti : un outil d'accessibilité qui égare le focus

Le menu contient un lien vers FACIL'iti, la solution d'adaptation de l'affichage :

<a href="#facil-iti">...</a>

Le script de FACIL'iti s'ouvre lorsqu'il détecte l'ancre dans l'URL. L'élément déclenche donc une action, mais il est déclaré comme un lien.

Surtout, à la fermeture de FACIL'iti (bouton « Fermer » ou Échap), le focus est perdu. Le drawer du menu reste ouvert, et le focus repart dans la page, sous le fond flouté du menu : on tabule à l'aveugle sur des éléments masqués. Pour revenir dans le menu, il faut traverser la page jusqu'au lien d'évitement « Aller à la navigation », ou recharger la page.

Pourquoi c'est un problème.

Le menu principal montre que l'équipe maîtrise les bons comportements clavier. Il lui manque surtout la sémantique de fenêtre modale et une sortie visible des sous-navigations. Les vrais écarts apparaissent sur les composants ajoutés autour : le sélecteur de pays et le script tiers FACIL'iti.

Ma recommandation.

Envelopper les drawers du menu et du sélecteur de pays dans un conteneur role="dialog" et aria-modal="true", nommé par son titre avec aria-labelledby, et appliquer au sélecteur de pays la gestion du focus du menu principal. Ajouter un bouton « Retour » en tête de chaque sous-navigation, et nommer chaque zone d'après sa rubrique (« Femme », « Homme »).

Renommer le bouton du sélecteur, par exemple « Pays de livraison : France, changer », et indiquer la langue du site associée à chaque pays. Remplacer « Trouver une boutique » par un lien, en signalant le nouvel onglet ou en ouvrant la page dans le même onglet.

Pour les icônes de l'en-tête, adapter la couleur du contour de focus au fond réel (ou utiliser un double contour noir et blanc, visible sur tous les fonds), et traduire les noms accessibles : « Liste d'envies », « Panier ».

Pour FACIL'iti, fermer le menu à l'ouverture de l'outil, puis replacer le focus sur le bouton « Ouvrir le menu de navigation » à sa fermeture. Le lien #facil-iti peut devenir un <button> qui appelle directement l'ouverture de l'outil.

Carrousel d'images

Constats.

Le carrousel présente les photos du produit. Il ne défile pas automatiquement : aucun bouton pause n'est donc nécessaire.

Les contrôles sont regroupés en bas à droite : un bouton « Précédent », un bouton par miniature, puis un bouton « Suivant ». Le carrousel ne tourne pas en boucle : les boutons « Précédent » et « Suivant » se désactivent lorsqu'on atteint la première ou la dernière image.

Point positif : lorsque le bouton « Suivant » se désactive sur la dernière image, le focus n'est pas perdu. La tabulation suivante reprend normalement, sans renvoyer au début de la page.

Des miniatures nommées par leur image

Chaque miniature est un bouton qui contient une image. Faute d'autre intitulé, c'est l'alternative de l'image qui donne son nom au bouton : « Cardigan Mirkaz 100% Cachemire thumbnail 1 ». Le lecteur d'écran annonce donc « bouton, Cardigan Mirkaz 100% Cachemire thumbnail 1 » : un nom en partie en anglais, qui décrit l'image au lieu de l'action, et qui ne distingue pas les vues entre elles.

La miniature de l'image affichée n'est signalée que visuellement : aucun attribut (aria-current, aria-pressed) ne l'indique, ni sur le bouton, ni sur l'image. Un utilisateur de lecteur d'écran ne sait pas quelle photo est à l'écran.

Des photos aux alternatives numérotées

Les grandes images suivent la même logique : « Cardigan Mirkaz 100% Cachemire 1 », « Cardigan Mirkaz 100% Cachemire 2 », etc. Or chaque photo montre une information différente : le produit de face, de dos, porté, un détail des boutons ou de la maille. Un visiteur qui ne voit pas les images n'a accès à aucune de ces informations.

Un zoom réservé à la souris

Un clic sur une photo l'agrandit. Mais les images ne sont pas atteignables avec Tab : un visiteur au clavier ne peut pas déclencher le zoom.

Une structure non déclarée

Le carrousel ne porte aucun attribut ARIA. Le lecteur d'écran n'annonce ni l'entrée dans un carrousel, ni le nombre d'images, ni la position de l'image affichée.

Pourquoi c'est un problème.

Sur une fiche produit, les photos sont l'information principale. Elles remplacent l'essayage en boutique. Des alternatives numérotées et un zoom inaccessible au clavier privent une partie des visiteurs de ce qui déclenche l'achat.

Ma recommandation.

Donner un intitulé explicite à chaque miniature, porté par le bouton, et masquer l'image qu'il contient aux lecteurs d'écran, puisqu'elle double la grande photo :

<button type="button" aria-label="Afficher l'image 2 sur 5 : vue de dos" aria-current="true">
     <img src="..." alt="">
</button>

Rédiger pour chaque photo une alternative qui décrit la vue, par exemple « Cardigan Mirkaz en cachemire camel, vue de face » ou « Cardigan Mirkaz, détail des boutons ».

Rendre le zoom accessible au clavier en plaçant chaque photo dans un <button aria-label="Agrandir l'image">, et faire de la vue agrandie une fenêtre modale qui se ferme avec Échap. Enfin, déclarer le carrousel selon le modèle du W3C : un conteneur nommé (« Photos du produit ») avec aria-roledescription="carrousel", et chaque diapositive annoncée par sa position (« 2 sur 5 »).

Focus trap : quand faut-il retenir le focus ?

Le RGAA interdit le piège au clavier (critère 12.9) : un visiteur doit toujours pouvoir quitter un composant au clavier. À l'inverse, une fenêtre modale doit retenir le focus tant qu'elle est ouverte. Sinon, la tabulation part dans la page masquée derrière elle. Ce confinement n'est pas un piège, à condition qu'une sortie soit disponible et connue : un bouton « Fermer » visible, la touche Échap, ou les deux.

La règle est simple. Un composant modal, qui rend le reste de la page inutilisable, confine le focus, se ferme avec Échap et rend le focus à l'élément qui l'a ouvert. Un composant non modal (menu déroulant, notification, bannière qui ne bloque pas la page) ne retient pas le focus, mais s'insère logiquement dans l'ordre de tabulation. La balise HTML <dialog>, ouverte avec showModal(), gère nativement le confinement et la touche Échap.

Synthèse des constats

Conclusion

La page étudiée part d'une base solide. La bannière des cookies est exemplaire, le lien vers le contenu principal fonctionne, et le menu principal gère correctement le focus à l'ouverture comme à la fermeture. On sent une équipe qui connaît les bonnes pratiques.

Les écarts se concentrent ailleurs : sur la visibilité du focus, sur les sorties des composants (sous-navigations, drawers, outil FACIL'iti) et sur le contenu des photos, qui restent muettes pour un visiteur qui ne les voit pas. Pris un par un, ces points sont rarement bloquants. Mis bout à bout, ils transforment un parcours simple en parcours d'obstacles pour un visiteur au clavier ou au lecteur d'écran.

Cette étude de cas n'est pas un audit complet. Elle couvre une seule page, sur ordinateur, et laisse de côté la recherche, la sélection de la taille, l'ajout au panier et le tunnel de commande. Un audit de conformité RGAA porte sur un échantillon de pages et sur l'ensemble des 106 critères. L'objectif ici était de montrer, sur un exemple concret, ce qu'une simple navigation au clavier révèle déjà.

Trois vérifications, simples à intégrer à une recette avant chaque mise en ligne, auraient permis de repérer la plupart de ces points :

1. Parcourir la page avec la seule touche Tab, et vérifier que le focus reste visible sur tous les fonds.
2. Ouvrir puis fermer chaque fenêtre, menu et outil tiers au clavier, et vérifier où revient le focus.
3. Relire les alternatives des images produit et les intitulés des boutons-icônes, comme le ferait un lecteur d'écran.

J'espère que cette étude de cas vous a donné un aperçu concret de ma démarche d'audit. Vous souhaitez vérifier l'accessibilité de votre boutique ou identifier les points de friction de votre site e-commerce ? Découvrez mes prestations d'audit UX et SEO e-commerce.