Mesurer : audit RGAA, déclaration, maintien

Mesurer : audit, déclaration et maintien dans la durée

1. L'audit RGAA, étape par étape

   Le RGAA fournit, pour chacun de ses 106 critères, une liste de tests à réaliser. La méthode est reproductible, ce qui est son avantage principal : deux evaluates personnes produisent le même résultat.

   L'ordre : ce qu'il faut savoir avant d'ouvrir le navigateur

   1. Périmètre. Quelles pages ? Un audit « du site » n'existe pas : on audite un échantillon représentatif, sinon on audite la page d'accueil et on conclut.
   2. Profil d'utilisateur. Mobile uniquement, desktop uniquement, ou les deux. L'écart entre les deux profils est souvent plus important que la liste des erreurs.
   3. Environnement de test. Navigateur, technologies d'assistance, niveau d'zoom, connexion. Un audit réalisé sur le poste du développeur en 400 % de zoom n'est pas l'usage réel.

   Les quatre phases de l'évaluation

   1. Collecte. Contenu, fonctionnalités, liste des technologies d'assistance visées.
   2. Audit automatique. Filtre, avec un rapport d'erreurs par page. On ne corrige pas encore : on mesure l'écart.
   3. Audit manuel. Les tests RGAA, paragraphe par paragraphe, avec traçabilité — pour chaque critère, la page et le résultat.
   4. Synthèse. Taux de conformité par critère, par thème et globalement, avec la liste des écarts.

   Lire un taux de conformité

   Un « 90 % de conformité » est un chiffre sans sens pris isolément, et c'est le piège le plus coûteux de la démarche. Un site à 92 % dont les 8 % d'échecs portent sur la navigation clavier et les erreurs de formulaire est inutilisable pour les personnes concernées. Un site à 75 % dont les échecs portent sur des contrastes secondaires est très utilisable.

   Ce qui compte, c'est la répartition : quels critères échouent. Un seul critère de niveau A bloquant (navigation clavier, nom accessible) pèse plus que trente écarts de contraste sur des éléments secondaires.

2. Outillage : ce que chaque outil apporte, et son angle mort

   Les outils automatiques

   • RGAA & DevTools — extension qui liste les erreurs par critère RGAA. Utile au quotidien, pour repérer les régressions.
   • Lighthouse et son volet accessibilité — integrated à Chrome DevTools, il donne une note et une liste. Le score est un indicateur de tendance, pas une mesure de conformité : il ne couvre qu'une partie des critères et son poids ne correspond pas au niveau A / AA.
   • axe-core — la base de Lighthouse, utile en intégration continue pour bloquer une régression sur un seuil.

   Les outils de test manuel

   • Lecteur d'écran — indispensable. VoiceOver sur Mac, NVDA sous Windows. Il ne faut pas se contenter de l'ARIA Tree : il faut écouter le rendu réel, avec ses silences et ses répétitions.
   • Inspecteur d'accessibilité de DevTools — pour voir ce que la technologie d'assistance va annoncer, y compris l'arbre de rôles et les règles de nommage. Vérification de trente secondes, à faire sur chaque composant sur mesure.
   • Vérificateur de contraste — pour les textes posés sur fond coloré ou image.

   Les tests qui ne s'outillent pas

   • Le parcours au clavier, chronométré, sur les tâches réelles.
   • Le test en 400 % de zoom et en 320 px de largeur, sur un vrai téléphone en connexion dégradée.
   • La relecture des messages d'erreur par quelqu'un qui n'a pas écrit le formulaire.
   • La question « qu'est-ce que ce bouton fait ? » posée à un utilisateur réel quand le bouton ne porte qu'une icône.

   L'angle mort commun : le test en conditions dégradées

   Un audit réalisé sur le poste du développeur — grand écran, bonne connexion, souris, à 100 % de zoom — est presque toujours optimiste. Les deux situations qui font le plus de dégâts sont l'accès dégradé (3G, CPU lent) et l'usage en mobilité (une main, en marchant, au soleil). Un site peut passer 100 % des tests automatisés et s'effondrer dans ces deux cas.

3. La déclaration d'accessibilité : ce qu'elle engage

   La déclaration n'est pas un formulaire administratif : c'est un engagement daté, et sa valeur tient entièrement à sa sincérité.

   Les quatre mentions attendues

   1. L'état de conformité constaté — « partiellement conforme », avec le nombre de pages auditées et le périmètre. « Conforme » est le seul état qui somme annoncé sans réserve ; il suppose un audit complet et sans écart.
   2. Le contenu et les méthodes de l'évaluation — pages auditées, outils utilisés, technologies d'assistance testées.
   3. Les écarts identifiés et leur justification. Pour chaque écart : sa nature, son impact, et pourquoi il n'a pas été corrigé. Un écart justifié est défendable ; un écart non signalé est un risque.
   4. La voie de recours — où déposer un signalement d'inaccessibilité, et qui le traite.

   Les trois formulations à éviter

   • « Ce site est conçu pour être accessible » — c'est une déclaration d'intention, pas un état de conformité. Elle n'apporte rien et n'engage personne.
   • « Nous nous efforçons de rendre ce site accessible » — le même problème, sous forme d'engagement creux : ni périmètre, ni méthode, ni date.
   • « 95 % conforme » — un pourcentage global sans répartition ne dit pas si le parcours principal est utilisable. Il ne dit rien.

   Ce que laDinum et le RGAA disent de l'avenir

   Le RGAA 5 est attendu fin 2026. La Dinum est explicite sur deux points qui doivent guider la rédaction dès aujourd'hui : les critères du RGAA 5 préciseront ou compléteront ceux du 4.1.2 sans les infirmer, et les déclarations d'accessibilité établies avant cette publication resteront valables 18 mois, dans la limite de trois ans à compter de leur date de publication.

   La lecture qui s'impose pour un projet en cours : il ne faut pas attendre le RGAA 5, mais il ne faut pas non plus s'y enfermer. Travailler avec le 4.1.2 dès maintenant est le bon calcul, à condition de viser le niveau AA — le niveau qui ne changera pas d'une version à l'autre, puisque le RGAA ne fixe pas de niveau AAA.

4. Tenir dans la durée : la régression silencieuse

   Un audit ponctuel produit une photo. La question est ce qui reste trois mois plus tard, après six livraisons.

   Pourquoi ça se dégrade sans bruit

   Une régression d'accessibilité ne casse rien de visible. Une mise à jour de dépendance remplace un composant par un div : le site est identique à l'œil, et le clavier ne fonctionne plus. Un design system pose outline: none sur tous les champs pour « clean » : le focus disparaît sur cent formulaires. Un banner de consentement couvre la moitié de l'écran en bas : le critère 2.4.11 est satisfait, puis violé par le bandeau suivant. Aucun de ces changements ne déclenche une alerte, parce qu'aucun ne casse une fonctionnalité pour la majorité des utilisateurs.

   Les cinq verrous, du moins cher au plus cher

   1. Le design system interdit outline: none sans remplacement visible, et fournit l'indicateur de focus par défaut. Une règle de lint CSS suffit à le tenir.
   2. Les composants sur mesure sont vérifiés au prototypage, pas à la livraison : inspecteur d'accessibilité, parcours clavier, test en 400 % de zoom. C'est le moment le moins cher.
   3. L'audit automatique tourne à chaque livraison avec un seuil bloquant sur les erreurs de niveau A. On ne bloque pas sur un score global, on bloque sur la régression.
   4. Le parcours clavier est dans la recette : il figure dans la check-list de mise en production, avec une personne désignée. Ce qui n'est pas dans la recette n'existe pas.
   5. La déclaration est révisée à chaque évolution majeure, et à date fixe sinon. Une déclaration de plus de douze mois est une déclaration périmée.

   La question qui décide du budget

   « Est-ce qu'on fait ce travail maintenant, ou est-ce qu'on va le faire plus tard ? » La réponse qui trompe est « plus tard, ce sera moins cher ». Le vrai calcul est inverse : un écart d'accessibilité est d'autant plus cher qu'il est trouvé tard, parce qu'il a été répliqué, documenté, testé et repris dans des cas de test. Le coût d'un défaut trouvé au prototypage est d'une heure ; le même défaut trouvé à la deuxième année est un projet.