Compléter les tests automatisés d’accessibilité par des tâches

Un test automatisé d’accessibilité peut révéler des problèmes récurrents et être relancé après des modifications. Son résultat concerne toutefois les règles, pages et états examinés. L’affirmation « aucune erreur signalée » doit être accompagnée de ce périmètre pour permettre une décision utile.

Passer du rapport à une tâche concrète

Prenons une vue d’ensemble de projets fictive. Supposons qu’un scan ne signale aucune erreur dans l’état initial. Un client doit maintenant sélectionner un projet et télécharger le plan approuvé. Le plan de vérification manuelle de cette tâche prévoit ceci :

Ce tableau est une consigne de vérification, pas un rapport de tests déjà effectués. Selon l’outil, des contrôles automatisés peuvent en soutenir certaines parties. Le rapport initial sans problème ne permet pas, à lui seul, de conclure que la tâche entière peut être réalisée de façon compréhensible.

Associer constats automatisés et manuels

W3C WAI explique que certains contrôles d’accessibilité ne peuvent pas être automatisés et que les outils peuvent produire des résultats inexacts. Les problèmes signalés doivent donc aussi être évalués dans leur contexte précis. Pour l’utilisation au clavier, le W3C décrit également la nécessité de pouvoir quitter une zone atteignable ; les éventuelles méthodes particulières pour en sortir doivent être compréhensibles.

Rendre la prochaine vérification traçable

Consignez ensemble outil et configuration, états de page examinés, tâche manuelle et résultat observé. Après une correction, les étapes concernées sont revérifiées. On distingue ainsi ce qui a été examiné de ce qui reste ouvert. Un seul scan ou une seule tâche manuelle ne fournit pas encore une évaluation complète de l’accessibilité du produit.

Sources

• W3C WAI: Evaluation Tools Overview

• W3C: Understanding No Keyboard Trap