Cela fait un moment que traîne l’idée d’un billet sur les tests utilisateurs, dans ma pile « articles à écrire dans pas longtemps », qui est haute comme ça et dont certains items ont 3 ans.
Un article paru sur le site d’Ochelys et intitulé Les tests utilisateurs pour l’accessibilité m’a donné l’occasion de rédiger un commentaire, devenu mini-topo, qui jette les bases d’une réflexion écrite sur la question.
On est évidemment bien loin de ce qu’il faudrait effectivement écrire sur le sujet, qui mériterait tout un bouquin! Mais au moins ça me permet de ne pas laisser ça en plan dans un lieu où personne n’a accès, pas même moi, parfois (je parle de mon cerveau, là). Considérons cela comme une pré-release alpha, si vous voulez.
L’article part d’une proposition avec laquelle on ne peut qu’être d’accord: cibler en priorité les implémentations qui correspondent aux besoins réels des utilisateurs. Avec en préambule le constat (ou l’hypothèse) que les listes de critères ne remplissent pas ce rôle.
L’approche préconisée pour cela est de se baser sur des tests utilisateurs, visant à « se [concentrer] d’abord sur ce qui est essentiel pour l’utilisateur en situation de handicap
« .
Je suis pour, à 100%, l’implication des utilisateurs dans le processus de développement et de corrections. Malheureusement le fait de partir des tests utilisateurs, et s’y limiter, recèle de nombreux écueils.
Les tests utilisateurs en accessibilité posent un problème récurrent: on teste autant l’utilisateur que l’application… Et en la matière, on se retrouve souvent à devoir faire le tri entre ce qui relève de l’utilisabilité, de l’ergonomie, et de l’accessibilité.
On a aussi le problème que l’utilisateur peut passer totalement à coté d’une information problématique. Par exemple, les liens vides (typiquement: images-liens avec alt="") ne sont pas restitués par un lecteur d’écran. Si bien qu’un utilisateur aveugle ne les détectera pas du tout, et du coup ne relèvera pas de problème. Avec ce genre de gag on a des sites qui ne passent pas le filtre d’une analyse basique par un testeur humain (et voyant), alors que les utilisateurs les déclarent accessibles. Pour les éviter il faut des scénarios d’utilisation exhaustifs, ce qui peut se révéler rapidement très coûteux par rapport à un test technique, même poussé, sur base d’une liste de critères.
De plus, on a à faire face à une variété très large d’utilisateurs. Le projet européen AEGIS a défini une petite vingtaine de personas pour l’accessibilité (en anglais). Si l’on veut tout englober on va donc se retrouver avec une énorme collection de scénarii.
Enfin, Il est très délicat de déterminer les niveaux où un problème est critique, problématique, ou gênant. Car cela va varier en fonction de l’utilisateur, du moment, du nombre d’occurrences du problème, de la config en cours d’utilisation… Croisons cela avec les accès mobiles, les différentes technos d’assistance susceptibles d’être employées par un même utilisateur, et la vitesse du vent (!)… On se retrouve avec une véritable usine à gaz dont il est difficile d’extraire des résultats exploitables à un coût acceptable. Car n’oublions pas qu’en général les travaux d’accessibilité sont effectués sur des queues de budget, voire en dehors, et sont rarement sur le haut de la pile.
Donc, on a eu beau tourner le problème dans tous les sens depuis des années, il est difficile de se passer totalement d’une approche par liste, qui a le mérite de couvrir tous les cas d’utilisation potentiels.
En conclusion je dirais que les tests utilisateurs et les listes de critères ne sont pas concurrents mais complémentaires. Et la priorisation est plutôt à faire d’abord sur les critères que sur la base uniquement des retours utilisateurs.
Une approche qui semble fonctionner dans bien des cas:
- Tests usine par les développeurs/contributeurs sur tous les bugs détectables par un outil automatique et des tests simples;
- Revue de critères techniques faits par un testeur humain, et boucles de rétroaction vers les développeurs/contributeurs;
- Une fois tout validé sur le plan purement technique, tests utilisateurs pour affiner les problèmes de pure utilisabilité.
Encore une fois, on effleure le sujet à 10000 pieds d’altitude ici. Mais la ressource définitive en la matière reste encore à écrire…
Si l’anglais ne vous rebute pas, plongez-vous dans ces articles de Karl Groves (encore lui), toujours très pointus, comme d’hab:
Olivier,
ça fait bien longtemps que ce sujet me titille voire bien plus que ça,
si ça te dit, essayons de faire un article un peu poussé sur le sujet,
tu es partant 😉
Très tentant! D’autant que tu as dû accumuler masse de retours terrain depuis que tu en fais…
Bon, on se cale ça dans un coin de la tête, et on échange en privé, si ça te va.
Quand la conférence de Sébastien Delorme à l’Accessiday sera en ligne, tu trouveras un écho certain à ce billet 🙂
Si c’est celle sur l’appli mobile accessible (conforme) mais pas utilisable, je l’ai vue passer. Expérience très instructive en l’occurrence!
Si j’ai bien compris, le problème de la confusion accessibilité/utilisabilité était flagrant. En plus sur le mobile on a la difficulté supplémentaire que les terminaux sont tellement propriétaires qu’il est quasiment impossible d’y appliquer des règles générales…
Juste un ajout (je commente très rarement) mais c’est un peu ennuyeux de vouloir différencier access desktop et access mobile. Attention de ne pas simplifier le problème juste à l’environnement mobile (je trouve que Sébastien à beaucoup jouer sur cet aspect pour sa conf mobile). Il se pose les mêmes problèmes aux environnements desktop. Pour info, dans bien des cas VoiceOver iOS se révèle meilleur que VoiceOver OSX.
Enfin pour l’article, Olivier, il me semble qu’un point pourrait se glisser entre le point 2 et le point 3 : les tests de restitution (qui sont à mon sens à la charge du testeur humain avant de pouvoir envisager de vrais tests utilisateurs). Et pour le coup, le travail devient délicat.
Effectivement, la confusion était nette.
Vivement qu’il y ait la vidéo, le sujet était particulièrement intéressant 🙂