Chapitre 14.1 — La stratégie de test
⏱️ TL;DR — Tester l’accessibilité, ce n’est pas lancer un outil : c’est empiler des couches complémentaires. L’automatique est rapide et large mais superficiel (~30-40 % des problèmes). Le clavier attrape ce que la souris cache. Le lecteur d’écran juge la sémantique réelle. Les tests utilisateurs avec des personnes handicapées sont l’étalon-or. Chaque couche rattrape les angles morts de la précédente ; aucune ne se suffit. Et on teste tôt et en continu (shift-left), pas en audit de dernière minute.
🎯 Objectifs
- Décrire les quatre couches de test et leur rôle.
- Savoir précisément ce que chaque couche attrape et rate.
- Démonter le mythe du score 100 comme preuve d’accessibilité.
- Placer le test tôt et en continu dans le cycle de dev (shift-left).
Pourquoi une seule couche ne suffit jamais
L’accessibilité mélange deux natures de problèmes. Les uns sont machinaux : un contraste sous le seuil, un alt manquant, un id dupliqué. Une machine les détecte parfaitement. Les autres sont humains : un alt qui décrit mal l’image, un ordre de tabulation illogique, une modale qu’on ne peut pas fermer au clavier, une annonce vocale absurde. Aucune machine ne les juge de façon fiable — il faut un cerveau, un clavier et une oreille.
C’est pour ça qu’on parle de stratégie en couches. Chaque couche a un profil : rapide ou lente, large ou ciblée, superficielle ou profonde. On les empile pour que les trous de l’une soient bouchés par l’autre.
Lis ce schéma comme un entonnoir : en haut, un filtre grossier qui traite beaucoup de pages pour peu d’effort ; en bas, un filtre fin qui traite peu de cas mais révèle la vérité du terrain. On ne saute aucun étage.
Ce que chaque couche attrape et rate
| Couche | Attrape | Rate |
|---|---|---|
| Automatique | Contraste, alt absent, attributs ARIA invalides, labels manquants, lang absent. | Pertinence d’un alt, ordre logique, pièges au clavier, utilisabilité réelle, sens. |
| Clavier | Éléments injoignables, focus invisible, ordre incohérent, pièges de focus, actions souris seule. | Ce qui est annoncé (noms, rôles, états) au lecteur d’écran. |
| Lecteur d’écran | Noms/rôles/états faux ou absents, annonces dynamiques muettes, structure de titres incohérente. | La difficulté vécue par un vrai utilisateur non expert de ton interface. |
| Tests utilisateurs | Les vrais blocages, la charge cognitive, les détours, ce qui « marche sur le papier » mais épuise. | Rien de fondamental — mais c’est lent et coûteux, donc rare. |
Retiens la ligne du haut : l’automatique attrape le plus facile et rate le plus important. C’est un excellent point de départ, un désastreux point d’arrivée.
💡 Réflexe — Ne demande jamais « est-ce que l’outil est vert ? » mais « quelle couche a validé ça ? ». Un contraste corrigé, c’est l’automatique. Un menu utilisable, c’est le clavier. Une modale bien annoncée, c’est le lecteur d’écran. Si une seule couche a tourné, tu ne sais presque rien.
Le mythe du score 100
Un score de 100 à l’onglet accessibilité de Lighthouse est flatteur et trompeur. Lighthouse (comme axe, WAVE, Pa11y) exécute une batterie de tests automatisables. Il ne peut pas cocher ce qu’il ne sait pas mesurer : il ne pénalise donc pas un alt="image" inutile, un ordre de focus chaotique ou un composant impossible à activer au clavier. Une page peut afficher 100/100 et rester inutilisable pour une personne aveugle ou motrice.
Le score dit une seule chose : « je n’ai trouvé aucun des problèmes que je sais détecter ». Ça n’est pas « cette page est accessible ». On creuse ce malentendu, et d’autres idées reçues tenaces, dans le Chapitre 1.5 — Mythes & réalités.
⚠️ Piège — Afficher un badge « 100 % accessible » ou « conforme » sur la foi d’un score automatique t’expose deux fois : tes utilisateurs se heurtent quand même aux vrais blocages, et une déclaration d’accessibilité mensongère est juridiquement risquée (RGAA, EAA). Le score est un outil de travail interne, pas une preuve de conformité.
Quand tester : tôt et en continu (shift-left)
L’erreur d’organisation la plus coûteuse, c’est de garder l’accessibilité pour la fin : un « audit a11y » deux semaines avant la mise en prod, sur une appli entière. On découvre alors des centaines de problèmes, souvent structurels (mauvais choix de balises, composants maison inaccessibles), impossibles à corriger à temps.
Le bon modèle est le shift-left : pousser le test le plus à gauche possible dans le cycle, c’est-à-dire le plus tôt.
- À la conception : maquettes vérifiées (contrastes, ordre de lecture, cibles tactiles) — voir Partie 15.
- Pendant le dev : linting a11y dans l’éditeur, extension axe ouverte à côté du navigateur, test clavier sur chaque composant fini.
- À chaque commit / PR : tests automatiques en CI (voir Chapitre 14.5).
- Par jalons : audit manuel complet (clavier + lecteur d’écran) et, quand c’est possible, tests utilisateurs.
Un bug d’accessibilité attrapé à la conception coûte une retouche de maquette ; le même attrapé en prod coûte un correctif, une non-régression et parfois une refonte. Tester tôt, c’est tester moins cher.
🧭 Sur A11yLearn — Sur A11yLearn, la première campagne de tests avait été faite « à l’ancienne » : un seul audit Lighthouse, score 96, feu vert. En production, les retours utilisateurs ont explosé — inscription impossible au clavier, tableau de bord muet au lecteur d’écran. Aucun de ces blocages n’était détectable par un outil automatique. On a rebâti la démarche en quatre couches et déplacé les tests dans la CI : depuis, chaque PR passe le crible automatique, chaque composant passe le test clavier, et les parcours clés sont vérifiés au lecteur d’écran avant release.
✏️ Exercices
Exercice 1 — Quelle couche pour quel bug ? Pour chacun de ces défauts, dis quelle couche est la plus à même de le détecter : (a) un texte gris clair sur fond blanc ; (b) une carte cliquable impossible à atteindre au Tab ; (c) un bouton « poubelle » sans texte, annoncé « bouton » sans plus ; (d) un utilisateur qui abandonne car il ne comprend pas l’étape suivante.
✅ Solution
(a) Automatique — un contraste insuffisant est mesurable par une machine. (b) Clavier — l’automatique voit rarement qu’un élément est injoignable ; le Tab le révèle immédiatement. (c) Lecteur d’écran — l’outil auto peut ne rien signaler si un aria-label existe, mais à l’écoute on entend « bouton » sans savoir ce qu’il fait : le nom accessible est vide de sens. (d) Tests utilisateurs — seul un vrai utilisateur en situation révèle un blocage de compréhension.
Exercice 2 — Le score qui ment. Un collègue te montre un rapport Lighthouse 100/100 et conclut « la page est accessible, on livre ». Donne-lui trois défauts graves qu’un tel score ne garantit pas absents.
✅ Solution
Trois exemples parmi d’autres : (1) un alt présent mais hors sujet (« photo.jpg ») — l’outil voit un alt, pas son inutilité ; (2) un ordre de tabulation illogique qui perd l’utilisateur clavier ; (3) une modale sans piège de focus ni fermeture au clavier. Le score signifie « aucun problème détectable automatiquement trouvé », pas « accessible ». Il faut au minimum ajouter le test clavier et le lecteur d’écran.
🧠 Quiz de révision
1. Quelles sont les quatre couches de test ?
Automatique (rapide, large, superficiel, ~30-40 %), clavier (manuel, rapide, très rentable), lecteur d’écran (manuel, juge la sémantique) et tests utilisateurs avec des personnes handicapées (lent, précieux, étalon-or). On les empile ; aucune ne suffit seule.
2. Environ quelle part des problèmes un outil automatique détecte-t-il ?
Environ 30 à 40 %. Il excelle sur le mesurable (contraste, alt absent, attributs invalides) et rate tout ce qui demande du jugement (pertinence, ordre logique, utilisabilité réelle, sens des annonces).
3. Pourquoi un score Lighthouse de 100 ne prouve-t-il pas l’accessibilité ?
Parce qu’il ne mesure que les critères automatisables. Un 100 signifie « aucun problème détectable par la machine trouvé », pas « utilisable par tous ». Une page peut scorer 100 et rester injouable au clavier ou muette au lecteur d’écran.
4. Que signifie « shift-left » pour les tests a11y ?
Pousser le test le plus tôt possible dans le cycle : conception, dev, chaque PR, puis jalons — plutôt qu’un audit unique de fin de projet. Un défaut attrapé tôt coûte infiniment moins cher qu’un défaut structurel découvert en prod.
5. Le test clavier peut-il remplacer le lecteur d’écran ?
Non. Le clavier vérifie qu’on peut atteindre et activer ; le lecteur d’écran vérifie ce qui est annoncé (nom, rôle, état, annonces dynamiques). Un composant peut être parfaitement navigable au clavier tout en étant muet ou trompeur à l’écoute. Ce sont deux couches distinctes.
Chapitre suivant : Les outils automatiques — axe, Lighthouse, WAVE, Pa11y, ARC : ce qu’ils voient, ce qu’ils ne verront jamais.