Accessibilité web RGAA : les 8 règles de base à respecter minimum en 2026

En dix ans de freelance, j ai vu l accessibilité web passer du « truc sympa mais optionnel » au sujet juridique incontournable. Depuis l entrée en vigueur de la directive européenne sur l accessibilité (European Accessibility Act) et la montée en version du RGAA aligné sur les WCAG 2.2, ignorer ces règles expose à des sanctions financières et, surtout, exclut une partie de vos utilisateurs. Je ne suis pas auditeur RGAA certifié, mais en tant que développeur WordPress qui livre des sites conformes, je connais les 8 règles de base qui couvrent la majorité des critères. Voici mon guide pratique, testé sur de vrais projets clients.

Pourquoi le RGAA concerne tous les sites en 2026

Le RGAA (Référentiel Général d Amélioration de l Accessibilité) est le cadre français qui traduit les Web Content Accessibility Guidelines (WCAG) en critères testables. Il est maintenu par la DINUM et publié sur le site officiel du RGAA. Jusqu à récemment, seuls les sites publics et les grandes entreprises (plus de 250 millions d euros de chiffre d affaires) étaient formellement obligés de s y conformer. Mais le calendrier s accélère.

Avec la transposition de la directive européenne EAA en droit français, les sites e-commerce, les applications bancaires et les services de transport sont désormais concernés depuis juin 2025. Les sanctions prévues par l article 47 de la loi du 11 février 2005 peuvent atteindre 50 000 euros par an et par service non conforme pour les opérateurs privés. Ce n est plus un risque théorique.

Concrètement, même si vous êtes freelance et que vous livrez un site vitrine pour un artisan, appliquer les 8 règles de base est un geste professionnel qui protège votre client et améliore l expérience de tous les utilisateurs. Un site accessible est aussi un site mieux référencé : Google valorise la structure sémantique, les alternatives textuelles et la navigabilité clavier, ce qui rejoint directement les fondamentaux du SEO technique WordPress.

Règle 1 : alternatives textuelles pour chaque image

C est la règle la plus connue et pourtant la plus mal appliquée. Le RGAA exige que chaque image porteuse d information possède une alternative textuelle pertinente via l attribut alt. Les images purement décoratives doivent avoir un alt="" vide pour que les lecteurs d écran les ignorent.

En pratique, je vois trois erreurs récurrentes :

• Alt absent : WordPress laisse le champ vide par défaut si le rédacteur ne le remplit pas à l upload. Résultat : le lecteur d écran lit le nom de fichier, souvent un truc comme « IMG_20260312_143022.jpg ».
• Alt générique : « image », « photo », « illustration ». Ça ne sert à rien. L alternative doit décrire ce que l image apporte au contenu.
• Alt trop long : au-delà de 80 à 120 caractères, c est une description, pas un alt. Dans ce cas, utilisez un attribut aria-describedby pointant vers un paragraphe masqué.

Pour un site WordPress, je recommande de configurer un champ obligatoire sur le texte alternatif dans la médiathèque. Des plugins comme « Flavor » ou un simple snippet dans functions.php permettent de bloquer la publication si un alt manque. C est aussi un point que je vérifie systématiquement quand j optimise les images d un site en WebP et AVIF.

Règle 2 : navigation clavier complète

Un utilisateur doit pouvoir atteindre et activer chaque élément interactif (lien, bouton, champ de formulaire, menu déroulant) uniquement avec le clavier, sans souris. C est vital pour les personnes en situation de handicap moteur, mais aussi pour les utilisateurs avancés qui préfèrent le clavier.

Les points critiques que je vérifie sur chaque projet :

• Ordre de tabulation logique : l attribut tabindex ne doit jamais être supérieur à 0. Un tabindex="0" insère l élément dans le flux naturel ; un tabindex="-1" le rend focusable par script mais invisible à la navigation Tab.
• Focus visible : le navigateur ajoute un contour (outline) par défaut. Ne le supprimez jamais avec outline: none sans proposer un style de remplacement au moins aussi visible. J utilise souvent un box-shadow personnalisé de 3px en couleur contrastée.
• Pièges clavier : les modales, les carrousels et les menus « mega-menu » sont les pièges les plus fréquents. L utilisateur doit pouvoir entrer et sortir de chaque composant avec Tab et Échap.
• Skip links : un lien « Aller au contenu principal » en haut de page, visible au focus, permet de sauter la navigation. C est un critère RGAA explicite et ça prend 5 minutes à implémenter.

Sur WordPress, les thèmes récents comme Twenty Twenty-Five intègrent nativement ces mécanismes. Mais dès qu on installe un builder visuel ou un thème premium, il faut tout retester manuellement avec la touche Tab.

Règle 3 : contrastes de couleurs suffisants

Le RGAA impose un ratio de contraste minimum entre le texte et son arrière-plan. Les seuils, alignés sur les WCAG 2.2 niveau AA, sont :

• 4.5:1 pour le texte courant (inférieur à 24px ou 18.5px en gras)
• 3:1 pour les grands textes (à partir de 24px ou 18.5px en gras)
• 3:1 pour les composants d interface et les éléments graphiques porteurs d information

En pratique, les couleurs qui posent problème sont presque toujours les mêmes : gris clair sur fond blanc pour les textes secondaires, jaune ou vert clair sur fond blanc pour les boutons d action, et les placeholders de formulaire trop pâles.

Mon outil de référence pour vérifier les contrastes : l extension navigateur WCAG Color Contrast Checker ou le site WebAIM Contrast Checker. Je teste systématiquement les couleurs dès la phase de maquette, idéalement dans Figma ou Penpot avec un plugin de contraste intégré. Corriger après intégration coûte trois fois plus cher que corriger en design.

Un point souvent oublié : les liens dans le texte doivent être distinguables autrement que par la couleur seule. Un soulignement ou un style en gras en complément de la couleur résout le problème pour les utilisateurs daltoniens.

Règle 4 : formulaires accessibles et étiquetés

Les formulaires sont un terrain miné pour l accessibilité. Le RGAA exige que chaque champ de saisie possède une étiquette (label) explicitement associée via l attribut for correspondant à l id du champ. Les placeholders ne remplacent pas les labels : ils disparaissent à la saisie et ne sont pas lus de manière fiable par tous les lecteurs d écran.

Voici ma checklist formulaire pour chaque projet :

• Labels visibles et associés : chaque input, select et textarea a son label for="id".
• Messages d erreur explicites : pas juste « Erreur » en rouge. Le message doit indiquer quel champ pose problème et comment corriger. Utilisez aria-describedby pour lier le message d erreur au champ concerné.
• Champs obligatoires signalés : avec aria-required="true" et une mention visuelle (astérisque avec légende explicative, pas juste « * » sans contexte).
• Groupes de champs : les boutons radio et les cases à cocher liés doivent être regroupés dans un fieldset avec un legend descriptif.
• Autocomplétion : l attribut autocomplete sur les champs de nom, email, adresse et téléphone facilite la saisie pour tous et est un critère RGAA.

Sur WordPress, les extensions de formulaire ne sont pas toutes égales. Fluent Forms gère correctement les labels et l attribut aria nativement. Contact Form 7 nécessite un peu de configuration manuelle mais reste solide. Gravity Forms est le plus complet en matière d accessibilité native. Évitez les formulaires construits en pur drag-and-drop dans un builder visuel : ils génèrent souvent un HTML catastrophique.

Règle 5 : structure HTML sémantique

La structure sémantique est le squelette invisible qui permet aux technologies d assistance de comprendre l organisation de votre page. Le RGAA vérifie plusieurs points critiques :

• Hiérarchie des titres : un seul h1 par page, puis h2, h3, etc., sans sauter de niveau. Pas de h3 directement après un h1.
• Landmarks ARIA : les zones header, nav, main, footer doivent utiliser les éléments HTML5 natifs. Les rôles ARIA (role="banner", role="navigation", role="main") ne sont nécessaires que si vous ne pouvez pas utiliser les balises sémantiques.
• Listes structurées : les menus de navigation doivent être des ul/li, pas des div empilés.
• Langue de la page : l attribut lang="fr" sur la balise html est obligatoire. Si un passage est dans une autre langue, il doit porter son propre lang.
• Titre de page unique : la balise title doit être descriptive et unique pour chaque page.

Sur WordPress, la structure dépend énormément du thème. Les thèmes basés sur le Full Site Editing (FSE) respectent mieux la sémantique que les anciens thèmes classiques. Mais dans tous les cas, je vérifie avec l extension HeadingsMap que la hiérarchie des titres est cohérente. C est aussi un point qui rejoint directement le balisage Schema.org : un HTML bien structuré facilite le travail de tous les parseurs, qu il s agisse de lecteurs d écran ou de robots Google.

Règle 6 : médias, sous-titres et transcriptions

Si votre site contient des vidéos ou des fichiers audio, le RGAA impose des alternatives textuelles synchronisées. Concrètement :

• Vidéos avec son : sous-titres synchronisés obligatoires (pas les sous-titres automatiques de YouTube, qui sont rarement fiables). Il faut des sous-titres relus et corrigés.
• Vidéos sans son : une alternative textuelle ou une audiodescription doit transmettre l information visuelle.
• Fichiers audio : une transcription textuelle complète est requise.
• Lecteur média accessible : les boutons lecture, pause, volume et barre de progression doivent être utilisables au clavier et étiquetés avec des attributs ARIA.

Pour les vidéos hébergées sur YouTube ou Vimeo, le lecteur intégré gère la plupart des aspects d accessibilité du player lui-même. Mais la responsabilité des sous-titres reste la vôtre. Sur un projet client récent, j ai utilisé le format WebVTT pour des sous-titres hébergés en propre, ce qui donne un contrôle total sur la mise en forme et la synchronisation.

Un conseil pratique : si le budget sous-titrage est limité, commencez par les vidéos de la page d accueil et des pages de conversion. 80 % du trafic se concentre souvent sur 20 % des pages, et c est là que l effort est le plus rentable.

Règle 7 : tableaux de données structurés

Les tableaux HTML sont un outil puissant pour présenter des données comparatives, mais ils doivent être correctement balisés pour que les lecteurs d écran puissent les interpréter. Le RGAA vérifie :

• En-têtes de colonnes et de lignes : utilisez th avec l attribut scope="col" ou scope="row" pour indiquer si l en-tête s applique à une colonne ou une ligne.
• Légende du tableau : un caption ou un aria-label doit décrire le contenu du tableau.
• Pas de tableaux pour la mise en page : les tableaux ne doivent servir qu à présenter des données tabulaires. La mise en page se fait en CSS avec Flexbox ou Grid.
• Tableaux complexes : si un tableau a des cellules fusionnées ou des en-têtes multiples, utilisez l attribut headers sur chaque td pour pointer vers les th correspondants.

En WordPress, les éditeurs visuels génèrent souvent des tableaux sans th ni scope. Je recommande de toujours vérifier le code source du tableau après insertion, ou d utiliser un bloc personnalisé qui force la bonne structure. C est un point que je soulève aussi quand je configure le Docker Compose local de mes clients : avoir un environnement de développement propre permet de tester l accessibilité avant la mise en production.

Règle 8 : déclaration d accessibilité obligatoire

Depuis la loi de 2005 et ses décrets d application, chaque site web concerné doit publier une déclaration d accessibilité. Ce n est pas un choix, c est une obligation légale. La déclaration doit contenir :

• Le taux de conformité : pourcentage de critères RGAA respectés, basé sur un audit réel (pas une estimation à la louche).
• La date de l audit et la version du RGAA utilisée.
• La liste des non-conformités identifiées et les raisons (charge disproportionnée, contenu tiers non maîtrisé, etc.).
• Un mécanisme de contact : un formulaire ou une adresse email pour signaler un problème d accessibilité.
• La mention de la voie de recours : le lien vers le Défenseur des droits en cas de non-réponse sous 6 mois.

Le RGAA fournit un modèle de déclaration d accessibilité à adapter. Je crée systématiquement cette page sur tous mes projets WordPress, même pour les petits sites vitrine. Le lien vers la déclaration doit être accessible depuis toutes les pages, typiquement dans le footer aux côtés des mentions légales et de la politique de confidentialité.

Un point important : la mention « non conforme », « partiellement conforme » ou « totalement conforme » doit aussi apparaître sur la page d accueil du site, visible dès le premier écran ou dans le header/footer. C est un critère que beaucoup de sites oublient.

Tableau récapitulatif des 8 règles RGAA

Comment auditer ces 8 règles sur WordPress

Voici la méthode que j applique sur chaque projet avant livraison. Elle ne remplace pas un audit RGAA complet par un expert certifié, mais elle permet de couvrir 60 à 70 % des critères avec un effort raisonnable.

Étape 1 : outils automatisés (30 minutes)

J installe l extension navigateur axe DevTools (gratuite) et je lance un scan sur les 5 pages principales du site. L outil détecte automatiquement les alt manquants, les problèmes de contraste, les labels absents et les erreurs de structure HTML. Je note chaque erreur dans un tableur avec la page, le critère RGAA et la correction à apporter.

Étape 2 : test clavier manuel (20 minutes)

Je navigue sur l ensemble du site uniquement au clavier (Tab, Shift+Tab, Entrée, Échap, flèches). Je vérifie que le focus est toujours visible, que je peux accéder à tous les liens et boutons, et que je ne reste jamais bloqué dans un composant. C est le test que les outils automatisés ne peuvent pas faire correctement.

Étape 3 : test lecteur d écran (30 minutes)

J active NVDA (gratuit, Windows) ou VoiceOver (intégré macOS) et je parcours les pages clés. J écoute comment les images, les formulaires et les tableaux sont restitués. C est souvent là qu on découvre les vrais problèmes : un bouton lu « lien, image » au lieu de « Envoyer le formulaire », un tableau de prix incompréhensible sans les en-têtes.

Étape 4 : vérification de la déclaration (10 minutes)

Je m assure que la page de déclaration d accessibilité existe, qu elle est liée depuis le footer, et qu elle contient tous les éléments requis. Sur WordPress, c est une simple page statique avec un template dédié.

Pour les développeurs qui travaillent en local, je recommande d intégrer ces vérifications dans le workflow Git avec un hook pre-commit qui lance un linter accessibilité (comme pa11y-ci) sur les templates modifiés. Ça évite de découvrir les problèmes en production.

Erreurs fréquentes que je vois chez mes clients

Après avoir audité plus de 80 sites WordPress ces cinq dernières années, je retrouve les mêmes erreurs dans 9 projets sur 10 :

• Le outline: none global dans le CSS du thème. Un seul *:focus { outline: none; } suffit à casser toute la navigation clavier. Je le remplace systématiquement par un style de focus personnalisé.
• Les icônes Font Awesome sans label. Un <i class="fa fa-phone"></i> sans aria-label="Téléphone" est invisible pour les lecteurs d écran. Si l icône est décorative, ajoutez aria-hidden="true".
• Les sliders et carrousels inaccessibles. La plupart des plugins de slider populaires ne gèrent ni la navigation clavier, ni les attributs ARIA live pour annoncer le changement de slide. Je recommande Splide.js ou Swiper.js qui sont accessibles par défaut.
• Les PDF non accessibles. Mettre un PDF en ligne ne dispense pas de le rendre accessible (balisage des titres, texte sélectionnable, ordre de lecture). En pratique, je propose systématiquement une version HTML de l information en complément du PDF.
• Le footer avec 50 liens sans structure. Regroupez les liens par section dans des nav étiquetés avec aria-label.
• Les animations qui ne respectent pas prefers-reduced-motion. Depuis les WCAG 2.2, les animations non essentielles doivent être désactivables. Une simple media query CSS suffit : @media (prefers-reduced-motion: reduce) { * { animation: none !important; } }.

Si vous utilisez des outils no-code comme Bubble ou Webflow, sachez que Webflow a considérablement amélioré sa gestion de l accessibilité en 2025 avec les attributs ARIA natifs dans le designer. Bubble reste en retrait sur ce sujet et nécessite des plugins tiers.

Pour suivre les performances et le comportement utilisateur de manière éthique pendant vos audits, pensez à utiliser des solutions analytics respectueuses de la vie privée qui ne nécessitent pas de bannière cookies : c est un point d accessibilité souvent oublié, car les bannières cookies mal conçues sont elles-mêmes de vrais obstacles pour la navigation clavier et les lecteurs d écran.