Les limites d'un audit RGAA
La conformité légale ne garantit pas l'accessibilité réelle
L’audit basé sur le Référentiel général d’amélioration de l’accessibilité (RGAA) présente de nombreuses limites. Cette méthodologie incontournable pour mesurer et attester de l’accessibilité des services numériques du service public, des structures délégataires d’une mission de service public et des grandes entreprises (seuil de chiffre d’affaires en France), offre en effet une vision biaisée et rapidement obsolète de l’accessibilité réelle d’un site.
Entre représentativité de l’échantillonnage, surreprésentation de certains critères, absence de pondération et distorsions statistiques, le résultat de votre audit ne reflète ainsi qu’imparfaitement l’expérience vécue par les utilisateurs en situation de handicap.
Le choix de l’échantillon : l’illusion d’une représentativité absolue
Le protocole du RGAA prescrit d’auditer un échantillon restreint de pages :
- Les pages obligatoires (accueil, contact, mentions légales, déclaration d’accessibilité, plan du site, etc.) ;
- Les pages représentatives des principaux services fournis, les étapes complètes d’un processus et au moins 10 % de pages tirées au sort.
En pratique, sur des portails qui comptent des centaines ou des milliers d’URL, l’auditeur va se limiter à un échantillon compris entre 10 et 20 pages.
Un site web peut obtenir un excellent score sur l’échantillon, voire une conformité totale, mais ce score peut chuter si d’autres URL sont intégrés dans l’audit : l’ajout d’une seule page avec un tableau de données complexe non accessible peut ainsi faire passer jusqu’à 6 critères en non conformité.
Un environnement de test parfois considéré comme peu représentatif
L’échantillon n’est pas le seul paramètre considéré peu représentatif : l’environnement de test peut aussi être considéré comme l’une des limites du RGAA 4.1.2.
Le navigateur retenu pour l’utilisateur d’un ordinateur Windows est Mozilla Firefox. Or, ce dernier possède des parts de marché réduites par rapport à Chrome, non testé dans la version actuelle du référentiel. Un composant correctement restitué par un lecteur d’écran sous Firefox peut en effet se comporter différemment sous Chrome (et vice versa). Le résultat de l’audit ne reflète alors pas forcément l’expérience de la majorité des utilisateurs.
Quelles sont les pages de l'échantillon obligatoire ?
Sept pages doivent absolument être intégrées à l’échantillon :
- Page d’accueil ;
- Page contact ;
- Page mentions légales ;
- Page comprenant la déclaration d’accessibilité ;
- Page plan du site ;
- Page d’aide ;
- Page d’authentification.
Pourquoi ne pas auditer l'ensemble des pages d'un site ?
L’audit RGAA d’une page prend du temps et ne peut pas être automatiser. Certains processus et le contrôle de la restitution du contenu par les technologies d’assistance (les lecteurs d’écran intégrés à l’environnement de texte) demandent des interventions manuelles chronophages.
La détermination d’un échantillon est la seule méthode possible pour auditer un site.
106 critères, mais un calcul qui porte sur les seuls critères applicables
Le référentiel actuel (RGAA 4.1.2) comporte 106 critères de contrôle répartis en 13 thématiques techniques (images, tableaux, formulaires, navigation, scripts…)
Contrairement à une idée répandue, la note finale est calculée uniquement sur le nombre de critères applicables rencontrés au sein de l’échantillon : taux de conformité = (nombre de critères validés / nombre de critères applicables) × 100.
Si un site ne comporte par exemple aucun composant multimédia et aucun tableau, l’intégralité des critères associés à ces thématiques est déclarée « non applicable » et sort de la formule de calcul. Un site vitrine épuré peut ainsi être évalué sur 40 critères applicables, tandis qu’un portail transactionnel complexe en mobilisera 85, 95, voire 100.
Cette approche est logique : un site ne va pas intégrer des fonctionnalités inutiles uniquement pour être audité sur les 106 critères. Mais ce mode de calcul peut entraîner des effets de bord méthodologiques, car le score dépend parfois davantage de la variété des fonctionnalités évaluées présentes dans l’échantillon que du soin réel apporté à l’ergonomie.
Une prise en compte limitée des handicaps cognitifs
Le RGAA 4.1.2 est calqué sur les critères de succès des niveaux A et AA des normes internationales WCAG 2.1.
Ces exigences ont été historiquement conçues pour lever les barrières sensorielles (cécité, malvoyance, surdité) et motrices (impossibilité d’utiliser la souris). Mais le référentiel général d’amélioration de l’accessibilité reste limité quand il s’agit d’évaluer les difficultés liées aux handicaps cognitifs, intellectuels ou psychiques. S’il prévoit quelques éléments dans le contrôle de saisie des formulaires (critères 11.10 et 11.11), il passe à côté d’autres facteurs :
- Aucune exigence éditoriale, comme la prise en compte de la méthode FALC ;
- Pas de limitation de la charge mentale face à des arborescences de navigation surchargées d’options.
Une interface peut ainsi respecter à la lettre l’intégralité des 106 critères du référentiel tout en demeurant anxiogène et difficilement utilisable pour un large pan d’utilisateurs, personnes en situation de handicap ou peu à l’aise avec la technologie, tels que les seniors.
L'absence de pondération entre critères bloquants et non bloquants
Dans le calcul officiel du RGAA 4.1.2, tous les critères se valent : chacun pèse exactement une unité dans le décompte des critères validés ou invalidés. Cette absence de pondération met sur le même plan arithmétique :
- Une image décorative non ignorée par les technologies d’assistance : la description comprise dans l’attribut alt=”” (par exemple, alt=”Image d’une infirmière soignant un senior”) perturbe l’utilisateur d’un lecteur d’écran, mais ne l’empêche à priori pas d’utiliser le site ;
- Une citation courte sans balise <q> (critère 9.4) : intégrer une citation entre simples guillemets typographiques au sein d’un paragraphe sans utiliser la balise HTML dédiée ne pose pas de réel blocage pour l’utilisateur ;
- Un piège au clavier (critère 12.9) : c’est une anomalie bloquante, car l’utilisateur qui navigue au clavier ne peut plus interagir avec le reste de la page.
Chacune de ces trois erreurs retire exactement un point au compteur, alors que dans les faits, seule la troisième erreur est réellement bloquante. Le score chiffré ne reflète donc en rien la sévérité d’impact sur l’utilisateur, regroupant potentiellement sous un même pourcentage des sites simplement imparfaits dans leur code et des sites totalement inadaptés à une personne handicapée.
Pour qu’un critère soit déclaré conforme au niveau du site, il doit être rigoureusement validé sur 100 % des pages de l’échantillon. Si un composant échoue sur une seule page parmi vingt, l’ensemble du critère bascule en non-conformité pour tout l’audit.
Ce principe binaire engendre un effet pervers pour les équipes de développement : un site ayant corrigé 99 % de ses images sans texte alternatif aura exactement la même note (critère 1.1 invalidé) qu’un site n’ayant fait aucun effort et dont la totalité des images est muette. Cette stratégie du tout ou rien est une autre limite majeure du RGAA.
Le critère 7.1 : l’entonnoir des blocages réels
Ce critère est , à mon avis, l’une des plus grandes limites actuelles du RGAA.
Dans le RGAA, le critère 7.1 (« Chaque script est-il, si nécessaire, compatible avec les technologies d’assistance ? ») supporte à lui seul une charge fonctionnelle disproportionnée.
Tandis que des dizaines de critères se consacrent à des vérifications HTML/CSS statiques (contrastes, niveaux de titres, balises sémantiques), le critère 7.1 analyse à lui seul tous les composants dynamiques riches : fenêtres modales, carrousels, filtres asynchrones, menus déroulants et boutons d’action générés en JavaScript. En regroupant dans un seul critère la restitution du nom, du rôle, de la valeur, du paramétrage et des changements d’états WAI-ARIA, le référentiel relègue au statut d’anomalie unique des défaillances qui paralysent des parcours entiers.
Astuces et tutoriels sur l'accessibilité Web
L'audit RGAA : une photographie du site rapidement obsolète
L’audit de conformité capture une photographie technique figée à un instant t. Dès le lendemain de la livraison du rapport, la vie éditoriale du site reprend son cours.
Un contributeur intégrant une infographie sans description textuelle, un tableau sans en-têtes, important un document PDF non balisé ou sélectionnant une couleur de texte peu contrastée dans l’éditeur de texte riche, invalide immédiatement plusieurs critères sur les pages concernées. Sans gouvernance éditoriale continue ni solution de contrôle automatisé au moment de la publication, le score issu de l’audit perd sa validité en quelques semaines.
Par ailleurs, un CMS est régulièrement mis à jour. Ces évolutions ne sont pas considérées comme des refontes, mais sont susceptibles de remettre en question l’accessibilité de certains composants.
Combien de temps un audit RGAA est-il valable ?
Un audit RGAA est valable en principe 3 ans. Il doit être mis à jour dans deux cas :
- Dès lors qu’une modification substantielle ou une refonte du site a lieu ;
- 18 mois au plus tard après la publication d’une nouvelle version du référentiel, pour les organismes appliquant la méthode technique.
Cas pratique n°1 : un site e-commerce conforme à 95 %... mais totalement inexploitable
Considérons une boutique en ligne auditée selon le RGAA :
- Le résultat chiffré : sur 70 critères applicables, le site en valide 67. Le calcul affiche 95,7 % de conformité, classant le site comme plutôt accessible (le seuil de « conformité totale » étant à 100 % et celui de « conformité partielle » à 50 %).
- L’anomalie résiduelle : l’un des rares échecs concerne le critère 7.1. Le bouton « Ajouter au panier » de la fiche produit repose sur une balise <div> stylée en JavaScript, dépourvue de rôle button, non atteignable au clavier et muette pour les API d’accessibilité.
L’impact utilisateur porté par la non conformité du critère 7.1 est énorme : pour une personne naviguant à l’aide d’un lecteur d’écran (NVDA, JAWS, VoiceOver) ou exclusivement au clavier, il est impossible de commander un article. Le site peut légalement revendiquer un taux d’accessibilité élevé dans sa déclaration publique, alors que sa fonction métier première est bloquée pour les personnes handicapées.
Cas pratique 2 : optimiser son score sans lever le moindre frein d'usage
Le mode de calcul basé sur les critères applicables ouvre la porte à des optimisations comptables déconnectées de tout bénéfice utilisateur :
- Situation de départ : Un site audité totalise 24 critères validés sur 49 critères applicables, soit 48,9 %. Ne franchissant pas le seuil légal des 50 %, il est contraint d’afficher sur sa page d’accueil la mention dévalorisante : « Accessibilité : non conforme ». Ce site ne contient aucun tableau de données.
- L’astuce technique : Avant de publier l’audit, l’équipe ajoute dans l’une des pages de l’échantillon un simple tableau de données parfaitement balisé avec balises <table>, <caption>, <th> et attributs scope conformes (critères 5.4, 5.5, 5.6 et 5.7 validés).
- La bascule : Ces 4 critères de la thématique « Tableaux », jusque-là non applicables, deviennent applicables et validés à 100 %. Le ratio passe immédiatement à 28 validés sur 53 applicables, soit 52,8 %.
Sans avoir corrigé un seul des problèmes initiaux d’accessibilité, le site franchit le seuil fatidique et obtient légalement le statut « Accessibilité : partiellement conforme ».
Compléter un audit RGAA par des tests utilisateurs
La DINUM (Direction interministérielle du numérique), organisme chargé d’éditer, de faire évoluer et de publier le RGAA, fournit un référentiel destiné à aider les éditeurs de site à évaluer l’accessibilité de leur site web. Mais derrière cette notion se cachent des réalités et des besoins concrets, avec des personnes en situation de handicap pour qui l’inclusivité numérique se traduit par une plus grande autonomie et une meilleure intégration sociale et professionnelle.
Le RGAA présente de réelles limites, mais il ne doit pas être perçu comme une fois en soi. C’est un jalon sur la voie d’une accessibilité plus complète de vos services web.
Audit RGAA et tests utilisateurs, loin de s’opposer, offrent dans les faits deux visions complémentaires :
- L’audit RGAA mesure la conformité légale d’un site par rapport à un référentiel, et vous permet de respecter la législation en vigueur ;
- Les tests utilisateurs mesurent la capacité réelle d’une personne en situation de handicap à accomplir une tâche donnée, et se situent à un niveau plus opérationnel.
Voici des éléments révélés par les tests utilisateurs révèlent et que l’audit ne voit pas :
- La sévérité réelle des anomalies : un critère non conforme peut être anecdotique ou bloquer tout un parcours, ce qu’un test montre immédiatement.
- Les difficultés cognitives non évaluées par le RGAA : charge mentale, navigation surchargée, consignes peu claires, etc. ;
- Les combinaisons réelles d’usage : lecteur d’écran avec un navigateur Chrome ou navigation au clavier sur mobile, les configurations des utilisateurs dépassent souvent l’environnement de test de l’audit.
- Les pages hors échantillon : un test centré sur un parcours complet passe par des pages que l’échantillon de l’audit n’a pas retenues.
La publication du RGAA 5, annoncée pour fin 2026, pourrait apporter une analyse plus centrée sur les usages et atténuer certaines limites de la version actuelle du référentiel.
Les 13 thématiques du référentiel RGAA
Répondez à vos obligations légales en réalisant un audit RGAA, et offrez à tous vos prospects et clients un site web accessible.