Le ticket qu'on reporte de sprint en sprint

Dans beaucoup de backlogs, l'accessibilité prend la forme d'un ticket : « Rendre la page accessible ». L'équipe l'estime, le priorise, puis le repousse, parce qu'une fonctionnalité visible passe toujours devant. Quand quelqu'un finit par s'en occuper, c'est souvent dans l'urgence d'un audit ou d'une plainte, avec des corrections ponctuelles que la prochaine évolution cassera.

Le problème n'est pas la mauvaise volonté des équipes. C'est la manière de poser le sujet. Une feature se livre une fois. L'accessibilité, elle, doit être vraie à chaque livraison.

L'accessibilité comme invariant

En développement, un invariant est une propriété qui doit rester vraie quoi qu'il arrive. Les équipes traitent déjà la sécurité ainsi : personne ne crée un ticket « Rendre l'application sécurisée ». Elle fait partie de la définition de ce qui est terminé. L'accessibilité mérite le même statut.

Concrètement, cela signifie qu'une user story n'est pas terminée si elle ne fonctionne pas au clavier, si ses contrastes ne sont pas conformes, si ses champs n'ont pas de libellé ou si un lecteur d'écran ne peut pas la parcourir. Ce travail fait partie de la story.

Commencer par le Design System

La façon la plus efficace de rendre un produit accessible est de rendre ses briques accessibles. Quand le bouton, le champ, la modale et les onglets du Design System sont conformes, chaque équipe qui les utilise hérite de cette conformité sans effort. Une correction dans le système profite à tous les produits à la fois.

C'est aussi pour cela que l'équipe ne devrait jamais publier un composant qui n'a pas passé les tests d'accessibilité. Un composant non conforme dans le système, c'est un défaut copié dans des dizaines d'écrans.

L'accessibilité, pour moi, n'est pas une contrainte réglementaire. C'est une qualité.

Dans les rituels de l'équipe

  • Conception : les maquettes montrent l'ordre de tabulation, les états de focus et d'erreur, et le designer vérifie les contrastes dans les deux thèmes.
  • Affinage : chaque story comporte ses critères d'accessibilité, au même titre que ses critères fonctionnels.
  • Développement : éléments HTML natifs d'abord, ARIA seulement quand c'est nécessaire, tests automatiques dans l'intégration continue.
  • Recette : un passage complet au clavier et un passage au lecteur d'écran sur les parcours principaux.
  • Démonstration : on montre aussi le parcours au clavier. Les équipes prennent au sérieux ce qu'on leur montre.

Les défauts que l'on retrouve partout

Sur la plupart des audits, les mêmes problèmes reviennent, et presque tous se règlent au niveau du système plutôt qu'écran par écran :

  • des textes gris clair sur fond blanc, choisis pour leur élégance et illisibles pour beaucoup de monde ;
  • des icônes cliquables sans nom accessible, que le lecteur d'écran annonce comme « bouton » sans autre précision ;
  • des champs dont le seul libellé est le texte d'exemple, qui disparaît dès qu'on commence à écrire ;
  • des modales qui laissent le focus partir derrière elles, ou qui ne se ferment pas avec la touche Échap ;
  • des erreurs signalées uniquement par une bordure rouge.

Aucun de ces défauts ne demande une expertise rare. Ils demandent seulement que quelqu'un les ait interdits une fois pour toutes, dans les composants et dans la définition de ce qui est terminé.

Mesurer pour progresser

Ce qui n'est pas mesuré n'avance pas. Je suis trois indicateurs simples : la part des composants du système conformes au niveau AA, le nombre de défauts d'accessibilité détectés en recette plutôt qu'en production, et les résultats des audits périodiques sur les parcours critiques. Les outils automatiques sont utiles mais ne détectent qu'une partie des problèmes ; ils complètent les tests manuels sans les remplacer.

Le cadre légal n'est pas le moteur

Le contexte réglementaire se renforce. En Europe, l'Acte européen sur l'accessibilité s'applique depuis juin 2025 à de nombreux services, dont la banque et le commerce en ligne. En France, le RGAA fournit une méthode de test détaillée. Ces obligations sont un bon argument pour obtenir du budget. Elles sont un mauvais moteur : une équipe qui travaille pour éviter une sanction fera le minimum, une équipe qui travaille pour ses utilisateurs fera ce qui est juste.

Ce qu'il faut retenir

Traiter l'accessibilité comme une discipline, c'est accepter qu'elle ne soit jamais terminée et qu'elle concerne tout le monde. Le designer, le développeur, le rédacteur, le testeur et le Product Manager y contribuent chacun à leur endroit. Le Design System leur donne un point de départ conforme ; les rituels et la mesure font le reste. Le ticket « Rendre la page accessible » peut alors être fermé pour de bon, parce qu'il n'a plus de raison d'exister.