Accessibilité

Le déclencheur

Un audit qui révèle l'écart avec les standards

La plateforme n'avait pas de démarche accessibilité structurée sur ses interfaces web. Un audit externe a révélé des non-conformités sur des critères de niveau A et AA : focus visible insuffisant, relations sémantiques manquantes, champs de formulaire sans description... Le produit était en dessous des standards attendus par une partie des grands comptes.

L'argument qui a tout débloqué

Transformer une contrainte en critère commercial

L'accessibilité n'était pas dans la roadmap. Ce qui a fait bouger les lignes, c'est le risque business concret : des grands comptes conditionnant leur renouvellement à une conformité WCAG AA, et un marché public de plus en plus exigeant sur ce point. Le sujet est passé de contrainte technique à critère commercial. C'est en posant le problème en termes de risque client que le sujet a obtenu sa place dans la roadmap.

La méthode de priorisation

Sévérité croisée avec fréquence d'usage

Face au volume de non-conformités, j'ai mis en place une grille de priorisation croisée : sévérité WCAG d'un côté, fréquence d'usage des écrans concernés de l'autre. Le principe : corriger en priorité ce qui bloque le plus les personnes en situation de handicap sur les parcours les plus fréquents, pour montrer des résultats rapides et maintenir la dynamique.

L'implémentation

Chaque correction devient un pattern réutilisable

J'ai pris en charge directement les corrections côté front-end sur le client web. Plutôt que de corriger au cas par cas, chaque fix devenait un pattern documenté et réutilisable par les devs sur des problèmes similaires. Sémantique HTML, gestion du focus, contrastes, ARIA : chaque sprint avançait le taux de conformité et réduisait la dépendance à une personne.

À gauche, les erreurs ne sont signalées que par la couleur, sans label ni message descriptif. À droite, chaque champ a un label visible, un message d'erreur spécifique et un focus clairement identifiable.

Ce que ça a changé

L'accessibilité intégrée dans le process dev

L'objectif n'était pas de cocher une case. C'était d'installer l'accessibilité comme un réflexe d'équipe. À la fin de la mission, les critères WCAG faisaient partie du process de dev sans attendre une revue design. Le même objectif qu'un design system : rendre la qualité autonome.

À la fin de la mission, la majorité des parcours principaux étaient conformes WCAG AA.

Cette mission m'a confirmé que l'accessibilité se pilote comme n'importe quel chantier produit : avec une priorisation claire, des arguments business solides, et une implémentation progressive qui laisse des traces durables dans les habitudes de l'équipe.

Les cas restants concernent des écrans secondaires, moins exposés aux personnes en situation de handicap, et feront l'objet d'une montée en conformité progressive à mesure que ces composants seront redesignés.