Accessibilité : 1 an après

Il y a un an, j’écrivais un article sur l’accessibilité chez OpenClassrooms sans avoir idée des répercussions sur mon quotidien. Cet article répondait à mon objectif du premier semestre 2021. Mon second objectif s’est naturellement porté sur l’accessibilité numérique et notamment la mise en œuvre des améliorations abordées dans l’article précédent.

Ici, je détaillerai ces objectifs et les différents projets entamés autour de ce sujet qui me tient à cœur.

Collaboration avec les autres équipes

Je ne vous cache pas que cette partie est aujourd’hui la plus compliquée pour nous, notamment à cause du manque de planification et de mise en avant du sujet au niveau de l’entreprise. Cela nous a amené à certaines situations où, l’accessibilité n’étant pas parmi les priorités principales, certaines avancées qui auraient pu sembler simples se sont avérées plus compliquées que prévu.

Peu de temps après la parution de mon précédent article, l’équipe Tech a proposé aux chapters (équipe de collègues ayant le même poste) de s’organiser en communauté (regroupement de deux personnes ou plus souhaitant travailler sur un même sujet). J’ai donc la chance de travailler avec Noëlie Roux, développeuse front-end d’une autre squad. Nous nous répartissons le travail et nous nous réunissons une fois par semaine pour discuter de notre avancement. Grâce à cette communauté dédiée à l’accessibilité nous avons pu avoir plus d’impact auprès de nos collègues, notamment au niveau de la sensibilisation. Évidemment, nous avons pu fournir une charge de travail plus importante mais aussi échanger sur le sujet et progresser ensemble.

Ces dernières semaines, nous avons franchi une étape importante en créant un comité d’accessibilité. Nous nous sommes rendues compte que plusieurs autres équipes travaillent sur ce sujet. Par exemple, le student support qui propose des aménagements spécialisés pour chaque personne, ainsi que l’équipe chargée du contenu des cours qui propose des sous-titres sur chacune des vidéos. Toutes les équipes travaillant avec les étudiants et étudiantes comprennent un ou une spécialiste handicap. Nous avons donc mis en place ce comité afin de regrouper nos efforts, nous avons déjà commencé à travailler sur l’accessibilité des PDFs et des vidéos. Cela nous permet d’avoir plus de visibilité et de poids dans les décisions.

Documentation

Notre première initiative était de revoir la documentation disponible. Pour ça nous avons créé un espace notion présentant l’initiative et proposant différents outils de suivi et de sensibilisation.

On y retrouve trois tableaux de suivi : un pour les pages publiques du site, un pour les pages connectées et un dernier pour l’avancement de notre travail.

Les deux premiers sont une liste de pages existantes, sur lesquelles nous avons pour but d’avoir un score Lighthouse de 100% et suivons l’avancement de leur mise à niveau.

Dans la partie Ressources, nous proposons principalement des éléments de sensibilisation sur lesquels je reviendrai dans le chapitre concerné.

Pour la partie liée au développement, nous avons un inventaire de toutes les règles d’accessibilité que nous suivons. J’étais agréablement surprise de constater que notre linter inclut de nombreuses règles a11y.

A ces règles nous avons ajouté celle de toujours fournir un aria-label aux boutons ne contenant qu’un icône. En effet, sans alternative textuelle, ces boutons ne sont pas du tout accessibles aux personnes utilisant des lecteurs d’écrans. Pour l’édition des aria-labels, j’ai travaillé avec une UX writer de ma squad. Nous avons décidé de proposer ces labels recommandés sur une page Notion ainsi que dans notre design system afin d’éviter de refaire ce travail à chaque nouveau projet.

Pour centraliser toutes ces règles à suivre lors du développement, j’ai rédigé une page dans notre Wiki GitHub. On y trouve :

• la structure HTML sémantique à respecter,
• la gestions des icônes (sémantiques, décoratifs, ou en guise de bouton),
• les éléments HTML interactifs (focus, hover, indicateurs visuels),
• les images et textes alternatifs,
• les animations et l’utilisation de reduceMotion,
• une liste des principales extensions navigateurs pour tester nos pages (Lighthouse, Web Developer et Axe).

Automatisation

Spoiler: l’automatisation est nécessaire.

Pour ce qui est du linter lors des commits et du push, je n’ai pas modifié grand-chose puisque notre linter intègre déjà les règles a11y. J’ai simplement ajouté notre règle des boutons avec icône, cet ajout a donné lieu à une pull request de 174 fichiers modifiés, ne pas négliger l’impact d’une seule règle !

Malgré une documentation fournie, le code envoyé en pull request ne respectait pas toujours l’accessibilité. Cela est dû à un manque d’habitude et de formation. En effet, les formations de développement web n’abordent que très peu l’accessibilité numérique, ou proposent seulement quelques jours de sensibilisation. C’est donc un point d’attention qui ne fait pas toujours partie du quotidien des développeuses et développeurs malgré leur bonne volonté et envie de contribuer. En discutant avec mes collègues, il apparaît clairement que la solution est d’intégrer un outil de vérification à la CI. Nous avons choisi Lighthouse mais malheureusement, notre équipe devops a eu beaucoup de travail cette année en migrant la CI sur Codefresh. Pour l’instant, Lighthouse vient d’être intégré dans NewRelic avec un échantillon de pages publiques. Il nous faut donc ajouter les pages restantes, trouver une solution pour vérifier les pages connectées et créer une alerte afin que cela soit efficace. De là, nous pourrons voir si c’est suffisant ou s’il faut intégrer Lighthouse dans la CI et bloquer les merge. C’est loin d’être terminé mais j’ai hâte de voir les effets sur notre quotidien et la qualité du code que nous délivrons.

Amélioration du taux de conformité au WCAG et RGAA

En parallèle des autres initiatives, nous avons entamé un travail beaucoup plus minutieux de correction des pages actuelles. N’ayant pas d’audit sur lequel nous baser, nous avons pour objectif d’avoir un score Lighthouse de 100 sur chaque page. Les pages sur lesquelles nous travaillons sont listées dans les deux tableaux que je présentais dans la partie documentation. C’est un travail chronophage mais moins fastidieux que l’on pourrait imaginer.

D’abord, il faut bien différencier la notion de taux de conformité et de niveau d’accessibilité. Les taux, tels que celui de Lighthouse, que nous utilisons en interne couvrent une partie “théorique” de l’accessibilité numérique, qui, elle, ne peut être testée que grâce à un audit. Une page peut avoir un score Lighthouse de 100 et être complètement inaccessible s’il y a un point bloquant dans l’en-tête ou le menu. Notre travail ici est donc d’être conforme à des taux d’accessibilité, seulement après cela nous pourrons démarrer un vrai travail d’accessibilité.

Ce travail de rendre accessible une page me semble plus difficile que la mise à niveau. En effet, il nécessite plus de collaboration inter-métier et bien souvent la refonte de designs voire de parcours entiers.

Roadmap

Une des leçons apprises cette année est la nécessité d’une “roadmap”, c’est-à-dire une organisation définie des sujets et de leurs priorités. Pas forcément pour la ou les personnes travaillant sur l’accessibilité car si vous êtes un petit groupe bien organisé avec un tableau de suivi c’est tout à fait suffisant. En revanche, dans une entreprise comme OpenClassrooms, lorsque vous aurez besoin de travailler avec une autre équipe il faudra que vos tâches soient planifiées dans une roadmap.

Nous avions défini un plan de travail sur plusieurs mois comprenant la mise en conformité des pages publiques puis des pages du parcours étudiant, le tout en continuant en parallèle à travailler sur des sujets plus transverses (par exemple les aria-labels sur les boutons avec icône). Finalement, ce plan a été chamboulé par des demandes de l’équipe produit, les pages du parcours étudiant sont passées en priorité et nous avons envisagé un audit externe qui n’a malheureusement pas encore pu avoir lieu.

Nous avons donc concentré nos efforts sur la sensibilisation et la communication, tout en continuant à améliorer notre taux de conformité et à développer des améliorations transverses.

Audit

Dans mon précédent article, j’abordais l’idée de faire réaliser un audit externe.

Premièrement, nous pensions à un audit exhaustif de notre site, il s’avère que les audits sont généralement réalisés sur une sélection de pages représentant un parcours type. Nous avons aussi appris que certaines sociétés d’audit proposent un suivi et une vérification des modifications apportées, ce qui nous paraît nécessaire.

Comme je l’évoquais dans le paragraphe précédent, la question de l’audit a été remise à plus tard. Néanmoins, j’en retiens qu’il n’est pas très pertinent de faire réaliser un audit avant d’être en conformité avec le RGAA et WCAG, ni sans avoir une roadmap qui permettra aux autres équipes de dégager du temps pour collaborer aux améliorations nécessaires.

Pendant ce temps, nous avons quand-même progressé en interne sur le test du niveau d’accessibilité des pages, notamment par la maîtrise d’outils tel que le lecteur d’écran.

Sensibilisation

Les actions de sensibilisation sont sûrement ce que nous avons le mieux réussi cette année.

Nous avons organisé un atelier de sensibilisation et de présentation des problématiques liées à l’accessibilité avec une association de personnes mal et non voyantes, qui était destiné à l’équipe technique (développement, design, qualité) et a réuni environ 60 personnes. L’accueil a été très positif et a permis d’éveiller les consciences sur le sujet, notamment en ce qui concerne l’utilisation du lecteur d’écran.

Nous avons aussi réalisé et ajouté à notre espace Notion une vidéo d’introduction à l’utilisation du lecteur d’écran, un guide de vérification de l’accessibilité des PDFs et une bibliothèque. Un tutoriel de vérification de l’accessibilité d’une page est en cours.

Nous avons également suivi le Global Awareness Accessibility Day (GAAD), à l’échelle de l’entreprise. Pour cela, nous avons incité nos collègues à zoomer leur écran, utiliser uniquement leur clavier puis utiliser uniquement le lecteur d’écran durant leur journée de travail. Une page récapitulative de l’évènement ainsi que des messages Slacks étaient à leur disposition pour animer la journée.

Nous constatons que les actions de sensibilisation fonctionnent toujours pour éveiller l’empathie et l’envie d’améliorer l’accessibilité numérique de notre plateforme. En revanche, elles n’entraînent pas encore suffisamment d’implication sur le long terme.

Conclusion

Comme l’année dernière, je termine cet article par ma to-do-list de l’année à venir :

• suivre une formation, d’une part pour être plus qualifiée mais aussi pour pouvoir partager ces connaissances avec mes collègues,
• automatiser les tests d’accessibilité,
• me tourner de plus en plus vers des groupes de travail extérieurs pour échanger sur leurs expériences et apprendre à leur côté,
• faire vivre le comité d’accessibilité, afin de conserver ce sujet comme une des priorités principales au sein de diverses équipes.

Cette première année était une mise en route de l’initiative et j’ai hâte qu’en découle des avancées plus techniques ! Avancées, que je ne manquerai pas de partager avec vous dans un an.