Un audit RGAA complet compte plusieurs centaines de critères. Un nouvel arrivant qui découvre le sujet le jour de son premier commit n’a besoin d’en connaître aucun par cœur : il a besoin de huit réflexes simples qui, à eux seuls, évitent la grande majorité des erreurs qu’on retrouve chez un développeur WordPress débutant sur le sujet.
Cette checklist n’a pas vocation à remplacer une formation approfondie aux référentiels légaux, qui reste indispensable pour un responsable technique amené à valider une déclaration de conformité. Elle sert d’antidote immédiat aux erreurs les plus fréquentes, applicable dès le premier jour, sans prérequis.
Les vérifications à intégrer avant chaque commit
- Chaque image porte un attribut
alt. Vide si l’image est purement décorative, renseigné et pertinent sinon. Une image sansaltdu tout est pire qu’unaltvide. - Les titres suivent une hiérarchie logique. Pas de
<h3>qui apparaît sans<h2>avant lui dans la page, et jamais deux<h1>sur un même gabarit. - Tout élément cliquable est un vrai
<button>ou un vrai<a href>. Jamais un<div onclick>, même stylé pour ressembler à un bouton. - Chaque champ de formulaire a un
<label>associé viaforetid, ou englobant, jamais un simple placeholder qui disparaît à la saisie.
La suite de la liste, tout aussi indispensable
- Le contraste texte/fond respecte 4,5:1 pour le texte courant, 3:1 pour le texte large ; un vérificateur de contraste dans les outils de développement du navigateur suffit à ce stade.
- Le site reste utilisable en navigant uniquement au clavier, tabulation et touche Entrée, sans jamais toucher la souris, sur chaque nouveau composant livré.
- Le focus clavier reste toujours visible, jamais masqué par un
outline: nonesans style de remplacement équivalent. - Aucun contenu ne clignote ni ne défile automatiquement sans contrôle pour l’arrêter, mettre en pause ou le masquer.
Comparé à une checklist RGAA complète qui couvre l’ensemble des 106 critères du référentiel français, cette liste de huit points ne prétend traiter qu’une fraction du sujet. Mais c’est précisément cette fraction qui représente, sur nos retours d’expérience internes, la très grande majorité des anomalies détectées chez un développeur qui découvre l’accessibilité.
Comment l’intégrer concrètement à la routine
Une checklist affichée quelque part dans un espace documentaire interne ne sert à rien si personne ne la consulte au bon moment. Les formats qui fonctionnent le mieux, sur nos équipes :
- Un modèle de description de pull request qui reprend les huit points sous forme de cases à cocher
- Une extension de navigateur d’audit rapide (type axe DevTools) installée par défaut sur le poste du nouvel arrivant dès son premier jour
- Un exercice pratique de trente minutes en semaine 1 : naviguer un gabarit existant du site au clavier uniquement, sans souris, et noter ce qui bloque
Cet exercice pratique produit systématiquement plus de prise de conscience qu’une heure de présentation théorique sur les référentiels, parce qu’il confronte immédiatement le nouvel arrivant à une expérience qu’il n’avait probablement jamais vécue avant.
Ce qu’on ne met volontairement pas dans cette liste
La rédaction d’une déclaration d’accessibilité, la conduite d’un audit externe, ou la compréhension fine des niveaux A, AA et AAA du WCAG relèvent d’une formation ultérieure, pas d’un onboarding de premier jour. Surcharger la liste initiale de ces sujets produirait l’effet inverse de celui recherché : une checklist trop longue n’est jamais suivie, une checklist courte et concrète devient un réflexe.
En résumé
Ces huit points ne remplacent ni une culture d’accessibilité construite dans la durée, ni la responsabilité du responsable technique sur la conformité légale du site. Ils donnent en revanche à un nouvel arrivant un filet de sécurité immédiat, applicable dès son premier commit, avant même qu’il ait suivi la moindre formation dédiée au sujet.
Sur nos équipes, on relit cette liste avec chaque nouvel arrivant au bout d’un mois, pas seulement le premier jour : c’est souvent à ce moment-là, une fois les réflexes de base pris sur le vif d’un vrai projet, que les questions les plus utiles remontent naturellement, et qu’on peut commencer à élargir la discussion vers des sujets plus larges comme les référentiels légaux ou la conduite d’un audit complet.
