Corrigez les 6 erreurs d'accessibilité les plus fréquentes sur votre thème Shopify

Principaux points à retenir

• Six erreurs sont responsables de l’écrasante majorité des problèmes d’accessibilité sur le web, et chacune d’entre elles se retrouve sur les boutiques Shopify.
• Les six sont détectables automatiquement, un scanner gratuit les trouve donc en quelques minutes. Chacune correspond à un critère de succès WCAG précis et se corrige via du code natif.
• La solution consiste toujours à modifier le code de votre thème ou un champ de l’admin, et non à ajouter un widget par-dessus. Les overlays laissent l’erreur sous-jacente en place.
• Les scanners automatisés repèrent ces six erreurs car elles sont sans ambiguïté, mais cela ne représente qu’un tiers des critères WCAG. Un test manuel au clavier et utiliser un lecteur d’écran (screen reader) reste donc indispensable.

Améliorer l’accessibilité de votre Shopify ne commence pas par la mémorisation de toutes les normes WCAG. Cela commence par six erreurs précises. L’étude annuelle WebAIM Million, menée sur le million de pages d’accueil les plus visitées, retrouve les mêmes six problèmes en tête de liste chaque année, et ensemble, ils constituent l’essentiel des erreurs détectées.¹

Ce guide aborde chaque erreur une par une : de quoi il s’agit, le critère de succès WCAG non respecté, comment elle se manifeste dans un thème Shopify, et la correction exacte dans le code natif ou depuis l’admin. Ce sont les corrections les plus rapides et efficaces, car elles sont courantes et sans ambiguïté.

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 boutiques rapides et accessibles. Nous sommes dans l’écosystème Shopify depuis plus de quatre ans et avons créé Fudge, un constructeur et éditeur de boutique par IA noté 5.0 sur le Shopify App Store, qui corrige les problèmes d’accessibilité directement dans le code natif du thème. Pour connaître le contexte juridique et normatif de ce travail, consultez notre guide complet sur la conformité ADA et WCAG de Shopify.

Les six erreurs les plus courantes en un coup d’œil

Le rapport WebAIM Million de février 2026 a détecté des non-conformités WCAG sur 95,9 % des pages d’accueil, avec une moyenne de 56,1 erreurs par page.¹ Ces six catégories concentrent presque toutes ces erreurs, et la liste a à peine changé en sept ans.

Les pourcentages représentent la part du million de pages d’accueil les plus visitées où WebAIM a détecté chaque erreur en février 2026.¹ Parcourez la liste et vous éliminerez la majeure partie de vos risques. Pour connaître tous les critères en dehors de ces six-là, consultez notre checklist WCAG 2.2 AA pour Shopify.

1. Texte à faible contraste

Ce que c’est. Un texte trop clair par rapport à son fond pour être lu confortablement. C’est l’erreur la plus fréquente sur le web, présente sur la grande majorité des pages.

Pourquoi ça ne respecte pas les WCAG. Le critère de succès 1.4.3 Contraste (minimum) impose un ratio de contraste d’au moins 4.5:1 pour un texte normal et de 3:1 pour un texte de grande taille (généralement 18px en gras ou à partir de 24px en mode normal). Un texte gris sur fond blanc et un texte clair sur un bouton aux couleurs de la marque sont les coupables habituels.

Comment ça se manifeste sur Shopify. Les thèmes affichent les choix de couleurs sous forme de jeux de couleurs (color schemes) dans l’éditeur de thème. Une palette de couleurs de marque choisie plus pour son esthétique que pour son contraste influe instantanément sur le corps du texte, les boutons, les pastilles promos et les placeholders sur la totalité des templates. Une légende dont le gris est amoindri ou un label “Ajouter au panier” pastel clair peuvent tomber bien en dessous de 4.5:1 sans pour autant paraître défectueux à l’œil nu.

La solution. Ajustez les variables de couleurs (tokens), et pas les éléments de façon individuelle. Dans l’éditeur de thème, ouvrez Paramètres du thème > Couleurs et augmentez le contraste des couleurs de texte et de bouton de chaque jeu de couleurs jusqu’à ce qu’ils soient valides. Si vous modifiez le code directement, les valeurs se trouvent dans les propriétés personnalisées du CSS du thème. Dans un thème basé sur Dawn, elles ressemblent à ceci :

.color-scheme-1 {
  --color-foreground: 18, 18, 18; /* assombrir le texte jusqu'à ce que le ratio texte/fond atteigne 4.5:1 */
  --color-background: 255, 255, 255;
}

Vérifiez chaque paire avec un outil de validation des contrastes tel que celui intégré aux Chrome DevTools ou le vérificateur de WebAIM. N’oubliez pas de tester le texte du bouton sur le fond du bouton, et non sur le fond de la page. Modifier la variable viendra corriger le contraste partout où le jeu de couleurs est utilisé.

2. Texte alternatif manquant sur les images

Ce que c’est. Une image sans alternative textuelle, de sorte qu’un lecteur d’écran (screen reader) n’annonce rien d’utile, ou lit carrément le nom du fichier.

Pourquoi ça ne respecte pas les WCAG. Le critère de succès 1.1.1 Contenu non textuel exige une alternative textuelle pour les images qui relaient de l’information. Les photos de produits, les bannières informatives et les images de contenu ont toutes besoin d’un texte alternatif. À l’inverse, les images purement décoratives nécessitent un alt="" vide pour que les technologies d’assistance les ignorent.

Comment ça se manifeste sur Shopify. Le texte alternatif (alt text) peut être omis à deux endroits différents :

• Les images de produits et de variantes ont un texte alternatif défini depuis l’admin. Ouvrez un produit, sélectionnez un média et utilisez Ajouter un texte alternatif dans les détails du média. Les chargements (uploads) en masse laissent presque toujours ce champ vide.
• Les images de section et de page (diapositives, bannières d’images, blocs promo) sont ajoutées via l’éditeur de thèmes, où chaque paramètre d’image_picker possède son propre champ Texte alternatif qu’il est malheureusement trop facile de laisser vide.

La solution. Renseignez le texte alternatif à la source pour chaque image dont le sens importe, et vérifiez que le thème l’affiche correctement. Un thème devrait restituer la valeur enregistrée :

{{ product.featured_image | image_url: width: 800 | image_tag: alt: product.featured_image.alt }}

Pour une image décorative qui ne transmet aucune information, affichez explicitement un alt vide pour que les lecteurs d’écran l’ignorent :

<img src="{{ 'divider.svg' | asset_url }}" alt="" role="presentation" width="1200" height="8">

Rédigez un texte alternatif qui décrit ce que montre l’image et la raison de sa présence sur la page, tout en veillant à rester concis.

3. Labels de champs de formulaire manquants

Ce que c’est. Un champ (input) qu’un lecteur d’écran ne peut pas nommer, car aucun label (étiquette) ne lui est rattaché programmatiquement parlant. Un placeholder visible n’est pas un label. Il disparaît au focus et de nombreux lecteurs d’écran n’en tiennent pas compte.

Pourquoi ça ne respecte pas les WCAG. Deux critères s’appliquent. Le critère 3.3.2 Étiquettes ou instructions exige que les champs (inputs) aient des labels, et le 4.1.2 Nom, rôle et valeur demande que chaque élément de contrôle expose un nom accessible pour toute technologie d’assistance.

Comment ça se manifeste sur Shopify. Les accusés habituels sont le champ de recherche, l’inscription à la newsletter, et les formulaires de contact. De nombreux thèmes conçoivent uniquement leurs champs avec des placeholders dans le but d’être plus épurés :

<input type="email" name="contact[email]" placeholder="Adresse e-mail">

Un tel code s’affichera donc à l’écran sans aucun nom accessible.

La solution. Associez un vrai <label> à votre input en liant les attributs for et id. Si le design du site ordonne qu’il n’y ait aucun label en vue, conservez le label dans le DOM et masquez-le plutôt le supprimer. Utilisez la classe visually-hidden du thème pour y parvenir de la bonne façon :

<label for="NewsletterEmail" class="visually-hidden">Adresse e-mail</label>
<input
  type="email"
  id="NewsletterEmail"
  name="contact[email]"
  placeholder="Adresse e-mail"
  autocomplete="email"
>

Dawn et la plupart des thèmes de l’Online Store 2.0 embarquent désormais une configuration visually-hidden (masqué visuellement). De ce fait, le label continue d’être utilisé par les lecteurs d’écran bien qu’il ne paie pas de mine à l’affichage. Un aria-label placé sur l’input constitue également une méthode de secours (fallback) viable dans les cas où l’intégration d’un élément apparent <label> est rendue impossible.

4. Liens vides

Ce que c’est. Un lien qu’un lecteur d’écran identifie comme un simple “lien” sans aucun texte explicitant sa destination, puisque son seul et unique contenu est une image dépourvue d’alternative textuelle (ou d’une icône seule).

Pourquoi ça ne respecte pas les WCAG. Le critère 2.4.4 Raison d’être d’un lien (selon le contexte) exige que le but d’un lien soit clair selon la façon dont il est écrit (libellé), et le 4.1.2 Nom, rôle et valeur exige un nom accessible. Un lien contenant uniquement une icône n’en satisfait hélas aucun.

Comment ça se manifeste sur Shopify. Les en-têtes (headers) et pieds de pages (footers) ne manquent pas de ce mauvais procédé : le bouton panier affiché sous forme d’icône cabas, les icônes de réseaux sociaux en bas de page, le lien attribué au logo entourant un SVG, et la pagination faite de simples chevrons. Le markup classique de ce cas ressemble généralement à ça :

<a href="{{ routes.cart_url }}">
  {% render 'icon-cart' %}
</a>

Le SVG n’a pas de texte, le lien n’a donc logiquement aucun nom (sans quoi indiquer).

La solution. Donnez au lien un texte (alt ou pas) qu’un lecteur d’écran pourra lire. L’approche la plus propre réside dans l’ajout de texte masqué visuellement (visually-hidden) à l’intérieur de la balise, cela octroie au passage l’incorporation fluide d’un compteur d’articles :

<a href="{{ routes.cart_url }}">
  {% render 'icon-cart' %}
  <span class="visually-hidden">Panier, {{ cart.item_count }} articles</span>
</a>

Appliquer un attribut de référence tel que aria-label sur un tag format lien <a...> suffira également dans d’autres cas. S’agissant des liens d’icônes, précisez avec le nom exact de tel ou tel réseau social pour rester intelligible pour le lecteur, du style : “Instagram” ou “TikTok” à la place d’un timide “lien social”, cela n’aide point.

5. Boutons vides

Ce que c’est. Un <button> sans texte discernable, autrement dit le jumeau interactif du lien vide. Le composant s’active très bien avec la souris, n’empêche, il laisse un immense silence aux technologies d’assistance pour le reste.

Pourquoi ça ne respecte pas les WCAG. Le critère 4.1.2 Nom, rôle et valeur exige que chaque composant expose un nom accessible. Un bouton uniquement composé d’une icône, dont la lecture finira par déclamer “bouton” sera recalé sans condition : l’utilisateur qui survole vos commandes (en aveugle, et le mot n’est pas vain) ne saurait avoir connaissance du but de la balise avant de cliquer dessus.

Comment ça se manifeste sur Shopify. Les composants ne contenant qu’une icône sont partout dans les thèmes modernes : le bouton pour déployer le menu mobile (hamburger), le bouton (en croix ×) faisant office de fermeture du tiroir panier, les commandes permettant l’ajout en plus et en moins pour paramétrer des quantités, ou encore la barre de recherche prédictive afin d’avancer un mot dans une barre (les fameux auto-complete). Voici un exemple :

<button type="button" class="header__icon" aria-expanded="false">
  {% render 'icon-hamburger' %}
</button>

La solution. Ajoutez un attribut aria-label explicitant le pourquoi de telle action, ou incluez à l’intérieur du composant bouton l’option du simple balisage visually-hidden évoqué plus haut :

<button type="button" class="header__icon" aria-expanded="false" aria-label="Ouvrir le menu">
  {% render 'icon-hamburger' %}
</button>

Pour un élément rétractable (toggle) comme un menu mobile ou d’un affichage de tiroir panier en glissant avec la souris, jumelez le balisage au label visuellement caché avec l’attribut aria-expanded pour indiquer un comportement synchronisé en plein milieu du code (ouvert/fermé) de vos composants avec le Javascript. Ainsi, des personnes usant de screen-reader (lecteurs) resteront par la même informés si les commandes sont laissées déployées ou si elles ont été repliées. Un curseur ou une croix de fermeture est supposé signaler explicitement que “Fermer” reste possible ; tandis que pour une modification de chiffres on précisera “Augmenter la quantité” ou “Diminuer la quantité”.

6. Langue du document manquante

Ce que c’est. Une page sans l’attribut lang sur sa balise d’enclenchement <html>, ce qui laisse les technologies de l’assistance et les moteurs de recherche dans l’ignorance s’agissant de la langue maternelle utilisée le long de chacune de vos sections.

Pourquoi ça ne respecte pas les WCAG. Le critère de contrôle 3.1.1 Langue de la page requiert que toute page dispose de l’entité “langue” assignée par voie de code (de manière programmatique). En absence de quoi, et au pire, les lecteurs d’écran risquent alors de déployer les mauvaises configurations ou des phonétiques abracadabrantes.

Comment ça se manifeste sur Shopify. Ce problème de conception peut faire l’objet de modification moyennant un simple petit tour à l’intérieur de ce seul fragment du thème : un endroit désigné sous le terme de theme.liquid. C’est le composant père contenant le point central enveloppant vos gabarits avec aisance. Si on se limite à une maquette parfaitement pensée par avance de la boutique, il s’assigne automatiquement selon la localisation choisie (locale). Mais, attention : un store custom, des bidouilles massives en bout de route, ou des mises à jour à mi-chemin, écraseront ou omettront parfois très violemment la déclaration d’origine locale, et un site perdra l’attribut de référencement multilingue vital.

La solution. Mettre à jour l’entrave avec le repérage de votre code local à la source via paramètre lang depuis la localisation via request.locale, la synchronisant de fait avec vos traductions et unifier la totalité de l’ouvrage sans peine. Ouvrez le fichier layout/theme.liquid puis naviguez sur la toute première ligne afin d’éditer la portion du code (souvent les 5 premières) qui doit renseigner à l’en-tête l’instruction suivante :

<!doctype html>
<html
  class="no-js"
  lang="{{ request.locale.iso_code }}"
  dir="{{ request.locale.iso_code | default: 'en' }}"
>

Utiliser tel quelle la mention de la classe : {{ request.locale.iso_code }} (sans altérer de fixité par l’interdiction de type "en", ou un "fr" rigide dicté en valeur pure et dure) aidera les modules Shopify Markets (l’environnement de vente multilingue par essence du cms) de faire cohabiter l’orientation sémantique propre à chaque région ciblée avec vos visites. L’avantage pour finir avec un allié redoutable mais pas compliqué, reste la simplicité à travers sa petite seule ligne codée modifiée : balayage des craintes concernant tout manque sur chaque onglet accessible à tous, sans avoir modifié cent fois autre chose par page visitée !

Pourquoi les scanners trouvent ces six erreurs, et ce qui leur échappe

Les six erreurs partagent une même caractéristique : elles sont vérifiables par la machine (machine-decidable). Un outil peut prouver qu’une balise image ne possède pas d’attribut alt, qu’un ratio de contraste est indéniablement en dessous de 4.5:1, ou qu’un <button> ne contient aucun texte. C’est pour ça qu’un scanner automatisé gratuit comme axe DevTools, WAVE ou Lighthouse les détecte en quelques secondes, et qu’elles dominent les données de l’étude WebAIM Million. WebAIM fait ses mesures avec des outils automatisés, les six résultats les plus fréquents sont donc logiquement les six les plus faciles à détecter par ceux-ci.

Le hic, c’est que la détection automatisée ne couvre qu’une partie de la norme WCAG en l’état. Des tests indépendants estiment régulièrement la couverture de ces outils à environ 30 à 40 % des critères de succès. Tout le reste nécessite l’appréciation humaine : si un texte alternatif est vraiment explicite en l’occurrence de la page, si l’ordre du focus clavier est logique lorsqu’on parcourt les composants de haut en bas, si un utilisateur de lecteur d’écran peut aller au bout sans ciller de l’action pour terminer le checkout, ou bien de juger de ce fait si un message d’erreur explique avec pertinence ou s’affiche convenablement à la vue de tous quant aux actions à corriger une fois bloqué.

Considérez donc ces six erreurs comme le minimum syndical, et non comme l’Everest accompli. Après les avoir corrigées en cascade, atteler la seconde composante à une passe manuelle au grand complet est très souhaitable :

• Parcourez tout le cheminement depuis l’onglet vers la page produit du début pour finaliser le checkout en n’utilisant que le clavier (les tabulations avec vos clefs Shift+Tab, le retour arrière, et la touche Entrée). Confirmez sans concession pour évaluer avec une certitude absolue que le tunnel va bien jusqu’à la fin ou à portée de vue concernant le déroulé de l’usage opéré.
• Activez le lecteur d’écran par défaut à disposition (les gens sont habitués par VoiceOver sur les postes Mac, mais préférez l’excellente prise en main libre et d’accès rapide de NVDA sur ceux sous format Windows) et enchaîner à procéder logiquement avec la simulation du but final, le geste du client cherchant à se diriger sans faille vers ses achats.
• Zoomez à 200 % vos paramètres (navigateur notamment) pour parer de ce fait qu’il n’y ait plus aucune coupe de composants se percutant honteusement sur votre affichage dans votre interface de gestion graphique après le passage mis à l’épreuve des normes dictées.

C’est aussi de sorte la raison pour laquelle les surcouches ou tout module externe tel un overlays de correction instantanée via l’accessibilité ne vaudront point la conformité parfaite pour rendre votre boutique à la hauteur des enjeux légaux en vigueur : car tout ce paquet compressé sous sa couche par des scripts ou l’injection soudaine (tardives au chargement du store) vient annuler ce principe et est incapable de fournir en aucune manière l’aspect réfléchi ou l’arbitrage pourvu du jugement de l’humain face au contexte de son travail et finit inlassablement vers la reconduction tacite et dissimulée des fameuses six cibles d’erreurs profondes sur un code non révisé de toutes pièces de cette bévue passée en silence. Si vous vous demandez encore si la plateforme choisie vous protège à ce niveau intrinsèquement face à ce dédale, consultez si Shopify est-il conforme à l’ADA ?

Corriger et surveiller ces six erreurs dans le code natif

Chaque correction ci-dessus revient bel et bien à initier une amélioration des pans du code de votre thème existant ou un changement drastique opéré par le responsable de l’administrateur chargé d’éditer le tout. C’est somme toute délibéré : car le déploiement d’un vrai code mis en propre, structuré à la racine depuis sa maquette restera à l’instar l’œuvre unique de ce qui pourrait être bâti convenablement en ligne en cas de travaux pour les lecteurs d’écran (que ces derniers ne louperont pour rien d’en retirer bénéfice vis-à-vis des concurrents du marché) et finira, si c’est appliqué méticuleusement du moins, ce à quoi de plus fondamental d’inattaquable vous saurez vous référer un beau jour de mise en avant devant les autorités au cas ou l’envoi vers un contentieux suite au manquement sur accessibilités sur un de vos portails pour le web fera l’objet d’une enquête décidée ! Autant être clairs (l’attention à défaut d’accessibilités amène son lot d’avis pénal sans préavis : le demand letter d’associations réclame sans arrêt un point).

C’est bien ici qu’un constructeur de boutique propulsé par l’IA tire son épingle du jeu et apporte le bon point. L’application du constructeur Fudge ira naviguer minutieusement dans ce que fait votre thème actuellement utilisé sur un site affiché par ses utilisateurs et procède pour dévoiler tous les failles dissimulées de loin par vos scripts en Liquid, le CSS du design en front, ou s’assurera au final la pureté exempte du JS des pages, les efface dans les lignes au contact, pour les remettre comme des pièces au carré, et d’un coup repousse et analyse sans coupure sur de longue durée, surveillant les méfaits et alertant l’usager de potentielle présence avant une prochaine actualisation : sans subir en toute discrétion d’application apposée via de tierce instance n’importe quel code nébuleux. Son approche par la racine et n’impliquant nulle surcouche d’entrave supplémentaire (aucun overlays) injectant des ralentisseurs d’images lors de process de rafraichissement est de plus pour les temps chargés et le trafic, aucun module additionnel viendrait y faire greffer son excès (du surpoids) qui freine et saboter le site à l’heure du chargement. Cela devient logiquement le meilleur de se jumeler et parfaire son référencement en prime pour ne pas entraver ce à propos avec les gestions adéquatement visé pour la structure de type riche des données ajoutées pour une indexation par un format sur shopify et de ce qui va convenir quant à l’édition générale de la boutique.

Corrigez ces six points de vigilance en cascade depuis cette lecture pour valider ensuite en profondeur l’intégrité suite à l’achèvement du test total par finalisation par le circuit en direct sous processus manuel et à vous, ô chanceux responsable de voir écartée du lot des grandes frayeurs la proportion non négligeables de failles majeures lié aux défaillances de lecture qu’encourent la majeure part d’autres des marchants web au centre où là ça pullule par l’éclectisme de modules d’ajoutées au lieu de la qualité code !

FAQ

Articles similaires

Les overlays d'accessibilité ne rendent pas votre boutique Shopify conforme

23 Jun 2026

L'Acte européen sur l'accessibilité pour les boutiques Shopify (2026)

7 Jul 2026

L'état des performances Shopify en 2026

20 Jul 2026