L'équipe Labs d'Deque s a travaillé d'arrache-pied sur plusieurs mises à jour de la bibliothèque de tests JavaScript «aXe-Core » en vue de la version 3.0. Ces mises à jour incluent notamment la prise en charge du Shadow DOM et des composants Web, l'amélioration des performances, ainsi que de nouvelles règles : il s'agit à la fois de règles expérimentales et de bonnes pratiques. D'autres nouveautés sont prévues après la version 3.0.
Pour vous permettre d’être prêt à vous lancer sans attendre avec aXe 3.0, nous allons examiner le fonctionnement de ces modifications apportées aux API, leur impact sur nos extensions de navigateur et autres intégrations, ainsi que sur notre gamme de produits Attest. Vous saurez ainsi ce que propose aXe 3.0, comment vous lancer sans attendre et disposer d’une suite d’outils de test d’accessibilité encore plus performante. C’est parti !
Axe 3.0 et Shadow DOM
Pour présenter les nouveautés d'aXe 3.0, il faut d'abord évoquer celles de la bibliothèque JavaScript « aXe-Core ». Il s'agit du code JavaScript sous-jacent qui alimente nos extensions de navigateur et nos API de test d'accessibilité.
Dans la version 3.0 d’ aXe-Core , le changement le plus important réside dans la prise en charge du Shadow DOM. Ce nom peut sembler un peu effrayant, mais il s’agit en réalité d’une norme faisant partie des spécifications des composants Web, qui permet d’encapsuler des parties de pages Web. On peut considérer les composants Web comme les plugins jQuery de demain, et le Shadow DOM est la partie de ces composants qui empêche vos styles et vos scripts de « fuir » vers l’intérieur ou vers l’extérieur.
Exemple : « aXe-core » 3.0 dans le Shadow DOM
Pour vous montrer comment cela fonctionne concrètement, j'ai créé cette petite application de démonstration permettant d'organiser un séjour au ski avec React JS, et je vais simplement l'examiner pour voir ce qui se passe dans l'inspecteur DOM de Chrome.
Si je zoome un peu, vous pouvez voir que ce composant de planificateur d'itinéraire comporte une encapsulation interne avec une racine d'ombre ouverte. Une racine d'ombre ouverte – par opposition à une racine d'ombre fermée – encapsule ces pages tout en permettant à des outils tels que aXe-Core d'y accéder. Il existe donc certains problèmes d'accessibilité connus dans ce composant que nous devrions pouvoir détecter grâce à aXe-Core 3.0.
Extension aXe-Coconut et Shadow DOM
Pour vous montrer comment cela fonctionne, je vais ouvrir notre extension « aXe-Coconut » en préversion, qui constituait jusqu’à présent le moyen de tester l’ aXe-Core e 3.0 dans cet environnement de préversion. À terme, ces modifications seront intégrées à nos extensions stables « axe DevTools » pour Chrome et Firefox, ce qui vous permettra de tester le Shadow DOM à l’aide de l’extension standard.
Mais pour l’instant, nous pouvons examiner cela dans aXe-Coconut et constater qu’il pénètre bel et bien dans le Shadow DOM ; il a détecté qu’il nous manquait certaines étiquettes de formulaire et a même relevé des problèmes de contraste des couleurs au sein de cette racine Shadow. Depuis aXe-Coconut, je peux inspecter le nœud et constater que, effectivement, aXe-Core a détecté ce problème au sein de notre racine Shadow ouverte. aXe ne sautera plus ces régions entières de pages si vous utilisez effectivement le Shadow DOM ouvert.
Signaler des bogues dans Axe-Coconut
Une autre fonctionnalité sympa que je tiens à souligner dans la nouvelle extension aXe-Coconut, c'est ce petit bouton de signalement de bug. Ce bouton vous permet de signaler un problème lié à une règle expérimentale ou au Shadow DOM directement depuis l'extension de navigateur.
Contrairement à notre extension Chrome habituelle, qui ne dispose pas de ce bouton de signalement de bug, aXe-Coconut a pour but de vous permettre de signaler les bugs dès leur apparition, avant que ces modifications ne soient déployées pour tous les utilisateurs. La prise en charge du Shadow DOM sera très bientôt disponible dans nos extensions aXe pour Chrome et Firefox ; elle est d’ailleurs déjà intégrée à la version 3.0 d’ aXe-Core .
Axe 3.0 dans votre suite de tests automatisés
Jusqu’à présent, nous nous sommes concentrés sur les extensions de navigateur et sur le processus plutôt manuel des tests d’accessibilité. Cependant, vous pouvez également utiliser aXe 3.0 dans votre suite de tests automatisés. Pour cela, passons à mon éditeur de texte, où j’ai rédigé quelques tests d’intégration pour notre petite application de démonstration, développée avec React.
Dans le fichier package.json, j’ai ajouté un script dédié à l’intégration. Il exécute le framework de test Mocha, puis notre fichier integration/a11y.js. J’utilise également une version spéciale d’aXe-WebdriverJS. Cela deviendra la norme dans notre version stable 2.0 d’aXe-WebdriverJS, mais jusqu’à présent, vous pouviez utiliser aXe 3.0 dans cette version 2.0.0-alpha.1. Cela deviendra très bientôt la norme, mais pour l’instant, je peux utiliser cette version alpha.1 avec l’outil aXe-WebdriverJS pour effectuer des tests automatisés au sein du Shadow DOM.
Dans notre fichier integration/a11y.js, j'utilise Selenium WebDriver et aXe-WebdriverJS pour lancer une instance de navigateur réelle et tester l'accessibilité depuis la ligne de commande. Je procède ici à quelques réglages, que j’ai déjà abordés dans d’autres vidéos ; je ne m’étendrai donc pas trop sur ce sujet pour l’instant, si ce n’est pour vous montrer ces tests concrets. Le premier test indique qu’il ne devrait détecter aucune non-conformité sur la page d’accueil ; il recherche un élément sur cette page, puis exécute cet axeBuilder.
Comment utiliser axeBuilder
Tout comme pour un test d’accessibilité classique, nous nous attendons à ce qu’il n’y ait aucune violation d’accessibilité. Ensuite, pour nous assurer que nous testons bien tous les différents aspects de cette application, celle-ci comporte une fenêtre modale ; nous allons donc l’ouvrir par programmation à l’aide de la touche Entrée, puis nous relançons axeBuilder pour vérifier qu’il n’y a pas de violations. J'ai toutefois délibérément intégré des violations d'accessibilité dans ce code ; nous devrions donc en voir plusieurs, et elles devraient ressembler à celles que nous avons observées dans aXe-Coconut.
Dans mon terminal, je vais faire npm run integration pour exécuter ce script npm. Cela va ouvrir une instance de navigateur en arrière-plan ; on peut voir qu’elle s’ouvre une fois pour chaque test, et si je fais défiler vers le haut, eh bien oui, malheureusement, il y a quelques problèmes d’accessibilité ici, mais c’était justement le but. Nous voulions voir comment aXe-WebdriverJS nous les signalerait.
Bon, dans cette application, je vais simplement faire défiler vers le haut jusqu’en haut de la page ; je constate qu’elle détecte effectivement les mêmes problèmes de balises que ceux que nous avions observés dans aXe-Coconut. Elle accède à ce planificateur d’itinéraire et nous signale que nous avons oublié certaines balises. C’est donc un problème que nous pourrions corriger. Nous pourrions détecter d’autres problèmes soit à l’aide des extensions de navigateur, soit dans nos tests automatisés, puis vous pourriez les corriger tous afin de vous assurer qu’il n’y a plus aucun problème d’accessibilité.
Résumé
Avec ce format, vous pourriez empêcher que des problèmes d’accessibilité ne soient déployés en production ou peut-être faire échouer une compilation avant même qu’elle ne soit validée dans une pull request. Le choix des outils que vous souhaitez utiliser dépend vraiment de la façon dont votre équipe souhaite travailler : préférez-vous les extensions de navigateur, les outils automatisés, ou une combinaison des deux ? C’est généralement ma façon de procéder. Mais avec aXe 3.0, vous pouvez véritablement moderniser votre workflow afin qu’il s’intègre au Shadow DOM et fonctionne aussi rapidement que possible. Nous travaillons actuellement sur de nombreux cas de figure particuliers ; si vous rencontrez des problèmes, qu’il s’agisse de faux positifs ou de faux négatifs, n’hésitez pas à nous en faire part, que ce soit sur GitHub ou sur Twitter. Nous serions ravis d’avoir votre avis. Merci beaucoup.
