Audit RGAA et fiabilité de la déclaration face au volume des éléments à contrôler

Un taux RGAA rassurant peut masquer une évaluation trop superficielle. Avant de publier une déclaration d’accessibilité, une organisation doit savoir sur quelles vérifications elle repose. Le nom du prestataire et le nombre de cases remplies dans une grille ne répondent pas à cette question.

Nous avons inventorié trois pages réelles : un article, une page d’accueil avec composants dépliables et un catalogue marchand. Résultat : 368, 487 et 2 945 éléments HTML dans le périmètre compté. Sur le catalogue, 205 éléments interactifs distincts étaient rendus, avant même d’ouvrir un menu ou de modifier un filtre.

Ces chiffres ne sont pas des nombres d’erreurs. Ils révèlent l’échelle du travail que peut cacher une seule page. Et posent une question au donneur d’ordre : quelle couverture réelle avez-vous achetée avec votre audit ?

Une page peut déjà contenir plus de mille éléments

L’étude WebAIM Million de février 2026, menée sur un million de pages d’accueil, relève une moyenne de 1 437 éléments HTML par page, ainsi que 66,6 images, 29,9 titres et 6,9 champs de formulaire. Ce sont des moyennes sur ce corpus international de pages d’accueil, pas une description de toutes les pages françaises. [1]

Un élément HTML n’équivaut pas à un objet fonctionnel ni à un test RGAA. Des conteneurs servent à la mise en page ; certaines images sont décoratives ; plusieurs éléments peuvent composer un seul bouton. Il serait donc trompeur de multiplier 1 437 éléments par 106 critères.

Mais l’inverse serait tout aussi trompeur : les 106 critères ne correspondent pas à 106 manipulations à effectuer une seule fois. Une même vérification peut concerner de nombreuses occurrences, dans plusieurs pages et plusieurs états.

Trois pages réelles pour comprendre la charge

Voici trois exemples observés le 4 novembre 2026, dans un navigateur de bureau de 1 363 x 936 pixels. Les niveaux légère, moyenne et forte décrivent ici la complexité fonctionnelle des exemples choisis. Ils ne constituent ni une classification officielle ni un échantillon statistique du Web.

Comment lire ces chiffres. Le DOM est la structure technique de la page chargée dans le navigateur. Le filtre de rendu conserve les éléments ayant une boîte géométrique et dont la visibilité calculée n’est pas « hidden » ; il inclut ceux situés plus bas dans la page. Il ne constitue pas un inventaire de l’arbre d’accessibilité.

Le comptage porte sur le document principal, hors barre d’administration WordPress et éléments script, style, noscript et template. Les sous-documents des cadres et les racines Shadow DOM ne sont pas parcourus. Aucun défilement ni interaction n’a été effectué. Les contenus chargés ultérieurement et les autres états ne sont donc pas recensés.

Les familles peuvent se recouper : une image peut être dans un lien, un lien dans un titre. Les lignes ne doivent pas être additionnées. Seule la dernière ligne utilise une sélection unique des éléments interactifs pour éviter de les compter deux fois.

Les 229 SVG du catalogue ne représentent pas 229 anomalies, ni nécessairement 229 images porteuses d’information. Leur fonction et leur traitement doivent être déterminés avant d’appliquer les tests correspondants. De même, l’absence d’élément img rendu dans l’article n’implique pas l’absence de tout contenu graphique.

Ces inventaires ne mesurent pas la conformité des sites cités et ne constituent pas une exécution d’appYaccess. Les trois adresses et le protocole sont indiqués en fin d’article.

Vérifier cinq liens sur 181 ne démontre pas la conformité des autres

Sur la page marchande observée, examiner cinq liens revient à examiner 2,8 % des liens rendus. Cela peut révéler un problème. Cela ne permet pas, à soi seul, de conclure que les 176 autres satisfont les exigences applicables.

Le RGAA repose sur un échantillon représentatif de pages. Cet échantillonnage ne doit pas être confondu avec la sélection arbitraire de quelques objets à l’intérieur de chaque page. Les procédures officielles demandent notamment de rechercher les éléments concernés, puis d’appliquer les vérifications prévues à chaque occurrence pertinente. [2][3]

L’auditeur peut organiser son travail, analyser les composants mutualisés et réutiliser des constats lorsque leur identité est établie. Il ne peut pas présumer que tous les contenus suivent correctement le même modèle : un composant identique peut contenir une image différente, un intitulé vide ou un texte dont le contraste change.

Ne pas trouver d’erreur sur quelques objets n’est pas une preuve de conformité de l’ensemble.

Un objet peut nécessiter plusieurs vérifications

Prenons une carte produit avec une photographie, un lien et un bouton.

Pour l’image, il faut notamment déterminer sa fonction, identifier l’alternative prévue et, lorsqu’elle est nécessaire, en apprécier la pertinence. La présence d’un attribut ne suffit pas à répondre à toutes ces questions.

Pour le lien, l’intitulé et le contexte autorisé par la méthode doivent être examinés. Pour le bouton, il peut être nécessaire de vérifier son nom, son utilisation au clavier et la restitution de son rôle ou de son état. Les textes et les composants soulèvent aussi des questions de contraste et de présentation. [3]

Il ne s’agit pas d’appliquer mécaniquement tous les tests à tous les objets. Il faut déterminer l’applicabilité, puis effectuer les vérifications correspondantes.

À cette répétition s’ajoute la diversité des états : menu fermé puis ouvert, filtre appliqué, message d’erreur affiché, fenêtre modale active, formulaire soumis. Une photographie de la page au chargement ne couvre pas tout le fonctionnement du service.

Le nombre d’objets donne une première idée du volume ; les états et les tests applicables déterminent la profondeur de l’évaluation.

Des centaines de points de vérification sur une seule page

Les 106 critères et les 13 thématiques organisent l’évaluation. Ils ne sont pas un multiplicateur uniforme : un critère portant sur les vidéos ne s’applique pas à tous les liens ; une vérification du titre de page ne se répète pas pour chaque image.

Pour donner un ordre de grandeur, construisons un modèle pédagogique de charge, à partir des objets effectivement comptés. Les quantités d’objets sont observées ; les coefficients ci-dessous sont des hypothèses explicites, pas des moyennes mesurées ni une prescription du RGAA.

Ces dimensions renvoient notamment aux thématiques Images, Liens, Scripts, Structuration de l’information, Présentation de l’information et Formulaires. Les critères concernés dépendent du type d’objet : par exemple 6.1 pour les liens, 7.3 pour les interactions scriptées, 10.7 pour la visibilité du focus, 1.1 à 1.3 pour le traitement des images et 9.1 pour les titres. [3]

Un point de revue désigne ici une dimension à examiner pour une occurrence, pas un test RGAA distinct ni une manipulation chronométrée. Un parcours au clavier peut documenter plusieurs points à la fois ; une même observation peut contribuer à plusieurs conclusions. L’applicabilité et les éventuelles équivalences doivent être établies dans l’audit réel.

La page « moyenne » donne ici légèrement moins de points que l’article : sa complexité fonctionnelle vient notamment de ses contenus dépliables, dont les différents états ne sont pas modélisés dans ce calcul. Le volume d’objets et la complexité ne sont pas interchangeables.

Le résultat dépend des hypothèses. Si l’on fait varier le coefficient des interactifs de deux à quatre points, en conservant les autres coefficients, la page complexe passe de 544 à 954 points de revue potentiels. Ce n’est pas un intervalle statistique : c’est une analyse de sensibilité du modèle.

Ce modèle laisse de côté les SVG, les contrastes, les listes, les tableaux, les cadres, les médias, les contrôles globaux de page et les autres états des composants. Les 13 thématiques doivent néanmoins être examinées pour déterminer ce qui s’applique. Il ne permet donc pas de calculer le nombre total de tests nécessaires à un audit complet.

Le message à retenir : même en ne modélisant que trois familles d’objets, le catalogue représente environ 750 points de revue potentiels. Ce volume explique l’intérêt de systématiser les vérifications répétitives avec un outil fiable, tout en conservant les contrôles et décisions qui nécessitent l’expertise humaine.

Trouver une erreur et établir la conformité sont deux travaux différents

Une seule occurrence en échec peut suffire à invalider un critère. Il n’est donc pas toujours nécessaire d’inventorier toutes les erreurs pour établir ce verdict.

En revanche, déclarer ce critère conforme suppose que les vérifications applicables soutiennent cette conclusion. Et préparer une correction complète demande souvent d’aller plus loin que la première occurrence fautive. [2][3]

Cette distinction explique pourquoi deux prestations peuvent produire des grilles proches, mais des livrables très différents :

• un état de conformité avec des exemples de non-conformités ;
• un inventaire plus étendu des occurrences à corriger ;
• des résultats permettant de vérifier les corrections et de repérer les régressions.

Le premier peut être un audit rigoureux. Le deuxième et le troisième apportent une couverture opérationnelle supplémentaire. Le client doit savoir ce qui est inclus.

Quelques validations injustifiées peuvent changer la déclaration

Prenons un exemple de calcul fictif, avec 80 critères applicables sur un échantillon donné.

Quatre validations erronées suffisent ici à faire passer le résultat sous le seuil de 50 %. Dans le cadre déclaratif du RGAA, ce seuil distingue l’état de conformité partielle de l’état de non-conformité. Ce calcul illustre un mécanisme ; il ne décrit aucun audit observé. [4]

Une grille complète en apparence peut donc conduire à une déclaration inexacte si certaines conclusions reposent sur des vérifications insuffisantes.

Le risque ne se limite pas au score : des obstacles restent invisibles dans le plan de correction et les équipes peuvent considérer, à tort, qu’un sujet est réglé.

Le client doit pouvoir justifier ce qu’il publie

La DINUM indique que l’organisme concerné doit veiller à la fiabilité de sa déclaration, y compris lorsqu’il recourt à un prestataire externe. La déclaration doit résulter d’une évaluation effective. [2][4]

Une erreur du prestataire peut soulever une question de responsabilité contractuelle. Elle ne rend pas exacte la déclaration publiée et ne dispense pas l’organisme de traiter ses propres obligations.

Pour les organismes relevant de l’article 47, l’article 47-1 prévoit un contrôle de l’Arcom, une mise en demeure et des sanctions possibles en cas de non-respect persistant. Les plafonds sont de 25 000 euros pour les obligations des III et IV de l’article 47, et de 50 000 euros pour l’obligation d’accessibilité du I, ce second contrôle visant les personnes mentionnées aux 1° à 3° du I. Les entreprises du 4° relèvent, dans ce dispositif, du contrôle des obligations des III et IV. [5]

Ces plafonds ne sont pas une amende automatique pour toute erreur d’audit. Le régime applicable, le manquement et la procédure doivent être établis. D’autres obligations peuvent concerner certains produits et services ; elles ne doivent pas être confondues avec ce dispositif.

Inutile non plus de présumer une fraude. Une conclusion inexacte peut venir d’une omission, d’une méthode inadéquate ou d’une mauvaise interprétation. L’intention exige des éléments distincts. Pour le client, l’urgence est d’obtenir une évaluation justifiable et de corriger les informations erronées.

Un audit fiable exige un outillage fiable et une méthode explicite

Le RGAA n’impose pas l’achat d’un logiciel commercial particulier. Sa méthodologie mentionne notamment le navigateur, l’inspecteur de code et les technologies d’assistance requises par certains tests. [6]

Le problème n’est donc pas de savoir si l’auditeur utilise une marque donnée. Il est de savoir comment il inventorie les éléments, effectue les mesures, vérifie les comportements, documente les conclusions et maîtrise les omissions.

À mesure que les pages, les objets et les versions se multiplient, effectuer ces tâches répétitives sans automatisation augmente l’effort nécessaire et rend la couverture plus difficile à maintenir. L’expérience de l’auditeur reste indispensable ; elle ne remplace pas un calcul de contraste, une inspection technique ou un test de restitution requis.

L’exigence doit être la même pour les logiciels. Le W3C rappelle qu’un outil ne peut pas déterminer seul tous les aspects de l’accessibilité, que le jugement humain reste nécessaire et que les résultats automatiques peuvent être inexacts. Un logiciel qui valide sans preuve ne résout pas le problème : il l’industrialise. [7]

Ce que doit apporter une solution comme appYaccess

L’intérêt d’appYaccess est de systématiser les contrôles automatisables et de structurer les résultats par page, critère, test et élément concerné. Les règles déterministes permettent de rejouer les vérifications dans des conditions maîtrisées ; les points nécessitant une appréciation ou une validation humaine restent identifiés. [8]

Le bénéfice attendu pour l’auditeur et son client est concret : limiter les oublis répétitifs, retrouver les éléments à corriger, vérifier les modifications et contrôler plus fréquemment le périmètre suivi.

La couverture méthodologique des 106 critères ne signifie pas que tous leurs tests sont automatisés. Une déclaration ne doit pas être finalisée en transformant les validations restantes en conformités présumées.

Sur votre propre page, demandez à voir ce qui a été inventorié, ce qui a été effectivement vérifié et ce qui reste à examiner. Cette démonstration est plus utile qu’un pourcentage d’automatisation annoncé sans périmètre.

Avant de choisir un audit à 1 000 euros ou à 15 000 euros

Le prix seul ne permet pas de conclure qu’une prestation est fiable ou insuffisante. Un périmètre réduit et un travail bien outillé peuvent diminuer le coût. Un devis plus élevé ne garantit pas davantage une bonne couverture.

Avant de commander, faites préciser :

• les pages, processus et états inclus dans l’évaluation ;
• la couverture des critères applicables et les éventuelles exclusions ;
• les outils, environnements et tests de restitution prévus ;
• la manière dont les conclusions de conformité sont justifiées ;
• le niveau de recensement des occurrences à corriger ;
• les validations humaines restantes et les conditions de contre-audit.

Ces éléments constituent des exigences d’achat et de pilotage recommandées, pas l’affirmation que la réglementation imposerait un export technique de chaque objet.

Un audit bon marché devient coûteux s’il vous conduit à publier un résultat que vous ne pouvez pas justifier. À l’inverse, un audit outillé et rigoureux peut réduire la charge sans réduire la profondeur des vérifications.

Votre organisation publie la déclaration. Avant d’en reprendre le score, exigez une méthode dont vous pouvez comprendre et vérifier les conclusions.

Découvrez les contrôles et le suivi avec appYaccess ou examinez les résultats sur une de vos pages.

Sources et protocole de comptage

Références consultées le 4 novembre 2026. Le cadre technique présenté est le RGAA 4.1.2.

1. WebAIM Million 2026 : corpus, limites de l’automatisation, complexité des pages et moyennes par famille.
2. DINUM : Évaluation de la conformité : fiabilité, représentativité, échantillon et calcul du taux.
3. DINUM : Critères et tests RGAA : procédures applicables aux éléments et aux comportements.
4. DINUM : Déclaration d’accessibilité : évaluation effective et états de conformité.
5. Légifrance : Article 47-1 de la loi du 11 février 2005 : périmètre des contrôles, mise en demeure et plafonds de sanction.
6. DINUM : Méthodologie de test : navigateur, inspecteur et technologies d’assistance.
7. W3C : Selecting Web Accessibility Evaluation Tools : capacités et limites des outils.
8. Quadran : appYaccess : fonctionnalités et validations humaines à compléter.

Pages inventoriées : article Quadran, accueil Quadran et catalogue Decathlon. Les comptages constituent trois observations ponctuelles de volume, sans jugement sur leur conformité et sans benchmark de performance d’appYaccess.

Pour reproduire l’inventaire : charger le document principal en bureau ; exclure les éléments sous #wpadminbar, script, style, noscript et template ; compter les sélecteurs ci-dessous ; pour la colonne rendue, conserver ceux dont getClientRects().length est supérieur à zéro et dont la propriété CSS visibility calculée diffère de hidden. Aucun parcours des cadres ou racines Shadow DOM n’est effectué. Les résultats peuvent varier avec le contenu, les expérimentations du site et l’état de session.

L’inventaire observé des objets est distinct du modèle pédagogique de points de revue. Les coefficients de ce modèle sont des hypothèses de calcul ; ils ne constituent ni un décompte des tests RGAA effectivement applicables, ni une estimation de durée, ni une mesure de performance d’appYaccess.