Aller au contenu

Accessibilite numerique-Automatiser certains tests-Notions de base

Une page de Wikiversité, la communauté pédagogique libre.

Mise en œuvre de l’accessibilité numérique

[modifier | modifier le wikicode]

Compétences détaillées

[modifier | modifier le wikicode]
  • Utiliser les outils de test automatique
  • Interpréter les résultats des tests
  • Intégrer les outils dans le process de production

Durée de la vidéo : 4 minutes 48 secondes

[modifier | modifier le wikicode]

Transcription textuelle de la vidéo

[modifier | modifier le wikicode]

Vous souhaitez vérifier l’accessibilité de votre projet web. Vous savez qu’il existe des outils de test automatique, mais lequel choisir ? Et dans quelle mesure les résultats en sont-ils fiables ?

Certains tests d’accessibilité sont automatisables et peuvent être réalisés par des robots. Par exemple, il est possible de vérifier de façon automatisée si toutes les images sont bien pourvues de l’attribut « alt » obligatoire.

Le responsable du projet n’est pas forcément celui qui effectue ces tests automatiques. En tant que chef d’équipe, vous veillerez à que les développeurs soient équipés de tels outils, afin d’éviter les erreurs au plus tôt. En tant qu’auditeur de l’accessibilité, vous choisirez d’alléger votre inspection des pages en commençant par utiliser l’un de ces outils de test.

1. Quels outils de test ?

Il existe plusieurs outils permettant de tester automatiquement une publication en ligne. On distingue ceux qui permettent de tester l’accessibilité et ceux qui permettent seulement de valider le code :

Valider le code

[modifier | modifier le wikicode]

Tout d’abord, il est facile de vérifier la validité́ du code, grâce aux validateurs mis à disposition par le W3C.

Cette validation automatique permet de vérifier non pas l’accessibilité́, mais la bonne facture du code, ce qui est un préalable et un minimum, de la même façon que l’on corrige les fautes d’orthographe et les coquilles d’un texte. Cette validation automatique est indispensable pour s’assurer d’un code sans erreur, ce qui est un prérequis à l’accessibilité.

Elle est surtout utilisée lors des développements : c’est un réflexe de développeur consciencieux, qui vérifie ainsi son code à chaque nouvelle page ou après chaque modification.

Veillez donc à ce que la validation W3C fasse partie de la trousse à outils et des réflexes de vos développeurs, internes ou prestataires externes.

Tester l’accessibilité

[modifier | modifier le wikicode]

Des consoles de tests dédiées à l’accessibilité́, comme l’inspecteur de pages Tanaguru, d’Océane Consulting, ou Opquast Reporting, de Temesis, permettent de détecter automatiquement un certain nombre de problèmes. Ces deux outils sont disponibles sous forme de service en ligne, en français. Ils analysent le code « généré », tel qu’il est vu par les utilisateurs, après application des scripts et feuilles de styles. Ils évaluent ce code au regard des critères automatisables de différents référentiels et produisent un rapport détaillé montrant les résultats de l’inspection.

Il existe plusieurs outils, qu’il serait impossible de lister tous ici : service en ligne ou de logiciel sur poste, gratuits ou payants…

Comment choisir ?

[modifier | modifier le wikicode]

Vous choisirez celui qui permet de tester les critères du référentiel que vous avez retenu : vérifiez donc que l’outil prend en compte le RGAA dans sa dernière version.

Comment lire les résultats ?

[modifier | modifier le wikicode]

Attention : quel que soit l’outil utilisé, ces vérifications automatiques ne couvrent qu’une petite partie des tests à réaliser.

Par exemple, si ces tests automatiques permettent de détecter quelles images ne sont pas pourvues de l’attribut « alt » obligatoire, ils ne peuvent vérifier si celui-ci est renseigné avec pertinence. Seul un humain peut vérifier cela.

Ces tests permettent de vérifier la présence des dispositifs techniques, et non la pertinence des alternatives. Ainsi, environ 20 % seulement des tests d’accessibilité sont automatisables.

Les tests automatiques ne suffisent donc pas, si le résultat est à 100 % positif, à garantir l'accessibilité d’un site.

Ces tests automatisés doivent impérativement être complétés par une inspection « humaine » des pages. En particulier pour détecter les erreurs ergonomiques ou éditoriales, ce qu’aucun robot ne saurait déceler.

Quand et pourquoi effectuer ces tests ?

[modifier | modifier le wikicode]

Ces outils fonctionnent sur des pages HTML. Ils peuvent donc s’utiliser dès que des pages (ou fragments de pages) sont produites, lors de la recette finale ou dès le début des développements :

  • Automatiser les tests permet de gagner du temps et de limiter les erreurs humaines. Ils sont effectués pendant les développements, où ils aident le développeur à déceler les erreurs et à les corriger.
  • C’est une façon très efficace d’amorcer la recette ou l’audit final, en économisant des ressources expertes, que l’on fera intervenir à bon escient, dans un second temps.


Ces tests automatisés ne sont pas obligatoires. Mais quel que soit votre processus de production, c’est une étape préalable. C’est-à-dire qu’elle doit intervenir avant l’inspection humaine (qu’il s’agisse d’une simple vérification, d’une recette ou d’un audit), qu’elle prépare.