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.
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.
