Identifier les principaux obstacles rencontrés par les utilisateurs et donner à l'équipe des priorités d'action concrètes.
RDV Service Public (lien externe) facilite la gestion et la prise de rendez‑vous des administrations.
L'équipe souhaitait évaluer l'accessibilité de son service et disposer d'une vision claire des corrections à prioriser.
Certains problèmes d'accessibilité paraissent très petits lorsqu'on les regarde dans le code ou dans l'interface. Un intitulé de bouton peu explicite, un message d'erreur difficile à comprendre, un élément qui ne reçoit pas correctement le focus au clavier… Pourtant, pour une personne qui utilise une technologie d'assistance ou navigue uniquement au clavier, ce « petit » problème peut suffire à interrompre complètement son parcours. C'est souvent dans ces situations que les échanges avec les équipes sont les plus intéressants : partir d'un problème très concret permet de comprendre pourquoi l'accessibilité compte réellement.
J'ai commencé par regarder le problème du point de vue de l'utilisateur : que se passe-t-il concrètement lorsqu'il rencontre cet élément ? J'ai ensuite vérifié son comportement dans différentes situations, notamment avec la navigation au clavier et les technologies d'assistance. Cela m'a permis de montrer à l'équipe non seulement ce qui n'allait pas, mais surtout dans quel contexte le problème devenait réellement bloquant. Nous avons ensuite cherché une correction adaptée au projet, en tenant compte simultanément de l'accessibilité, des contraintes techniques et de l'expérience utilisateur.
Un problème d'accessibilité n'est pas forcément spectaculaire pour être important. C'est souvent en partant d'une situation très concrète, plutôt que d'un critère du RGAA, que l'on permet à une équipe de comprendre les conséquences réelles d'un choix d'interface.
Derrière chaque non-conformité, il y a un usage et, surtout, une personne.
À l'issue de la mission
Informations
Crédits
Transcription