Site public en recette : la checklist RGAA 4.1 la plus utile juste avant mise en ligne

La recette technique d’un site de collectivité territoriale, livrée trois jours avant l’échéance contractuelle, a fait remonter dix-sept anomalies liées à l’accessibilité sur un thème classique pourtant conçu dès le départ avec les bonnes intentions. Sur ces dix-sept anomalies, huit points de contrôle en concentraient plus de la moitié — de quoi construire une checklist resserrée, réutilisable sur le prochain projet du même type.

Cette liste ne prétend pas remplacer un audit RGAA (Référentiel Général d’Amélioration de l’Accessibilité, version 4.1) complet mené par un expert accrédité, obligatoire pour la déclaration de conformité officielle d’un site public. Elle sert de filet de sécurité pour un développeur en dernière ligne droite avant recette, afin d’écarter les anomalies les plus fréquentes et les plus coûteuses à corriger une fois le site en production.

Les huit points de contrôle prioritaires

1. Contraste de texte insuffisant — vérifier chaque combinaison texte/fond avec un outil de mesure de contraste, seuil minimal de 4,5:1 pour le texte courant, 3:1 pour le texte large
2. Focus clavier invisible — parcourir l’intégralité du site à la touche Tab, sans souris, et confirmer qu’un contour visible entoure systématiquement l’élément actif
3. Hiérarchie de titres incohérente — un <h2> qui suit directement un <h4> sans niveau intermédiaire trompe les technologies d’assistance qui s’appuient sur cette structure pour la navigation
4. Images sans texte alternatif pertinent — un attribut alt vide n’est pas une erreur en soi pour une image décorative, mais un alt absent ou redondant avec la légende voisine en est une
5. Liens au libellé non explicite hors contexte — un lien « cliquez ici » ou « en savoir plus » répété plusieurs fois sur une page ne permet pas de distinguer sa destination à l’écoute d’un lecteur d’écran
6. Formulaires sans étiquette associée — chaque champ doit avoir un élément <label> lié par l’attribut for, pas seulement un texte de substitution visuel proche du champ
7. Alertes visuelles fondées uniquement sur la couleur — un message d’erreur affiché seulement en rouge, sans icône ni texte, reste invisible pour un utilisateur daltonien ou non-voyant
8. Zoom texte à 200 % qui casse la mise en page — tester l’agrandissement du texte du navigateur à 200 % et vérifier qu’aucun contenu ne devient inaccessible ou tronqué

Pourquoi ces huit points concentrent l’essentiel des anomalies

Ces points ont un point commun : ils sont invisibles à l’œil nu pour un développeur qui teste son site à la souris, avec une vue non affectée, sur un écran standard. Le contraste insuffisant, par exemple, se remarque rarement sans outil de mesure dédié — l’œil s’habitue naturellement à un gris clair sur blanc qui, mesuré, tombe pourtant sous le seuil réglementaire.

Sur ce thème de collectivité, le cas le plus fréquent concernait des liens de couleur gris moyen sur fond blanc dans le pied de page, avec un ratio de contraste mesuré à 3,8:1, sous le seuil de 4,5:1 requis pour du texte courant. Le correctif a consisté à foncer légèrement la teinte, sans changer la charte graphique de façon perceptible pour un visiteur non concerné par ce test.

Outils utilisés pour ce contrôle rapide

Aucun de ces huit contrôles ne nécessite d’outil payant. La navigation au clavier se teste directement dans le navigateur. Le contraste se mesure avec l’inspecteur d’accessibilité intégré aux outils de développement des navigateurs modernes, ou une extension dédiée. La hiérarchie de titres se vérifie avec une extension de plan de page qui liste tous les titres <h1> à <h6> d’une page dans leur ordre d’apparition, faisant immédiatement ressortir un saut de niveau anormal.

Ce que cette checklist ne couvre volontairement pas

Un audit RGAA complet, tel qu’exigé pour la déclaration d’accessibilité officielle d’un site de collectivité, porte sur cent six critères répartis en treize thématiques, avec un échantillon de pages représentatif et des tests par des outils spécialisés ainsi que, idéalement, des retours d’utilisateurs concernés. Cette checklist de huit points ne prétend couvrir qu’une fraction de ce périmètre : elle sert à éliminer les anomalies les plus fréquentes et les moins coûteuses à corriger avant recette, pas à établir une conformité légale.

Une checklist de dernière ligne droite corrige les anomalies évidentes ; elle ne remplace jamais l’audit accrédité exigé pour la déclaration d’accessibilité d’un site public.

Correctif type pour la hiérarchie de titres

Le cas de la hiérarchie de titres mérite un exemple concret, car il touche directement la structure du template de thème plutôt qu’une simple valeur CSS. Le template de page d’actualité affichait, à l’origine, le titre de l’article en <h3> (pour des raisons purement esthétiques, un <h1> paraissant « trop gros » au regard de la maquette), directement sous un <h1> de bandeau de page. La correction a séparé les deux préoccupations : le niveau de titre reste sémantiquement correct (<h2> pour le titre d’article), et l’apparence visuelle souhaitée est obtenue par une classe CSS dédiée, sans toucher au niveau HTML du titre.

Pour aller plus loin

Une fois ces huit points vérifiés et corrigés, l’étape suivante logique reste la commande d’un audit RGAA 4.1 complet par un organisme accrédité, seule voie qui permette à la collectivité de publier une déclaration d’accessibilité conforme à ses obligations légales. Cette checklist réduit le nombre d’anomalies que cet audit externe relèvera, sans s’y substituer.