Audit RGAA : en quoi consiste un audit d’accessibilité numérique et quelles sont les étapes ?

L’audit RGAA reste souvent perçu comme une formalité réglementaire à traiter en urgence lorsque la communication institutionnelle parle de « mise en conformité ». En réalité, un véritable Audit RGAA ouvre surtout une fenêtre très concrète sur l’état d’accessibilité numérique d’un service, ses blocages critiques, ses points forts et ses risques juridiques. Il permet de relier les textes de loi à des situations d’usage réelles : une personne aveugle qui ne peut pas finaliser un formulaire, un senior perdu dans une navigation, un étudiant dyslexique qui abandonne la lecture d’une page entière. Quand l’évaluation accessibilité est menée sérieusement, elle devient un outil de pilotage bien plus qu’un simple contrôle ponctuel.

Ce type d’analyse de site s’appuie sur un référentiel précis, le Référentiel Général d’Amélioration de l’Accessibilité, et sur une méthodologie d’audit encadrée par l’État. L’objectif officiel est clair : mesurer la conformité RGAA d’un site ou d’une application et produire un rapport d’audit exploitable. Mais sur le terrain, l’enjeu dépasse largement le score final. Les équipes ont besoin de comprendre ce qui bloque, pourquoi cela bloque, et comment intégrer les correctifs accessibilité dans leur backlog sans tout casser. Un audit RGAA bien mené articule donc trois dimensions : la norme, l’ergonomie web et la réalité des parcours utilisateurs. C’est cette articulation qui fait la différence entre un rapport théorique qui finit dans un tiroir et un levier d’amélioration continue.

• L’audit RGAA est l’évaluation de référence pour mesurer l’accessibilité numérique d’un site ou d’une application en France.
• Il s’appuie sur 106 critères issus des normes accessibilité internationales et adaptés au contexte français.
• Le résultat principal est un taux global de conformité RGAA qui doit figurer dans la déclaration d’accessibilité.
• Un audit complet combine tests techniques, revue ergonomique et parfois tests utilisateurs ciblés.
• Les non-conformités sont documentées dans un rapport d’audit avec recommandations pragmatiques et priorisation.

Comprendre le RGAA et le cadre réglementaire avant de lancer un audit d’accessibilité numérique

Avant de se lancer dans un Audit RGAA, il reste utile de clarifier ce que recouvre exactement ce référentiel et à qui il s’applique. Le RGAA, acronyme de Référentiel Général d’Amélioration de l’Accessibilité, décrit les règles techniques et fonctionnelles à respecter pour qu’un service en ligne soit utilisable par le plus grand nombre, y compris les personnes en situation de handicap visuel, auditif, moteur ou cognitif. Il reprend l’essentiel des exigences WCAG 2.1 et de la norme EN 301 549, mais les traduit dans un langage et une structure adaptés au contexte français.

Ce référentiel ne sort pas de nulle part. Il découle directement de la loi du 11 février 2005 sur « l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées », puis des textes ultérieurs qui ont renforcé les obligations d’accessibilité numérique. Concrètement, les organismes publics, les acteurs privés chargés d’une mission de service public, et les entreprises dépassant certains seuils de chiffre d’affaires sont tenus de respecter ces normes accessibilité. Depuis l’entrée en vigueur de l’Acte européen sur l’accessibilité, les secteurs comme l’e-commerce, la banque ou les transports sont de plus en plus concernés, même lorsqu’ils n’avaient jamais entendu parler du RGAA auparavant.

Pour les équipes qui découvrent le sujet, un contenu synthétique comme le guide proposé sur cette définition simple du RGAA aide souvent à mettre à plat les notions de base. On y retrouve les principes fondamentaux : contenu perceptible, utilisable au clavier, compréhensible, et robuste techniquement pour dialoguer avec les technologies d’assistance. Derrière chaque critère se trouvent des situations très concrètes : un bouton sans nom accessible, un contraste de texte insuffisant, un champ de formulaire sans étiquette correcte, un document PDF illisible pour un lecteur d’écran.

Autre élément clé du cadre réglementaire : la déclaration d’accessibilité. Toute organisation soumise au RGAA doit la publier sur son site, en accès direct depuis la page d’accueil. Ce document doit indiquer le niveau de conformité RGAA atteint, les principales non-conformités, les éventuelles dérogations justifiées et un plan d’actions sur plusieurs années. Sans audit sérieusement conduit, cette déclaration se transforme en exercice de communication déconnecté de la réalité. Avec une évaluation solide, elle devient au contraire un outil de transparence assumé, qui donne aux usagers des repères clairs.

Les sanctions ne sont plus théoriques. Les autorités de contrôle demandent désormais des preuves tangibles, notamment la mise à disposition d’un rapport d’audit daté et la trace d’actions engagées. S’en tenir à un auto-diagnostic rapide ou à un test automatique n’est plus tenable. Un Audit RGAA structuré reste aujourd’hui la façon la plus solide de démontrer la bonne foi et la progression d’un service. C’est aussi un levier de qualité globale : lorsqu’un site devient plus accessible, l’ergonomie web s’améliore pour tout le monde, y compris les utilisateurs sans handicap reconnu.

En quoi consiste concrètement un audit RGAA complet et sérieux ?

Un Audit RGAA tient autant de l’examen technique que de l’enquête d’usage. Il commence par une phase de cadrage rarement valorisée mais décisive. Les auditeurs prennent le temps de comprendre le service : typologie des utilisateurs, finalités du site, technologies employées, contraintes de sécurité ou de marché public. Une plateforme de démarches administratives n’a pas les mêmes enjeux qu’un site vitrine touristique ou qu’une application bancaire. Sans ce contexte, l’évaluation accessibilité risque de passer à côté des vrais points de douleur.

Vient ensuite la sélection de l’échantillon de pages. Contrairement à une idée répandue, l’audit ne porte pas sur l’intégralité du site, sauf cas très particulier. Les auditeurs identifient un nombre limité de pages et de fonctionnalités qui représentent l’ensemble des gabarits : page d’accueil, listes de contenus, fiches détaillées, formulaires, espace de connexion, moteur de recherche, pages d’aide, documents téléchargeables. Ce choix se fait à partir du kit officiel publié par l’administration et, idéalement, en dialogue avec l’équipe projet. Un échantillon mal choisi conduit à un taux de conformité rassurant, mais déconnecté des parcours réellement empruntés.

Sur chaque page retenue, les auditeurs passent les 106 critères RGAA en revue. Certains sont vérifiés via des outils (analyse de contraste, validation de code, détection de certains attributs), mais la majeure partie repose sur des tests manuels : navigation clavier seule, lecture avec un lecteur d’écran, contrôle de la cohérence des titres, vérification du sens de tabulation, comportement des menus déroulants, etc. C’est là que la différence entre un audit superficiel et une évaluation approfondie devient flagrante. Un scan automatique ne détectera jamais qu’un message d’erreur de formulaire s’affiche bien visuellement mais n’est pas vocalisé au bon moment pour une personne aveugle.

Dans les projets les plus engagés, cette analyse technique se combine avec de vrais tests utilisateurs, réalisés avec des personnes qui utilisent quotidiennement un lecteur d’écran, une plage braille, un logiciel de grossissement ou la navigation clavier. Les retours de ces sessions donnent une épaisseur supplémentaire à l’audit : ils révèlent par exemple qu’un parcours, pourtant conforme RGAA sur le papier, reste confus ou anxiogène en pratique. De nombreux sites « validés » d’un point de vue normatif montrent encore des parcours de paiement ou des formulaires d’inscription décourageants pour les publics fragiles.

Le résultat de ce travail minutieux n’est pas qu’un score. Un Audit RGAA aboutit à un rapport d’audit détaillé, qui doit être structurée pour que les équipes puissent l’exploiter. Chaque non-conformité est reliée à un critère du référentiel, documentée par des captures ou extraits de code, expliquée en langage accessible et assortie de pistes de correction. Sans cette pédagogie, les développeurs se sentent parfois accusés sans comprendre ce qui est attendu. Rédiger un bon rapport d’audit, ce n’est pas aligner les défauts, c’est montrer comment passer d’un état A à un état B réaliste.

Certaines organisations choisissent de se former un minimum en amont pour tirer davantage profit de ce travail. Des ressources comme le guide proposé par cet accompagnement à l’accessibilité RGAA permettent de préparer les équipes et d’éviter que le rapport ne soit perçu comme un couperet incompréhensible. Quand chacun connaît déjà les grands principes, l’audit alimente un échange technique argumenté plutôt qu’un simple constat à sens unique.

Le taux de conformité RGAA : un indicateur utile mais à manier avec prudence

Le calcul du taux de conformité intrigue souvent les directions. Beaucoup imaginent un score simple qui suffirait à juger un site. La réalité est un peu plus nuancée. Chaque critère RGAA est évalué sur l’échantillon de pages avec trois possibilités : conforme, non conforme ou non applicable. À partir de ces résultats, l’auditeur peut calculer un taux moyen par page pour suivre les progrès au fil du temps, et surtout un taux global de conformité agrégé, qui seul a vocation à figurer dans la déclaration officielle.

Ce taux global permet de classer un service en trois catégories : non conforme (moins de 50 %), partiellement conforme (entre 50 % et moins de 100 %), ou totalement conforme (100 % des critères applicables respectés). Très peu de sites atteignent réellement le dernier niveau, même parmi les grandes plateformes publiques. Lorsque c’est le cas, c’est généralement le résultat d’années d’itérations, de contrôles réguliers et d’une culture d’accessibilité bien ancrée dans les équipes produit.

Le piège serait de se satisfaire d’un « bon » taux sans se demander où se situent les non-conformités. Une anomalie majeure sur un tunnel de paiement peut être noyée dans un ensemble de pages correctes et ne peser que faiblement dans le score global. Sur le terrain, elle crée pourtant une exclusion directe pour certains publics. Un Audit RGAA digne de ce nom insiste donc sur la criticité des défauts et leur impact réel sur les utilisateurs, et pas seulement sur la quantité de points invalidés.

Cette distinction entre conformité et accessibilité effective doit être intégrée dès le début du projet. Le RGAA ne couvre pas encore tous les besoins, notamment en matière de troubles cognitifs, de fatigue mentale ou de surcharge informationnelle. Un site peut être conforme tout en restant déroutant, complexe, saturé de contenus non hiérarchisés. C’est là que le lien entre audit normatif et travail sur l’ergonomie web devient essentiel. Le score RGAA ouvre la porte, mais ce sont les choix de conception et de rédaction qui font la différence au quotidien.

Les grandes étapes d’un audit RGAA : du cadrage au suivi des correctifs d’accessibilité

Lorsqu’une organisation commande un Audit RGAA, elle a parfois l’impression de signer pour un bloc monolithique. En réalité, un audit sérieux s’articule en plusieurs étapes bien distinctes, qui peuvent se caler sur la vie du projet. Imaginer le cas d’une collectivité qui vient de refondre son portail citoyen aide à visualiser le déroulé. Le site est en ligne depuis six mois, les premiers retours d’usagers arrivent, et la direction demande une évaluation accessibilité avant de publier sa déclaration officielle.

La première étape consiste à clarifier le périmètre. Faut-il auditer le site principal uniquement, ou aussi l’extranet agents, le blog, les mini-sites événementiels, les formulaires en ligne hébergés par des prestataires tiers ? Cette question n’est pas anodine. Plus le périmètre est large, plus l’échantillon de pages doit être réfléchi pour rester représentatif sans devenir ingérable. Les auditeurs bâclent parfois cette phase, alors qu’elle conditionne la pertinence de tout ce qui suit.

Vient ensuite la sélection concrète des pages à tester. Les règles officielles imposent déjà certaines incontournables : page d’accueil, contact, aide, page de connexion si elle existe, page de consultation de contenus, formulaire type, page présentant des médias (vidéo, audio), etc. L’auditeur complète généralement cette liste avec des pages reflétant les parcours critiques du service : prise de rendez-vous, dépôt de dossier, paiement, simulation. On évite au passage de se concentrer uniquement sur les écrans les plus soignés visuellement, pour inclure aussi les « coulisses » moins glamour mais centrales pour les usagers.

Les tests commencent ensuite, en combinant évaluation manuelle et outils de contrôle. Sur chaque page, l’auditeur vérifie, parfois plusieurs dizaines de fois, les intitulés de liens, la cohérence des titres, la qualité des textes alternatifs, la capacité du site à fonctionner uniquement au clavier, la présence de mécanismes de contournement comme les liens d’évitement, la bonne hiérarchisation du contenu pour un lecteur d’écran. Les outils automatiques servent surtout à détecter des tendances récurrentes. Ils ne remplacent pas l’analyse humaine.

Une fois l’analyse terminée, l’auditeur ne livre pas uniquement un verdict brut. La phase de restitution avec les équipes est décisive. Idéalement, elle réunit au même moment développeurs, designers, rédacteurs, responsables métiers et décideurs. On y passe en revue les non-conformités les plus impactantes, mais aussi les bonnes pratiques déjà en place. Une resttitution réussie ne se limite pas à lire un rapport : elle aide chacun à comprendre comment ses décisions quotidiennes (choix de composant, formulation d’un texte, intégration d’une image) influent directement sur l’accessibilité numérique.

Enfin, un Audit RGAA digne de ce nom propose un plan d’action hiérarchisé. Tout corriger en une fois reste rarement possible. L’enjeu consiste donc à distinguer ce qui bloque immédiatement des parcours essentiels, ce qui peut être traité au fil des sprints, et ce qui relève plutôt d’une future refonte. Les organisations qui progressent le plus vite sont souvent celles qui planifient d’emblée un audit de contrôle, quelques mois après la première vague de correctifs, pour mesurer les effets des changements et ajuster la déclaration d’accessibilité.

Exemple de déroulé d’audit et articulation avec le projet numérique

Pour rendre les choses plus concrètes, imaginons une entreprise de services qui lance un nouvel espace client. La direction souhaite un Audit RGAA dans les six mois suivant la mise en ligne. Le cadrage identifie les pages clés : tableau de bord, consultation de factures, modification des coordonnées, changement de mot de passe, assistance en ligne. L’échantillon inclut aussi quelques pages publiques de présentation de l’offre, pour vérifier la cohérence globale.

Les tests révèlent plusieurs familles de problèmes : boutons d’action sans étiquette lisible pour les lecteurs d’écran, absence de message clair en cas d’erreur de saisie dans les formulaires, contrastes trop faibles sur les liens, structure de titres incohérente. Techniquement, rien d’insurmontable, mais ces défauts cumulés rendent l’espace client épuisant à utiliser pour un public malvoyant ou peu à l’aise avec le numérique. Les développeurs prennent conscience qu’une simple correction sur le composant de bouton partagé améliore d’un coup des dizaines de pages.

La restitution avec les équipes permet de transformer ces constats en tickets concrets dans le backlog. Le rapport d’audit indique par exemple : « Priorité haute sur la correction des boutons d’action dans les parcours de paiement, moyenne sur les pages secondaires d’historique, faible sur les zones peu utilisées ». Les product owners peuvent ainsi arbitrer avec d’autres exigences (SEO, performance, nouvelles fonctionnalités) en gardant en tête les risques juridiques et humains associés aux défauts d’accessibilité.

Pour ce type de projet, un deuxième audit plus léger, focalisé sur les points critiques, quelques mois plus tard, permet de vérifier que les correctifs accessibilité ont réellement l’effet escompté. On évite au passage un phénomène courant : des corrections bien intentionnées qui introduisent de nouveaux problèmes ailleurs, faute de vision globale. Ce suivi dans le temps donne aussi du poids à la déclaration d’accessibilité, qui peut mentionner des progrès mesurables plutôt qu’une promesse vague de « mise en conformité prochaine ».

Lire, utiliser et faire vivre un rapport d’audit RGAA au quotidien

Une fois le rapport livré, beaucoup d’équipes se sentent un peu démunies. Le document est parfois long, truffé de références aux critères RGAA, et tout le monde n’a pas envie d’apprendre par coeur la structure du référentiel. La question clé devient alors : comment transformer ce rapport d’audit en moteur d’évolution plutôt qu’en simple justificatif à envoyer à la direction ou à l’autorité de contrôle ?

Une première approche consiste à trier les résultats selon trois axes : criticité pour les utilisateurs, complexité technique de la correction, et impact sur la conformité RGAA. Un tableau synthétique aide beaucoup pour ce travail d’arbitrage.

Type de non-conformité	Impact sur l’utilisateur	Complexité de correction	Priorité conseillée
Bouton d’envoi de formulaire non vocalisé	Blocage complet pour les utilisateurs de lecteur d’écran	Modification d’un composant partagé	Très haute
Contraste insuffisant sur les liens secondaires	Gêne de lecture, surtout en mobilité	Ajustement de la feuille de styles	Haute
Absence d’attribut alt sur des images décoratives	Légère perte de confort, pas de blocage	Nettoyage progressif au fil des mises à jour	Moyenne
Structure Hn irrégulière sur quelques pages éditoriales	Navigation moins fluide pour certains lecteurs d’écran	Reprise éditoriale au moment des refontes	Faible

Ce type de grille, souvent esquissé pendant la restitution, permet de transformer des dizaines de pages de remarques en feuille de route concrète. Les développeurs savent sur quoi se concentrer dans les prochains sprints, les rédacteurs identifient les points à reprendre dans leurs contenus, les designers voient quelles composantes de leur design system doivent évoluer. Au lieu de subir le rapport, l’équipe se l’approprie.

Autre réflexe utile : relier systématiquement les constats de l’audit aux retours d’utilisateurs lorsqu’ils existent. Quand une personne malvoyante signale qu’elle ne parvient pas à utiliser un simulateur, il devient plus facile de convaincre la direction que le critère « Nom de lien non explicite » n’est pas un détail. L’évaluation accessibilité prend alors une dimension très concrète. Certains services organisent même de courtes démonstrations en interne, où un collègue utilise un lecteur d’écran ou désactive sa souris pour naviguer. L’impact pédagogique est souvent plus fort qu’un long argumentaire.

Ce travail n’a pas à se faire en vase clos. Des ressources extérieures, comme les contenus publiés sur des sites spécialisés dans l’audit RGAA, permettent de confronter les recommandations de l’auditeur à d’autres retours d’expérience. On y trouve souvent des exemples d’intégration réussie de l’accessibilité dans des méthodes agiles, des mises en perspective avec le SEO ou la performance, et des retours sur les relations parfois délicates avec des sous-traitants peu sensibilisés au sujet.

Une erreur fréquente consiste à traiter l’audit comme un épisode ponctuel, à faire un effort massif de correction, puis à revenir à la routine habituelle. Or, chaque nouvelle fonctionnalité, chaque mise à jour du design, chaque changement de CMS peut réintroduire des obstacles. Les organisations qui s’en sortent le mieux sont celles qui transforment certaines recommandations du rapport en règles internes : check-list d’accessibilité dans les revues de code, modèles de contenus pré-paramétrés, formation minimum pour les nouveaux arrivants, etc.

En filigrane, la question posée par tout rapport d’audit est simple : veut-on uniquement cocher une case réglementaire, ou utiliser l’accessibilité numérique comme levier de qualité globale ? Celles et ceux qui font le second choix constatent rarement qu’ils y perdent, y compris sur des sujets très concrets comme le taux de conversion, le nombre d’appels au support ou la lisibilité sur mobile.

Combien coûte un audit RGAA et comment l’intégrer dans une stratégie d’accessibilité numérique durable

La question du budget revient tôt ou tard. Beaucoup de responsables de sites hésitent à se lancer, par crainte d’un coût disproportionné ou d’un retour sur investissement difficile à expliquer. On trouve pourtant des repères assez clairs. Le prix d’un audit dépend surtout du périmètre (taille et complexité du site, nombre de gabarits à couvrir) et du niveau de détail attendu. Certaines structures professionnelles annoncent des tarifs indicatifs, comme le montre par exemple cette page sur le prix d’un audit RGAA, pour donner un ordre de grandeur aux clients potentiels.

Au-delà du montant brut, la vraie question devient : que paie-t-on exactement ? Un audit complet inclut en général l’évaluation des pages sur les 106 critères, la rédaction du rapport d’audit, la restitution orale avec les équipes, et parfois l’aide à la rédaction de la déclaration d’accessibilité. Certains prestataires proposent en option un audit de contrôle destiné à vérifier l’effet des correctifs accessibilité quelques mois plus tard. Ce second passage, moins lourd que le premier, rassure les directions et fournit une preuve objective que les engagements pris dans la déclaration ont été tenus.

Pour les organisations qui disposent de moyens limités, plusieurs stratégies existent. Certaines choisissent de concentrer d’abord l’audit sur un périmètre restreint mais critique (portail de démarches, espace client) avant d’élargir progressivement. D’autres combinent un audit externe ciblé avec un travail de montée en compétence interne : formation des équipes, mise en place de check-lists simples, utilisation d’outils d’auto-contrôle. L’idée n’est pas de remplacer l’expertise extérieure, mais de la compléter par des réflexes quotidiens.

Sur le long terme, un Audit RGAA trouve sa place dans une démarche plus globale d’accessibilité numérique. Certains acteurs choisissent par exemple de programmer un audit complet tous les deux ou trois ans, complété par des revues plus légères à chaque release majeure. D’autres lient systématiquement l’audit à de grands jalons du projet : mise en production d’une refonte graphique, changement de socle technique, ajout de parcours métiers importants. Dans tous les cas, l’objectif reste d’éviter l’effet « réveil brutal » où l’on découvre à la veille d’un contrôle que rien n’est en règle.

Une approche intéressante consiste à intégrer l’accessibilité dans les critères de choix des prestataires externes. Plutôt que de confier au même acteur la réalisation du site et son audit, beaucoup d’organisations préfèrent confier l’évaluation à un tiers. Cela limite les conflits d’intérêt et incite l’intégrateur à respecter ses engagements. Le rapport d’audit devient alors un document de dialogue entre le client et son prestataire, et non une critique unilatérale.

Pour aller plus loin, certaines équipes s’appuient aussi sur des guides pédagogiques destinés aux non-spécialistes, comme le guide d’accessibilité RGAA évoqué plus haut. Ces ressources permettent de diffuser une culture commune de l’ergonomie web inclusive, au-delà du seul cercle des développeurs. Quand les rédacteurs, les communicants et les chefs de projet comprennent la logique du référentiel, les audits suivants rencontrent beaucoup moins de résistances.

Un Audit RGAA ne résout pas tout. C’est un point de départ et un filet de sécurité. Il indique où se situent les problèmes, mesure les progrès, et fournit des arguments solides lorsqu’il faut convaincre une direction ou un partenaire réticent. Utilisé dans cette logique, il devient un investissement structurel plutôt qu’une dépense contrainte à justifier chaque année.

Faire du RGAA un réflexe de conception plutôt qu’un contrôle en bout de chaîne

Reste une question de fond : comment éviter que l’accessibilité ne soit abordée qu’au moment de l’audit, quand tout est déjà en place ? La réponse passe en grande partie par la manière dont on conçoit et pilote les projets numériques. Si les maquettes sont systématiquement vérifiées au regard de quelques critères de base (contrastes, taille des cibles interactives, ordre de tabulation supposé), si les spécifications mentionnent explicitement les besoins des utilisateurs en situation de handicap, l’audit final devient beaucoup moins douloureux.

Pour cela, il peut être utile de repérer quelques gestes simples à intégrer dans les routines d’équipe :

• Tester chaque nouvelle fonctionnalité au clavier et corriger immédiatement les éléments inaccessibles.
• Vérifier les contrastes de couleurs de la charte graphique avant de la figer.
• Documenter les composants du design system avec des exemples d’utilisation accessibles.
• Prévoir des gabarits éditoriaux qui guident les auteurs sur les titres, les listes et les liens.

À partir du moment où ces pratiques deviennent banales, l’audit n’arrive plus comme une sanction, mais comme une validation externe d’un travail déjà engagé. La conformité RGAA cesse d’être un objectif lointain et se transforme en indicateur de qualité partagée. Sur le long terme, cette approche est souvent moins coûteuse, en temps comme en argent, qu’une succession de corrections d’urgence sous la pression d’un contrôle.

En filigrane, l’audit rappelle surtout une chose : l’accessibilité n’est pas un supplément d’âme réservé à quelques publics. C’est une façon structurée de vérifier que ce qui est conçu pour « tout le monde » fonctionne vraiment pour chacun, y compris pour celles et ceux qui ne rentrent pas tout à fait dans la norme supposée de l’utilisateur idéal.

Qui a l’obligation légale de faire un audit RGAA sur ses sites et applications ?

Les organismes publics, les structures privées qui exercent une mission de service public et les entreprises dépassant certains seuils de chiffre d’affaires en France doivent se conformer au RGAA. Pour démontrer cette conformité, un audit d’accessibilité numérique réalisé selon la méthode officielle reste le moyen le plus solide de justifier le taux de conformité annoncé dans la déclaration d’accessibilité.

Un audit RGAA se limite-t-il à des tests automatiques ?

Non. Les outils automatiques repèrent une partie des erreurs, mais ils ne couvrent qu’une fraction des 106 critères RGAA. Un audit sérieux repose surtout sur des tests manuels, parfois complétés par des tests utilisateurs avec des personnes en situation de handicap. Sans cette dimension humaine, de nombreux obstacles concrets passent totalement inaperçus.

Combien de temps dure en général un audit RGAA ?

La durée dépend du périmètre et du nombre de pages incluses dans l’échantillon. Pour un site de taille moyenne, il faut souvent compter quelques semaines entre le cadrage, l’analyse détaillée, la rédaction du rapport d’audit et la restitution. Les audits de contrôle, menés après les corrections, sont généralement plus rapides car ils ciblent des points précis.

Le taux de conformité RGAA suffit-il à juger la qualité d’un site ?

Le taux de conformité donne une mesure standardisée du respect du référentiel, mais il ne reflète pas toujours la facilité d’usage réelle. Deux sites avec le même score peuvent offrir des expériences très différentes. Pour évaluer la qualité globale, il faut compléter le score par une analyse de la criticité des défauts et, si possible, par des retours d’utilisateurs.

Que faire après un premier audit RGAA ?

Après un premier audit, la priorité consiste à traiter les non-conformités les plus impactantes pour les utilisateurs, puis à planifier les corrections restantes dans les sprints ou la feuille de route produit. De nombreuses organisations programment ensuite un audit de contrôle, afin de vérifier les progrès et de mettre à jour leur déclaration d’accessibilité avec des éléments vérifiés.