Un bloc « Carrousel de témoignages » corrigé sur la marque A reste-t-il cassé sur les cinq autres, si personne ne synchronise les correctifs ? C’est le risque concret d’une bibliothèque de 300 composants Gutenberg partagée entre plusieurs sites de marques différentes, construits sur le même socle technique mais avec des habillages visuels propres à chacune.
Ce texte ne traite pas de la charte graphique propre à chaque marque, mais de la méthode de vérification centralisée qui garantit un socle d’accessibilité commun, indépendamment des déclinaisons visuelles appliquées ensuite site par site.
Séparer ce qui relève de la structure de ce qui relève du style
La première étape d’un audit centralisé consiste à distinguer, pour chaque composant, ce qui appartient à sa structure HTML et à son comportement JavaScript (commun à toutes les marques) de ce qui relève de sa présentation CSS (propre à chaque marque). Un carrousel accessible au clavier reste accessible quelle que soit la couleur de ses flèches de navigation ; un carrousel qui piège le focus reste défaillant sur les six marques à la fois.
Cette séparation permet de concentrer l’audit d’accessibilité sur le socle structurel, testé une seule fois, plutôt que sur chaque déclinaison visuelle, qui multiplierait le travail par le nombre de marques sans apporter d’information nouvelle sur la structure.
Le cas des variantes de contraste
Une exception notable concerne les palettes de couleurs, différentes par marque : chaque marque doit tout de même valider séparément ses propres ratios de contraste, puisque la structure ne garantit rien sur ce point précis. Un tableau de correspondance entre composants et palettes, mis à jour à chaque nouvelle marque intégrée, évite d’oublier cette vérification spécifique.
Constituer un catalogue de tests de non-régression par composant
Pour chacun des 300 composants, un jeu de tests minimal couvre la navigation clavier complète, le comportement des lecteurs d’écran sur les états dynamiques (ouverture, fermeture, changement d’onglet) et la présence des attributs ARIA attendus. Ce catalogue, versionné avec le code du socle, devient la référence unique consultée par les six équipes de marque.
// composants/carrousel-temoignages/tests-a11y.md
- [ ] Flèches précédente/suivante atteignables au clavier
- [ ] Focus visible sur chaque élément interactif du carrousel
- [ ] Pause automatique du défilement au focus ou au survol
- [ ] Annonce du numéro de diapositive courante via aria-live
- [ ] Aucun piège de focus lors du changement de diapositive
Organiser un audit par vague plutôt qu’un audit unique
Auditer 300 composants d’un seul bloc représente plusieurs mois de travail continu, difficilement compatible avec le rythme de production des équipes. Découpez l’audit par familles fonctionnelles : navigation, formulaires, contenus médias, mise en avant commerciale, puis publiez les résultats famille par famille au fur et à mesure.
- Une famille de composants auditée et corrigée avant de passer à la suivante
- Un score de conformité affiché par composant dans le catalogue interne
- Des tickets de correction rattachés au composant, pas à une marque en particulier
Gérer la dérive : quand une marque modifie un composant partagé
Le risque principal d’un socle mutualisé est la dérive silencieuse : une équipe de marque copie un composant partagé pour l’adapter localement, sans remonter la modification au socle commun. Ce fork local échappe alors à tous les audits et correctifs ultérieurs appliqués au composant d’origine.
Un socle partagé sans processus de contribution retour finit toujours par se fragmenter en autant de versions divergentes que de marques, chacune avec ses propres régressions d’accessibilité non détectées.
Mettez en place une règle simple : toute adaptation d’un composant partagé passe par une proposition de modification sur le dépôt central, même si elle ne concerne qu’une marque dans un premier temps. Les autres marques héritent ainsi automatiquement du correctif ou de l’amélioration, sans audit supplémentaire de leur côté.
Communiquer les résultats aux équipes de marque
Un rapport d’audit technique n’a de valeur que s’il est traduit en actions compréhensibles par les équipes qui ne touchent pas directement le code du socle. Un tableau de bord simple, listant les composants conformes, ceux en cours de correction et ceux non encore audités, suffit largement à faire vivre la démarche dans la durée.
En résumé
Auditer une bibliothèque de composants partagée entre plusieurs marques consiste à séparer structure et présentation, à constituer un catalogue de tests par composant plutôt que par site, et à empêcher toute dérive locale non remontée vers le socle commun.
