TerrainScénario type
Former une équipe de développement à l’accessibilité
Une journée de formation, un support de deux cents diapositives, et trois semaines plus tard rien n'a changé. Le scénario d'une équipe qui a repris la formation à l'accessibilité par l'autre bout : ses propres écrans, ses propres composants.
Le support comptait près de deux cents diapositives. La journée de formation avait été bien notée par les participants. Trois semaines plus tard, la nouvelle page de commande arrive en recette avec des boutons sans nom, un formulaire impossible à remplir au clavier et des messages d’erreur signalés par la seule couleur rouge. La responsable produit de cette entreprise de vente en ligne de taille moyenne, concernée par l’European Accessibility Act depuis juin 2025, en tire une conclusion : la formation accessibilité a eu lieu, l’apprentissage non. Ce scénario type décrit comment l’équipe a repris le problème.
Le point de départ
L’équipe compte six développeurs, une designer et une responsable produit. Elle maintient le site marchand et l’application mobile, avec une livraison toutes les deux semaines. Un audit réalisé au printemps a relevé de nombreux défauts sur les parcours principaux : recherche, fiche produit, panier, paiement, compte client.
La journée de formation a présenté les WCAG critère par critère. Les développeurs en ont retenu des principes, mais aucun réflexe : face à leur propre code, ils ne savaient pas par où commencer, ni comment vérifier. La designer, elle, n’avait pas été invitée.
La formation portait sur le référentiel, pas sur le travail de l’équipe. Elle a eu lieu une fois, hors du cycle de livraison, et n’a laissé derrière elle ni outil, ni rituel, ni personne référente.
Changer d’approche : partir des composants
Avec l’appui d’un intervenant extérieur pour trois mois, l’équipe décide de reprendre la formation par ses propres écrans. Le programme tient en quatre temps, insérés dans les itérations existantes.
- Composants d’abordcorriger la bibliothèque partagée
- Tester comme un usagerclavier, lecteur d’écran, zoom
- Automatiser le filettests dans l’intégration continue
- Installer le rituelclinique hebdomadaire, référents
Les composants d’abord. L’équipe utilise une bibliothèque de composants partagée : boutons, champs, listes déroulantes, fenêtres modales, onglets. Chaque défaut d’un composant se répète sur toutes les pages. Les premières séances consistent donc à corriger ensemble, en binôme avec l’intervenant, une dizaine de composants. Chaque correction devient une leçon concrète : pourquoi un bouton doit avoir un nom accessible, comment une fenêtre modale doit garder le focus, ce qu’un lecteur d’écran annonce pour une liste déroulante personnalisée.
Tester comme un usager. Chaque développeur apprend trois gestes de vérification, à faire avant toute demande de relecture : parcourir la fonctionnalité au clavier seul, l’écouter avec un lecteur d’écran (NVDA sous Windows, VoiceOver sur Mac et iPhone), l’afficher à 200 % de zoom. Ces trois gestes prennent quelques minutes et révèlent la majorité des défauts courants.
Automatiser le filet. Un outil de test automatique, intégré à la chaîne d’intégration continue, bloque désormais les régressions les plus simples : contrastes, alternatives manquantes, attributs invalides. L’équipe sait qu’il ne détecte qu’une partie des problèmes ; il évite simplement de revenir en arrière.
Installer le rituel. Chaque semaine, une « clinique » de trois quarts d’heure examine un écran en cours de développement. Deux développeurs volontaires deviennent référents et animent progressivement ces séances à la place de l’intervenant.
La designer et la responsable produit dans la boucle
Le deuxième mois, l’équipe constate que plusieurs défauts naissent avant le code. La designer annote désormais ses maquettes : ordre de lecture, texte des boutons, comportement au focus, alternatives des images. La palette a été revue pour que les contrastes soient conformes par défaut. La responsable produit ajoute l’accessibilité aux critères d’acceptation de chaque fonctionnalité : une fonctionnalité utilisable au clavier et correctement annoncée par un lecteur d’écran fait partie de la « définition de terminé », au même titre que les tests fonctionnels.
On ne forme pas une équipe à un référentiel ; on la forme à vérifier son propre travail, chaque semaine, sur ses propres écrans.
Mesurer les progrès sans se raconter d’histoires
L’équipe se dote d’un indicateur simple, suivi à chaque itération : le nombre de défauts d’accessibilité détectés en recette sur les nouvelles fonctionnalités, classés en bloquants et gênants. L’indicateur ne mesure pas la conformité du site, mais la capacité de l’équipe à produire juste du premier coup. C’est précisément ce que la formation cherche à changer.
Un second repère, plus qualitatif, s’ajoute : les questions posées lors des cliniques. Au début, elles portent sur les bases (« faut-il une alternative à cette icône ? »). Après quelques semaines, elles deviennent plus fines (« comment annoncer la mise à jour du panier sans interrompre la lecture ? »). Ce glissement est un bon signe que les réflexes de base sont acquis.
Le coût de la démarche est connu dès le départ : trois quarts d’heure de clinique par semaine, quelques minutes de vérification par fonctionnalité, l’appui extérieur pendant trois mois. La responsable produit le présente à la direction comme un investissement dans la qualité de livraison, et non comme un poste de dépense à part.
Ce qui a changé, et ce qui reste difficile
Au bout de trois mois, les nouvelles fonctionnalités arrivent en recette avec nettement moins de défauts d’accessibilité, et ceux qui restent sont plus subtils : formulations ambiguës, parcours trop longs, composants complexes comme le sélecteur de dates. Les référents tranchent la plupart des questions ; l’intervenant n’est plus sollicité que pour les cas difficiles.
Restent deux chantiers. Les pages anciennes, construites avant la bibliothèque de composants, demandent une reprise progressive, planifiée dans le schéma pluriannuel. Et l’équipe n’a pas encore organisé de test avec des personnes en situation de handicap, la seule manière de savoir si un parcours conforme est aussi un parcours utilisable. Il est prévu au trimestre suivant.
Trois enseignements dépassent ce scénario. Une formation utile s’insère dans le cycle de travail, au lieu de s’y ajouter. Elle commence par ce qui se répète, les composants, pour que chaque correction profite à tout le produit. Et elle vise l’autonomie : des référents internes et des gestes de vérification quotidiens, plutôt qu’une dépendance durable à un expert.
C’est l’approche que nous suivons dans notre expertise web accessible : intervenir dans l’équipe, sur son code, jusqu’à ce qu’elle n’ait plus besoin de nous. Notre dossier sur l’accessibilité numérique replace la formation dans la démarche d’ensemble, de l’audit au pilotage.
Scénario type construit à partir de situations courantes ; il ne décrit pas une organisation réelle.
Questions fréquentes
Combien de temps faut-il pour former une équipe de développement à l'accessibilité ?
Les bases (structure, clavier, alternatives, formulaires, contrastes) s'acquièrent en quelques séances pratiques. La maîtrise vient avec la répétition sur des cas réels, sur plusieurs mois. Une formation efficace s'étale donc dans le temps, au rythme du travail de l'équipe, plutôt que de se concentrer en une journée.
Les tests automatisés suffisent-ils ?
Non. Les outils de test automatique détectent une partie des défauts, comme les contrastes insuffisants, les images sans alternative ou certains attributs manquants. Ils ne savent pas juger si une alternative est pertinente, si l'ordre de lecture a un sens ou si un parcours est utilisable au clavier. Ils sont un filet de sécurité, pas une évaluation.
Faut-il former aussi les designers et les chefs de produit ?
Oui. Beaucoup de défauts naissent dans la maquette ou dans la définition du besoin : contrastes choisis, informations transmises par la seule couleur, composants complexes là où un composant standard suffirait. Une équipe dont seuls les développeurs sont formés corrige en aval des problèmes qui auraient pu être évités en amont.
Que faire si l'équipe ne dispose pas de personne experte ?
Faire appel à un appui extérieur pour une durée limitée, avec un objectif explicite de transfert : à la fin, une ou deux personnes de l'équipe doivent pouvoir animer la pratique seules. L'appui extérieur sert à démarrer et à trancher les cas difficiles, pas à porter durablement l'accessibilité à la place de l'équipe.