Dans ce tutoriel, nous allons mettre en place des tests d'accessibilité automatisés pour un projet JavaScript à l'aide de axe-webdriverjs, un module Node.js permettant de créer axe-core facile à utiliser avec Selenium WebDriver. Ce tutoriel utilise le Cadre de test Jasmine– qui pourrait être remplacé par Mocha ou une autre solution de test –, mais qui, pour le reste, est indépendant de tout framework et peut être intégré à n'importe quel projet.
Pourquoi recourir aux tests d'accessibilité automatisés ?
Les tests automatisés permettent de réduire de 30 % l'effort consacré aux tests manuels, ce qui en fait un outil précieux pour le développement logiciel. En créant un script de navigateur permettant d'ouvrir des pages Web et d'effectuer des tâches utilisateur de manière programmatique, vous pouvez valider des fonctionnalités sans avoir à ouvrir chaque page vous-même. En intégrant axe-core à vos tests, vous pouvez étendre la couverture en matière d'accessibilité sans avoir à devenir un expert. De plus, vous pouvez évaluer la prise en charge de l'accessibilité et détecter les régressions dans vos versions, empêchant ainsi le code défectueux d'être déployé en production.
Configuration requise et installation
Pour commencer, consultez la démo de ce tutoriel depuis GitHub. Vous aurez besoin de Node.js et npm (gestionnaire de paquets Node) doit être installé. Selenium WebDriver permet de tester plusieurs navigateurs, notamment Firefox, Chrome, Safari, Edge et Opera. Cette démo utilise Chrome ; pour cela, vous aurez besoin de ChromeDriver installé quelque part sur votre $PATH. [Comment installer Chromedriver sous OS X]
La mise en place d'un projet de test avec axe-webdriverjs est très simple grâce à npm. Notre démo comporte quelques dépendances : package.json fichier, comprenant notamment Selenium WebDriver, Jasmine et axe-webdriverjs, que nous pouvons installer très facilement à l'aide de npm install. Ces modules, associés au module « axe-core » (installé automatiquement), nous fournissent tout ce dont nous avons besoin pour écrire des tests d'intégration au navigateur en matière d'accessibilité.
Pour résumer, vous aurez besoin de :
- Git
- Node.js
- npm
- Chrome
- ChromeDriver
Démonstration sur GitHub : https://github.com/marcysutton/axe-webdriverjs-demo
Installer les dépendances :
npm install
Et voilà, la configuration est terminée !
[embedyt] https://www.youtube.com/watch?v=1QAvRJM-zR8[/embedyt]
Utilisation des tests
Pour tester une page Web par programmation, vous pouvez diriger Selenium WebDriver vers une URL, fournir les détails de configuration nécessaires et vérifier qu'elle ne présente aucune erreur d'accessibilité dans cet état. Si votre environnement dispose déjà de tests d'intégration, il est facile de travailler avec aXe puisque vous disposez déjà d'une infrastructure permettant de charger des URL et de créer des scénarios utilisateur par script.
Voici un exemple de test d'une page hébergée sur un serveur web local :
var selenium = require('selenium-webdriver'),
AxeBuilder = require('axe-webdriverjs');
describe('Accessibility', function() {
var driver;
beforeEach(function(done) {
driver = new selenium.Builder()
.forBrowser('chrome')
.build();
driver.get('http://localhost:4000/')
.then(function () {
done();
});
});
// Close website after each test is run (so it is opened fresh each time)
afterEach(function(done) {
driver.quit().then(function () {
done();
});
});
it('should change state with the keyboard', function() {
var selector = 'span[role="radio"][aria-labelledby="radiogroup-0-label-0"]';
driver.findElement(selenium.By.css(selector))
.then(function (element) {
element.sendKeys(Key.SPACE);
return element;
})
.then(function (element) {
return element.getAttribute('aria-checked')
})
.then(function (attr) {
expect(attr).toEqual('true');
});
});
it('should analyze the page with aXe', function (done) {
AxeBuilder(driver)
.analyze(function(results) {
console.log('Accessibility Violations: ', results.violations.length);
if (results.violations.length > 0) {
console.log(results.violations);
}
expect(results.violations.length).toBe(0);
done();
})
});
});
Dans le fichier de test ci-dessus, nous importons nos dépendances : selenium-webdriver et axe-webdriverjs, ce qui nous permet d'appeler les fonctions intégrées à ces bibliothèques. Un test d'intégration existant vérifie la prise en charge du clavier et d'ARIA par un bouton radio personnalisé. En utilisant la configuration WebDriver de ce test avec axe-webdriverjs, un deuxième test appelle AxeBuilder pour analyser la page à l'aide de axe-core. Une fois AxeBuilder Une fois que la fonction a renvoyé les résultats de l'audit via une promesse JavaScript, nous pouvons les afficher dans la console.
Tirer parti de la valeur d'aXe
L'intégration d'aXe dans un environnement de test plus vaste comptant de nombreux développeurs implique que vous devrez exploiter davantage les résultats : se contenter d'afficher « 2 devrait être égal à 0 » pour les violations d'accessibilité n'apportera pas grand-chose à un développeur qui a introduit des régressions sans s'en rendre compte. Il existe plusieurs options pour exploiter les données de résultats d’aXe au-delà des fonctionnalités de base : l’API WorldSpace Attest Reporting, qui s’intègre facilement à votre infrastructure de test existante ; ou encore, la création de votre propre fonctionnalité permettant d’enregistrer puis de générer des rapports sur ces résultats pour l’ensemble de la suite de tests une fois celle-ci terminée.
Un outil de rapport efficace devrait synthétiser les résultats des tests d'accessibilité et afficher les informations nécessaires pour diagnostiquer rapidement les défaillances, telles que le nom du test, le niveau d'impact et le balisage concerné. Un utilitaire permettant d'enregistrer l'objet des résultats pendant les tests pourrait également s'avérer utile, afin de fournir davantage d'informations aux développeurs tout en évitant de répéter du code standard dans chaque fichier de test.
Pièges à éviter
Temps morts
Si vous intégrez aXe dans des tests fonctionnels existants, vous attendez sans doute déjà que les pages se chargent et vérifiez l’apparition de composants d’interface utilisateur spécifiques avant de procéder aux assertions. Cependant, si vous ne disposez pas encore de ces mécanismes, vous risquez de rencontrer quelques difficultés. Tout d’abord, il existe des différences de temps significatives entre les URL locales et distantes : en l’absence de toute limitation du réseau visant à simuler la latence et les vitesses de téléchargement réelles, les URL exécutées localement renverront des résultats bien plus rapidement que celles distantes. Si vous essayez de tester des URL distantes (c’est-à-dire https://www.deque.com, par rapport à http://localhost:4000, qui ne fonctionnerait que sur votre machine), vous verrez apparaître des erreurs de délai d'expiration à tout va. Heureusement, il est possible de résoudre ce problème en augmentant les délais d'expiration de Jasmine et de Webdriver.
Pour augmenter le délai d'expiration par défaut de Jasmine, modifiez cette valeur à n'importe quel endroit de votre fichier de test :
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000 ;
Une fois que vous avez instancié Selenium WebDriver, vous pouvez également augmenter la durée maximale d'exécution de ses scripts :
browser.manage().timeouts().setScriptTimeout(60000);
Promesses
Un autre piège majeur lors de l'utilisation de WebdriverJS est la question des commandes asynchrones dans un environnement synchrone. Pour y faire face, vous devez maîtriser l'utilisation des « Promises » en JavaScript. Chaque commande prend un certain temps à s'exécuter et vous devez attendre la confirmation avant de pouvoir exploiter les données renvoyées. Vous apprendrez à apprécier l'instruction `return` pour maintenir la fluidité de votre flux continu de données. Pour en savoir plus sur l'utilisation des Promises dans WebdriverJS, consultez mon article de blog consacré à l'écriture de plugins Protractor.
Conclusion
Il est évident que les tests automatisés apportent une réelle valeur ajoutée au développement logiciel. En utilisant des outils tels que axe-core, vous pouvez réaliser une grande partie de vos tests d’accessibilité sans avoir recours à des tests manuels. Vous pouvez commencer à tester des éléments tels que le contraste des couleurs, les libellés des formulaires ou l’utilisation d’ARIA sans avoir à devenir un expert en algorithmes de mise en œuvre. De plus, si le niveau d’accessibilité de votre application venait à se dégrader, vous le sauriez immédiatement, car vous aurez déjà établi une référence du niveau actuel d’accessibilité.
Le prestataire de cours en ligne edX a pu réduire considérablement ses tests d'accessibilité manuels en intégrant aXe à son infrastructure de tests. Selon Mark Sadecki :
« Étant donné que axe-core est conçu pour éliminer les faux positifs, edX peut utiliser en toute confiance cet ensemble de règles dans son cadre de tests d'acceptation, ce qui permet d'écarter de notre environnement de production certaines des défaillances d'accessibilité les plus flagrantes. »
Laissez les tests automatisés identifier les points les plus faciles à améliorer en matière d'accessibilité logicielle dans votre projet et faites un grand pas en avant vers l'égalité numérique !
