L’accessibilité d’un site web, c’est un site que les personnes en situation de handicap peuvent percevoir, utiliser et comprendre ; avec l’European Accessibility Act, c’est désormais une obligation légale pour de nombreuses entreprises qui vendent aux consommateurs dans l’UE. En pratique, l’Acte renvoie à la norme harmonisée EN 301 549, qui repose elle-même sur les règles pour l’accessibilité des contenus web (WCAG) du W3C, niveau AA. Ce guide explique qui est concerné et depuis quand, ce que demandent les normes, les défauts que nous rencontrons le plus souvent et comment les corriger, une méthode d’audit numérotée, la déclaration d’accessibilité et la manière dont le texte est appliqué dans les États membres.
Dernière mise à jour : 27 octobre 2026.
Qu’est-ce que l’European Accessibility Act ?
L’European Accessibility Act est la directive (UE) 2019/882, adoptée le 17 avril 2019. Elle fixe des exigences d’accessibilité communes pour une liste de produits et de services dans tout le marché unique, afin qu’une entreprise respecte un seul ensemble de règles plutôt qu’un ensemble différent dans chaque pays.
S’agissant d’une directive, chaque État membre devait la transposer dans son droit national avant le 28 juin 2022 et appliquer ces règles à partir du 28 juin 2025. Depuis le 28 juin 2025, l’European Accessibility Act s’applique aux produits concernés mis sur le marché et aux services concernés fournis aux consommateurs. Ce qu’une entreprise doit faire concrètement est fixé par chaque loi nationale, qui suit de près la directive mais y ajoute ses propres autorités de contrôle et ses propres sanctions.
L’Acte côtoie un texte plus ancien, la directive sur l’accessibilité des sites web, qui couvre les sites et applications des organismes du secteur public. C’est l’European Accessibility Act qui atteint les entreprises privées.
En bref : si vous vendez certains services aux consommateurs dans l’UE, votre site web et votre application doivent être accessibles. La référence est la norme EN 301 549, qui s’appuie sur le niveau AA des WCAG. Les très petites entreprises de services sont exemptées. Chaque pays applique sa propre version des règles.
Chez Odduel, agence créative et technologique à Barcelone et São Paulo, l’accessibilité est intégrée à chaque site dès le premier wireframe : c’est ainsi que nous cadrons nos projets de création de sites web. La suite de ce guide reprend ce que nous disons aux clients qui nous demandent où ils en sont.
Qui doit se conformer à l’EAA ?
L’Acte couvre des produits et des services nommément listés, pas tous les sites web. Côté services, ceux qui concernent le plus de sites et d’applications sont :
- Services d’e-commerce : tout service vendu à distance aux consommateurs via un site web ou une application mobile. C’est pourquoi la plupart des boutiques en ligne entrent dans le périmètre.
- Les services bancaires aux consommateurs, y compris les sites et applications par lesquels ils sont proposés.
- Les livres numériques et les logiciels servant à les lire.
- Les services de communications électroniques et les services donnant accès aux médias audiovisuels.
- Certains éléments des services de transport de voyageurs aériens, par autobus, ferroviaires et par voie d’eau : sites web, applications, billets électroniques et informations de voyage en temps réel.
Côté produits, le texte couvre notamment les ordinateurs, les smartphones, les liseuses, les terminaux de paiement, les distributeurs de billets et les bornes de billetterie. Si vous fabriquez ou importez ces produits, l’Acte s’applique au matériel et à son logiciel, pas seulement à un site web.
Une entreprise située hors de l’UE n’est pas hors de portée : ce qui compte, c’est que le service soit proposé à des consommateurs dans l’UE. Une entreprise qui vend uniquement à d’autres entreprises, sans service destiné aux consommateurs, sort en général du champ du commerce électronique ; mais beaucoup de sites servent les deux, et la partie grand public est alors couverte.
L’exemption des microentreprises
La directive exempte les microentreprises qui fournissent des services. Une microentreprise, au sens de la directive, emploie moins de dix personnes et réalise un chiffre d’affaires annuel ou un total de bilan inférieur à un plafond modeste fixé dans le texte. Un petit studio qui vend ses services en ligne peut donc échapper à l’obligation.
Deux points passent souvent inaperçus. L’exemption vaut pour les services uniquement : une microentreprise qui fabrique ou vend des produits concernés doit tout de même respecter les exigences applicables aux produits, avec des formalités allégées. Et être exempté aujourd’hui ne rend pas un site inaccessible judicieux pour autant : une entreprise qui dépasse le seuil entre dans le champ, et les clients en situation de handicap restent des clients dans tous les cas.
Contenus et contrats bénéficiant d’un régime particulier
La directive laisse certains contenus hors des exigences : les contenus audio et vidéo préenregistrés publiés avant le 28 juin 2025, les documents bureautiques publiés avant cette date, les contenus archivés non modifiés depuis, les cartes en ligne dont l’information essentielle est fournie de manière accessible, et les contenus de tiers que l’entreprise ne finance ni ne contrôle. Les contrats de services conclus avant le 28 juin 2025 peuvent se poursuivre sans modification jusqu’à leur terme, pendant cinq ans au maximum.
Une entreprise peut aussi faire valoir qu’une exigence lui imposerait une charge disproportionnée ou modifierait fondamentalement le service. Cette invocation doit être évaluée et documentée au regard des critères de la directive, et les autorités peuvent demander à la consulter. Ce n’est pas une dérogation générale.
Quelle norme s’applique ?
La directive décrit l’accessibilité en termes fonctionnels : un contenu doit être perceptible, utilisable, compréhensible et robuste. Pour en faire des tests, l’UE s’appuie sur des normes harmonisées ; pour les sites et applications, il s’agit de la norme EN 301 549, la norme européenne sur l’accessibilité des technologies de l’information et de la communication. Respecter une norme harmonisée dont la référence est publiée pour l’Acte confère une présomption de conformité.
Pour les contenus web, la norme EN 301 549 reprend les critères de succès des WCAG du W3C aux niveaux A et AA. La version actuelle de la norme repose sur les WCAG 2.1. Les WCAG 2.2, plus récentes et recommandation du W3C depuis octobre 2023, conservent les critères de la version 2.1 (sauf un critère obsolète sur l’analyse syntaxique) et en ajoutent neuf, dont six aux niveaux A et AA.
Notre conseil : concevoir et tester selon les WCAG 2.2 AA. Un site qui les respecte remplit aussi les critères 2.1 que la norme teste aujourd’hui, et il est prêt pour la prochaine révision d’EN 301 549 sans avoir besoin d’un second passage.
| WCAG 2.1 AA | WCAG 2.2 AA | |
|---|---|---|
| État | Recommandation du W3C, 2018 | Recommandation du W3C, octobre 2023 |
| Utilisée aujourd’hui par EN 301 549 | Oui | Pas encore |
| Focus visible et non masqué | Le focus doit être visible | Le focus ne doit pas non plus être entièrement masqué par des barres ou bandeaux fixes |
| Petites commandes | Pas de taille minimale au niveau AA | Cibles d’au moins 24 × 24 pixels CSS, ou espacement suffisant |
| Glisser-déposer | Non couvert au niveau AA | Une alternative au glissement avec un seul pointeur |
| Formulaires | Libellés et aide à la saisie | Et pas de nouvelle saisie d’une information déjà fournie |
| Connexion | Non couvert | Pas de test de mémoire ou d’énigme sans alternative |
| Aide | Non couvert | Les options d’aide au même endroit sur chaque page |
Que signifie WCAG 2.2 AA en pratique ?
Les WCAG se présentent sous forme de critères de succès testables, regroupés sous quatre principes. Traduit en expérience du visiteur, le niveau AA demande à peu près ceci :
- Perceptible : les images ont des alternatives textuelles, les vidéos des sous-titres, le texte un contraste suffisant avec son fond (4,5 pour 1 pour le texte courant, 3 pour 1 pour les grands textes et les éléments d’interface), et la page fonctionne toujours quand le texte est agrandi à 200 % ou que l’écran est étroit.
- Utilisable : tout peut se faire au clavier seul, le focus est toujours visible, rien ne clignote de manière dangereuse, les contenus en mouvement peuvent être mis en pause, et le visiteur dispose d’assez de temps pour agir.
- Compréhensible : la page déclare sa langue, la navigation se comporte de façon cohérente, les formulaires ont des libellés et expliquent les erreurs, et rien ne change de contexte sans prévenir.
- Robuste : le code expose correctement les noms, rôles et états aux technologies d’assistance comme les lecteurs d’écran, et les messages d’état sont annoncés.
Rien de tout cela n’impose un site austère ou terne. Les sites que nous concevons ont du mouvement, de grands caractères et des couleurs franches ; ce qui change, c’est que le mouvement respecte le réglage de réduction des animations du visiteur, que la couleur ne porte jamais seule une information et que chaque interaction a un chemin au clavier. L’accessibilité fonctionne mieux quand elle fait partie des règles d’identité : une charte graphique qui précise des paires de couleurs accessibles évite bien des débats plus tard.
Quelles sont les défaillances d’accessibilité les plus courantes, et comment les corriger ?
La plupart des audits retrouvent sans cesse les mêmes défauts. Ils viennent de décisions de design prises sans les règles en tête et de composants copiés d’un projet à l’autre. Le tableau recense ceux que nous voyons le plus souvent et ce qui les corrige.
| Défaut | Qui est concerné | Critère WCAG | Parade |
|---|---|---|---|
| Texte peu contrasté, surtout gris sur blanc ou blanc sur couleur vive | Malvoyants, visiteurs âgés, toute personne en plein soleil | 1.4.3 Contraste (minimum) | Fixer des paires de couleurs accessibles dans les design tokens et mesurer chaque nouvelle paire |
| Images sans alternative textuelle utile | Utilisateurs de lecteurs d’écran | 1.1.1 Contenu non textuel | Décrire les images informatives ; donner un alt vide aux images décoratives |
| Champs de formulaire sans libellé, ou texte indicatif servant de seul libellé | Utilisateurs de lecteurs d’écran et de commande vocale | 1.3.1, 3.3.2, 4.1.2 | Un libellé visible lié à chaque champ ; les erreurs en texte à côté du champ |
| Commandes utilisables uniquement à la souris | Utilisateurs du clavier et de contacteurs | 2.1.1 Clavier | Utiliser de vrais boutons et liens ; tester chaque parcours au clavier seul |
| Contour de focus supprimé ou masqué par un en-tête fixe | Utilisateurs du clavier | 2.4.7, 2.4.11 | Un style de focus marqué ; une marge de défilement pour que le focus ne soit jamais couvert |
| Titres utilisés pour la taille, pas pour la structure | Utilisateurs de lecteurs d’écran | 1.3.1 Information et relations | Un seul H1, des titres dans l’ordre, des styles appliqués par classe |
| Liens qui disent seulement « cliquez ici » ou « lire la suite » | Utilisateurs de lecteurs d’écran | 2.4.4 Fonction du lien | Un texte de lien qui nomme la destination |
| Vidéos sans sous-titres | Visiteurs sourds et malentendants | 1.2.2 Sous-titres | Des sous-titres pour chaque vidéo parlée ; des transcriptions pour l’audio |
| Bandeaux cookies et fenêtres qui piègent ou sautent le focus | Utilisateurs du clavier et de lecteurs d’écran | 2.1.2, 2.4.3 | Placer le focus dans la fenêtre, l’y maintenir, le rendre à la fermeture |
| Minuscules boutons-icônes collés les uns aux autres | Troubles moteurs, utilisateurs sur téléphone | 2.5.8 Taille de la cible (minimum) | Des cibles d’au moins 24 × 24 pixels CSS, ou un espacement autour |
| Animation impossible à arrêter | Troubles vestibulaires, difficultés d’attention | 2.2.2 Mettre en pause, arrêter, masquer | Une commande de pause ; respecter le réglage de réduction des animations |
Les outils automatiques en détectent une partie, comme les alternatives textuelles manquantes, le contraste insuffisant ou les libellés absents. Ils ne peuvent pas dire si une alternative textuelle a du sens, si l’ordre de tabulation est logique ou si un message d’erreur aide vraiment. C’est pourquoi la méthode ci-dessous combine outils et tests manuels.
Comment auditer et corriger l’accessibilité d’un site web ?
Un audit n’est utile que s’il débouche sur des corrections et reste vrai après la mise en production suivante. Voici la méthode que nous suivons, que le site soit le nôtre ou hérité.
- Fixer la cible et le périmètre. Convenez des WCAG 2.2 AA et listez les gabarits et parcours à tester : accueil, page de contenu, page produit ou service, recherche, panier et commande, connexion, formulaires de contact et bandeau cookies. Sur la plupart des sites, une douzaine de gabarits couvrent presque toutes les pages.
- Lancer les vérifications automatiques. Utilisez un moteur de règles reconnu sur chaque gabarit et dans chaque version linguistique. Consignez les problèmes par critère, pas par page, car un défaut de composant se répète partout.
- Tester au clavier seul. Réalisez chaque parcours clé sans souris : atteindre chaque commande, voir le focus en permanence, ouvrir et fermer menus et fenêtres, envoyer les formulaires avec et sans erreurs.
- Tester avec un lecteur d’écran et le zoom. Écoutez les parcours principaux avec au moins un lecteur d’écran sur ordinateur et un sur téléphone, puis agrandissez le texte à 200 % et affichez la page en largeur étroite. Vérifiez titres, régions, libellés et annonces.
- Revoir les contenus et les médias. Vérifiez les alternatives textuelles, la formulation des liens, les sous-titres, les documents téléchargeables et la clarté des instructions et des messages d’erreur.
- Prioriser selon l’impact. Corrigez d’abord ce qui bloque une tâche (une commande impossible à finaliser au clavier), puis ce qui la complique, puis le reste. La plupart des corrections relèvent des composants partagés et des design tokens : une seule modification répare de nombreuses pages.
- Corriger, puis retester. Relancez les mêmes tests sur les gabarits corrigés et conservez les résultats datés, pour pouvoir montrer ce qui a été trouvé et quand cela a été corrigé.
- Publier la déclaration et l’intégrer au processus de mise en production. Rédigez la déclaration d’accessibilité (ci-dessous), puis ajoutez des contrôles d’accessibilité à chaque mise en production, à côté du reste de votre checklist de recette de site web.
Les tests avec des utilisateurs en situation de handicap apportent ce qu’aucune checklist ne peut dire : si le site est vraiment agréable à utiliser. Quand le budget le permet, une courte série de sessions sur les parcours principaux vaut plus qu’un nouveau scan automatique.
L’accessibilité recoupe aussi la maintenance. Des extensions et thèmes mis à jour sans contrôle peuvent casser la gestion du focus ou les libellés : la même rigueur qui protège un site, décrite dans notre guide sur la sécurité WordPress, le garde accessible.
Faut-il une déclaration d’accessibilité ?
Avec l’European Accessibility Act, les prestataires de services doivent indiquer comment leur service répond aux exigences d’accessibilité, dans leurs conditions générales ou à un autre endroit facile à trouver, et sous une forme accessible. La plupart des entreprises s’en acquittent avec une déclaration d’accessibilité accessible depuis le pied de chaque page.
Une déclaration claire précise :
- la norme visée (WCAG 2.2 AA, via EN 301 549) et dans quelle mesure le site la respecte ;
- les lacunes connues, avec leur raison et une date de correction quand vous en avez une ;
- les contenus hors exigences et toute charge disproportionnée documentée ;
- comment et quand le site a été évalué pour la dernière fois ;
- un contact par lequel les visiteurs peuvent signaler un problème ou demander un contenu dans un autre format, et votre délai de réponse ;
- où un visiteur peut se plaindre si la réponse ne le satisfait pas, ce qui dépend de votre autorité nationale.
Rédigez-la simplement et tenez-la à jour. Une déclaration qui affirme une conformité totale sur un site aux défauts évidents fait plus de tort qu’une déclaration honnête qui liste ce qui est encore en cours de correction.
Comment l’EAA est-il appliqué, et quelles sont les sanctions ?
Chaque État membre désigne ses propres autorités de surveillance du marché et fixe ses propres sanctions, que la directive veut effectives, proportionnées et dissuasives. Les autorités, les procédures et l’ampleur des sanctions varient donc d’un pays à l’autre, et certaines lois nationales permettent aussi aux associations de consommateurs ou aux particuliers d’agir.
Pour une entreprise qui vend dans plusieurs pays de l’UE, la réponse pratique consiste à respecter partout la norme commune plutôt qu’à suivre chaque variante nationale. Si vous avez besoin des règles exactes de sanction d’un marché, lisez la loi de transposition de ce pays ou consultez un avocat qui y exerce : les montants sont nationaux, et nous ne les citons pas ici.
Ce que les autorités peuvent généralement demander, ce sont des preuves : la norme suivie, vos résultats de tests, votre déclaration et toute évaluation de charge disproportionnée. L’historique d’audit produit par la méthode ci-dessus constitue ces preuves.
Questions fréquentes
L’acte européen sur l’accessibilité s’applique-t-il à mon site ?
Il s’applique si votre site ou votre application fournit un service concerné à des consommateurs dans l’UE : commerce électronique, banque de détail, livres numériques, communications électroniques ou informations de transport de voyageurs. Un site d’entreprise purement informatif peut être hors champ, et les microentreprises de services sont exemptées. Vérifiez par rapport à la liste de la directive et à la loi de transposition de votre pays.
Les WCAG 2.2 AA sont-elles obligatoires ?
La loi impose l’accessibilité, et la norme harmonisée EN 301 549 confère une présomption de conformité. Cette norme utilise aujourd’hui les WCAG 2.1 AA pour les contenus web. Les WCAG 2.2 AA incluent ces critères et en ajoutent quelques-uns : concevoir selon les WCAG 2.2 AA respecte donc la norme actuelle et prépare le site à sa prochaine révision.
Un overlay ou une extension d’accessibilité peut-il rendre mon site conforme ?
Non. Les overlays et barres d’outils modifient l’apparence ou la lecture d’une page, mais ne corrigent ni le code sous-jacent, ni les libellés, ni l’ordre de tabulation, ni les contenus, et certains perturbent les lecteurs d’écran que les visiteurs utilisent déjà. Un site conforme exige de corriger ses gabarits et ses composants. Les extensions peuvent aider à vérifier pendant la saisie, mais elles ne remplacent pas ce travail.
Combien de temps dure un audit d’accessibilité de site web ?
Cela dépend du nombre de gabarits et de parcours plutôt que du nombre de pages, car la plupart des défauts se trouvent dans des composants partagés. Un petit site avec quelques gabarits s’audite vite ; une grande boutique avec comptes clients, recherche et commande demande plus de temps. Un plan à prix fixe suit un rapide examen du site et de ses parcours clés.
Que se passe-t-il si mon site n’est pas accessible ?
Vous vous exposez à une action de l’autorité nationale de surveillance du marché, qui peut exiger des corrections et imposer des sanctions selon la loi nationale, et dans certains pays à des plaintes de consommateurs ou d’associations. Tout aussi important, vous perdez les clients qui ne peuvent pas finaliser un achat. Corrigez d’abord les problèmes bloquants et publiez une déclaration honnête pendant que le reste est traité.
Si vous ne savez pas si votre site respecte l’European Accessibility Act, commencez par un audit des gabarits et des parcours qui comptent le plus, puis corrigez les composants partagés à l’origine de la plupart des défauts. Nous concevons des sites accessibles dès le premier wireframe et remettons à niveau les sites hérités dans le cadre de nos projets de création de sites web. Parlez-nous de votre site : nous vous dirons clairement où il en est.
Pour aller plus loin : Check-list d’audit UX : les points à vérifier et la méthode en sept étapes.
