# Un audit d’accessibilité manuel qui contredit un score automatisé à 100 %

> L'outil automatisé affiche fièrement 100 %. L'audit manuel qui suit trouve pourtant huit anomalies bloquantes. Comment expliquer un tel écart au client ?

- Auteur : Clément Hadrot
- Publié le : 2025-08-06
- Mis à jour le : 2025-08-06
- Catégorie : Accessibilité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/accessibilite/audit-manuel-contredit-score-automatise-100/

## L’essentiel

- Un score automatisé ne teste que ce qui est détectable par du code, jamais l'usage réel
- Les anomalies de logique clavier échappent presque toutes aux scanners
- Présenter l'écart au client demande de rendre visible ce que l'outil ne voit pas

Le client avait fait tourner un scanner d'accessibilité en ligne avant de nous confier l'audit RGAA complet. Le rapport automatisé affichait 100 %, aucune anomalie détectée. Notre audit manuel, sur les mêmes pages, a remonté huit anomalies bloquantes, dont trois empêchaient purement et simplement de valider le formulaire de devis au clavier.

Ce paradoxe revient régulièrement, et il mérite d'être expliqué clairement plutôt que balayé d'un « les scanners ne servent à rien ». Voici le diagnostic complet de cet écart, cas par cas.

## Symptôme

Le rapport automatisé du client, généré par un scanner populaire, affiche un score parfait sur les trois pages testées : accueil, page de service, formulaire de devis. Le client, rassuré, nous demande de confirmer ce résultat par un audit complémentaire « pour la forme ». L'audit manuel révèle une tout autre réalité.

## Diagnostic — ce que l'outil ne peut pas voir

> L'essentiel à retenir : Un score automatisé ne teste que ce qui est détectable par du code, jamais l'usage réel ; Les anomalies de logique clavier échappent presque toutes aux scanners ; Présenter l'écart au client demande de rendre visible ce que l'outil ne voit pas

En reprenant chaque anomalie trouvée manuellement, un motif se dégage : aucune ne repose sur un défaut de balisage détectable par une analyse statique du DOM. Toutes relèvent de la logique d'interaction :

- Le focus, à l'ouverture d'une fenêtre modale de prise de rendez-vous, ne se déplace jamais dans la fenêtre : indétectable sans exécuter réellement le clavier
- Un menu déroulant affiche visuellement ses sous-options au survol, mais elles restent atteignables au `Tab` même fenêtre fermée : un piège invisible pour un scanner qui n'observe pas l'état visuel réel
- Le message de succès du formulaire de devis s'affiche dans une zone du DOM sans `aria-live`, mais avec un `role="status"` mal positionné qui trompe certains scanners en le comptant comme conforme
- L'ordre de tabulation saute par-dessus le bouton d'envoi du formulaire à cause d'un `tabindex` positif ailleurs sur la page — un problème de séquence, pas de présence

## Pourquoi le scanner ne voit rien de tout ça

Les outils automatisés excellent sur les critères structurels : présence d'un attribut `alt`, contraste calculable entre deux couleurs, existence d'une étiquette de formulaire. Ils échouent presque systématiquement sur tout ce qui relève du comportement dynamique : gestion du focus, cohérence de l'ordre de tabulation réel, pertinence contextuelle d'un message annoncé. Selon les études indépendantes disponibles, les outils automatisés les plus complets détectent rarement plus de 30 à 40 % des critères RGAA, tous les autres nécessitant une vérification humaine.

## Correctif

Les quatre anomalies ont été corrigées en une itération courte, aucune ne demandant une refonte lourde :

1. Ajout d'un déplacement de focus explicite à l'ouverture de la modale
2. Suppression du survol seul comme déclencheur du sous-menu, remplacé par un clic ou une touche Entrée
3. Repositionnement du message de statut dans une zone `aria-live="polite"` correctement identifiée par les lecteurs d'écran testés
4. Suppression du `tabindex` positif superflu, l'ordre naturel du DOM suffisant une fois la structure corrigée

## Prévention

Pour éviter que ce paradoxe ne se reproduise à chaque nouvelle fonctionnalité, deux mesures ont été mises en place avec le client : une vérification manuelle systématique au clavier pour tout composant interactif ajouté, et une clause dans le cahier des charges des prestataires qui interdit de présenter un score automatisé comme preuve de conformité RGAA.

> Un score automatisé à 100 % ne signifie jamais « conforme ». Il signifie « rien de détectable par cet outil sur ce qu'il sait tester ». La nuance change tout dans la communication avec un client.

## En résumé

L'écart entre un scanner à 100 % et un audit manuel qui trouve des anomalies bloquantes n'a rien d'un bug ou d'une anomalie de mesure : c'est la limite structurelle des outils automatisés, qui ne testent jamais réellement l'usage au clavier ni la cohérence des annonces vocales. Présenter cette limite clairement au client, avec des exemples concrets, évite bien des malentendus lors des audits suivants.