Atteindre la conformité RGAA ressemble souvent à une quête obscure remplie d’acronymes, de checklists interminables et de tableaux Excel qui font peur. Pourtant, derrière le jargon, il s’agit surtout d’une mécanique claire : comprendre le référentiel général d’accessibilité, choisir une méthode de test solide, auditer un échantillon représentatif, calculer un taux de conformité et publier une déclaration transparente.
En pratique, ce sont des choix quotidiens de design et de code qui décident si une personne utilisant un lecteur d’écran, un clavier ou une loupe logicielle peut réellement utiliser ton service. L’accessibilité numérique n’est plus un « plus », c’est une exigence légale assortie de sanctions, mais aussi une attente forte des utilisateurs qui en ont marre de se cogner à des formulaires impossibles ou à des menus inaccessibles.
Dans beaucoup d’organisations, on voit encore l’audit RGAA comme une formalité administrative à cocher pour être tranquille. Mauvais pari. Le jour où un usager bloque sur une démarche en ligne essentielle, ce n’est pas un pourcentage de conformité abstrait qui remonte, c’est un signal d’alarme très concret. Les équipes qui s’en sortent le mieux sont celles qui traitent le test RGAA comme un outil de pilotage continu, pas comme un examen final.
Elles mixent outils automatiques, vérifications manuelles et retours d’utilisateurs réels pour transformer les normes obligatoires en règles de conception durables. Résultat : moins de bugs, moins de tickets de support, plus de confiance. Ce texte décortique justement cette mécanique : comment choisir ton échantillon, définir ton environnement de test, interpréter ton taux de conformité, organiser ta mise en conformité dans le temps et éviter les erreurs classiques qui font dérailler un projet.
En bref
- L’accessibilité web n’est pas qu’un sujet légal : c’est une expérience utilisateur et un enjeu de réputation.
- La conformité RGAA repose sur un audit structuré : échantillon représentatif, environnement de test défini, critères appliqués avec rigueur.
- Les outils de test RGAA couvrent une partie seulement des 106 critères : la vérification humaine reste indispensable.
- Le taux de conformité doit servir à prioriser les correctifs plutôt qu’à produire un joli chiffre pour un rapport.
- Une bonne mise en conformité s’appuie sur une feuille de route, de la formation et des contrôles réguliers, pas sur une refonte totale subie.
Conformité RGAA et accessibilité numérique : ce que recouvrent vraiment les « normes obligatoires »
Quand une entité parle de conformité RGAA, elle fait référence à une chose précise : le respect d’un ensemble de critères inspirés des WCAG, formalisés dans le référentiel général d’accessibilité, et rendus obligatoires par des textes comme le décret de 2019 sur l’accessibilité numérique des services publics.
On est loin d’une simple recommandation. Pour les organismes concernés, il existe une obligation de vérifier et de publier le niveau de conformité de leurs sites, intranets, extranets ou applications.
Sur le terrain, tout cela se matérialise par 106 critères, eux-mêmes décomposés en tests techniques. Certains sont très concrets, par exemple l’usage d’un texte alternatif pertinent pour les images porteuses d’information. D’autres touchent aux interactions, comme la navigation au clavier ou les retours visuels de focus. C’est cette granularité qui permet une validation conformité argumentée, page par page, fonctionnalité par fonctionnalité.
Une erreur fréquente consiste à réduire l’accessibilité web à une poignée de correctifs sur le contraste ou la taille du texte. En pratique, l’audit RGAA met en lumière des aspects bien plus structurels : architecture des gabarits, cohérence des composants, logique de navigation, gestion des messages d’erreur dans les formulaires. Un site peut avoir des couleurs impeccables tout en étant inutilisable au clavier ou incompréhensible pour un lecteur d’écran. Dans ce cas, parler de mise en conformité sur la base de quelques ajustements superficiels reste trompeur.
Autre point souvent mal compris : la loi ne demande pas la perfection, mais une démarche rigoureuse. Ce qui est attendu, c’est une méthode claire de test RGAA, une transparence sur les éléments dérogés (charge disproportionnée, par exemple pour certains documents complexes) et l’affichage d’une trajectoire d’amélioration. Miser uniquement sur un audit ponctuel sans rien changer à la façon de concevoir et de maintenir le service, c’est repousser le problème à plus tard.
Un cas typique : une collectivité met en ligne un nouveau portail. Elle commande un audit, obtient un taux de conformité correct, publie sa déclaration… puis enchaîne les évolutions sans aucun contrôle. Deux ans plus tard, l’accessibilité réelle du site n’a plus grand-chose à voir avec le rapport initial. Les composants ont changé, des modules externes ont été ajoutés, de nouveaux contenus ont été intégrés sans balisage correct. La validation conformité devient alors une illusion. Moralité : traiter le RGAA comme un processus continu plutôt qu’un sprint isolé change totalement la donne.
Pour résumer cette première partie, les normes obligatoires ne se limitent pas à cocher une feuille Excel ; elles cherchent à garantir que chaque personne, quelle que soit sa situation de handicap, puisse réellement accomplir ses démarches. Une fois que cette vision est claire, l’audit RGAA prend une dimension beaucoup plus concrète et moins administrative.
Audit RGAA pas à pas : échantillon, représentativité et pièges classiques
La première décision structurante d’un audit RGAA, c’est le choix de l’échantillon. Ce n’est pas un détail, car tout le calcul du taux de conformité découle de ce panel de pages. Un échantillon mal cadré donne une image tronquée de la réalité. Un échantillon bien construit, lui, révèle très vite les forces et les faiblesses de l’accessibilité web du service.
Certaines pages sont incontournables. On retrouve la page d’accueil, la page de contact, les mentions légales, la page dédiée à l’accessibilité (qui porte la déclaration elle-même), le plan du site, la page d’aide et, dès qu’il y en a une, la page d’authentification. Ces pages servent de vitrine mais aussi de porte d’entrée vers des parcours plus complexes. Les ignorer reviendrait à évaluer un immeuble sans jamais tester le hall ni l’ascenseur.
À ce socle de base viennent s’ajouter des pages davantage liées au métier du site : une page représentative de chaque grande rubrique, une ou plusieurs pages de résultats de recherche, des pages contenant des tableaux de données, des médias, des formulaires dynamiques. Il faut aussi couvrir des processus complets, comme une prise de rendez-vous ou une simulation en plusieurs étapes. L’accessibilité numérique d’un parcours peut s’effondrer sur un seul écran mal pensé, ce qui justifie un contrôle séquentiel plutôt qu’une analyse page par page déconnectée.
Un point souvent oublié concerne les documents téléchargeables. Pour un service qui propose des formulaires PDF, des rapports ou des brochures, au moins un document significatif doit être intégré à l’échantillon pour chaque type de service clé. Là encore, l’utilisateur n’a que faire d’une page web accessible si le formulaire qu’il doit remplir reste inutilisable avec un lecteur d’écran.
Enfin, une partie de l’échantillon doit être sélectionnée au hasard, à hauteur d’au moins dix pour cent du total. Ce « tirage aléatoire » évite le biais classique qui consiste à ne tester que les pages soignées pendant la refonte en laissant de côté les contenus plus anciens ou plus chaotiques. Beaucoup d’organisations découvrent à cette étape des modèles de pages oubliés, des composants non mis à jour ou des contenus importés sans balisage correct.
Pour t’y retrouver, un petit tableau de synthèse aide à cadrer l’échantillon :
| Type de page | Statut dans l’audit RGAA | Exemple concret |
|---|---|---|
| Page de base obligatoire | Toujours incluse | Accueil, contact, mentions légales, aide |
| Page métier | Au moins une par type de service | Rubrique thématique, fiche produit, actualité |
| Processus complet | Toutes les étapes | Formulaire multi-pages, tunnel de paiement |
| Document téléchargeable | Un par type pertinent | Formulaire PDF, rapport d’activité |
| Pages aléatoires | Au moins 10 % de l’échantillon | Pages profondes, anciens contenus |
Un échantillon représentatif mélange donc pages stratégiques, pages typiques et pages moins visibles. Du coup, il reflète la réalité vécue par les utilisateurs, et pas uniquement la vitrine soignée du site. À partir de là, l’audit RGAA commence à produire des résultats utiles pour la mise en conformité, plutôt qu’un simple score théorique.
Environnement de test RGAA : base de référence, lecteurs d’écran et contraintes réelles
Tester un site pour l’accessibilité numérique sans définir un environnement de test, c’est un peu comme mesurer une performance sportive sans préciser la distance parcourue. Le RGAA parle de « base de référence » : un ensemble de technologies d’assistance, de navigateurs et de systèmes d’exploitation qui sert de socle pour les tests de restitution, notamment pour les critères liés au JavaScript et aux interactions riches.
En pratique, cette base doit refléter les usages réels des personnes en situation de handicap. On y retrouve les lecteurs d’écran les plus répandus, les combinaisons clavier/navigateur les plus fréquentes, les loupes logicielles ou outils de contraste utilisés au quotidien. Certaines organisations se contentent du minimum et vérifient juste sur un lecteur d’écran moderne avec un navigateur récent. D’autres prennent en compte des configurations plus anciennes encore très présentes en entreprise ou dans l’administration.
Quand on connaît le parc de postes de travail d’un intranet, par exemple, la base de référence peut être calée précisément sur l’environnement des agents : version du système, navigateur imposé, outils d’assistance déployés. Cette approche pousse à une validation conformité plus réaliste. Elle évite de déclarer un site accessible sur Chrome dernier cri alors que, dans les faits, tout le monde navigue sous un navigateur figé plusieurs versions en arrière.
Pour un service public en ligne grand public, la base de référence doit rester plus large. L’enjeu consiste alors à couvrir les combinaisons majeures sans se perdre dans une explosion de scénarios. C’est là que les outils de test RGAA automatisés peuvent compléter le travail, à condition de se rappeler qu’ils ne remplacent jamais un test avec un lecteur d’écran ou une navigation uniquement au clavier. Les critères liés à la compréhension, à la cohérence des intitulés ou à la logique des messages d’erreur restent, par essence, humains.
Au passage, un écueil revient souvent : tester uniquement avec une souris en se disant que « si ça marche à la souris, ça ira ». C’est l’inverse qui fonctionne : quand un parcours fonctionne totalement au clavier, qu’il est clair à la lecture linéaire pour un lecteur d’écran, qu’il respecte les critères de focus et de structure, l’expérience souris suit naturellement. Penser « clavier d’abord » accélère la mise en conformité bien plus qu’un empilement de correctifs graphiques.
Autre décision importante : fixer une version stable de la base de référence pour chaque audit. Sans cela, on se retrouve à comparer des résultats obtenus dans des conditions différentes, ce qui brouille l’analyse des progrès. Documenter cette base dans la déclaration d’accessibilité, avec les outils et versions testés, offre de la clarté aux utilisateurs qui souhaitent savoir dans quelles conditions le test RGAA a été réalisé.
En résumé, une base de référence réfléchie donne du sens aux chiffres de conformité et connecte les critères du référentiel général d’accessibilité à la réalité des équipements utilisés sur le terrain.
Test RGAA des pages : critères applicables, non applicables et calcul du taux de conformité
Une fois l’échantillon et la base de référence définis, vient le moment où chaque page est passée au crible des critères. Là, la discipline fait la différence. Pour chaque critère du RGAA, l’auditeur doit commencer par déterminer s’il est applicable à la page. C’est un passage obligé si tu veux que ton test RGAA ne se transforme pas en labyrinthe incompréhensible.
Trois raisons principales expliquent qu’un critère soit considéré comme non applicable. Premièrement, le contenu ou la fonctionnalité visée n’existe tout simplement pas sur la page. Si une page ne contient aucune vidéo, les critères portant sur les médias synchronisés n’entrent pas en jeu. Deuxièmement, le contenu appartient à une catégorie explicitement exemptée par le cadre légal. Troisièmement, le contenu fait l’objet d’une dérogation pour charge disproportionnée, avec une alternative numérique accessible réellement disponible. Dans ce cas précis, les critères concernant ce contenu sont marqués non applicables, mais uniquement si l’alternative tient la route.
Une fois la liste des critères applicables établie pour chaque page, les tests commencent. Un critère est considéré comme validé pour une page quand tous les éléments concernés respectent les tests associés. Dès qu’un seul élément de la page échoue, le critère est noté non conforme. La règle est stricte, et c’est logique : l’accessibilité web ne se juge pas à la moyenne, mais au maillon le plus faible. Pour les processus multi-pages, un critère n’est validé que s’il l’est sur toutes les pages du parcours.
De là découlent deux manières de parler du niveau de conformité. On peut calculer le taux de conformité moyen page par page, puis faire la moyenne pour le site. On peut aussi mesurer le pourcentage de critères RGAA respectés sur l’ensemble de l’échantillon. Dans cette deuxième approche, un critère est déclaré globalement validé seulement s’il est valide sur toutes les pages où il est applicable. À l’inverse, il suffit qu’il soit applicable sur une seule page pour être pris en compte dans le calcul.
Ce mode de calcul a un effet très concret : une seule page mal conçue peut faire chuter le pourcentage de critères respectés pour le site entier. C’est inconfortable, mais cela pousse à traiter les problèmes à la racine plutôt qu’à tolérer des zones d’ombre. Pour piloter la mise en conformité, beaucoup d’équipes combinent ces deux lectures : elles regardent le taux moyen par page pour prioriser les parcours les plus critiques, et le pourcentage global de critères pour suivre le progrès global dans le temps.
Pour t’aider à structurer le travail, une liste simple peut servir de guide opérationnel pendant les tests :
- Identifier les critères applicables pour chaque page de l’échantillon.
- Appliquer les outils de test RGAA automatiques sur les critères détectables (structure, attributs, contrastes).
- Compléter systématiquement par des vérifications manuelles et des tests de restitution (clavier, lecteur d’écran, zoom).
- Consigner pour chaque critère la nature de l’écart, des exemples précis et un niveau de priorité.
- Générer le taux de conformité par page, puis les agrégats globaux nécessaires à la validation conformité.
Quand cette mécanique est en place, la discussion autour des résultats devient beaucoup plus sereine. On ne débat plus à coups d’impressions subjectives, on parle de critères formulés, d’exemples d’écarts et de décisions claires sur ce qu’il faut corriger en premier.
Mise en conformité RGAA dans la durée : outils, organisation et feuille de route réaliste
Une fois les chiffres tombés, une autre histoire commence. Que faire d’un taux de conformité de 40 %, 70 % ou 90 % ? C’est ici que beaucoup de projets se cassent les dents. L’audit RGAA sert alors de signal de départ pour une transformation plus large, qui touche autant à la technique qu’aux contenus et aux processus de travail.
Première brique : les outils de test RGAA. Ils ne se valent pas tous, mais ils rendent de fiers services quand ils sont bien utilisés. Certains se branchent en extension de navigateur pour signaler les problèmes de balisage, d’autres analysent des groupes de pages pour repérer les erreurs récurrentes. Des plateformes plus complètes proposent même des tableaux de bord, des rapports détaillés et des suggestions de correctifs. À condition de ne pas prendre leurs résultats pour une vérité absolue, ces outils permettent de repérer rapidement les régressions pendant les sprints de développement.
Deuxième brique : l’organisation. Une mise en conformité sérieuse implique de répartir les responsabilités. L’équipe design gère les composants accessibles du design system, l’équipe de développement veille à intégrer ces composants sans les casser, les rédacteurs apprennent à structurer leurs contenus avec des titres logiques, des liens explicites et des descriptions pertinentes. Si tout repose sur une seule personne « référent accessibilité », le projet reste fragile et dépendant.
Troisième brique : la feuille de route. Il vaut mieux un plan priorisé sur un an qu’un fantasme de refonte totale immédiate. Certaines corrections se règlent vite, comme le contraste ou le texte des liens. D’autres demandent de revoir en profondeur un composant clé ou un gabarit de page. Articuler ces actions avec les objectifs du site (lancement d’une nouvelle rubrique, migration technique, refonte graphique) évite le classique « on verra l’accessibilité à la fin », qui revient en pratique à ne jamais la traiter.
On croise régulièrement des équipes qui choisissent d’axer d’abord leurs efforts sur quelques parcours stratégiques : démarches administratives critiques, tunnels de commande, formulaires d’inscription. L’idée, c’est de garantir que les actions vitales pour l’usager deviennent accessibles en priorité, tout en continuant à améliorer le reste du site par vagues successives. Dans ce schéma, l’accessibilité numérique se glisse dans la maintenance et l’évolution courante, plutôt que d’être un chantier exceptionnel hors du flux.
Enfin, une mise en conformité qui tient dans le temps s’accompagne de deux habiletés souvent sous-estimées : la pédagogie interne et l’écoute des usagers. Partager les résultats de l’audit, organiser de petites démonstrations de navigation au clavier ou au lecteur d’écran, documenter les bonnes pratiques dans l’outil de ticketing, tout cela change le regard sur le sujet. De l’autre côté, ouvrir des canaux de remontée (adresse mail dédiée, formulaire de signalement, accès facilité à la page d’accessibilité) permet de détecter des obstacles que l’audit n’avait pas vus.
Quand ces briques sont réunies, la conformité RGAA cesse d’être une corvée administrative. Elle devient une façon structurée de faire évoluer ton service dans le bon sens, à la vitesse que ton contexte permet.
Quelle différence entre audit RGAA automatique et manuel ?
Un audit automatique s’appuie sur des outils qui analysent le code pour repérer des problèmes détectables mécaniquement, comme l’absence d’attribut alt ou des erreurs de structure HTML. Un audit manuel vérifie aussi la restitution réelle avec clavier, lecteur d’écran, zoom, cohérence des contenus et compréhension des messages. Pour une validation conformité sérieuse, les deux approches sont complémentaires, mais l’audit manuel reste incontournable pour couvrir tous les critères du RGAA.
À partir de quel taux peut-on parler de conformité RGAA ?
Le RGAA ne fixe pas un seuil unique pour dire qu’un site est conforme ou non. La déclaration d’accessibilité doit indiquer le taux de conformité, détailler les critères non conformes et mentionner les éventuelles dérogations. En pratique, beaucoup d’organismes visent un niveau proche de 100 % sur les parcours critiques, tout en affichant de manière transparente les points restants et la feuille de route de mise en conformité.
Combien de temps dure un audit RGAA complet ?
La durée dépend de la taille du site, de la complexité des parcours et du nombre de gabarits différents. Un petit site vitrine avec peu de modèles se traite en quelques jours, là où un portail riche en fonctionnalités, formulaires et documents peut nécessiter plusieurs semaines. L’essentiel reste de cadrer clairement l’échantillon de pages et l’environnement de test en amont pour éviter les allers-retours inutiles.
Faut-il refaire un audit RGAA après chaque mise à jour du site ?
Un audit intégral après chaque évolution serait ingérable. En revanche, il est recommandé de planifier un audit complet périodique et de mettre en place des contrôles ciblés à chaque livraison, au moins sur les composants et pages concernés. Les outils de test RGAA intégrés dans la chaîne de développement aident à repérer rapidement les régressions et à maintenir un niveau d’accessibilité stable entre deux audits complets.
Comment impliquer les équipes non techniques dans l’accessibilité web ?
Les équipes éditoriales, marketing ou métiers jouent un rôle clé dans la conformité RGAA. On peut les impliquer via des ateliers courts pour apprendre à rédiger des titres hiérarchisés, des liens explicites, des textes alternatifs pertinents, ou encore à utiliser des gabarits accessibles fournis par l’équipe technique. Plus les bonnes pratiques sont intégrées au quotidien, moins il faudra corriger de problèmes lourds lors des audits.
