Pourquoi et comment réaliser des tests avec de vrais utilisateurs et utilisatrices ?

Ce que j’ai fait :

• lire l’article Involving Users in Evaluating Web Accessibility(lien externe) du W3C (World Wide Web Consortium)
• lire l’article Involving Users in Web Projects for Better, Easier Accessibility(lien externe) du W3C
• lire l’article Mettre en place des tests utilisateurs en accessibilité(lien externe) de Vincent Aniort

Ce que j’ai appris

La valeur ajoutée des tests utilisateurs/utilisatrices

L’implication d’utilisateurs et utilisatrices - en particulier en situation de handicap - pour tester l’accessibilité d’un projet se révèle positive sur plusieurs points :

• la mise en oeuvre de sites web plus accessibles et utilisables : en comprenant les problèmes d’accessibilité auxquels peuvent être confrontés les internautes, les développeurs et développeuses peuvent mettre en place des solutions plus robustes qui amélioreront le fonctionnement et l’utilisation du site, non seulement pour les personnes en situation de handicap mais aussi pour tous les internautes de manière globale.

• un développement plus efficace : intégrer au plus tôt des retours de test dans le projet permet d’éviter de nombreux écueils et d’avancer plus vite :
  • on prend des décisions en connaissance de cause et on ne perd pas de temps à deviner
  • on corrige rapidement les développements en cours
  • on valide les livrables au fur et à mesure
  • on évite les régressions
    
    
• une motivation supplémentaire : pour des chefs de projet, des designers, des développeurs et développeuses, voir des personnes utiliser leur produit et en particulier ne pas réussir à l’utiliser correctement engendre une motivation supplémentaire et leur apporte une vision humaine de l’accessibilité, au-delà d’une simple checklist de contrôle.

Quand tester ?

Il faut tester à toutes les étapes du développement du projet :

• dès la phase de conception/design : par exemple en intégrant des personnes en situation de handicap dans les cas d’utilisateurs ou la création de personas

• une fois le premier prototype réalisé : pour tester la navigation dans l’interface

• lors de la création des premiers composants d’interface : pour valider leur fonctionnement et leur facilité d’usage

• pendant le développement : pour valider les différentes pages

• lors d’une évolution : pour s’assurer qu’il n’y a pas de régression…

Qui teste ?

Dans l’idéal, il s’agit de personnes en situation de handicap utilisant des technologies d’assistance, qu’il est possible d’intégrer à un groupe de tests d’utilisabilité ou d’ergonomie classique. Ces utilisateurs et utilisatrices doivent avoir des connaissances suffisantes pour naviguer sur le web et utiliser des aides techniques.

Cependant, cette démarche peut avoir des limites :

• il existe une très grande variété de handicaps et d’aides techniques : pour être le plus exhaustif possible il faut donc un grand panel d’utilisateurs/utilisatrices incluant les grandes typologies de déficiences (déficient moteur, visuel, auditif, mental…) et illustrant l’hétérogénéité des aides techniques utilisées. Or, ils sont peu nombreux et difficiles à trouver.

• mettre en place des tests de cette envergure peut vite coûter très cher en terme de temps et de budget.

Cela ne signifie pas pas pour autant qu’il faut sacrifier ces tests. Vincent Aniort, dans son article Mettre en place des tests utilisateurs en accessibilité(lien externe), recommande ainsi :

Cependant, il faut réserver ce type de tests complets à des projets volumineux, possédant de nombreux utilisateurs, au budget conséquent (blindés quoi !), ou lorsque le public cible est un public de personnes en situation de handicap.

Une alternative possible, toujours proposée par Vincent Aniort, consisterait à concentrer les tests sur les personnes utilisant des lecteurs d’écran (car ce sont elles les plus impactées par un manque d’accessibilité) et procéder à de mini-tests, soit directement réalisés par de vrais utilisateurs de lecteurs d’écran, soit par des personnes de l’équipe formées (expert accessibilité, développeuse, chef de projet…).

Des pré-requis nécessaires

• effectuer un audit technique rapide du site pour se faire un idée du niveau d’accessibilité : si le niveau est trop bas, réaliser des tests ne servira pas à grand chose avant d’avoir atteint un seuil minimum de corrections.

• prévoir des parcours utilisateurs ou des scénarios afin de tester les fonctionnalités principales ou essentielles du site

• avoir identifié la cible du site en terme de combinaison navigateur/aide technique, ainsi que les typologies d’utilisateurs et utilisatrices

Déroulement des tests

Le principal intérêt du test est d’observer l’utilisateur dans le contexte réel d’utilisation : il faut donc un binôme expert accessibilité/utilisateur. Dans l’article Wikipédia Test utilisateur(lien externe), il est précisé :

Il est préférable que l’observateur se tienne à côté du participant, légèrement en retrait, afin d’établir une relation de confiance qui favorisera les échanges et l’observation.

Le W3C recommande également de mettre à l’aide les testeurs et testeuses en échangeant avec eux de manière informette, de les rassurer en leur rappelant qu’ils et elles sont libres d’arrêter à tout moment et de leur offrir une compensation appropriée pour leur temps.

A l’issue du test, on doit être en mesure de :

• repérer les points bloquants, c’est-à-dire les problèmes empêchant de réaliser une action : par exemple sur un site de vente en ligne, l’absence d’un label dans le formulaire de commande peut empêcher de faire son achat.

• prioriser les actions à mener

• proposer des pistes de correction