Tout est parti de notre file de support. Des marchands ont commencé à passer des scanners d'accessibilité sur leur boutique, et certains des rapports qui nous sont remontés pointaient le code de Candy Rack plutôt que leur thème : des images que nous injectons sans texte alternatif, un niveau de titre que nous sautons, des contrôles dont un scanner voit bien qu'ils n'ont pas d'étiquette. C'était mérité. En juillet, nous sommes allés regarder sérieusement nos trois surfaces de boutique, et ce que nous y avons trouvé s'est révélé plus intéressant que le rapport de scan qui nous y avait poussés.
Les marchands ne lancent pas ces scans par curiosité. La pression derrière est réelle et mesurable. Les plaignants ont déposé 3 117 plaintes pour accessibilité de sites devant les tribunaux fédéraux américains en 2025, soit 27 % de plus que les 2 452 de 2024, et les affaires d'accessibilité web sont passées de 28 % à 36 % de l'ensemble des dépôts fédéraux au titre du Title III de l'ADA. En comptant aussi les tribunaux d'État, le rapport annuel d'UsableNet chiffre le total 2025 à environ 5 100 affaires, dont près de 70 % visent l'e-commerce. Côté européen, l'Acte européen sur l'accessibilité s'applique depuis le 28 juin 2025 via les lois de transposition de chaque État membre, et le 4 juin 2026 le tribunal judiciaire de Caen a condamné Carrefour France sur le fondement de la transposition française.
Voilà l'angle mort. Le conseil habituel donné à un marchand inquiet tient en deux points : choisissez un thème bien noté, et installez un widget qui ajoute une barre d'outils d'accessibilité. Ni l'un ni l'autre n'atteint les applications tierces présentes sur la page. Votre thème affiche la page, et vos applications injectent leur propre code par-dessus, souvent sous la forme d'une fenêtre modale qui s'ouvre au-dessus de tout le reste. Un audit de thème n'ira pas regarder à l'intérieur de cette modale, une barre d'outils ne peut pas la corriger, un scanner n'attrape que la partie superficielle de ce qui cloche là-dedans, et jusqu'à récemment nous n'aurions pas pu vous dire avec certitude ce qu'il y avait dans la nôtre.
À quoi ressemble concrètement une application qui casse l'accessibilité
Ce n'est pas abstrait, et ce n'est pas surtout une affaire de texte alternatif. Neuf schémas couvrent ce que nous avons trouvé sur nos propres surfaces, plus ce que je vérifierais dans l'application de n'importe qui d'autre. La plupart correspondent à un critère WCAG précis, et quand ce n'est pas le cas, c'est signalé.
| Ce qu'il faut chercher | Où cela apparaît | Critère WCAG | Qui peut le corriger |
|---|---|---|---|
| Une modale s'ouvre sans rôle dialog, sans nom accessible, sans piège de focus, sans touche Échap | Pop-ups d'upsell, tiroirs de panier, contrôles d'âge, pop-ups newsletter | 4.1.2, 2.4.3, et 2.1.2 si le focus est piégé sans issue. La fermeture par Échap relève des pratiques de rédaction ARIA plutôt que d'un critère numéroté | Éditeur de l'application uniquement |
| Contour de focus supprimé sans rien de visible à la place | Tout contrôle mis en forme par l'application | 2.4.7 | Éditeur de l'application uniquement |
Des contrôles portent tabindex="-1" alors qu'ils sont visibles à l'écran | Champs de code promo, panneaux dépliables | 2.1.1 | Éditeur de l'application uniquement |
| Les boutons composés d'une seule icône sont annoncés comme un simple « bouton » | Croix de fermeture, sélecteurs de quantité, boutons de suppression | 4.1.2, 1.1.1 | Éditeur de l'application uniquement |
L'élément cliquable est un simple div sans rôle ni arrêt de tabulation | Vignettes de produits, cartes d'offre | 2.1.1, 4.1.2 | Éditeur de l'application uniquement |
| Le texte alternatif des images est absent, ou générique sur toutes les images | Vignettes de produits dans les offres | 1.1.1 | Éditeur de l'application uniquement |
| Le total du panier, le nombre d'articles ou la progression d'une récompense se mettent à jour en silence | Tiroirs de panier, barres de livraison offerte | 4.1.3 | Éditeur de l'application uniquement |
| Un bloc injecté saute des niveaux de titre | Tout bloc d'application ayant son propre titre | Généralement rattaché au 1.3.1 | Éditeur de l'application uniquement |
| Contraste du texte sous 4,5:1, ou sous 3:1 pour les grands textes (18 pt, ou 14 pt gras) | Toute couleur que vous avez choisie dans les réglages de l'application | 1.4.3 | Vous, dans les réglages de l'application |
Lisez la dernière colonne. Huit lignes sur neuf portent sur des choses qu'un marchand ne peut corriger à aucun prix, quel que soit le widget installé. C'est l'argument qui fait du choix d'une application une décision d'accessibilité autant qu'une décision de fonctionnalités.
Ce que nous avons trouvé dans notre propre application
Les trois surfaces que nous avons auditées selon les WCAG 2.1 et 2.2 niveau AA sont la pop-up d'upsell de la page produit, la pop-up de panier affichée sur le chemin du paiement, et le tiroir de panier. Pas un score de scanner cette fois, mais une inspection du code rendu, contrôle par contrôle.
Les résultats sont inégaux d'une manière que je soupçonne d'être typique. Le point de départ du tiroir de panier était meilleur que prévu : les contrôles de fermeture et de suppression étaient de vrais boutons, chaque image produit portait déjà un texte alternatif descriptif, et le bouton de paiement avait déjà un nom accessible. C'est dans les modales que se trouvait l'essentiel, et la même poignée de problèmes revenait sur les trois surfaces, ce qui s'est révélé être le point utile. Une répétition, c'est un correctif partagé plutôt que trois.
Les deux points les plus sérieux ne sont pas ceux que les scanners avaient signalés. Le premier était un style de focus supprimé, ce qui est pire qu'il n'y paraît : cela casse la navigation au clavier pour tous les contrôles qui en héritent, pas seulement celui pour lequel il avait été écrit. Le second était un ensemble de contrôles restés hors de l'ordre de tabulation alors qu'ils étaient visibles à l'écran, ce qui transforme discrètement une fonctionnalité qui marche en fonctionnalité réservée à la souris. Une personne qui navigue au clavier n'obtient pas une version dégradée de cette fonctionnalité. Elle n'en obtient aucune. Nous avons réparti la correction sur trois tickets, un par surface, et les avons clos fin juillet.
Pourquoi nous ne revendiquons pas la conformité
Une chose que nous n'avons pas close, délibérément. Toutes les couleurs de Candy Rack côté boutique sont modifiables par vous, et nous ne validons pas le contraste des valeurs que vous réglez. Sur la boutique auditée, chaque couleur configurée passait, mais rien n'empêche un marchand de se configurer un échec au critère 1.4.3 sans le moindre avertissement. Ajouter un contrôle de contraste dans l'interface de réglages est à notre programme. En attendant, et même après, nous n'irons pas vous dire que l'application rend votre boutique conforme.
Rien de tout cela ne rend une barre d'outils d'accessibilité inutile. Elle donne aux visiteurs des réglages sur la façon dont votre boutique s'affiche, et elle vous donne du suivi, ce qui explique qu'une d'entre elles ait sa place dans notre sélection des meilleures applications Shopify de conformité, aux côtés du consentement aux cookies, du GPSR, de la facturation et des CGV. Simplement, ce n'est pas de la correction de fond, et elle ne peut pas plus que vous aller à l'intérieur de la modale d'une autre application. La conformité est une propriété de l'ensemble de votre boutique à un instant donné, et aucun éditeur seul n'est en position de la certifier. Ce qu'un éditeur peut vous dire, c'est ce qu'il a audité, ce qu'il a changé, et ce qui reste ouvert.
Comment vérifier les applications de votre boutique
Vous pouvez faire un passage utile vous-même en une dizaine de minutes, et sans scanner. L'essentiel de ce qui compte ici est invisible pour les outils automatiques, qui repèrent bien les attributs alt manquants et les défauts de contraste, mais sont aveugles aux pièges de focus, à l'ordre de tabulation et aux annonces. Tous les rapports de scan qui ont déclenché cette histoire relevaient de la première catégorie. Aucun n'a signalé les deux problèmes qui, eux, enfermaient réellement des gens dehors.
- Écartez votre souris du clavier et laissez-la de côté.
- Parcourez votre page produit avec la touche Tab et surveillez l'indicateur de focus. S'il disparaît quelque part, arrêtez-vous : vous avez déjà trouvé le point bloquant.
- Déclenchez toutes les surfaces que vos applications contrôlent : ajout au panier, ouverture du tiroir de panier, passage au paiement, et attendez les pop-ups qui se déclenchent après un délai.
- Dans chacune, vérifiez quatre choses. Pouvez-vous y entrer avec Tab ? Le focus reste-t-il à l'intérieur au lieu de repartir sur la page derrière ? La touche Échap la ferme-t-elle ? Le focus revient-il sur l'élément que vous aviez cliqué pour l'ouvrir ?
- Manipulez chaque contrôle au clavier seul, y compris les sélecteurs de quantité, les choix de variantes, les champs de code promo et les boutons de suppression. Tout ce que vous atteignez à la souris mais pas au clavier est un échec au critère 2.1.1.
- Activez VoiceOver (Cmd+F5 sur Mac) ou NVDA et écoutez ce qui est annoncé pour le bouton de fermeture et les images produit. « Bouton » et « Produit » sont deux échecs.
- Changez une quantité et écoutez si le nouveau total est annoncé. Si la mise à jour ne reçoit jamais le focus et que rien n'est annoncé, c'est un échec au critère 4.1.3.
Tout ce que vous trouvez aux étapes 3 à 7 relève de l'éditeur de l'application. Ce qui nous amène à la dernière partie.
Quatre questions à poser à un éditeur
Posez-les avant d'installer, et considérez le flou comme une réponse.
- Avez-vous audité l'interface de votre application côté boutique selon les WCAG 2.1 ou 2.2 niveau AA, et quand ?
- Vos modales appliquent-elles la sémantique de dialogue et la gestion du focus, c'est-à-dire rôle, nom accessible, piège de focus, Échap et retour du focus ?
- Chaque fonctionnalité de votre application peut-elle être utilisée au clavier seul ?
- Et qu'est-ce qui reste ouvert ?
La quatrième question est celle qui en dit le plus. Un éditeur qui a une vraie réponse en aura une, parce que tout le monde a quelque chose d'ouvert. Mon interprétation, c'est que « nous sommes parfaitement conformes » signifie en général que personne n'a regardé, et il vaut la peine de se rappeler sur quoi portait réellement la décision de la FTC contre accessiBe : pas sur le mot conforme, mais sur une revendication de conformité que l'entreprise ne pouvait pas étayer.
En pratique, la partie que les plaignants et les régulateurs poursuivent, c'est le marchand qui exploite la boutique, pas les éditeurs qui en fournissent les morceaux. C'est inconfortable, parce qu'une bonne partie de ce qui arrive chez vos clients est du code que vous n'avez pas écrit et que vous ne pouvez pas modifier. Ce que vous contrôlez, c'est le choix de vos éditeurs et ce que vous leur demandez. Si vous comparez des applications et voulez le même regard appliqué à la conversion plutôt qu'à la conformité, notre guide de stratégie d'upsell et notre guide d'optimisation du paiement couvrent ce versant. Si vous vendez dans l'UE, le bouton de rétractation et les autres contraintes européennes dont nous avons parlé arrivent dans la même période que l'Acte européen sur l'accessibilité.
Les correctifs issus de cet audit ont été livrés fin juillet et sont en ligne dans Candy Rack, y compris dans le tiroir de panier et la barre de récompenses. Si vous trouvez quelque chose qui nous a échappé, dites-le-nous : nous le corrigerons plutôt que de discuter de sa gravité.
Cet article décrit notre propre audit et constitue une information générale, pas un conseil juridique. Pour vos obligations au titre de l'ADA, de l'Acte européen sur l'accessibilité ou des lois nationales de transposition, adressez-vous à un avocat.
