« Le RGAA a pour objet de rendre accessible tout support numérique aux personnes en situation de handicap », rappelle le référentiel officiel publié par la direction interministérielle du numérique. Cette exigence, obligatoire pour les sites publics, devient un poste de coût récurrent pour une agence qui livre le même type de thème, décliné, à plusieurs collectivités : sans architecture partagée, chaque nouveau site repart d’un audit complet, alors que la structure sous-jacente reste souvent identique d’un projet à l’autre.
Ce chantier ne concerne pas l’accessibilité d’un site construit avec l’éditeur de site et des gabarits theme.json, dont les mécanismes de validation diffèrent. Il porte sur des thèmes classiques déclinés pour plusieurs collectivités, où l’enjeu est de ne certifier le socle structurel qu’une seule fois.
Le principe : séparer le socle structurel de la déclinaison locale
Un thème parent unique porte tout ce qui relève de la structure et du comportement : navigation au clavier, contrastes de base, structure de titres, gestion du focus visible, formulaires accessibles. Chaque collectivité reçoit un thème enfant qui ne touche que ce qui lui est propre : couleurs de la charte graphique locale, logo, contenu. Cette séparation garantit qu’un audit RGAA mené sur le thème parent reste valable, sur les critères structurels, pour chaque déclinaison qui en hérite sans modifier ce socle.
L’arborescence qui porte cette séparation
theme-parent-collectivites/
├── functions.php (navigation clavier, focus, structure ARIA)
├── template-parts/
│ ├── header.php (menu accessible, testé au clavier)
│ └── formulaire-contact.php (labels, messages d'erreur associés)
├── assets/css/base.css (contrastes minimums garantis)
└── ACCESSIBILITE.md (liste des critères validés sur ce socle)
theme-ville-alpha/
├── style.css (Template: theme-parent-collectivites)
└── assets/css/couleurs-alpha.css (respecte les contrastes minimums du socle)
theme-ville-beta/
├── style.css (Template: theme-parent-collectivites)
└── assets/css/couleurs-beta.css
Ce que le socle doit garantir, une fois pour toutes
- Une hiérarchie de titres cohérente, générée par les gabarits du parent, jamais laissée à la main du rédacteur pour la structure globale de page.
- Une navigation entièrement utilisable au clavier, avec un indicateur de focus visible sur chaque élément interactif.
- Des formulaires dont chaque champ est associé à un
<label>explicite et dont les messages d’erreur sont annoncés correctement. - Un contraste minimal garanti par défaut, indépendant des couleurs propres à chaque collectivité.
Le point de vigilance : les couleurs locales ne doivent jamais casser le contraste garanti
La liberté laissée à chaque collectivité sur ses couleurs de marque est la faille la plus fréquente de cette architecture : une couleur d’accent choisie localement, appliquée sur un bouton ou un lien, peut faire chuter le contraste sous le seuil requis par le RGAA, même si le socle du thème parent respecte parfaitement ce critère. La solution consiste à documenter, dans le socle, une plage de luminosité acceptable pour chaque token de couleur personnalisable, et à vérifier chaque nouvelle déclinaison avec un outil de mesure de contraste avant mise en production.
Un contrôle simple à intégrer avant chaque livraison
Contraste minimum requis (texte normal) : 4.5:1
Contraste minimum requis (texte large) : 3:1
Vérification : couleur d'accent de la collectivité
sur fond blanc et sur fond de la charte locale.
Ce que l’audit ciblé remplace, projet après projet
Avec cette architecture en place, chaque nouvelle collectivité ne nécessite plus un audit RGAA complet, mais une vérification ciblée sur les seuls éléments qu’elle personnalise : couleurs, logo, éventuel contenu additionnel spécifique. Le gain de temps se mesure directement en heures d’audit non refacturées à chaque nouveau projet, tout en maintenant un niveau de conformité identique d’un site à l’autre.
Un socle d’accessibilité qui ne peut pas être modifié par une déclinaison locale est plus fiable qu’une checklist répétée à chaque livraison : il élimine la possibilité même de l’oubli.
Ce qu’il faut retenir
Industrialiser l’accessibilité d’un thème livré à plusieurs collectivités ne consiste pas à répéter le même audit à chaque projet, mais à isoler ce qui garantit la conformité dans un socle non modifiable, pour ne vérifier ensuite que ce qui varie réellement d’une déclinaison à l’autre. Cette architecture réduit le coût de conformité sur la durée, tout en rendant plus difficile la régression accidentelle d’un critère déjà validé.
