Accessibilité numérique : l’échéance européenne est passée, et maintenant ?

Pendant quinze ans, l’accessibilité numérique a été perçue comme une affaire de secteur public. La directive européenne 2019/882, dite European Accessibility Act, a déplacé la ligne : depuis le 28 juin 2025, un large ensemble de services numériques du secteur privé entre dans le périmètre. Un an plus tard, le sujet n’est plus « faut-il s’y mettre ? » mais « par où reprendre un produit qui n’a jamais été conçu pour ça ».

Qui est concerné, concrètement

Le texte vise les produits et services listés par la directive, transposée en droit français. En pratique, dans nos audits, ce sont surtout ces catégories qui découvrent l’obligation :

• Le commerce en ligne : sites et applications de vente aux consommateurs, du tunnel de commande au suivi de livraison.
• Les services bancaires aux particuliers, y compris les parcours d’ouverture de compte et les applications mobiles.
• Le transport de voyageurs : achat de titres, information voyageur, bornes en libre-service.
• Les communications électroniques et les services d’accès aux médias audiovisuels.
• Les livres numériques et les plateformes qui les diffusent.

Pour le secteur public, rien de nouveau sur le principe : l’obligation existe depuis la loi de 2005 et le RGAA en est le référentiel d’application. Ce qui change, c’est l’effet d’entraînement — les mêmes exigences techniques deviennent la norme de fait pour les prestataires qui travaillent des deux côtés.

RGAA, WCAG, EN 301 549 : trois noms, un même socle

La confusion est fréquente et coûte du temps en réunion. Les trois référentiels sont emboîtés, pas concurrents.

Autrement dit : on conçoit avec les WCAG en tête, on prouve avec la méthode de test du RGAA. Une équipe qui maîtrise l’un ne repart pas de zéro sur l’autre.

Les cinq défauts que l’on retrouve partout

D’un audit à l’autre, les mêmes causes reviennent — et elles sont presque toutes évitables au moment de la conception, pas de la recette.

1. 01

   Le HTML détourné

   Des <div> rendues cliquables au lieu de boutons, des titres choisis pour leur taille de police. Le lecteur d’écran annonce une page sans structure, et la navigation au clavier ne trouve rien.

2. 02

   Le focus clavier invisible

   Le contour de focus a été retiré par une règle CSS globale pour des raisons esthétiques. Un utilisateur au clavier ne sait plus où il se trouve dans la page.

3. 03

   L’information portée par la seule couleur

   Un champ en rouge pour signaler une erreur, sans message texte associé. L’information disparaît pour une partie des utilisateurs.

4. 04

   Les images et icônes non décrites

   Alternatives vides sur des images porteuses de sens, ou à l’inverse des alternatives verbeuses sur des éléments purement décoratifs.

5. 05

   Les composants « maison »

   Modales, menus déroulants et onglets recodés sans gestion du focus ni attributs ARIA. C’est le poste de correction le plus lourd, systématiquement.

Par où commencer sur un produit existant

Reprendre un site entier d’un coup est le meilleur moyen de ne rien livrer. La séquence qui fonctionne est plus modeste, et se mesure.

1. 1Identifiez les parcours critiques, pas les pages. Créer un compte, acheter, contacter le support : trois parcours valent mieux que deux cents pages.
2. 2Traversez-les au clavier seul, sans souris. Une demi-journée suffit à révéler l’essentiel des blocages, et l’exercice est parlant pour une direction.
3. 3Corrigez d’abord la structure HTML. Beaucoup de défauts apparents disparaissent une fois les vrais boutons, titres et libellés en place.
4. 4Intégrez les critères au Definition of Done de l’équipe. Sans cela, chaque sprint reconstitue la dette corrigée au précédent.
5. 5Faites auditer et publiez la déclaration de conformité une fois le socle assaini, pas avant.

« Le coût d’une correction d’accessibilité après mise en production est sans commune mesure avec celui d’un choix de conception fait au bon moment. La contrainte n’est pas technique, elle est calendaire. »

L’effet de bord : ça profite à tout le monde

Une structure HTML correcte est mieux comprise par les moteurs de recherche. Des contrastes suffisants servent la lecture en plein soleil sur mobile. Des formulaires correctement libellés réduisent les erreurs de saisie et les appels au support. L’accessibilité ne se justifie pas seulement par la conformité : elle recoupe largement la qualité technique d’un produit.