Tests utilisateurs mon amour (a11y)

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, @sanvin27 juin 2014

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…

1. Contexte2. Comparaison3. Testeurs4. Organisation5. Réaliser6. Conclusion

Sommaire

1. Contexte

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 handicaplecteurs d’écran, loupe logicielle …

Qu’est-ce que l’accessibilité ?

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

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

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

2. Comparaison

Tests utilisateurs Audit expert

VS

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

3. Testeurs

Qui est-il ?La perle rare :un « vrai » utilisateur de l’applicationet 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

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

4. Organisation

Comment les organiser ?

Pré requis 1Il 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

Comment les organiser ?Pré requis 2Des 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

Principales fonctionnalités

Fonctionnalités ou tâches essentielles d’une application qui justifient son utilité pour l’utilisateurPar 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

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

Comment les organiser ?

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

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’ATou– 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é)

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

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

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

5. Réaliser

À 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)

6. Conclusion

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

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,

MERCI, DES QUESTIONS ?