Chapitre 14.4 — Le test au lecteur d’écran

⏱️ TL;DR — Le test clavier vérifie qu’on peut atteindre et actionner ; le test au lecteur d’écran vérifie qu’on comprend ce qu’on entend — les bons noms, rôles, états et annonces. C’est la couche que les outils automatiques ne touchent pas. Combos recommandés : NVDA + Firefox/Chrome (Windows), VoiceOver + Safari (Mac). Pas besoin d’être expert : quelques commandes suffisent à révéler l’essentiel. Reste humble — tester n’est pas vivre l’expérience au quotidien.

🎯 Objectifs

• Choisir un combo lecteur d’écran + navigateur pour tester.
• Connaître les commandes minimales pour parcourir une page.
• Savoir quoi vérifier (noms, rôles, états, ordre, annonces).
• Tester un parcours réel de bout en bout.

Quel combo utiliser

Les lecteurs d’écran ont des affinités avec certains navigateurs. Pour tester, choisis-en un :

Tu n’as pas besoin de tous les tester. Commence par un combo desktop (NVDA ou VoiceOver) et ajoute le mobile pour les parcours clés (13.4). Les commandes de prise en main sont dans le chapitre 5.4.

Les commandes minimales

Tu n’as besoin que d’une poignée de commandes pour tester utilement :

• Lire de haut en bas (flèche bas / VO+A) — parcourir tout le contenu.
• Élément suivant/précédent — avancer pas à pas.
• Naviguer par titres (touche H sous NVDA) — vérifier la structure.
• Naviguer par landmarks / formulaires / liens — tester les raccourcis.
• Lister les titres / liens (rotor VoiceOver, listes NVDA) — voir la table des matières perçue.

Ce qu’il faut vérifier

Le test au lecteur d’écran valide ce que le clavier ne dit pas :

1. Les noms — chaque élément est-il annoncé avec un libellé correct et utile ? Un bouton icône dit-il « Rechercher » et non « bouton » tout court ? (nom/rôle/valeur)
2. Les rôles — un bouton est-il annoncé « bouton », un lien « lien », un titre « titre niveau 2 » ? Un faux bouton se trahit ici (annoncé comme du texte).
3. Les états — une case cochée dit-elle « cochée » ? Un accordéon « développé/replié » ? Un onglet « sélectionné » ?
4. L’ordre et la structure — la lecture linéaire a-t-elle du sens ? Les titres forment-ils un plan cohérent ?
5. Les annonces dynamiques — un message de succès, un compteur de résultats, une erreur sont-ils annoncés (live regions) sans qu’on ait à les chercher ? (6.4)
6. Le contenu masqué — le décoratif est-il bien ignoré (aria-hidden), et le texte utile bien lu ?

♿ Côté utilisateur — Ferme les yeux pendant le test, ou détourne le regard de l’écran. Tu vis alors ce que vit un utilisateur aveugle : si tu es perdu, si tu ne sais pas ce qu’est un élément ou dans quel état il se trouve, c’est un vrai problème — pas un détail. Cette bascule de perspective est ce qui rend le test au lecteur d’écran si formateur.

Tester un parcours réel

Un test utile ne se contente pas de survoler une page : il déroule une tâche complète au lecteur d’écran. Par exemple, pour A11yLearn : « s’inscrire, se connecter, ouvrir un cours, lancer la vidéo ». À chaque étape, vérifie que tu comprends ce qui se passe uniquement à l’oreille, que les erreurs sont annoncées, que les changements de page sont signalés.

⚠️ Piège — Tester un composant isolé et le déclarer bon. Beaucoup de problèmes n’apparaissent que dans le flux : un focus mal rendu après fermeture d’une modale, une erreur de formulaire non annoncée, une navigation SPA muette. Teste des parcours, pas seulement des éléments.

🧭 Sur A11yLearn — On déroule « ouvrir un cours et le marquer terminé » sous NVDA. Deux découvertes : le bouton « Marquer comme terminé » est annoncé « bouton » sans libellé (une icône seule sans nom accessible → on ajoute aria-label), et le message « Cours terminé ✔ » n’est pas annoncé (pas de live region → on l’enveloppe dans role="status"). Invisibles au test clavier, évidents au lecteur d’écran.

✏️ Exercices

Exercice 1 — Le bouton muet. Au lecteur d’écran, un bouton d’action est annoncé simplement « bouton ». Quelle est la cause probable et le correctif ?

Exercice 2 — Le succès silencieux. Après avoir soumis un formulaire, un message « Enregistré » s’affiche mais le lecteur d’écran ne dit rien. Pourquoi, et comment corriger ?

🧠 Quiz de révision

Chapitre suivant : Tests en CI & anti-régression — automatiser ce qui peut l’être pour ne pas régresser.