Avec le lancement d’Online Store 2.0 et la réouverture de la boutique des thèmes de Shopify aux développeurs, le moment est idéal pour commencer à créer un thème Shopify. Afin de garantir la facilité d'utilisation et l’accessibilité de tous les thèmes Shopify, nous avons mis en place de nouvelles exigences et instructions pour la validation des thèmes.
L’accessibilité est un critère de plus en plus important pour les marchands au moment de choisir leur thème. Nous voulons vous donner des instructions claires et précises pour la conception de nouveaux thèmes, afin que vous puissiez intégrer les bonnes pratiques d’inclusion dès le début de votre projet.
Dans cet article, nous présentons les nouvelles exigences en matière d’accessibilité et nous vous expliquons comment assurer la compatibilité de votre thème.
Pourquoi l’accessibilité est-elle importante ?
En tant que concepteur ou développeur, vous avez la responsabilité d’inclure les bonnes pratiques d’accessibilité et de design inclusif par défaut dans votre thème.
C’est essentiel pour plusieurs raisons :
- Permettre un accès inclusif aide les personnes en situation de handicap (environ 15 % de la population mondiale) à vivre dignement et en autonomie.
- Vous pouvez profiter d’un potentiel de revenus supérieur en permettant à plus de personnes d'utiliser correctement votre thème.
- L’accessibilité contribue à l’amélioration des performances et du référencement naturel.
- En évitant toute discrimination à l’encontre des personnes handicapées qui ont recours aux technologies d’assistance, vous donnez au grand public une meilleure image des marchands utilisant votre thème.
- En intégrant dès le départ l’accessibilité à votre thème, vous aidez les marchands à éviter les actions en justice pour manque d’accessibilité numérique. De nombreuses lois et règlementations de par le monde exigent au minimum la conformité avec les règles WCAG 2.0 niveau AA.
L’accessibilité de vos thèmes doit être une priorité. Voyons plus en détail les exigences en la matière auxquelles votre thème doit répondre pour être publié dans la boutique des thèmes de Shopify.
Comment tester l’accessibilité de votre thème ?
Comme nous l’avons déjà indiqué, l’accessibilité doit être intégrée dans chaque aspect de votre thème dès la conception. Pour vous assurer que c’est bien le cas, des tests poussés sont indispensables.
Vous n’avez pas besoin de tester chaque page de votre thème, même si nous vous encourageons à le faire. Nous attendons de vous que vous testiez spécifiquement ce que nous appelons le « chemin critique », c’est-à-dire le parcours client depuis la page d’accueil jusqu’à la page de paiement. Chaque étape doit être effectuée facilement en utilisant des technologies d'assistance.
Par exemple, est-il possible en utilisant simplement le clavier de passer de la page d’accueil à une page de produit, d’ajouter un article au panier puis de procéder au paiement ?
De plus, vous n’avez pas besoin de tester toutes les sections de la page d’accueil (même si, là encore, nous vous conseillons de le faire). Concentrez-vous sur les sections les plus importantes, telles que l’en-tête de navigation, les annonces de produits et le pied de page.
Tester les réglages par défaut du thème
Assurez-vous que les paramètres, les couleurs, la mise en page, les images et le contenu du thème soient réglés par défaut pour assurer l’accessibilité. Si un thème est fourni avec plusieurs démos, testez principalement la démo par défaut.
En créant des réglages d’accessibilité par défaut, vous offrez au marchand la meilleure configuration de base. Imaginez qu'un marchand installe votre thème et se contente de mettre en ligne ses produits. Sans aucune modification ni configuration supplémentaire, le thème doit assurer une expérience utilisateur hautement accessible.
Tester objectivement les problèmes d’accessibilité
Avant de soumettre votre thème pour validation, vous devez tester objectivement les problèmes d’accessibilité. Vous pouvez pour cela utiliser les outils de test d’accessibilité Lighthouse, intégrés dans le navigateur Google Chrome.
Votre thème doit avoir un score d'accessibilité Lighthouse d’au moins 90.
Le score moyen inclut les résultats des tests Lighthouse sur les pages suivantes d'un thème :
- Page d'accueil
- Page de produit
- Page de collection
- Page du panier.
Pour calculer le score moyen, vous devez effectuer les tests d’accessibilité Lighthouse sur chacune des 4 pages. Additionnez les scores de chaque page, puis divisez le total par 4 pour obtenir le score moyen. Vous pouvez aussi créer une nouvelle feuille de calcul Google Sheets et utiliser la fonction MOYENNE pour calculer le score final.
Notre équipe de validation des thèmes exécutera les mêmes tests. Nous effectuons les tests d’accessibilité Lighthouse sur une boutique de référence, puis nous attribuons un score unique au thème, selon Lighthouse.
Pour corriger les éventuels problèmes détectés, suivez les instructions fournies par Lighthouse. Consultez également la documentation relative aux audits d’accessibilité (en anglais) si nécessaire. Pour savoir comment utiliser Lighthouse, consultez la vidéo Accessibility Testing—Totally Tooling Tips des développeurs Google Chrome.
Tester subjectivement les problèmes d’accessibilité
En plus de ces tests automatiques, l’équipe effectuera aussi une série de tests manuels pour identifier les problèmes subjectifs d’accessibilité. L’objectif ici est d’aider à identifier les barrières à l’accès les plus fréquentes lors de l’utilisation de technologies d'assistance. Nous détaillons ci-dessous ces 8 problèmes d’accessibilité subjectifs.
1. Tous les éléments d'une page doivent être accessibles avec le clavier
Certains utilisateurs ne peuvent pas utiliser de souris. Utilisez simplement le clavier pour tester la navigation et le fonctionnement de votre thème. De la page d’accueil jusqu’au paiement, tous les éléments doivent être accessibles avec le clavier uniquement. Tous les liens, boutons, champs de saisie et contrôles personnalisés doivent être accessibles et utilisables avec le clavier.
Remarque : le contenu tel que le texte brut, les conteneurs de contenus, les images et autres n’a pas à être accessible avec le clavier.
Voici les points auxquels l’équipe de validation est particulièrement attentive :
- Les éléments de navigation déroulants doivent s’ouvrir d’un clic, et non par le focus (effet de surbrillance autour d’un élément). Cela permet aux utilisateurs de clavier de contourner facilement la zone de navigation. Il faut cliquer sur
Enter
(Entrée) ouSpace
(Espace) pour ouvrir les éléments, et surEsc
(Echap) pour les fermer et revenir à l’élément parent. - Les fenêtres modales doivent déplacer le focus sur ou à l’intérieur d’elles-mêmes. Cela permet d'orienter l’utilisateur de clavier vers le contenu nouvellement affiché. La touche Echap permet de revenir à l’élément qui a lancé la fenêtre modale.
- Les tiroirs du panier qui apparaissent sur le côté ou en haut de l’écran de manière dynamique doivent déplacer le focus sur ou à l’intérieur d’elles-mêmes. Cela permet d'orienter l’utilisateur de clavier vers le contenu nouvellement affiché. La touche Echap permet de revenir à l’élément qui a lancé la fenêtre modale.
- Les cartes de produits, qui incluent souvent plusieurs liens vers la même page (image, titre, « Plus d’infos », etc.) doivent être conçues de façon à ce qu’il n’y ait qu’un seul arrêt de tabulation, tout en permettant la navigation à travers toutes les informations avec une technologie d’assistance.
COMMENT TESTER
Voici quelques astuces pour utiliser le clavier lorsque vous testez votre thème :
- Utilisez la touche
Tab
pour vous déplacer sur le prochain élément interactif d’une page. - Utilisez
Shift
+Tab
pour revenir à l’élément précédent. - Utilisez
Enter
pour activer les liens,Enter
ouSpace
pour activer les boutons etSpace
pour activer les contrôlesinput
(cases à cocher, boutons radio, sélections). - Utilisez les touches de direction pour vous déplacer entre des contrôles radio groupés.
À SURVEILLER
Voici les éléments auxquels vous devez faire particulièrement attention pendant vos tests d’accessibilité :
- Les éléments anchor (ancre) sont utilisés pour ouvrir de nouvelles pages ou pour déplacer le focus sur du contenu de la même page/du même contexte.
- Les contrôles d’envoi de formulaire ne sont pas désactivés par défaut.
- Les éléments button (bouton) sont utilisés pour activer les fenêtres modales et les tiroirs de panier. Lorsqu’ils sont activés, le focus est déplacé vers la fenêtre.
- La touche Echap permet de fermer les fenêtres modales, paniers latéraux ou éléments déroulants et renvoie le focus vers l’élément précédent.
- Seuls les éléments interactifs par nature doivent être focalisables : liens, boutons, contrôles de formulaires, etc. Le contenu statique tel que le texte brut, les images et autres ne doit pas pouvoir être actif. Utilisez l’attribut tabindex avec prudence.
RESSOURCES (EN ANGLAIS)
- WCAG 2.1.1 Keyboard – W3C
- Disclosure (Show/Hide) – WAI-ARIA Authoring Practices
- Dialog (Modal) – WAI-ARIA Authoring Practices
- Cards – Inclusive Components
- Keyboard access fundamentals – Google Developers
- Ensure all interactive features are keyboard-accessible – Deque University
- Keyboard – MDN
- Keyboard Accessibility – WebAIM
2. Les éléments de formulaire input
doivent avoir des éléments label
avec des attributs for
Les contrôles de formulaire input
, textarea
et select
nécessitent un élément label
associé par programmation. L'élément label
représente une légende pour un objet. Afin de fournir du contexte sur l’objectif de l’élément input
via un calcul de nom accessible, l’attribut for
d’un élément label
doit correspondre à l’attribut id
de l’élément input
associé. Sans légende, les utilisateurs de lecteurs d’écran risquent de ne pas savoir ou de ne pas comprendre l’objectif des données demandées. Les utilisateurs de la dictée vocale pourraient ne pas être capables d'appeler la commande pour sélectionner le champ de formulaire spécifié.
L’attribut placeholder
ne peut pas remplacer l’attribut label
, car son objectif est de fournir des données d’exemple.
❌ Exemple incorrect : utilisation d’un « label » visuel uniquement
<div class="label">First Name</div>
<input type="text" name="first_name" autocomplete="given-name">
✅ Exemple correct : utilisation d’un élément label
, assigné par programmation à l’élément input
associé
<label for="firstName">First Name</label>
<input type="text" id="firstName" name="first_name" autocomplete="given-name">
Vous pouvez également appliquer l’attribut aria-label
avec une valeur de texte explicite ou aria-labelledby
en référençant un conteneur de contenu existant directement dans l’élément input
, ce qui fournit un nom accessible et répond aux exigences des tests. Utilisez la technique appropriée à chaque cas.
✅ Exemple correct : appliquer l’attribut aria-label
pour fournir une légende
<input type="search" aria-label="Search" name="q">
COMMENT TESTER
Le rapport Lighthouse indiquera si des légendes sont manquantes pour certains champs de formulaire. Pour tester manuellement ces éléments :
- Ouvrez les outils de développement Chrome.
- Assurez-vous que l’élément
label
existe dans le DOM. - Vérifiez que la valeur de l’attribut
for
correspond à l'attributid
de l’élémentinput
associé.
À SURVEILLER
Les éléments input
de formulaires doivent être associés à un élément label
, de préférence un élément label toujours visible. Vous pouvez également appliquer l’attribut aria-label
avec une valeur de texte explicite ou aria-labelledby
en référençant un conteneur de contenu existant directement dans l’élément input
, ce qui fournit un nom accessible et répond aux exigences des tests.
RESSOURCES (EN ANGLAIS)
- WCAG 3.3.2 Labels or Instructions – W3C
- Use Labels for Forms to Maximize Screen Reader Compatibility – Deque University
- Label – MDN Associate Form
3. Les thèmes doivent utiliser un code HTML valide
Un code HTML valide contribue à assurer une expérience solide, quel que soit l’appareil ou le navigateur. Il contribue également à l’accessibilité de l’expérience utilisateur. Avec du HTML valide, le navigateur récupérera les données du DOM et fournira les informations requises à la technologie d’assistance. Ce sont ces informations qui forment ce que l’on appelle l’arbre d’accessibilité.
Rédigez ou générez toujours du HTML valide, tel que défini dans les spécifications HTML.
COMMENT TESTER
- Si la boutique de test est publique, copiez l’URL et collez-la dans l’outil Nu Html Checker.
- Si la boutique est protégée par un mot de passe :
- Ouvrez l’inspecteur des outils de développement.
- Copiez le code depuis la fenêtre de l’inspecteur.
- Collez-le dans la zone de texte de Nu Html Checker.
À SURVEILLER
Toutes les erreurs doivent être corrigées. En général, vous pouvez ignorer les avertissements, mais procédez au cas par cas.
RESSOURCES (EN ANGLAIS)
- WCAG 4.1.1 Parsing – W3C
- HTML specification – WHATWG
- The Accessibility Tree – Google Developers
- Use Valid Markup to Prevent Possible Accessibility Issues – Deque University
- HTML – MDN
4. Un texte alternatif image.alt
doit être disponible pour toutes les images de produits
Le texte alternatif, alt, des images de produits de la boutique de démonstration doit décrire précisément chaque produit : ce dont il s’agit, ses caractéristiques matérielles, comment le mannequin porte/utilise le produit, etc. Fournissez assez d’informations pour que l'utilisateur puisse s’en faire une représentation exacte, mais pas trop pour ne pas le perdre. Cela permet aux utilisateurs de lecteur d’écran de comprendre ce qu’est un produit.
Insérer le titre du produit à la place d’une description de l’image n’est pas une solution satisfaisante.
Le texte alternatif doit être fourni dans chaque modèle où apparaît l’image : la section Produits à la une de la page d’accueil, les pages de collections, les images de variantes de produits, le panier, etc. L’utilisateur a ainsi assez de contexte tout au long de son parcours.
❌ Exemple incorrect : utilisation du titre du produit comme texte alt
<img src="{product.image.src}" alt="{product.title}">
✅ Exemple correct : utilisation d’un texte alt
fourni par le marchand
<img src="{product.image.src}" alt="{product.image.alt}">
Regardez l’image ci-dessous. Comment décririez-vous ce produit à quelqu’un qui ne peut pas le voir ?

Voici un bon exemple de description pour cette image :
<img src="dress.jpg" alt="Leather dress with thin, rounded black collar in front and back, short black sleeves. Dress pattern is made up of colored and symmetrical vertical rectangles. Colors include mostly various shades of blue with a small amount of yellow, white, red, maroon and grey. Waist tapers inward.">
COMMENT TESTER
Utilisez les outils pour les développeurs Chrome pour inspecter les images de produits. Vous pouvez aussi choisir d’utiliser un lecteur d’écran : VoiceOver sur macOS ou NVDA sur Windows. Utilisez le curseur virtuel pour naviguer dans chaque page et écoutez la description de chaque image de produit.
À SURVEILLER
Le texte alternatif alt
doit décrire le produit. Fournissez assez d’informations pour que l'utilisateur puisse s’en faire une représentation exacte, mais pas trop pour ne pas le perdre.
Un texte alternatif doit informer l’utilisateur du contenu de l’image. Pour en savoir plus, consultez l’article Considerations When Writing Alt Text du blog Shopify UX.
RESSOURCES (EN ANGLAIS)
- WCAG 1.1.1 Non-text Content – W3C
- Alt Text Should Describe the Purpose of the Image – Deque University
- The Image Embed element – MDN
- Alternative Text – WebAIM
5. Testez le contraste de couleurs
Le contraste de couleurs entre l’arrière-plan et le premier plan (généralement du texte) doit être suffisant pour assurer une bonne lisibilité. Les utilisateurs daltoniens ou ayant une vue faible, ou ceux qui ont le soleil dans les yeux en regardant leur écran ont besoin d'un contraste suffisant pour bien voir les contenus textuels ou graphiques.
COMMENT TESTER
L'outil Lighthouse signalera tout problème de contraste détecté. Pour tester manuellement les couleurs (comme pour du texte sur une image de fond), utilisez le Colorimètre numérique macOS ou un outil similaire pour sélectionner les valeurs de couleurs, puis utilisez l’outil Contrast Ratio pour tester le contraste.
À SURVEILLER
- Le contenu textuel et le texte de contrôle doivent répondre aux critères 1.4.3: Contrast (Minimum) dans leurs états par défaut, pointé, focalisé ou activé :
- Ratio de contraste de
4.5:1
pour le texte de taille normale (moins de 24 pixels ou 18 pixels, gras). - Ratio de contraste de
3:1
pour le grand texte (au moins 24 pixels ou 18 pixels, gras). - Les bordures des contrôles, les arrière-plans adjacents (s’il n’y a pas de bordure), les icônes et les anneaux de focus personnalisés doivent répondre aux critères 1.4.11: Non-text Contrast :
- Ratio de contraste de
3:1
pour le contenu non textuel par rapport à son arrière-plan. - Consultez les exemples de composants d’interface utilisateur actifs (en anglais) pour en savoir plus.
Composants exemptés des conditions ci-dessus :
- Les contrôles dont l’état est désactivé, via l’attribut
disabled
. - Les anneaux de focus par défaut du navigateur.
- Le texte intégré dans des images à titre de décoration uniquement.
- Les logos.
RESSOURCES (EN ANGLAIS)
- WCAG 1.4.3 Contrast (Minimum) – W3C
- 1.4.11 Non-text Contrast – W3C
- Color and contrast accessibility – Google Developers
- Check Text and Background for Sufficient Color Contrast – Deque University
- Color contrast – MDN
- Contrast and Color Accessibility – WebAIM
6. Les éléments focalisables doivent avoir un état focalisé visible
Les utilisateurs voyants qui utilisent uniquement le clavier, ceux qui recourent à la dictée vocale, ceux qui sont malvoyants ou ceux qui ne peuvent pas utiliser la souris doivent pouvoir connaître la position actuelle du curseur du clavier.
La position du curseur de clavier est représentée par l’anneau de focus. En CSS, l’anneau de focus est généralement décrit à l’aide de la propriété outline
. Nous vous recommandons fortement de ne pas supprimer l’anneau de focus par défaut.
❌ Exemple incorrect : supprimer l’anneau de focus pour tous les utilisateurs
*:focus {
outline: none;
}
✅ Exemple correct : ne pas supprimer l’anneau de focus par défaut
*:focus {
/* outline: none; */
}
Si vous préférez, vous pouvez appliquer la pseudo-classe :focus-visible
. Cela permet de supprimer l’anneau de focus visible pour les utilisateurs de la souris et de l’écran tactile, mais pas pour les utilisateurs du clavier uniquement. Attention toutefois, cette fonctionnalité n’est pas prise en charge nativement par tous les navigateurs.
✅ Exemple correct : utiliser la pseudo-classe :focus-visible
pour supprimer l’anneau de focus uniquement pour les utilisateurs de la souris et de l’écran tactile
*:focus:not(:focus-visible) {
outline: none;
}
Si un anneau de focus est présent, son contraste de couleurs doit respecter le ratio 3:1
.
COMMENT TESTER
Testez en utilisant la touche Tab
pour déplacer le focus vers l’avant et les touches Shift
+Tab
pour aller vers l’arrière.
À SURVEILLER
Lorsque vous vous déplacez dans la page avec le clavier, voyez-vous l’anneau de focus visuel ? Savez-vous toujours où se situe le focus de clavier sur la page ? Les éléments activables de la page tels que les liens, les boutons et les contrôles de formulaires doivent afficher un anneau de focus visuel lorsqu’ils sont focalisés.
RESSOURCES (EN ANGLAIS)
- WCAG 2.4.7 Focus Visible – W3C
- Style focus – Google Developers
- Enhancing Visual Focus for the Sighted Keyboard User – Deque University
- outline – MDN
- :focus-visible – MDN
- Focus indicators – WebAIM
7. L’ordre du focus visible doit correspondre à l’ordre du DOM
Les anneaux de focus du clavier doivent se déplacer dans un ordre linéaire et prévisible : de haut en bas et de gauche à droite (ou de droite à gauche si cela correspond au sens de lecture). Si vous déplacez le focus dans des directions inattendues à cause d'une réorganisation du contenu CSS, cela risque de poser des problèmes aux utilisateurs malvoyants ou présentant des troubles cognitifs ou neurologiques.
Par exemple, les propriétés CSS telles que flex-direction
avec une valeur de row-reverse
doivent si possible être évitées. La règle de base est de respecter l’ordre du DOM. C’est également vrai pour les points d’arrêt, y compris sur les mises en page « mobiles ».
❌ Exemple incorrect : inverser le contenu visuellement uniquement
.box {
display: flex;
flex-direction: row-reverse;
}
✅ Exemple correct : ordre du contenu correspondant au DOM
.box {
display: flex;
flex-direction: row;
}
COMMENT TESTER
Utilisez la touche Tab
pour déplacer le focus vers l’avant et les touches Shift
+Tab
pour aller vers l’arrière.
À SURVEILLER
L’anneau de focus du clavier doit se déplacer de haut en bas et de gauche à droite (ou de droite à gauche selon le sens de lecture).
RESSOURCES (EN ANGLAIS)
- WCAG 2.4.3 Focus Order – W3C
- Content reordering – Google Developers
- Navigation order – WebAIM
8. Taille des zones cibles tactiles
Les utilisateurs ayant une motricité fine limitée ont besoin de grandes zones cibles tactiles. Si les zones cibles sont trop petites, les utilisateurs risquent d’activer un autre contrôle par erreur. Cela inclut les utilisateurs de la souris et de l’écran tactile aussi bien que les personnes âgées.
Les critères WCAG 2.5.5 Target Size définissent une taille de zone cible de 44
par 44
pixels CSS. Cela s’applique à toutes les méthodes essentielles de navigation et de saisie : bascules de navigation mobile, champs de saisie des formulaires, éléments de navigation, etc. Les liens dans le corps du texte sont exclus.
Remarque : utilisez la propriété CSS padding
pour augmenter la taille physique du contrôle sans perturber le design prévu.
❌ Exemple incorrect : définir une largeur et une hauteur fixes avec des valeurs en pixels
.navigation-toggle {
height: 32px;
width: 32px;
}
✅ Exemple correct : utiliser des unités flexibles et le padding
pour augmenter la taille de la zone cible tactile
.navigation-toggle {
height: 2em;
width: 2em;
padding: 1.25em;
}
COMMENT TESTER
Utilisez les outils pour les développeurs Chrome pour inspecter rapidement la taille physique d’un contrôle. La taille est indiquée en haut à droite de la fenêtre d'inspection.
À SURVEILLER
Les éléments essentiels tels que les bascules de navigation mobile, les champs de saisie et boutons de formulaires, etc. doivent avoir une taille physique de zone cible tactile d’au moins 44
par 44
pixels CSS.
RESSOURCES (EN ANGLAIS)
- WCAG 2.5.5 Target Size – W3C
- Accessible tap targets – Google Developers
- Large touch targets – The A11Y Project
Assurer l’accessibilité de vos thèmes
Pour plus d’informations sur l’accessibilité des thèmes, consultez les exigences de la boutique des thèmes et la page recensant les bonnes pratiques d’accessibilité pour les thèmes Shopify de Shopify.dev.
Nous encourageons les développeurs qui utilisent VS Code à installer le plug-in axe Accessibility Linter. Ce linter traque et signale tous les problèmes de balisage qui pourraient être des freins à l’accessibilité lorsque vous modifiez vos modèles de thèmes.
Pour assurer une accessibilité sans faute à votre thème, vous pouvez aussi contacter notre partenaire Fable Tech Labs. En intégrant le retour d’expérience de personnes qui utilisent les technologies d'assistance, vous pourrez améliorer l'accessibilité et la facilité d’utilisation de votre thème.
Répondre à ces exigences n’est pas seulement un prérequis pour publier votre thème dans la boutique des thèmes de Shopify, c’est également un premier pas vers le succès de vos marchands et de leurs clients.
Rejoignez le programme des partenaires de Shopify
Inscrivez-vous gratuitement au programme partenaire de Shopify. Accédez à des outils et ressources pour aider les marchands Shopify à développer leur activité et faites partie d’un écosystème riche en opportunités.
Devenir partenaire ShopifyPublié par Maud Leuenberger. Maud est la rédactrice en chef du blog français de Shopify.
Texte original par Scott Vinkle. Traduction par Solenn Marchand.