# Éditeur de site pour collectivité : bilan RGAA après cinq ans de templates

> Cinq ans d'audits RGAA sur des sites publics en éditeur de site font ressortir les mêmes points de blocage. Retour critique sur ce qui revient le plus souvent, template après template.

- Auteur : Clément Hadrot
- Publié le : 2026-07-08
- Mis à jour le : 2026-07-08
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/bilan-rgaa-cinq-ans-templates-fse/

## L’essentiel

- Le contraste des palettes de theme.json reste le point le plus souvent signalé
- La navigation clavier de la Query Loop paginée pose problème sur près d'un site sur deux
- Les images de fond du bloc Cover manquent presque toujours d'alternative

Combien de fois un même point de blocage doit-il apparaître dans un rapport d'audit avant de devenir un vrai sujet de fond plutôt qu'un oubli isolé ? Après cinq ans d'audits RGAA menés sur des sites publics de collectivités construits en éditeur de site, la réponse est sans appel : trois motifs reviennent, presque systématiquement, indépendamment du thème bloc utilisé ou de l'agence qui l'a développé.

Ce bilan ne prétend pas se substituer à un tutoriel RGAA complet, ni détailler les obligations légales qui pèsent sur les sites publics : il se concentre sur ce que l'expérience répétée d'audits révèle comme points de friction structurels, propres à la manière dont l'éditeur de site construit ses templates.

## Premier point récurrent : le contraste des palettes de theme.json

La palette de couleurs déclarée dans `theme.json` est presque toujours pensée du point de vue de l'identité visuelle avant celui du contraste réel. Une couleur d'accent choisie pour son impact graphique se retrouve régulièrement appliquée à du texte sur fond clair, avec un ratio de contraste insuffisant au regard du critère RGAA correspondant, sans qu'aucune alerte ne remonte au moment de la conception, l'éditeur de site ne vérifiant pas nativement la conformité des combinaisons de couleurs choisies dans les styles globaux.

## Deuxième point récurrent : la navigation clavier de la Query Loop paginée

Sur près d'un site sur deux audités, la pagination d'une Query Loop, qu'elle soit générée nativement par le bloc `core/query-pagination` ou enrichie d'une interactivité côté client, présente un ordre de tabulation qui saute des éléments ou un focus visuel insuffisamment marqué après un changement de page. Le clavier permet techniquement d'atteindre les liens de pagination, mais le retour visuel du focus, ou l'annonce du changement de contenu pour un lecteur d'écran, fait presque toujours défaut sans intervention manuelle spécifique.

> L'essentiel à retenir : Le contraste des palettes de theme.json reste le point le plus souvent signalé ; La navigation clavier de la Query Loop paginée pose problème sur près d'un site sur deux ; Les images de fond du bloc Cover manquent presque toujours d'alternative

## Troisième point récurrent : les images de fond du bloc Cover

Le bloc `core/cover`, très utilisé pour les bannières d'en-tête de page, applique son image en arrière-plan CSS plutôt qu'en balise `img` classique dans une bonne partie des configurations rencontrées. Quand cette image porte une information (visuel d'un événement, illustration d'un dispositif public), l'absence d'alternative textuelle associée reste un manque quasi systématique, l'éditeur ne forçant à aucun moment la saisie d'un texte alternatif pour ce type d'usage.

## Ce qui s'est amélioré sur la période

Tous les constats ne sont pas négatifs. Le bloc `core/navigation`, dans ses versions les plus récentes, a nettement progressé sur la structuration sémantique de ses menus, avec des rôles ARIA correctement posés par défaut. La gestion des landmarks de page (en-tête, contenu principal, pied de page) via les parties de template s'est également largement standardisée, la plupart des thèmes blocs récents respectant désormais une hiérarchie de sectionnement correcte sans intervention supplémentaire.

### Un point resté stable, ni amélioré ni dégradé

La hiérarchie des titres au sein des patterns composés reste un point à surveiller systématiquement : un pattern conçu isolément commence souvent par un `<h2>`, sans tenir compte du niveau de titre déjà utilisé plus haut dans la page une fois assemblé, un défaut de conception qui ne dépend d'aucune version particulière de l'éditeur mais de la discipline de l'équipe qui compose la page finale.

## Ce que ces trois points ont en commun

- Aucun des trois n'est bloquant au sens strict : le site reste utilisable, mais l'expérience se dégrade fortement pour une partie des usagers.
- Aucun des trois n'est détecté automatiquement par l'éditeur de site lui-même, qui ne procède à aucune vérification de conformité au moment de la construction du template.
- Les trois se corrigent une fois identifiés, mais reviennent presque systématiquement sur le projet suivant si aucune checklist de vérification n'est intégrée au processus de livraison.

> Sur cinq ans d'audits, le motif le plus révélateur n'est pas la difficulté technique de ces corrections, toujours modeste, mais leur récurrence : c'est un problème de processus de livraison, pas de compétence technique isolée.

## En résumé

Ce bilan critique ne remplace ni un tutoriel RGAA pas à pas, ni le détail des obligations légales applicables aux sites publics, deux sujets traités ailleurs de façon plus exhaustive. Il met en évidence une réalité simple après cinq ans d'observation répétée : l'éditeur de site facilite la construction rapide de templates, mais ne garantit en rien leur conformité, et les mêmes trois points continuent de réapparaître tant qu'aucune vérification systématique n'est intégrée avant chaque mise en production.
