Le fonctionnement des lecteurs d'écran diffère entre Mac et Windows. Nous détaillons ci-après comment cela se passe dans chacun des deux systèmes d'exploitation.
Le fonctionnement des lecteurs d'écran diffère entre Mac et Windows. Nous détaillons ci-après comment cela se passe dans chacun des deux systèmes d'exploitation.
Même si les raccourcis clavier utilisés sont différents, JAWS et NVDA fonctionnent de façon similaire pour restituer l'information. Comme évoqué dans le paragraphe Fonctionnement des lecteurs d'écran, les lecteurs d'écran restituent les informations provenant du système d'exploitation et des applications.
Dans le cas précis du navigateur web, l'information est restituée à la fois via le DOM et les API d'accessibilité.
JAWS et NVDA restituent l'information sous forme de deux modes :
Ce mode permet d'explorer le document, de le lire et de naviguer à l'intérieur.
Lorsqu'on arrive sur une page web, on est par défaut dans le mode navigation. Le lecteur d'écran restitue le contenu de la page sous forme d'un texte linéaire, c'est-à-dire, dans l'ordre dans lequel les contenus se présentent dans le code.
Pour ce faire, il utilise ce qui s'appelle le « tampon virtuel » dans lequel une copie du contenu est stocké pour être vocalisé. Certaines interactions entre l'utilisateur et le contenu utilisent également le « tampon virtuel ».
Dans le mode navigation, le texte est restitué à l'utilisateur sans formatage, changement de police ou styles.
Par exemple, si la page présente deux colonnes de texte, visuellement positionnées l'une à côté de l'autre, ces colonnes seront parcourues par le lecteur d'écran l'une après l'autre. Il n'existe pas d'élément « colonne » en HTML, donc le lecteur d'écran ne signalera pas que le contenu est structuré en colonne. En revanche, il s'appuie sur la sémantique des éléments du HTML retransmises par le navigateur pour restituer la nature des éléments telle que les titres et leurs niveaux, les liens et leurs états, les listes, les images, etc.
L'appui sur les flèches de direction permet de déplacer le focus du lecteur d'écran de caractère en caractère (flèche droite et gauche) et de ligne en ligne (flèches bas et haut), sans pour autant faire défiler la page. Pour cette raison, il est difficile pour une personne voyant l'écran de comprendre où se trouve l'utilisateur de lecteur d'écran lorsqu'il parcourt une page.
Lorsqu'il vocalise une page web, le lecteur d'écran fournit des informations supplémentaires à l'utilisateur, qui ne sont pas affichées sur la page web. Cette verbosité déroute les personnes qui ne maîtrisent pas le fonctionement d'un lecteur d'écran. Ainsi, lorsque le navigateur affiche une image servant de lien, le lecteur d'écran annoncera : « lien graphique » suivi de l'intitulé du lien. Sur une liste à puces, il vocalisera : « liste de x éléments ». Il pourra également annoncer si un lien a déjà été visité. Lorsqu'il arrivera sur un titre de niveau 2, il dira « titre de niveau 2 » suivi de l'intitulé de ce titre.
Quand la page est bien structurée à l'aide de titres, de listes, de liens, l'utilisateur peut se servir de raccourcis clavier pour se déplacer d'un élément à l'autre sur la page : par exemple, l'appui sur h pour NVDA et T pour JAWS, permet d'aller au titre de niveau Hx suivant. F déplace le curseur au prochain champ de formulaire, l à la prochaine liste à puces ou numérotée, t pour NVDA et Y pour JAWS déplacent le curseur au tableau suivant.
Il est également possible de demander au lecteur d'écran d'afficher, à l'aide d'un raccourci clavier spécifique, une liste de liens, de champs de formulaires ou des titres présents sur la page.
Ce mode permet à l'utilisateur d'interagir avec le contenu : éditer du texte, cocher une case ou un bouton, dérouler une boîte de liste.
Lorsqu'un composant interactif est présent sur la page, le lecteur d'écran quitte le mode navigation et passe dans le mode formulaire, que l'on appelle aussi parfois « le mode application ». Pour des raisons de simplicité, nous ne ferons pas de distinction entre mode formulaire et mode application, puisqu'en définitive, c'est le même. Nous appellerons ce mode le « mode formulaire » dans le reste du document.
Lorsque l'utilisateur passe dans le mode formulaire, l'appui sur les lettres ne permet plus de déplacer le focus à un élément donné, mais de saisir du texte et d'interagir avec l'élément à l'aide des raccourcis clavier spécifiques prévus par la spécification HTML lorsque il s'agit d'un élément natif ou par l'API ARIA lorsqu'il s'agit d'un composant développé avec JavaScript.
Sous JAWS, le mode formulaire s'active en appuyant sur la touche Entrée, sous NVDA en appuyant sur Entrée ou NVDA + Espace.
Pour en savoir plus sur les modes navigation, formulaire et application, consulter l'article de Léonie Watson, Understanding screen reader interaction modes (article en anglais).
Cet article explique notamment le comportement du lecteur d'écran dans un système d'onglets :
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.
La majorité des utilisateurs naviguent sur les pages web grâce au mode navigation. Cependant, lorsque vous devrez tester les composants étudiés plus loin dans ce guide, vous devrez vous servir de la touche de tabulation. C'est l'une des seules touches qui n'est pas interceptée directement par le lecteur d'écran. L'appui sur cette touche est automatiquement récupéré par le navigateur, ce qui déclenche le déplacement du focus vers l'élément suivant : lien, champ de formulaire, composant. Il en est de même, lorsqu'on appuie sur Entrée pour activer un lien ou Espace pour cocher une case à cocher.
La restitution de l'information par le lecteur d'écran VoiceOver sous MacOS est différente de celle faite sous Windows par JAWS ou NVDA.
Alors que les lecteurs d'écran sous Windows reformatent l'information pour la présenter d'une façon plus textuelle à l'utilisateur, la philosophie d'Apple est de faire naviguer l'utilisateur un peu comme une personne voyant l'écran.
Le lecteur d'écran affiche les différents composants d'une application et propose à l'utilisateur de se déplacer de l'un à l'autre grâce à une combinaison de touches spécifiques. On peut ainsi aller à la barre de menus, à la barre d'outils, au contenu de l'application ou à sa barre de titre. Une fois qu'on a atteint la zone que l'on souhaite explorer, on interagit avec un raccourci dédié pour entrer dans cette zone.
Sur les pages web, il en est de même. Il faut interagir avec ce que VoiceOver appelle la zone HTML avant de pouvoir la lire.
Il n'existe pas vraiment de mode navigation ou mode formulaire. Lorsqu'on lit une page web et qu'on arrive sur un champ de saisie, on peut directement saisir l'information dans le champ.
On peut néanmoins paramétrer VoiceOver pour qu'il passe en mode navigation rapide en appuyant simultanément sur les flèches droite et gauche pour activer ce mode. On peut alors, à l'aide de raccourcis clavier spécifiques, naviguer de titre en titre, de lien en lien, de champ de formulaire en champ de formulaire, etc. Il est aussi possible d'utiliser le mode de navigation rapide avec des touches uniques (voir le chapitre sur la configuration de VoiceOver). Ainsi, en appuyant sur h, on ira au prochain titre, sur l à la prochaine liste, ainsi de suite.
En ce qui concerne les composants riches, pour interagir avec eux, il sera nécessaire d'appuyer sur le raccourci qui permet cette interaction.