Zoom sur les outils de tests automatiques et manuels.

Ce que j’ai fait :

• lire l’article Selecting Web Accessibility Evaluation Tools(lien externe) du W3C (World Wide Web Consortium)
• lire l’article The Importance Of Manual Accessibility Testing(lien externe) de Eric Bailey
• lire l’article Vérifiez vous-même l’accessibilité(lien externe) de Romy Duhem-Verdière
• lire l’article Méthodes et outils de test(lien externe) d’Orange
• parcourir la liste des outils d’évaluation de l’accessibilité web(lien externe) du W3C

Ce que j’ai appris

Des outils pour tester l’accessibilité

Il existe de nombreux outils qui permettent d’aider à tester, voir tester automatiquement, l’accessibilité d’un site web. Ces outils d’évaluation sont des logiciels ou des services en ligne qui aident à déterminer si un contenu web respecte les recommmandations d’accessibilité.

Les outils d’évaluation peuvent identifier rapidement certains problèmes. Ils peuvent être utilisés tout au long du cycle de vie d’un projet :

• au démarrage du projet : pour le choix du framework, du CMS ou du logiciel

• pendant la phase de conception : lors de l’élaboration des maquettes et des prototypes

• pendant la phase de développement

• en production : pour vérifier que les contenus sont accessibles

Certains outils de tests sont conçus pour des métiers spécifiques : designers, développeurs et développeuses, rédacteurs et rédactrices de contenus, responsables d’assurance qualité…

On distingue les outils de tests automatiques et les outils de tests manuels.

Les outils de tests automatiques

Les tests d’accessibilité automatisés ne sont si plus ni moins que des séries de scripts pour tester la présence ou l’absence de certaines conditions dans le code. Ces conditions sont définies par des référentiels, comme le RGAA 4 (Référentiel Général d’Amélioration de l’Accessibilité) ou les WCAG (Web Content Accessibility Guidelines). Par exemple : pour tester la présence ou non d’un attribut alt sur les images.

L’automatisation se révèle ici extrêmement utile : un outil automatique peut répéter un tâche sans relache avec une mémoire parfaite et à un rythme bien plus rapide que tout être humain est capable de le faire.

Exemples

• aXe(lien externe) : outil d’évaluation de l’université de Deque, basé sur les WCAG et qui se présente sous la forme d’une extension navigateur.

• a11y.css(lien externe) : outil de tests relatif au CSS (Cascading Style Sheets) de Gaël Poupard, sous forme d’extension navigateur ou de bookmarklet.

• CheckMyColours(lien externe) : outil en ligne de Giovanni Scala pour vérifier les combinaisons de couleurs de premier plan et d’arrière-plan de tous les éléments DOM (basé sur les WCAG).

Des limites

Ces outils, aussi pratiques soient-ils, possèdent des limites et doivent être utilisés en connaissance de cause.

Les outils de tests automatiques génèrent des scores destinés à donner une indication sur le niveau d’accessibilité. Obtenir un score de 100% sur ces outils ne signifie pas que le site est 100% accessible. D’une part, nous l’avons vu dans l’article L’audit d’accessibilité (partie 2), on ne quantifie pas le niveau d’accessibilité mais son niveau de conformité à un référentiel donné. D’autre part, un score de 100% signifierait 100% de réussite aux tests automatisés uniquement : ces vérifications automatiques ne couvrent qu’une petite partie des 257 tests du RGAA 4 et ne permettent donc pas de vérifier tous les critères d’accessibilité.

Les outils automatiques peuvent également être source d’erreurs. Eric Bailey, dans son article The Importance Of Manual Accessibility Testing(lien externe), donne l’exemple suivant :

<h1 aria-hidden=“true”>
  Tired of unevenly cooked asparagus? Try this tip from the world’s oldest cookbook.
</h1>

Dans ce cas précis, l’attribut aria-hidden est appliqué correctement à l’élément <h1> d’un point de vue technique, mais prive les technologies d’assistance - et donc certains internautes - d’informations importantes (le titre de la page, la possibilité de naviguer sur le titre…).

Les outils de tests automatiques sont donc un bon point de départ pour tester l’accessibilité d’un site, mais il ne faut pas s’arrêter à eux. Eric Bailey écrit ainsi :

The same goes for automated accessibility tests, as well as GPS apps. They’re great tools to have, just get to know the terrain a little bit first.

Les outils de tests manuels

Les outils de tests manuels donnent des conseils et des instructions supplémentaires pour résoudre les problèmes qui ne peuvent pas être systématiquement évalués par des tests automatiques.

Exemples

• l’assistant RGAA(lien externe) : outil de la DISIC qui propose la liste complète des critères et tests accompagnés d’instructions pour guider l’évaluation.

• l’inspecteur d’accessibilité de Firefox qui permet entre autres de signaler les problèmes de navigation au clavier ou de vérifier si un objet de l’arbre d’accessibilité comporte bien un nom accessible.

Et sans outils…

Enfin, n’oublions pas que même sans outils il est facile de vérifier certains points d’accessibilité :

• tester la navigation du site uniquement au clavier

• est-il possible de mettre en pause ou de stopper un carousel ou une vidéo ?

• une vidéo est-elle entièrement compréhensible sans sous-titres ?