La Checklist WCAG 2.2 AA pour les Boutiques Shopify

WCAG 2.2 AA est la version et le niveau auxquels presque toutes les lois sur l’accessibilité font désormais référence, et c’est la cible que nous recommandons pour toute boutique Shopify. Voici une liste de contrôle pratique : les critères de succès qui comptent, organisés selon les quatre principes POUR, chacun étant associé à l’endroit où le problème réside réellement dans un thème Shopify.

Conformez-vous une fois aux WCAG 2.2 AA et vous satisferez en même temps aux régimes antérieurs. Les WCAG 2.2 sont un surensemble des 2.1, donc les respecter permet également de respecter la norme de règlement de l’ADA aux États-Unis, la norme européenne EN 301 549 (WCAG 2.1 AA), ainsi que les règles britanniques, canadiennes et australiennes. Un seul travail les couvre toutes.

Points clés

• Les WCAG 2.2 AA sont la référence légale actuelle. S’y conformer satisfait également aux WCAG 2.1 AA et à tous les régimes qui s’appuient dessus.
• La conformité de niveau AA implique de respecter chaque critère de succès de niveau A et de niveau AA. Les critères AAA ne sont pas requis.
• Les WCAG 2.2 ont ajouté 9 critères de succès par rapport aux 2.1 et en ont supprimé un (4.1.1 Analyse syntaxique). Six des neuf se situent au niveau A ou AA.
• Les scanners automatisés ne détectent qu’environ 30 à 40 % des critères. Une vérification manuelle au clavier et un passage avec un lecteur d’écran sont nécessaires pour couvrir le reste.
• Chaque véritable correctif nécessite une modification du code de votre thème (Liquid, CSS, JavaScript), et non un widget superposé.

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 à mettre en ligne des boutiques accessibles et rapides. Nous sommes dans l’écosystème Shopify depuis plus de quatre ans et avons créé Fudge, un créateur et éditeur de boutique par IA avec une note de 4.9 sur le Shopify App Store. Fudge détecte les problèmes d’accessibilité dans votre thème et les corrige directement dans le code natif. Les numéros de critères et les niveaux ci-dessous sont tirés directement de la recommandation officielle WCAG 2.2 du W3C, et non de mémoire.

Cette checklist est le compagnon pratique de notre guide complet sur la conformité ADA et WCAG pour Shopify. Si vous souhaitez avoir un aperçu juridique plutôt que les critères techniques, commencez par là.

---

Comment lire cette checklist

Les WCAG comportent trois niveaux de conformité : A (minimum), AA (la cible) et AAA (le plus élevé). Pour revendiquer le niveau WCAG 2.2 AA, vous devez satisfaire chaque critère de niveau A et chaque critère de niveau AA. Les critères AAA sont optionnels et ne font pas partie du standard légal ; nous les signalons donc sans pour autant les exiger.

Les directives sont regroupées sous quatre principes, connus par l’acronyme POUR :

• Perceptible (Perceivable). Les utilisateurs doivent pouvoir percevoir le contenu via l’un de leurs sens.
• Utilisable (Operable). Les utilisateurs peuvent manipuler tous les contrôles.
• Compréhensible (Understandable). Le contenu et le comportement sont prévisibles.
• Robuste (Robust). Les technologies d’assistance peuvent interpréter le markup (HTML).

Chaque section ci-dessous dresse la liste des critères les plus susceptibles de faire défaut sur une boutique Shopify, en y associant le numéro exact, son niveau et comment le corriger dans votre thème.

Quoi de neuf dans les WCAG 2.2

Les WCAG 2.2 sont devenues une recommandation du W3C en octobre 2023 et constituent la version actuelle.¹ Elles ont conservé tout ce qui se trouvait dans la 2.1 et ont ajouté neuf nouveaux critères de succès, tout en en supprimant un. Être précis sur leurs niveaux est important, car seuls les ajouts de niveau A et AA affectent votre objectif de conformité.²

Critère de succès	Niveau	Dans votre objectif AA ?
2.4.11 Masquage du focus (minimum)	AA	Oui
2.4.12 Masquage du focus (amélioré)	AAA	Non
2.4.13 Apparence du focus	AAA	Non
2.5.7 Mouvements de glissement	AA	Oui
2.5.8 Taille de la cible (minimum)	AA	Oui
3.2.6 Aide cohérente	A	Oui
3.3.7 Saisie redondante	A	Oui
3.3.8 Authentification accessible (minimum)	AA	Oui
3.3.9 Authentification accessible (améliorée)	AAA	Non

Deux points importants à retenir. Le critère 2.4.13 Apparence du focus est de niveau AAA, et non AA, il n’est donc pas requis pour la conformité AA même s’il concerne le focus. Et le critère 4.1.1 Analyse a été supprimé dans les WCAG 2.2 : il est obsolète, car les navigateurs modernes gèrent très bien le code mal formé qu’il ciblait, vous n’avez donc plus besoin de le tester.²

Les six nouveaux critères A et AA sont ceux qu’il faut ajouter à votre audit 2.1 existant. Nous les détaillons dans leurs sections POUR ci-dessous.

Perceptible

Tout ce dont un client a besoin pour comprendre la page doit être accessible à la vue, à l’ouïe ou aux technologies d’assistance.

Alternatives textuelles et médias

• 1.1.1 Contenu non textuel (A). Toute image porteuse de sens nécessite une alternative textuelle. Dans Shopify, il s’agit du champ alt sur les images de produits, de collections et toute image ajoutée via une section ou l’éditeur de thème. Les images décoratives doivent avoir un alt="" vide pour que les lecteurs d’écran les ignorent. Les commandes uniquement constituées d’icônes (panier, recherche, menu hamburger) ont également besoin d’un nom accessible, ce qui recoupe les critères du principe Utilisable ci-dessous.
• 1.2.2 Sous-titres (préenregistrés) (A) et 1.2.5 Audiodescription (préenregistrée) (AA). Si vous intégrez des vidéos de produits ou un « lifestyle reel » (vidéo d’ambiance), fournissez des sous-titres, ainsi qu’une audiodescription ou une alternative textuelle lorsque les visuels véhiculent des informations absentes de la piste audio.

Pour les images de produits en particulier, notre audit gratuit des données de catalogue Shopify analyse la couverture du texte alternatif sur l’ensemble de votre catalogue, ce qui vous permet de voir l’ampleur de l’écart vis-à-vis du critère 1.1.1 avant de commencer à rédiger.

Couleur et contraste

• 1.4.1 Utilisation de la couleur (A). Ne vous fiez jamais uniquement à la couleur pour faire passer un message. Un prix promo affiché uniquement en rouge, ou une erreur de formulaire matérialisée juste par une bordure rouge, échouera au test. Ajoutez du texte, une icône ou un soulignement.
• 1.4.3 Contraste (Minimum) (AA). Le texte normal requiert un ratio de contraste d’au moins 4.5:1 avec son arrière-plan ; le grand texte (environ 24px, ou 18.66px en gras) doit être de 3:1. C’est le faux pas le plus courant sur Shopify, généralement lié aux couleurs de la marque exploitées au niveau du texte principal, des boutons ou des placeholders (textes indicatifs). Corrigez ceci depuis les réglages couleurs de votre thème ou en CSS.
• 1.4.11 Contraste des éléments non textuels (AA). Les composants d’interface et graphiques majeurs nécessitent un contraste de 3:1. Pensons aux bordures gris clair des inputs, aux boutons d’ajout au panier juste cerclés (outline) ou à ce ring de focus trop discret pour être vu.

Adaptation de la mise en page

• 1.4.4 Redimensionnement du texte (AA). Le texte doit rester lisible via un zoom à 200 % sans aucune perte de contenu. Évitez de fixer des hauteurs fixes en pixels sur les conteneurs empêchant l’extension du texte.
• 1.4.10 Redistribution (Reflow) (AA). Le contenu doit être redistribué en formant une seule colonne sur un viewport de 320 pixels CSS de large (équivalent au zoom à 400 %) sans scroll horizontal. Dans Shopify, on sanctionne souvent les sticky headers, les larges tableaux et les sections multi-colonnes.
• 1.4.12 Espacement du texte (AA) et 1.4.13 Contenu au survol ou à la prise de focus (AA). Le contenu doit résister sans casse lors de l’accroissement des espaces entre les lettres ou les lignes. Aussi, toute popover qui se déclenche au hover/au focus (méga-menu, infobulle de guide des tailles) doit pouvoir être ignorée, survolée et rester persistante.
• 1.3.5 Identification de l’objectif de la saisie (AA). Les champs de profil collectant les infos classiques (nom, e-mail, adresse au checkout ou en création de compte) doivent renseigner l’attribut autocomplete afin de faciliter le travail des navigateurs et outils d’assistance.

Utilisable

Chaque menu, slider, ou bouton doit répondre au clavier et au toucher, et pas uniquement à la souris.

Accès au clavier

• 2.1.1 Clavier (A) et 2.1.2 Pas de piège au clavier (A). Tout ce que l’on contrôle en souris doit être maniable via clavier, et le focus ne doit jamais se bloquer. Sur une boutique classique, ceci est bafoué par les méga-menus, paniers sous forme de tiroir (cart drawer), modales de vue rapide et galeries d’images customisés à grand renfort de JavaScript mais délaissant le clavier. À l’aide de Tab et d’Entrée, le client doit pouvoir ouvrir son panier coulissant, le consulter en profondeur et le refermer sans pépins.
• 2.4.1 Éviter les blocs (A). Proposez un ‘skip link’ (lien d’évitement) pour que l’utilisateur au clavier ignore le header complexe pour filer vers le cœur de page. Le thème Dawn ou la majorité des thèmes du store en ont un natif ; les boutiques surchargées le perdent régulièrement.

Visibilité du focus

• 2.4.7 Focus visible (AA). L’élément actif recevant le focus clavier doit s’orner d’un indicateur de focus décelable. Les thèmes pêchent très souvent sur ce point via une directive globale outline: none en CSS retirant ces indicateurs. Ôtez-la ou remplacez-la par une mise en forme personnalisée qui soit flagrante.
• 2.4.11 Focus non masqué (Minimum) (AA). Nouveau avec les 2.2. Lorsqu’un élément accueille le focus, il ne doit en aucun cas être occulté par un élément superposé. Les coupables sont souvent les sticky headers (en-têtes collants), les bannières de cookies et les widgets de chat qui flottent et couvrent des champs clés lors d’une navigation à la touche Tab.

Pointeur, tactile et taille de la cible

• 2.5.7 Mouvements de glissement (AA). Nouveau en 2.2. Toute manœuvre articulée autour d’un glissement/swipe requiert une alternative fonctionnant au pointeur unique (sans drag/drag-and-drop). Si le thème intègre un slider d’image manœuvré au doigt, assurez-vous qu’un clic/tap ou que des boutons sont là en substitution.
• 2.5.8 Taille de la cible (Minimum) (AA). Nouveau en 2.2. Les cibles du doigt tactile (boutons) nécessitent au moins 24 par 24 pixels CSS, ou devront s’entourer d’assez d’espace afin de ne pas risquer l’erreur de clic. Les petits menus embouteillés sur mobile, les steppers pour ajouter une quantité, les swatches serrés et les icônes de footer riquiqui enfreignent bien trop souvent la règle sur Shopify.
• 2.5.3 Étiquette dans le nom (A). Le nom accessible d’un raccourci d’action doit contenir le texte du libellé visible pour faire réagir le micro des utilisateurs vocalisant “Ajouter au panier”.

Compréhensible

L’internaute doit déduire aisément l’utilité des éléments d’action et, le cas échéant, retomber sur ses pattes après une bévue de manipulation.

Langue et prévisibilité

• 3.1.1 Langue de la page (A). Renseignez l’attribut lang de page (ex : <html lang="fr">) pour prémunir les lecteurs d’écran de bafouillages absurdes. Le critère 3.1.2 Langue des parties (AA) identifie la portion ponctuelle parlant une langue différente (essentiel sur les stores multilingues).
• 3.2.3 Navigation cohérente (AA) et 3.2.4 Identification cohérente (AA). Maintenez à plat l’interface de navigation, le header et les pictogrammes sans modifier leurs libellés au fil des pages de section. Rebaptiser l’icône de panier « Caddie » sur l’accueil puis « Sac » ailleurs crée une confusion.
• 3.2.6 Aide cohérente (A). Nouveau aux 2.2. Si un lien vers une page ou popover de support est offert, installez-le à une adresse cohérente quelle que soit la maquette déroulée, de manière prévisible.

Formulaires, labels et erreurs

• 3.3.2 Étiquettes ou instructions (A). Tout champ d’input demande un <label> clair. Un placeholder n’agit aucunement comme un véritable label. L’oubli cible la newsletter, la page de contact, l’input de recherche et les sélecteurs de quantité/de variantes (swatches) bien souvent. Un label resté masqué pour qui voit l’écran, mais présent aux yeux du lecteur, suffit amplement.
• 3.3.1 Identification des erreurs (A) et 3.3.3 Suggestion de correction des erreurs (AA). Quand le formulaire grince car ignoré ou corrompu, indiquez en texte brut l’erratum et soufflez comment y remédier. L’indication en couleurs seules (la case devient rouge) ne suffit plus.
• 3.3.7 Saisie redondante (A). Nouveau aux 2.2. Évitez aux visiteurs de ressaisir ce qu’ils ont déjà formulé ou configuré il y a peu. Dans le tunnel de checkout, cocher l’idée d’une « adresse de facturation similaire à celle pour la livraison » reste idoine.
• 3.3.8 Authentification accessible (Minimum) (AA). Nouveau aux 2.2. Ne figez pas la tentative de login par une exigence cognitive trop ardue (copier le texte d’un visuel). Si l’on barricade avec un CAPTCHA, offrez impérativement une pirouette de ralliement comme les mots de passe standards ou les magic links envoyés sur boîte mail.

Robuste

La charpente de balises doit offrir une lecture limpide et robuste par le biais d’un logiciel d’assistance.

• 4.1.2 Nom, rôle et valeur (A). Les éléments d’UI façonnés “custom” imposent un rôle à justifier. Pour qu’une <div> fasse le travail de bouton, un attribut role="button" s’impose, adossé aux déclics de clavier. S’il s’agit d’un accordéon : un aria-expanded. Quitte au possible à enrôler les éléments basiques natifs (<button>, <a>, <select>) plutôt que de réinventer la roue.
• 4.1.3 Messages de statut (AA). Lorsqu’un événement s’affiche furtivement en coin d’écran, du type : « Ajouté avec succès ! » mais dont l’œil perd la mire, un lecteur d’écran doit au moins murmurer la réussite, par l’entremise de balises cachées exploitant les ARIA live regions.
• Note : L’analyse 4.1.1 (Parsing) est évacuée du cadre 2.2. Ainsi un attribut id en redite accidentelle ou une imbrication un peu lâche n’échoue plus ici (mais peut encore perturber d’autres tests).

La checklist rapide

Utilisez ceci comme une vérification rapide. Chaque ligne représente un critère, son niveau, et l’endroit sur Shopify où il pose généralement problème. Les lignes marquées Nouveau dans la 2.2 sont celles à ajouter à un audit WCAG 2.1 existant.

Critère	Niveau	Où ça coince sur Shopify
1.1.1 Contenu non textuel	A	alt manquant sur les images de produits et de sections ; boutons d’icônes sans label
1.4.1 Utilisation de la couleur	A	Prix soldés ou erreurs de formulaire indiqués uniquement par la couleur
1.4.3 Contraste (minimum)	AA	Couleurs de marque sur le texte principal, les boutons, les placeholders en dessous de 4.5:1
1.4.10 Redistribution (Reflow)	AA	Scroll horizontal à 320px ; headers sticky et tableaux larges
1.4.11 Contraste non textuel	AA	Bordures d’input très claires, boutons outline, focus rings peu visibles
2.1.1 Clavier	A	Méga-menus, cart drawers (tiroirs de panier), modales quick-view inutilisables au clavier
2.4.1 Contourner des blocs	A	Lien skip-to-content manquant sur les thèmes personnalisés
2.4.7 Focus visible	AA	outline: none global qui supprime les indicateurs de focus
2.4.11 Masquage du focus (Min) Nouv. dans la 2.2	AA	Header sticky ou widget de chat recouvrant l’élément en focus
2.5.7 Mouvements de glissement Nouv. dans la 2.2	AA	Sliders uniquement drag-and-drop sans alternative au clic ou avec les flèches
2.5.8 Taille de la cible (Min) Nouv. dans la 2.2	AA	Zones de clic mobiles trop petites : steppers, swatches, icônes de footer de moins de 24px
3.1.1 Langue de la page	A	Attribut lang manquant ou erroné, très fréquent sur les thèmes modifiés
3.2.6 Aide cohérente Nouveau dans la 2.2	A	Lien de support ou de contact placé de façon incohérente entre les pages
3.3.2 Étiquettes ou instructions	A	Champs de newsletter, recherche, contact et variantes sans <label>
3.3.7 Saisie redondante Nouveau dans la 2.2	A	Resaisir les infos de livraison comme infos de facturation
3.3.8 Authentification access. (Min) Nouv. 2.2	AA	Connexion uniquement par CAPTCHA sans alternative accessible
4.1.2 Nom, rôle et valeur	A	Boutons et accordéons en <div> sans rôles ni états
4.1.3 Messages d’état	AA	« Ajouté au panier » non annoncé aux lecteurs d’écran

Les outils automatisés ne font qu’une partie du travail

Un scanner est une bonne première étape, et c’est le moyen le plus rapide de repérer les problèmes de contraste, les textes alt manquants et les labels manquants. Mais les outils automatisés ne détectent qu’environ 30 à 40 % des critères de succès des WCAG. Une machine ne peut pas juger si un texte alt est pertinent, si l’ordre de navigation au clavier est logique, ou si un lecteur d’écran peut réellement finaliser un checkout.

Un vrai audit comporte donc deux étapes :

1. Scan automatisé. Lancez un outil gratuit comme axe DevTools, WAVE ou Lighthouse sur vos templates clés (accueil, collection, produit, panier et une page de contenu).
2. Vérifications manuelles. Naviguez sur tout le parcours, de la page produit à la fin du checkout, en utilisant uniquement le clavier (Tab, Maj+Tab, Entrée). Puis répétez l’opération avec un lecteur d’écran (VoiceOver sur Mac, l’outil gratuit NVDA sur Windows). Enfin, zoomez à 200 % et passez en reflow à 320px pour confirmer que rien ne se coupe ou ne se chevauche.

Pour un aperçu des erreurs les plus fréquentes et comment les corriger, consultez notre guide sur la résolution des problèmes d’accessibilité courants sur Shopify.

Corriger ce que vous trouvez, de la bonne manière

Chaque réparation viable débouche inévitablement sur une retouche directe de votre propre architecture de thème. Ce détail exclut les extensions de pansement rapide. Une surcouche externe (overlay) ne peut pas corriger durablement les ratés d’un lecteur au cœur des balises alt, étalonner correctement l’ordre des focus au clavier ou rendre un menu opérable sans mal à la volée. C’est un rafistolage calqué au-dessus de portions HTML qui continuent d’échouer. Ce n’est pas pour rien que les entreprises se font poursuivre en justice et que les autorités pénalisent les promesses sans lendemain des overlays. Nous couvrons ce sujet précis sur l’échec des overlays d’accessibilité, et l’angle de base pour la plateforme dans Shopify est-il conforme à l’ADA ?

Les correctifs concrets se logent au niveau des dossiers Liquid, CSS et JavaScript :

• Fournir de vrais alt significatifs ou des vides alt="" quand c’est trivial.
• Donner un nom à l’intégralité des boutons illustrés sans légende.
• Associer rigoureusement les labels <label> en dur aux entrées requises.
• Sublimer les taux de contraste vers de vrais ratios 4.5:1 et 3:1.
• Restaurer le repérage de prise de visée focus clavier.
• Élargir les pastilles interactives vers 24px de seuil minimum et ajouter des interfaces fonctionnant sans glissement.
• Placer la bonne langue depuis le paramètre lang.

C’est très exactement ici qu’un éditeur dopé à l’IA gagne de la hauteur. Fudge décode la trame en temps réel, remonte et diagnostique les nœuds fatals, pour finalement en souder la parade depuis la moelle (Liquid, CSS, JavaScript) et pérenniser la correctrice mise à jour dans ce même thème. Le travail de rustine cède la place à un vrai remaniement structurel comparable à un chirurgien, n’encombrant pas la vitrine par de vastes appels externes lourdement figeant la vitesse page. Il marche en synergie vers une optimisation comme ajouter des données structurées avec de larges efforts sur l’édition de boutique.

Le modèle prôné, et autour duquel nous avons dessiné la mécanique de Fudge, se fait ainsi en trois étagements : détecter ce qui doit être corrigé, le corriger à la source native et surveiller par la suite afin qu’un éditeur futur égaré n’importune un paramètre. Si l’UE entre en lice, relevez que l’étape des cotes 2.2 AA embrasse également les obligations de l’Acte Européen sur l’Accessibilité (European Accessibility Act), rattaché de longue main à la référence des versions antérieures WCAG 2.1 AA.

---

FAQ

Footnotes

1. Règles pour l’accessibilité des contenus Web (WCAG) 2.2, Recommandation du W3C, devenues une Recommandation en octobre 2023, w3.org/TR/WCAG22. Valeurs de contraste issues de 1.4.3 et 1.4.11 ; taille de la cible de 2.5.8 ; redistribution de 1.4.10. ↩

2. W3C Web Accessibility Initiative, “What’s New in WCAG 2.2” : neuf nouveaux critères de succès (2.4.11, 2.4.12, 2.4.13, 2.5.7, 2.5.8, 3.2.6, 3.3.7, 3.3.8, 3.3.9) et la suppression du 4.1.1 Analyse syntaxique, w3.org/WAI/standards-guidelines/wcag/new-in-22. ↩ ↩²