Un formulaire de réservation peut sembler simple tout en empêchant quelqu'un d'aller au bout. Un sélecteur de date peut nécessiter une souris, une erreur peut n'être signalée que par la couleur, ou un délai d'attente peut effacer les informations saisies avant que la personne n'ait terminé. L'accessibilité examine ces obstacles comme faisant partie intégrante du fonctionnement du produit.
L'introduction du W3C à l'accessibilité du Web met l'accent sur les personnes en situation de handicap, tout en soulignant les avantages pour l'ensemble des utilisateurs. Ce travail englobe les contenus, les interactions, l'implémentation technique et les technologies utilisées pour y accéder.
Évaluer à la fois l'implémentation et l'expérience
Les vérifications techniques permettent de repérer des problèmes comme l'absence de noms accessibles, des contrastes insuffisants ou une structure incorrecte. La recherche menée avec des participants en situation de handicap montre comment l'expérience se déroule en conditions réelles. Ces approches sont complémentaires : une étude à petite échelle ne peut pas couvrir toutes les exigences, et un audit automatisé ne peut garantir que l'ensemble du parcours est réellement utilisable.
Les Règles pour l'accessibilité des contenus Web (WCAG) fournissent des critères vérifiables organisés autour de contenus perceptibles, utilisables, compréhensibles et robustes. Définissez la norme de référence et le périmètre de l'évaluation, puis combinez les tests automatisés avec des vérifications manuelles adaptées. Les obligations légales varient selon le contexte et doivent faire l'objet de vérifications spécifiques.
Pour notre exemple de formulaire de réservation, cela pourrait impliquer de tester la navigation au clavier, le rendu avec un lecteur d'écran, le zoom, la gestion du focus, la correction des erreurs et le délai accordé pour effectuer l'action. Se limiter au premier écran ferait passer à côté de blocages situés plus loin dans le parcours.
Recruter en fonction de l'expérience étudiée
Des personnes partageant un même handicap peuvent utiliser des appareils, des paramètres, des stratégies et des technologies d'assistance très variés. Construisez votre recrutement autour du produit et de la question de recherche, sans considérer qu'un participant représente à lui seul toutes les personnes ayant ce handicap.
Rendez la recherche elle-même accessible. Les invitations, les informations sur le consentement, la prise de rendez-vous, le matériel de test et les formats de communication peuvent tous influencer la participation. Renseignez-vous sur les besoins d'accessibilité et laissez les personnes utiliser leurs configurations habituelles dès que le protocole le permet.
Un prototype ne reflète pas toujours la sémantique ou les interactions du produit final. Soyez explicite sur ce que son niveau de fidélité permet d'évaluer, et testez l'expérience réellement développée lorsque ces détails sont essentiels.
Suivre l'obstacle jusqu'à la validation du correctif
Documentez ce qui a bloqué la progression, l'environnement concerné et l'impact pour le participant. « Impossible de sélectionner une date au clavier » donne à l'équipe une piste bien plus claire que « problème d'accessibilité ».
Testez à nouveau le correctif et vérifiez si le problème se répète ailleurs. Un composant corrigé peut partager son modèle avec beaucoup d'autres, tandis qu'un parcours complet peut encore comporter d'autres freins indépendants. L'accessibilité se construit à travers ces choix de design et de développement, la recherche aidant l'équipe à mesurer les conséquences bien réelles de chaque oubli.