Tests utilisateurs mon amour (a11y)

  • Published on
    27-Jun-2015

  • View
    375

  • Download
    4

Embed Size (px)

DESCRIPTION

les tests utilisateurs dans une dmarche de mise en accessibilit du contenu web, prsent lors d'AccessiDay 2014

Transcript

<ul><li> 1. TESTS UTILISATEURS, MON AMOUR DE LA NCESSIT DE TESTS UTILISATEURS EN ACCESSIBILIT OU SI VOUS FAITES DE LA11Y, POURQUOI VOUS DEVEZ AIMER ET VOUS AIMEREZ LES TESTS UTILISATEURS Vincent Aniort, @sanvin 27 juin 2014 </li></ul> <p> 2. cest qui lui ? Travaille chez Orange dans le seul service daccessibilit EASE Expert AccessiWeb depuis 2006, membre du GTA, Rfrent accessibilit numrique lAPF (Association des Paralyss de France), Ainsi quau niveau du CFHE (Conseil Franais des personnes Handicapes pour les questions Europennes), Et dautres trucs 3. 1. Contexte 2. Comparaison 3. Testeurs 4. Organisation 5. Raliser 6. Conclusion Sommaire 4. 1. Contexte 5. cest la qualit dun produit, ou dun service dtre utilisable par tous personnes en situation de handicap seniors personnes valides et dans tous les contextes avec tous les types de matriel PC, MAC, IE, FF, Opra, tl mobiles dans un contexte dgrad mauvaise luminosit, Touchpad en mobilit, petite bande passante avec les logiciels spcifiques de compensation de handicap lecteurs dcran, loupe logicielle Quest-ce que laccessibilit ? 6. Laccessibilit 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. Rfrentiel d'accessibilit Niveau A : environ 1/3 des critres Niveau AA : environ 2/3 des critres Niveau AAA : TOUS les critres 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 dergonomie (un utilisateur peut suffire !) Laccessibilit, ce nest pas quun problme technique mais humain Prendre en compte des contextes dutilisation et des besoins diffrents Pour tre avocat de lutilisateur, rien ne vaut un test utilisateur 9. 2. Comparaison Tests utilisateurs Audit expert VS 10. Quelles sont les diffrences entre audit et test utilisateur ? tests utilisateurs audit technique complet caractristiques 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 prtes mise en accessibilit itrative, progressive classique chantillonnage principales fonctionnalits lot de pages couverture partielle exhaustive (trop ?) corrections cibles, priorises, limites globales, complte, quantifies autres apports vertu pdagogique 11. 3. Testeurs 12. Qui est-il ? La perle rare : un vrai utilisateur de lapplication et un (ou des) utilisateur expert daides techniques (lecteur dcran en priorit, plusieurs testeurs en validation/recette) Mais, on est souvent limit : utilisateurs peu nombreux utilisent diffrents types dAT (VoiceOver, Jaws, NVDA) avec peu de testeur, on aura un test u efficace 13. Qui sont-ils? Former lutilisation dAT, mini tests utilisateurs (mieux que rien) : experts accessibilit (bien sr !) des dveloppeurs des recetteurs, des qualifieurs des chefs de projet En fait, il faut jouer sur deux critres : connaissance de lapplication connaissance des AT 14. 4. Organisation 15. Comment les organiser ? Pr requis 1 Il faut une personne forme ou un expert accessibilit En effet, besoin daudit rapide technique pour valuer le niveau global : Aucune prise en compte on fait pas Niveau moyen identifier les barrires Propre on amliore lutilisabilit fine (confort)/on valide 16. Comment les organiser ? Pr requis 2 Des scnarios ou parcours utilisateurs (user story, use case) ! Quest ce ? Un parcours utilisateur est : un ensemble dinstructions utilisateur, permettant deffectuer une tche prcise dans lihm, cette tche doit tre une fonctionnalit principale, cruciale de lapplication Qui les crit ? Une personne qui connait lappli cation et son contexte dutilisation, soit : MOA, mtier Chef de projet (MOA,MOE, fonctionnel) Utilisateur Expert accessibilit Ils doivent tre clairs, prcis, complets et en nombre suffisant 17. Principales fonctionnalits Fonctionnalits ou tches essentielles dune application qui justifient son utilit pour lutilisateur 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 coordonnes poser un RDV, mettre un commentaire 18. Un exemple de parcours utilisateurs cran 1 : login/mot de passe cran 2 : page daccueil avec un choix de 5 onglets (menus principaux) dont seuls 2 onglets sont utiliss : oprations et documentations choix Commande dopration cran 3 : commande dopration avec parcours ordonn sous forme de 7 onglets de 2e niveau : + un picto i daccs une documentation (juste en dessous et prsent sur tous les onglets). Choix onglet 1, Type dopration Consulter les informations 19. Comment les organiser ? Pr requis 3 Il faut avoir identifi la cible navigateurs/AT et les typologies dutilisateurs Car, besoin de : valider le niveau daccessibilit ressenti sadapter aux diffrentes implmentations s adapter aux habitudes des utilisateurs (confort) 20. Comment les mettre en place ? Un binme : Le guide : un technique form ou un expert accessibilit Le testeur : en gnral, un utilisateur dAT ou un binme, mais tout seul : jouer lutilisateur ! Puis le guide explique et pilote, le testeur excute les parcours utilisateur un par un : reprage de points bloquants identification des contenus inaccessibles proposition de corrections techniques priorisation en fonction de lincidence (gravit) 21. Points bloquants Barrires au niveau de laccessibilit empchant deffectuer une action Type de blocage, impact utilisateur priorisation des corrections Exemples sur un site de vente : label absent dans un formulaire dinscription, priorit 1 systme de correction des erreurs inaccessible, priorit 2 pas daccs aux caractristiques techniques des produits, la priorit dpend du type de produits 22. Les qualits dun bon test u Application, pas site contenu Rapide mettre en uvre Sassure que toutes les fonctionnalits cruciales de lapplication sont testes En mode agile ct du dev, cycles courts, itratifs Montrer les rgles du jeu, impliquer les dveloppeurs tester eux-mmes, mini tests u 23. Retour dexprience chez Orange 70% WCAG 2.0 AA et pas de points bloquants Sassurer que lapplication est utilisable (accessible) par tous et que lon peut tout faire Former les dveloppeurs tester tt par eux- mmes puis validation experts Mise en place dun label accessibilit pour application mtier (interne), valorisation du travail de mise en accessibilit pour le projet 24. 5. Raliser 25. quelles tapes doit on les planifier ? "Test early, test often!" toutes les tapes : spcification, conception intgration : maquettes/pages fonctionnel(le)s dveloppement : processus, composants recette/validation (confort, interoprabilit) volutions (NR) 26. 6. Conclusion 27. Quen retire t-on ? On a une approche fonctionnelle et non plus page page On identifie les problmes dinteroprabilit et de confort On lve les barrires daccs aux fonctionnalits cls de lappli On priorise de fait les correctifs On amliore progressivement On sensibilise et on forme 28. Maintenant, Ils permettent : Une mise en uvre aise (2 personnes) De tester tout au long du projet De prioriser les actions de correction Une amlioration progressive centre utilisateur et non plus QUE technique De valider quune application est accessible Maintenant, 29. MERCI, DES QUESTIONS ? </p>