Lire un rapport d’audit d’accessibilité

Un rapport n’est utile que si l’on sait ce qu’il a examiné, ce que ses résultats signifient et comment organiser les suites.

Ce guide donne des repères de lecture. Le périmètre et les méthodes varient d’un audit à l’autre : appuyez-vous toujours sur les précisions du rapport reçu.

Avant de regarder un taux ou une liste de problèmes, vérifiez ce qui a été audité. Les résultats décrivent un périmètre défini à une date donnée ; ils ne résument pas à eux seuls toute l’expérience du service.

Comprendre le périmètre

Un audit examine un échantillon défini du service, pas nécessairement chaque page et chaque situation. Repérez d’abord ces informations dans le rapport ou dans la proposition qui a cadré la mission :

Le service et sa version: Quel site, quelle application ou quel environnement a été examiné ? À quelle date et sur quelle version ?
L’échantillon: Quelles pages, gabarits, fonctionnalités et étapes de parcours ont été testés ? Un formulaire ou une démarche en plusieurs étapes est-il couvert de bout en bout ? Les limites de l’échantillon sont-elles précisées ?
La méthode: Quel référentiel et quelle version sont indiqués ? Quels contrôles manuels et automatisés ont été réalisés ? Quels navigateurs, appareils ou outils d’assistance figurent dans l’environnement de test ?

Un même gabarit peut être utilisé par plusieurs pages, mais un contrôle sur une page ne prouve pas automatiquement que toutes ses variantes ont été vérifiées. Si le périmètre ou la couverture d’un parcours reste flou, demandez une précision avant de tirer une conclusion générale sur le service.

Lire les résultats

Un rapport peut contenir plusieurs niveaux d’information. Les distinguer évite de confondre la règle, la façon de la vérifier et le problème réellement observé :

Le critère: Décrit l’exigence d’accessibilité à vérifier.
Le test: Décrit comment vérifier cette exigence dans une situation donnée.
Le constat: Indique ce qui a été trouvé, où cela a été trouvé et, idéalement, qui ou quelle tâche peut être affectée.
La recommandation: Suggère une correction ; l’équipe doit la confronter à son code, ses contenus et son fonctionnement.

Dans le RGAA, les résultats des critères sont notamment présentés comme conformes, non conformes ou non applicables. Le rapport doit permettre de comprendre sur quel élément et quel test repose le résultat.

Conforme: Le contrôle décrit dans le rapport satisfait le critère pour les éléments testés.
Non conforme: Un obstacle a été relevé ; lisez le contexte, les conséquences et les exemples associés.
Non applicable: Le critère n’a pas été retenu comme applicable au périmètre examiné ; vérifiez la justification.

Décrypter un constat de bout en bout

Exemple fictif, pour illustrer la lecture d’une ligne de rapport — ce n’est pas un constat réalisé par numera11y.

Ligne du rapport: Formulaire de contact · champ « Courriel » · critère 11.1 · non conforme
Ce qui a été observé: Dans cet exemple, le champ n’a pas de nom accessible qui indique sa fonction aux outils d’assistance.
La conséquence possible: Une personne qui utilise un lecteur d’écran peut ne pas savoir quelle information saisir dans ce champ.
La correction à examiner: Associer au champ un libellé visible et correctement relié au contrôle, sans compter sur le texte indicatif du champ comme seul repère.
Comment vérifier: Reprendre le formulaire avec un lecteur d’écran : le champ doit être annoncé avec son nom, puis pouvoir être renseigné et validé dans le parcours.

Le rapport réel devrait apporter ses propres captures, détails techniques et références de test. Cet exemple montre comment passer d’un résultat à une question d’usage, puis à une vérification après correction.

Organiser les priorités

Un rapport peut fournir une hiérarchisation et des recommandations. Les catégories d’impact ou de priorité sont propres à la méthode du rapport ; elles ne remplacent pas les critères ni les niveaux du référentiel. Pour décider de l’ordre des corrections, mettez les constats en regard des usages de votre service :

Impact : une tâche importante est-elle bloquée ou rendue particulièrement difficile ? Existe-t-il un autre moyen de l’accomplir ?
Étendue : le même obstacle apparaît-il sur plusieurs pages, dans un composant partagé ou à plusieurs étapes d’un parcours ?
Dépendances : quelle équipe peut corriger le problème ? Faut-il modifier le contenu, le composant commun, le code ou l’organisation du service ?

Une correction d’un composant partagé peut résoudre plusieurs occurrences ; à l’inverse, une anomalie unique peut empêcher une démarche essentielle. Le classement du rapport est un point de départ à discuter avec les responsables du service et les équipes qui devront intervenir.

Préparer la suite

Transformez les constats retenus en actions suivies par votre équipe. Une carte de correction utile peut tenir dans ces cinq champs :

Où : page, composant ou étape du parcours concerné.
Quoi : constat et critère associés, avec la recommandation utile.
Qui : personne ou équipe chargée de la correction.
Quand : échéance décidée selon l’impact, les dépendances et la capacité de l’équipe.
Comment vérifier : test à refaire et preuve attendue après correction.

Prévoyez une vérification adaptée après correction, puis mettez à jour le suivi interne et les informations publiques concernées lorsque c’est nécessaire. Un audit reste une observation du périmètre et de la version examinés ; il ne constitue pas une certification ni une garantie permanente sur le service.