outils de test automatisé d'accessibilité. Mais ceux-ci ne peuvent pas tout vérifier. Prenons l’exemple des images, pour lesquelles une alternative textuelle doit être prévue. Il est possible de détecter automatiquement si une alternative est présente. Mais seule une relecture humaine peut évaluer si cette alternative est appropriée et pertinente.
La majorité des tests doit donc s’effectuer manuellement, par une inspection humaine. L’exécution de ces tests s’incorpore dans la routine de chacun des membres de l’équipe agile (designers, dev, PO) :
Ces vérifications doivent figurer dans la « definition of done » qui liste les critères permettant de considérer l’user story comme achevée et délivrable.
Comment vous est venue l’idée de créer cette formation ? Nous pratiquons, dans les missions qui nous sont confiées, une série de tests d’accessibilité lors des recettes fonctionnelles. Nous souhaitons partager notre expérience.
Ces tests s’inspirent des 10 « Easy Checks » du W3C. Bien qu’ils soient simples et rapides à effectuer, ils nécessitent une initiation. Il s’agit d’éprouver différentes situations de consultation réellement vécues par les utilisateurs : l’interface reste-t-elle compréhensible et utilisable en basse connexion, par exemple en déplacement, lorsque les images ne se chargent pas ou bien lorsque l’utilisateur a grossi les caractères pour les adapter à sa vue ? Comment navigue-t-il au clavier (sans souris) ? Telles sont les manipulations à apprendre.
C’est pourquoi nous avons conçu une formation opérationnelle, très concrète, qui repose sur la pratique, avec échanges et retours d’expérience, de façon à ce qu’à la fin de la journée, les participants sachent chacun et chacune effectuer les 10 tests fondamentaux qui serviront à vérifier l’accessibilité de tous leurs projets.