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

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.
• Ces six erreurs sont détectables automatiquement, un scanner gratuit peut donc les trouver en quelques minutes. Chacune a un critère de succès WCAG spécifique et une correction spécifique dans le code natif.
• La solution consiste toujours à modifier le code de votre thème ou un champ de l’interface d’administration, et non à ajouter un widget par-dessus. Les surcouches (overlays) laissent l’erreur sous-jacente en place.
• Les scanners automatisés détectent ces six erreurs car elles sont sans ambiguïté, mais cela ne couvre qu’environ un tiers des critères WCAG. Une vérification manuelle au clavier et avec un lecteur d’écran reste donc importante.

Améliorer l’accessibilité de votre boutique Shopify ne commence pas par la mémorisation de tous les critères WCAG. Cela commence par six erreurs spécifiques. L’étude annuelle WebAIM Million sur le million de pages d’accueil les plus visitées place les mêmes six problèmes en tête de liste chaque année, et à eux seuls, ils constituent la majeure partie de toutes les erreurs détectées.¹

Ci-dessous, chaque erreur avec son critère WCAG, la façon dont elle se présente dans un thème Shopify, et la solution.

Pourquoi vous pouvez nous faire confiance

Jacques possède plus de 15 ans d’expérience en développement et a aidé de nombreuses marques Shopify à mettre en ligne des boutiques rapides et accessibles. Nous évoluons dans l’écosystème Shopify depuis plus de quatre ans et développons Fudge, l’opérateur IA pour les boutiques Shopify, avec une note de 4.9 sur le Shopify App Store. La correction des problèmes d’accessibilité directement dans le code natif du thème fait partie de ses fonctions. Pour en savoir plus sur le contexte juridique et les normes derrière 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 révélé des échecs WCAG détectables sur 95,9 % des pages d’accueil, avec une moyenne de 56,1 erreurs par page.¹ Ces six catégories regroupent presque toutes ces erreurs, et la liste n’a pratiquement pas évolué en sept ans.

Les pourcentages représentent la part du million de pages d’accueil les plus visitées sur lesquelles WebAIM a détecté chaque erreur en février 2026.¹ Corrigez ces points un par un pour éliminer la majeure partie des risques. Pour connaître l’intégralité des critères au-delà de ces six-là, consultez notre checklist WCAG 2.2 AA pour Shopify.

1. Texte à faible contraste

De quoi s’agit-il. Un texte trop clair par rapport à son arrière-plan pour être lu confortablement. C’est l’erreur la plus courante sur le web, présente sur la grande majorité des pages.

Pourquoi cela échoue aux critères WCAG. Le critère de succès 1.4.3 Contraste (minimum) exige un ratio de contraste d’au moins 4.5:1 pour le texte normal et de 3:1 pour le texte de grande taille (environ 18px en gras ou 24px en normal et plus). Le texte gris sur fond blanc et le texte pâle sur un bouton aux couleurs de la marque en sont les coupables habituels.

Comment cela se présente sur Shopify. Les thèmes affichent les choix de couleurs sous forme de jeux de couleurs dans l’éditeur de thème. Une palette de marque, choisie pour son esthétique plutôt que pour son contraste, s’applique d’un coup au corps du texte, aux boutons, aux badges de promotion et aux textes d’espace réservé (placeholders) sur tous les modèles (templates) en même temps. Une légende gris clair ou un bouton « Ajouter au panier » de couleur pastel clair peut chuter bien en dessous de 4.5:1 sans pour autant paraître visiblement anormal.

La solution. Ajustez les variables de couleur, pas les éléments individuels. Dans l’éditeur de thème, ouvrez Paramètres du thème > Couleurs et augmentez le contraste du texte et des boutons de chaque jeu de couleurs jusqu’à ce qu’ils passent le test. Si vous modifiez directement le code, les valeurs se trouvent dans les propriétés CSS personnalisées 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 contraste texte/fond atteigne 4.5:1 */
    --color-background: 255, 255, 255;
}

Vérifiez chaque combinaison avec un outil de contraste, comme celui intégré aux Chrome DevTools ou le vérificateur de contraste de WebAIM. N’oubliez pas de tester le texte des boutons par rapport au fond du bouton, et non par rapport à l’arrière-plan de la page. Corriger la variable de couleur répare 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 attribut lang sur son élément <html>, ce qui empêche les technologies d’assistance de savoir dans quelle langue lire le contenu.

Pourquoi ça ne respecte pas les WCAG. Le critère 3.1.1 Langue de la page exige que la langue par défaut de chaque page soit définie de manière programmatique. Sans cela, les lecteurs d’écran risquent d’utiliser de mauvaises règles de prononciation pour toute la page.

Comment ça se présente sur Shopify. Ce problème se trouve dans un seul fichier : theme.liquid, le layout qui enveloppe chaque page. Un thème bien conçu définit l’attribut à partir de la langue de la vitrine. Les développements sur mesure et les thèmes fortement modifiés codent parfois une valeur en dur, ou suppriment complètement l’attribut lors d’une refonte.

La solution. Définissez lang à partir de la locale de la requête pour qu’il reste correct sur chaque marché et vitrine traduite. Ouvrez layout/theme.liquid et vérifiez que la balise d’ouverture ressemble à ceci :

<!doctype html>
<html
  class="no-js"
  lang="{{ request.locale.iso_code }}"
>

L’utilisation de {{ request.locale.iso_code }} au lieu d’un "en" fixe permet à Shopify Markets et aux boutiques multilingues de servir automatiquement le bon code de langue à chaque visiteur. C’est une modification d’une seule ligne qui corrige l’erreur sur toutes les pages en même temps.

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

Ces six erreurs partagent un point commun : elles sont détectables par une machine. Un outil peut prouver qu’un élément image n’a pas d’attribut alt, qu’un ratio de contraste est inférieur à 4,5:1, ou qu’un <button> ne contient pas de texte. C’est pourquoi un scanner automatisé gratuit comme axe DevTools, WAVE ou Lighthouse les repère en quelques secondes, et pourquoi elles dominent les données du WebAIM Million. WebAIM effectue ses mesures avec des outils automatisés, les six résultats les plus courants sont donc les six les plus faciles à détecter.

Le hic, c’est que la détection automatisée ne couvre qu’une partie des règles WCAG. Des tests indépendants estiment régulièrement que la couverture automatisée ne représente qu’environ 30 à 40 % des critères de succès. Le reste nécessite un jugement humain : déterminer si le texte alternatif est vraiment pertinent, si l’ordre du focus au clavier est logique, si un utilisateur de lecteur d’écran peut finaliser sa commande, ou si un message d’erreur explique comment corriger le problème.

Considérez donc ces six points comme une base, pas comme une fin en soi. Une fois que vous les avez corrigés, faites une vérification manuelle :

• Parcourez tout le chemin, de la page produit jusqu’à la finalisation de la commande, en utilisant uniquement le clavier (Tab, Maj+Tab, Entrée). Vérifiez que vous pouvez atteindre et utiliser chaque contrôle.
• Activez un lecteur d’écran (VoiceOver sur Mac, le logiciel gratuit NVDA sur Windows) et essayez d’acheter quelque chose.
• Zoomez à 200 % et vérifiez que rien n’est tronqué ou ne se chevauche.

Notre guide sur la réalisation d’un audit d’accessibilité de site web détaille entièrement cette analyse manuelle, et explique comment échantillonner les pages et consigner vos découvertes.

C’est aussi la raison pour laquelle les surcouches d’accessibilité ne rendent pas une boutique conforme : un script greffé au moment du chargement ne peut pas fournir le jugement requis par l’analyse manuelle, et laisse les six erreurs sous-jacentes dans le code. Si vous vous demandez encore si la plateforme vous protège, lisez notre article pour savoir si Shopify est conforme à l’ADA.

Corriger et revérifier les six erreurs dans le code natif

Toutes les corrections ci-dessus consistent à modifier le code de votre thème ou un champ dans l’admin. C’est délibéré. Une vraie modification du code correspond à ce qu’un développeur déploierait, ce qui profite réellement à un lecteur d’écran, et ce qui tient la route si vous recevez un jour une mise en demeure.

C’est là que Fudge entre en jeu. C’est l’opérateur IA pour les boutiques Shopify : lorsque vous demandez un audit d’accessibilité, il parcourt votre thème en ligne, trouve ces six erreurs dans vos fichiers Liquid, CSS et JavaScript, et prépare les corrections à la source pour que votre équipe puisse les prévisualiser et les publier. Demandez à nouveau l’audit après la mise à jour d’un thème ou l’installation d’une nouvelle app, pour éviter qu’un changement ne réintroduise discrètement une erreur. Comme le résultat est du code natif plutôt qu’une couche injectée, il n’y a aucun script supplémentaire pour ralentir la page. Cela s’intègre naturellement avec des tâches connexes telles que l’ajout de données structurées et l’édition globale de la boutique.

Éliminez ces six erreurs, effectuez une passe manuelle, et vous aurez supprimé la majeure partie des risques liés à l’accessibilité sur une boutique typique, à l’endroit même où ils se trouvent.

FAQ