Loi accessibilité numérique : vérifier votre site vous-même

Si vous vendez en ligne à des consommateurs dans l’UE, les exigences de l’European Accessibility Act pour les sites web, souvent appelé la loi accessibilité numérique, s’appliquent à votre boutique depuis le 28 juin 2025, sauf si votre entreprise est une microentreprise. Vous pouvez repérer vous-même bon nombre des problèmes sérieux : passez une commande test uniquement au clavier, zoomez la page et essayez chaque formulaire. Ce qu’une vérification par vous-même ne peut pas faire, c’est prouver que l’ensemble du site respecte la norme.

Un développeur a peut-être évoqué la loi, ou un e-mail vous a proposé un widget qui rend n’importe quel site « conforme » avec une seule ligne de code. Un client qui ne parvient pas à passer votre tunnel de commande au clavier ou avec un lecteur d’écran (un logiciel qui lit la page à voix haute) peut partir chez un autre commerçant sans se plaindre.

Votre site est-il concerné par la loi accessibilité numérique ?

L’European Accessibility Act s’applique si votre site vend à des consommateurs, c’est-à-dire à des personnes qui achètent pour elles-mêmes, et si votre entreprise n’est pas une microentreprise. La directive (UE) 2019/882 range les services de commerce électronique parmi les services qu’elle couvre : des services fournis via un site web ou une application « en vue de la conclusion d’un contrat avec un consommateur ». Les pays devaient appliquer ses règles à partir du 28 juin 2025. C’est notre lecture de la directive ; pour un avis juridique sur votre propre cas, consultez un avocat.

• Les microentreprises qui fournissent des services sont exemptées. C’est l’article 4, paragraphe 5. La directive définit une microentreprise comme une entreprise qui occupe moins de 10 personnes et dont le chiffre d’affaires annuel ou le total du bilan annuel n’excède pas 2 millions d’euros. L’effectif et l’un des deux critères financiers comptent tous les deux : une équipe de dix personnes sort de l’exemption, si faible que soit le chiffre d’affaires.
• Vendre uniquement à des entreprises. La définition porte sur les contrats avec des consommateurs. Si des particuliers peuvent commander via votre tunnel de commande, considérez le site comme concerné.
• Un site qui ne vend rien. Un site d’entreprise sans commandes, réservations ni paiements n’est en général pas un service de commerce électronique au sens de la directive. Les réservations et les paiements changent la donne.
• L’échéance de 2030 concerne les produits et les anciens contrats. La période de transition jusqu’au 28 juin 2030 prévue à l’article 32 couvre les produits utilisés pour fournir un service et les contrats conclus avant juin 2025.

Chaque pays de l’UE fait appliquer l’European Accessibility Act par sa propre loi et fixe ses propres sanctions ; en Allemagne, cette loi est le BFSG. Si votre entreprise est établie en Suisse ou au Royaume-Uni et vend à des consommateurs dans l’UE, demandez à un avocat comment les règles de ces pays s’appliquent à vous.

Pourquoi les sites marchands échouent-ils aux contrôles d’accessibilité ?

Les défauts ci-dessous viennent en général de choix de design et de formulaires faits une fois dans un thème et répétés sur chaque page. La directive (UE) 2019/882 demande des sites web « perceptibles, utilisables, compréhensibles et robustes ». La norme européenne qui traduit cela en tests, EN 301 549, suit les WCAG, les règles pour l’accessibilité des contenus web publiées par le W3C. Les WCAG classent leurs critères en trois niveaux : A (le minimum), AA et AAA. Le niveau AA est la cible retenue par la norme.

Le contour de focus a été supprimé pour l’esthétique. Quand quelqu’un parcourt une page avec la touche Tab, le navigateur dessine un cadre autour du lien ou du bouton actif. Certains thèmes le masquent parce qu’il fait désordre, alors que les WCAG exigent un indicateur de focus visible. Un critère ajouté dans les WCAG 2.2 précise aussi que l’élément qui a le focus ne doit pas être entièrement masqué par le contenu du site lui-même, comme un en-tête fixe ou un bandeau cookies.

Le texte est trop pâle. Les WCAG demandent un rapport de contraste, c’est-à-dire à quel point le texte est plus foncé ou plus clair que son fond, d’au moins 4,5:1 pour le texte normal et 3:1 pour le grand texte. L’analyse 2026 de WebAIM portant sur un million de pages d’accueil a trouvé du texte à faible contraste sur 83,9 % d’entre elles. Le gris clair sur blanc et le blanc sur un bouton pastel sont les cas habituels.

Les formulaires misent sur le texte indicatif et la couleur. Un indice gris dans un champ disparaît dès que vous tapez, et une bordure rouge seule ne dit pas ce qui ne va pas. Les WCAG exigent des étiquettes ou des instructions partout où une saisie est attendue, et des erreurs décrites sous forme de texte.

Le tunnel de commande a été conçu pour la souris. Les listes déroulantes personnalisées, les CAPTCHA à puzzle et les connexions qui demandent de mémoriser ou de recopier un code bloquent les personnes qui utilisent un clavier ou un lecteur d’écran. Pour le commerce électronique, la directive cite séparément l’identification, la sécurité et le paiement. En mars 2026, l’autorité néerlandaise des consommateurs ACM a indiqué que sur 61 % des grandes boutiques en ligne néerlandaises et autres grands sites grand public qu’elle a contrôlés, il était impossible de passer commande avec une technologie d’assistance comme un lecteur d’écran.

Un widget ou un score remplace la correction. Les widgets en surcouche (overlays) ajoutent une barre d’outils d’accessibilité par-dessus le site. La Commission européenne indique que les surcouches et outils similaires qui ne rendent pas le site lui-même conforme à la norme « ne constituent pas une solution appropriée ». Un test automatique aide, mais selon les mots du W3C, « aucun outil ne peut à lui seul déterminer si un site respecte les normes d’accessibilité ».

Comment vérifier votre site vous-même face à la loi

Vous pouvez faire un premier examen avec un navigateur et un clavier, sans outil payant. Le W3C, l’organisme à l’origine des WCAG, publie sur ce principe une série de vérifications simples, les Easy Checks. Choisissez trois pages : la page d’accueil, une page produit ou service, et le tunnel de commande ou le formulaire de contact. Procédez dans l’ordre et notez chaque endroit où vous bloquez.

1. Rangez la souris. Parcourez chaque page avec Tab et Maj+Tab, et utilisez Entrée, Espace et les flèches. Vous devez pouvoir atteindre le menu, les filtres, le bouton d’ajout au panier, chaque champ de formulaire et le bouton de paiement. À tout moment, vous devez voir où vous êtes. Notez où le cadre disparaît derrière un en-tête fixe ou un bandeau cookies, et si vous pouvez sortir d’un menu ou d’une fenêtre de chat.
2. Zoomez. Réglez le navigateur sur 200 %. Les WCAG attendent que le texte reste lisible sans que le contenu soit coupé ou se chevauche. Réduisez ensuite la fenêtre à environ 1280 pixels de large et zoomez à 400 % : le contenu doit tenir dans la largeur sans défilement horizontal, sauf pour des éléments comme les cartes et les tableaux de données.
3. Vérifiez le texte pâle. Les outils de développement de Chrome, Edge et Firefox affichent le rapport de contraste d’une couleur de texte sélectionnée. Vérifiez le texte courant, les prix, les boutons et le petit texte gris sous les champs de formulaire.
4. Essayez chaque formulaire vide, puis mal rempli. Chaque champ a besoin d’une étiquette visible qui reste quand vous tapez. Envoyez le formulaire vide : l’erreur doit dire en toutes lettres ce qui manque, à côté du champ, et conserver ce que vous avez déjà saisi. Un nouveau critère des WCAG 2.2 demande aussi que les informations déjà saisies dans le même processus, comme une adresse, soient remplies automatiquement ou proposées au choix. Les autres façons dont un formulaire vous fait perdre des commandes sont dans notre article du trafic sur le site, mais aucune demande.
5. Connectez-vous et passez le contrôle anti-spam. Selon les WCAG 2.2, la connexion ne doit pas dépendre d’un test de fonction cognitive, comme mémoriser un mot de passe ou résoudre un puzzle, sauf s’il existe une alternative ou une aide, comme un gestionnaire de mots de passe ou le copier-coller. Un CAPTCHA à puzzle sans autre option échoue ici.
6. Regardez les images produit. Faites un clic droit sur une image et choisissez Inspecter. Le texte alternatif, la courte description que lit un lecteur d’écran, doit dire ce qu’est le produit ; les images purement décoratives peuvent en avoir un vide.
7. Refaites les étapes clés sur un téléphone. De petites icônes rapprochées sont difficiles à toucher. Les WCAG 2.2 fixent une taille de cible minimale de 24 sur 24 pixels CSS (une unité de taille de la page web elle-même), avec des exceptions comme un espace suffisant autour de la cible.

Le W3C note qu’une page « pourrait sembler réussir ces vérifications tout en présentant d’importants obstacles à l’accessibilité ». L’étape suivante est un test par une personne qui utilise un lecteur d’écran au quotidien.

Que corriger en premier ?

Commencez par les corrections dans le thème et les composants de formulaire, de la moins chère à la plus coûteuse. Une modification dans un modèle corrige toutes les pages construites dessus. Gardez les informations publiées sur l’accessibilité pour la fin, quand vous saurez ce que le site fait et ne fait pas.

1. N’installez pas de surcouche. La Commission européenne conseille de corriger les problèmes d’accessibilité « à la source », ce qui, pour une boutique, veut dire le thème, les formulaires et le tunnel de commande.
2. Rétablissez le cadre de focus et foncez le texte. Les deux se trouvent en général dans les réglages de couleurs et de styles du thème. Nous commençons par fixer le contraste une fois dans la palette du design et par le vérifier dans les versions claire et sombre du site, pour qu’une nouvelle page parte de couleurs déjà conformes.
3. Refaites les formulaires. Des étiquettes visibles, des erreurs en toutes lettres à côté du champ, les données saisies conservées après une erreur, le focus placé sur le premier champ à corriger, et la saisie automatique du navigateur pour le nom, l’e-mail et l’adresse. Dans nos projets de sites web, nous commençons par le composant de formulaire lui-même, pour que chaque nouveau formulaire intègre d’emblée ces corrections.
4. Ajoutez les textes alternatifs et la langue de la page. Décrivez les images de produits et de contenu, et assurez-vous que chaque page déclare sa langue, pour qu’un lecteur d’écran la prononce correctement. Les moteurs de recherche lisent les mêmes textes alternatifs et le même attribut de langue, c’est pourquoi ils relèvent aussi du SEO technique.
5. Corrigez le tunnel de commande, la connexion et les widgets tiers. Remplacez les CAPTCHA à puzzle par des contrôles qui ne demandent au client de rien résoudre, et proposez un mode de connexion qui ne dépend pas de la mémoire. Les widgets de paiement et de chat viennent de prestataires : demandez à chacun ses informations d’accessibilité et remplacez ceux qu’un clavier ne peut pas atteindre.
6. Publiez vos informations sur l’accessibilité. L’annexe V de la directive demande aux prestataires de services de décrire comment le service satisfait aux exigences, dans les conditions générales ou un document équivalent. Votre droit national fixe les détails.
7. Visez les WCAG 2.2 niveau AA. La version 4.1.1 de l’EN 301 549, publiée en septembre 2026, ajoute six exigences issues des WCAG 2.2, rapporte AccessibleEU. Tant que la Commission ne l’a pas citée au Journal officiel de l’Union européenne, précise la même source, la référence reste la version 3.2.1, fondée sur les WCAG 2.1 niveau AA. La National Disability Authority irlandaise attend cette citation le 16 décembre 2026. Corriger dès maintenant selon les WCAG 2.2 signifie que les nouvelles exigences seront couvertes à ce moment-là.

La directive admet une exception lorsque la mise en conformité imposerait une charge disproportionnée, mais elle exige une évaluation, et ses considérants précisent que « le manque de priorité, de temps ou de connaissances » ne constitue pas une raison légitime.

Que mesurer après les corrections ?

Mesurez si une personne peut accomplir les tâches principales au clavier et sur une page zoomée. Refaites la même vérification au regard de la loi accessibilité numérique sur les trois mêmes pages, et comparez les endroits où vous bloquiez avant et après les changements. Revérifiez à chaque changement de thème, d’extension ou de prestataire de paiement.

1. Une commande test au clavier uniquement, de la page produit à la confirmation, sans toucher la souris.
2. La liste des résultats d’un test automatique gratuit, comme Lighthouse dans Chrome, lancé sur les trois mêmes types de pages. Passez les résultats en revue et vérifiez lesquels subsistent.
3. Des formulaires envoyés avec des erreurs, pour confirmer que chaque erreur est décrite en toutes lettres et que rien de ce qui a été saisi n’est perdu.
4. Vos informations publiées sur l’accessibilité, mises à jour après chaque changement qui touche la façon dont les clients commandent.

Notre rôle

Quand nous examinons le tunnel de commande d’une boutique, nous suivons le parcours du client : la page produit, le panier, les formulaires et l’étape de paiement, d’abord au clavier, puis sur un téléphone. Les problèmes qui se trouvent dans le thème ou les composants de formulaire coûtent le moins cher à corriger à cet endroit ; ce qu’une vérification par vous-même ne peut pas trancher est réservé à un test avec un lecteur d’écran. Si vous souhaitez un second regard sur votre tunnel de commande, parlez-nous de votre site.

← Tous les articles