Accessibilité RGAA/EAA : mettre votre site aux normes sans tout refaire

Depuis le 28 juin 2025, l'European Accessibility Act (EAA) a changé la donne pour toutes les entreprises qui vendent des produits ou services numériques dans l'Union européenne. En France, cette directive s'est traduite par un élargissement du RGAA (Référentiel Général d'Amélioration de l'Accessibilité) : en 2026, il ne concerne plus seulement les administrations, mais aussi une grande partie des PME. Pour beaucoup de dirigeants, la question n'est plus "faut-il s'y conformer ?" mais "comment le faire sans repartir de zéro sur mon site ou mon application ?".

Qui est concerné, et pourquoi ce n'est plus théorique

Le seuil est désormais clair pour les entreprises privées : les entreprises privées de plus de 10 salariés ou avec un chiffre d'affaires supérieur à 2 millions d'euros sont concernées par l'obligation d'accessibilité numérique. Sites e-commerce, espaces clients, services bancaires en ligne et plateformes de réservation sont explicitement visés.

Ce n'est plus une menace lointaine : l'enforcement de l'EAA a démarré le 28 juin 2025, et les premières poursuites en France ont été déposées en novembre 2025. Les sanctions ne sont pas symboliques : les amendes varient selon les pays, d'environ 60 000 € en Irlande à près de 900 000 € en Suède, tandis qu'en France, les sanctions financières atteignent jusqu'à 50 000 € par service non conforme, renouvelables. Au-delà de l'amende, les autorités peuvent aussi exiger un audit obligatoire ou retirer un service du marché — un risque opérationnel bien réel pour un site marchand.

Ce que "accessible" veut dire concrètement dans le code

La bonne nouvelle : la mise en conformité ne signifie presque jamais une refonte totale. La référence technique, le RGAA 4.1.2, est alignée sur les WCAG 2.1 niveau AA, un standard international bien documenté. Dans la majorité des cas, le travail porte sur des points précis et localisés :

• HTML sémantique : remplacer les balises génériques (div, span) par des balises porteuses de sens (nav, main, button) pour que les lecteurs d'écran comprennent la structure de la page.
• Navigation clavier : s'assurer que chaque action (menu, formulaire, panier) reste utilisable sans souris, avec un ordre de tabulation logique.
• Contrastes et tailles de police : corriger les couleurs de texte/fond qui ne respectent pas les ratios minimums.
• Attributs ARIA et alternatives textuelles : décrire les images, icônes et éléments interactifs pour les technologies d'assistance.
• Formulaires accessibles : labels explicites, messages d'erreur clairs et associés au bon champ.

Ces correctifs se font le plus souvent module par module, sans toucher à l'architecture globale de l'application.

Par où commencer : l'audit avant tout chantier

Avant de coder quoi que ce soit, un audit technique permet de prioriser : quelles pages sont critiques pour vos clients, quels blocages sont les plus fréquents, quels correctifs sont rapides à déployer. C'est le même principe qu'un audit de performance ou de sécurité : on cartographie, on priorise, puis on corrige par lots. Pour un site ou une application construite sur mesure, cet audit s'intègre naturellement à une démarche de développement web sur mesure, où chaque composant peut être revu indépendamment sans casser le reste du parcours utilisateur.

Des cas différents selon votre outil

Boutique en ligne WooCommerce

Sur une boutique WooCommerce, les points de friction classiques sont le tunnel de commande, les filtres produits en JavaScript et les pop-ups de panier. Certains thèmes et extensions du marché ne respectent pas nativement les standards ARIA ; un travail sur les plugins WooCommerce personnalisés permet souvent de corriger ces points précis sans changer de plateforme.

Application mobile ou PWA

Sur une application mobile (PWA), l'accessibilité passe aussi par le respect des tailles de zones cliquables, la compatibilité avec VoiceOver/TalkBack et la gestion du zoom sans casser la mise en page — des critères souvent oubliés lors du développement initial.

Outils internes (ERP, back-office)

Les interfaces internes ne sont pas toujours exemptées : si des salariés en situation de handicap utilisent votre module Dolibarr ou votre back-office métier, l'accessibilité devient aussi un sujet RH et légal, pas seulement une contrainte client.

Automatiser le contrôle plutôt que le refaire à chaque mise à jour

L'accessibilité n'est pas un projet ponctuel : chaque nouvelle fonctionnalité peut réintroduire un défaut. La solution la plus pérenne consiste à intégrer des contrôles automatisés (tests d'accessibilité type axe-core ou Lighthouse) directement dans votre chaîne de déploiement, au même titre que les tests de sécurité ou de performance. C'est un cas d'usage typique de l'automatisation des tâches techniques : un contrôle qui tourne à chaque mise en production et qui alerte avant que le problème n'atteigne vos utilisateurs.

En résumé

Le RGAA élargi et l'EAA ne sont plus des sujets théoriques : les premiers contrôles et sanctions sont déjà là. La bonne approche reste la même que pour tout chantier technique sérieux : auditer avant d'agir, corriger par priorité, et automatiser le contrôle plutôt que de tout refaire à chaque mise à jour. Si vous voulez évaluer où en est votre site ou votre application sur ces critères, contactez notre équipe pour un point de départ concret.

Questions fréquentes