les tests utilisateurs dans une démarche de mise en accessibilité du contenu web, présenté lors d'AccessiDay 2014

1. TESTS UTILISATEURS, MON AMOUR
DE LA NÉCESSITÉ DE TESTS UTILISATEURS EN
ACCESSIBILITÉ
OU SI VOUS FAITES DE L’A11Y, POURQUOI VOUS
DEVEZ AIMER ET VOUS AIMEREZ LES TESTS
UTILISATEURS
Vincent Aniort, @sanvin
27 juin 2014

2. c’est qui lui ?
• Travaille chez Orange dans le seul
service d’accessibilité EASE
• Expert AccessiWeb depuis 2006,
membre du GTA,
• Référent accessibilité numérique à
l’APF (Association des Paralysés de
France),
• Ainsi qu’au niveau du CFHE
(Conseil Français des personnes
Handicapées pour les questions
Européennes),
• Et d’autres trucs…

3. 1. Contexte
2. Comparaison
3. Testeurs
4. Organisation
5. Réaliser
6. Conclusion
Sommaire

4. 1. Contexte

5. c’est la qualité d’un produit, ou d’un service d’être
utilisable par tous
 personnes en situation de handicap
 seniors
 personnes valides
et dans tous les contextes
 avec tous les types de matériel
PC, MAC, IE, FF, Opéra, tél mobiles
 dans un contexte dégradé
mauvaise luminosité, Touchpad en mobilité, petite bande passante
 avec les logiciels spécifiques de compensation de handicap
lecteurs d’écran, loupe logicielle …
Qu’est-ce que l’accessibilité ?

6. L’accessibilité du web…
The power of the Web is in its
universality.
Access by everyone
regardless of disability is an
essential aspect.
Tim Berners-Lee,
W3C Director and inventor of the World Wide Web

7. Référentiel d'accessibilité
Niveau A : environ 1/3 des critères
Niveau AA : environ 2/3 des critères
Niveau AAA : TOUS les critères
WCAG (Web Content Accessibility Guidelines)
le WAI (Web Accessibility Initiative), groupe de travail du W3C,
édicte des recommandations
WCAG 1 (1999)
WCAG 2 (2008), devenu une norme ISO/IEC 40500:2012

8. Contexte
• Tests utilisateurs accessibilité != tests
utilisateurs d’ergonomie (un utilisateur peut
suffire !)
• L’accessibilité, ce n’est pas qu’un problème
technique mais humain
• Prendre en compte des contextes d’utilisation
et des besoins différents
• Pour être avocat de l’utilisateur, rien ne vaut un
test utilisateur

9. 2. Comparaison
Tests utilisateurs Audit expert
VS

10. Quelles sont les différences entre audit et
test utilisateur ?
tests utilisateurs audit technique complet
caractéristiques rapide et facile à mettre en
œuvre
long et couteux
intervenant 2 au minimum,
dont un utilisateur expert
au moins 1 expert accessibilité
mise en œuvre composant fonctionnel pages prêtes
mise en accessibilité itérative, progressive classique
échantillonnage principales fonctionnalités lot de pages
couverture partielle exhaustive (trop ?)
corrections ciblées, priorisées, limitées globales, complète, quantifiées
autres apports vertu pédagogique

11. 3. Testeurs

12. Qui est-il ?
La perle rare :
un « vrai » utilisateur de l’application
et
un (ou des) utilisateur expert d’aides techniques (lecteur
d’écran en priorité, plusieurs testeurs en
validation/recette)
Mais, on est souvent limité :
•utilisateurs peu nombreux
•utilisent différents types d’AT (VoiceOver, Jaws, NVDA…)
•avec peu de testeur, on aura un test u efficace

13. Qui sont-ils?
Former à l’utilisation d’AT, mini tests utilisateurs
(mieux que rien) :
•experts accessibilité (bien sûr !)
•des développeurs
•des recetteurs, des qualifieurs
•des chefs de projet…
En fait, il faut jouer sur deux critères :
•connaissance de l’application
•connaissance des AT

14. 4. Organisation

15. Comment les organiser ?
Pré requis 1
Il faut une personne formée ou un expert
accessibilité
En effet, besoin d’audit rapide technique pour
évaluer le niveau global :
•Aucune prise en compte  on fait pas
•Niveau moyen  identifier les barrières
•Propre  on améliore l’utilisabilité fine
(confort)/on valide

16. Comment les organiser ?
Pré requis 2
Des scénarios ou parcours utilisateurs (user story, use case) !
Qu’est ce ?
Un parcours utilisateur est :
– un ensemble d’instructions utilisateur,
– permettant d’effectuer une tâche précise dans l’ihm,
– cette tâche doit être une fonctionnalité principale, cruciale de l’application
Qui les écrit ?
Une personne qui connait l’appli cation et son contexte d’utilisation,
soit :
– MOA, métier
– Chef de projet (MOA,MOE, fonctionnel…)
– Utilisateur
– Expert accessibilité 
Ils doivent être… clairs, précis, complets et en nombre suffisant

17. Principales fonctionnalités
Fonctionnalités ou tâches essentielles d’une
application qui justifient son utilité pour l’utilisateur
Par exemple :
•Pour un site de vente :
– remplir son panier
– processus de paiement…
•Pour un site de prise de RDV client :
– identifier le client
– valider ses coordonnées
– poser un RDV, mettre un commentaire

18. Un exemple de parcours utilisateurs
Écran 1 : login/mot de passe
Écran 2 : page d’accueil
avec un choix de 5 onglets (menus principaux)
dont seuls 2 onglets sont utilisés : opérations et documentations
choix « Commande d’opération »
Écran 3 : « commande d’opération »
avec parcours ordonné sous forme de 7 onglets de 2e
niveau :
+ un picto « i » d’accès à une documentation (juste en dessous et présent sur tous les onglets).
 Choix onglet 1, « Type d’opération »
 Consulter les informations

19. Comment les organiser ?
Pré requis 3
Il faut avoir identifié la cible navigateurs/AT et les
typologies d’utilisateurs
Car, besoin de :
•valider le niveau d’accessibilité ressenti
•s’adapter aux différentes implémentations
•s ’adapter aux habitudes des utilisateurs (confort)

20. Comment les mettre en place ?
• Un binôme :
– Le guide : un technique formé ou un expert accessibilité
– Le testeur : en général, un utilisateur d’AT
ou
– un binôme, mais tout seul : jouer à l’utilisateur !
• Puis le guide explique et pilote, le testeur exécute les
parcours utilisateur un par un :
– repérage de points bloquants
– identification des contenus inaccessibles
– proposition de corrections techniques
– priorisation en fonction de l’incidence (gravité)

21. Points bloquants
• Barrières au niveau de l’accessibilité
empêchant d’effectuer une action
• Type de blocage, impact utilisateur
 priorisation des corrections
• Exemples sur un site de vente :
– label absent dans un formulaire d’inscription,
priorité 1
– système de correction des erreurs inaccessible,
priorité 2
– pas d’accès aux caractéristiques techniques des
produits, la priorité dépend du type de produits

22. Les qualités d’un bon test u
• Application, pas site contenu
• Rapide à mettre en œuvre
• S’assure que toutes les fonctionnalités cruciales
de l’application sont testées
• En mode « agile » à côté du dev, cycles courts,
itératifs
• Montrer les règles du jeu, impliquer les
développeurs  tester eux-mêmes, mini tests u

23. Retour d’expérience chez Orange
• 70% WCAG 2.0 AA et pas de points bloquants
• S’assurer que l’application est utilisable
(accessible) par tous et que l’on peut tout
faire
• Former les développeurs à tester tôt par eux-
mêmes puis validation experts
• Mise en place d’un label accessibilité pour
application métier (interne), valorisation du
travail de mise en accessibilité pour le projet

24. 5. Réaliser

25. À quelles étapes doit on les planifier ?
"Test early, test often!"
À toutes les étapes :
– spécification, conception
– intégration : maquettes/pages fonctionnel(le)s
– développement : processus, composants
– recette/validation (confort, interopérabilité)
– évolutions (NR)

26. 6. Conclusion

27. Qu’en retire t-on ?
• On a une approche fonctionnelle et non plus
page à page
• On identifie les problèmes d’interopérabilité et
de confort
• On lève les barrières d’accès aux fonctionnalités
clés de l’appli
• On priorise de fait les correctifs
• On améliore progressivement
• On sensibilise et on forme

28. Maintenant,
Ils permettent :
• Une mise en œuvre aisée (2 personnes)
• De tester tout au long du projet
• De prioriser les actions de correction
• Une amélioration progressive centrée
utilisateur et non plus QUE technique
• De valider qu’une application est accessible
Maintenant,

29. MERCI,
DES QUESTIONS ?