Checklist de l’Acte européen sur l’accessibilité (2026)

1. Vérifier qu’il vous concerne

La directive couvre les services aux consommateurs : commerce électronique, services bancaires, livres numériques, communications électroniques, accès aux médias audiovisuels et transport de voyageurs. Pour la plupart des propriétaires de sites, la question est celle du commerce électronique — tout site où des consommateurs achètent ou réservent en ligne, de la boutique WooCommerce au formulaire de réservation avec paiement.

Les microentreprises qui fournissent des services sont exemptées : moins de 10 personnes et un chiffre d’affaires annuel ou un total du bilan annuel n’excédant pas 2 millions d’euros. Au-delà, vous pouvez faire valoir qu’une exigence représente une charge disproportionnée, mais vous devez l’évaluer, la documenter et la réexaminer — ce n’est pas une dispense générale.

Chaque pays a transposé la directive dans sa propre loi, avec ses autorités et ses sanctions. Notre page sur l’Acte européen sur l’accessibilité résume la loi et deux régimes de sanctions nationaux, sources à l’appui.

2. Savoir ce que la loi exige d’un site

L’annexe I de la directive demande que les sites et applications soient perceptibles, utilisables, compréhensibles et robustes. Ce sont les quatre principes des WCAG, les règles du W3C pour l’accessibilité des contenus web, et c’est ainsi que l’exigence est remplie en pratique : via l’EN 301 549, la norme européenne dont la partie web suit les WCAG.

L’EN 301 549 version 3.2.1 suit WCAG 2.1 niveau AA. La version 4.1.1, mise à jour en septembre 2026 dans le cadre de la demande de normalisation liée à l’Acte, passe à WCAG 2.2 niveau AA. Si vous commencez maintenant, visez 2.2 AA : c’est 2.1 plus quelques critères, comme une taille minimale de cible et un focus qui ne disparaît pas derrière un en-tête fixe.

La loi demande aussi de l’information. L’annexe V prévoit que les prestataires expliquent comment leur service satisfait aux exigences d’accessibilité — en général dans une déclaration d’accessibilité qui indique la norme visée, les lacunes connues et la façon de signaler un problème.

3. Tester les pages qui vous rapportent

Commencez par les pages qu’un client doit franchir : accueil, une catégorie, un produit, le panier, la commande, et la connexion ou le compte. Un moteur automatique comme axe-core — celui d’axe DevTools et du score d’accessibilité de Lighthouse — trouve en quelques secondes les erreurs WCAG détectables par une machine : libellés manquants, textes alternatifs absents, contraste insuffisant, boutons sans nom, langue de la page absente.

Corrigez d’abord la commande. Un champ e-mail sans libellé ou un bouton de paiement sans nom peut empêcher totalement une personne qui utilise un lecteur d’écran d’acheter ; un problème de contraste dans le pied de page, non. Le tableau ci-dessous liste les erreurs courantes par critère WCAG, et celles qu’un outil trouve.

4. Faire tester par une personne ce que les outils ne peuvent pas

Les tests automatisés repèrent une partie des problèmes, pas tous. Le W3C précise que les outils d’évaluation ne peuvent pas déterminer seuls l’accessibilité, et l’étude de Deque sur des audits réels a montré que les tests automatisés identifiaient environ 57 % des problèmes en volume. Le reste demande du discernement.

Faites ceci à la main : parcourez toute la commande au clavier seul en vous assurant de toujours voir où vous êtes ; zoomez à 200 % et confirmez que rien n’est coupé ; activez un lecteur d’écran (VoiceOver et NVDA sont gratuits) et finalisez un achat ; envoyez un formulaire avec des erreurs et lisez si les messages disent quoi corriger. Pour un site concerné, un audit professionnel — idéalement avec des personnes qui utilisent des technologies d’assistance — vaut la dépense.

5. Empêcher les régressions

C’est l’étape que la plupart des checklists oublient. L’accessibilité ne se règle pas une fois pour toutes : une mise à jour du thème réécrit le balisage de la commande, un constructeur de pages remplace un bouton par une icône, une nouvelle couleur de campagne n’atteint pas le contraste. Rien de tout cela n’apparaît comme une erreur, et personne ne refait l’audit après chaque mise à jour d’extension.

La surveillance de l’accessibilité de Relvato exécute les mêmes règles axe-core sur vos pages clés chaque semaine et après les mises à jour d’extensions, de thème, du cœur et de WooCommerce. Vous approuvez les problèmes de la première analyse comme référence ; ensuite, tout nouveau problème fait échouer l’exécution et indique la page et le critère WCAG — tant que la correction est encore petite.

Erreurs WCAG courantes sur les boutiques, et qui les trouve

Critère WCAG	Ce qui échoue	Tests automatisés	Une personne doit
1.1.1 Contenu non textuel	Images et liens image sans texte alternatif	Trouvent les textes alternatifs manquants	juger si le texte alternatif décrit l’image
1.3.1 / 4.1.2 Libellés, nom, rôle	Champs sans libellé ; boutons et liens sans nom	Trouvent les libellés et noms manquants	juger si les libellés se comprennent hors contexte
1.4.3 Contraste (minimum)	Texte sous 4,5:1, ou 3:1 pour le texte agrandi	Trouvent la plupart des textes sur fond uni	regarder le texte sur images et dégradés
2.1.1 Clavier	Menus, carrousels ou étapes de commande qui exigent une souris	Trouvent très peu	parcourir la commande au clavier seul
2.4.7 Visibilité du focus	Aucun contour visible sur l’élément qui a le focus	Rarement détectable	voir où est le focus à chaque étape
2.4.2 Titre de page / 3.1.1 Langue	Pages sans titre ; attribut lang absent ou erroné	Trouvent ceux qui manquent	juger si le titre décrit la page
2.5.8 Taille de la cible (minimum)	Cibles tactiles de moins de 24×24 px sans espacement suffisant	Trouvent la plupart	essayer les commandes sur un vrai téléphone
1.4.4 Redimensionnement / 1.4.10 Redistribution	Zoom désactivé ; contenu coupé à 200 % ou sur écran étroit	Trouvent le zoom désactivé dans la balise viewport	zoomer à 200 % et confirmer que rien ne se perd
3.3.1 Identification des erreurs	Erreurs de formulaire signalées seulement par une bordure rouge	Trouvent très peu	envoyer des formulaires avec des erreurs et lire les messages
1.2.2 Sous-titres (préenregistrés)	Vidéos sans sous-titres	Peu : ils ne savent pas si les sous-titres sont justes	regarder avec les sous-titres activés

Questions fréquentes

Existe-t-il une checklist officielle de l’Acte européen sur l’accessibilité ?

Non. La directive fixe les exigences, l’EN 301 549 fixe la façon de les tester, et WCAG 2.1 ou 2.2 niveau AA est l’objectif pratique pour les sites. Une checklist comme celle-ci aide à les traiter dans l’ordre — ce n’est pas un certificat.

Un overlay ou un widget d’accessibilité rend-il un site conforme ?

Non. Une barre qui change la taille du texte ou le contraste ne corrige ni les libellés manquants, ni les pièges clavier, ni les boutons sans nom de votre balisage, et beaucoup de personnes qui utilisent des technologies d’assistance trouvent que les overlays les gênent. Corrigez le balisage en dessous.

À quelle fréquence retester ?

Après tout ce qui modifie le balisage : mises à jour de thème et d’extensions, nouvelle mise en page, refonte. Les tests automatisés coûtent assez peu pour tourner chaque semaine et après chaque mise à jour ; une revue manuelle a du sens après les changements importants et au moins une fois par an.

Ai-je besoin d’une déclaration d’accessibilité ?

L’annexe V de la directive demande aux prestataires d’expliquer comment leur service satisfait aux exigences d’accessibilité, et les lois nationales en font des obligations précises. Une page courte qui indique la norme visée, les lacunes connues et la façon de signaler un problème couvre l’essentiel.

Checklist de l’Acte européen sur l’accessibilité pour les sites web