Tests automatiques et audit manuel : comparer la couverture

Mis à jour le 1er octobre 2026 · Rédaction : Plein Accès

Donner une fonction précise au scan

Un outil automatique peut parcourir des pages et signaler certains défauts détectables dans le code ou le rendu. Il peut aider à retrouver une erreur répétée dans un modèle et à suivre son évolution. Le résultat dépend des règles utilisées, des pages atteintes et de leur état au moment du contrôle. Demandez donc ce qui a été examiné, avec quels paramètres et quelles limites. Un nombre de problèmes sans couverture connue ne permet pas de qualifier tout le service.

Le W3C explique qu’aucun outil seul ne peut déterminer l’accessibilité d’un site. Une évaluation doit intégrer une appréciation humaine. Le scan peut faire partie d’un audit, mais son score ne doit pas être confondu avec le taux d’une évaluation RGAA. Le guide du rapport décrit les preuves nécessaires pour comprendre les résultats livrés et leur relation aux critères applicables.

Vérifier le sens de l’information

Certains contrôles demandent de comprendre la fonction d’un contenu. Une image peut avoir une alternative textuelle présente dans le code, mais inadéquate pour l’action de l’utilisateur. Un lien peut posséder un texte sans expliquer sa destination dans son contexte. L’auditeur doit observer le contenu et décider ce que l’usager doit pouvoir comprendre. La présence technique d’un attribut n’apporte pas toute cette réponse.

Préparez des exemples représentatifs : illustration de produit, bouton avec pictogramme et document à télécharger. Demandez au rapport d’expliquer pourquoi l’information est suffisante ou insuffisante. Cette preuve doit pouvoir être discutée avec l’équipe éditoriale. Une recommandation utile peut proposer la fonction du texte attendu sans inventer une description qui ne correspond pas au produit ou au service.

Parcourir les interactions au clavier

Le test au clavier suit une action complète : ouvrir le menu, choisir une option, remplir un formulaire et traiter une erreur. Il faut examiner l’ordre de progression et la possibilité de retrouver le contexte après un changement. Un bouton présent dans le code peut rester difficile à atteindre ou son action peut laisser l’utilisateur dans une position imprévisible. Le rapport doit décrire le chemin suivi et l’obstacle observé.

Les fenêtres et les éléments dynamiques méritent des scénarios dédiés. Notez ce qui doit se passer à l’ouverture, pendant l’usage et à la fermeture. La gestion du focus doit être examinée dans les cas pertinents, avec les méthodes prévues au contrat. Le guide des corrections montre comment rattacher ces constats à des critères de réception plutôt qu’à une consigne générale de « rendre le composant accessible ».

Examiner la restitution avec les technologies d’assistance

Le lecteur d’écran apporte une autre observation que le clavier seul. Il permet d’examiner les noms, les rôles et les informations d’état restituées dans l’environnement retenu. Un changement visible peut ne pas être annoncé ; une erreur peut perdre sa relation avec le champ concerné. Demandez la combinaison de système, navigateur et technologie d’assistance utilisée. La preuve doit distinguer le défaut observé d’une hypothèse sur tous les autres environnements.

La base de référence doit être annoncée avant l’audit et reprise dans le rapport. Des tests supplémentaires peuvent être utiles selon le public et le service, sans être présentés comme une garantie de fonctionnement universel. Si l’organisation connaît les postes de ses utilisateurs, cette information peut aider au cadrage. L’équipe doit comprendre les limites des vérifications pour décider si une investigation complémentaire est nécessaire.

Combiner les contrôles dans le suivi

Après une correction, un test automatique peut vérifier une règle répétitive tandis qu’un scénario humain examine le comportement. Conservez les deux lorsque leur fonction est claire. La chaîne de livraison peut intégrer des contrôles qui détectent rapidement une régression, mais la recette doit garder des parcours manuels pour les interactions importantes. Une règle automatique passée ne valide pas une fonction qui n’a pas été atteinte.

Pour acheter la prestation, demandez au candidat la couverture manuelle et les preuves de résultat. Le guide de choix du prestataire aide à préparer cette discussion. Si vous commandez seulement un diagnostic automatisé initial, nommez-le ainsi et définissez ce qu’il doit déclencher ensuite. L’évaluation de conformité nécessite un périmètre et une méthode permettant de justifier les résultats, pas seulement un tableau de bord.

Questions sur les outils automatiques

Un score parfait prouve-t-il l’accessibilité ?

Il indique seulement le résultat des règles appliquées sur la couverture observée. Les vérifications humaines et les interactions non atteintes restent à examiner.

Les tests utilisateurs remplacent-ils l’audit de conformité ?

Ils peuvent révéler des obstacles d’usage précieux. L’audit conserve sa méthode critère par critère ; les deux démarches doivent être décrites avec leurs objectifs distincts.

Faut-il supprimer les scans du projet ?

Non. Ils sont utiles lorsque leur rôle et leurs limites sont explicites. Demandez comment leurs résultats sont vérifiés, complétés et transformés en tâches de correction.

Sources vérifiées le 1er octobre 2026

W3C : document de référence