Chez Radio France, nous travaillons actuellement à améliorer l’accessibilité de nos sites internets. C’est une démarche multiple, qui nous a conduits à rechercher comment réaliser des tests automatisés sur l’accessibilité de site internet.

Nous avons testé de nombreux outils, mais aucun ne permettait de répondre à nos besoins :

  • l’outil doit permettre de remonter facilement les anomalies dans un rapport d’intégration continue (dans un format TAP ou Junit par exemple) ;
  • l’outil doit permettre de disposer de rapports graphiques faciles à exploiter ;
  • l’outil doit être Open Source et libre.

Pour ces raisons, nous avons conçu et publions aujourd’hui notre projet Open Source : a11y-ci, un outil de tests automatisés d’accessibilité.

Comment ça marche ?

Développé en NodeJs, a11y-ci parse les pages web à l’aide de PhantomJs et audite les pages à l’aide de la librairie Google Accessibility developer tools pour analyser les pages.

Pour installer a11y-ci:

npm install -g a11y-ci

Pour pour générer un rapport au format JUnit, directement exploitable par Jenkins:

a11y-ci --junit=junit.xml https://www.github.com 

Notez que cette commande échouera si la page en question lève des erreurs d’accessibilité. Vous pouvez donc vous en servir pour stopper un processus de déploiement si une page n’est pas accessible.

De la même façon, vous pouvez générer un rapport HTML pour votre site ; les éléments qui ne sont pas accessibles seront directement mis en surbrillance sur votre site.

a11y-ci --html=my-report.html https://www.franceculture.fr

Aperçu du rapport d'accessibilité pour franceculture

Le projet est libre et publié sous licence CeCILL-B (compatible avec les licences BSD, X11, MIT…).

Nous espérons que ce projet saura vous être utile ! N’hésitez pas à nous faire part de vos remarques ou idées directement sur Github.

L’accessiblité, c’est quoi ?

Une définition que nous apprécions et parageons à Radio France est celle donnée dans le document Web Content Accessibility Guidelines 1.0 (disponible ici en français) du W3C (ndlr: le World Wide Web Consortium est une organisation en chage de la mise en place de standards pour le web).
Cette définition, en date du 05 mai 1999, est la suivante :

L’objectif principal de ces directives est de promouvoir l’accessibilité aux personnes handicapées. Cependant, en les suivant, le contenu Web s’en trouvera plus accessible à tous les utilisateurs, indépendamment du programme utilisateur (par exemple, logiciel de consultation bureautique (appelé navigateur), logiciel vocal, téléphone mobile, ordinateur personnel embarqué dans une automobile, etc.) et quelques soient les contingences imposées par l’environnement d’utilisation (par exemple, lieu bruyant, sur- ou sous-éclairé, en gardant les mains libres etc.) En suivant ces directives, on permettra également aux utilisateurs de trouver de l’information sur le Web plus rapidement.

Plusieurs notions nous intéresse ici. Tout d’abord, la notion de “promouvoir l’accessibilité aux personnes handicapées”.
En tant que service publique nous nous devons d’être accessible à tous et d’offrir le même accès à nos contenus à chacun des concitoyens français.

Ensuite viens une partie forte intéressante “Le contenu Web s’en trouvera plus accessible à tous les utilisateurs, indépendamment du programme utilisateur […] et quelques soient les contingences imposées par l’environnement d’utilisation […]”.
Ici, il nous est clairement explicité que l’accessibilité n’est pas une problématique touchant uniquement une partie de la population mais nous concerne bel et bien tous. Peu importe nos différences et particularités, nous devons avoir accès aux mêmes éléments. En tant que service public, celà est de notre devoir.

La dernière notion “on permettra également aux utilisateurs de trouver de l’information sur le Web plus rapidement” nous informe du bénéfice en matière d’indexation de nos contenus. En tout point l’accessibilité est donc un sujet important que nous ne négligeons pas.

Comment nous améliorons l’accessibilité de nos sites ? Le cas de franceculture.fr

Sur franceculture.fr, l’accessibilité se manifeste en premier lieu par une interface utilisateur dite “responsive”, rendant l’accès à des fonctionnalités, ainsi qu’au service public, possible à tous. Et ce peu importe l’appareil ou la résolution de l’écran de l’utilisateur.

Afin de garantir l’accès aux principales fonctionnalités de manière cohérente en toutes conditions de navigation, nous essayons de concevoir nos fonctionnalités en priorité pour être utilisées en mobilité. De ce fait, si le besoin est adressé sur téléphone portable tactile avec une interface adaptée, nous nous assurons qu’il le soit également sur des écrans plus grand utilisés avec un clavier, un souris, une qualité de connexion variable, des hauts-parleurs, un lecteur d’écran, etc. Cette manière de concevoir les fonctionnalités est souvent appelée “mobile-first”.

Grâce à l’outil précédemment présenté, nous avons pu faire un état des lieux du site. Plusieurs pistes d’amélioration ont ainsi été mise en lumière, représentant des étapes d’une évolution vaste et conséquente.

Comme vous l’avez peut-être dejà lu ici, au sein de la direction du numérique nous travaillons en méthode agile, et plus précisement en scrum pour les équipes en charges des frontaux de chacune des chaines.

Nous pratiquons des “sprints” de deux semaines qui débutent par un “sprint planning” et se clotûrent par une demonstration puis une retrospective d’équipe.

Le sprint planing consiste plus précisément en l’engagement de la part de l’équipe pluri-disciplinaire à livrer un nombre finie de “User Stories” (abrégées en “US”) dans le sprint à venir. La “démonstration” servira quant à elle à valider ou non des US, par extension l’engagement de l’équipe.

Avant même qu’une évolution conséquente ne débute, on la découpe en différentes US regroupées au sein d’une “épopée”. Celà permet de suivre l’avancée de l’évolution lorsque l’on prend ses US sur différents sprints.

Nous avons donc mis en place une épopée d’accessibilité composée de 14 users stories, comprenant chacune les specifications non respectées et identifiées grace à l’outil a11y-ci.

Nous avons dejà tiré bénéfice de cet outil en ajoutant, par exemple, un label à chacun de nos boutons de réécoute d’audio. Ceci posait problème pour les personnes malvoyante utilisant un lecteur d’écran. Aucun label n’étant présent, le lecteur d’écran n’a pas d’information à lire à l’utilisateur, rendant impossible l’accès à la réécoute.

Nous avons encore beaucoup d’améliorations à réaliser mais grace à l’outil et à notre méthode, toutes les améliorations necessaires sont historisées, organisées et développées, participant à l’amélioration continue du produit de service publique.