Rendre un backoffice accessible

Ces derniers temps je travaille à rendre le Backoffice du CMS Translucide plus accessible. A la base j'avais pensé au CMS pour qu'il soit plus écoconçu. Des temps d'exécution plus courts, moins de code à maintenir, moins d'espace sur le disque, des pages qui nécessitent peu de données et fichiers pour être chargées nativement, une base fonctionnelle sobre pour les besoins de base.

Aussi, que les usagères qui administrent le site aient moins de charge mentale, ne pas avoir une 2ème interface de Backoffice à ingurgiter. Qu'ils comprennent plus rapidement les interfaces et puissent modifier très rapidement leur contenu facilement. Mais je n'étais pas acculturé à l'accessibilité aux handicaps.

Être développeur avant et après la découverte de l'accessibilité web

Je dois dire qu'après avoir découvert le monde de l'accessibilité, je ne vois plus le web de la même façon et mon code s'en trouve beaucoup affecté. Loin d’apprendre une nouvelle technologie et d'utiliser de l'assistance par IA, il s'agit de faire du code HTML généré qui respecte les normes et des fonctions utilisables par tous.

Et là je vois bien que je n'avais pas du tout les bons réflexes. Je pensais à l'UX en premier sans penser à son accessibilité, son usage au clavier ou autre système d'assistance. Repenser l'ordre des fonctionnalités, leur contraste et visibilité, leur accessibilité par d'autres moyens que la souris, leur intelligibilité. Concrètement, mon héritage de développeur qui a viré sur des usages plus JavaScript s'est éloigné des standards du HTML et de la nécessité d'utiliser les bonnes balises.

Rendre du fonctionnel complexe plus accessible

Le fait que tout soit activable et utilisable au clavier par exemple est une autre façon de penser, hors de mes habitudes d'utilisateurs valides qui utilisent la souris. Si un lecteur d'écran doit en permanence décrire les actions en cours, il faut aussi penser à ce que ça ne soit pas interminable, compréhensible pour une personne qui ne voit absolument rien à ce qui se passe. Imaginer dans sa tête ce qui nous est décrit.

Je n'y suis pas encore, le Backoffice ne sera pas 100% conforme au RGAA pour le moment, mais ça avance, et je réfléchis aujourd'hui autrement. C'est comme la prise de conscience environnementale, une fois que l'on sait que c'est difficile de ne plus y penser, on essaie de faire autrement, de façon plus respectueuse envers le vivant, en essayant de ne pas discriminer.

Un bénéfice aussi pour les personnes valides

Ce qui est étonnant, c'est que finalement, pour un utilisateur valide, il ne verra pas forcément la différence. La présentation et le fonctionnel restent similaires, voire un peu ralentis. On a moins d'actions automatisées au survol de la souris, les actions s'activent au clic. Ça ralentit, mais aussi stabilise les interfaces. Après aussi, les gains en contraste sont un confort en plus. Quand je retombe sur un site avec l'ancienne interface, ça me fait bizarre. Ça apporte aussi du confort, subtil pour les personnes valides, primordial pour des personnes en situation de handicap.

Bilan de presque 100 heures de développement sur l'accessibilité d'un Backoffice

A l'heure de l'écriture de ces lignes, je dirais que je suis repassé dans plus de la moitié du code du CMS. J'ai recouru une grande partie de ce qui génère les interfaces, sous les conseils de Access42. Ils m'ont aidé à y voir plus clair, et aussi priorisé sur les fonctionnalités les plus utilisées.

Ça a aussi été l'occasion de revoir l'UX de certaines fonctionnalités, pour les rendre plus robustes. Il me reste quelques fonctionnalités importantes pour boucler cette première passe. Je suis déjà passé sur 80 % de ce qui était prévu, avec un surplus de temps d'environ 30/40 %. Ce qui augmente considérablement l'accessibilité du Backoffice. Il restera une longue phase de test durant les prochains mois pour pouvoir imaginer une seconde passe et être sûr qu'il n'y ait pas de point bloquant.

Rendre accessible un Backoffice comparé à un Frontoffice

Rendre accessible un Backoffice est une autre paire de manches comparée à un Frontoffice (le site que voient les visiteurs). Dès qu'il y a des interactions complexes entre l'utilisateur et la machine, la complexité peut augmenter vite. En gros, les comportements de formulaire ou d'interaction en JavaScript créent beaucoup de tests à effectuer pour s'assurer de leur fonctionnement sur tous les systèmes d'assistance. C'est souvent pour ça que les outils d'entreprise sont souvent non accessibles. Aussi, plus une interface est grosse, voire obèse, plus le travail est démultiplié. En cela, une démarche d'écoconception, qui réduit et repense le fonctionnel, est un atout.

Je ne remercierai jamais assez l'agglomération du Pays Basque qui a ouvert un budget pour rendre plus accessible le Backoffice du CMS Translucide. Des institutions publiques, motivées par des personnes investies, peuvent faire évoluer le logiciel libre, pour le bien de tous, un commun numérique. Cette mise à jour permettra à plus de personnes de modifier le contenu de leur site pour qu'il soit toujours plus conforme au RGAA.