Comment les corrections d’accessibilité arrivent dans le thème d’une boutique Shopify, Shopware, WooCommerce ou Magento

Lorsque le thème est à l’origine d’un échec, la correction va dans le fichier qui produit le balisage, le style ou le texte défaillant : un fichier de template, une feuille de style, un script ou un fichier de traduction du thème de la boutique. Chaque plateforme range ces fichiers dans sa propre structure et avec son propre langage de templates ; le même échec, par exemple un bouton sans nom, peut donc se trouver dans un fichier Liquid sur Shopify, un fichier Twig sur Shopware, un fichier PHP sur WooCommerce et un fichier .phtml sur Magento.

Une correction dans le thème modifie le code que la boutique sert elle-même. Un développeur peut la lire sous forme de diff avant sa mise en ligne et l’annuler comme n’importe quelle autre modification du code. Un overlay d’accessibilité est différent : c’est un script qui modifie les pages de la boutique dans le navigateur du visiteur, alors que le thème reste tel qu’il était, à part la référence qui charge le script. Ce que les overlays modifient et ce qu’ils laissent en l’état

Une mise à jour du thème peut annuler une correction d’accessibilité lorsque la correction se trouve dans un fichier que la mise à jour remplace, ou lorsque la mise à jour ne peut pas reprendre la modification ; sur certaines plateformes, d’autres changements peuvent aussi masquer une correction. Les plateformes documentent ce point chacune à leur manière.

• WooCommerce. Selon WooCommerce, les modifications faites directement dans un plugin ou un thème parent disparaissent lorsque le plugin ou le thème se met à jour : la mise à jour supprime entièrement l’ancienne version et la remplace par une copie neuve et à jour (WooCommerce sur la structure des templates). WooCommerce recommande plutôt un thème enfant avec des surcharges de templates. Ces surcharges ne sont pas mises à jour lorsque les templates du cœur de WooCommerce le sont, et le rapport d’état du système de WooCommerce (System Status) peut afficher un avis indiquant qu’une surcharge est obsolète.
• Thèmes de blocs WordPress. Un template modifié par quelqu’un dans l’éditeur de site est enregistré dans la base de données du site et l’emporte sur les fichiers de template du thème et d’un thème enfant (Theme Handbook de WordPress sur les templates et sur la hiérarchie des templates). Une correction apportée dans le fichier d’un tel template n’est alors pas ce que voient les visiteurs.
• Magento Open Source et Adobe Commerce. Adobe recommande vivement de ne pas modifier les fichiers des thèmes Luma et Blank ni les templates par défaut, car les mises à niveau peuvent les écraser (Adobe sur les thèmes, Adobe sur les templates). L’endroit que recommande Adobe pour les modifications est un thème personnalisé, qui peut hériter de Luma ou de Blank.
• Shopware 6. Un thème qui hérite d’un thème acheté laisse inchangé le code de ce dernier, comme décrit plus haut. Shopware avertit qu’un thème qui surcharge des variables d’un thème tiers peut ne plus compiler si ce thème renomme ou supprime ces variables par la suite (Shopware sur la configuration des thèmes).
• Shopify. Le centre d’aide de Shopify sur la mise à jour des thèmes indique que les modifications de code qui n’entrent pas en conflit avec une mise à jour du thème sont reprises dans la copie mise à jour. Si elles sont incompatibles avec la mise à jour, toutes les modifications de code sont retirées de la copie mise à jour, et les conserver suppose de les recopier dans la nouvelle version. La mise à jour arrive sous forme de thème brouillon dont le nom commence par « Updated copy of ».

Les corrections de Validiscan modifient les fichiers du code source du thème qu’il reçoit. Savoir de quel code source il s’agit (le thème utilisé, son thème enfant ou un thème qui en hérite) est donc une question à poser au développeur de la boutique avant le début du travail. Lorsqu’un thème WooCommerce parvient à Validiscan sous forme de ZIP, le portail client demande le dossier du thème « y compris le thème enfant si vous en utilisez un ». La protection contre les régressions, un service distinct facturé chaque mois après un projet, scanne de nouveau la boutique chaque semaine ou chaque mois et compare chaque exécution à la référence. Lorsqu’un échec corrigé est constaté de nouveau, par exemple après une mise à jour du thème, le constat est rouvert et signalé comme une régression. Un nouveau scan ne trouve que ce que des contrôles automatisés peuvent trouver sur les pages qu’il atteint.

Validiscan prépare les corrections sur une copie du code source du thème, qu’il obtient de l’une des trois façons suivantes. Il applique les corrections dans un dossier de travail temporaire, supprimé après chaque livraison.

• Un dépôt GitHub, sur les quatre plateformes. La boutique installe l’application GitHub de Validiscan sur le dépôt, ou donne à Validiscan un jeton d’accès. Dans la configuration de Validiscan, l’application dispose d’un accès en écriture au contenu du dépôt et à ses pull requests, d’un accès en lecture à ses métadonnées, et de rien d’autre.
• Un mot de passe Theme Access, sur Shopify uniquement. L’application Theme Access de Shopify crée des mots de passe qui donnent un accès en écriture aux seuls thèmes (la portée write_themes). Pour configurer l’application, il faut le propriétaire de la boutique, ou un membre du personnel ou un collaborateur disposant de l’autorisation Thèmes. Au 6 octobre 2026, la documentation de Shopify indique que le lien vers le mot de passe expire au bout de 7 jours ou dès qu’il a été consulté, et que la suppression du mot de passe révoque l’accès.
• Un ZIP du thème, sur les quatre plateformes, pour un lot de correctifs, téléversé dans le portail client sous la forme d’un seul fichier de 100 Mo au maximum. Le portail demande le dossier du plugin de thème sous custom/plugins sur Shopware, le dossier du thème sous wp-content/themes sur WooCommerce, le dossier du thème sous app/design/frontend sur Magento, et le fichier du thème téléchargé depuis l’interface administrateur Shopify sur Shopify.

Sans aucune de ces trois voies, Validiscan n’a aucun code à modifier, et aucune correction n’est préparée.

Validiscan livre les corrections approuvées sous forme de pull request, de copie non publiée du thème Shopify ou de lot de correctifs. Le mode de livraison est défini pour chaque boutique, et non pour chaque plateforme, et le lot de correctifs est le mode par défaut. Aucun des trois ne modifie le thème publié de la boutique ni la branche par défaut du dépôt.

La liste de contrôle de relecture de la pull request de Validiscan demande au développeur de relire les corrections comme n’importe quelle autre modification du thème, et aussi d’utiliser les éléments modifiés au clavier et, si possible, avec un lecteur d’écran. Elle énumère ces étapes :

1. Lisez le diff de chaque commit.
2. Déployez la branche dans un environnement de prévisualisation ou de préproduction, et non sur la version en ligne de la boutique.
3. Ouvrez les pages concernées et vérifiez qu’elles ont le même aspect et fonctionnent comme avant.
4. Utilisez les éléments modifiés uniquement au clavier : tout doit pouvoir être atteint et le focus doit être visible.
5. Si possible, vérifiez les éléments modifiés avec un lecteur d’écran, par exemple NVDA ou VoiceOver.
6. Fusionnez lorsque le résultat vous convient. Validiscan contrôle ensuite les pages concernées par un scan de vérification.

Les documents de livraison (le texte de la pull request, PATCH.md et le README) sont rédigés en anglais ou en allemand. Les clients dont la langue est réglée sur le danois, le français ou l’espagnol reçoivent la version anglaise.

Chaque page de plateforme décrit ce que les corrections modifient sur cette plateforme et ce que le commerçant fournit : les corrections d’accessibilité pour les thèmes Shopify, pour les thèmes Shopware, pour les thèmes WooCommerce et pour les thèmes Magento.

Sur Shopify, Shopware, WooCommerce et Magento, Validiscan prépare les corrections dans le code même du thème de la boutique, pour les échecs qui se corrigent à cet endroit, et les livre de l’une des trois façons décrites plus haut. Les constats du niveau MANUAL ne donnent lieu qu’à des indications, pas à une modification du code. Une fois les modifications en ligne, un scan de vérification contrôle de nouveau les pages concernées. Le Remediation Evidence Package consigne ensuite ce qui a été testé, ce qui a été modifié et ce que le scan de vérification a relevé, avec la date de chaque scan. Il constitue la preuve d’une évaluation et de travaux de correction, pas un certificat. Le déroulement d’un projet, étape par étape