Un audit produit deux choses : un taux de conformité et des recommandations. Le taux intéresse le commanditaire. Les recommandations intéressent l’équipe qui va corriger. Mais entre les deux, il y a souvent un écart : les recommandations sont rédigées pour des auditeurs, pas pour des clients.
“Critère 1.1 non conforme : l’image ne possède pas d’attribut alt.” C’est exact. Ce n’est pas utile pour quelqu’un qui ne sait pas ce qu’est un attribut alt, ni pourquoi son absence pose problème.
Ce qu’un client non technique a besoin de comprendre
Trois informations suffisent pour qu’une recommandation soit actionnable :
Qui est impacté. Pas “les utilisateurs de lecteurs d’écran” comme abstraction, mais une situation concrète. Une personne aveugle qui navigue au clavier. Une personne malvoyante qui utilise une loupe d’écran. Quelqu’un qui a désactivé les images pour économiser de la bande passante.
Ce qu’il ne peut pas faire. Pas “l’image n’est pas accessible”, mais ce que l’absence d’alternative bloque concrètement. Il ne sait pas ce que l’image représente. Il rate une information nécessaire pour comprendre le contenu. Il ne peut pas accomplir l’action que l’image illustre.
Ce qu’il faut corriger. Une instruction claire, sans jargon superflu. Pas “implémenter un attribut alt conforme aux spécifications WCAG 2.1”, mais “ajouter une description courte de l’image dans le champ alt de votre médiathèque WordPress”.
Un exemple concret
Situation : une page présente un graphique montrant l’évolution du budget municipal sur cinq ans. Le graphique est une image sans alternative textuelle.
Version technique :
Critère 1.1 : Non conforme. L’image
graphique-budget.pngne possède pas d’attributalt. Les informations véhiculées par l’image ne sont pas restituées aux technologies d’assistance.
Version argumentée :
Le graphique montrant l’évolution du budget sur cinq ans n’a pas de description textuelle. Un utilisateur qui ne voit pas l’image (lecteur d’écran, image non chargée) ne peut pas accéder à ces données. Il faut ajouter une alternative qui restitue l’information principale : par exemple “Graphique : le budget municipal a augmenté de 12% entre 2020 et 2024, passant de 4,2 à 4,7 millions d’euros.” Si les données détaillées sont importantes, les présenter aussi dans un tableau sous le graphique.
La deuxième version prend plus de place. Elle est aussi la seule qui permet au client de comprendre pourquoi corriger, et à l’intégrateur de savoir quoi écrire.
Les formulations qui bloquent la compréhension
Certaines formulations récurrentes dans les rapports d’audit créent de la distance avec le client.
Le nom du critère sans explication. “Critère 3.3 non conforme” ne dit rien à quelqu’un qui ne connaît pas le RGAA. Citer le critère est utile pour la traçabilité, pas pour la compréhension. Le mettre en référence secondaire, pas en titre de recommandation.
Le jargon technique non défini. “Contraste insuffisant”, “landmark manquant”, “focus non visible” : ces termes ont un sens précis pour un auditeur, aucun pour un chef de projet ou un élu. Soit on les définit en une phrase, soit on les reformule.
La recommandation générique. “Améliorer l’accessibilité des formulaires” ne dit pas quoi faire. Une recommandation utile cible un élément précis, décrit le problème, et propose une correction.
L’accumulation sans priorisation. Un rapport de 80 non-conformes sans ordre de priorité est paralysant. Le client ne sait pas par où commencer. Regrouper par impact ou par facilité de correction aide à rendre le rapport actionnable.
Distinguer l’impact selon les utilisateurs
Toutes les non-conformités n’ont pas le même impact. Un bouton sans nom accessible bloque complètement un utilisateur de lecteur d’écran : il ne peut pas savoir ce que fait le bouton, ni l’activer. Un texte en italique sur fond blanc avec un contraste légèrement insuffisant gêne un utilisateur malvoyant sans le bloquer totalement.
Signaler cette différence dans le rapport aide le client à prioriser. Deux niveaux suffisent pour commencer :
- Bloquant : l’utilisateur ne peut pas accomplir la tâche, quelle que soit la façon dont il contourne le problème.
- Gênant : l’utilisateur peut accomplir la tâche, mais avec une friction significative.
Cette distinction n’est pas dans le RGAA, qui note conforme ou non conforme sans gradation. Elle est dans le rapport, comme information complémentaire au service du client.
Ce que ça change pour la relation client
Un rapport argumenté fait deux choses qu’un rapport technique ne fait pas.
Il rend le problème réel. “Un utilisateur aveugle ne peut pas savoir ce que représente cette image” est plus concret que “l’attribut alt est absent”. Le client comprend qu’il y a quelqu’un derrière le critère, pas seulement une règle à cocher.
Il rend la correction possible. Une équipe qui comprend pourquoi quelque chose pose problème corrige mieux qu’une équipe qui applique une instruction sans contexte. Et elle pose moins de questions en cours de correction.
Rédiger des recommandations compréhensibles prend plus de temps qu’exporter une liste de critères non conformes. C’est aussi la partie du travail qui a le plus d’impact sur la suite.