Accessibilité des boutiques en ligne : ce que l’European Accessibility Act change pour vous

Dernière mise à jour : juin 2026. L’EAA s’applique depuis le 28 juin 2025 et est mis en œuvre par des transpositions nationales (le BFSG en Allemagne et des équivalents ailleurs), qui peuvent varier dans leurs détails et leurs seuils ; les chiffres indiqués ici correspondent aux bases publiées par l’UE, pas à une décision applicable à votre situation. Les pistes techniques concernent PrestaShop 1.7, 8 et 9 avec le thème Classic. Ceci n’est pas un avis juridique, vérifiez votre périmètre, votre éventuel statut d’exemption et vos obligations nationales avec un avocat dans votre pays, et gardez à l’esprit qu’aucun module ni aucun thème ne rend une boutique « conforme » à lui seul.

Voici le point que beaucoup de marchands PrestaShop n’ont retenu qu’à moitié : depuis le 28 juin 2025, l’European Accessibility Act (EAA) fait de l’accessibilité web une obligation légale pour la plupart des boutiques en ligne qui vendent à des consommateurs de l’UE, ce n’est plus une option sympathique, ni un problème à repousser à 2030. L’application se fait au niveau des États membres (BFSG en Allemagne, directive transposée dans chaque pays), et l’obligation repose sur le vendeur, pas sur PrestaShop ni sur l’éditeur de votre thème. Si votre tunnel de commande ne peut pas être terminé au clavier, c’est désormais un écart de conformité qui vous concerne directement.

Ce guide explique précisément ce que l’EAA implique pour une boutique PrestaShop et comment corriger les lacunes dans le logiciel que vous utilisez réellement, le thème, l’interface d’administration, les modules. C’est le volet accessibilité de notre ensemble de contenus sur la conformité : lorsqu’un sujet relève d’un article voisin (bannières de cookies, RGPD, conditions générales), nous vous orienterons en une ligne au lieu de tout répéter. Pour une vue juridique plus large de la vente dans l’UE, commencez par le droit de l’e-commerce dans l’UE.

Qui est réellement concerné par l’EAA (et qui est exempté)

Avant de passer votre week-end sur les textes alternatifs, vérifiez si la loi s’applique pleinement à vous, car la réponse change ce que vous devez faire.

• Vous vendez en B2C à des consommateurs de l’UE : vous entrez dans le champ d’application. Les « services de commerce électronique » sont explicitement mentionnés dans l’acte.
• Vous êtes une microentreprise qui vend des services : moins de 10 salariés et un chiffre d’affaires annuel ou un total de bilan inférieur à 2 M€, les prestataires de services de cette taille sont exemptés des obligations relatives aux services. C’est l’exception dont relèvent beaucoup de petites boutiques, mais lisez le point suivant avant de souffler.
• Vous vendez des produits (la liste de produits réglementés par l’EAA, liseuses, matériel, terminaux) : l’exemption des microentreprises pour les services ne couvre pas les produits. La plupart des boutiques de vêtements, cosmétiques ou articles pour la maison ne vendent pas de produits réglementés, donc ce n’est pas souvent le piège, mais vérifiez au lieu de supposer.
• B2B pur : en général, vous êtes hors du périmètre destiné aux consommateurs, même si l’accessibilité reste une bonne pratique et peut être exigée par contrat par de grands acheteurs.

Et alors ? Une boutique polonaise de deux personnes sous le seuil de chiffre d’affaires est probablement à l’abri de la contrainte juridique directe, mais l’accessibilité élargit quand même son marché et soutient son SEO, donc le travail reste rentable. Une boutique en croissance perd l’exemption dès qu’elle ne remplit plus les critères de microentreprise selon les règles nationales applicables. Considérez le seuil comme une échéance vers laquelle vous avancez, pas comme un bouclier permanent. Ce guide ne donne volontairement pas d’avis juridique sur votre statut précis, confirmez-le avec un avocat dans votre pays ; les chiffres indiqués ici sont les seuils publiés par l’UE, pas une décision sur votre cas.

La norme derrière la loi : WCAG 2.1 AA, en clair

L’EAA lui-même ne liste pas des ratios au pixel près. Il renvoie à la norme harmonisée EN 301 549, qui adopte à son tour WCAG 2.1 niveau AA comme référence web. C’est le niveau que l’interface publique de votre boutique PrestaShop doit atteindre. Les critères de succès qui touchent une boutique typique tiennent en une courte liste, et chacun correspond à quelque chose de concret dans votre thème :

Remarquez le schéma : presque aucun de ces problèmes n’est un bug du cœur de PrestaShop. Ce sont des décisions intégrées dans votre thème et vos modules. C’est une bonne nouvelle, cela veut dire que les correctifs se trouvent dans des fichiers que vous maîtrisez.

Là où PrestaShop vous aide, et là où il vous expose

Le thème Classic par défaut de PrestaShop 1.7 à 9 s’appuie sur Bootstrap et constitue un point de départ raisonnable : les champs de formulaire utilisent de vrais éléments <label>, le tunnel de commande suit une hiérarchie de titres logique, et la plupart des contrôles natifs sont accessibles au clavier. Si votre boutique reste proche du thème Classic d’origine, vous êtes plus avancé que vous ne le pensez.

L’exposition vient de trois endroits prévisibles :

• Votre thème personnalisé ou acheté. Beaucoup de thèmes payants suppriment visuellement le contour de focus, ajoutent des menus utilisables seulement au survol et emploient des textes gris très fins qui échouent au critère 1.4.3. C’est la principale source d’échecs dans les boutiques réelles.
• Les modules qui injectent du balisage côté boutique. Carrousels, fenêtres d’aperçu rapide, bannières de cookies, cœurs de liste d’envies, listes déroulantes de recherche instantanée. Chacun ajoute un DOM interactif qui peut ne pas être utilisable au clavier ni annoncé. Chaque module installé est une nouvelle surface d’accessibilité à tester.
• Le contenu que vous rédigez. Descriptions produit avec des images ajoutées via l’éditeur de texte enrichi (sans alt), pages CMS avec des niveaux de titres sautés, PDF liés avec un simple « cliquez ici ». PrestaShop ne peut pas corriger ce que vous saisissez.

Une checklist de correction spécifique à PrestaShop

Le conseil générique « ajoutez des textes alternatifs » ne sert à rien si vous ne savez pas où agir. Voici la carte de l’interface d’administration et du code, à peu près dans l’ordre du meilleur rapport effort/résultat.

1. Texte alternatif des images produit, corrigez-le à la source et en masse

Dans l’éditeur de produit, l’onglet Catalogue → Produits → [produit] → Images contient un champ Légende pour chaque image. Cette valeur devient l’attribut alt côté boutique. Le remplir produit par produit dans un vrai catalogue, c’est souvent là que les bonnes intentions s’arrêtent. Deux chemins plus rapides :

• SQL/en masse : le texte alternatif des images se trouve dans ps_image_lang.legend (indexé par id_image et id_lang). Une mise à jour contrôlée à cet endroit, ou un import, bat la modification manuelle de centaines de lignes, faites d’abord une sauvegarde.
• Arrêtez de créer la dette : intégrez une légende utile à votre routine d’ajout de produit afin que les nouvelles images ne soient jamais vides. Un bon texte alternatif est aussi lu par Google Images : c’est donc de l’accessibilité et de la visibilité en un seul geste, notre suite Smart SEO Revolution existe pour garder ce type de métadonnées de page propres à l’échelle du catalogue, au lieu de les traiter produit par produit.

2. Visibilité du focus, souvent une correction d’une ligne dans le thème

Si le CSS de votre thème contient outline: none ou outline: 0 sur les liens, boutons ou champs sans remplacement tout aussi visible, les utilisateurs au clavier perdent totalement leur position. Cherchez-le dans le dossier assets/css/ de votre thème (et dans tout fichier custom.css). La bonne correction n’est pas de supprimer la règle à l’aveugle, mais de fournir un style :focus-visible clair, un contour de 2 px très contrasté. C’est le changement le plus rentable et le plus simple de cette liste.

Ajoutez ceci au custom.css de votre thème (ou à une feuille de style de thème enfant, afin qu’une mise à jour du thème ne l’efface pas) : cela rétablit un anneau de focus visible sur les éléments interactifs sans réactiver les contours lors des clics à la souris :

/* Restore a visible keyboard focus indicator (WCAG 2.4.7) */
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible {
  outline: 2px solid #1a1a1a;   /* pick a colour that hits 3:1 against its background */
  outline-offset: 2px;
}

La couleur du contour doit atteindre un contraste de 3:1 avec ce qui se trouve derrière elle : adaptez donc l’hexadécimal à votre palette au lieu de le copier sans réfléchir. Si le thème a défini outline: none avec !important, vous devrez peut-être atteindre la même spécificité, mais préférez supprimer la règle fautive à la source plutôt que d’empiler un autre !important par-dessus.

3. Tunnel de commande et formulaires, la partie liée au chiffre d’affaires

Le tunnel de commande est à la fois la page la plus sensible juridiquement et la plus sensible commercialement de votre boutique. Parcourez tout le flux de commande sur le contrôleur order de PrestaShop, informations personnelles, adresses, livraison, paiement, uniquement au clavier. Vérifiez que chaque champ possède un libellé visible (pas seulement un texte indicatif), que les boutons radio des transporteurs sont accessibles, et que les erreurs de validation nomment le champ fautif au lieu d’afficher une bannière générique. Les iframes de paiement tiers (Stripe, PayPal, Adyen) ont leur propre niveau d’accessibilité, testez une soumission réelle de bout en bout, pas seulement le chargement de la page. Comme un tunnel de commande accessible et un tunnel de commande qui convertit bien sont en grande partie le même tunnel, ce point rejoint tout ce que nous expliquons dans notre guide sur la sécurité des paiements pour bien maîtriser ce flux.

4. Messages d’état AJAX, l’angle mort des lecteurs d’écran

PrestaShop met à jour le total du panier et la grille de produits de ps_facetedsearch sans recharger la page. Un utilisateur voyant voit le nombre changer ; un utilisateur de lecteur d’écran n’entend rien, sauf si la zone mise à jour est marquée aria-live="polite". C’est le critère WCAG 4.1.3, et c’est celui que les outils automatisés manquent le plus souvent. Vérifiez que le bloc de sous-total du panier et le conteneur des résultats de recherche à facettes annoncent leurs mises à jour, si un module a remplacé le panier ou la recherche natifs, la responsabilité de cette vérification porte sur ce module.

5. Hiérarchie des titres et contraste, auditable en quelques minutes

Vérifiez que chaque page possède exactement un <h1> et ne saute aucun niveau (une page de catégorie qui passe de H1 à H3 perturbe la navigation au lecteur d’écran). Pour le contraste, les coupables habituels sont la couleur atténuée des prix et anciens prix, les badges de promotion et les textes indicatifs des champs, passez-les dans n’importe quel vérificateur de contraste avec une cible de 4,5:1.

Tester votre boutique comme le feront les autorités

Les scanners automatisés ne détectent qu’une minorité de problèmes, on cite souvent environ un tiers, même si les estimations varient selon l’outil et le site. Ils sont donc une ligne de départ, pas une ligne d’arrivée. Superposez vos tests :

• Premier passage automatisé : Lighthouse (Chrome DevTools → audit Accessibilité), l’extension WAVE et axe DevTools. Lancez-les sur votre page d’accueil, une catégorie, un produit, le panier et chaque étape du tunnel de commande, pas seulement sur la page d’accueil.
• Parcours au clavier uniquement : débranchez la souris. Tabulez du logo jusqu’à une commande finalisée. Tout ce que vous ne pouvez pas atteindre ou activer est un échec, point.
• Parcours au lecteur d’écran : NVDA (Windows, gratuit) ou VoiceOver (Mac, intégré). Écoutez une page produit et un tunnel de commande. Cela fait ressortir les problèmes de textes alternatifs, de libellés et d’aria-live qu’aucun scanner ne signalera avec certitude.
• Zoom à 200 % : vérifiez qu’aucun contenu n’est coupé et que rien n’exige un défilement horizontal.

La déclaration d’accessibilité, le document que tout le monde oublie

Plusieurs transpositions nationales attendent la publication d’une déclaration d’accessibilité : la norme visée (EN 301 549 / WCAG 2.1 AA), les limitations connues et un canal de contact pour les retours liés à l’accessibilité. Dans PrestaShop, le plus simple est d’en faire une page CMS (Apparence → Pages) liée depuis votre pied de page, à côté de vos autres pages légales. Elle appartient à la même étagère que vos conditions générales de vente, et, comme elles, c’est un document vivant que vous mettez à jour quand vous corrigez ou découvrez un problème.

Là où l’accessibilité recoupe le reste de votre conformité

Deux aspects du travail d’accessibilité relèvent en réalité aussi de sujets voisins : traitez-les là où ils vivent, plutôt que deux fois.

• La bannière de consentement aux cookies. Une bannière qui bloque les utilisateurs au clavier ou ne peut pas être fermée sans souris échoue à la fois sur l’accessibilité et sur le droit du consentement. Corrigez une fois la bannière elle-même. Ce qu’elle doit faire juridiquement est expliqué dans le consentement aux cookies pour PrestaShop et la conformité RGPD et cookies pour PrestaShop, puis testez cette même bannière au clavier.
• Les données et les formulaires. Le travail sur les formulaires accessibles de vos pages compte et contact se trouve juste à côté de vos obligations de traitement des données ; le volet confidentialité est couvert dans le RGPD pour les boutiques en ligne.

L’intérêt commercial au-delà de l’amende

Il vaut la peine de résister à l’idée que l’accessibilité n’est qu’une taxe. Une part significative de la population, souvent estimée à environ une personne sur sept dans le monde, avec des chiffres nationaux variables, vit avec un handicap, et bien plus de personnes utilisent des fonctions d’accessibilité selon les situations : reflet du soleil sur un téléphone, poignet foulé, bébé endormi qui exclut l’audio. Chacune d’elles est un client pour qui votre tunnel de commande est actuellement plus difficile qu’il ne devrait l’être.

Le recoupement avec une bonne ingénierie est réel lui aussi. Une structure de titres correcte et des textes alternatifs sont les mêmes signaux que les moteurs de recherche récompensent ; des libellés clairs et un focus visible réduisent les erreurs de formulaire et les abandons pour tout le monde, pas seulement pour les utilisateurs de technologies d’assistance. Vous aurez probablement du mal à séparer totalement « nous l’avons fait pour l’EAA » de « cela a simplement amélioré la boutique ». C’est la vraie bonne raison de faire le travail, même si votre exemption de microentreprise tient encore aujourd’hui.

Faire durer le résultat : l’accessibilité comme routine, pas comme projet

Les boutiques qui restent conformes ne lancent pas un audit héroïque ponctuel pour l’oublier ensuite, elles intègrent quelques vérifications dans leurs habitudes existantes :

• Ajout d’un produit : renseignez la légende de chaque image, gardez les descriptions dans de vrais titres/listes plutôt que dans de faux titres en gras.
• Installation d’un module : parcourez au clavier tout élément ajouté côté boutique avant la mise en ligne ; un carrousel ou une fenêtre contextuelle inaccessible est une régression que vous avez introduite.
• Changement de thème ou de design : relancez les tests clavier et contraste. Les refontes sont l’endroit où les contours de focus et le contraste disparaissent discrètement.
• Chaque trimestre : un balayage de 30 minutes avec Lighthouse + clavier sur le parcours principal (accueil → catégorie → produit → panier → tunnel de commande).

Questions fréquentes

L’EAA s’applique-t-il à ma petite boutique PrestaShop ?

Cela dépend de votre taille et de ce que vous vendez. Une microentreprise qui fournit des services, moins de 10 salariés et un chiffre d’affaires ou un total de bilan inférieur à 2 M€, est généralement exemptée des obligations relatives aux services, ce qui couvre de nombreuses petites boutiques B2C. Mais l’exemption ne s’étend pas à la liste de produits réglementés par l’EAA, et le B2B pur se situe largement hors du périmètre consommateur. Ce sont les seuils publiés par l’UE, pas une décision sur votre cas ; confirmez votre statut avec un avocat dans votre pays, car les transpositions nationales varient.

Quelle norme d’accessibilité dois-je réellement respecter ?

L’EAA renvoie à la norme harmonisée EN 301 549, qui adopte WCAG 2.1 niveau AA comme référence web. C’est le niveau que votre boutique en ligne doit atteindre. Les critères qui touchent une boutique PrestaShop typique tiennent en une courte liste, texte alternatif, contraste, utilisation au clavier, focus visible, vrais libellés de formulaires et annonces des mises à jour AJAX, et presque tous relèvent de décisions de thème ou de module, pas de bugs du cœur.

Le thème Classic par défaut de PrestaShop est-il accessible tel quel ?

C’est un point de départ raisonnable, pas une garantie. Le thème Classic utilise de vrais éléments <label>, une hiérarchie de titres logique dans le tunnel de commande et des contrôles pour la plupart accessibles au clavier. Les échecs viennent généralement d’un thème personnalisé ou acheté qui a supprimé le contour de focus et utilise un gris trop fin, de modules qui injectent du balisage interactif, et du contenu que vous rédigez sans texte alternatif. Plus vous restez proche du thème Classic d’origine, moins vous avez de corrections à faire.

Un scanner automatisé me dira-t-il si je suis conforme ?

Non. Les outils automatisés (Lighthouse, WAVE, axe) ne détectent qu’une minorité de problèmes, souvent autour d’un tiers, même si cela varie selon l’outil et le site. Ils ne sont donc qu’un point de départ. Il vous faut encore un parcours au clavier uniquement (débranchez la souris, tabulez du logo jusqu’à une commande finalisée), un passage au lecteur d’écran (NVDA ou VoiceOver) et un test de zoom à 200 %. Les critères que les scanners manquent le plus sont précisément ceux que les autorités et les vrais utilisateurs rencontrent : annonces aria-live, qualité des libellés et pièges au clavier.

Ai-je besoin d’une déclaration d’accessibilité, et où la placer dans PrestaShop ?

Plusieurs transpositions nationales en attendent une : la norme visée (EN 301 549 / WCAG 2.1 AA), les limitations connues et un canal de contact pour les retours liés à l’accessibilité. L’emplacement le plus simple dans PrestaShop est une page CMS sous Apparence → Pages, liée depuis votre pied de page à côté de vos autres pages légales. Traitez-la comme un document vivant que vous mettez à jour chaque fois que vous corrigez ou découvrez un problème.

L’EAA n’a pas inventé un nouveau type de travail ; il a mis une échéance juridique sur des travaux d’UX dont vous profiteriez de toute façon. Sur PrestaShop en particulier, ce travail est inhabituellement maîtrisable, car les échecs se concentrent dans votre thème, vos modules et les contenus que vous rédigez : tous visibles et modifiables depuis votre propre interface d’administration. Commencez par le tunnel de commande (la page où l’inaccessibilité et la perte de chiffre d’affaires sont le même problème), corrigez le contour de focus supprimé par votre thème, reprenez les textes alternatifs à la source, et vous aurez déjà franchi l’essentiel du seuil avant de toucher à quoi que ce soit d’exotique.