Accessibilité PrestaShop : votre boutique est-elle conforme ?
En bref
Non, PrestaShop ne rend pas votre boutique automatiquement conforme à l'European Accessibility Act. PrestaShop le dit lui-même : la conformité « ne s'obtient pas en un clic », elle passe par un audit, des corrections et un suivi — à la charge du marchand. Concrètement :
- le cœur de PrestaShop et son nouveau thème Hummingbird intègrent des bases accessibles, mais le thème historique Classic (celui de la plupart des boutiques existantes) n'a pas été audité au niveau AA ;
- ce qui dépend de vous : contrastes, textes alternatifs des images produit, libellés de formulaire, navigation clavier ;
- les modules tiers (avis, pop-ups, sliders, page builders) cassent souvent l'accessibilité du thème ;
- testez à la main (clavier + lecteur d'écran) et publiez la déclaration d'accessibilité obligatoire — que PrestaShop ne génère pas.
Aucun thème, aucun module « 1 clic » ne remplace ces étapes. Voici un plan concret pour une boutique PrestaShop.
Vous vendez sur PrestaShop et vous vous demandez si le CMS « s'occupe » de l'accessibilité ? La réponse honnête : le logiciel vous donne de bonnes fondations — surtout sur ses versions récentes — mais la conformité finale dépend de votre thème, de vos modules, de vos personnalisations et de votre contenu. Et elle reste votre responsabilité légale depuis l'entrée en vigueur de l'EAA, le 28 juin 2025.
La vérité qui dérange : aucun CMS ne vous rend conforme
C'est le malentendu le plus coûteux. PrestaShop fournit un socle technique ; la conformité aux WCAG 2.1 AA (la grille imposée par la norme EN 301 549, elle-même exigée par l'EAA et reprise en France par le RGAA) se joue sur trois couches que vous contrôlez : le thème que vous utilisez, les modules que vous installez, et le contenu que vous publiez (images, textes, vidéos).
PrestaShop est explicite dans sa propre FAQ sur l'EAA : si vous vendez des produits ou services dans l'Union européenne, « cela vous concerne », et la mise en conformité passe par un audit d'accessibilité, l'intégration de correctifs et un suivi régulier — jamais par une simple mise à jour automatique. Autrement dit : PrestaShop vous évite de partir de zéro, mais le dernier kilomètre — celui qui est contrôlé en cas de litige — vous appartient.
Thèmes : Classic n'est pas Hummingbird (et ça change tout)
PrestaShop a fait de l'accessibilité une exigence stricte pour ses nouveaux thèmes, pas une option : sa documentation développeur l'écrit noir sur blanc (« Accessibility is a hard requirement for new PrestaShop themes, not an optional enhancement ») et aligne ses recommandations sur les WCAG. Mais tout dépend du thème que fait tourner votre boutique.
Le thème Hummingbird (récent)
- C'est le thème conçu avec l'accessibilité en tête : la doc PrestaShop lui consacre une section dédiée (gestion du focus, états d'interface, structure sémantique).
- Il applique les fondamentaux exigés par la doc : HTML sémantique et hiérarchie de titres, « tous les éléments interactifs doivent être atteignables et utilisables sans souris », libellés de formulaire, indicateur de focus visible, contraste minimal de 4,5:1 (texte normal) et 3:1 (grand texte).
Le thème Classic (historique)
- C'est le thème par défaut de la majorité des boutiques PrestaShop déjà en ligne. Il est antérieur à ces exigences : son cœur respecte une partie des critères, mais il n'a pas été audité au niveau AA et demande des ajustements HTML/CSS/JS réels pour l'atteindre.
- Conséquence directe : le travail d'accessibilité récent de PrestaShop ne « retombe » pas sur votre boutique tant que vous êtes sur Classic (ou sur un thème premium fortement personnalisé). Changer de thème n'est pas obligatoire, mais l'existant doit être corrigé.
Les modules : la première cause de non-conformité « surprise »
La force de PrestaShop — son immense catalogue de modules — est aussi son principal risque d'accessibilité. Un module s'injecte dans vos pages et peut y introduire des pièges au clavier, des éléments non étiquetés ou des contrastes insuffisants, sans que vous touchiez au thème :
- Sliders, pop-ups et bannières (promotions, newsletter, cookies) : fréquemment non navigables au clavier, ou impossibles à fermer sans souris.
- Avis clients, roues de réduction, chats : widgets tiers rarement testés à l'accessibilité.
- Page builders et modules d'affichage : génèrent souvent un balisage peu sémantique par défaut.
Ce qui se teste à la main (indépendamment du thème)
Certains critères ne se « cochent » pas via un réglage : ils se vérifient en utilisant réellement la boutique. Les voici, du plus rentable au plus fin :
| À vérifier | Comment | Critère WCAG |
|---|---|---|
| Parcours complet au clavier (accueil → produit → panier → paiement) | Rangez la souris, naviguez en Tab / Entrée | 2.1.1 |
| Focus toujours visible | Le contour suit-il votre navigation ? | 2.4.7 |
| Images produit avec alternative textuelle | Champ alt renseigné dans la fiche produit | 1.1.1 |
| Contrastes (texte, boutons, prix, badges promo) | Outil de mesure de contraste | 1.4.3 · 1.4.11 |
| Champs de formulaire étiquetés + erreurs explicites | Testez une commande avec une erreur volontaire | 3.3.1 · 3.3.2 |
| Messages dynamiques annoncés (ajout panier, code promo) | Test au lecteur d'écran (VoiceOver / NVDA) | 4.1.3 |
Pour le détail point par point, notre checklist de conformité EAA en 24 points reprend chaque vérification par étape du parcours d'achat.
Par où commencer : le plan d'action PrestaShop
- Mesurez l'existant. Un scan automatisé détecte en quelques secondes 30 à 50 % des problèmes (contrastes,
altmanquants, libellés, structure) et vous donne les éléments exacts à corriger — un point de départ chiffré plutôt qu'une page blanche. - Identifiez votre thème. Sur Hummingbird, vous partez d'un meilleur socle ; sur Classic ou un thème premium personnalisé, prévoyez des corrections HTML/CSS. Inutile de tout refaire : corrigez plutôt que de migrer par réflexe.
- Corrigez les quick wins. Contrastes de la palette de marque, alternatives textuelles des images produit, libellés de champs : fort impact, faible coût.
- Auditez vos modules. Désactivez temporairement pop-ups, sliders et widgets, re-testez le parcours : vous verrez vite lesquels cassent l'accessibilité.
- Testez à la main au clavier puis au lecteur d'écran, au moins sur le tunnel de commande — la partie la plus sensible juridiquement.
- Publiez la déclaration d'accessibilité. Obligatoire, vite réalisée, et c'est le manquement le plus simple à constater (voir ci-dessous).
L'étape que PrestaShop ne fait pas pour vous : la déclaration
Ni le cœur de PrestaShop, ni Hummingbird, ni un module ne génèrent la déclaration d'accessibilité que la loi exige. Or c'est l'obligation la plus facile à contrôler — un agent regarde simplement si elle existe — et son absence est sanctionnable : jusqu'à 25 000 € en France, et le cadre s'applique partout dans l'UE (jusqu'à 100 000 € en Allemagne, par exemple). La déclaration doit indiquer l'état de conformité réel (totalement / partiellement / non conforme), lister les non-conformités connues et donner les voies de recours.
C'est exactement ce que DeclareAccess produit : à partir d'un audit, vous obtenez le document au modèle légal — français (RGAA) ou allemand (BFSG) — prêt à publier en pied de page de votre boutique.
Auditez votre boutique PrestaShop
DeclareAccess analyse une page de votre site selon les WCAG 2.1 AA, vous renvoie un rapport chiffré des non-conformités (avec les éléments concernés), puis génère la déclaration d'accessibilité prête à publier. Audit gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre demande d'audit est enregistrée — vous recevrez votre rapport WCAG par e-mail sous 24 h ouvrées.
Questions fréquentes
PrestaShop est-il conforme à l'EAA « par défaut » ?
Non. PrestaShop fournit des bases accessibles — surtout sur ses versions récentes et son thème Hummingbird — mais indique lui-même que la mise en conformité passe par un audit, des corrections et un suivi, jamais par une simple mise à jour. La conformité de votre boutique relève de votre responsabilité, car vous contrôlez le thème, les modules et le contenu.
Le thème Classic est-il accessible ?
Partiellement seulement. Classic est le thème historique de la plupart des boutiques en ligne ; il est antérieur aux exigences d'accessibilité récentes de PrestaShop et n'a pas été audité au niveau WCAG AA. Il demande des ajustements HTML/CSS/JS pour l'atteindre. Le thème Hummingbird, plus récent, part d'un bien meilleur socle, mais aucun thème seul ne suffit sans un contenu et des modules corrigés.
Un module « accessibilité 1 clic » de l'Addons Marketplace suffit-il ?
Non. Ces overlays (accessiBe, STK Accessibility et similaires) ajoutent une surcouche JavaScript qui traite la présentation, sans corriger les problèmes structurels du thème et des modules, et ne produisent pas la déclaration d'accessibilité exigée. Ils sont largement jugés insuffisants et ont valu une amende de 1 M$ à accessiBe (FTC, 2025) pour allégations trompeuses. Ils peuvent même dégrader l'expérience au lecteur d'écran.
Dois-je migrer vers Hummingbird pour être conforme ?
Pas nécessairement. Hummingbird facilite la conformité en fournissant un meilleur socle, mais une boutique Classic peut aussi être mise en conformité par des corrections ciblées. Migrer un thème est un chantier en soi : mesurez d'abord vos écarts réels, puis décidez entre correctif et refonte selon leur ampleur.
Quelle est la première chose à faire ?
Mesurer. Lancez un scan automatisé pour obtenir une liste chiffrée et localisée des non-conformités, puis traitez les quick wins (contrastes, alternatives textuelles, libellés de formulaire) et publiez la déclaration d'accessibilité. Vous partez ainsi de faits, pas d'impressions.