Combien de temps faut-il vraiment pour développer un composant accessible, comparé au même composant développé sans y penser puis corrigé ensuite ? La question revient à chaque devis, souvent sous une forme plus tranchée : « l’accessibilité, ça va faire exploser le budget ». Pour y répondre autrement qu’à l’instinct, nous avons chronométré deux développeurs de niveau comparable sur un même composant : un bloc Gutenberg personnalisé de type onglets, utilisé pour présenter les garanties d’un produit sur une fiche technique.
Le premier développeur a reçu une spécification incluant, dès le départ, le comportement clavier attendu (flèches pour naviguer entre les onglets, Home/End pour aller au premier et au dernier), les rôles ARIA du motif tablist/tab/tabpanel, et la gestion du focus associée. Le second a reçu uniquement la maquette visuelle et la consigne « rendre accessible avant la livraison », sans détail préalable.
Ce que révèle la notion de « conception accessible dès le départ »
Un composant conçu avec l’accessibilité comme contrainte de départ n’est pas plus long à coder : le code du motif tablist est connu, documenté par le WAI-ARIA Authoring Practices Guide, et se transpose directement en JavaScript et en marquage HTML sans tâtonnement :
<div role="tablist" aria-label="Garanties du produit">
<button role="tab" aria-selected="true" id="onglet-1" aria-controls="panneau-1">
Garantie légale
</button>
<button role="tab" aria-selected="false" id="onglet-2" aria-controls="panneau-2" tabindex="-1">
Garantie commerciale
</button>
</div>
<div role="tabpanel" id="panneau-1" aria-labelledby="onglet-1">...</div>
<div role="tabpanel" id="panneau-2" aria-labelledby="onglet-2" hidden>...</div>
Le temps de développement de ce premier bloc, gestion clavier comprise, s’est établi à 3 heures et 40 minutes, contre 3 heures pour une version purement visuelle sans gestion clavier ni rôles ARIA. L’écart initial, environ 40 minutes, correspond au temps d’écriture des gestionnaires d’événements clavier et à la mise en place correcte des attributs aria-selected et tabindex dynamiques.
Ce que révèle la correction a posteriori
Le second bloc, développé sans spécification d’accessibilité, a nécessité 3 heures et 5 minutes de développement initial, un temps très proche de la version visuelle du premier scénario. La correction ultérieure, elle, a demandé 2 heures et 20 minutes supplémentaires : il a fallu reprendre la structure DOM existante (les onglets n’utilisaient que des <div> cliquables sans sémantique), ajouter les rôles après coup sans casser le style déjà écrit, retester chaque état, et gérer des conflits entre le gestionnaire de clic initial et le nouveau gestionnaire clavier. Le temps total pour ce second bloc s’est élevé à 5 heures et 25 minutes, contre 3 heures et 40 minutes pour le premier.
L’écart mesuré entre les deux approches complètes atteint 45 minutes en faveur de la conception accessible dès le départ, alors même que le second développeur partait avec un temps de développement initial légèrement inférieur au premier.
Ce que le chronomètre ne capture pas entièrement
- Le bloc conçu accessible dès le départ a servi de base à deux autres blocs d’onglets sur le même projet, réutilisés sans reprise de la logique clavier
- Le bloc corrigé après coup a nécessité une revalidation complète en recette, alors que le premier n’a demandé qu’une vérification ciblée
- Le stress de la correction tardive, proche de la livraison, a un coût difficile à chiffrer mais réel sur la qualité du reste du sprint
Une limite assumée de cette mesure
Un seul composant chronométré sur deux développeurs ne constitue pas une preuve statistique généralisable : la variance entre développeurs, la familiarité préalable avec le motif ARIA tablist, ou la complexité propre au projet influencent fortement le résultat. Ce que cette mesure montre surtout, c’est que le surcoût de l’accessibilité en conception initiale est faible et prévisible, alors que le coût de la correction a posteriori dépend fortement de la qualité du code déjà écrit, et grimpe vite si la structure DOM doit être reprise en profondeur.
La leçon que nous tirons de cet exercice, projet après projet : le budget d’accessibilité se dépense le mieux au moment de la spécification, jamais au moment de la recette finale.
En résumé
L’accessibilité ne ralentit pas le développement de façon significative lorsqu’elle fait partie du cahier des charges dès la conception d’un composant. Elle ralentit en revanche nettement le projet lorsqu’elle est traitée comme une correction de dernière minute, parce qu’elle oblige alors à revenir sur des décisions structurelles déjà prises. Le chiffre à retenir n’est pas tant les 45 minutes d’écart mesurées ici que le moment où ce temps est dépensé : en amont, il s’intègre au flux normal de développement ; en aval, il s’ajoute dessus.
