Mettre en place des tests utilisateurs en accessibilité
Préambule
Dans cet article, je vais m’appuyer sur la démarche que nous utilisons dans mon service d’accessibilité chez Orange et mon expérience pratique de mise en accessibilité de projets.
Les tests utilisateurs en accessibilité ne sont pas des tests utilisateurs d’ergonomie, mais en reprennent certains principes.
Ces tests peuvent être utilisés pour, bien sûr, le Web, pour les applications mobiles et globalement pour les documents numériques.
Quand doit-on faire des tests utilisateurs ?
Il faudra tester souvent et à toutes les étapes de développement du projet, à la création des premiers composants d’interface (menus, widgets, formulaires…), lors du développement (en agile, à chaque sprint ; en classique, à chaque page), tout au long de l’accompagnement accessibilité, durant la qualification/validation et pendant une évolution (test de non-régression).
Pourquoi mettre en place des tests utilisateurs ?
Les tests utilisateurs en accessibilité ont une vraie valeur ajoutée pour :
- déterminer une stratégie lorsque l’on intervient sur de l’existant,
- corriger au plus vite les développements en cours,
- vérifier la qualité des développements et valider les livrables,
- prioriser les actions de correction, éviter les régressions,
- en un mot, anticiper les points de blocage !
Qui teste ?
Dans un monde parfait…
Rien ne vaut des utilisateurs handicapés et utilisateurs de technologies d’assistance (lecteur d’écran, loupe logicielle…). En fait, une variété de vrais utilisateurs, c’est ce qu’il y a de plus efficace pour révéler les barrières d’accessibilité et d’utilisabilité. Cependant, ils sont peu nombreux, donc difficiles à trouver. Ils utilisent des aides techniques très variées, il faut, donc, un panel large 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 afin de tout couvrir.
Dans une démarche de conception centrée utilisateur et pour améliorer la pertinence des retours, on privilégiera des utilisateurs qui, de plus, utilisent l’application ou le site que l’on veut tester. Ces vrais utilisateurs de l’application connaissent le contexte d’utilisation de l’application/site (fréquence, cadre d’utilisation, besoins fonctionnels liés à l’activité, les habitudes d’utilisation…), toute une série de paramètres importants à prendre en considération lors des conclusions d’un test et des corrections proposées.
Tous ces utilisateurs peuvent, bien entendu, s’intégrer à des campagnes des tests utilisateurs d’utilisabilité ou d’ergonomie classiques.
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.
Mais, si c’est pas possible…
On peut tout de même tester sans être Crésus ! Pour cela, il faut comprendre que mon expérience m’a montré que les utilisateurs de lecteurs d’écran sont les plus impactés par un manque d’accessibilité, ils identifieront donc beaucoup des défauts d’accès à l’information. C’est aussi ceux pour qui les problèmes d’inaccessibilité sont les moins évidents à identifier et repérer sans tests techniques poussés. Je considère donc que ne tester qu’en tant qu’utilisateur de lecteur d’écran est suffisant et si l’on change de testeur souvent, ces tests sont pertinents et permettent d’identifier un grand nombre de problèmes d’accessibilité.
Il pourra, donc, s’appuyer sur des utilisateurs de lecteurs d’écran, voire former un membre de l’équipe à l’utilisation d’un lecteur d’écran et effectuer ce que j’appelle des mini-tests utilisateurs. Effectuer des tests utilisateurs, même au rabais (mini-tests), on en tire toujours de grands enseignements.
Lorsqu’on manque de vrais utilisateurs de lecteurs d’écran, on formera donc un ou plusieurs membre de l’équipe pour effectuer les tests :
- un expert accessibilité (bien sûr, mais il l’est déjà !),
- un développeur,
- un recetteur, un qualifieur,
- un chef de projet…
Il devra donc effectuer les tests presque comme un vrai utilisateur de lecteur d’écran, ou tout au moins en essayant de se mettre dans les mêmes conditions (dans la peau !) qu’un vrai utilisateur de lecteur d’écran.
Bien sûr, cette solution est un pis-aller, mais c’est toujours mieux que rien et cela permet rapidement pour un coût mineur d’effectuer de tests utilisateurs.
Entre ces deux extrêmes, toutes les solutions intermédiaires sont envisageables : avoir un utilisateur de lecteur d’écran dédié aux tests utilisateurs, c’est ce qu’on appelle un utilisateur expert (c’est notre choix chez Orange), avoir une liste d’éventuels utilisateurs d’aides techniques mobilisables pour les tests utilisateurs…
Comment les organiser ?
Prérequis 1
Tout d’abord, il faut un expert accessibilité pour organiser et guider les tests utilisateurs. L’expert va pouvoir, avant toute autre démarche, effectuer un audit technique dit rapide (au contraire d’un audit dit complet, exhaustif mais long à réaliser), qui va permettre de se faire une idée du niveau global d’accessibilité. Trois possibilités, l’audit révèle :
- aucune prise en compte de l’accessibilité et tant qu’un seuil minimum n’est pas atteint, rien ne sert de se lancer dans des tests utilisateurs ;
- un niveau moyen, l’audit utilisateur va permettre d’identifier les barrières principales d’accessibilité ;
- un bon niveau, avec l’audit utilisateur on va améliorer l’utilisabilité fine, le confort.
Prérequis 2
Puis, il faut posséder des parcours utilisateurs ou des scénarios (user story, use case), tous ces termes illustrent la même idée.
Qu’est-ce qu’un parcours utilisateur ?
Un parcours est un ensemble d’instructions utilisateur, permettant d’effectuer une tâche précise pas à pas dans l’IHM (interface homme-machine). Cette tâche doit être une fonctionnalité principale, essentielle de l’application, ce pour quoi elle a été développée.
Qu’est-ce qu’une fonctionnalité essentielle ?
Les fonctionnalités ou tâches essentielles d’une application sont celles qui justifient son utilité pour un utilisateur, ce à quoi elle est destinée.
Par exemple :
- Pour un site de vente :
- remplir son panier,
- entrer ses coordonnées,
- procéder au paiement…
- Pour un site de prise de rendez-vous client :
- identifier le client,
- valider ses coordonnées,
- poser un rendez-vous et y laisser mettre un commentaire.
Qui écrit les scénarios utilisateur ?
Une personne qui connaît l’application et son contexte d’utilisation écrit les parcours utilisateur :
- la MOA, métier,
- le chef de projet (MOA, MOE, fonctionnel…),
- Un utilisateur de l’application/site,
- l’expert accessibilité (ce n’est pas le mieux placé, souvent il connaît peu ou pas l’application),
- ou bien, ils peuvent être élaborés collégialement par l’ensemble des parties prenantes, ce qui est souvent le plus efficace !
Ils doivent être clairs, précis, complets et en nombre suffisant pour utiliser les fonctionnalités principales ou essentielles.
Prérequis 3
Il faut avoir identifié la cible en termes de couple navigateur/aide technique et les typologies d’utilisateurs de l’application/site.
Car on a besoin de jauger du niveau d’accessibilité ressenti par les utilisateurs lors des tests, adapter les implémentations aux différents couples navigateur/aide technique (notamment en ce qui concerne l’ARIA, Accessible Rich Internet Applications), et enfin, prendre en compte les habitudes des utilisateurs (confort et contexte d’utilisation de l’application/site).
Comment organiser les tests eux-mêmes ?
Il faut donc constituer un ou des binômes expert/utilisateur :
- Le guide : un expert accessibilité ou quelqu’un de formé au minimum à l’accessibilité.
- Le testeur : comme vu précédemment, un utilisateur d’aide technique, mais parfois ça peut être le développeur ou l’expert accessibilité lui-même jouant le rôle de l’utilisateur.
Lorsque c’est possible, il faut changer le testeur régulièrement au cours des tests pour améliorer qualité et quantité des retours.
Le guide explique et pilote, le testeur lui exécute les parcours utilisateur un par un. Grâce à cela, on va pouvoir :
- identifier les contenus inaccessibles,
- repérer les points bloquants et prioriser en fonction de l’incidence, la gravité,
- et donc, charge à l’expert de proposer des corrections techniques.
Qu’est ce qu’un point bloquant ?
Les points bloquants sont des barrières au niveau de l’accessibilité, empêchant d’effectuer une action. Par exemple sur un site de vente, des points bloquants peuvent être :
-
label
absent dans un formulaire d’inscription, priorité forte, - système de correction des erreurs inaccessible, priorité moyenne,
- pas d’accès aux caractéristiques techniques des produits, la priorité dépendant du type de produits.
L’expert va, au final, pouvoir rédiger un rapport de test afin de lister les points bloquants ou les améliorations envisageables, les prioriser et proposer des pistes de corrections.
Et chez Orange ?
Nous avons décidé que pour déclarer une application/site accessible, il faut respecter 70% des WCAG (Web Content Accessibility Guidelines) 2.0 niveau AA pour le web et 70% des nos guidelines pour les applications mobiles et pas de points bloquants lors des tests utilisateurs. Cette demande d’absence de points bloquants nous permet de nous assurer que l’application est utilisable (accessible) par tous et que l’on peut tout y faire (fonctionnalités essentielles).
Bien sûr, nous avons des testeurs handicapés utilisant notamment des lecteurs d’écran ou des loupes logicielles pour les validations finales ou les cas délicats. Mais nous formons, dans chaque projet, des membres de l’équipe (notamment des développeurs) pour effectuer au plus tôt des mini-tests utilisateurs.
Nous avons mis en place un label accessibilité pour applications métiers (interne) afin de valoriser le travail de mise en accessibilité et l’investissement du projet, et garantir à tous les utilisateurs un bon niveau d’accessibilité et d’utilisabilité.
Quelques bonnes pratiques
- Tester tout au long du projet, tester souvent et rapidement par des mini-tests et terminer un cycle par un « vrai » test complet de validation.
- S’assurer que toutes les fonctionnalités cruciales de l’application sont testées.
- Tester intensément des applications à l’interactivité complexe, par rapport, par exemple, à des site de contenu.
- Effectuer des tests dans lesquels les développeurs sont impliqués afin de les sensibiliser et leur faire comprendre les enjeux humains de l’accessibilité.
- En mode « agile », privilégier les tests en cycles courts, itératifs, au plus près des développeurs afin d’être plus rapide.
Les principaux avantages
- Une mise en œuvre aisée (2 personnes au minimum, un testeur, un guide).
- Une priorisation des actions de correction en matière d’accessibilité.
- Une amélioration progressive centrée utilisateur et non plus seulement technique.
- Une validation de l’accessibilité d’une application par une approche fonctionnelle (fonctionnalités essentielles) et non plus page à page de manière exhaustive. On ne corrige que ce qui doit être corrigé, on limite donc le coût de la mise en accessibilité !
- Sensibilisation voire formation de tous les acteurs d’un projet.
- Prise en compte des contextes d’utilisation et de besoins différents.
Conclusion
En mettant en place des tests utilisateurs en accessibilité, on se focalise sur ce qu’il y a d’humain dans l’accessibilité et non plus que sur l’aspect technique. Il ne faut jamais oublier que l’on se doit d’être l’avocat des utilisateurs, tous les utilisateurs, en prenant en compte le contexte d’utilisation de l’application ou du site.
Et ces tests sont encore plus cruciaux pour des applications mobiles pour lesquelles, souvent, l’accessibilité est à la traîne et l’accès aux sources plus délicat.
Donc, n’hésitez pas à faire ces tests, ils vous apporteront des pistes de corrections innovantes et des enseignements précieux. Même si votre budget est réduit, vous pouvez toujours opter pour des mini-tests utilisateurs.
4 commentaires sur cet article
Grégory Copin, le 3 décembre 2014 à 9:34
Un très bon article : complet, bien rédigé et avec un sujet passionnant... quoiqu'en pensent certains. Si on sort un peu du cadre des tests j'ajouterais qu'il faut former en amont les développeurs (voire les graphistes) à une sensibilisation à l'accessibilité, sans forcément que tout le monde devienne expert. Certaines bonnes pratiques (alternative textuelle, contenu disponible sans script, ...) n'engendrent aucun coût supplémentaire et se doivent d'être intégrées aux chartes de travail pour alléger encore un peu plus les phases de tests. Merci pour cet article en tout cas.
Frédéric, le 3 décembre 2014 à 12:07
Merci Vincent pour cette approche à la fois pragmatique et synthétique. Cette méthode efficace et peu coûteuse est exactement ce qu'il faut pour faire rentrer le respect de l'accessibilité dans les processus de production. La conclusion de l'article : rendre service à l'humain à l'autre bout de la ligne, permet de revenir à l'essentiel de la question de l'accessibilité.
Claire Bizingre, le 3 décembre 2014 à 12:24
Très bon article, clair, précis, un bon exemple de rédaction Web accessible !
J'approuve, le sujet est passionnant et faire des tests est essentiel.
En effet, il faut sensibiliser tous les acteurs des projets, pour que chacun puisse tester, en visant le niveau d'accessibilité requis.
La prise en main d'un lecteur d'écran comme NVDA est tout à fait possible. Une simple navigation au clavier est encore plus facile à réaliser.
Vos testeurs handicapés sont-ils des membres de votre organisation ou faites-vous appel à des personnes externes à Orange ?
Merci pour cet article
sanvin, le 3 décembre 2014 à 14:50
merci pour ces retours, sympa de constater que ça va vous servir ;) @claire pour des appli interne, on utilise des testeur interne qui connaissent le métier et nos appli, pour nos produits pour nos clients, on fait parfois appel à des testeurs externes grand public inclus dans des tests d'ergo. C'est en fait une question de budget !
Il n’est plus possible de laisser un commentaire sur les articles mais la discussion continue sur les réseaux sociaux :