L’accessibilité numérique est devenue une obligation légale, mais aussi un enjeu de qualité.
Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) fixe le cadre pour rendre les sites web utilisables par tous : personnes en situation de handicap, seniors, utilisateurs de lecteurs d’écran ou d’interfaces vocales.
Derrière cette exigence, il y a aussi un objectif de bon sens : rendre les contenus plus clairs, les formulaires plus logiques, et la navigation plus cohérente.
C’est une démarche bénéfique à la fois pour les utilisateurs, le référencement, et la qualité globale du code.
1. Le RGAA en bref
Le RGAA est la déclinaison française des normes internationales WCAG 2.1 (Web Content Accessibility Guidelines) et de la norme européenne EN 301 549.
Il comprend 13 thématiques, 106 critères de contrôle, et environ 300 tests permettant de mesurer la conformité d’un site.
Trois niveaux de conformité existent :
- A : exigences essentielles,
- AA : niveau légal obligatoire,
- AAA : niveau optimal, rarement atteint.
Les documents officiels sont publics et disponibles sur le site du gouvernement français. Ils définissent les méthodes de test, les critères de réussite et les obligations de déclaration.
2. Comment se déroule un audit RGAA
Un audit RGAA se déroule en plusieurs étapes précises :
- Définition du périmètre : choix des pages et gabarits représentatifs (accueil, page de contenu, article, contact, etc.).
- Sélection des échantillons : environ 8 à 10 pages pour un site classique.
- Vérifications automatiques et manuelles : lecture du code, tests clavier, lecteurs d’écran, contrastes, structure HTML.
- Analyse et synthèse : notation, priorisation, rapport détaillé.
- Plan d’action : mise en conformité progressive et publication de la déclaration d’accessibilité.
Chaque critère est vérifié selon une grille stricte : par exemple, la présence de titres hiérarchiques corrects, d’étiquettes de formulaire, ou d’alternatives textuelles aux images.
3. Pourquoi c’est long
L’audit RGAA est un travail minutieux.
Certains points sont simples à détecter automatiquement, mais la plupart exigent une revue manuelle du code et de la restitution réelle par les technologies d’assistance.
Les causes de lenteur principales :
- grand nombre de critères à vérifier (106) ;
- besoin de tester plusieurs navigateurs, résolutions et lecteurs d’écran ;
- documentation de chaque non-conformité ;
- complexité du code généré par les CMS (WordPress, Drupal, etc.).
En pratique, un audit complet sur un site vitrine demande entre une et deux semaines selon la taille et la variété des contenus.
4. Les erreurs les plus fréquentes
Voici les points qui reviennent presque systématiquement dans les audits RGAA :
- Mauvaise hiérarchie des titres <h1> à <h6>.
- Liens non explicites (“cliquez ici”, “en savoir plus”).
- Images sans attribut alt pertinent.
- Champs de formulaire sans label associé.
- Contrastes texte/fond insuffisants.
- Focus clavier invisible ou absent.
- PDF non accessibles (absence de structure, texte non sélectionnable).
Corriger ces points simples permet déjà d’améliorer significativement le score global.
5. WordPress et FSE : leviers et limites
WordPress a beaucoup progressé depuis le passage au Full Site Editing (FSE).
La structure HTML générée par les blocs est plus propre : les balises <header>, <main>, <footer> ou <nav> sont intégrées nativement, ce qui favorise une meilleure sémantique.
Mais certaines limites subsistent :
- les constructeurs tiers ajoutent souvent des couches de HTML inutiles ou mal structurées ;
- les composants dynamiques (menus, carrousels, formulaires) sont rarement accessibles sans adaptation manuelle ;
- et les thèmes hérités de versions anciennes peuvent contenir des incohérences ARIA.
Les bons réflexes :
- vérifier le code HTML produit ;
- soigner les attributs aria-label et aria-expanded ;
- garder un focus clavier visible ;
- privilégier les composants natifs de WordPress plutôt que les blocs externes non testés.
Les outils d’analyse comme Wave, axe DevTools, Lighthouse, ou Accessibility Checker for WP facilitent la détection rapide des erreurs.
6. L’approche développeur (réaliste et progressive)
La mise en conformité d’un site passe avant tout par une bonne base de code.
Mon approche, côté développement :
- intégrer l’accessibilité dès la conception d’un site WordPress, plutôt que d’ajouter des correctifs a posteriori ;
- utiliser des scripts automatiques d’audit pour repérer les points bloquants, puis compléter par une vérification manuelle ;
- corriger directement dans le code source, plutôt qu’en empilant des rustines ARIA ;
- documenter les choix (balises, rôles, comportement au clavier) pour assurer la cohérence dans le temps.
L’objectif à moyen terme : tendre vers des thèmes WordPress accessibles par défaut, exploitant les progrès du FSE et les futures mises à jour du core.
7. Évaluer la durée et le périmètre d’un audit
Pour un site WordPress standard (pages, articles, événements, références, formulaire de contact) :
- Audit complet : 1 à 2 jours.
- Rédaction du rapport : 1 journée.
- Corrections et tests de validation : 2 à 5 jours.
Soit environ une à deux semaines pour atteindre un premier niveau de conformité mesurable.
L’important n’est pas de viser 100 % dès le départ, mais de structurer une progression : corriger les erreurs majeures, publier la déclaration, puis planifier les optimisations.
8. Qui est concerné et quand ?
Les structures déjà concernées
- Les administrations, collectivités et établissements publics.
- Les entreprises ou associations exerçant une mission de service public.
- Les structures privées de plus de 250 millions d’euros de chiffre d’affaires.
Vers une généralisation
L’European Accessibility Act prévoit une extension des obligations à l’horizon 2027–2028.
Les entreprises privées et sites e-commerce seront alors concernés, avec une application progressive à tous les services numériques grand public.
Déclaration obligatoire, même sans conformité totale
Le respect de la loi impose au minimum la publication d’une déclaration d’accessibilité, même si le site n’est pas encore conforme.
Cette déclaration doit préciser :
- le taux de conformité (ex. : 55 %, 70 %, etc.) ;
- les non-conformités identifiées ;
- et un plan d’action pour les corriger progressivement.
L’objectif n’est pas d’être parfait, mais de montrer une démarche active.
Un site non conforme mais engagé dans une amélioration documentée respecte déjà partiellement ses obligations.
Corrections progressives et seuils réalistes
Quelques corrections simples (titres structurés, liens explicites, attributs alt, contrastes) peuvent augmenter sensiblement le taux de conformité.
D’autres points, plus lourds (formulaires, scripts, navigation clavier), nécessitent plus de temps.
Dans les faits :
- atteindre 70 % est déjà un bon niveau,
- peu de sites dépassent 85 %,
- certaines limites viennent du code HTML généré par WordPress, qui s’améliore au fil des versions.
La bonne approche
Le plus efficace est de viser un pourcentage “acceptable” (75 – 85 %) et de programmer les corrections sur plusieurs mois.
Cette démarche progressive est valorisée par l’administration : elle prouve une volonté de mise en conformité et un suivi régulier des améliorations.
9. En conclusion
L’accessibilité n’est pas une case à cocher, c’est une démarche continue.
Un site peut rarement être “100 % conforme”, mais il peut être plus utilisable, plus clair et plus équitable.
L’objectif n’est pas seulement de respecter la loi, mais de créer une expérience inclusive pour tous les visiteurs.
Et sur le plan technique, c’est aussi un excellent indicateur de qualité de code et de rigueur de développement.
Sources officielles
Besoin d’un accompagnement pour votre mise en conformité RGAA ?
Je peux auditer votre site, corriger les points techniques dans le code, et vous aider à publier une déclaration d’accessibilité conforme.
