RGAA : par où commencer pour un site conforme

« On sait qu’il faut s’y mettre, mais on ne sait pas par où commencer. » C’est la phrase qui revient dès qu’on parle d’accessibilité numérique, et elle est légitime : le RGAA compte 106 critères répartis en treize thématiques, et le lire d’un bout à l’autre n’est pas une façon de démarrer.

La bonne nouvelle, c’est qu’une petite partie du référentiel explique la grande majorité des blocages réels rencontrés par les internautes. Voici l’ordre dans lequel nous attaquons le sujet, et ce qu’il faut savoir avant de commencer.

D’abord : qui est concerné, et par quoi

En France, l’obligation d’accessibilité des sites vient de l’article 47 de la loi du 11 février 2005, précisé par le décret de 2019. Elle s’applique aux services de l’État, aux collectivités, aux établissements publics et aux organismes chargés d’une mission de service public — ainsi qu’aux entreprises privées dont le chiffre d’affaires dépasse un seuil élevé. Le non-respect des obligations de publication expose à une sanction administrative renouvelable, dont le plafond a été relevé en 2023.

À cela s’ajoute, depuis le 28 juin 2025, l’application de la directive européenne sur l’accessibilité (souvent appelée European Accessibility Act) à de nombreux services destinés aux consommateurs : commerce en ligne, banque, transport, livres numériques. Autrement dit : le sujet a cessé d’être une affaire de secteur public.

Le référentiel technique, lui, est le RGAA, qui est la déclinaison française des règles internationales WCAG 2.1 niveau AA. Travailler pour le RGAA, c’est travailler pour les WCAG : il n’y a pas deux chantiers.

Trois obligations documentaires, souvent oubliées

Beaucoup d’organisations travaillent leur site sans produire les documents attendus — alors que ce sont eux qui sont contrôlés en premier, parce qu’ils sont publics et immédiatement vérifiables :

• Une déclaration d’accessibilité, accessible depuis le site, qui annonce l’état réel : non conforme, partiellement conforme ou totalement conforme, avec le taux obtenu et la liste des contenus non conformes.
• Un schéma pluriannuel de mise en accessibilité, décliné en plans d’action annuels.
• La mention du niveau d’accessibilité sur la page d’accueil, avec un lien vers la déclaration.

Un point qui rassure souvent nos interlocuteurs : « partiellement conforme » est un état déclarable et parfaitement assumable. Annoncer honnêtement un taux et un plan d’action vaut infiniment mieux que se taire — ou que revendiquer une conformité totale invérifiable. Notre propre déclaration d’accessibilité suit cette logique.

Les cinq chantiers qui règlent le plus de problèmes

Si vous ne faites que cinq choses, faites celles-là. Elles couvrent l’essentiel des obstacles concrets, et elles sont à la portée d’une équipe qui n’est pas spécialiste.

1. Les contrastes. Texte courant contre son fond : rapport minimal de 4,5 pour 1, et 3 pour 1 pour les grands titres. C’est le critère le plus fréquemment en échec, et le seul qui se corrige entièrement dans la charte graphique — avant la première ligne de code. Attention aux gris clairs sur fond blanc, aux textes posés sur des photos et aux boutons dont l’état survolé perd du contraste.
2. Les alternatives textuelles. Chaque image porteuse d’information a besoin d’une alternative qui transmet cette information ; chaque image décorative a besoin d’une alternative vide, pour être ignorée. « Photo », « image1.jpg » ou le nom du fichier ne sont pas des alternatives.
3. La structure de titres. Un seul H1, puis une hiérarchie H2/H3 continue, sans niveau sauté et sans titre choisi pour sa taille. C’est le plan du document : c’est ainsi qu’un lecteur d’écran permet de parcourir une page, comme vous parcourez un sommaire.
4. Le clavier. Tout ce qui est cliquable doit être atteignable et actionnable à la touche Tab, dans un ordre logique, avec un focus visible. Le contour de focus supprimé en CSS parce qu’il « fait sale » est l’une des régressions les plus courantes — et l’une des plus handicapantes.
5. Les formulaires. Chaque champ a une étiquette visible et associée, les champs obligatoires sont annoncés autrement que par une couleur, et les messages d’erreur disent quoi corriger, à côté du champ concerné.

Le test de cinq minutes

Avant tout audit, il existe un test que n’importe qui peut faire : posez la souris et parcourez votre page d’accueil uniquement au clavier. Tab pour avancer, Entrée pour activer. Trois questions suffisent : est-ce que je vois toujours où je suis ? ; est-ce que je peux atteindre le menu, la recherche et le formulaire ? ; est-ce que je me retrouve piégé quelque part, typiquement dans une fenêtre modale ou un carrousel ?

Si la réponse est non à l’une des trois, vous connaissez déjà votre premier chantier — et il pèse plus lourd que la moitié du référentiel.

Les outils : utiles, mais partiels

Les extensions de navigateur d’analyse automatique et les rapports d’audit intégrés aux navigateurs font gagner du temps : ils repèrent les contrastes insuffisants, les alternatives manquantes, les erreurs de structure. Utilisez-les, ils sont gratuits.

Mais ils ne détectent qu’une partie des critères du RGAA. Tout ce qui relève du sens échappe à l’automatisation : une alternative textuelle peut être présente et inutile, un ordre de tabulation peut être valide et incompréhensible, un composant peut être techniquement correct et impraticable. Le reste se vérifie à la main, au clavier, et avec un lecteur d’écran.

Ce qu’il ne faut pas faire : installer une surcouche

On vous proposera un script à ajouter à votre site, avec un petit bouton flottant promettant la conformité en une ligne de code. Notre position est nette : ces surcouches ne rendent pas un site conforme. Elles n’ont aucun effet sur les critères du référentiel, qui portent sur le code de vos pages ; un audit RGAA les traverse sans les voir. Dans le meilleur des cas, elles ajoutent une préférence de contraste que le système d’exploitation du visiteur gère déjà mieux qu’elles.

L’accessibilité n’est pas une case à cocher en fin de projet : c’est une contrainte de conception, au même titre que le mobile.

Les angles morts : PDF, vidéos, composants riches

• Les documents PDF. Ils font partie du périmètre. Un rapport annuel exporté sans structure de titres ni ordre de lecture est un contenu inaccessible, même sur un site irréprochable. La question à trancher est souvent : ce document doit-il rester un PDF, ou devenir une page web ?
• Les vidéos. Sous-titres pour l’audio, et transcription pour ce qui est purement visuel. Les sous-titres automatiques sont un point de départ à relire, jamais un livrable.
• Les composants riches — carrousels, accordéons, onglets, fenêtres modales, menus déroulants. C’est là que se concentrent les échecs, et souvent à cause d’attributs ARIA ajoutés au hasard. Un composant sans ARIA mais utilisable au clavier vaut mieux qu’un composant couvert d’attributs qui mentent au lecteur d’écran.

La partie qu’on oublie toujours : les contributeurs

Un site livré conforme se dégrade au fil des publications. Le premier PDF non balisé, la première image sans alternative, le premier « cliquez ici », le premier titre choisi parce qu’il était à la bonne taille : la conformité s’érode par le contenu, pas par le code.

C’est pourquoi nous considérons la formation des personnes qui éditent le site comme une partie du chantier d’accessibilité, et pas comme une option de fin de projet. Une demi-journée et une fiche de rappel de dix lignes suffisent à changer durablement la trajectoire.

Par où commencer, concrètement

1. Faire le test au clavier sur trois pages clés : accueil, page de contenu, formulaire.
2. Corriger les contrastes dans la charte, une fois pour tout le site.
3. Reprendre la structure de titres et les alternatives des gabarits, puis des pages les plus consultées.
4. Rendre le focus visible et vérifier les composants interactifs.
5. Faire auditer un échantillon de pages représentatif, puis publier la déclaration d’accessibilité avec le taux réel.
6. Écrire le schéma pluriannuel : ce qui est corrigé, ce qui est planifié, quand.
7. Former les contributeurs, et intégrer la vérification d’accessibilité à la recette de chaque évolution.

Cet ordre a une logique : il commence par ce qui coûte le moins et bénéficie au plus grand nombre, et il évite le piège classique du projet d’accessibilité — vouloir tout traiter d’un coup, et ne rien livrer.

Besoin d’un point de départ ?

Nous réalisons des audits d’accessibilité RGAA avec un rapport priorisé, la déclaration à publier, et l’accompagnement des équipes. Pour les organisations publiques, l’accessibilité est traitée dès la réponse à la consultation : voir nos pages marchés publics et notre article sur notre méthode de réponse aux appels d’offres.

Un doute sur l’état de votre site ? Écrivez-nous via la page contact : nous regardons quelques pages et vous disons où vous en êtes, sans vendre un audit complet à qui n’en a pas encore besoin.