9. Tester auprès des utilisateurs

a. Choisir son outil

Il existe différents moyens de prototyper son service.

• Idéalement, prototyper en HTML/CSS : c'est une technologie extrêmement robuste, documentée en accessibilité depuis plus de 20 ans, utilisable par quasiment tous les usagers et avec n'importe quelle technologie d'assistance. Pour cela, il faut cependant un minimum de connaissances techniques ou une personne experte en développement et en accessibilité.
• Sinon, vous pouvez aussi prototyper sous Figma de façon accessible mais nous ne l'avons pas testé. Voir l'article d'aide (en anglais)
• Enfin, vous pouvez aussi travailler la hiérarchie de votre contenu dans Word avec les niveaux de titre puis revenir tester le site HTML une fois développé en pré-prod.

b. Évaluer son accessibilité

Quelques autres conseils sur le prototype :

• Tester au maximum l'accessibilité vous-même avant de le mettre entre les mains des usagers. Vos tests ne vous apprendront rien s'ils sont bloqués dès la première étape. Vous pouvez par exemple vous auditer rapidement avec W3C, utiliser le plugin Wave ou vous mettre dans la peau de vos personas pour tester différents parcours de navigation avec différentes technologies d'assistance.
• Pour les parcours avec lecteurs d'écran, vous pouvez lire vos interfaces à voix haute pour vous rendre compte si elles sont digestes ou trop longues. Si vous êtes un peu plus expert, vous pouvez aussi activer le lecteur d'écran intégré à votre appareil (VoiceOver sur MacOS par exemple) et naviguer avec.

c. Planifier les tests avec les bons profils

Nous recommandons de mener plusieurs séries de tests, avec des personnes de profils différents (5 à 10 personnes à chaque fois) :

1. Experts accessibilité aveugles : ce sont les usagers que nous avons identifiés le plus facilement. Leurs retours sont extrêmement utiles pour identifier les points de progression techniques. Exemple de retour spontané :
   « Le label est bien relié. Je tape E j’arrive directement au champ d’édition de la recherche. Vous pouvez ajouter un “role=search”. »
   → Attention avec cette cible à rappeler que vous voulez aussi leurs retours en tant qu'usagers ! Ils ont une tendance à auditer le site avant tout.
2. Personnes aveugles éloignées du numérique : elles ont une tendance à être oubliées. S'il y a un arbitrage à faire entre ce qui est agréable pour une personne à l'aise et ce qui est le plus simple pour une personne pas à l'aise, trancher en faveur de la seconde. Si elles parviennent à utiliser le service, tout le monde y arrivera.
3. Personnes malvoyantes : une fois le prototype fonctionnel validé auprès des personnes aveugles, on peut alors commencer à faire une passe de forme. Les personnes malvoyantes utilisent leur résidu de vision pour naviguer : les repères visuels (couleurs, formes, photos…) sont extrêmement importants pour elles. À noter que la plupart de nos utilisateurs malvoyants ne naviguent qu'en mode sombre.

Nous avons veillé par ailleurs à avoir de la diversité d'âge, de genre, et de région.

Voir la partie 3. b. Recruter les utilisateurs.

d. Mener les tests avec des synthèses vocales

À part pour les personnes les plus expertes, naviguer prend plus de temps pour les personnes aveugles ou malvoyantes car elles ne peuvent pas survoler aussi facilement le site. Prévoir au moins 1 heure par personne.

Quoiqu'il existe d'autres technologies d'assistance, la plupart des usagers risquent d'utiliser un lecteur d'écran pour s'aider dans leur navigation. Quelques points à avoir en tête :

Durant l'entretien pré-test

• Demandez le logiciel de synthèse vocale utilisé : voir synthèse vocale
  En cas de difficulté liée à du développement, cela sera utile pour reproduire le problème et identifier les bons ajustements. À noter : certaines personnes déficientes visuelles qui en utilisent un ne savent tout de même pas ce qu'est un "lecteur d'écran".
• Contrairement à un test utilisateur classique où on va éviter de parasiter l’enregistrement oral, ici on va régulièrement acquiescer oralement afin de montrer son écoute car la personne ne peut pas voir si l'on hoche la tête.
• Rappelez que l'on veut avant tout des retours sur ce qu'elles comprennent ou non, ce qui leur plaît ou non... En effet, certaines personnes, surtout les plus expertes, ont tendance à tester l'accessibilité plutôt que le service en lui-même.

Pendant la passation du test

Contrairement à la phase d'entretien, l'utilisateur va ici être en train d'écouter son lecteur d'écran. Il faut donc essayer de parler le moins possible en même temps que la synthèse vocale. De plus, certaines personnes utilisent la commande vocale pour remplir les champs. Ne prendre la parole que si nécessaire.

Pour entendre le lecteur d'écran lorsque l'on anime un test à distance, plusieurs possibilités :

• Idéalement : l'utilisateur partage son écran et son lecteur d’écran (en haut-parleur et non en oreillettes). Mais cela est compliqué pour beaucoup de personnes, même avec Zoom.
• Si on n'a que le partage d'écran, on peut savoir où est l'utilisateur avec le Focus (attendre qu’il soit à l’arrêt pour parler).
• On peut aussi n'entendre que le lecteur d’écran, ce qui fonctionne sans visio en haut-parleur par téléphone.
• Avec l'habitude, et grâce aux retours spontanés des utilisateurs durant leur navigation, on comprend de mieux en mieux où ils sont sans partage d'écran ni entendre la synthèse vocale.

Dans les consignes : évitez de dire "en-dessous" ou "au-dessus" car cela ne parle pas forcément.

Ne soyez pas surpris si les utilisateurs parlent de "DV" : cela signifie "déficient visuel".