Un framework complet d’accessibilité, ça envoie des « good vibes » !

Je travaille toujours dans un service qui fait de l’accessibilité chez Orange et je continue à expérimenter des nouvelles méthodes pour intégrer l’accessibilité et des outils pour accompagner les projets.

Mais cette année, voyons voir ce que peut apporter l’adoption d’un framework complet dans une stratégie globale d’amélioration de l’expérience utilisateur, de la qualité front et la mise en accessibilité. Un retour d’expérience de chez Orange avec de vrais morceaux de projets dedans !

Contexte

Pour diffuser au mieux notre message (« l’accessibilité, c’est bon mangez-en ! ») dans les dizaines de projets qui mensuellement sortent des esprits inventifs et souvent tordus de nos marketeux et designers, nous avions compris, il y a déjà 5 ans, qu’il fallait outiller le projet avec du code front prêt à consommer, pratique pour les chefs de projets, efficace pour les développeurs.

Nous avions donc développé, de novo à la mimine, des composants d’interface HTML, CSS, JS, chartés, accessibles et ergonomiques en libre utilisation. Bon… succès mitigé, difficile à intégrer dans les frameworks utilisés en interne et il fallait rajouter nos CSS et notre JS à la page.

Il fallait trouver autre chose de plus vendeur, plus facile à utiliser, finalement plus sexy pour prêcher la bonne parole !

Et hop, un framework basé sur Bootstrap : Boost !

Vu les retours et les attentes des projets, suite à une étude menée par notre équipe (— Eurêka ! —), la solution envisagée après âpres discussions est… Bootstrap.

Plusieurs raisons : mobile first, responsive, grosse activité de la communauté, très utilisé aussi chez Orange, prise en main aisée, facilement utilisable avec les frameworks, les CMS ou les interfaces backend utilisés en interne, pour n’en citer que quelques-uns.

Nous avons rajouté à Bootstrap le plug-in PayPal pour assurer un meilleur niveau d’accessibilité. Cependant pour satisfaire à nos attentes et celle de nos clients, les projets, nous avons dû développer une surcouche spécifique permettant :

• de résoudre tous les problèmes (peu nombreux mais bloquants) d’accessibilité
• d’optimiser l’ergonomie ou disons plutôt l’utilisabilité
• de respecter la charte, la « Brand Orange » (contraignante et difficile à maitriser)
• d’y inclure une dizaine de composants spécifiques Orange
• de proposer une dizaine de gabarits de page type (qui mettent en scène nos composants et les bonnes pratiques de développement front)
• et de la documentation sur la mise en œuvre.

C’est ainsi que naquit Boost (Bootstrap Open Orange Simplicity Toolkit. Je sais… rigolez, mais si vous avez mieux, on est preneur).

Ce framework s’inscrit dans une démarche Open Source (licence MIT, disponible sur GitHub) et de conception centrée utilisateur. Il est utilisable librement par tous en interne et en externe et s’enrichit régulièrement suite aux retours et suggestions des utilisateurs. Il s’adresse à tous les projets web ayant besoin d’interfaces chartées Orange.

Pour un projet, utiliser Boost est l’assurance d’enrichir l’expérience utilisateur, tout en garantissant une expérience client homogène, ergonomique, accessible, interopérable et adaptative (responsive web design).

Gros succès : en 4 mois (date de lancement de la première version stable), plus de 50 projets ont adopté Boost. Vu la forte demande pour ce type d’outil, nous avons rapidement proposé le framework Boost pour un environnement Angular. Le travail au niveau accessibilité fut encore plus conséquent mais ô combien nécessaire !

On rajoute une chaîne de test de qualité front

Le support aux projets dans l’utilisation de Boost nous a permis de jauger de la qualité front des pages produites. Et en particulier en termes d’accessibilité, eh bien… ce n’était pas brillant !

Dommage d’en arriver là en utilisant Boost, car même avec des composants unitaires d’interface propres, on peut arriver à faire une page sale.

Donc après réflexion et action, on va aider les projets dans l’amélioration progressive de leur code front, et aussi, tant qu’à faire, de leur accessibilité. Comment ? En leur fournissant un framework complet de tests de qualité de code front.

Intégration continue chez Orange

Chez Orange, la majorité des projets utilise une forge logicielle qui permet l’intégration continue. L’intégration continue, c’est une méthode pour :

• tester les modifications
• déceler rapidement et systématiquement les erreurs
• améliorer les performances et la qualité de code

C’est une méthode basée sur des outils :

• le code source partagé (avec Git, ici chez Orange)
• intégration rapide des modifications
• des tests d’intégration (avec Sonar)
• l’application est construite en continu

C’est aussi une méthode basée sur l’automatisation des tâches (avec Jenkins) :

• de tests (unitaires, fonctionnels, …)
• de compilation
• de build (la construction de l’application)

L’intégration continue va nous permettre de tester rapidement et fréquemment. C’est donc un socle intéressant pour commencer à mettre en place notre framework de test, mais pas suffisant.

Outillage supplémentaire que nous avons choisi

Sur le poste du développeur, nous voulions aussi pouvoir lancer nos tests pour corriger au plus tôt. Pour cela nous avons opté pour un environnement classique et éprouvé (Node.js et Grunt) qui nous permet de faire exécuter nos tâches Javascript de tests.

La chaîne complète de qualité web

Nous avons donc mis en place la chaîne de tests suivante.

Optimisation de la performance web :

• concaténation, minification, uglification, … (chez Orange, on a encore du IE8)

Qualité de code :

• Validation du HTML avec htmllint
• Validation des CSS avec csslint
• Validation JS avec jshint
• Tests spécifiques :
  • Validation de la syntaxe spécifique Bootstrap avec bootlint
  • Validation des LESS ou Sass avec lessLint ou scssLint

Tous ces linters permettent de valider la grammaire et la syntaxe des langages utilisés par Bootstrap. (Les critères à respecter sont déterminés par le projet en fonction du choix de développement et des contraintes techniques.) Et comme tout linter, on peut rajouter ses propres règles d’écriture au besoin. Par exemple, on peut restreindre au niveau des CSS (ou LESS ou Sass) l’utilisation de seules les couleurs de la charte.

Ces tests sont lancés en local sur le poste du développeur avant qu’il ne commit ses développements (on peut même bloquer le commit en fonction du nombre ou de la criticité des erreurs) ou lorsqu’il le juge nécessaire. Ces tests automatiques rassurent les développeurs (et les chefs de projet), permettent d’assurer un bon niveau et les font entrer dans un cercle vertueux d’amélioration progressive de la qualité de code front.

Mais jusque-là, rien de très avant-gardiste. Maintenant intégrons dans cette chaine l’accessibilité !

La cerise sur le gâteau : les tests automatiques d’accessibilité

En parallèle, nous avons investigué pour trouver un outil :

• open source (politique interne)
• complet en termes de nombre de test
• modulaire (paramétrable)
• intégrable (fonctionnant sur les machines des développeurs d’Orange et avec de nombreux frameworks de tests)
• contextuel (l’ensemble de tests dépend du contexte à tester : la page ou une fraction de celle-ci)
• extensible (on peut y ajouter des règles facilement)

Les candidats repérés furent : a11y, AATT, accessLint, ariaLinter, grunt-accessibility, aXe-core, Pa11y, Quail, Tota11y.

Le vainqueur fût aXe de Deque, car il répondait le mieux à nos exigences. De plus, le manifeste d’aXe assure que les règles des tests :

• ne génèrent aucun faux positif
• sont légères et s’exécutent rapidement
• sont interopérables dans les navigateurs modernes
• sont elles-mêmes testables automatiquement (tests unitaires)

Axe fonctionne dans l’environnement local Node.js et Grunt des développeurs, mais peut être également déployé sur nos serveurs d’intégration basés sur Jenkins.

Sur le serveur Jenkins, on peut lancer notre tâche de qualité front, mais aussi la tâche d’accessibilité aXe. L’avantage réside dans une double validation locale sur le poste du développeur et, avec des critères de tests plus drastiques, sur le serveur d’intégration (pour plus de qualité, on est plus près de l’appli finale).

Pour utiliser aXe avec Jenkins, il fallait être capable de récupérer les résultats issus des tests.

Pour cela, nous avons créé un convertisseur aXe (résultat en JSON) vers un format JUnit, afin d’afficher les résultats des tests aXe lancés lors d’une tâche de build dans un dashboard Jenkins, en incluant le code source de la page testée avec une mise en avant et explication de l’erreur identifiée. Les pages sont testées au travers d’un navigateur headless PhantomJS en injectant le moteur de test axe-core. Ceci permet au chef de projet ou au lead developer de superviser l’amélioration au cours du temps, en ayant une vue haut niveau, et aux développeurs ou testeurs d’identifier page à page les erreurs une à une et donc de pouvoir les corriger.

Pour l’instant, cette partie de connecteur aXe avec Jenkins est juste une preuve de faisabilité. Il reste du travail mais ça fonctionne ! Nous allons l’améliorer prochainement et le mettre en open source, lui aussi sur Github.

Et avec tout ça, on a quels avantages ?

Il faut toujours avoir en mémoire que les tests automatiques d’accessibilité couvrent au maximum environ 30% des critères d’accessibilité. Par conséquent, ils ne peuvent suffire à rendre accessible une application. On a toujours besoin d’une validation humaine.

Mais ces 30 % des critères représentent en moyenne 60 % des erreurs d’accessibilité, et en général des erreurs bloquantes (pas d’alternative sur les images, pas de titres, …). De plus, avec les RIA (Rich Internet Applications), le code front (HTML, CSS) est de plus en plus construit par JavaScript (et donc suite à l’interprétation du navigateur). C’est du code généré : il faut alors valider ce code et non le code statique de la page.

Les tests basés sur aXe webdriver ou ceux via PhantomJS et aXe-core que nous avons mis en place permettent justement d’auditer du code généré, tout en mettant nativement en œuvre un grand nombre de critères automatiques (c’est un des outils les plus efficaces que je connaisse !).

En fait, pourquoi je vous raconte tout ça ? Pour que vous puissiez vous inspirer de cette démarche et gagner du temps. Car il nous en a fallu, du temps. Ce fut une longue marche pour arriver à ce niveau de maturation tout en sachant bien qu’il nous reste du chemin à parcourir.

Dès le début de notre démarche, nous avons mis en place de la conception centrée utilisateur : on écoute ou on sollicite les retours des projets, on propose de nouvelles évolutions et on corrige au besoin. On enrichit notre framework en étant à l’écoute de nos utilisateurs et en assurant un support dans la mise en place de notre solution !

Bien sûr, Bootstrap n’est pas forcément la solution idéale, pas exempt de lourdeurs, pas toujours adapté aux besoins, mais c’est un outil qui nous a permis de diffuser notre propre surcouche Boost et notre framework de tests pour :

• homogénéiser l’expérience utilisateur en proposant un set de composants tout prêt
• sensibiliser et former de manière indolore les équipes à la qualité de code front
• s’assurer que les projets partent sur de bonnes bases avec leur code front, limiter la dette technique front et améliorer la maintenabilité
• faire entrer l’accessibilité par la grande porte et l’intégrer au processus de développement, en faire une brique comme une autre de la qualité.

Nous utilisons ces tests dans nos développements pour Boost et pour valider nos nouvelles versions lors des évolutions de Bootstrap, notamment. Nous en sommes contents. Et donc, il nous reste à le diffuser plus largement déjà en interne.

Bon point complémentaire aussi, Orange n’a pas historiquement de culture open source. Boost nous a permis de voir qu’en poussant fort en interne (six mois pour un GitHub Boost !), les salariés d’une boite peuvent modestement faire évoluer les mentalités (espérons que nous aurons le même succès avec l’accessibilité !).

Une p’tite conclusion !

Ce que je veux que vous reteniez, c’est que ce que je vous ai présenté ici n’est qu’un exemple. C’est la démarche qui est la chose la plus intéressante : fournir des outils d’accessibilité intégrés dans une chaine de qualité front. C’est aussi un moyen de convaincre que l’accessibilité c’est bien plus facile si on a des outils adéquats.

Proposer un framework HTML/JS/CSS accessible avec des composants utiles et à l’utilisation aisée. Ajouter à ça des gabarits de pages, de la documentation sur les bonnes pratiques de mise en oeuvre et du support aux projets.

Parfois, Boost n’est pas adapté à la façon de travailler. Alors, nous pouvons proposer aux projets de mettre au moins en place le framework de tests pour s’assurer d’un minimum de qualité front.

Pour notre équipe, ce type de démarche nous facilite l’accompagnement de la mise en place de l’accessibilité dans les projets en nous évitant la plupart des erreurs de base et en nous donnant du temps pour de vraies tâches d’expertise en accessibilité.

Si je reprends, voici ce qu’il faut pour convaincre les projets web que l’accessibilité c’est bon et que c’est bien plus facile si on a des outils adéquats :

• mettre à disposition un framework HTML/JS/CSS accessible avec des composants utiles et à la mise en œuvre aisée
• ajouter à ça des gabarits de pages
• y adjoindre de la documentation et documenter les bonnes pratiques (de mise en œuvre, par exemple)
• fournir des outils d’accessibilité intégrés dans une chaine de qualité front en y rajoutant des outils d’accessibilité efficaces, car tout projet veut faire de la qualité !
• et du support aux projets.