Un audit RGAA automatisé et une revue experte donnent une photographie solide, mais rien ne remplace l’observation d’une vraie personne en situation de handicap qui tente d’accomplir une tâche sur le site. C’est aussi l’étape la plus mal préparée dans les agences, souvent reléguée à un recrutement de dernière minute via un post sur un réseau social.
Voici la check-list qu’on utilise avant chaque session de test utilisateur incluant des participants en situation de handicap, pensée pour éviter les faux pas les plus courants — sans jamais transformer la session en démonstration de bonnes intentions plutôt qu’en vrai recueil de données.
1. Définir les profils par technologie, pas par diagnostic
Le premier réflexe consiste souvent à chercher « une personne aveugle » ou « une personne à mobilité réduite ». C’est trop imprécis : deux utilisatrices non-voyantes peuvent naviguer très différemment selon qu’elles utilisent NVDA, JAWS ou VoiceOver, et selon leur niveau d’expertise avec l’outil. La check-list doit lister des combinaisons profil/outil, par exemple :
- Utilisateur non-voyant, lecteur d’écran NVDA, navigation au clavier
- Utilisateur malvoyant, zoom d’écran et contrastes renforcés
- Utilisateur avec tremblements ou amplitude de mouvement réduite, navigation au clavier ou dispositif de pointage adapté
- Utilisateur sourd ou malentendant, dépendant des sous-titres et transcriptions
- Utilisateur avec trouble de l’attention ou de la lecture, sensible à la densité d’information
2. Passer par de vrais réseaux de recrutement
Les associations spécialisées, les instituts de formation pour aveugles et malvoyants, les ESAT numériques et certains panels professionnels dédiés au test d’accessibilité constituent des canaux bien plus fiables qu’un appel générique sur les réseaux sociaux. Ils permettent aussi d’éviter l’écueil du participant qui coche la case handicap sans réellement utiliser de technologie d’assistance au quotidien.
3. Prévoir un temps de session réaliste
Un parcours qui prend cinq minutes à la souris peut en prendre vingt avec un lecteur d’écran, surtout si le site comporte des zones mal structurées. Caler une session de test sur la durée « normale » du parcours condamne le participant à l’échec avant même de commencer, et fausse les résultats en faisant passer un problème d’ergonomie du site pour une lenteur du participant.
4. Compenser financièrement, sans ambiguïté
Le temps et l’expertise d’un utilisateur en situation de handicap qui teste un site ont une valeur, au même titre que celle d’un testeur ordinaire. Une compensation claire, versée rapidement et sans démarche administrative compliquée, doit être annoncée dès le recrutement — pas négociée après coup.
5. Préparer des scénarios ouverts
Un scénario du type « cliquez sur le bouton vert en haut à droite » présuppose une perception visuelle et un vocabulaire qui n’ont pas de sens pour tous les participants. Mieux vaut formuler l’objectif sans décrire l’interface : « trouvez comment prendre rendez-vous avec un conseiller ». Le participant choisit alors son propre chemin, ce qui révèle beaucoup plus de problèmes réels.
Éviter le sur-accompagnement
Un animateur qui intervient trop vite dès qu’un blocage apparaît empêche d’observer le vrai comportement de contournement — ou d’abandon — du participant. La consigne donnée aux animateurs : laisser s’installer l’inconfort quelques instants avant de proposer une aide, exactement comme on le ferait pour un test utilisateur classique.
Un panel de trois utilisateurs bien choisis, avec des technologies d’assistance différentes, remonte souvent plus d’anomalies bloquantes qu’un audit automatisé complet.
Pour aller plus loin
Recruter des utilisateurs en situation de handicap ne s’improvise pas la semaine précédant le test. Cela se prépare en amont du projet, avec un budget dédié, des canaux de recrutement spécialisés et des scénarios pensés pour ne présupposer aucune modalité de perception ou d’interaction. C’est un investissement qui change la nature des retours, bien au-delà de ce que révèle un audit technique seul.
