Tester l’accessibilité avec la reconnaissance vocale

Les logiciels de reconnaissance vocale permettent de naviguer et d’interagir avec du contenu web à l’aide de commandes vocales. Ce type de technologie d’assistance est utilisé principalement par les personnes ayant des handicaps moteurs. Par exemple, certaines personnes sont tétraplégiques (paralysie des quatre membres), d’autres vivent avec des mains ou membres en moins, ou d’autres encore connaissent une habileté restreinte en raison de pathologies telles que l’arthrose. Dans certains cas, la reconnaissance vocale peut être utilisée conjointement à d’autres technologies d’assistance, dont le switch, et peut aussi être adoptée par des personnes ayant des handicaps cognitifs.

Afin de tester l’accessibilité d’un contenu web avec des logiciels de reconnaissance vocale, il convient d’abord de s’intéresser à leur mode d’utilisation. Dragon est compatible avec trois différentes méthodes d’interaction avec du contenu web :

• l’activation de contrôles en prononçant le texte correspondant ;
• l’utilisation de commandes vocales pour naviguer au clavier, notamment avec les touches Tabulation et Entrée ;
• l’utilisation de commandes vocales pour contrôler le pointeur de la souris.

L’activation des contrôles par la voix reste la méthode la plus rapide et la plus facile. Par exemple, il suffit de prononcer la phrase « Cliquer sur Produits » pour générer un clic sur un lien intitulé « Produits ». S’il existe plusieurs liens au sein d’un même texte (ou si une commande générique telle que « Cliquer sur le lien » est utilisée), Dragon indiquera tous les liens correspondant à la commande, en leur attribuant un numéro. L’utilisateur ou l’utilisatrice pourra alors activer le lien souhaité en prononçant le numéro correspondant.

Identification des contrôles à partir de leur intitulé

Il est important de souligner que les logiciels de reconnaissance vocale modernes se basent sur le nom accessible d’un contrôle pour l’identifier. Le texte accessible d’un contrôle correspond généralement au texte visible. Si toutefois le contrôle possède un texte accessible qui n’est pas visible, ce texte pourra être utilisé comme commande vocale de substitution (ou en complément).

Il est d’usage de désambiguïser les liens qui auraient tous le même texte visible. Pour cela, la pratique consiste à ajouter du texte non visible plus riche en informations. S’assurer que chaque lien est unique et explicite hors contexte rend service aux personnes qui utilisent des lecteurs d’écran.

<a href="/produits" aria-label="En savoir plus sur nos produits">En savoir plus</a>
…
<a href="/services" aria-label="En savoir plus sur nos services">En savoir plus</a>

Ce texte non visible peut également être exploité par les logiciels de reconnaissance vocale. Si on prononçait « Cliquer sur En savoir plus », Dragon identifierait les deux liens associés à ce texte en les numérotant, comme nous l’avons vu précédemment. Il serait aussi possible de prononcer « Cliquer sur En savoir plus sur nos produits » afin d’activer ce lien uniquement, mais encore faut-il savoir que c’est bien ce texte qu’il faut prononcer. Chose impossible s’il n’est pas visible.

Cet exemple n’est donc pas inaccessible puisque seules deux commandes sont nécessaires pour identifier le lien souhaité. Cela dit, s’assurer que le texte visible de chaque contrôle est unique améliore l’utilisabilité pour celles et ceux qui utilisent la reconnaissance vocale. De même, pour les contrôles de formulaire, une personne utilisant la reconnaissance vocale pourrait accéder aux champs de saisie dépourvus d’une étiquette visible ou liée, mais le processus serait plus simple et rapide avec un texte lié au champ dans le code :

<label for="fullname">Prénom et nom</label>
<input id="fullname" name="fullname" type="texte" />

Si un contrôle possède à la fois un texte visible et un texte accessible, comme dans les exemples précédents, il faut absolument que le texte accessible commence par le texte visible. Dans l’exemple qui suit, la commande vocale « Cliquer sur En savoir plus » risque de ne pas permettre d’identifier le lien puisque le texte « En savoir plus » n’est pas inclus dans le texte accessible du lien :

<a href="/produits" aria-label="Plus d’informations sur nos produits">En savoir plus</a>

À l’inverse, la commande retrouvera le lien si le texte accessible commence par le texte visible :

<a href="/produits" aria-label="En savoir plus sur nos produits">En savoir plus</a>

Naviguer avec le clavier par la voix

En plus d’activer les commandes directement, la reconnaissance vocale permet aussi de prononcer des commandes de navigation au clavier comme « Tabulation » et « Appuyer sur Entrée » dans le but d’interagir de la même façon qu’une personne utilisant un clavier ou un switch.

Ainsi, afin qu’un contenu web soit facilement accessible aux utilisateurs et utilisatrices de technologies de reconnaissance vocale, il doit être compatible avec une navigation au clavier.

Naviguer avec la souris par la voix

Dragon propose aussi des fonctionnalités qui permettent de contrôler le pointeur de la souris ou le pseudo-pointeur. Le Damier de souris (« MouseGrid » en anglais) constitue l’une de ces fonctionnalités. En annonçant « Damier de souris » ou « Fenêtre damier », la page se recouvre d’une grille de 9 cases, chacune numérotée. L’utilisateur ou l’utilisatrice peut alors énoncer l’un de ces numéros pour générer une grille plus ciblée, comportant également 9 cases. Ce processus se poursuit jusqu’à ce que le damier de souris se situe dans une zone suffisamment précise pour permettre de cliquer sur un élément spécifique.

Ce type d’interaction peut être utilisé pour les contrôles qui ne contiennent pas de texte visible. C’est le cas notamment des boutons graphiques et des contrôles qui ne peuvent pas recevoir le focus. Mais comme vous pouvez l’imaginer, il peut être fastidieux et chronophage d’isoler les contrôles en procédant de cette manière. La tâche est rendue beaucoup plus facile lorsque les contrôles peuvent recevoir le focus et disposent soit d’étiquettes de texte visibles soit de texte accessible évident et intuitif qu’il est possible de deviner. Par exemple, si un bouton de partage sur le réseau social Facebook inclut le mot Facebook dans son texte accessible, une personne pourrait raisonnablement se dire que si elle énonce le mot « Facebook », alors le contrôle sera activé.

Dragon prévoit même des commandes directes pour contrôler la souris, dont « Déplacer la souris en bas » (qui anime lentement le pointeur jusqu’à ce que l’on dise « Arrêter » ; la vitesse de la souris peut être contrôlée également grâce à des commandes telles que « Plus vite » et « Plus lentement »). Ces commandes peuvent être sollicitées pour interagir avec du contenu qui n’est pas accessible au clavier ; mais recourir à cette fonctionnalité est encore plus fastidieux et chronophage que recourir à la fonctionnalité Damier de souris et requiert par ailleurs une bonne réactivité de la part de l’utilisateur ou l’utilisatrice. Ce n’est donc pas une solution qui se prête aux interactions avec la souris nécessitant une maîtrise précise (le glisser-déposer, par exemple). Ainsi, tout contenu de ce type doit également posséder des équivalents claviers évidents et intuitifs (comme cela devrait de toute façon être le cas).

Contenus mal masqués

La possibilité d’interagir via des commandes vocales implique nécessairement une vision suffisante. Les personnes ayant recours à la reconnaissance vocale doivent forcément pouvoir voir l’écran afin de percevoir les intitulés, la position du focus, etc. Si ces choses sont masquées, il sera très difficile pour ces personnes d’interagir avec le contenu. Il en va de même pour les personnes qui voient l’écran et naviguent au clavier.

Un problème qui revient souvent dans ce contexte concerne l’utilisation d’en-têtes flottants qui parfois chevauchent ou masquent du contenu pouvant recevoir le focus à mesure que la page se déroule. Les en-têtes flottants doivent être évités. Autre problématique récurrente : lorsque le focus n’est pas emprisonné à l’intérieur d’une fenêtre modale, la navigation des contenus cachés derrière la fenêtre devient impossible. Tout comme pour celles et ceux qui naviguent au clavier et dont la vision n’est pas diminuée, les personnes utilisant la reconnaissance vocale se retrouveraient dans une situation où le focus pourrait se déplacer sur un élément qu’elles ne perçoivent pas, ou bien l’activer par erreur. Les fenêtres modales doivent toujours piéger le focus au sein de la fenêtre tant que celle-ci est ouverte.

Sémantique des éléments

Présumer de la vision d’autrui pourrait nous mener à penser que la sémantique sous-jacente des contenus web, indispensable pour les personnes déficientes visuelles qui utilisent un lecteur d’écran, n’a pas d’intérêt pour les personnes voyantes ayant recours à la reconnaissance vocale. Mais c’est faux. Nous avons pu le constater dans plusieurs exemples où il existe une différence entre le texte accessible d’un contrôle et son texte visible. Il existe également des cas où des aspects sémantiques tels que le rôle ou l’état sont tout aussi importants en termes de reconnaissance vocale.

Les commandes servant à activer des types de contrôles spécifiques tels que les boutons radio et les cases à cocher s’appuient sur la sémantique sous-jacente de ces contrôles. Une case à cocher native implémentée avec <input type="checkbox"/> réagirait à la commande « Cliquer sur la case à cocher », et puisque Dragon prend également en charge les rôles ARIA (versions 1.3 et ultérieures), une case à cocher personnalisée implémentée avec role="checkbox" fonctionnerait correctement également. Toutefois, une case à cocher personnalisée dépourvue d’une sémantique adéquate et qui n’a d’une case à cocher que l’apparence ne réagirait pas à cette commande. Ainsi, il est tout aussi important pour les personnes utilisant la reconnaissance vocale que pour celles qui utilisent des lecteurs d’écran que les contrôles personnalisés soient associés à la bonne sémantique.

Il est également intéressant de se pencher sur les avantages de maintenir une certaine cohérence en matière d’« affordance » visuelle, c’est-à-dire la correspondance entre ce que représente un élément et ce à quoi il ressemble. Si un élément ressemble à un bouton, mais n’est en réalité qu’un lien stylisé, il ne serait pas possible d’utiliser la commande « Cliquer sur le bouton » pour activer le contrôle, contrairement à ce que l’élément laisse penser. S’il ne s’agit pas en soi d’un manquement aux règles pour l’accessibilité des contenus web (WCAG), il est tout de même préférable d’utiliser des styles qui offrent une cohérence visuelle par rapport à la fonction de l’élément en question.

Exigences des WCAG

Compte tenu de tous ces différents scénarios, un certain nombre de critères de succès des WCAG s’appliquent en faveur des personnes qui ont recours à la reconnaissance vocale. On retrouve, par exemple, tous les critères de succès portant sur l’accessibilité par le clavier, et plusieurs critères de succès relatifs à la sémantique des éléments et aux limites d’interaction :

Ressources

• Consultez cet article sur ARC (en anglais, réservé aux personnes ayant souscrit un abonnement Essentials ou Enterprise)
• Logiciel de reconnaissance vocale Dragon
• Bases de la navigation web (Support Dragon) (en anglais)
• Naviguer à l’aide de la reconnaissance vocale (en anglais)

Traduction : Eleanor Hac.