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 :

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.
Vincent Aniort

À propos de Vincent Aniort

Vincent Aniort travaille chez Orange en accessibilité numérique. Il est impliqué dans de nombreuses associations qui militent pour l'accessibilité, en particulier numérique. C'est un combat de longue haleine : convaincre que l'accessibilité est un avantage pour tous, une nécessité pour certains. Vous pouvez suivre Vincent sur Twitter.

Vous pouvez partager cet article sur Facebook, Twitter ou Google+.

Faites un don pour soutenir l'association Les B-A des Satellites

L'association Les B-A des Satellites aide à offrir une école aux enfants de Niellé en Côte d'Ivoire.

Les fonds récoltés vont directement sur le compte PayPal de l'association. En cliquant sur le bouton « Faire un don » ci-dessus, vous allez être redirigé vers PayPal. Vous n'êtes pas obligés de créer un compte PayPal pour faire un don.

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

  1. MoOx, le mardi 1 décembre 2015 à 09:38

    My 2 cents sur les linters à utiliser aujourd'hui:

    JS: ESlint
    CSS: Stylelint (csslint n'étant vraiment pas maintenu)

    C'est 2 outils sont modulaires: vous pouvez facilement ajouter vos propres règles pour linter votre code !

  2. Nicolas Chevallier, le mardi 1 décembre 2015 à 09:48

    Le choix de se baser sur Bootstrap est judicieux et c'est à mon avis le point le plus important pour la réussite et l'adoption de ce nouveau framework, s'appuyer sur un framework existant populaire.

  3. Nathan Peixoto, le mardi 1 décembre 2015 à 10:24

    Très intéressant.
    Je suivrais de près l'arrivée de votre Framework sur Github.
    On fait encore trop peu d'accessibilité de notre côté et on n'a pas vraiment de contraintes à ce niveau-là, mais c'est tout de même relativement important.

  4. sanvin, le mardi 1 décembre 2015 à 11:06

    @MoOx merci, je vais regarder ça
    @Nicolas Chevallier tout à fait d'accord avec toi, c'est la principale raison de notre succès
    @Nathan Peixoto c'est pas "relativement" important, c'est très important et là on a moyen de faire entrer l'a11y plus facilement et avec peu d'effort

  5. Kevin Py, le mardi 1 décembre 2015 à 13:27

    L'expérience Utilisateur et Bootstrap, c'est pas bon signe. On connait tous la lourdeur de ce framework, mais si vous arrivez à le rendre plus accessible, et compatible Angular, avec une complète accessibilité, moi je dis, cool. Bootstrap ne demande qu'à être aimé, mais en l'état pur, il n'est pas vraiment convaincant, et je pense qu'il nécessite un travail comme le vôtre pour qu'il soit utiliser à son plein potentiel.

  6. Julien Jolly, le mardi 1 décembre 2015 à 14:26

    Salut @Kevin_Py . Tu peux développer concernant l'UX et Bootstrap ?
    Sinon, concernant bootstrap et angular, ça existe déjà: https://angular-ui.github.io/bootstrap/. Bon après, ok, il y a des lacunes concernant l'accécibilité

  7. Carsten, le mardi 1 décembre 2015 à 15:46

    Intégrer l’accessibilité ainsi dans un process qualité est vraiment une très bonne chose. J’entends déjà dans les commentaires des remarques sur Bootstrap qui n’est clairement pas ce qui se fait de mieux pour démarrer une démarche qualité, ce que je confirme.
    Le problème de Bootstrap, c’est déjà sa lourdeur. Si vous utilisez un micro-framework comme roCSSti pour n’en citer qu’un, vous aurez déjà un CSS plus léger, plus rapide dans vos tâches de compilation et surtout bien plus favorable pour coder accessible.
    Bootstrap est déjà lui-même un assemblage de librairies dont normalize. Cette dernière, par exemple, provoque des bugs d’accessibilité sur Firefox (https://github.com/necolas/normalize.css/issues/481). On y ajoute des plugins (Paypal ou autres) pour corriger et améliorer tout un tas de choses. Puis on y ajoute encore des sur-couches pour l’adapter à l’accessibilité de vos projets. Au final vous avez un millefeuille bien long à manipuler et lourd pour les utilisateurs.
    Le mérite de cette approche, c’est qu’elle est fédératrice et même si j’attends de voir pour la partie Bootstrap optimisée, ce choix donne encore plus de mérite à l’équipe Orange. Ce qui compte c’est de s’y mettre et de changer les mentalités des développeurs !

  8. Kevin Py, le mardi 1 décembre 2015 à 17:05

    Hey @JulienJolly, @Carsten a bien résumer le truc. Le problème de Bootstrap, c'est que c'es lourd. Alors avec des plugins en plus, ça devient encore plus lourd. Mais ça ne me gêne pas dans l'absolue. Ce qui me gêne, c'est le concept mobile-first, qui n'est pas adapté aux smartphones, car cela requiert un grand temps de chargement, ce qui de base, n'en fait pas un bon compagnon pour l'expérience utilisateur.
    Mais je suis convaincu que Bootstrap peut être utiliser à bon escient, comme c'est le cas de @sanvin. Il faut savoir le dompter, et pas juste lui coller des plugin, pour le rendre plus lourd et difficilement maintenable.

  9. Gaël Poupard, le mercredi 2 décembre 2015 à 10:04

    Bootstrap n'est qu'un outil, et @sanvin explique très bien pourquoi ils l'ont choisi. c'est comme souvent une question de contexte.

    Tout ce processus d'intégration continue incluant l'accessibilité et l'outillage complet de la chaîne de production est vraiment génial. Ça fait des années que je tends vers ça mais j'en suis encore très loin. Merci beaucoup pour ce super retour d'expérience, qui complète également votre atelier à Paris Web ;)

    Vous évoquez que Boost est open source : est-il dénichable dans un recoin du web ? Même si c'est charté Orange, je pense qu'il y a plein de bons morceaux à étudier dedans :D

  10. sanvin, le mercredi 2 décembre 2015 à 11:25

    En effet, Bootstrap est lourd, mais on a quand même des moyens de l'alléger (UnCSS par exemple) mais, ici, Bootstrap n'est qu'un moyen dans un contexte particulier... comme le dit @Gaël Poupard (merci pour ton commentaire)
    Boosted (c'est son nouveau nom lors du release en open source) est https://github.com/Orange-OpenSource/Orange-Boosted-Bootstrap

  11. Cyberbaloo, le lundi 7 décembre 2015 à 11:26

    Good, je vais voir ce que je peux utiliser au travail. Ca serait bien qu'on ait un framework accessible de *base*
    Je te tiens au courant :-)

Laisser un commentaire

Les commentaires sont modérés manuellement. Merci de respecter l'auteur de l'article, les autres participants à la discussion, et la langue française. Vous pouvez suivre les réponses par flux RSS.