Comment aborderiez-vous les tests d'accessibilité pour une application web ?

Combinez travail automatisé et manuel, parce que les outils automatiques n'attrapent qu'environ un tiers des problèmes. Faites tourner un scan basé sur axe en CI pour le contraste, les libellés manquants et les problèmes de structure. Testez ensuite manuellement la navigation au clavier seul, l'ordre et la visibilité du focus, les annonces du lecteur d'écran, l'association des erreurs de formulaire, et le zoom à 200 pour cent. Jugez par rapport à WCAG 2.2 AA, la cible habituelle.

Je découpe en automatisé et manuel, et je dis d'emblée que l'automatisation n'attrape qu'environ un tiers des vrais problèmes. La partie automatisée est un scan basé sur axe branché dans le pipeline, qui attrape de façon fiable les défauts de contraste, les textes alternatifs manquants, les contrôles sans libellé et les structures de titres cassées, et qui ne coûte rien par exécution. La partie manuelle est là où vivent les vrais problèmes. D'abord je débranche la souris et je fais tout le parcours critique au clavier : puis-je atteindre chaque élément, l'indicateur de focus est-il visible, l'ordre suit-il la disposition visuelle, le focus se retrouve-t-il piégé dans une fenêtre modale, revient-il à un endroit sensé quand elle se ferme. Ensuite une passe au lecteur d'écran, parce que c'est la seule façon de savoir si une liste déroulante sur mesure s'annonce comme quelque chose de compréhensible ou comme un div sans libellé. Je vérifie que les erreurs de formulaire sont annoncées et rattachées programmatiquement à leur champ plutôt que juste passées en rouge. Puis un zoom à 200 pour cent et une fenêtre étroite pour que rien ne soit tronqué. Je teste contre WCAG 2.2 AA pour que le passé et l'échoué soient définis, et là où l'organisation le soutient, je pousse pour des sessions avec des utilisateurs qui s'appuient sur des technologies d'assistance.