Développement web : quand tester avec un lecteur d’écran ?

Pour savoir si votre site ou votre application web (web app) est conforme au RGAA 4 ^[1], vous n’avez pas besoin de tout tester avec un lecteur d’écran.

Mais il y a des situations où les tests avec un lecteur d’écran seront indispensables.

Par exemple :

• tester la restitution des composants riches (système d’onglets, boîte de dialogue, barre de progression, potentiomètre, etc.) ;
• évaluer des fonctionnalités et processus complexes.

Cependant, utiliser les différents lecteurs d’écran pour faire ces tests nécessite de bien connaître leur fonctionnement.

Or, si l’on ne s’en sert pas au quotidien, on peut ignorer, voire oublier certaines fonctionnalités. Mais même les personnes chevronnées ne connaissent pas toutes les possibilités de ces technologies complexes.

La prise en main et la connaissance des lecteurs d’écran sont donc essentielles pour comprendre et corriger les problèmes rencontrés par les utilisateurs et utilisatrices de votre site ou application web.

Voici quelques exemples de cas concrets où la connaissance des lecteurs d’écran vous sera d’une aide précieuse.

Accessibilité des composants riches

Quand vous intégrez un composant riche sur votre site, vous devez vous assurer qu’il est accessible aussi bien au clavier qu’aux lecteurs d’écran.

C’est le recours à l’API WAI-ARIA ^[2] qui rend ces composants riches accessibles. ARIA est une spécification qui propose des fonctionnalités à implémenter par les navigateurs.

Or, le support d’ARIA par les lecteurs d’écran peut être inconstant.

En effet, si ces fonctionnalités sont testées avec les navigateurs courants avant d’être introduites dans la spécification ARIA, en revanche aucun test n’est effectué avec les lecteurs d’écran. ^[3]

Il est donc possible qu’au moment où vous intégrerez ces composants ARIA sur votre site ou votre web app, les lecteurs d’écran usuels ne les gèrent pas encore correctement…

D’où la nécessité de tester ces composants riches avec les lecteurs d’écran pour s’assurer qu’ils seront bien restitués aux personnes déficientes visuelles qui les utiliseront, et améliorer si besoin cette restitution.

Base de référence

Ces tests de restitution sont encadrés par le RGAA et son document « Environnement de test ».

En ce qui concerne les ordinateurs de bureau, cet environnement de test est constitué de plusieurs combinaisons réunissant un système d’exploitation + un navigateur + un lecteur d’écran.

Ces combinaisons incluent les outils les plus utilisés :

• systèmes d’exploitation : Windows et MacOS ;
• navigateurs : Internet Explorer et Firefox pour Windows, et Safari pour MacOS ;
• lecteurs d’écran : NVDA et JAWS pour Windows, et VoiceOver pour MacOS.

C’est ce que l’on appelle la « base de référence ».

Effectuer des tests à l’aide des combinaisons recommandées par la base de référence va vous permettre de déterminer si les composants riches présents sur votre site ou application web sont compatibles avec l’accessibilité, et donc utilisables notamment avec un lecteur d’écran.

Comprendre les retours utilisateurs

Par ailleurs, savoir utiliser les lecteurs d’écran va également vous permettre de mieux comprendre les retours faits par les utilisateurs et utilisatrices sur votre site ou application.

Ces retours peuvent être compliqués à analyser si vous ne savez pas reproduire le problème relevé avec les technologies d’assistance dont se servent ces personnes.

En testant vos interfaces avec un lecteur d’écran, vous serez en mesure de déterminer si le problème relève d’une difficulté réelle ou s’il est la conséquence d’un manque de maîtrise du lecteur d’écran ou de l’une de ses fonctionnalités.

En effet, les lecteurs d’écrans disposent de nombreux paramètres qui impactent la façon dont l’information est restituée : par exemple les langues, la ponctuation ou l’utilisation de dictionnaire de prononciation.

Il est donc indispensable de maîtriser ces paramètres pour pouvoir réaliser des tests efficaces et, in fine, apporter des solutions aux utilisateurs.

Voici deux exemples réels qui illustrent ces difficultés.

Différence de restitution selon le mode d’interaction

La maîtrise des différents modes d’interaction et de navigation est un élément indispensable pour traiter les retours utilisateurs.

Imaginons par exemple qu’une personne déficiente visuelle vous explique qu’elle ne comprend pas la saisie attendue dans un formulaire :

• soit parce que les cases à cocher ou les boutons radio n’ont pas d’étiquette ;
• soit parce que l’étiquette est vocalisée après la case à cocher ou le bouton radio.

Ce type de retour est fréquent dans deux cas :

• lorsque la personne navigue dans un formulaire avec les flèches de direction au lieu de la touche de tabulation Tab ;
• ou bien lorsqu’elle a désactivé le mode d’interaction spécifique aux formulaires.

Dans ce genre de cas, ce n’est pas le code HTML mis en œuvre ni le travail de l’équipe de développement qui est en cause, et il ne s’agit pas d’un problème d’accessibilité.

La solution consiste à indiquer à l’utilisateur ou à l’utilisatrice les fonctionnalités qui lui permettent de naviguer dans un formulaire et de l’utiliser efficacement.

Confusion entre les liens et les boutons

Prenons un second exemple.

Imaginons un formulaire d’inscription dont l’utilisation modifie le contenu au fur et à mesure de la saisie de l’utilisateur sans recharger la page.

Mais une personne aveugle vous signale qu’à l’issue de cette procédure d’inscription, le lien de validation ne fonctionne pas : quand elle active le lien, rien ne se passe.

Ici, contrairement au premier exemple, le problème d’accessibilité est réel. En effet :

1. il aurait fallu utiliser un bouton, et non un lien, pour charger la seconde partie du formulaire ;
2. puis transférer le focus sur la partie mise à jour ou utiliser une propriété ARIA ad hoc pour vocaliser le contenu ajouté.

Reproduire le problème avec les différents lecteurs d’écran vous permettra de choisir entre les méthodes disponibles pour corriger et rendre le processus parfaitement accessible.