Accessibilité EAA et WCAG 2.1 AA sur PrestaShop : analyser, corriger, déclarer

Depuis le 28 juin 2025, l’European Accessibility Act (EAA) demande aux boutiques en ligne qui vendent aux consommateurs de l’Union européenne d’être utilisables par les personnes handicapées et d’informer sur leur accessibilité. La référence technique est la norme EN 301 549, qui reprend les critères WCAG 2.1 niveau AA.

Audit accessibilité EAA & WCAG 2.1 AA (EAA Accessibility Checker) mène cette démarche dans le back-office de PrestaShop, en quatre étapes : analyser les pages de la boutique, corriger les problèmes trouvés, vérifier les critères qui demandent un regard humain et publier la déclaration d’accessibilité dans chaque langue. Ce guide explique comment l’installer, réussir une première analyse et l’utiliser au quotidien.

Points forts :

• Une analyse des pages réelles dans le navigateur avec axe-core, contrastes compris, et une analyse par le serveur pour les analyses programmées
• Un score honnête : un critère n’est compté comme respecté qu’après votre vérification, sans problème ouvert
• Des problèmes expliqués, regroupés par élément, avec la façon de les corriger dans PrestaShop
• Six corrections automatiques sûres, activables une par une
• Une déclaration d’accessibilité sur le modèle européen, préremplie pour six pays, publiée dans chaque langue

Découvrir le module et ses formules

---

Présentation

Aucun outil ne peut déclarer seul une boutique accessible : une partie des critères WCAG dépend du contenu et de l’usage (pertinence d’un texte alternatif, sous-titres, ordre de lecture). Le module combine donc des contrôles automatiques, une checklist manuelle des 50 critères WCAG 2.1 A et AA (et des 6 critères de WCAG 2.2 en option) et une déclaration qui reflète la réalité de votre boutique.

Il s’adresse aux marchands PrestaShop qui veulent savoir où en est leur boutique, savoir quoi corriger et par où commencer, et garder la trace de leur démarche pour leurs clients, leur agence ou un contrôle. Le module ne remplace pas un conseil juridique ; les textes préremplis de la déclaration sont un point de départ à adapter.

Votre démarche en quatre étapes, avec un score honnête

Fonctionnalités

Analyser les pages comme vos clients les voient

L’écran 1. Analyser propose des pages représentatives de chaque modèle de votre boutique : accueil, catégories, produits avec et sans déclinaisons, page CMS, marque, résultats de recherche, contact, connexion, création de compte et panier. La première langue cochée reçoit tous les types de pages ; les autres langues reçoivent l’accueil, une catégorie et un produit. Vous pouvez ajouter toute autre adresse de votre boutique (une page d’atterrissage, la page d’un module).

Deux modes d’analyse :

• Dans votre navigateur (recommandé) : chaque page est ouverte de façon invisible dans votre fenêtre et contrôlée par axe-core, tel que vos visiteurs la voient. C’est le seul mode qui mesure les contrastes, les attributs ARIA, les contenus ajoutés par les scripts et l’effet des corrections. Gardez la page ouverte pendant l’analyse : une quinzaine de pages prennent environ une minute.
• Par le serveur : le serveur lit le HTML des pages et contrôle les règles du module (images, étiquettes, noms des boutons et liens, titres, langues, formulaires). C’est le mode des analyses programmées ; il ne mesure pas les contrastes.

Une analyse des pages réelles, dans le navigateur

Une page qui ne peut pas être analysée (par exemple une page de connexion remplacée par un autre module, qui redirige vers sa propre page) est signalée comme non analysée, avec la raison, sans fausser les résultats.

Suivre la démarche sur le tableau de bord

La vue d’ensemble affiche le nombre de critères WCAG 2.1 AA respectés, les problèmes à corriger par gravité (grave, modéré, mineur), la dernière analyse et son évolution, puis les quatre étapes avec leur état : Analyser, Corriger, Vérifier, Publier. Un critère est compté comme respecté lorsque vous l’avez vérifié dans la checklist et qu’aucun problème ouvert de l’analyse ne le contredit.

Corriger les problèmes trouvés

L’écran 2. Corriger liste les problèmes ouverts, regroupés par élément : un même défaut répété sur des dizaines de pages n’apparaît qu’une fois, avec le nombre de pages concernées. Filtrez par statut, gravité, endroit où corriger (thème, contenus, images du catalogue, module) et critère WCAG.

Les problèmes à corriger, regroupés par élément

Chaque problème a sa fiche : pourquoi c’est important, comment le corriger dans PrestaShop, le critère WCAG concerné, l’élément et son extrait HTML, et les pages où il apparaît, avec un lien vers l’écran du back-office à modifier quand il existe (fiche produit, page CMS, images du catalogue).

Pourquoi c’est important, et comment le corriger

Pour chaque problème, choisissez une décision :

• Corrigé, à confirmer par la prochaine analyse : il redevient ouvert si l’analyse suivante le trouve encore.
• Limite connue : il compte toujours contre ses critères et il est proposé dans les contenus non accessibles de la déclaration.
• Faux positif : il ne compte plus.

Les décisions sont conservées d’une analyse à l’autre. Une action groupée permet de traiter plusieurs problèmes affichés.

Activer les corrections automatiques sûres

Dans Réglages, six corrections de la boutique s’activent séparément :

• Lien d’évitement : un lien « Aller au contenu principal », affiché quand le clavier l’atteint, seulement si le thème n’en a pas déjà un.
• Noms des boutons et liens : un nom pour les boutons et liens réduits à une icône (panier, recherche, menu, fermer, quantité, réseaux sociaux), d’après leur titre, leur icône ou leur rôle dans le thème.
• Icônes décoratives : les polices d’icônes et les SVG décoratifs sont masqués aux lecteurs d’écran quand la commande a déjà un nom.
• Étiquettes des formulaires : un nom pour les champs qui n’ont qu’un texte indicatif (recherche, newsletter) et la réparation des étiquettes qui désignent un champ par son nom au lieu de son identifiant.
• Saisie automatique : la finalité des champs des formulaires de compte et d’adresse (e-mail, nom, adresse, téléphone) est déclarée, pour que les navigateurs les remplissent.
• Focus visible : un anneau net autour de l’élément atteint au clavier, sur tous les fonds.

Des corrections sûres, activées une par une

Chaque correction ajoute seulement une information manquante et ne retire jamais ce que votre thème déclare. Leur effet est mesuré par l’analyse suivante dans le navigateur. Elles ne remplacent pas une correction du thème. Sur la vue d’ensemble, le bouton Activer les corrections recommandées active les cinq premières en une fois ; le focus visible, qui change l’apparence du focus de votre thème, s’active à part.

Renseigner les légendes des images

L’écran Légendes des images affiche, pour chaque langue, le taux d’images de produits légendées, puis les images page par page, même sur un grand catalogue. Filtrez par langue, par état (sans légende, avec légende, toutes) et par nom ou référence de produit. Le bouton Utiliser le nom du produit pour les légendes vides de cette page propose une première légende ; chaque légende est enregistrée dès que vous la saisissez.

Les légendes d’images manquantes, en quelques minutes

Un bon texte alternatif décrit ce que montre l’image (couleur, angle, détail) en quelques mots, plutôt que de répéter le nom du produit.

Vérifier les critères avec la checklist

L’écran 3. Vérifier présente les 50 critères WCAG 2.1 A et AA exigés par EN 301 549, regroupés par principe (perceptible, utilisable, compréhensible, robuste), et les 6 critères de WCAG 2.2 marqués « recommandé ». Pour chaque critère :

• ce qu’il demande et un conseil concret pour PrestaShop ;
• ce que l’analyse en contrôle (entièrement, en partie ou pas du tout) ;
• votre verdict : respecté, non respecté ou non applicable ;
• une note (ce que vous avez vérifié, ce qui reste), avec l’auteur et la date.

Chaque critère WCAG, avec un conseil pour PrestaShop

Un critère reste « non respecté » tant que l’analyse trouve un problème ouvert pour lui. Les filtres par état, niveau et version aident à avancer par lots.

Publier la déclaration d’accessibilité

L’écran 4. Publier prépare la déclaration sur le modèle européen (directive (UE) 2019/882, EN 301 549) :

• Pays de référence : la loi nationale et l’autorité de contrôle sont préremplies pour la France, la Belgique, l’Espagne, l’Italie, la Pologne et l’Allemagne, et restent modifiables ; les autres pays utilisent le modèle européen.
• État de conformité : totalement, partiellement ou non conforme, avec la suggestion tirée de votre checklist.
• Contact : e-mail, téléphone facultatif, lien vers le formulaire de contact et délai de réponse.
• Textes par langue : mesures prises, contenus non accessibles et leurs alternatives (le bouton Insérer les critères non respectés reprend votre checklist), description du service et voies de recours.

Une déclaration préremplie pour votre pays

Activez Publier la déclaration sur la boutique : la page est disponible dans chaque langue, à une adresse lisible, avec un lien dans le pied de page de chaque page si vous l’activez. Tant qu’elle n’est pas publiée, l’adresse répond « page introuvable » et vous pouvez la prévisualiser dans le back-office.

La déclaration publiée, dans chaque langue

Programmer les analyses et recevoir le rapport

Dans Réglages, activez Analyser la boutique automatiquement, choisissez la fréquence (chaque jour, chaque semaine, chaque mois), le jour et l’heure, puis les destinataires du rapport par e-mail. Le rapport indique les problèmes ouverts, nouveaux et résolus depuis l’analyse précédente.

Des analyses programmées et un rapport par e-mail

Les analyses démarrent quand l’hébergeur exécute l’une des deux tâches affichées dans les réglages, toutes les heures (recommandé) ou chaque jour :

• la commande à confier à la tâche cron de l’hébergeur ;
• ou l’adresse avec un secret, compatible avec le module « Gestionnaire de tâches cron » de PrestaShop. Un bouton permet de créer un nouveau secret.

Exporter le rapport

L’écran Rapport ouvre un rapport imprimable daté (analyses, critères et problèmes), à enregistrer en PDF avec la commande d’impression du navigateur, et exporte les problèmes ou la checklist au format CSV (lisible par un tableur).

---

Installation

1. Téléchargez l’archive du module depuis votre espace client WePresta.
2. Dans le back-office, ouvrez Modules > Gestionnaire de modules et cliquez sur Installer un module.
3. Envoyez le fichier ZIP.
4. Cliquez sur Configurer pour activer votre licence, puis ouvrez le module depuis le bouton de la page ou le menu WePresta > Accessibilité (EAA) (Modules > Accessibilité (EAA) quand la boutique n’a pas le menu WePresta).

L’installation crée les tables du module, l’adresse lisible de la déclaration et l’entrée de menu. Aucune page de la boutique n’est modifiée tant que vous n’activez pas une correction ni le lien de pied de page.

Première analyse

1. Ouvrez 1. Analyser, laissez Dans votre navigateur et les pages proposées cochées.
2. Cliquez sur Lancer l’analyse et gardez la page ouverte : chaque page affiche son nombre de problèmes.
3. Ouvrez 2. Corriger : commencez par les problèmes graves présents sur beaucoup de pages, souvent liés au thème.
4. Activez les corrections recommandées dans Réglages, puis relancez une analyse pour mesurer leur effet.
5. Avancez dans 3. Vérifier, puis préparez et publiez votre déclaration dans 4. Publier.

Boutique protégée par un mot de passe (préproduction) : renseignez ses identifiants HTTP dans les réglages pour les analyses par le serveur et les analyses programmées.

Prérequis et compatibilité

• PrestaShop 1.7.8, 8.0+ et 9.0+
• PHP 7.4 ou plus, extension DOM
• Une tâche cron (ou le module « Gestionnaire de tâches cron ») pour les analyses programmées
• Boutique simple ou multiboutique : chaque boutique a ses analyses, sa checklist et sa déclaration
• Interface en français, anglais, espagnol, italien et polonais

Sur la boutique, axe-core n’est chargé que sur les pages ouvertes par une analyse ; seules les corrections que vous activez ajoutent un script d’environ 5 Ko compressé.

---

FAQ

L’EAA, c’est quoi exactement et pourquoi votre boutique est concernée ?

L’European Accessibility Act (directive (UE) 2019/882) s’applique depuis le 28 juin 2025 à de nombreux services numériques, dont le commerce en ligne destiné aux consommateurs de l’Union européenne. Votre boutique doit pouvoir être utilisée par les personnes handicapées et informer sur son accessibilité. La référence technique est la norme EN 301 549, qui reprend les critères WCAG 2.1 niveau AA ; les microentreprises qui fournissent des services en sont exemptées. Le module vous aide à mesurer, corriger, vérifier et documenter cette démarche ; il ne remplace pas un conseil juridique.

WCAG 2.1 AA : ça veut dire quoi, concrètement, pour un e-commerce ?

Les WCAG 2.1 rassemblent 50 critères de niveaux A et AA : textes alternatifs des images, contrastes, navigation au clavier, formulaires compréhensibles, titres et structure, langue des pages, etc. Pour une boutique, les pages critiques sont l’accueil, les listes de produits, la fiche produit, le panier, la commande et le compte client. Le module analyse ces modèles de pages dans chaque langue et propose, pour chaque critère, une vérification adaptée à PrestaShop.

Que détecte le scanner d’accessibilité et comment sont priorisés les problèmes ?

L’analyse dans le navigateur s’appuie sur axe-core : elle contrôle plusieurs dizaines de règles WCAG A et AA sur la page telle qu’elle s’affiche, contrastes compris. L’analyse par le serveur, utilisée par les analyses programmées, vérifie le HTML avec les règles du module (images, étiquettes, noms des boutons et liens, titres, langues, formulaires). Les problèmes sont classés par gravité (grave, modéré, mineur), regroupés par élément et rattachés à l’endroit où les corriger : thème, contenus, images du catalogue ou module.

L’Auto-Fix : quelles corrections sont faites automatiquement ?

Six corrections, chacune activable séparément : le lien « Aller au contenu principal » (seulement si votre thème n’en a pas), un nom pour les boutons et liens à icône, le masquage des icônes décoratives pour les lecteurs d’écran, des étiquettes pour les champs qui n’ont qu’un texte indicatif (recherche, newsletter), la saisie automatique sur les formulaires de compte et d’adresse, et un focus visible sur tous les fonds. Elles ajoutent une information manquante sans retirer ce que déclare votre thème, et l’analyse suivante dans le navigateur mesure leur effet.

Est-ce que l’Auto-Fix suffit pour être conforme à 100 % ?

Non, et aucun outil ne le peut. Les corrections automatiques traitent des défauts techniques courants, mais beaucoup de critères dépendent du contenu et de l’usage : textes alternatifs pertinents, sous-titres des vidéos, ordre de lecture, messages d’erreur compréhensibles. Une démarche efficace consiste à : (1) analyser, (2) corriger le thème et les contenus, en vous aidant des corrections sûres, (3) vérifier les critères manuels dans la checklist, (4) publier une déclaration qui reflète la réalité.

Comment gérer les textes alternatifs (ALT) à grande échelle, sans y passer des semaines ?

L’éditeur des légendes affiche les images de vos produits page par page, ce qui reste rapide sur un grand catalogue. Filtrez par langue, par produit ou référence et par images sans légende ; un bouton propose le nom du produit pour toutes les légendes vides de la page, et chaque légende est enregistrée dès que vous la saisissez. Pour un bon texte alternatif, décrivez ce que montre l’image (couleur, angle, détail) plutôt que de répéter le nom du produit.

Pourquoi une checklist manuelle est indispensable, même avec un scanner automatique ?

Une machine ne peut pas juger la pertinence d’un texte alternatif, la présence de sous-titres, l’ordre du focus ou la clarté d’un message d’erreur. La checklist couvre les 50 critères WCAG 2.1 A et AA et, en option recommandée, les 6 critères de WCAG 2.2, regroupés par principe. Pour chaque critère : un conseil concret pour PrestaShop, votre verdict (respecté, non respecté, non applicable), vos notes, l’auteur et la date. Un critère reste « non respecté » tant que l’analyse trouve un problème ouvert pour lui.

À quoi sert la déclaration d’accessibilité et comment est-elle générée ?

Elle informe vos clients du niveau d’accessibilité de votre service, des contenus non accessibles et de leurs alternatives, et de la façon de vous contacter ou de faire valoir leurs droits. Le module la prépare sur le modèle européen, avec le texte national et l’autorité de contrôle préremplis pour la France, la Belgique, l’Espagne, l’Italie, la Pologne et l’Allemagne (modifiables, ou un modèle européen pour les autres pays). Vous choisissez l’état de conformité, rédigez les textes dans chaque langue et publiez une page dédiée, avec un lien en pied de page si vous le souhaitez.

Peut-on automatiser les scans (CRON) et recevoir des alertes en cas de régression ?

Oui. Choisissez une fréquence (quotidienne, hebdomadaire ou mensuelle), un jour et une heure : la tâche cron de votre hébergeur, ou le module « Gestionnaire de tâches cron » avec l’adresse à secret affichée dans les réglages, lance l’analyse dès que le moment prévu est passé. Le rapport par e-mail indique les problèmes ouverts, nouveaux et résolus depuis l’analyse précédente.

Performance et prérequis : est-ce que ça ralentit le front-office ? quelles conditions techniques ?

Les analyses partent du back-office : axe-core n’est chargé que sur les pages ouvertes par une analyse. Sur la boutique, seules les corrections que vous activez ajoutent un script d’environ 5 Ko compressé et une petite feuille de style. Prérequis : PrestaShop 1.7.8, 8.0+ ou 9.0+, PHP 7.4 ou plus et l’extension DOM ; un accès cron est utile pour les analyses programmées.

Pourquoi analyser dans le navigateur plutôt que sur le serveur ?

Le navigateur voit la page comme vos clients : styles appliqués, contenus ajoutés par JavaScript, couleurs réelles. C’est la seule façon de mesurer les contrastes et l’effet des corrections automatiques. L’analyse par le serveur reste utile pour les analyses programmées ; pour une boutique protégée par un mot de passe (préproduction), renseignez ses identifiants HTTP dans les réglages.

Le module fonctionne-t-il en multiboutique et sur PrestaShop 1.7 ?

Oui. Chaque boutique a ses analyses, sa checklist et sa déclaration ; quand plusieurs boutiques sont sélectionnées, le module vous demande d’en choisir une. Le même module fonctionne sur PrestaShop 1.7.8, 8.0+ et 9.0+ avec PHP 7.4 minimum.

Que se passe-t-il si j’utilisais déjà la version 1 du module ?

La mise à jour reprend votre checklist, le contact de votre déclaration et vos réglages d’analyse programmée. Les anciens résultats d’analyse sont remplacés par ceux de la nouvelle analyse. Relisez ensuite votre déclaration et publiez-la de nouveau depuis l’écran Publier : elle n’est pas remise en ligne automatiquement.

---

Support

Pour toute aide, contactez-nous depuis votre espace client WePresta ou par e-mail à mail@wepresta.shop, selon l’option de support de votre formule.

Avant de nous écrire, préparez :

• les versions de PrestaShop et de PHP
• le thème utilisé
• l’adresse de la page concernée et une capture de la fiche du problème

---

Changelog

Version 2.0.0

Nouveautés

• Analysez vos pages dans le navigateur avec axe-core : contrastes calculés, attributs ARIA et contenus ajoutés par les scripts.
• Suivez votre démarche en quatre étapes : Analyser, Corriger, Vérifier, Publier.
• Retrouvez chaque problème regroupé par élément, avec la façon de le corriger dans PrestaShop et un lien vers l’écran à modifier.
• Marquez un faux positif ou une limite connue : votre décision est conservée aux analyses suivantes.
• Vérifiez les 50 critères WCAG 2.1 A et AA et, en option, les 6 critères de WCAG 2.2, avec un conseil pour chaque critère.
• Publiez une déclaration d’accessibilité sur le modèle européen, avec la loi et l’autorité préremplies pour six pays.
• Ajoutez le lien de la déclaration en pied de page de la boutique.
• Exportez un rapport imprimable, ainsi que les problèmes ou la checklist au format CSV.
• Lancez les analyses programmées par la tâche cron de votre hébergeur ou par une adresse à secret.
• Utilisez le module sur PrestaShop 1.7.8, 8.0+ et 9.0+ avec PHP 7.4 minimum.

Améliorations

• Un critère n’est compté comme respecté qu’après votre vérification, sans problème ouvert.
• Les pages analysées représentent chaque modèle de votre boutique, dans chaque langue.
• L’analyse par le serveur vérifie davantage de règles : titres, langues, formulaires, saisie automatique, zoom.
• Chaque correction automatique s’active séparément et son effet est mesuré par l’analyse suivante.
• L’éditeur des légendes reste rapide sur un grand catalogue et enregistre chaque légende dès sa saisie.
• Le rapport par e-mail indique les problèmes nouveaux et résolus.
• Le module est accessible depuis le menu WePresta, avec une interface en cinq langues.
• Une adresse ajoutée à la main est limitée aux domaines de votre boutique.

Corrections

• La page publique de la déclaration affiche bien son contenu.
• Les analyses programmées s’exécutent de nouveau.
• Ignorer un problème ne le compte plus comme corrigé.
• Les images sans texte alternatif ne reçoivent plus le texte « Image ».
• Le lien d’évitement est placé au début de la page, sans doublon avec celui du thème.
• Ouvrir le module ne vide plus le cache de la boutique.
• Les droits des profils d’employés sont respectés sur PrestaShop 8.

Après la mise à jour : votre checklist, le contact de la déclaration et vos réglages d’analyse programmée sont repris ; relisez votre déclaration puis publiez-la de nouveau depuis l’écran Publier.

Version 1.0.0

• Lancement initial
• Scan WCAG 2.1 AA
• Auto-Fix intégré
• Éditeur de textes alternatifs
• Déclaration d’accessibilité multilingue

Découvrir le module et ses formules