Presque tous les programmes d’accessibilité que nous auditons rapportent le même chiffre : quatre-vingt-dix pour cent et quelques des développeurs frontend déclarent « tester avec un lecteur d’écran ». Demandez-leur de faire une démonstration, et la démo se résume généralement aux mêmes trois raccourcis — l’activer, parcourir la page au clavier, le désactiver. Ce n’est pas tester. C’est cocher une case.

La raison pour laquelle cela se produit est structurelle, et non pas liée à la paresse. Un lecteur d’écran ne s’apprend pas comme on prend en main un nouveau linter. C’est un modèle d’interaction différent avec son propre état modal, sa propre grammaire de raccourcis et un ensemble de conventions qui n’ont de sens qu’après plusieurs heures d’utilisation réelle. Tant qu’on ne franchit pas ce seuil, l’outil dit presque rien — et pire, il dit des choses fausses, parce que les annonces entendues dépendent du mode du lecteur, de l’arbre d’accessibilité du navigateur et de la couche IME de la plateforme de manières non évidentes depuis l’extérieur.

La maîtrise, pour nos besoins, est le point auquel il est possible de prendre le clavier d’un collègue qui signale un composant défectueux et de reproduire le bogue avec le lecteur d’écran activé — sans regarder l’écran, sans consulter une aide-mémoire, et sans aggraver les annonces par rapport à un usage réel. La familiarité, c’est le point auquel on a entendu un lecteur d’écran. L’écart entre les deux représente environ trente à trente-cinq heures de pratique délibérée.

Le marché compte trois lecteurs d’écran qui comptent pour le travail web sur ordinateur : NVDA sur Windows, VoiceOver sur macOS et iOS, et JAWS sur Windows. Chacun dispose d’une base d’utilisateurs suffisamment large pour qu’il serait risqué de l’ignorer, et chacun annonce le même balisage de manière légèrement différente. Un développeur maîtrisant l’outil peut en piloter au moins deux.

Notre recommandation, après avoir observé des dizaines de développeurs franchir le seuil, est sans ambiguïté : commencer par NVDA sur Windows et VoiceOver sur macOS. Les deux sont gratuits. Les deux sont préinstallés (VoiceOver) ou installables en moins de cinq minutes (NVDA). Les deux sont utilisés par suffisamment d’utilisateurs réels — NVDA détient approx. 65 % des parts de marché des lecteurs d’écran Windows dans la dernière enquête WebAIM, VoiceOver domine le mobile et une part significative de macOS — que ce qu’on apprend se traduit immédiatement en bogues pour lesquels on peut livrer un correctif. JAWS est le troisième outil, pas le premier, même s’il reste le lecteur d’écran avec la plus grande base installée en entreprise. Pour trois raisons.

Les trois raisons de ne pas commencer par JAWS sont pédagogiques, et non politiques. Premièrement, JAWS et NVDA partagent un modèle mental — le mode navigation versus le mode formulaire sous Windows, le même préfixe de commande basé sur Insert, le même tampon virtuel — donc une fois NVDA maîtrisé, quatre-vingt-dix pour cent des commandes JAWS dont on a réellement besoin se trouvent à portée d’un simple glossaire. Deuxièmement, JAWS a accumulé des décennies d’inférence « intelligente » : il tente de corriger le balisage défectueux avant que l’utilisateur ne l’entende, ce qui signifie qu’un bogue que JAWS masque sera quand même livré aux utilisateurs de NVDA. Le comportement délibérément conservateur de NVDA en fait le lecteur de référence pour comprendre ce qui est cassé. Troisièmement, les obstacles liés à la licence JAWS — l’activation, le mode d’essai de quarante minutes qui relance un avertissement à chaque redémarrage — constituent une taxe d’apprentissage inutile jusqu’à ce qu’on soit suffisamment confiant pour l’assumer.

VoiceOver s’associe à NVDA plutôt qu’il ne lui fait concurrence, parce que les deux lecteurs représentent les deux modèles d’interaction dominants. NVDA (et JAWS) utilisent le modèle « curseur PC » : un tampon virtuel qui présente la page comme un document linéaire et un focus séparé qui suit l’ordre de tabulation. VoiceOver utilise un curseur VoiceOver unique positionné au-dessus du focus, navigable par le rotor et par les touches VO+flèche. Un développeur ne maîtrisant qu’un seul modèle écrira du code qui s’annonce bien dans son lecteur et mal dans l’autre. Apprendre les deux simultanément est le seul moyen fiable de ressentir la différence.

Le programme de la première semaine a une règle : éteindre le moniteur. Pas assombri, pas minimisé, pas « je vais fermer les yeux » — physiquement éteint, ou caché sous un carton si l’écran est le seul de la pièce. L’objectif est de supprimer la possibilité de tricher. L’instinct d’un développeur voyant, dès qu’un lecteur d’écran dit quelque chose de confus, est de jeter un coup d’œil à l’écran et de résoudre l’ambiguïté visuellement. Cet instinct est la principale raison pour laquelle « j’ai testé avec un lecteur d’écran » ne détecte pas les vrais bogues.

Il faut prévoir trois séances d’environ quatre-vingt-dix minutes chacune lors de la première semaine, avec au moins un jour entre les séances pour laisser la mémoire musculaire se consolider. Chaque séance a une mission. La première établit la grammaire de commandes de base. La deuxième impose une interaction réelle. La troisième teste la rétention sous un léger stress.

Les deuxième à quatrième semaines de pratique devraient totaliser environ vingt heures de travail — deux séances de quatre-vingt-dix minutes par semaine, plus une petite quantité d’usage incident pendant la journée de travail. L’objectif de cette période est d’intérioriser les deux choses qui désorientent le plus les nouveaux utilisateurs de lecteurs d’écran : la distinction entre le mode navigation et le mode formulaire, et la différence entre ce que le rotor voit et ce que l’ordre de tabulation voit.

La confusion la plus courante en deuxième semaine survient quand un développeur appuie sur une touche fléchée dans NVDA, s’attend à ce que le tampon virtuel se déplace, et entend à la place la liste déroulante ciblée s’ouvrir. C’est le mode navigation qui passe en mode formulaire automatiquement parce que le focus vient d’atterrir sur un élément que NVDA classe comme widget « applicatif ». Les nouveaux développeurs vivent cela comme un dysfonctionnement du lecteur. Ce n’en est pas un — le lecteur fait exactement ce que la spécification demande. Une fois cela entendu dix ou quinze fois, on arrête d’être surpris ; d’ici là, il faut s’attendre à être surpris environ toutes les deux séances.

Le programme de la troisième semaine porte sur les formulaires. Il faut construire une page de test privée avec huit ou dix contrôles : un champ de texte obligatoire avec une erreur en ligne, un sélecteur de date, une liste à sélection multiple, une case à cocher personnalisée, un bouton désactivé qui devient actif, un bouton « afficher le mot de passe », un champ de numéro de téléphone avec un sélecteur de code pays, et un bouton d’envoi qui déclenche un résumé de validation côté serveur. Moniteur éteint, naviguer à travers lui cinq fois — d’abord avec NVDA en mode navigation, puis NVDA en mode formulaire, puis NVDA à nouveau avec le paramètre d’annonce verbeux activé (Insert+Z, voir section cinq), puis VoiceOver avec le rotor, puis VoiceOver sans le rotor. Le même formulaire sonnera différemment cinq fois. C’est ce que ressemble la maîtrise de l’intérieur : constater que le même balisage raconte cinq histoires différentes, et être capable de prédire à l’avance laquelle se jouera.

La quatrième semaine porte sur la navigation. Il faut prendre un site réel et complexe — un portail de documentation, un tableau de bord professionnel, une page de catégorie d’un site de commerce électronique — et tenter de trouver une information précise en utilisant uniquement les raccourcis du lecteur d’écran. Utiliser H pour sauter entre les titres. Utiliser D (NVDA) ou VO+U puis « Repères » (VoiceOver) pour naviguer entre les repères. Utiliser 1 à 6 pour aller directement à un niveau de titre particulier. À la fin de la quatrième semaine, les raccourcis de navigation doivent être des réflexes plutôt que des choix, comme le sont déjà Tab et Maj+Tab.

Une fois que les commandes utilisateur sont des réflexes, le cap suivant est d’entrer dans les surfaces orientées développeur de chaque lecteur. Ce sont les modes et raccourcis que les manuels enfouissent — en partie parce qu’ils sont destinés aux développeurs, en partie parce qu’ils sont suffisamment bruités pour qu’un utilisateur quotidien ne veuille pas les avoir activés. Trois méritent d’être appris immédiatement.

Deux autres habitudes feront gagner plus de temps que n’importe quel raccourci. Premièrement, laisser la visionneuse de paroles de NVDA épinglée sur un second moniteur (ou dans un coin de l’écran unique) pendant le développement. Le journal verbatim de chaque annonce est au travail avec un lecteur d’écran ce que la console des outils de développement est à JavaScript : la différence entre supposer et savoir. Deuxièmement, apprendre à lire l’arbre d’accessibilité dans les outils de développement du navigateur — le volet Accessibilité de Chrome, l’Inspecteur d’accessibilité de Firefox, l’onglet Audit de Safari. Le lecteur annonce ce que contient l’arbre d’accessibilité, pas ce que contient le DOM, et les deux divergent suffisamment souvent pour qu’il soit impossible de déboguer les régions dynamiques, ARIA ou le Shadow DOM sans lire directement l’arbre.

Une confusion à signaler maintenant, parce qu’elle fait perdre des heures lors des deuxième et troisième semaines : le mode navigation versus le mode formulaire n’est pas le même axe que « la page est interactive » versus « la page est un document ». NVDA passe automatiquement en mode formulaire quand le focus atterrit sur un contrôle avec role=“application”, ou sur un contenteditable, ou sur certains widgets personnalisés que le lecteur classe heuristiquement comme interactifs — quel que soit le caractère principalement statique de la page. À l’inverse, une application monopage richement interactive dont l’élément racine est un repère main et dont les widgets sont des boutons natifs bien balisés restera en mode navigation pendant presque toute la session de l’utilisateur. Le mode est une propriété de l’élément ciblé, pas une propriété de la page.

Les chiffres ci-dessous sont issus du suivi informel d’environ quatre-vingts développeurs — ingénieurs frontend, responsables QA, spécialistes de l’accessibilité en formation — sur trois ans d’ateliers en entreprise et de mentorat individuel. Ce n’est pas une étude scientifique. C’est suffisant pour planifier. Deux hypothèses : pratique délibérée (moniteur éteint, tâches réelles, pas « j’ai laissé NVDA tourner en fond pendant que je codais »), et un appairage de lecteurs fixe (NVDA sur Windows et VoiceOver sur macOS).

« Semi-fluent » est la destination réaliste pour la plupart des développeurs voyants et, en termes pratiques, c’est tout ce dont il faut disposer pour contribuer efficacement à un produit accessible. La véritable maîtrise — le niveau auquel on pourrait plausiblement se substituer à un utilisateur quotidien d’un lecteur d’écran lors d’une évaluation d’utilisabilité — représente plutôt cent cinquante heures et un an de pratique incidente, et la plupart des développeurs en activité n’en ont pas besoin. Viser la semi-maîtrise, planifier les quarante heures, et accepter que tout ce qui va au-delà s’acquiert en faisant son travail quotidien avec un lecteur actif et en acceptant de ralentir.

Un dernier repère pour calibrer les attentes honnêtement : les développeurs qui stagnent, d’après notre expérience, stagnent entre la dixième et la vingtième heure. La cause est presque toujours la même — ils arrêtent d’éteindre le moniteur. Ils se disent qu’ils sont désormais « suffisamment bons » pour tester avec l’écran allumé, le lecteur d’écran activé en fond, et la confirmation visuelle disponible dès que l’audio est ambigu. Ce n’est pas le cas. Les seize heures entre « utile » et « à l’aise » requièrent le moniteur éteint parce que c’est la période où les annonces du lecteur deviennent des informations plutôt que du bruit. Sans cette contrainte, le cerveau revient à la vision et la voix du lecteur s’efface en fond sonore. Si la progression ralentit, c’est presque toujours à cause du moniteur.

Si « tester avec un lecteur d’écran » produit des résultats si médiocres dans l’ensemble du secteur, ce n’est pas parce que l’outil est difficile à apprendre — quarante heures n’est vraiment pas beaucoup de temps — mais parce que cet apprentissage est inconfortable d’une manière spécifique. Éteindre le moniteur donne à un développeur voyant un sentiment d’incompétence inhabituel dans notre métier. Nous sommes habitués à être ceux qui trouvent des solutions ; le lecteur d’écran nous rend, pendant quelques heures de suite, à nouveau débutants. Cet inconfort, et non les raccourcis, est le véritable obstacle.

Le chemin à travers est celui décrit ci-dessus : NVDA et VoiceOver, trois séances la première semaine avec le moniteur éteint, formulaires et modes lors des semaines deux à quatre, raccourcis du mode développeur dès que les raccourcis utilisateur sont des réflexes, quarante heures au total avant de pouvoir être sollicité pour une vérification sérieuse avant livraison. Rien de tout cela n’est nouveau. Le travail que le secteur n’a pas accompli est de le traiter comme un travail — de planifier les heures, de les défendre contre d’autres engagements, d’accepter que les dix premières de ces heures semblent inutiles jusqu’au moment où elles cessent soudainement de l’être.

Si vous livrez du frontend, la version de vous de l’autre côté de ces quarante heures est un ingénieur nettement meilleur que celui qui a commencé, d’une manière qui se manifestera non seulement dans votre travail d’accessibilité, mais aussi dans votre compréhension de l’ordre de focus, de l’amélioration progressive, de ce que le navigateur fait réellement sous le capot. Le lecteur d’écran est la leçon de systèmes distribués la moins chère accessible à quiconque développe pour le web. Le prix est le moniteur éteint et quelques week-ends.