Propulsé par le RAAMM

Technique – outils d’évaluation

Introduction

On retrouve une grande variété d’outils destinés à l’évaluation technique de l’accessibilité. Cette abondance d’options peut rapidement devenir déroutante. Pour une approche plus optimale et cohérente, il est recommandé de se limiter à une petite sélection d’outils, qui se complémentent dans les fonctions offertes.

Divers facteurs et préférences peuvent influencer le choix d’outils d’évaluation. Dans cette perspective, nous fournissons quelques exemples d’outils bien établis, pouvant servir de première base de référence.

Cette section se consacre principalement aux outils d’évaluation de sites Web et d’applications Web. Nous mentionnons cependant, à titre indicatif, quelques exemples d’outils pour l’évaluation technique de documents téléchargeables ou d’applications mobiles.

Enfin, la majorité des outils cités en exemple sont totalement gratuits. Certains le sont partiellement, mais comportent plusieurs options intéressantes sans frais. Notons par ailleurs que des solutions payantes spécialisées se trouvent sur le marché, à coûts modérés ou considérables selon la nature des fonctionnalités.

Note : Pour en apprendre davantage sur l’évaluation à l’aide d’outils d’adaptation, consulter plutôt la page sur l’évaluation fonctionnelle.

Exemples d’outils d’évaluation technique

Les outils d’évaluation automatique contribuent à fournir un premier aperçu du niveau d’accessibilité d’un site Web, en détectant un certain nombre de problèmes d’accessibilité parmi l’ensemble des points à surveiller.

Malgré leurs limites, ces outils demeurent très utiles pour les équipes de conception-développement Web. En effet, l’évaluation automatique facilite le repérage de plusieurs enjeux d’accessibilité très tôt dans le processus de développement. Cela évite de repousser toutes les vérifications et corrections à des phases tardives, où il est souvent plus difficile et coûteux d’intervenir. Cela peut aussi alléger le travail lors des contrôles qualité, dans la perspective d’un partage des responsabilités de l’accessibilité au sein des équipes.

Nous vous présentons WAVE et Axe DevTools, deux outils réputés d’évaluation automatique et semi-automatique, qui se complémentent bien dans leurs capacités respectives.

WAVE

Cet outil peut s’employer de différentes manières, notamment :

WAVE affiche presque instantanément tous les aspect de la page qui peuvent faire l’objet d’une évaluation automatique ou semi-automatique. Parmi ses points forts, il offre une vue d’ensemble des erreurs et des avertissements, ce qui permet de repérer facilement et de corriger plusieurs problèmes.

Cet outil ne produit aucun rapport, mais présente les résultats en surcouche de la page web, accompagnés de nombreuses icônes. Pour faciliter le repérage des contenus signalés, on peut filtrer l’affichage par type d’erreur ou par catégorie de rétroactions. Il est aussi possible de désactiver les styles de la page ou de visualiser le code source correspondant. Les signalements sont accompagnés d’explications en langage simple et clair, dans une interface en anglais.

Axe DevTools

Axe DevTools est une extension de navigateur compatible avec Chrome, Firefox et Edge. Pour télécharger : extensions Axe DevTools (en anglais).

L’outil se base sur axe-core, une bibliothèque de tests d’accessibilité en code libre, réputée pour sa performance et sa flexibilité. Soulignons qu’Axe DevTools couvre l’entièreté des règles axe-core, comparativement à d’autres extensions comme Lighthouse, qui n’utilise qu’une sélection de ces règles.

Axe DevTools s’intègre aux outils de développement du navigateur, avec une interface graphique partiellement traduite en français. Les problèmes détectés sont classés par gravité, avec des explications de chaque problème et les segments de code concernés. Il est possible d’enregistrer et d’exporter les résultats.

Enfin, Axe DevTools peut tester une page entière (option gratuite), mais comprend aussi des fonctionnalités payantes plus spécifiques, comme le test d’une partie de page ou des tests guidés intelligents. Ces derniers accompagnent ou allègent certaines vérifications manuelles.

Vous pouvez consulterr la liste des règles qu’Axe Dev Tools est en mesure d’évaluer (en anglais).

Limites des outils d’évaluation automatique

  • Détection partielle : L’évaluation automatique ne détecte qu’une fraction des problèmes d’accessibilité. Il est crucial de combiner cette approche à une évaluation technique manuelle, ainsi qu’à des tests fonctionnels avec des outils d’adaptation, pour un portrait juste et complet du niveau d’accessibilité.
  • Nécessité du jugement humain : Il demeure important de s’assurer que les signalements sont valides, ce que permettra un examen manuel de l’élément en cause, à la lumière des rétroactions de l’outil. De plus, les outils automatiques peuvent émettre des avertissements qui exigent une vérification manuelle.
  • Résultats variables selon le contexte d’évaluation : Les outils automatiques comme WAVE et Axe DevTools évaluent le code source tel que généré par la page Web au moment du lancement de l’évaluation. Ainsi, les résultats affichés, incluant le nombre de signalements, peuvent varier selon divers facteurs. Par exemple : la largeur d’écran (interfaces responsives), l’état des composants interactifs au moment du test, la présence de contenus ou de notifications éphémères, etc. En testant la page dans différents contextes de présentation, on augmente les chances d’intercepter divers enjeux d’accessibilité.
  • Contenus des <iframe> : Certains outils automatisés, comme Axe DevTools, parviennent à évaluer les contenus à l’intérieur des <iframe>. Ce n’est toutetefois pas le cas de WAVE. Pour vérifier rapidement si une page contient cette balise : se rendre dans l’onglet des détails de WAVE, puis vérifier dans la partie « Structural elements » si cet élément y est mentionné.

Voici quelques exemples d’outils permettant une évaluation plus spécifique de certains critères d’accessibilité.

Bookmarklets

Les bookmarklets sont des favoris de navigateurs qui contiennent du code JavaScript au lieu d’une adresse. On peut les exécuter pendant l’affichage d’une page web. Plusieurs bookmarklets d’accessibilité modifient l’affichage de la page pour faciliter des vérifications manuelles. Certains fournissent aussi des rétroactions automatisées. Exemples :

  • Text Spacing Bookmarklet : pour évaluer le critère 1.4.12 – Espacement du texte (depuis WCAG 2.1).
  • ARIA Usage (TPGi) : pour évaluer l’emploi d’ARIA. Permet plusieurs vérifications automatiques actuellement non couvertes par des outils comme Axe DevTools et WAVE.
  • Visual ARIA Bookmarklet : pour une visualisation d’ensemble de l’emploi d’ARIA dans une page. Aussi proposé comme extension de navigateur pour Chrome et Firefox. L’un des avantages de l’extension est de permettre un filtrage des informations à afficher.
  • Tables Bookmarklet (Paul J. Adam) : pour une vue d’ensemble rapide et regroupée des éléments de structure des tableaux simples et complexes. Facilite notamment la détection visuelle des entêtes, cellules, légende et résumé, identifiants, etc. Peut signaler certains problèmes d’associations d’identifiants dans les tableaux complexes.
  • À combiner pour l’évaluation du critère 2.5.8 – Taille de la cible (minimum) (WCAG 2.2) :
    • Le Target Size Highlighter met en évidence le contour de la cible des éléments interactifs.
    • Le 24px Cursor Bookmarklet (A. Roselli) fournit un curseur de référence pour évaluer la taille des cibles ainsi que les exceptions liées aux espacements entre les cibles. Pour l’employer correctement, le zoom du navigateur doit être à 100 %.
    • Note : certains tests automatisés commencent à voir le jour pour ce critère, mais donnent des résultats mitigés. Des vérifications manuelles demeurent plus sûres, à ce jour.

Application

  • Colour Contrast Analyser (CCA) (Windows, Mac) : Cet analyseur de contraste des couleurs nécessite une intervention manuelle pour désigner les couleurs d’avant-plan et d’arrière-plan (outil Pipette ou saisie du code de couleur). Il demeure un complément indispensable aux analyses automatiques des contrastes effectuées par des outils comme WAVE ou Axe DevTools. En effet, le CCA est le seul outil permettant d’évaluer le contraste du texte apparaissant sur une image. Il est également nécessaire pour tester le contraste des éléments non textuels d’interface (critère 1.4.11, depuis WCAG 2.1), ou pour toute autre analyse des contrastes passant sous le radar des outils automatisés.

Extensions de navigateur

  • Web Developer Toolbar (Chrome, Firefox et Opera) : Facilite l’inspection manuelle du code source, notamment par l’affichage d’informations en surcouche de la page (structure, métadonnées, etc.). Elle propose aussi des options de rendu (désactivation des styles, linéarisation de la page, etc.) et d’analyse du code source.
  • NerdeRegion (Chrome) : Cette extension enregistre toutes les sorties d’information des régions aria-live, depuis les outils de développement du navigateur. Elle peut ainsi contribuer à identifier l’origine technique de certains problèmes d’annonces aria-live constatés lors de tests fonctionnels avec des lecteurs d’écran.
  • Accessibility Insights for Web (Chrome et Edge) : Cette extension regroupe plusieurs fonctionnalités, dont les outils Ad hoc. Il s’agit d’options activables à la demande, en surcouche de la page, pour faciliter des tests manuels. Par exemple, l’affichage de l’ordre de tabulation, ou encore, l’identification des niveaux de titres. Cette dernière fonctionnalité est souvent appréciée par les personnes rédigeant des contenus Web. Elle permet de vérifier rapidement l’emploi des niveaux de titres, sans s’encombrer d’une multitude de rétroactions fournies par d’autres outils.

Inspecteur d’accessibilité des navigateurs

Chrome, Edge et Firefox intègrent par défaut un inspecteur d’accessibilité dans leurs outils de développement.

  • Pour accéder à l’inspecteur sur Firefox : panneau Accessibilité des outils de développement (Maj+F12).
  • Pour Chrome et Edge : se rendre dans les outils de développement (touche F12 ou Commande+Maj+C), puis choisir le panneau Éléments et le sous-panneau Accessibilité.

L’inspecteur d’accessibilité facilite la détection de certains enjeux et l’identification de leur origine, grâce à la visualisation de l’arbre d’accessibilité et à l’inspection des propriétés d’un élément. Il est aussi utile en complément d’autres outils déjà présentés, tels que certains bookmarklets, dont les rétroactions parfois abondantes peuvent devenir difficiles à lire. Exemples d’informations fournies par l’inspecteur :

  • nom accessible et informations prises en compte dans ce calcul (critère 2.5.3 – Étiquette dans le nom) (depuis WCAG 2.1);
  • élément focusable ou non;
  • élément exposé ou non à l’API d’accessibilité, ainsi que les rôles, propriétés et valeurs;
  • calcul automatique du contraste de couleur (pour un élément textuel), etc.

Les outils de développement comportent quelques outils additionnels, comme la simulation de différentes formes de daltonisme (dans le panneau Accessibilité de Firefox, ou le panneau Rendu de Chrome).

Outils d’évaluation en amont du codage (linters)

Les linters s’emploient durant la rédaction du code source (HTML, CSS, JavaScript, etc.). Ils analysent ce code pour y repérer des erreurs, des incohérences ou des pratiques non recommandées. Le principal avantage de tels outils est d’intercepter automatiquement certains problèmes dès la saisie du code. Il est alors possible d’intervenir très tôt dans le processus de développement.

Exemples d’analyseurs de code gratuits pour l’accessibilité :

  • Axe Linter se base sur la bibliothèque axe-core. Cet outil analyse les fichiers HTML, Angular, React, Vue, React Native et Markdown. Il est offert comme extension pour l’éditeur de code Visual Studio.
  • ESLint est un analyseur généraliste de code JavaScript qui peut accueillir certaines intégrations spécifiques pour l’accessibilité. Par exemple, un plugiciel ESLint pour les éléments JSX (eslint-plugin-jsx-a11y).

Outils de tests automatisés en ligne de commande (CLI)

Pour les équipes de conception-programmation Web ainsi que les équipes d’assurance qualité, les outils de tests automatisés en ligne de commande (CLI) comportent plusieurs avantages :

  • À la différence des extensions Web, ils permettent de déployer des tests sans passer par une interface de navigateur traditionnelle, ce qui confère plus de flexibilité et de facilité d’automatisation.
  • Les outils CLI peuvent être incorporés à des scripts ou à des environnements de tests et de développement existants. Ils sont tout indiqués dans des processus d’intégration et de développement continus (CI/CD).
  • Les outils CLI tendent à offrir plus de flexibilité pour la configuration et la personnalisation des règles d’accessibilité. Cela permet d’adapter les tests d’accessibilité à des besoins spécifiques.
  • Enfin, certains outils en ligne de commande – mais pas tous – peuvent s’employer pour des évaluations à plus large échelle, conduites sur un grand nombre de pages à la fois.

À titre indicatif, voici deux exemples d’outils CLI gratuits et réputés, adaptés à une variété d’environnements ou de flux de travaux :

  • Axe-cli : Basé sur axe-core, cet outil est conçu pour des tests ciblés sur un petit nombre de pages à la fois. Ainsi, pour planifier et automatiser des tests d’accessibilité sur de vastes sections d’un site web, une intégration d’axe-core avec Selenium Webdriver (@axe-core/webdriverjs) est davantage recommandée.
  • Pa11y : Utilise l’analyseur d’accessibilité de HTML CodeSniffer, qui peut être combiné à axe-core pour une plus grande couverture d’analyse automatique.

Il existe par ailleurs des outils CLI conçus pour des cadriciels ou des environnements de développement et de tests spécifiques. Exemples utilisant axe-core : cypress-axe, axe-puppeteerreact-axe, etc.

Enfin, mentionnons que les extensions de navigateur comme WAVE ou Axe DevTools conservent leur utilité, même pour les équipes ayant recours aux tests automatisés en ligne de commande. De fait, les interfaces graphiques des extensions peuvent s’avérer plus intuitives pour certaines parties prenantes du projet, qui copartagent la responsabilité de l’accessibilité numérique. Par ailleurs, les extensions permettent de tester les pages Web en temps réel, durant la navigation, et fournissent des informations visuelles ou contextuelles qui peuvent manquer dans les outils CLI.

Exemples d’outils d’évaluation pour les documents électroniques

Exemples d’outils d’évaluation pour les applications mobiles

  • Xcode, d’Apple, fournit un inspecteur d’accessibilité ainsi que certains tests automatisés. L’appareil mobile contenant l’application à tester doit au préalable être branché sur un ordinateur Mac.
  • Google Accessibility Scanner s’exécute directement sur l’appareil mobile de test, pour détecter automatiquement certains types de problèmes d’accessibilité dans une application.
  • Diverses applications existent sur le marché pour partager l’écran d’un appareil mobile vers un ordinateur. Il devient alors possible d’utiliser certains outils comme le Colour Contrast Analyser, précédemment cité.