L’European Accessibility Act (EAA, directive (UE) 2019/882) s’applique depuis le 28 juin 2025 : les entreprises qui proposent aux consommateurs certains services, dont le commerce électronique, les services bancaires, les transports de voyageurs et les communications électroniques, doivent rendre leurs sites, applications mobiles et parcours d’achat accessibles aux personnes en situation de handicap. Seules les microentreprises prestataires de services sont exemptées. En France, la DGCCRF contrôle et peut sanctionner. Concrètement, il faut aligner ses interfaces sur la norme européenne EN 301 549, que le référentiel français RGAA décline en critères vérifiables.
Ce guide fait le point sur le périmètre réel du texte, souvent mal compris, puis sur la façon d’intégrer l’accessibilité dans un projet d’application sans en faire un chantier interminable.
Qui est concerné par l’European Accessibility Act ?
La directive ne vise pas « tous les sites web ». Elle dresse une liste fermée de produits et de services. Pour les services, la fiche d’information de la DGCCRF retient :
- les services de communications électroniques (téléphonie fixe ou mobile) ;
- l’accès aux services de médias audiovisuels, comme la vidéo à la demande par abonnement ;
- les services de transport de voyageurs (aérien, ferroviaire, autocar, métro, tramway, voie navigable) : sites, applications mobiles, billetterie, information en temps réel, bornes ;
- les services bancaires aux consommateurs : crédit, services de paiement, comptes, monnaie électronique ;
- le commerce électronique.
Côté produits, le texte couvre notamment les ordinateurs, smartphones, tablettes, terminaux de paiement, bornes libre-service et liseuses.
Le point décisif est le destinataire : l’EAA protège les consommateurs. Une boutique en ligne grand public, un espace client bancaire ou un tunnel de réservation sont dans le périmètre. Un extranet réservé à des clients professionnels ou un outil interne ne le sont pas, au titre de cette directive.
Les exemptions et périodes de transition
Trois cas permettent d’échapper à tout ou partie des obligations, selon la DGCCRF :
| Situation | Effet | Ce qu’il faut pouvoir montrer |
|---|---|---|
| Microentreprise prestataire de services (moins de 10 salariés, chiffre d’affaires ou total de bilan inférieur à 2 millions d’euros) | Aucune obligation d’accessibilité pour ses services | Les données sociales et financières |
| Mise en conformité qui modifierait fondamentalement la nature du service | Exemption pour l’exigence concernée | Une évaluation documentée |
| Charge disproportionnée pour l’opérateur | Exemption, selon des critères fixés par la réglementation | Une évaluation documentée, à réviser |
| Contrat de service conclu avant le 28 juin 2025 | Il s’applique sans modification jusqu’à son terme | Au plus tard jusqu’au 28 juin 2030 |
Attention au piège de la « charge disproportionnée » : c’est une exception à démontrer, au cas par cas, pas une dispense générale. Le site officiel de la DINUM rappelle d’ailleurs, pour les services soumis à la loi française, que cette dérogation s’invoque fonctionnalité par fonctionnalité et n’exempte pas de publier une déclaration d’accessibilité.
Et les grandes entreprises, même en B2B ?
Indépendamment de l’EAA, l’article 47 de la loi du 11 février 2005 impose l’accessibilité des services de communication au public en ligne aux entreprises dont le chiffre d’affaires moyen réalisé en France dépasse 250 millions d’euros sur les trois derniers exercices. Pour ces ETI et grands groupes, la question « suis-je dans le périmètre de l’EAA ? » est donc secondaire : leurs sites sont concernés dans tous les cas.
Que faut-il concrètement rendre accessible ?
Un service accessible permet à une personne en situation de handicap de le percevoir, de l’utiliser, de le comprendre et de le commander, y compris avec des technologies d’assistance : lecteur d’écran, plage braille, commande vocale, navigation au seul clavier, zoom. La DGCCRF reprend les quatre principes des règles internationales :
- Perceptible : un équivalent textuel pour chaque image utile, des vidéos sous-titrées, des contrastes suffisants, un contenu qui reste lisible quand on l’agrandit.
- Utilisable : toutes les fonctions accessibles au clavier, un ordre de navigation logique, assez de temps pour remplir un formulaire, aucun contenu clignotant dangereux.
- Compréhensible : des pages au comportement prévisible, des libellés explicites, une aide à la correction des erreurs de saisie.
- Robuste : un code propre et standard, compatible avec les technologies d’assistance actuelles et futures.
S’y ajoutent deux obligations souvent oubliées : fournir une information accessible sur l’accessibilité du service lui-même, et des services d’assistance (centre d’appels, support) capables de répondre sur ces sujets par des moyens de communication accessibles.
RGAA, WCAG 2.2, EN 301 549 : quelle référence suivre ?
Trois référentiels coexistent et s’emboîtent :
| Référentiel | Origine | Rôle | Version à connaître |
|---|---|---|---|
| WCAG | W3C, international | Les règles de base pour les contenus web, en trois niveaux (A, AA, AAA) | 2.2, recommandation d’octobre 2023 |
| EN 301 549 | Normalisation européenne | La norme qui donne la présomption de conformité aux exigences européennes, au-delà du seul web | V3.2.1, citée par la DGCCRF |
| RGAA | État français (DINUM) | La méthode d’audit : critères, tests, déclaration d’accessibilité | 4.1.2, une version 5 annoncée pour fin 2026 |
En pratique, une équipe projet travaille avec le niveau AA des WCAG comme objectif de conception et avec le RGAA comme grille de contrôle. Les WCAG 2.2 ont ajouté neuf critères, dont plusieurs changent directement la conception d’une application métier :
- taille minimale des cibles cliquables (2.5.8, niveau AA) : fini les icônes de 12 pixels dans les tableaux de données ;
- alternative aux glisser-déposer (2.5.7, AA) : un planning ou un tableau kanban doit aussi être utilisable sans faire glisser ;
- focus non masqué (2.4.11, AA) : un bandeau collant ou une fenêtre ne doit pas cacher l’élément actif ;
- saisie redondante (3.3.7, A) : ne pas redemander une information déjà fournie dans le même parcours ;
- authentification accessible (3.3.8, AA) : pas de test cognitif imposé pour se connecter, le copier-coller du mot de passe doit fonctionner.
Viser les WCAG 2.2 dès aujourd’hui coûte à peine plus que viser les 2.1 et évite une remise à niveau quand les référentiels de contrôle les intégreront.
Où en sont les sites aujourd’hui ?
Le constat est sévère. L’étude annuelle WebAIM Million, qui analyse automatiquement les pages d’accueil du million de sites les plus visités, relève en 2026 des erreurs WCAG détectables sur 95,9 % d’entre elles. Les plus fréquentes sont aussi les plus simples à corriger :
- textes au contraste insuffisant (83,9 % des pages) ;
- images sans texte alternatif (53,1 %) ;
- champs de formulaire sans étiquette (51 %) ;
- liens vides (46,3 %) et boutons vides (30,6 %).
Deux enseignements pour une PME ou une ETI. D’abord, l’essentiel des défauts vient de quelques composants répétés partout : corriger le bouton, le champ et la carte produit de la bibliothèque d’interface corrige des centaines d’occurrences. Ensuite, un outil automatique ne repère qu’une partie des problèmes ; l’ordre de lecture, la pertinence d’un texte alternatif ou la logique d’un parcours exigent un contrôle humain.
Que risque une entreprise qui ne s’y conforme pas ?
La DGCCRF contrôle les produits et services concernés, en coordination avec l’Arcom, l’Arcep, la Banque de France, l’ACPR et l’AMF selon les secteurs. Les consommateurs peuvent signaler un manquement sur SignalConso. Selon Mon Parcours Handicap, le site d’information de l’État, les manquements exposent à :
- des amendes pouvant atteindre 7 500 € au titre des contraventions de 5e classe ;
- une astreinte de 3 000 € par jour, plafonnée à 300 000 €, pour contraindre à la mise en conformité.
Le risque commercial est plus immédiat que la sanction. Un tunnel de commande inutilisable au clavier ou avec un lecteur d’écran fait perdre des ventes, et l’accessibilité figure de plus en plus souvent dans les cahiers des charges des grands comptes et des acheteurs publics. Elle profite enfin à tous : contrastes lisibles en extérieur, formulaires clairs, navigation rapide au clavier pour les utilisateurs intensifs.
Comment intégrer l’accessibilité dans un projet d’application ?
L’accessibilité se traite comme la sécurité : elle coûte peu quand elle est prévue, cher quand elle est rattrapée. Voici comment nous l’intégrons à chaque étape d’un projet d’application web sur mesure.
Au cadrage
- Identifier si le service entre dans le périmètre de l’EAA ou de l’article 47, et fixer la cible (WCAG 2.2 niveau AA dans la plupart des cas).
- Inscrire l’exigence dans le cahier des charges, avec la grille de contrôle retenue ; notre modèle de cahier des charges prévoit une rubrique dédiée.
- Repérer les parcours critiques : inscription, connexion, commande, paiement, contact.
En conception
- Choisir une palette dont les contrastes sont vérifiés dès la charte, pas après.
- Prévoir des alternatives aux interactions complexes (glisser-déposer, graphiques, cartes).
- Rédiger des libellés et des messages d’erreur explicites ; c’est aussi un sujet d’ergonomie des applications métier.
En développement
- Construire une bibliothèque de composants accessibles une fois pour toutes : boutons, champs, fenêtres modales, tableaux, menus.
- Utiliser le HTML standard plutôt que des éléments réinventés, et réserver les attributs ARIA aux cas où le HTML ne suffit pas.
- Ajouter des tests automatiques d’accessibilité dans la chaîne d’intégration, pour bloquer les régressions.
En recette et après la mise en production
- Tester les parcours critiques au clavier et avec un lecteur d’écran, en plus des outils automatiques ; c’est une ligne à part entière du cahier de recette.
- Faire réaliser un audit RGAA sur un échantillon de pages, publier la déclaration d’accessibilité et un moyen de contact pour signaler un défaut.
- Maintenir le niveau dans le temps : chaque nouvelle fonctionnalité passe les mêmes contrôles.
Par où commencer si votre service est déjà en ligne ?
Pour une application existante, la démarche la plus efficace tient en cinq étapes :
- Qualifier le périmètre : quels services sont destinés aux consommateurs, quelle est votre taille, quels contrats sont antérieurs au 28 juin 2025.
- Auditer un échantillon représentatif : un exemplaire de chaque gabarit de page et les parcours critiques, plutôt que tout le site.
- Prioriser par impact : un défaut bloquant sur le paiement passe avant un contraste imparfait sur une page d’archives.
- Corriger à la source : les composants partagés et les gabarits d’abord, les contenus ensuite (textes alternatifs, titres, documents téléchargeables).
- Documenter : déclaration d’accessibilité, évaluation écrite en cas de charge disproportionnée invoquée, plan de mise en conformité daté.
Si l’audit révèle une interface trop ancienne pour être corrigée raisonnablement, la question devient celle d’une modernisation progressive, parcours par parcours, plutôt que d’une refonte d’un bloc.
Vous lancez une application ou un portail client et vous voulez l’accessibilité intégrée dès le départ, ou vous devez évaluer un service existant ? Décrivez votre situation dans notre diagnostic de projet : nous revenons vers vous avec une première analyse du périmètre et des priorités.
