3. Tests utilisateurs

Nous avons énormément misé sur les tests utilisateurs réguliers afin de nous assurer que notre service était accessible. Les écarts constatés entre l'application du RGAA et l'accessibilité réelle ressentie des utilisateurs nous ont conforté dans la pertinence de cette approche : appliquer le RGAA ne suffit pas à être accessible.

a. Planifier les tests avec les bons profils

Nous avons effectué différentes séries de tests, auprès de 5 à 10 personnes à chaque fois :

1. experts accessibilité aveugles : ce sont les usagers que nous avons identifié 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. A 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.

Attention : Il est important d'améliorer l'accessibilité au maximum avant de démarrer des tests avec des personnes en situation de handicap car sinon elles risquent d'être bloquées à l'étape 1 du parcours et c'est une perte de temps pour tout le monde.

b. Adapter les protocoles pour les personnes déficientes visuelles

À 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. Exemple de problème rencontré en test :

Certains outils numériques utilisés dans les échanges avec les utilisateurs ne sont pas accessibles. Nous recommandons pour un échange ou test à distance :

• l'e-mail : il est interopérable et accessible pour les personnes déficientes visuelles
• le téléphone : pour les personnes les plus éloignées du numérique, rien ne vaut de s'appeler
• Zoom : en terme d'outils de visioconférence, le plus accessible est Zoom d'après Access42 (comparatif complet). Attention : il reste difficile pour les personnes aveugles d'activer le partage d'écran et impossible de cliquer sur un lien partagé dans le chat.

Concernant le protocole de test, en cas de collecte de données personnelles notamment, nous recommandons les méthodes suivantes de recueil du consentement :

• envoyer les informations par mail et recueillir le consentement par réponse au mail ou sur enregistrement vocal durant l'entretien
• envoyer le formulaire de consentement en document Word et recueillir le consentement par réponse au mail. NB : il est aisé de rédiger un document Word accessible si on utilise les niveaux de titres.
• si le test est en personne, imprimer le formulaire de consentement, le lire à voix haute, symboliser la zone de signature par un relief ou guider la main.

Exemple

Exemple de zone de signature

Pour les entretiens en présentiel, une zone de signature a été matérialisée sur la formulaire par des morceaux de post-its découpés.

c. Mener les tests avec des synthèses vocales

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 lecteur d'écran utilisé : VoiceOver (Apple), JAWS (PC), NVDA (PC), Orca (PC), Talkback (Android) ou autre. En cas de difficulté liée à du développement, cela sera utile pour reproduire le problème et identifier les bons ajustements. A noter : toutes les personnes déficientes visuelles qui en utilisent un ne savent 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.