106 critères composent le référentiel RGAA 4.1. Une bonne moitié ne dépend ni du contenu rédigé par l’agent territorial, ni du plugin de formulaire installé plus tard : ils se jouent dans le thème lui-même, avant même que le site ne soit rempli. Livrer un thème classique à une collectivité sans avoir balayé ces points, c’est transférer la dette d’accessibilité à un client qui n’a souvent ni le budget ni les compétences pour la corriger après coup.
Cette liste ne remplace pas un audit RGAA complet réalisé par un expert accessibilité, ni les obligations légales qui pèsent sur l’organisme (déclaration de conformité, schéma pluriannuel). Elle couvre uniquement ce qu’un développeur peut et doit vérifier lui-même dans le code d’un thème avant la recette.
Structure de titres et hiérarchie
Le critère 9.1 du RGAA impose une hiérarchie de titres pertinente. Dans un thème classique, cela se contrôle gabarit par gabarit :
- Un seul
<h1>par page, généré par le titre de l’article ou de la page, jamais par le logo du site. - Pas de saut de niveau : un
<h2>ne doit jamais être suivi directement d’un<h4>dans le balisage du thème (widgets, template parts). - Les titres de widgets (
the_widget_title) doivent rester dans la hiérarchie du gabarit, pas systématiquement en<h2>quelle que soit leur position.
Contraste et couleurs codées en dur
Le critère 3.2 fixe un ratio minimal de 4,5:1 pour le texte courant et 3:1 pour les grands textes. Sur un thème de collectivité, trois zones sont systématiquement oubliées lors des tests visuels rapides : le texte des placeholders de formulaire, la couleur des liens visités dans le corps de texte, et les états :focus des boutons quand ils reprennent la couleur d’accent de la charte graphique sans l’assombrir suffisamment. Un contrôleur de contraste appliqué sur chaque couple couleur de texte / couleur de fond défini dans le style.css du thème permet de lever la majorité de ces problèmes avant la mise en ligne.
Focus visible et navigation clavier
Le critère 10.7 exige qu’un élément recevant le focus soit visuellement identifiable. Beaucoup de thèmes appliquent une règle *:focus { outline: none; } pour « nettoyer » l’apparence des boutons, ce qui viole ce critère de manière quasi systématique. La correction ne consiste pas à supprimer l’outline mais à le redessiner de façon cohérente avec la charte :
a:focus-visible,
button:focus-visible,
input:focus-visible {
outline: 3px solid #1a4d8f;
outline-offset: 2px;
}
Testez ensuite chaque gabarit uniquement au clavier (Tab, Maj+Tab, Entrée) : menu principal, formulaire de recherche, footer avec ses liens légaux. Un menu qui ne s’ouvre qu’au survol de la souris, sans équivalent clavier, bloque totalement l’accès aux sous-pages pour un usager qui ne peut pas utiliser de pointeur.
Formulaires et messages d’erreur
Sur les gabarits de contact ou de recherche fournis par le thème, chaque champ doit avoir une étiquette associée via <label for="">, jamais un simple placeholder qui disparaît à la saisie. Les messages d’erreur générés par le thème (recherche sans résultat, champ requis) doivent être annoncés aux technologies d’assistance, par exemple via un attribut role="alert" sur le conteneur de message plutôt que par une simple classe CSS qui change une couleur de bordure.
Images et médias du thème
Les images purement décoratives intégrées dans les gabarits (bandeaux, motifs de fond) doivent porter un alt="" vide et non un attribut absent, pour être correctement ignorées par les lecteurs d’écran. À l’inverse, les images porteuses de sens injectées par le thème (logo, pictogrammes de navigation) ont besoin d’un texte alternatif pertinent, configurable depuis l’administration plutôt que codé en dur dans le PHP du thème.
Zoom texte et responsive
Le critère 10.4 impose qu’un zoom texte jusqu’à 200 % n’entraîne ni perte de contenu ni de fonctionnalité. Beaucoup de thèmes de collectivité utilisent des hauteurs fixes en pixels sur les cartes d’actualités ou les blocs d’accès rapide de la page d’accueil : à 200 % de zoom, le texte déborde et devient illisible. Remplacer les height fixes par des min-height, et les tailles de police en px par des unités relatives (rem), règle la plupart de ces cas avant qu’ils ne remontent en recette.
En résumé
Aucun de ces points ne remplace un audit RGAA formel, mais les traiter en amont dans le thème évite à la collectivité de découvrir, au moment de la déclaration de conformité obligatoire, qu’une bonne partie du travail reste à refaire sur un gabarit déjà en production. Une checklist courte, passée gabarit par gabarit avant la recette finale, coûte largement moins cher qu’une reprise après mise en ligne.
