De nombreux outils automatisés sont disponibles pour tester les problèmes d'accessibilité. Avant de plonger dans le vif du sujet, clarifions une chose : les tests automatisés ne peuvent détecter de manière fiable que 30 à 40 % de tous les problèmes d'accessibilité .
Les outils automatisés ne sont pas en mesure de déterminer à quoi un composant est réellement destiné. Il ne peut pas remplacer un humain testant une interface pour des problèmes d'accessibilité et de convivialité. Il est conseillé de toujours tester manuellement avec la technologie d'assistance et d'effectuer des sessions de test d'utilisabilité avec des personnes qui utilisent et dépendent de la technologie d'assistance.
Outils de tests automatisés
Voici des outils courants avec lesquels tester. Ceux-ci peuvent être installés en tant qu'extensions de navigateur et exécutés sur n'importe quel site sur lequel vous travaillez. Exécutez souvent pour identifier les problèmes de "fruits à portée de main".
- Phare de Google
- aXe par Deque
- WAVE par WebAIM
- Informations sur l'accessibilité par Microsoft
Assurez-vous d'exécuter plus d'un outil, car certains fournissent des commentaires plus détaillés et précis que d'autres.
Tests d'utilisation
Les tests d'utilisabilité doivent être effectués après le développement d'un composant, mais avant son lancement auprès du grand public. De cette façon, les commentaires seront reçus et du temps sera disponible pour corriger tout problème d'utilisation.
Les services recommandés incluent :
Tests unitaires
Il est très possible d'écrire des tests unitaires pour tester votre code pour les problèmes d'accessibilité. C'est un autre excellent moyen d'attraper ces "gains faciles" et d'empêcher les régressions de se produire lors de la mise en production du code.
Le framework de test le plus populaire est la bibliothèque aXe -core de Deque. Il est intégré à Lighthouse pour Google Chrome, Sonarwhal par l'équipe Edge de Microsoft, Ember A11y Testing, et plus encore.
Par exemple, voici un test exécutant l'ensemble complet de règles sur un document dans un test d'intégration au niveau de la page :
var axe = require('axe-core'); describe('Some component', function() { it('should have no accessibility violations', function(done) { axe.run('.some-component', {}, function(error, results) { if (error) return error; expect(results.violations.length).toBe(0); }); }); });L'exécution des tests entraîne le renvoi d'un objet JSON avec tout ce qui a été trouvé : des tableaux de réussites, de violations et même un ensemble d'éléments "incomplets" qui nécessitent une révision manuelle. Vous pouvez écrire des assertions basées sur le nombre de violations, utiles pour débloquer les builds localement ou en intégration continue (CI).
Découvrez cet exemple d' utilisation de ax avec le framework de test unitaire Jasmine par Marcy Sutton.
Environnements CI
L'exécution de tests dans votre environnement CI est une autre méthode de prévention des régressions et peut être considérée comme une "dernière ligne de défense". Ces tests s'exécutent automatiquement lorsqu'un changement de code d'une pull request est sur le point d'être fusionné avec la branche master.
Un outil que vous pouvez utiliser pour ce type de test est pa11y-ci qui exécute des tests d'accessibilité sur plusieurs URL et signale des problèmes.