Comprendre les modes d’interaction des lecteurs d’écran

Les lecteurs d’écran sous Windows ont des modes d’interaction multiples, et en fonction de la tâche à effectuer, ils basculeront automatiquement dans le mode le plus approprié.

Ce billet explique pourquoi les lecteurs d’écran sous Windows se comportent ainsi, et comment votre code peut influencer ce comportement.

Le mode virtuel/navigation

Lorsqu’un document est restitué par le navigateur, les lecteurs d’écran sous Windows tels que Jaws et NVDA accèdent au Document Object Model (DOM) soit directement, ou via les APIs d’accessibilité disponibles.

Le DOM est une représentation hiérarchique des objets du document web et les informations qu’il restitue sont enrichies par le lecteur d’écran et restituées à l’utilisateur sous la forme d’une copie virtuelle de l’original.

En créant une copie virtuelle du document, les lecteurs d’écran permettent aux personnes aveugles d’interagir avec les contenus d’une manière qui ne serait pas possible autrement sur la plateforme Windows. Cela se produit parce que le lecteur d’écran intercepte la plupart des appuis sur le clavier avant qu’ils ne parviennent au navigateur, en déclenchant à la place une interaction avec le document virtuel.

Par exemple, les flèches de direction droite et gauche sont interceptées et utilisées pour déplacer le focus au caractère précédent/suivant dans le contenu, et les flèches haut et bas déplacent le focus à la ligne précédente/suivante au lieu de faire défiler la page.

Ce comportement permet aussi de naviguer dans le contenu à l’aide de raccourcis clavier natifs du lecteur d’écran. La plupart des lecteurs d’écran sous Windows suivent une convention de raccourcis clavier largement similaires: par exemple T déplace le focus au tableau suivant (NVDA), titre suivant (Jaws), H à l’en-tête suivant (NVDA), L à la prochaine liste, G au prochain graphique, et ainsi de suite. Il est également possible d’ouvrir des boîtes de dialogue qui affichent la liste de tous les éléments d’un type particulier – par exemple les contrôles de formulaire ou les liens.

Dans Jaws, ce mode d’interaction est connu sous le nom de mode virtuel, et dans NVDA et Window-Eyes de mode navigation. La copie du document original est généralement référencée comme le tampon virtuel.

Le mode formulaire/focus

Cependant, tous les appuis sur le clavier ne sont pas capturés par le lecteur d’écran. Lors de l’utilisation de la touche Tabulation, l’information est automatiquement communiquée au navigateur, ce qui entraîne le déplacement du focus du clavier vers le prochain contenu interactif, exactement comme si le lecteur d’écran n’était pas actif. Il se passe aussi la même chose dans d’autres circonstances, lorsque par exemple la touche Entrée est utilisée pour activer un lien ou la touche Espace pour sélectionner une case à cocher.

Ce processus intelligent est automatique, sans que l’utilisateur n’en ait conscience, mais il y a des circonstances où l’utilisateur a besoin d’être informé d’un changement du mode d’interaction. Lorsqu’il interagit avec un champ de saisie ou une liste déroulante, l’utilisateur doit savoir que l’appui sur une touche fera autre chose qu’exécuter une commande de navigation propre au lecteur d’écran, – par exemple que le H saisira un caractère au lieu de déplacer le focus au prochain en-tête, ou que la flèche bas sélectionnera une option de la liste déroulante au lieu d’aller à la prochaine ligne de contenu.

Dans NVDA, ce mode d’interaction est connu sous le nom de mode focus et dans Jaws, c’est le mode formulaire.

Window-Eyes ne lui donne pas de nom, mais indique simplement que le mode navigation est désactivé. Néanmoins, il y a des subtilités à ce mode d’interaction. Par exemple, NVDA activera ou quittera le mode formulaire lorsque la touche Tabulation est utilisée pour déplacer le focus sur ou à l’extérieur du champ de formulaire, pas si les flèches de direction sont utilisées. Jaws activera ou quittera automatiquement le mode formulaire quelle que soit la méthode utilisée pour déplacer le focus sur le champ, bien que dans Jaws16 (encore non disponible en français, ndt) il soit possible de configurer Jaws pour qu’il ignore le mode formulaire lors de la navigation dans le contenu à l’aide des flèches de direction. On peut également forcer les deux lecteurs d’écran à changer de mode manuellement et tous deux indiquent le changement de mode par un « clic » audible.

Il existe une anomalie sur certains champs de formulaire lors du passage en mode formulaire. Bien qu’il soit possible de sélectionner un bouton radio sans changer de mode, il est nécessaire d’être dans le mode formulaire pour utiliser les touches de direction afin de se déplacer dans un groupe de boutons radio. Si on ne connaît pas cette anomalie, on peut faire l’erreur de croire qu’un groupe de boutons radio ne fonctionne pas.

Le mode application

Bien que ce changement de mode puisse sembler contre-intuitif à quelqu’un qui n’est pas habitué à un lecteur d’écran sous Windows, il fonctionne bien en pratique et la plupart des utilisateurs de lecteurs d’écran ignorent ce qui se passe « sous le capot ». Du point de vue du développeur, il est cependant bien plus important de comprendre un peu la mécanique du lecteur d’écran.

La plupart du temps, un lecteur d’écran gérera automatiquement les différents modes d’interaction, à condition que le document original soit bâti selon un balisage robuste et sémantique. Cependant, tout change dans le cas de composants web riches/personnalisés. Un widget (du type barre de menus ou système d’onglets) est un composant web développé pour se comporter comme son équivalent dans une application logicielle.

Le fonctionnement des lecteurs d’écran sous Windows ne prévoit pas l’utilisation de tampon virtuel pour la navigation dans les applications logicielles. Ainsi l’ajout d’un widget dans un document web force soudain la cohabitation de deux paradigmes du lecteur d’écran dans un même espace.

Le système d’onglets est un bon exemple : lorsqu’on interagit avec des onglets dans une application logicielle, les flèches gauche/droite déplacent le curseur en boucle entre chacun des onglets. Lorsqu’un système d’onglets est transposé dans un document web, le même modèle d’interaction est géré par le script proposant la fonctionnalité du widget. C’est là que réside le défi : un lecteur d’écran sous Windows interceptera l’appui sur les touches gauche/droite et l’utilisera pour déplacer le focus dans le tampon virtuel au lieu de passer la main au navigateur pour interagir avec les onglets.

ARIA (connu sous le nom de WAI-ARIA dans les occasions formelles) est la solution. Lorsque certains roles ARIA sont appliqués à des widgets, ils informent le lecteur d’écran que l’élément (ou groupe d’éléments) a une fonction spécifique et également que le mode virtuel/navigation n’est pas approprié. Il en résulte que le lecteur d’écran bascule en mode application et traite le widget comme s’il était le composant d’une application logicielle.

Quoiqu’il en soit, le mode application est identique au mode formulaire – il a pour conséquence que le lecteur d’écran redonne la main au navigateur pour les raccourcis clavier afin que ceux-ci puissent remplir leur fonction originale. Par exemple, lorsque les rôles tablist et tab sont utilisés en tant qu’élément du modèle de conception (Design Pattern) du système d’onglets, l’utilisation de la touche Tabulation pour déplacer le focus sur le premier onglet de la liste des onglets fait basculer automatiquement le lecteur d’écran en mode application. À partir de là, toute l’interaction au clavier est gérée par le script. Cela signifie bien sûr que le script qui gère la fonctionnalité du widget doit prévoir la gestion de l’interaction au clavier !

Merci à Hans Hillen.