Quand recruter et dans quel objectif

Le recrutement de personnes en situation de handicap peut souvent être plus long et complexe que celui effectué pour des tests d'utilisabilité, pour des raisons évidentes. C'est un projet à long terme.

Il est essentiel de définir clairement les objectifs et le processus de sélection. 

• Avant de se lancer dans le recrutement, il est fortement recommandé de procéder à une série d'audits complets de la base de code, de l'application ou de l'interface.
• Créez une équipe dédiée au projet "Accessibilité" qui comprendra au moins un designer et un développeur web afin de couvrir les exigences techniques.

Testez votre code : assurez-vous de l'avoir testé avec des outils d'audit librement accessibles tels que :

• Wave Web Accessibility Tool
• Accessibility Developer Tools
• Lighthouse
• Axe
• Contrast Checker pour tester l'accessibilité des couleurs et gérer les contraintes liées au contraste
• Colour Contrast Analyser

Définissez des objectifs clairs et des directives d'accessibilité pour votre application ou produit.

• Identifiez vos utilisateurs et leurs besoins spécifiques en termes d'accessibilité.
• Établissez les directives qui doivent être mises en place à l'échelle du produit et déterminez quand elles doivent être appliquées (établissez un plan avec vos développeurs, Product Owners, Project Managers, Business Owners, etc.)
• Dans notre cas, il s'agissait de tester un flow complet: onboarding (sign-up form) et product discovery avec des utilisateurs de screen readers. Notre hypothèse était que l'on découvrirait des problèmes mais en réalité, le scree-reader ne permettait carrément pas la navigation du formulaire d'onboarding. Les directives étaient: permettre aux utilisateurs de screen readers de créer un compte et de naviguer la page produit.
• Je rajoute un point que je n'avais peut-être pas abordé: on oublie souvent qu'il n'y a pas qu'un seul type d'outils utilisé par les personnes handicapées: les screen readers ne sont qu'un infime partie de ces outils, la compagne de mon tester par exemple, utilisait les screen magnifiers. C'est ainsi que j'ai découvert une toute autre dimension. Mais ce serait peut-être un article pour une autre fois :)
• Réfléchissez à la manière d'intégrer et de respecter ces directives : cela peut nécessiter une révision de la base de code ou du design system.
• Effectuez un audit d'accessibilité interne (voire plusieurs).
• Adoptez une approche agile : implémentez, testez, révisez, re-testez…
• Établissez des priorités : élaborez un plan de recherche pour déterminer quels objectifs d'accessibilité doivent être atteints en priorité.
• Définissez des critères pour évaluer si ces objectifs sont atteints.
• c'est très basique à ce stade, on s'attendait à des améliorations à faire, mais en fait le code n'était pas accessible. Donc success/failure rate, time on task, perceived difficulty, satisfaction

Avant de commencer le recrutement :

• Assurez-vous d'avoir une équipe projet en place.
• Établissez des objectifs clairs.
• Effectuez un ou plusieurs audits internes (ou faites appel à des experts).
• Élaborez un plan de recherche (quels tests effectuer, quand, avec qui).
• Mettez en place un processus de sélection pour le recrutement.
• Dans le cadre d'un test d'accessibilité, l'objectif est de s'assurer que les personnes ayant recours à des supports ou aides (à l'écran ou externes, tels que des lecteurs d'écran, des outils de contraste, etc.) seront en mesure de naviguer sur votre site.

Posez-vous les questions suivantes :

• Quelles actions doivent pouvoir être réalisées sur ce site ou cette interface (par exemple, les flux critiques tels que la connexion ou le processus de commande) ?
• Quels sont les différents types de handicaps et quels sont leurs impacts sur nos utilisateurs ? Consultez https://theaccidentalally.com/toolkit/ pour plus d'informations.
• Quels outils ou supports seront utilisés par quels types d'utilisateurs ?

Il arrive souvent que, en voulant "inclure" certains groupes d'utilisateurs soumis à des mesures d'accessibilité, d'autres soient exclus. Par exemple, une vidéo peut être un outil formidable pour une personne dyslexique ou ayant une maîtrise limitée de la langue, mais elle sera totalement inaccessible pour une personne sourde. L'ajout d'une transcription ou de sous-titres peut résoudre ce problème facilement.

Ne vous concentrez pas uniquement sur les handicaps les plus "visibles" : de nombreux handicaps ne sont pas visibles, tels que la dyslexie, les troubles anxieux, l'autisme ou les troubles cognitifs, etc.

Dans mon entreprise par exemple, notre client base est plus âgée. Donc il coule de source de se référer aux déficiences cognitives de chacun à partir de 60 ans (visuelles, auditives) mais il est aussi intéressant de comprendre le background culturel de nos utilisateurs: si une personne dyslexique peut comprendre un texte complexe (un contrat par exemple), alors une personne dont la langue maternelle n'est pas celle du groupe cible local sera plus susceptible de consommer ce contenu avec aisance.

Où recruter des personnes pour un test d'accessibilité :

• Faites appel à des agences spécialisées.(on en a listé certaines ici)
• Collaborez avec des associations de personnes en situation de handicap.
• Consultez des experts du design inclusif (une recherche sur LinkedIn peut être utile).
• Envisagez également un recrutement en mode guérilla, pourquoi pas ?

Note :

Les personnes en situation de handicap sont généralement ouvertes à s'exprimer sur leurs besoins, mais il est important de ne pas les réduire à leur handicap. De même, il faut éviter de se concentrer sur un handicap spécifique : une personne aveugle peut privilégier certains outils ou aides, tandis qu'une personne sourde aura besoin d'un autre type de support de navigation. La qualité de votre recherche réside dans la diversité de votre panel.