1. Ou des tests utilisateurs d’accessibilité vite et bien
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’intervenant accessibilité
numérique au CFHE (Conseil Français
des personnes Handicapées pour les
questions Européennes),
Et d’autres trucs…
3. 1.Tests auto (barre d’outils, extensions,
applications/site, appliquettes…)
2.Test manuels (expert/néophyte,
échantillon de pages, outils, rapports…)
3.Test utilisateurs
4. Pourquoi mettre en place des tests utilisateurs ?
Les tests utilisateurs accessibilité ont une vraie valeur ajoutée :
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 d’utilisabilité,
prioriser les actions de correction,
éviter les régressions,
en un mot, anticiper les points de blocage !
Pour être avocat de l’utilisateur,
rien ne vaut un test utilisateur
5. Qui teste ?
La perle rare :
3 à 5 « vrais » utilisateurs de l’application
Mais, on est souvent limité :
utilisateurs peu nombreux, choix limité
utilisateurs de différents types d’AT (ZoomText, VoiceOver, Jaws,
NVDA…)
difficulté de mise en place des tests (locaux, durée…)
À réserver à:
des gros projets (riches ou tests d’ergo déjà prévus)
des sites visant un public de personnes handicapées
6. Qui teste quand on est pas riche ?
Mini tests utilisateurs (mieux que rien)
Former à l’utilisation de lecteur d’écran, :
experts accessibilité (c’est déjà le cas !)
des développeurs
des recetteurs, des qualifieurs
des chefs de projet…
Jouer le jeu, faire comme si…
En fait, il faut jouer sur deux critères :
connaissance de l’application
connaissance des AT
7. Pré-requis
Pré-requis 1
Audit rapide technique pour s’assurer du niveau de prise en
compte de l’accessibilité
Pré-requis 2
Des scénarios ou parcours utilisateurs (user story, use case)
Pré-requis 3
Identification de la cible navigateurs/AT et les typologies
d’utilisateurs
8. Parcours utilisateur, User stories
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
9. Organiser les tests
Constituer un ou des binômes expert/utilisateur :
Le guide : un expert accessibilité, explique, pilote et filtre les retours
Le testeur : un utilisateur d’aide (vrai ou pas !), exécute les parcours
utilisateurs
Lorsque c’est possible, il faut changer le testeur régulièrement au cours
des tests pour améliorer qualité et quantité des retours.
Résultats :
repérage de points bloquants principaux et secondaires
identification des contenus inaccessibles
priorisation en fonction de l’incidence (gravité)
proposition de corrections techniques
10. 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 :
payer ses achats, somme à payer calcul JS inaccessible, 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
11. À quelles étapes doit on les planifier ?
"Test early, test often!«
À toutes les étapes :
– maquette, conception
– intégration : maquettes/pages fonctionnel(le)s
– développement : processus, composants
– recette/validation (confort, interopérabilité)
– évolutions (Non Régression)
12. 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.
13. Avantages
Une mise en œuvre aisée (2 personnes au minimum,
un testeur, un guide)
Une priorisation des actions de correction
Une amélioration progressive centrée utilisateur
Une approche fonctionnelle (pas page à page)
Une limitation du coût de la mise en accessibilité !
Sensibilisation/formation de tous les acteurs
Prise en compte des contextes d’utilisation et de besoins
différents pour tous les utilisateurs
en fait en lecteurs d’écran car les plus impactés par un manque d’A11y
Il faut connaitre le contexte d’utilisation de l’appli : à quoi sert elle, par qui elle est telle utilisée, que font les utilisateur avec, leur activité ?
Il faut des scénarios utilisateurs précis et en nombre suffisants permettant d’utiliser toutes les fonctionnalités principales, essentielles de l’appli
Conception : pédago
Dès que des pages voire même de simples composants d’interface sont prêts
En dev, inté, conception : en mode agilité avec les dev pédago formation
test composant par composant genre test unitaires au niveau utilisateur
En recette pour validation
Valider les évolutions patchs avec les scénars en prod suivi de l’access au long court, test de qualification d’une nouvelle version (NR) !
Conception : pédago
Dès que des pages voire même de simples composants d’interface sont prêts
En dev, inté, conception : en mode agilité avec les dev pédago formation
test composant par composant genre test unitaires au niveau utilisateur
En recette pour validation
Valider les évolutions patchs avec les scénars en prod suivi de l’access au long court, test de qualification d’une nouvelle version (NR) !