Les lecteurs d’écran, petit guide de survie.

Quand vous faites du développement web accessible, il y a toujours un moment où se pose la question du support des lecteurs d’écran. En tant que formateur, je suis régulièrement confronté à des dialogues de ce genre : 

— Euh… mais… Euh… ça veut dire qu’il faut que je teste mon dév. dans un lecteur d’écran ?
— Ben, oui.
— …
— …
— Mais… Euh… C’est-à-dire ? 
— Ben, tu lances le lecteur d’écran de ta machine et tu écoutes si tout ce qui est censé être vocalisé l’est réellement.
— D’accord, d’accord… mais… ça marche comment, exactement, un lecteur d’écran ?

Voilà ! La réalité du développement web c’est que la très vaste majorité des développeurs et des développeuses n’ont pas besoin de ce genre d’outil et n’ont donc aucune idée de ce dont il s’agit et encore moins de comment ça marche. 

Cet article est donc là pour vous aider un peu à vous dépatouiller de ces outils pour que vous puissiez à minima vous rendre compte de ce que vous faites quand vous développez un site ou une application web.

Il était une fois… l’accessibilité web

Je ne vais pas revenir ici sur ce qu’est l’accessibilité web et pourquoi c’est une bonne chose d’en faire. Pour cela, je vous invite à lire cet autre article que j’ai écrit il y a quelques années : Introduction à l’accessibilité web.

L’objectif de ce nouvel article est de vous donner les bases pour que vous puissiez vérifier les résultats de votre travail dans un lecteur d’écran. Cependant, avant de commencer, quelques petits rappels s’imposent.

L’accessibilité web est une démarche globale qui vise à améliorer l’accès aux informations et fonctionnalités d’un site web pour tout le monde. Les problèmes d’accessibilité liés à la vue, s’ils sont souvent les plus nombreux, sont loin d’être les seuls et sont de toute façon extrêmement variés. La cécité totale ou partielle, qui aura besoin d’un lecteur d’écran pour être compensée, n’en est qu’un exemple parmi d’autres : perception des couleurs et/ou du mouvement, myopie, astigmatisme, altération du champ visuel… Sans parler de tous les troubles neurologiques et cognitifs liés à l’usage de la vue : dyslexie, épilepsie, illettrisme, etc.

La bonne prise en charge des lecteurs d’écran, si elle est nécessaire à une bonne accessibilité web, n’est absolument pas suffisante pour espérer atteindre un quelconque taux de conformité WCAG ou RGAA. C’est un cas d’usage, parmi d’autres, qu’il faut prendre en compte.

Ainsi, pensez à prévoir des interfaces qui peuvent supporter une taille de texte arbitraire, des formes de zoom diverses et variées, des paramètres d’affichage du texte variables (interlettrage, espace entre les mots, hauteur de lignes, césures), un contrôle des animations, la capacité à ajuster les contrastes de couleurs… Ce sont autant de choses toutes aussi importantes que le support des lecteurs d’écrans.

Ceci étant dit et, toutes choses étant égalent par ailleurs, c’est quoi un lecteur d’écran et comment ça marche ?

Il fait sombre ici, non ?

Comme son nom l’indique, un lecteur d’écran est un logiciel qui va lire tout ce qui s’affiche sur un écran. La transcription de cette lecture prend en général la forme d’une sortie sonore qui vocalise le résultat de la lecture. Cependant, il est aussi possible de coupler un lecteur d’écran avec d’autres formes de sorties comme une plage braille qui restituera le résultat de la lecture sous la forme d’un texte en relief en alphabet braille.

Les principaux utilisateurs de ce type d’outils sont les personnes qui souffrent de cécité totale ou partielle pour qui l’écran n’est pas exactement une source d’information fiable. De manière plus anecdotique, un lecteur d’écran peut également être utilisé pour lire un contenu à la demande (par exemple pour vous faire lire un article de journal pendant que vous faites la cuisine).

Au moment où j’écris ces lignes (2023), tous les systèmes d’exploitation grand public embarquent nativement un lecteur d’écran et de nombreuses solutions alternatives sont disponibles pour Windows.

• Windows 10/11
  • Narrateur (installé avec le système)
  • NVDA (Libre et gratuit)
  • Jaws® (Le leader du marché)
• MacOS : VoiceOver (installé avec le système)
• iOS : VoiceOver (installé avec le système)
• Android : TalkBack (installé avec le système)

Avertissement : Je ne connais pas bien les environnements Linux et je ne me risquerai donc pas à en parler ici. Je connais vaguement Orca, mais sorti de ça, il existe sans doute d’autres alternatives. Renseignez-vous si vous devez/voulez supporter ces environnements.

Dans la suite de cet article, on va voir les manipulations de base nécessaires à l’utilisation de ces outils et nous discuterons de quand et comment les utiliser. Cependant, il convient de noter que, en plus de ces logiciels dédiés, les assistants vocaux intégrés (Siri, Cortana, l’assistant Google, Alexa, etc.) et les recherches actuelles en Intelligence Artificielle offrent de nouvelles possibilités d’accès aux contenus de plus en plus variées. Nous n’en parlerons pas dans cet article mais restez aux aguets, de nouveaux outils et de nouveaux usages vont apparaître. Dans une démarche d’accessibilité, il est important de les anticiper.

De manière générale, si vous voulez vous donner une idée des outils utilisés dans la vraie vie véritable du monde réel, je vous invite à jeter un coup d’œil aux enquêtes d’utilisation de la fondation WebAIM (Web Accessibility In Mind en anglais). Tous les deux ans environ, ils réalisent une enquête auprès d’utilisateurs de technologies d’assistance pour voir quels sont les usages et les évolutions. Même si cette enquête souffre de nombreux biais, ça vous aidera à mieux cerner les tendances actuelles : WebAIM Screen Reader User Survey #9 (2021)

Les mains dans le cambouis

Ok, rentrons dans le vif du sujet et voyons comment utiliser rapidement les différents lecteurs d’écran. Je vais ici survoler les usages les plus basiques. Si vous voulez creuser un peu le sujet et expérimenter des usages un peu plus complets ou plus avancés, outre les documentations officielles, je vous invite à utiliser les guides de références créés par le site DequeUniversity. Personnellement, comme au quotidien je travaille sous Mac, j’ai toujours la cheatsheet de VoiceOver au format papier à portée de main. 😉

Pour tous les lecteurs d’écran sur ordinateur de bureau, les interactions se font au clavier (vous pouvez toujours utiliser la souris pour activer/désactiver votre lecteur d’écran, mais vous allez vite vous rendre compte que ça complique les choses). Ce qui veut dire que, avant même d’ouvrir un lecteur d’écran, vous devez vous assurer que toutes les interactions avec votre contenu web sont réalisables au clavier !

Dans le cadre de l’accessibilité au clavier, on va souvent retrouver des comportements d’interaction communs : La touche de tabulation (Tab) pour passer d’un élément interactif à l’autre, les touches Enter et Space pour activer un élément ou valider une action, les flèches de direction pour se déplacer entre éléments adjacents ou pour scroller selon le cas.

Pour les appareils et lecteurs d’écran mobiles, les interactions se font via des gestes (du simple touch aux gestures à points multiples), mais contrairement au clavier, il y a assez peu de gestes en commun entre iOS et Android, en particulier en ce qui concerne l’utilisation de VoiceOver et TalkBack. Je ne m’attarderai pas plus que ça ici sur ces lecteurs d’écran. En tant que développeur, concentrez-vous déjà sur ce que vous pouvez faire sur les environnements de bureau.

Des lunettes pour voir les gens habillés !

Une page/application web est donc un type de document bien plus compliqué qu’on ne l’imagine et pour pouvoir l’exploiter pleinement, les lecteurs d’écran proposent différents modes de rendu qui vont chacun avoir leurs spécificités.

Chaque lecteur d’écran a une approche un peu différente de la question avec des dénominations pas toujours très claires, mais dans les grandes lignes on trouve toujours les mêmes deux ou trois modes de restitution : 

1. Le mode lecture qui va simplement lire le document d’un point A à un point B, chaque lecteur d’écran ayant diverses manières de définir ce que sont A et B.
2. Le mode exploration qui permet de décrire et de naviguer dans le document (la liste des titres, des régions, des liens, des tables, des champs de formulaires, etc.)
3. Le mode de saisie/interactif qui permet de remplir les formulaires sans risque d’activer un raccourci clavier par erreur.

A minima pour pouvoir utiliser un lecteur d’écran pour vos tests, vous devez savoir : Activer et désactiver le lecteur d’écran, démarrer et arrêter la lecture, passer d’un titre/en-tête à l’autre. C’est le minimum pour ne pas perdre de temps, le reste viendra à force de manipulation.

Tous les lecteurs d’écrans ont une touche ou combinaison de touches qui permettent d’accéder à leurs fonctionnalités. Je vous met un petit tableau résumé ici du minimum à connaître : 

Cachez cet écran que je ne saurais voir !

Ok, maintenant que vous savez démarrer un lecteur d’écran et faire quelques opérations de base avec, voyons plus en détail comment s’en servir pour tester votre travail et surtout les limites de ce genre de test.

Il y a un point à garder en tête les premières fois où on lance un lecteur d’écran : souvenez-vous bien que vous n’êtes pas un utilisateur régulier de ce genre d’outil. Ça parait évident, mais quand on a lancé un lecteur d’écran une petite dizaine de fois, c’est bien de s’en souvenir pour une raison bien spécifique : Vous n’êtes pas capable de juger de la qualité ergonomique de la restitution vocale ! En clair, vous serez parfois surpris de l’ordre de restitution, de la façon dont certaines informations sont énoncées ou non, de la forme qu’elles peuvent prendre (chaque lecteur d’écran aillant une façon particulière de restituer une même information). Cela pour la seule raison que vous n’êtes pas un utilisateur régulier de ce genre d’outils et que vous ne savez donc pas comment contrôler le niveau et la nature des informations que vous voulez entendre.

Pas de panique, c’est normal et ce n’est pas grave.

En tant que développeurs et développeuses web, ce que vous devez vérifier c’est si toutes les informations nécessaires sont bien restituées par le lecteur d’écran. Est-ce que tous les éléments interactifs ont bien un libellé qui est clairement restitué ? Est-ce que les modifications apportées à un document sont clairement énoncées via un bon usage des régions dynamiques ARIA ? Est-ce que les différents messages d’erreurs d’un formulaire sont correctement restitués ? Etc.

Si vous voulez savoir si toutes ses informations sont correctement agencées d’une manière réellement exploitable par les utilisateurs, il n’y a pas 36 solutions. Le plus efficace va être de discuter avec vos collègues UX Designers pour organiser des tests utilisateurs avec des utilisateurs réguliers de lecteur d’écran.

Je vous invite à minima à tester votre travail en cachant votre écran dès que vous vous sentirez un peu plus à l’aise avec un lecteur d’écran… Oui, oui, éteignez-le, mettez un tissu ou un carton dessus et essayez d’utiliser ce que vous avez fait. Au-delà du rendu vocal, cela va également vous forcer à évaluer la pertinence de l’usage du clavier. Je pense que les premières fois vont vous surprendre.

Conclusion

Bon, ben voilà… Vous voyez, ce n’est pas si difficile ! Prenez juste l’habitude de lancer un lecteur d’écran pendant vos phases de développement et vous allez très vite voir la qualité de vos interfaces s’améliorer sensiblement.

Avant d’en finir, je glisse ici un petit mot sur la Web Speech API qui permet, entre autres, de faire du text-to-speech comme pourrait le faire un lecteur d’écran. Soyez extrêmement prudent en vous en servant car si vous vous y prenez mal, vous pourriez avoir de sérieux clashs avec l’utilisation d’un lecteur d’écran.

Ainsi, et même (surtout ?) dans ce cas, testez, testez et testez encore avec un lecteur d’écran. 😉