Chapitre 14.2 — Les outils automatiques

⏱️ TL;DR — Les outils automatiques sont ta première couche : rapides, gratuits, ils balaient une page en une seconde et attrapent les fautes mécaniques (contraste, alt absent, ARIA invalide, label manquant). Le plus précis et le plus utilisé est axe (moteur axe-core, extension axe DevTools). Autour : Lighthouse (intégré à Chrome), WAVE, Pa11y, ARC Toolkit. Mais aucun ne juge la pertinence d’un alt, l’ordre logique, ni l’utilisabilité réelle. Leur pire danger, c’est la fausse confiance qu’ils inspirent.

🎯 Objectifs

Connaître les principaux outils automatiques et leur positionnement.
Savoir ce qu’ils détectent de façon fiable.
Savoir ce qu’ils ne peuvent structurellement pas juger.
Les intégrer à ton flux navigateur sans tomber dans la fausse confiance.

Le paysage des outils

Tous s’appuient sur la même idée : parcourir le DOM rendu et le comparer à un jeu de règles. Ils diffèrent surtout par l’ergonomie et le moteur. Le moteur qui fait référence est axe-core (open source, édité par Deque), réputé pour son très faible taux de faux positifs — ce qu’il signale est presque toujours un vrai problème.

Outil	Forme	Particularité
axe DevTools	Extension navigateur (moteur `axe-core`)	La référence : précis, peu de faux positifs, explications claires.
Lighthouse	Intégré à Chrome (onglet dédié)	Pratique, donne un score — mais un sous-ensemble de règles, moteur `axe-core`.
WAVE	Extension / service en ligne	Visuel : superpose des icônes sur la page, très pédagogique.
Pa11y	Ligne de commande / CI	Scriptable, idéal pour automatiser (voir Chapitre 14.5).
ARC Toolkit	Extension navigateur	Inspection fine des composants et de l’ARIA.

Tu n’as pas besoin de tous les cumuler. Un bon socle : axe DevTools pour l’audit précis, Lighthouse pour un aperçu rapide et un score de suivi, WAVE quand tu veux voir les problèmes posés sur la page.

Ce qu’ils détectent (et bien)

Sur le terrain du mesurable, ces outils sont excellents et il serait absurde de s’en priver. Ils repèrent de façon fiable :

Contraste insuffisant entre texte et fond (rapporté au seuil AA).
alt manquant sur une <img>, ou attribut requis absent.
Attributs ARIA invalides : rôle inexistant, aria-* mal orthographié, valeur illégale, combinaison interdite.
Champs de formulaire sans label accessible.
id dupliqués, lang de page absent, titre de page vide.
Structure de base : <html lang>, hiérarchie de titres manifestement cassée.

Tout ça, c’est du temps gagné : autant laisser la machine trouver un alt oublié plutôt que de le chercher à l’œil.

Ce qu’ils ne peuvent PAS juger

Voici la partie que personne ne devrait ignorer. Un outil automatique vérifie la présence et la validité, jamais le sens.

La pertinence d’un alt. alt="image" ou alt="DSC_0042.jpg" passe le test : l’attribut existe. Pour un utilisateur, il ne veut rien dire. La machine ne lit pas l’image.
L’ordre logique. L’outil ne sait pas si l’ordre de lecture ou de tabulation a du sens pour un humain. Un focus qui saute du haut au pied de page puis revient est « valide » à ses yeux.
L’utilisabilité réelle. Un composant peut être techniquement conforme et impraticable : cible trop petite, interaction obscure, piège de focus. La machine ne « fait » pas le parcours.
La justesse d’un nom accessible. Un bouton avec aria-label="bouton" a bien un nom : l’outil est content. À l’oreille, c’est une annonce vide de sens.
Le texte de lien. « Cliquez ici » et « En savoir plus » répétés dix fois passent techniquement, mais désorientent qui navigue de lien en lien.
Les états dynamiques. Une notification qui apparaît sans être annoncée, une erreur de formulaire silencieuse : hors de portée d’un scan statique.

En clair : l’outil te dit si le code est bien formé, pas s’il est utilisable. C’est exactement la frontière entre la couche automatique et les couches manuelles.

⚠️ Piège — La fausse confiance est le vrai danger de ces outils. « axe ne remonte rien » ne signifie pas « accessible » : ça signifie « aucune des règles automatisables n’a été violée ». Le graphique passe au vert, l’équipe se détend, et personne ne débranche la souris ni ne lance NVDA. L’outil automatique n’est pas un juge de conformité — c’est un détecteur de fautes grossières. Traite un rapport vide comme un point de départ, jamais comme un feu vert.

Les utiliser dans le navigateur

Le flux le plus efficace tient en trois gestes, à répéter souvent pendant le dev plutôt qu’une fois à la fin.

Ouvre les DevTools (F12), va dans l’onglet axe DevTools (après installation de l’extension) ou Lighthouse.
Scanne la page dans son état réel : ouvre la modale, déplie le menu, affiche le message d’erreur — l’outil n’analyse que le DOM présent à l’instant du scan. Une modale fermée n’est pas testée.
Lis chaque anomalie, corrige, re-scanne. axe pointe l’élément fautif, explique la règle et lie la documentation.

Ce dernier point est capital : comme l’analyse porte sur le DOM courant, il faut piloter l’interface dans ses différents états (menu ouvert, onglet actif, formulaire en erreur) et scanner chacun. Un scan unique sur l’état initial rate tout ce qui est conditionnel.

💡 Réflexe — Garde l’extension axe ouverte à côté de ton navigateur pendant que tu développes un composant, et scanne à chaque état que tu ajoutes. Corriger un aria-* invalide au moment où tu l’écris coûte dix secondes ; le retrouver trois semaines plus tard dans un audit global en coûte cent.

🧭 Sur A11yLearn — Sur A11yLearn, on a intégré axe dès le dev du formulaire d’inscription. Premier scan : trois champs sans label associé, un contraste faible sur les messages d’aide, un aria-describedby pointant vers un id inexistant. Corrigés en quelques minutes. Mais le scan restait muet sur le vrai problème vécu par les utilisateurs — l’erreur « e-mail déjà pris » qui s’affichait sans être annoncée. Ça, seul le test au lecteur d’écran (Chapitre 14.4) l’a révélé. L’automatique avait fait sa part : nettoyer le terrain. Pas plus.

✏️ Exercices

Exercice 1 — Vrai ou faux détecteur ? Pour chaque défaut, dis si un outil automatique le détecte de façon fiable : (a) <img src="logo.png"> sans alt ; (b) <img src="graph.png" alt="image"> sur un graphique de résultats ; (c) un role="buton" mal orthographié ; (d) un ordre de tabulation qui part du footer avant le header.

✅ Solution

(a) Détecté — alt manquant, faute mécanique classique. (b) Non détecté — l’alt existe, donc l’outil est satisfait ; sa nullité de sens échappe à la machine. (c) Détecté — buton n’est pas un rôle ARIA valide, l’outil le signale. (d) Non détecté de façon fiable — l’ordre « illogique mais valide » relève du jugement humain et du test clavier.

Exercice 2 — Scan incomplet. Un dev lance axe sur une page à modale, obtient « 0 problème », et conclut que la modale est accessible. Quelle erreur de méthode a-t-il commise ?

✅ Solution

Il a probablement scanné avec la modale fermée : son contenu n’était pas dans le DOM, donc pas analysé. L’analyse automatique ne porte que sur l’état présent au moment du scan. Il faut ouvrir la modale, la scanner dans cet état, puis vérifier au clavier et au lecteur d’écran le piège de focus, la fermeture par Échap et l’annonce — que l’automatique ne juge pas.

🧠 Quiz de révision

1. Quel est le moteur de référence des outils automatiques ?

axe-core (Deque), open source, réputé pour son très faible taux de faux positifs. Il équipe l’extension axe DevTools, Lighthouse, et de nombreux outils de CI. Ce qu’il signale est presque toujours un vrai problème.

2. Cite trois choses qu’un outil automatique détecte bien.

Par exemple : contraste insuffisant, alt manquant, attributs ARIA invalides (rôle inexistant, valeur illégale). Aussi : champ sans label, id dupliqués, lang de page absent. Tout ce qui est mesurable mécaniquement.

3. Cite trois choses qu’un outil automatique ne peut PAS juger.

Par exemple : la pertinence d’un alt, l’ordre logique de lecture/tabulation, l’utilisabilité réelle d’un composant. Aussi : la justesse d’un nom accessible, la qualité d’un texte de lien, les annonces dynamiques. Tout ce qui demande du sens et du jugement.

4. Pourquoi faut-il piloter l’interface avant de scanner ?

Parce que l’outil n’analyse que le DOM présent à l’instant du scan. Une modale fermée, un menu replié, un message d’erreur non affiché ne sont pas dans le DOM et échappent donc au test. Il faut activer chaque état (ouvrir, déplier, déclencher) et scanner chacun.

5. Que signifie vraiment « axe ne remonte aucune erreur » ?

Que aucune règle automatisable n’a été violée sur l’état testé — rien de plus. Ce n’est pas « accessible ». C’est un point de départ propre : il reste à faire le test clavier, le test au lecteur d’écran, et idéalement des tests utilisateurs.

Chapitre suivant : Le test clavier — le test manuel le plus rapide et le plus rentable : débrancher la souris et faire Tab.