L'accessibilité n'est pas une checklist, c'est une architecture

La majorité des audits RGAA que j'ai vus arriver trop tard partageaient le même défaut d'origine : l'accessibilité avait été pensée comme une liste de corrections, jamais comme une contrainte de conception.

Le symptôme classique

Un design system qui n'intègre pas les contrastes ou la navigation clavier dès sa conception générera des centaines de non-conformités, répétées sur chaque écran qui l'utilise. Corriger après coup revient à reprendre chaque écran individuellement.

Ce que change une approche architecture

• Les composants de base (boutons, formulaires, modales) sont validés une fois, accessibles partout ensuite
• Les choix de structure HTML sémantique sont faits en amont, pas retrofités
• Les tests d'accessibilité s'intègrent au cycle de développement, pas en fin de recette

Le bénéfice économique

Le coût de correction d'un défaut d'accessibilité croît avec le nombre d'écrans qui en dépendent. Le traiter au niveau du design system divise ce coût par le nombre d'écrans concernés, parfois par centaines.

Un exemple concret de propagation

Un bouton de formulaire mal contrasté, validé une seule fois dans le design system, se retrouve ensuite reproduit sur chaque écran qui l'utilise : page de connexion, tunnel de paiement, formulaire de contact, espace client. Le corriger à la source règle instantanément tous ces écrans. Le corriger écran par écran, une fois le produit en production, demande de retrouver chaque occurrence, de vérifier qu'aucune variante locale n'a été introduite entre-temps, puis de retester chacune individuellement. La différence de charge n'est pas linéaire, elle est multipliée par le nombre d'écrans concernés.

C'est ce même raisonnement qui justifie de traiter l'accessibilité au niveau du design system plutôt qu'écran par écran : un investissement ponctuel à la source, plutôt qu'une dette qui se paie autant de fois qu'il y a d'écrans.

Un audit RGAA en fin de projet mesure des symptômes. Une architecture pensée pour l'accessibilité en traite la cause.

C'est cette approche que je mets en œuvre dans mon audit RGAA : traiter l'accessibilité comme une architecture, pas comme une correction de fin de projet.

---

Pour aller plus loin : pourquoi l'accessibilité par conception coûte moins cher que la mise en conformité tardive