L'autonomie, voilà l'essentiel. Nous souhaitons que les développeurs soient les moteurs de la mise en œuvre de bonnes pratiques en matière d'accessibilité au sein des grandes entreprises, et c'est en partie ce qui nous a poussés à créer la gamme d'outils de développement web WorldSpace Attest. Nous voulions donner aux développeurs les moyens d'être autonomes.
S'appuyant sur notre moteur de règles très apprécié «axe-core », Attest propose divers outils d'intégration pour Node.js, Selenium WebDriver, Ruby, le JavaScript des navigateurs et bien d'autres encore, permettant ainsi aux développeurs de choisir la solution qui leur convient le mieux. Grâce à des fonctionnalités simples de création de rapports et d'exportation de données, ainsi qu'à une extension de navigateur très pratique, plusieurs membres d'une même équipe peuvent collaborer au développement de l'accessibilité et obtenir des résultats de test cohérents à l'échelle de l'entreprise.
Dans cet article, je vais vous montrer comment les composants Attest permettent de placer les tests d'accessibilité au cœur des préoccupations de l'équipe dès les premières étapes du cycle de vie du développement logiciel, ce qui rend cette démarche durable et pragmatique.
Pourquoi choisir WorldSpace Attest ?
Les audits manuels réalisés par des experts en la matière constituent un élément essentiel de la mise en conformité en matière d'accessibilité pour les entreprises : les connaissances de ces spécialistes peuvent servir à établir une feuille de route pour la correction des bogues, à l'intention des équipes de développement et d'assurance qualité.
Cependant, 40 % des problèmes d’accessibilité peuvent être résolus à l’aide d’outils automatisés avant même qu’un testeur manuel ne les repère, ce qui permet de réduire considérablement la charge de travail liée au signalement, au suivi, au tri et à la validation de ces problèmes. Nous espérons qu’avec le temps, les développeurs pourront tirer parti des outils automatisés pour détecter eux-mêmes les bugs d’accessibilité les plus évidents, libérant ainsi les experts en la matière pour qu’ils se consacrent à des tâches plus complexes nécessitant une intervention humaine.
Cela me rappelle ce vieil adage : « Donne un poisson à un homme, tu le nourris pour un jour ; apprends-lui à pêcher, tu le nourris pour toute une vie. » En intégrant pleinement l’accessibilité au processus de développement logiciel et en en assurant la gestion en interne (à l’aide de quelques outils), les organisations peuvent identifier leurs propres problèmes beaucoup plus rapidement et obtenir des résultats cohérents avec le personnel dont elles disposent déjà.
WorldSpace Attest se distingue de nos outils open source plus basiques par le nombre de ses intégrations sophistiquées et la prise en charge de règles personnalisées, sans oublier l’accompagnement technique fourni par l’équipe Deque . Il combine le meilleur des deux mondes : des API de test automatisées qui concentrent des années d’expertise en matière d’accessibilité, ainsi qu’un accompagnement sur mesure de la part de l’équipe qui les a développées. Pour les grandes entreprises, Attest peut aider votre équipe à se lancer et à obtenir des résultats durables en matière d’accessibilité en un rien de temps.
Flux de travail des développeurs
Attest est un excellent outil permettant d’automatiser les tests d’accessibilité à l’aide de règles personnalisées, très courantes dans les grandes entreprises. Pour vous montrer comment cela fonctionne, je vais vous présenter un workflow type de tests d’intégration front-end, en mettant particulièrement l’accent sur la prise en charge optimale des règles personnalisées par Attest. Je vais vous montrer ces mêmes règles personnalisées en action dans l’extension de navigateur Attest (anciennement FireEyes II), disponible avec une licence WorldSpace Attest ou WorldSpace Comply. Disposer de plusieurs outils utilisant le même ensemble de règles sous-jacent vous permet de tester une norme d’accessibilité personnalisée manuellement ou dans un environnement automatisé, ce qui harmonise les normes entre plusieurs disciplines.
Il convient de noter que les tests automatisés détectent environ 30 % des problèmes liés aux critères de réussite (en fonction de votre ensemble de règles) et 50 % du nombre total de problèmes ; ils ne rendent donc pas les tests manuels superflus. Mais ces 30 à 50 % peuvent représenter un progrès considérable pour un effort minimal. Les tests automatisés permettent également d’empêcher par programmation que des régressions en matière d’accessibilité ne se glissent dans l’environnement de production, ce qui constitue un avantage considérable pour les déploiements à haut risque et les grandes équipes.
Étape 1 : Se procurer les outils
Les modules WorldSpace Attest sont hébergés chez un fournisseur tiers npm registre géré par Artifactory – notre instance s'appelle Agora. Une fois la licence WorldSpace Attest acquise, un administrateur d'Deque accordera l'accès à votre équipe. Vous pourrez alors activer l'authentification via un .npmrc fichier qui permettra d'effectuer des installations en ligne de commande sur votre ordinateur.
Étape 2 : Installer les dépendances
Avec des identifiants Agora valides et .npmrc Une fois ces informations renseignées, vous pouvez installer Attest-Node et Attest-Webdriverjs dans votre projet. Si vous ne disposez pas encore de dépendances npm, vous pouvez initialiser votre projet avec npm init.
Installez Attest-Node et Attest-Webdriverjs à partir du registre :
npm install -g attest-node npm install attest-webdriverjs
Attest-Node est particulièrement utile lorsqu'il est installé au niveau global, mais cette étape est facultative.
Vous devrez également installer quelques dépendances pour les tests, notamment Selenium WebDriver, Mocha et Chai :
npm install selenium-webdriver mocha chai --save-dev
Étape 3 : Ajouter une règle personnalisée
Règles personnalisées dans WorldSpace Attest
Les règles personnalisées dans Attest respectent le même format JSON que celui utilisé dans le projet open source axe-core . La structure nécessite un tableau « rules » contenant des objets qui correspondent aux nœuds DOM pertinents et décrivent le fonctionnement de la règle, ainsi qu’un tableau « checks » contenant des objets représentant des sous-tests permettant d’évaluer certaines parties d’une règle. Le fait que les règles et les contrôles soient organisés en structures distinctes permet d’utiliser les sous-tests dans plusieurs règles.
À titre d'exemple, je vais utiliser un fichier JSON contenant une règle personnalisée qui signale <p> éléments utilisés comme titres. Pour l'installer, deux options s'offrent à nous :
- Ajoutez une entrée pour
$ATTEST_PATHdans.bash_profilequi pointe vers un.jsonconfiguration des règles. (Redémarrez votre client en ligne de commande pour que cette méthode prenne effet.) - Mettez un
attest.jsonfichier de configuration des règles situé à la racine du projet.
La première option est idéale pour utiliser la même configuration de règles dans plusieurs projets, tandis que la seconde permet de se lancer plus rapidement. Attest-Node et Attest-webdriver fonctionneront conjointement pour configurer la règle personnalisée et la rendre disponible de manière transparente pour nos tests d'intégration. Dès lors que la règle personnalisée détecte un nœud présentant une violation d'accessibilité pertinente, celui-ci apparaîtra dans nos résultats d'audit.
Règles personnalisées dans WorldSpace Attest DevTools
Pour analyser des pages à l'aide de la règle personnalisée dans l'extension pour développeurs WorldSpace Attest (anciennement FireEyes II), deux options s'offrent à vous :
- Utilisez WorldSpace Comply pour diffuser la règle depuis le serveur.
- Activer un onglet « Règles personnalisées » dans les préférences de l'extension afin de pouvoir coller le contenu des règles au format JSON et, si vous le souhaitez, le télécharger vers WorldSpace Comply.
Pour activer une règle personnalisée depuis l'ancienne extension FireEyes II pour Firefox, rendez-vous sur about://addons et activez l’option « Autoriser les règles personnalisées » dans les préférences de l’extension FireEyes. Vous pourrez alors coller le contenu du fichier JSON de la règle personnalisée dans l’interface utilisateur de l’extension. Pour plus d’informations, consultez la Documentation relative à FireEyes II sur le site de l'université « Deque » (connexion requise).
Une fois la règle personnalisée activée, le lancement d'une analyse dans le navigateur donnera les mêmes résultats que notre test d'intégration :
Étape 4 : Rédiger un test d'intégration
Les tests d'intégration dans Attest-webdriverjs sont similaires à ceux de notre module open source axe-webdriverjs, à la différence près qu'Attest est le seul à intégrer une fonctionnalité de génération de rapports, très utile pour partager les résultats des tests avec les équipes. Attest facilite également la gestion des règles personnalisées dans plusieurs projets, grâce à la possibilité de les stocker dans un fichier unique référencé via une variable d'environnement PATH. Si votre ensemble de règles personnalisées doit être modifié, vous pouvez mettre à jour cette source unique de référence sur votre machine de développement, plutôt que de reconfigurer chaque projet concerné.
Voici un exemple de test JavaScript qui charge les dépendances, configure WebDriver pour qu'il s'exécute dans Google Chrome et vérifie qu'il n'y a aucune violation des règles d'accessibilité pour une page « localhost » donnée :
const WebDriver = require('selenium-webdriver'),
AttestBuilder = require('attest-webdriverjs'),
attest = require('attest-node')();
const assert = require('assert');
var util = require('util');
describe('Attest demo', function() {
this.timeout(10000);
let driver;
let serverUrl = 'localhost:3000',
dqReporter = attest.report(serverUrl, './a11y-results');
beforeEach(function(done) {
driver = new WebDriver.Builder()
.forBrowser('chrome')
.build();
done();
});
afterEach(function(done) {
driver.quit().then(function() {
done();
});
});
it('should find no accessibility violations', function(done) {
driver
.get(serverUrl)
.then(function () {
new AttestBuilder(driver)
.analyze(function (results) {
dqReporter.logTestResult('about', results);
assert.equal(results.violations.length, 0);
done();
});
});
});
});
Étape 5 : Corrigez les éventuels défauts
Les résultats au format JSON enregistrés à l'aide de dqReporter peuvent être convertis en un rapport lisible par l'utilisateur, à l'aide de l'interface de ligne de commande attest-report d'Attest-Node :
$ attest-report ./a11y-results --dest ./a11y-reports --format html+junit
Cette commande génère des rapports HTML et JUnit dans un nouveau répertoire nommé « a11y-reports ». En ouvrant la version HTML dans un navigateur, on peut consulter les résultats sous une forme clairement présentée, plutôt que de devoir éplucher du JSON brut :
Grâce à ces informations, les développeurs peuvent identifier le ou les éléments à l'origine de la non-conformité et mettre en œuvre des corrections de manière itérative. Les résultats peuvent également être communiqués à l'équipe de développement à des fins de suivi. Dans le cas de notre test « p-as-heading », il suffit de remplacer le paragraphe non conforme par un titre de niveau h1 à h6 pour que le test soit réussi.
Demander une démonstration
Grâce à WorldSpace Attest, les équipes de développement peuvent prendre en main leurs propres tests d’accessibilité plutôt que d’attendre les retours du service d’assurance qualité ou d’une équipe d’évaluation tierce. Le fait de disposer d’une gamme d’outils adaptés aux différents membres de l’équipe permet de favoriser la collaboration et d’éviter que la responsabilité ne repose sur une seule personne. Au final, cela signifie que vous créez un environnement dans lequel l’accessibilité peut évoluer au même rythme que votre organisation.
Pour en savoir plus sur WorldSpace Attest, n'hésitez pas à nous contacter afin d'assister à une démonstration pratique.
