Comment auditer l'accessibilité de votre boutique Shopify (Outils gratuits)

À retenir

• Un audit d’accessibilité de site web comporte quatre niveaux : une analyse automatisée, un test au clavier, un test avec lecteur d’écran, et des vérifications du contenu et du design. Ne faire que le premier n’est pas un audit.
• Le W3C précise que les outils “ne peuvent pas déterminer l’accessibilité, ils peuvent seulement aider à le faire”. Une machine peut prouver qu’une image n’a pas d’attribut alt. Elle ne peut pas juger si le texte alternatif est utile.
• Analyser votre page d’accueil ne revient pas à analyser votre boutique. Échantillonnez une page par modèle (template), plus les états interactifs : tiroir du panier, menu mobile, pop-ups, aperçu rapide.
• Consignez vos résultats dans un journal des problèmes avec la page, le critère de succès WCAG, la sévérité et le responsable. Priorisez d’abord les problèmes bloquants, puis selon le nombre de pages concernées par la correction.
• Ré-auditez après des changements de thème, la création de campagnes et l’installation d’applications. Les installations d’applications sont la source habituelle des régressions, car elles injectent du code que vous n’avez pas écrit.

Un audit d’accessibilité de site web est l’étape que la plupart des marchands Shopify ignorent, ou plutôt, l’étape qu’ils pensent avoir accomplie parce qu’ils ont lancé un outil d’analyse une fois et obtenu un score. Un score est un point de départ. Ce n’est pas un audit, et cela ne vous dira pas si un client utilisant un clavier peut finaliser sa commande.

Ce guide aborde la méthode d’audit plutôt que les correctifs ou la législation. Quatre niveaux, tous réalisables gratuitement, sur une vraie boutique, par quelqu’un qui n’est pas spécialiste de l’accessibilité. Si vous préférez l’aspect légal, commencez par notre guide sur la conformité ADA et WCAG sur Shopify.

Pourquoi vous pouvez nous faire confiance

Jacques a plus de 15 ans d’expérience en développement et a aidé de nombreuses marques Shopify à publier des vitrines accessibles et rapides. Nous sommes présents dans l’écosystème Shopify depuis plus de quatre ans et avons travaillé avec des centaines de marques Shopify sur leurs vitrines. Nous développons Fudge, un éditeur de vitrine IA avec une note de 4.9 sur le Shopify App Store et le statut Built for Shopify, nous passons donc nos journées dans la couche du thème où ces problèmes se trouvent réellement.

---

Pourquoi un scan automatisé n’est pas un audit

Les outils automatisés sont doués pour ce qu’ils font, mais ils ont des limites, et c’est bien pour ça qu’un vrai audit comporte plusieurs niveaux.

La Web Accessibility Initiative du W3C énonce clairement cette limite : “Les outils ne peuvent pas vérifier tous les aspects de l’accessibilité automatiquement. Le jugement humain est requis.” Cette même page ajoute que les outils d’évaluation “ne peuvent pas déterminer l’accessibilité, ils ne peuvent qu’y aider.”¹

Ce qu’ils ratent dépend de ce que vous comptez.

• Si on compte les critères de succès, l’automatisation n’en couvre qu’une minorité. Le propre rapport de Deque note que la méthode traditionnelle place les outils à environ 16 des 50 critères WCAG 2.1 de niveau AA.²
• Si on compte le volume de problèmes, le chiffre est plus élevé. Sur plus de 2 000 premiers audits, 13 000 pages et près de 300 000 problèmes, Deque a trouvé que l’automatisation détectait 57,38 % des problèmes enregistrés.²

Les deux sont vrais et mesurent des choses différentes. L’automatisation trouve une grande partie des instances, car quelques types d’erreurs se répètent des milliers de fois (le contraste des couleurs en tête). Elle couvre beaucoup moins de règles, et les règles qu’elle manque nécessitent une personne physique.

La répartition est logique :

Un scanner peut prouver	Un scanner ne peut pas juger
Qu’une image n’a pas d’attribut alt	Si le texte alt décrit l’image de façon utile
Qu’un ratio de contraste est inférieur à 4.5:1	Si l’ordre de tabulation correspond à l’ordre visuel
Qu’un <button> n’a pas de nom accessible	Si un bouton “En savoir plus” indique vraiment quelque chose à un utilisateur de lecteur d’écran
Qu’un input n’est associé à aucun <label>	Si un message d’erreur explique comment corriger la saisie
Que la page n’a pas d’attribut lang	Si un utilisateur naviguant au clavier peut fermer le cart drawer

Tout ce qui se trouve dans la colonne de droite est détecté par les niveaux deux, trois et quatre.

---

Les quatre niveaux d’un audit d’accessibilité de site web

Exécutez-les dans cet ordre. Chacun est gratuit, et chacun trouve des choses que le précédent ne pouvait pas voir.

Étape	Ce que ça trouve	Temps pour un premier passage
1. Scan automatisé	Contraste, alt manquants, labels manquants, contrôles vides	1 à 2 heures sur un échantillon de pages
2. Passage au clavier	Pièges au focus (focus traps), focus invisible, impasses, ordre de tabulation cassé	1 à 2 heures
3. Passage au lecteur d’écran	Noms sans signification, mises à jour non annoncées, parcours inutilisables	Une demi-journée
4. Contenu et design	Qualité des textes alt, messages d’erreur, sous-titres, zoom et reflow	2 à 3 heures

Un premier audit sur une boutique classique prend environ deux jours de travail. Les audits suivants sont beaucoup plus rapides, car vous vérifiez les changements plutôt que toute la boutique.

---

Niveau 1 : le scan automatisé

Quel scanner gratuit utiliser

Quatre outils gratuits couvrent cette étape.

Outil	Où il s’exécute	Utile pour
axe DevTools (extension gratuite)	Chrome, Edge, Firefox	Le premier scan par défaut. Fait tourner le moteur axe-core par rapport aux normes WCAG 2.0, 2.1 et 2.2 aux niveaux A, AA et AAA
WAVE	Chrome, Firefox, Edge	Superposition visuelle des problèmes sur la page elle-même. S’exécute localement, donc ça fonctionne sur les pages de dev ou protégées par mot de passe
Lighthouse	Intégré aux Chrome DevTools	Un score d’accessibilité unique plus une liste séparée de vérifications manuelles qu’il ne peut explicitement pas automatiser
Accessibility Insights for Web	Chrome, Edge	FastPass offre des vérifications automatisées plus un suivi visuel des arrêts de tabulation (tab-stops) en moins de cinq minutes

WAVE s’exécute entièrement dans le navigateur, donc rien n’est envoyé à un serveur et vous pouvez scanner un thème en aperçu protégé par mot de passe. Lancez-le avec Contrôle + Maj + U, ou Commande + Maj + U sur Mac. Accessibility Insights for Web est gratuit et open source, créé par Microsoft, et la propre doc de Shopify sur l’accessibilité des thèmes le recommande aux côtés de Lighthouse et WAVE. Si vous préférez faire le scan depuis l’interface d’administration de Shopify, notre sélection des meilleures applications d’accessibilité Shopify compare les applications de scan dédiées.

Une petite note sur Lighthouse. Le score d’accessibilité est une moyenne pondérée d’audits réussis ou échoués, et une page ne reçoit aucun point si elle ne réussit qu’en partie. Voyez ça comme un détecteur de fumée, pas un certificat. Shopify dit la même chose de ses propres conseils : “Suivre uniquement les bonnes pratiques de cette page ne garantit pas que votre thème est totalement accessible.”

Scanner votre page d’accueil ne revient pas à scanner votre boutique

Votre page d’accueil est un template. Votre boutique en compte une douzaine, chacun rendant différentes sections avec leurs propres images, formulaires et contrôles. Un scan sans erreur de la page d’accueil ne dit rien sur votre page produit, et c’est la page produit qui compte.

Prenez un échantillon d’une page par template, puis scannez chacune d’elles :

• L’accueil (Home)
• Une page collection, idéalement avec des filtres et une pagination
• Une page produit, idéalement avec des variantes, un guide des tailles et des avis
• La page panier (et le tiroir de panier séparément, voir ci-dessous)
• Les résultats de recherche, y compris l’état sans résultats
• Une page de contenu : une page À propos, un article de blog, ou une FAQ
• Une page de compte client si les comptes sont activés sur votre boutique
• Le checkout, aussi loin que vous pouvez aller

Le checkout nécessite une précision. Depuis l’abandon de checkout.liquid, le code du checkout est rendu par Shopify sur tous les forfaits plutôt que par votre thème. Parcourez-le et notez ce que vous trouvez, mais les problèmes ici relèvent du checkout de Shopify et de ses extensions, pas du code de votre thème.

Ensuite, scannez les états, pas seulement les pages. C’est là que les thèmes Shopify échouent le plus souvent, car ces composants sont en JavaScript sur mesure et un scanner ne voit que ce qui est actuellement dans le DOM :

• Le tiroir de panier (cart drawer), ouvert
• Le menu mobile et tout mega-menu, ouvert
• Tout pop-up ou modale de newsletter, ouvert
• L’aperçu rapide (quick view) sur une page collection
• Une modale de quiz ou de recherche de produit, en cours d’utilisation
• Le panneau de recherche prédictive, avec les résultats affichés

Ouvrez d’abord l’état, puis scannez. Un scan effectué sur un tiroir fermé ne signalera rien sur ce tiroir.

La plupart de ce que la première étape renvoie correspond à une poignée de problèmes qui se répètent : contraste, texte alt, labels, liens et boutons vides. Nous couvrons la réparation de chacun d’eux dans comment corriger les six erreurs d’accessibilité Shopify les plus courantes.

---

Niveau 2 : le test manuel au clavier

Mettez la souris de côté. Commencez sur la page d’accueil, appuyez sur Tab, et continuez jusqu’à terminer une commande test.

Ce qu’il faut vérifier au fur et à mesure :

• Le lien d’évitement. La première pression sur Tab sur n’importe quelle page doit révéler un lien “Passer au contenu”. Beaucoup de thèmes personnalisés le perdent.
• Le focus visible. Vous devez pouvoir voir où vous êtes à tout moment. Un outline: none global dans le CSS du thème est la cause habituelle d’un indicateur de focus invisible.
• L’ordre de tabulation correspond à l’ordre visuel. Le focus doit se déplacer de gauche à droite, de haut en bas. Les sections en positionnement absolu et les éléments sticky cassent souvent cela.
• Pas de pièges à focus. Ouvrez le tiroir du panier avec le clavier. Pouvez-vous naviguer à l’intérieur avec Tab et en ressortir ? Pouvez-vous le fermer avec Échap ?
• Pas d’impasses. Chaque contrôle cliquable avec une souris doit être accessible avec Tab et utilisable avec Entrée ou Espace.
• Le focus n’est pas masqué. Un header sticky, une bannière de cookies ou une bulle de chat flottante peuvent se superposer à l’élément que vous venez de cibler.

Les quatre composants qui échouent le plus souvent sont le tiroir du panier, le menu mobile, l’aperçu rapide et toute popup injectée par une application. Ces quatre composants sont des modales ou des tiroirs, et ils nécessitent les mêmes trois comportements : le focus se déplace dans le panneau lorsqu’il s’ouvre, il reste à l’intérieur tant qu’il est ouvert, et la touche Échap le ferme en ramenant le focus sur l’élément qui l’a ouvert.

Enregistrez chaque échec et continuez à tabuler. Ne vous arrêtez pas pour corriger quoi que ce soit en plein audit. Auditer et corriger sont deux tâches distinctes, et les mélanger est la meilleure façon de ne jamais finir un audit.

---

Niveau 3 : le test avec lecteur d’écran

C’est le niveau que les gens évitent, et celui qui change votre façon de voir votre boutique.

Les deux meilleures options sont gratuites. VoiceOver est intégré à macOS et iOS sans frais et s’active dans les paramètres d’Accessibilité. NVDA est gratuit sur Windows, développé par NV Access, une association caritative.

Votre premier passage sera lent, car vous apprendrez à utiliser le lecteur d’écran tout en auditant la boutique. Comptez une demi-journée. Le deuxième audit prendra une heure.

Commencez par une page produit, car elle concentre la plus grande complexité interactive d’une boutique. Écoutez si :

• La structure des titres. Les titres décrivent-ils la page et s’imbriquent-ils logiquement ?
• L’image du produit. Annonce-t-elle quelque chose d’utile, un nom de fichier, ou rien du tout ?
• Les sélecteurs de variantes. Les pastilles de couleurs et les menus déroulants sont-ils annoncés avec un nom et une valeur actuelle ? Les pastilles de couleur rendues sous forme de divs sans label sont courantes.
• Le sélecteur de quantité. Les boutons plus et moins annoncent-ils ce qu’ils font ?
• L’ajout au panier. Le bouton a-il un nom, et la mise à jour du panier est-elle annoncée ? Un “Ajouté au panier” qui apparaît sans déplacer le focus nécessite une région live ARIA, sinon l’utilisateur du lecteur d’écran ne l’entendra jamais.
• Les changements de prix et de stock. Lorsqu’un changement de variante modifie le prix ou affiche “Plus que 2 en stock”, est-ce annoncé ?
• Les accordéons. Les panneaux de livraison, retours et description ont besoin d’un aria-expanded qui reflète leur état réel.

Répétez ensuite sur le panier et tout au long du checkout. Si vous pouvez finaliser un achat uniquement avec un lecteur d’écran, vous avez éliminé la plus grande partie de vos risques. Si vous ne le pouvez pas, vous venez de trouver le problème qui a la priorité sur tout le reste dans votre journal.

---

Niveau 4 : vérifications du contenu et du design

Le dernier niveau fait appel à votre discernement : résoudre les critères qu’un scanner signale comme “à revoir”, et repérer les problèmes de contenu qu’aucun scanner ne peut voir.

Contraste des couleurs. Le critère 1.4.3 des WCAG 2.2 exige au moins 4.5:1 pour le texte normal et 3:1 pour le texte en grand, défini comme 18 points, ou 14 points en gras. Le critère 1.4.11 exige 3:1 pour les composants d’interface et les graphiques porteurs de sens.³ Les scanners détectent la majeure partie de cela. Vérifiez les cas qu’ils manquent : du texte sur une image hero, du texte sur un dégradé, des boutons désactivés. Testez le texte du bouton contre la couleur du bouton, et non contre l’arrière-plan de la page.

Qualité du texte alternatif, pas seulement sa présence. Un scanner validera alt="IMG_4021". Un acheteur n’en tirera rien. Lisez chaque attribut alt de votre échantillon et demandez-vous s’il transmet bien ce que l’image montre. Les images décoratives nécessitent un alt="" vide pour que les lecteurs d’écran les ignorent. Notre guide sur comment ajouter du texte alternatif dans Shopify couvre le champ dans l’admin et le côté thème.

Noms des liens et des boutons. “Cliquez ici”, “En savoir plus” et “Lire la suite” échouent lorsqu’ils sont lus hors de leur contexte, et les utilisateurs de lecteurs d’écran naviguent souvent en affichant une liste de liens. Nommez la destination : “Lire le guide des tailles”.

Labels de formulaires et messages d’erreur. Chaque champ de saisie a besoin d’un vrai label associé. Déclenchez ensuite délibérément des erreurs de validation : soumettez le formulaire de contact à vide, entrez un email invalide dans le champ de la newsletter. L’erreur doit identifier le champ, indiquer textuellement ce qui ne va pas, et ne pas s’appuyer uniquement sur une bordure rouge.

Sous-titres vidéo. Toute vidéo comportant de la voix a besoin de sous-titres. Les vidéos d’arrière-plan en lecture automatique nécessitent un contrôle de pause.

Redimensionnement du texte et zoom. Zoomez à 200 % et vérifiez que rien n’est coupé ou superposé. Réduisez ensuite le viewport à 320 pixels CSS et confirmez que la page passe sur une seule colonne (reflow) sans défilement horizontal. Les en-têtes sticky, les larges tableaux et les sections multi-colonnes sont les échecs habituels.

Pour la version critère par critère de ce niveau, utilisez notre checklist WCAG 2.2 AA pour Shopify.

---

Comment consigner ce que vous trouvez

Un seul fichier de suivi (spreadsheet). Pas quatre exports d’outils et des captures d’écran dans un thread Slack. Chaque problème trouvé correspond à une ligne :

Colonne	Son utilité
Page ou état	“Template produit” ou “Cart drawer ouvert”, pour que la personne en charge puisse le reproduire
Problème	Une phrase décrivant le comportement, pas la théorie
Critère de succès WCAG	Le numéro, par exemple 2.1.2. Rend la découverte justifiable et facile à chercher
Sévérité	Bloquant ou dégradant, voir ci-dessous
Emplacement	Code du thème, contenu de l’admin, ou une app
Responsable	Une personne, pas une équipe
Statut	Ouvert, corrigé, vérifié

La colonne “emplacement” compte plus qu’il n’y paraît. Elle sépare trois types de travaux très différents : le code du thème que vous contrôlez, le contenu de l’admin que n’importe qui peut corriger sans l’aide d’un développeur, et le code injecté par des apps que vous ne pourrez peut-être pas modifier du tout.

Comment prioriser les correctifs

Deux questions, dans cet ordre.

Est-ce bloquant ou dégradant ? Un problème bloquant signifie que l’action ne peut pas être terminée : un piège à focus dans le tiroir du panier, un champ de checkout obligatoire sans label, un bouton d’ajout au panier sans nom accessible. Ce sont des ventes perdues, et c’est ce que décrit une mise en demeure. Un problème dégradant rend la tâche plus difficile mais toujours possible : un texte avec un faible contraste, un texte alternatif flou, un niveau de titre sauté. Réglez chaque problème bloquant avant de passer aux problèmes dégradants.

Jusqu’où s’étend la correction ? Triez ce qui reste en fonction du nombre de pages touchées. Un label manquant sur le champ de recherche de l’en-tête est un changement qui corrige l’erreur sur toute la boutique. Un texte alternatif médiocre sur l’image d’un blog ne concerne qu’une seule image. Pondez en fonction du trafic, puisque ce sont vos templates de produits et de collections qui génèrent l’essentiel de vos sessions.

La liste qui découle de ces deux questions est le véritable résultat de l’audit.

À quelle fréquence ré-auditer

Trois déclencheurs, plus une fréquence de base.

• Après un changement de thème. Une mise à jour du thème, une refonte, ou une nouvelle section personnalisée. Ré-auditez les templates touchés.
• Après la création d’une campagne. Les landing pages créées à la hâte pour un lancement ou le BFCM sont celles qui se retrouvent en ligne avec un champ d’email sans label et un badge de réduction avec un contraste de 2.5:1.
• Après l’installation d’une application. Le cas classique.
• Tous les trimestres, comme base de référence, même si rien n’a changé.

Les installations d’apps sont la source habituelle de régressions. Une application front-end injecte du code que vous n’avez ni écrit ni vérifié : un widget d’avis, un tiroir d’upsell, une popup, un convertisseur de devises, une bulle de chat. Cela s’intègre en dehors des conventions de votre thème, n’hérite pas de vos styles de focus, et se résume souvent à un <div> avec un événement clic là où un <button> serait approprié. Rien dans Shopify ne vous avertit que l’app que vous venez d’installer a ajouté un piège à focus.

Après chaque installation d’application front-end, lancez un scan et un test au clavier sur les pages où elle apparaît. Vingt minutes suffisent pour détecter l’essentiel.

Un overlay n’est pas un audit, et pas une solution

Il est important de le mentionner, car c’est souvent vendu comme un raccourci magique pour tout ce qui précède.

Les surcouches d’accessibilité (overlays) tierces ne remplacent ni un audit ni les corrections. En avril 2025, la FTC a approuvé une ordonnance finale exigeant qu’accessiBe paie 1 million de dollars suite à des allégations affirmant que son produit d’IA pouvait rendre n’importe quel site conforme aux WCAG.⁴ Les sites qui utilisent des overlays se font toujours poursuivre en justice, car le code sous-jacent n’est pas modifié. Nous détaillons ce sujet dans notre guide expliquant pourquoi les overlays d’accessibilité échouent.

L’alternative n’est pas glamour mais elle fonctionne : trouver les problèmes, les corriger dans le thème, puis re-vérifier. C’est le modèle sur lequel nous avons construit Fudge. Il lit votre thème en ligne, repère ce qui échoue dans votre Liquid, CSS et JavaScript, et le corrige directement dans le code natif du thème plutôt que d’injecter une surcouche par-dessus. Parce que le résultat est du vrai code, il survit à une désinstallation, n’ajoute aucun script supplémentaire à la page, et s’intègre naturellement avec le reste de votre travail d’édition de boutique.

---

FAQ

Footnotes

1. W3C Web Accessibility Initiative, “Selecting Web Accessibility Evaluation Tools” : “Les outils ne peuvent pas vérifier tous les aspects de l’accessibilité automatiquement. Le jugement humain est nécessaire” et “Les outils d’évaluation de l’accessibilité web ne peuvent pas déterminer l’accessibilité, ils peuvent seulement aider à le faire.” https://www.w3.org/WAI/test-evaluate/tools/selecting/ ↩

2. Deque, “The Automated Accessibility Coverage Report” : 57,38 % des problèmes détectés par l’automatisation sur plus de 2 000 premiers audits, 13 000+ pages et près de 300 000 problèmes, mesurés par le volume de problèmes. Le rapport note que la méthode traditionnelle basée sur les critères couvre environ 16 des 50 critères WCAG 2.1 Niveau AA. https://www.deque.com/automated-accessibility-coverage-report/ ↩ ↩²

3. W3C, WCAG 2.2 Quick Reference : le critère de succès 1.4.3 Contraste (Minimum) exige un ratio de 4,5:1 pour le texte normal et 3:1 pour le texte en grand (18 points, ou 14 points en gras) ; 1.4.11 Contraste non textuel exige 3:1. https://www.w3.org/WAI/WCAG22/quickref/ ↩

4. Federal Trade Commission, “FTC Approves Final Order Requiring accessiBe to pay $1 Million”, Avril 2025. https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million ↩