Guide complet de la conformité au RGAA pour les sites web

L’accessibilité numérique est devenue un enjeu majeur pour les entreprises et les administrations. En France, le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) constitue la norme de référence à respecter pour rendre un site web accessible à tous, y compris aux personnes en situation de handicap. Se conformer au RGAA n’est pas seulement une obligation légale, c’est aussi une démarche inclusive qui élargit l’audience potentielle de vos services. Ce guide didactique vous expliquera les obligations légales associées au RGAA, les critères techniques à respecter, ainsi qu’une méthodologie pas à pas pour mettre votre site en conformité. Des outils, solutions et bonnes pratiques concrets vous aideront à naviguer dans ce processus afin d’atteindre un haut niveau d’accessibilité.

Obligations légales et échéances clés

En France, l’accessibilité des services web est encadrée par la loi n°2005-102 du 11 février 2005 (dite “Loi Handicap”). Son article 47 a instauré l’obligation pour les sites internet publics d’être accessibles aux personnes handicapées. Cette obligation a été précisée par le décret du 14 mai 2009, qui la rendait applicable sous deux ans pour les sites de l’État et trois ans pour ceux des collectivités.

Concrètement, depuis 2012, l’ensemble des sites web des organismes publics (État, collectivités territoriales, établissements publics) doit être conforme aux critères d’accessibilité. En outre, depuis septembre 2019, ces sites doivent afficher sur chaque page leur niveau de conformité et publier une déclaration d’accessibilité officielle en ligne.

Ils doivent également mettre en place un mécanisme permettant aux utilisateurs de signaler d’éventuelles difficultés et de saisir le Défenseur des droits en cas de non-réponse.

Les échéances clés à retenir pour le secteur public étaient :

23 septembre 2019 – Publication obligatoire d’une déclaration d’accessibilité pour les sites publics récents (créés après cette date).
23 septembre 2020 – Tous les sites web du secteur public (même plus anciens) devaient être accessibles à 100 %.
23 juin 2021 – Toutes les applications mobiles publiques devaient à leur tour être accessibles.

Initialement, ces obligations ne concernaient que le secteur public. Cependant, elles ont été progressivement étendues au secteur privé. Dès 2016, la loi « République Numérique » a inclus certaines entreprises d’envergure (aux chiffres d’affaires excédant 250 millions d’euros annuels) dans le champ d’application.

Plus récemment, un décret d’octobre 2023 a marqué une étape décisive : désormais, les entreprises privées de certains secteurs doivent aussi se conformer aux normes du RGAA, alors même que cela ne s’appliquait auparavant qu’aux organismes publics.

L’échéance est fixée au 28 juin 2025 : d’ici cette date, toutes les entreprises concernées devront être en conformité avec le RGAA.

Cela inclut notamment des secteurs comme le e-commerce, les banques, les transports, la téléphonie, l’audiovisuel et l’édition de livres numériques

Les micro-entreprises (moins de 10 salariés et moins de 2 M€ de chiffre d’affaires) sont exemptées, mais toutes les autres devront intégrer l’accessibilité dans leurs sites web, applications mobiles, services en ligne et même communications électroniques (emails, documents, etc.).

Sanctions : Ne pas respecter ces obligations expose l’organisme ou l’entreprise à des sanctions. Le défaut de publication de la déclaration d’accessibilité, par exemple, peut entraîner une amende pouvant atteindre 20 000 € par service en ligne non conforme.

De plus, des autorités de contrôle dédiées ont été désignées (par exemple l’Arcom pour le secteur public, la DGCCRF pour le e-commerce, etc.) pour vérifier la conformité et proposer des sanctions en cas de manquement.

Au-delà du risque juridique, il en va de la responsabilité sociale de l’entreprise de garantir l’accès de tous à ses services numériques.

En résumé, toute entité publique, et toute entreprise privée de grande taille ou exerçant dans les secteurs précités, doit aujourd’hui rendre ses sites et applications accessibles. Les dates clés (2020 pour le public, 2025 pour le privé) ne laissent aucune marge : il est impératif d’agir sans tarder pour mettre vos sites en conformité.

Les critères du RGAA : principes et thématiques

Le RGAA est le référentiel technique qui permet d’évaluer et d’assurer l’accessibilité d’un service web en France. Il s’agit en fait d’une adaptation nationale des guidelines internationales WCAG (Web Content Accessibility Guidelines) du W3C.

Les WCAG, et donc le RGAA, s’articulent autour de 4 principes fondamentaux : un contenu accessible doit être perceptible, utilisable (opérable), compréhensible et robuste.

Autrement dit, les utilisateurs doivent pouvoir percevoir les informations (par la vue, l’ouïe ou tout autre sens de substitution), naviguer et interagir avec les fonctionnalités, comprendre le contenu et le fonctionnement de l’interface, et enfin utiliser le service via une diversité de technologies (navigateurs, lecteurs d’écran, etc.) sans que l’accessibilité ne soit rompue.

Le RGAA décline ces principes en 13 thématiques couvrant tous les aspects de l’accessibilité web. Chaque thématique regroupe plusieurs critères de succès testables. Au total, la version actuelle du RGAA comprend 106 critères de conformité, répartis dans ces 13 thématiques.

Ces critères correspondent pour la plupart aux niveaux A et AA des WCAG 2.1, considérés comme le socle obligatoire (le niveau AAA n’étant pas exigé de manière générale).

Le respect de l’ensemble de ces critères garantit une conformité à 100 % au RGAA. Voici un aperçu des 13 thématiques du RGAA et de ce qu’elles recouvrent :

Images – Garantir des alternatives textuelles appropriées pour les images informatives. Exemple : chaque image porteuse d’information doit avoir une description textuelle pertinente (attribut alt), de sorte qu’un utilisateur de lecteur d’écran comprenne le contenu visuel.
Cadres (Frames) – Rendre accessibles les cadres et contenus intégrés. Par exemple, une iframe doit posséder un titre explicite décrivant son contenu.
Couleurs – Assurer un contraste suffisant entre le texte et l’arrière-plan et ne pas véhiculer d’information uniquement par la couleur. Exemple : si un élément est signalé en rouge pour “erreur”, il faut ajouter un libellé ou icône visible pour les daltoniens.
Multimédia – Rendre accessible l’audio et la vidéo. Cela inclut la présence de sous-titres synchronisés pour les vidéos, de transcriptions textuelles pour les contenus audio, d’audiodescriptions pour certains contenus vidéo, ainsi que des contrôles pour mettre en pause ou régler le volume.
Tableaux – Utiliser correctement les tableaux HTML pour présenter des données tabulaires. Il faut notamment définir les en-têtes de colonnes/lignes (<th>) et associer chaque cellule de données à ses en-têtes (attributs scope ou id/headers) afin que les lecteurs d’écran restituent le tableau de façon compréhensible.
Liens – Fournir des liens explicites. L’intitulé de chaque lien doit permettre de comprendre sa fonction ou sa destination. Exemple : éviter les liens vagues du type “cliquez ici” ; à la place, un lien devrait indiquer clairement sa cible (e.g. “Télécharger le rapport annuel”). De même, les liens sous forme d’images doivent avoir des alternatives équivalentes.
Scripts – Rendre les contenus dynamiques et interactifs accessibles. Les éléments générés par JavaScript doivent rester utilisables avec le clavier et être restitués par les technologies d’assistance. Il faut gérer le focus correctement lors de l’ouverture de fenêtres modales, utiliser les attributs ARIA pour enrichir l’accessibilité si nécessaire, etc. Par exemple, un menu déroulant scripté doit pouvoir être ouvert et parcouru au clavier.
Éléments obligatoires – Inclure dans chaque page web les éléments techniques de base requis. Cela comprend, entre autres, un doctype valide, une structure HTML correcte, la déclaration de langue primaire du document (<html lang="fr"> par exemple), la présence d’un titre de page pertinent (<title>), et l’indication de la direction de lecture si elle diffère (attribut dir). Ces éléments, bien que “cachés” pour l’utilisateur, sont essentiels pour une base accessible et conforme du document HTML.
Structuration de l’information – Structurer le contenu de manière logique via les titres et paragraphes. Il s’agit d’utiliser les balises de titre (<h1> à <h6>) dans le bon ordre hiérarchique, d’employer les listes à puces/numérotées pour les énumérations, de segmenter les sections, etc. Une bonne structuration aide tous les utilisateurs à comprendre la structure du contenu et permet aux lecteurs d’écran de proposer une navigation par titres.
Présentation de l’information – Veiller à la présentation visuelle sans compromettre l’accessibilité. Par exemple, s’assurer que le contenu reste lisible lorsque l’utilisateur agrandit la police ou zoome, que les contenus ne se chevauchent pas si les styles CSS sont désactivés, ou encore qu’aucun élément textuel n’est présenté sous forme d’image (sauf cas particulier) sans alternative. L’idée est que la mise en page s’adapte aux besoins de chacun (zoom, contraste personnalisé, etc.) sans perte d’information ni fonctionnalité.
Formulaires – Rendre les formulaires utilisables par tous. Chaque champ de formulaire doit avoir une étiquette associée (visible ou cachée) indiquant son intitulé ou sa fonction. Les instructions et erreurs doivent être présentées de manière accessible (par exemple, un message d’erreur en texte, lié au champ concerné via aria-describedby ou indiqué dans le libellé). Il faut également veiller à l’ordre de tabulation logique des champs, et à ce que la soumission du formulaire puisse se faire au clavier.
Navigation – Fournir des moyens de navigation cohérents et accessibles. Cela recouvre la présence de liens d’évitement (par exemple un lien “Aller au contenu” en début de page permettant de sauter le menu), une navigation cohérente d’une page à l’autre (menus identiques présentés au même endroit), des indications de position dans le site (fil d’Ariane), etc. La navigation au clavier doit permettre d’atteindre tous les éléments interactifs, avec un focus visible sur chaque élément focalisable.
Consultation – Assurer à l’utilisateur le contrôle de la consultation du contenu. Cette thématique regroupe divers critères tels que : la possibilité de contrôler les limites de temps (ex. prolonger ou stopper un carrousel défilant automatiquement), l’absence de contenu qui clignote ou scintille de manière dangereuse (prévention des crises d’épilepsie photosensible), la fourniture d’alternatives lorsqu’un contenu n’est pas accessible sur un support donné, etc. En somme, l’utilisateur doit pouvoir consulter le site sans être bloqué par une contrainte de temps, un contenu non alternatif ou un effet visuel perturbant.

À noter : certains contenus ou situations sont exemptés par la réglementation – par exemple, les documents bureautiques anciens publiés avant 2018, les vidéos en direct sans sous-titres, les cartes géographiques complexes, ou les anciens intranets non refondus.

Ces exceptions sont précisées par le RGAA et la loi, mais elles restent limitées. Dans la plupart des cas, il est attendu d’un site qu’il respecte l’ensemble des critères ci-dessus pour être considéré comme conforme. Un site est “totalement conforme” si 100 % des critères applicables sont respectés, “partiellement conforme” si plus de 50 % le sont, et “non conforme” en-dessous de 50 %.

L’objectif à viser est bien sûr la conformité totale, gage d’une accessibilité optimale.

Méthodologie pas à pas pour mettre un site web en conformité

La mise en conformité d’un site web au RGAA peut sembler complexe, mais en suivant une méthodologie structurée pas à pas, le processus devient plus clair et gérable. Voici les étapes recommandées pour parvenir à un site conforme :

1/ Réaliser un audit d’accessibilité – Diagnostiquez l’existant.

Commencez par évaluer le niveau actuel de votre site par rapport aux critères du RGAA. Cet audit peut être confié à un expert accessibilité (interne formé ou prestataire externe) qui examinera un échantillon représentatif de pages de votre site. L’audit identifie tous les points de non-conformité et mesure le taux de conformité global.

Par exemple, un audit RGAA formalisé restituera un pourcentage de critères respectés sur l’échantillon, ce qui permet de qualifier le site de totalement, partiellement ou non conforme.

L’audit doit inclure des tests techniques (vérification du code, du contraste, etc.), des tests manuels (navigation au clavier, utilisation d’un lecteur d’écran sur les pages) et éventuellement des tests utilisateurs en situation de handicap.

À l’issue de cette étape, vous disposez d’une liste détaillée des non-conformités classées par critère, et d’une vision claire des corrections à apporter en priorité.

2/ Analyser les résultats et planifier la mise en conformité – Élaborez un plan d’action.

Une fois l’audit réalisé, il faut analyser les problèmes relevés et définir comment les résoudre. Il est utile de rédiger un rapport de recommandations qui liste, pour chaque critère non respecté, les corrections à effectuer et des conseils de mise en œuvre.

Sur cette base, priorisez les actions : toutes les non-conformités n’ont pas le même impact, on traitera en premier les problèmes critiques d’accès à l’information (images sans alt, impossibilité de naviguer au clavier, etc.) avant des points plus mineurs.

Ensuite, construisez une feuille de route réaliste en estimant les ressources nécessaires (temps de développement, budget, compétences techniques). Le RGAA impose aux organismes soumis à l’obligation de formaliser cette démarche dans un schéma pluriannuel de mise en accessibilité sur 3 ans maximum.

Ce document est en quelque sorte le plan d’action officiel qui décrit les améliorations prévues et l’échéancier pour atteindre la conformité complète. Même si vous n’y êtes pas légalement tenu (cas d’un site privé hors champ par exemple), il est fortement conseillé d’avoir un tel plan interne pour piloter efficacement le projet.

Profitez-en pour impliquer vos équipes : c’est le moment de sensibiliser et former les développeurs, designers et contributeurs de contenu aux bonnes pratiques d’accessibilité, afin qu’ils adhèrent au plan et intègrent l’accessibilité dans leurs tâches quotidiennes.

3/ Mettre en œuvre les corrections – Passez à l’action : développement et contenu.

Cette étape est le cœur du processus : il s’agit de modifier le site pour corriger les problèmes identifiés.

Les développeurs front-end devront adapter le code HTML/CSS/JS (ajout d’attributs manquants, correction du DOM, gestion du focus, etc.), tandis que les équipes éditoriales devront compléter les contenus manquants (textes de remplacement, descriptions, légendes).

Il est recommandé de suivre une approche itérative, par lots de pages ou de fonctionnalités. Après chaque série de corrections, réalisez des tests pour valider que le critère est désormais respecté.

Par exemple, quelques actions courantes lors de cette étape : optimiser les contrastes couleurs/texte, améliorer la lisibilité (taille de police, espacement), rendre la navigation entièrement possible au clavier, ajouter des descriptions alternatives aux images, associer des étiquettes aux champs de formulaires, structurer le code HTML avec des titres et zones ARIA landmarks, etc.

Vous pouvez vous appuyer sur des outils (voir plus loin) pour vérifier rapidement certains points, mais n’oubliez pas de tester manuellement les scénarios d’utilisation (soumettre un formulaire, naviguer dans un menu déroulant, etc.) comme le ferait un utilisateur aveugle ou à mobilité réduite.

Cette phase peut être longue et technique, mais chaque correction apportée est un pas vers une meilleure accessibilité. N’hésitez pas à solliciter conseil auprès d’experts ou à consulter la documentation du RGAA qui fournit des techniques pour satisfaire chaque critère.

4/ Tester et valider la conformité atteinte – Vérifiez les améliorations.

Après avoir apporté toutes les modifications prévues, il faut procéder à une nouvelle série de tests complets.

Reproduisez un audit d’accessibilité sur le site corrigé : utilisez des validateurs automatiques pour un premier contrôle, puis refaites un passage manuel sur les pages avec un lecteur d’écran (par ex. NVDA ou VoiceOver) et en testant uniquement au clavier.

L’idéal est d’organiser également des tests utilisateurs avec des personnes en situation de handicap (par exemple un utilisateur non-voyant, une personne ayant des troubles moteurs utilisant seulement le clavier, etc.) afin de recueillir leur feedback sur l’ergonomie du site. Ces tests permettront de détecter d’éventuels oublis ou problèmes résiduels.

Assurez-vous que le site est accessible sur tous les supports (ordinateur, mobile, tablette) et avec plusieurs navigateurs. Si certains critères restent non satisfaits, apportez les ajustements finaux. À l’issue de cette étape de validation, vous devriez atteindre un taux de conformité proche de 100 %.

5/ Publier les documents obligatoires de conformité – Déclarez votre niveau d’accessibilité.

Une fois votre site conforme (ou du moins après l’audit, même s’il n’est pas encore parfait), la réglementation vous impose de communiquer sur son accessibilité. Concrètement, vous devez rédiger et publier la déclaration d’accessibilité du site, généralement sous la forme d’une page dédiée (souvent accessible via un lien “Accessibilité” en pied de page).

Cette déclaration suit un format officiel fourni par l’État et doit contenir notamment : le taux de conformité atteint et le statut (totalement, partiellement ou non conforme), la liste des contenus non accessibles avec les raisons de leur non-conformité (par exemple “vidéo X : pas de sous-titres, sera corrigé d’ici fin 2024”), un lien vers le schéma pluriannuel d’amélioration si celui-ci est requis, et les contacts de référence pour l’accessibilité.

Il faut aussi mentionner le mécanisme de feedback : expliquer comment un usager peut signaler un défaut d’accessibilité (adresse mail ou formulaire de contact à disposition) et rappeler qu’il peut, en l’absence de réponse sous un mois, saisir le Défenseur des droits pour faire valoir ses droits.

Enfin, sur la page d’accueil du site, vous devez afficher de manière visible le niveau de conformité (une phrase du type “Accessibilité : partiellement conforme”, avec éventuellement un lien vers la page de déclaration pour plus de détails). Publiez également votre schéma pluriannuel et le plan d’actions annuel sur votre site (section “Accessibilité” ou “Informations légales”), afin de montrer votre engagement dans la durée.

Cette transparence est non seulement exigée légalement, mais elle démontre aussi auprès du public que vous prenez au sérieux l’accessibilité.

6/ Assurer le suivi et la maintenance de l’accessibilité – Pérennisez la démarche.

La conformité d’un site n’est pas un état figé, surtout si votre site évolue régulièrement. Il faut donc mettre en place une gouvernance de l’accessibilité sur le long terme.

Cela passe par des actions de sensibilisation continues (former les nouveaux arrivants, inclure un module accessibilité dans vos processus de développement et de rédaction), par l’intégration systématique de critères RGAA dans les cahiers des charges de vos prestataires, et par des évaluations régulières.

On recommande de réaliser un audit de suivi au moins une fois par an, ou après chaque refonte majeure du site, pour garantir que les nouveaux contenus ajoutés respectent bien les exigences. Mettez à jour la déclaration d’accessibilité à chaque évolution significative (nouveau taux de conformité si vous avez amélioré des points, nouvelle date d’audit, etc.).

De même, continuez à remplir votre plan d’action annuel et à le publier chaque année avec l’avancée des travaux. Cette étape de maintenance est cruciale pour rester conforme dans le temps et ne pas voir vos efforts initiaux dilapidés par de nouvelles régressions. En internalisant une culture de l’accessibilité (via des bonnes pratiques de développement, des check-lists qualité en fin de production, etc.), vous ferez de l’accessibilité non plus une contrainte ponctuelle, mais un atout durable de votre stratégie numérique.

Outils et solutions pour faciliter la mise en conformité

Différents outils et solutions existent pour vous aider à vérifier et améliorer l’accessibilité de votre site web. Ces outils peuvent grandement simplifier la détection des problèmes et même, pour certains, apporter des correctifs ou des fonctionnalités supplémentaires pour se conformer au RGAA. Voici un aperçu des catégories d’outils disponibles, ainsi que quelques exemples pour chacune :

Outils d’évaluation automatique de l’accessibilité : il s’agit de validateurs ou scanners qui inspectent vos pages web et signalent les violations courantes des critères. Par exemple, l’outil Lighthouse intégré dans le navigateur Chrome permet d’auditer une page et fournit un score d’accessibilité ainsi que la liste des problèmes détectés (images sans alt, contrastes insuffisants, etc.). De même, l’extension Wave de WebAIM ou l’extension Assistant RGAA (disponible sur Chrome/Firefox) survolent le code de la page et mettent en évidence visuellement les éléments non conformes (erreurs ARIA, formulaires sans label, titres manquants…). Ces outils automatiques sont très pratiques pour un premier diagnostic rapide. Néanmoins, gardez en tête qu’ils ne détectent qu’une partie des critères (environ 30 à 50 % des tests) et qu’ils doivent être complétés par une vérification humaine.

Modules et extensions pour CMS (WordPress, Drupal, etc.) : si votre site utilise un CMS populaire, la communauté propose des plugins facilitant la mise en conformité. Par exemple, sur WordPress, le plugin gratuit WP Accessibility ajoute des fonctionnalités utiles (il peut insérer des liens d’évitement si votre thème n’en prévoit pas, forcer l’attribut alt sur les images uploadées, améliorer la navigation au clavier, etc.). Il existe également des thèmes “prêts pour l’accessibilité” : le thème WP-DSFR (Design Système de l’État) est un thème WordPress open-source conçu pour respecter par défaut le RGAA et les standards graphiques de l’État français, ce qui en fait une excellente base si vous créez un site institutionnel. Côté Drupal, on trouve un équivalent avec le thème Drupal DSFR, maintenu par la DINUM, qui intègre les composants du design système de l’État et vise une conformité native. De plus, des modules Drupal comme All-in-One Accessibility ou Siteimprove (pour ne citer que ceux-là) peuvent aider à analyser vos contenus et à corriger certains aspects directement depuis l’interface du CMS. Ces extensions ne dispensent pas d’un travail manuel soigné, mais elles offrent un gain de temps et une surveillance continue de l’accessibilité de vos pages lors de la mise à jour de contenu.

Outils open-source d’audit approfondi : pour une analyse plus poussée, vous pouvez vous tourner vers des solutions open-source dédiées. Par exemple, Asqatasun est un outil libre permettant de scanner un site entier et de générer un rapport d’accessibilité selon le RGAA (il intègre les règles RGAA 4 et produit un bilan détaillé par critère). On peut l’installer sur un serveur ou utiliser sa version en ligne.
De même, Tanaguru est un moteur d’audit (initialement français, à l’origine d’Asqatasun) qui propose une version open-source pour effectuer des audits automatisés complexes. Ces outils sont utiles pour auditer de nombreux pages et suivre l’évolution de la conformité dans le temps, notamment pour les grandes plateformes.

Outils d’aide au développement et à la conception : cette catégorie regroupe divers utilitaires qui, sans vérifier directement tous les critères RGAA, aident les équipes techniques à créer des contenus accessibles. On peut citer par exemple les analyseurs de contraste (tel que Color Contrast Analyzer du Paciello Group, ou l’outil en ligne Contrast-Finder) qui permettent de tester si les combinaisons de couleurs que vous utilisez respectent les ratios de contraste minimum (niveau AA ou AAA). Il existe également des plug-ins pour vos IDE ou pour vos tests unitaires qui intègrent axe-core (la librairie du moteur aXe de Deque Systems) afin de détecter en amont les erreurs dans le code. Côté design, certains kits UI incluent des composants accessibles prêts à l’emploi (ex. bibliothèques de composants ARIA).
Enfin, n’oublions pas les technologies d’assistance elles-mêmes, qui sont des “outils” à utiliser durant vos tests : un lecteur d’écran gratuit comme NVDA sur Windows, ou VoiceOver sur Mac, permettra de vérifier concrètement comment votre site est restitué à une personne non-voyante. De même, l’extension de navigateur NoCoffee simule divers handicaps visuels (basse vision, daltonisme) pour éprouver l’interface. En combinant ces outils, les développeurs et responsables qualité peuvent intégrer l’accessibilité tout au long du cycle de développement.

Afin de mieux visualiser les solutions disponibles, le tableau ci-dessous présente quelques outils et solutions couramment utilisés pour la mise en conformité, avec leur usage principal :

Outil / Solution	Type / Plateforme	Description et fonctionnalités clés
Lighthouse (Chrome)	Outil d’audit automatisé (Chrome)	Audit d’accessibilité intégré au navigateur Chrome (ou Chromium). Génère un rapport avec un score et liste les problèmes détectés (sémantique, contraste, etc.).
Wave (WebAIM)	Outil en ligne & Extension navigateur	Analyse une page web et affiche visuellement les erreurs d’accessibilité (images sans alt, liens vides, etc.) directement sur la page. Utile pour un diagnostic rapide critère par critère.
Assistant RGAA	Extension navigateur (Chrome/Firefox)	Extension officielle (open source) permettant d’auditer une page selon le référentiel RGAA. Elle met en évidence les éléments non conformes et guide l’auditeur dans les tests à réaliser.
Asqatasun	Outil open-source (serveur ou local)	Scanner d’accessibilité automatique. Permet de tester un site complet selon le RGAA 4, avec rapports détaillés (pourcentage de réussite par thématique, listing des critères non-validés).
WP Accessibility	Extension WordPress (plugin)	Plugin gratuit améliorant l’accessibilité d’un site WordPress : insertion de liens d’évitement, gestion du focus, indications s’il manque des attributs alt, désactivation du target=_blank, etc.
WP-DSFR	Thème WordPress	Thème WordPress conforme au RGAA, intégrant le Design Système de l’État (DSFR). Il fournit des composants accessibles prêts à l’emploi (navigation, formulaires…) pour faciliter la création de sites publics accessibles.
Drupal DSFR	Thème Drupal (base theme)	Thème de base pour Drupal aligné sur le Design Système de l’État. Offre une base graphique et HTML accessible (gabarits respectant les critères RGAA). Adapté aux sites gouvernementaux ou tout site cherchant une conformité élevée par défaut.
Color Contrast Analyzer	Outil desktop (Windows/Mac) ou Web	Permet de vérifier le contraste entre deux couleurs. Indique si les rapports de contraste respectent les seuils AA ou AAA du RGAA/WCAG. Incontournable pour ajuster sa charte graphique.
NVDA (NonVisual Desktop Access)	Logiciel lecteur d’écran (Windows)	Lecteur d’écran gratuit open-source, utilisé pour tester la compatibilité d’un site avec une navigation non-visuelle. Indispensable pour valider l’expérience utilisateur d’une personne aveugle ou malvoyante naviguant sur votre site.

(Note : Cette liste n’est pas exhaustive – de nombreux autres outils existent. Par exemple, axe DevTools, Accessibility Insights de Microsoft, ou des solutions commerciales telles que Siteimprove, Acceo etc., peuvent également accompagner vos démarches. L’important est de choisir les outils adaptés à vos besoins et de bien comprendre leurs rapports pour s’en servir efficacement.)

En combinant ces différentes solutions, vous pourrez à la fois diagnostiquer rapidement vos pages, corriger certains problèmes de façon assistée et vérifier le résultat sur divers scénarios utilisateurs. Profitez des outils open-source et gratuits en premier lieu, et envisagez des solutions plus avancées si votre contexte le requiert (grand site e-commerce, besoin de monitoring continu, etc.).

Liste de contrôle pour vérifier la conformité de votre site

Voici une check-list synthétique des principaux points à vérifier pour évaluer le niveau de conformité de votre site vis-à-vis du RGAA. Parcourez cette liste régulièrement – par exemple lors de la recette d’une nouvelle fonctionnalité ou avant la mise en ligne d’un nouveau site – de manière à ne rien oublier. Cochez chaque élément lorsque c’est bon :

Images : chaque image informative possède une alternative textuelle pertinente (attribut alt décrivant l’information ou la fonction de l’image). Les images décoratives sont soit ignorées par les technologies d’assistance (alt vide ""), soit en arrière-plan CSS.
Multimédia : les contenus vidéo sont sous-titrés et, si nécessaire, audio-décrits ; les contenus audio ont une transcription texte disponible. Tout lecteur média offre des contrôles (lecture/pause, volume) accessibles au clavier.
Couleurs et contraste : les textes et éléments visuels respectent les ratios de contraste minimum (au moins 4.5:1 entre texte normal et arrière-plan, 3:1 pour du texte large ou des graphiques). Aucune information n’est transmise uniquement par la couleur (par exemple, un astérisque ou texte d’erreur accompagne la surbrillance en rouge des champs invalides).
Structure sémantique : la page comporte un titre principal (<h1>) représentatif, et la structure des titres est hiérarchisée correctement (<h2>, <h3>, … sans sauter de niveau injustifié). Les listes sont balisées avec <ul>/<ol> et <li> pour les énumérations. La langue par défaut de chaque page est déclarée (attribut lang="fr" par ex.), et tout changement de langue dans le texte utilise un attribut lang approprié.
Liens : les libellés de lien sont explicites et compréhensibles hors contexte. On évite les “Lire la suite” ou “Cliquez ici” ambigus non accompagnés. Si des liens ouvrent une nouvelle fenêtre ou un téléchargement, cela est indiqué explicitement à l’utilisateur (par du texte ou un attribut title).
Navigation au clavier : on peut naviguer dans toutes les rubriques et contrôles au clavier uniquement (en utilisant la touche Tab pour avancer, Shift+Tab pour reculer, Entrée ou Espace pour activer). L’ordre de tabulation suit un enchaînement logique (généralement l’ordre du code ou visuel). Un indicateur de focus visible apparaît sur l’élément focalisé (par ex. un contour ou un surlignage sur le lien sélectionné via Tab).
Formulaires : chaque champ de formulaire est associé à un label descriptif, soit via une étiquette <label> visible, soit via une alternative accessible (aria-label ou aria-labelledby). Les libellés ou instructions sont présents pour indiquer le format attendu si nécessaire (ex: format de date). En cas d’erreur de saisie, un message d’erreur clair est affiché et associé au champ en erreur (par exemple en utilisant aria-describedby ou en plaçant le message juste après le champ). Les champs obligatoires sont signalés explicitement (par du texte, pas seulement par une couleur ou astérisque isolé sans indication).
Éléments obligatoires techniques : la page utilise un code HTML valide (doctype présent et correct, balises bien imbriquées). Le code ne contient pas d’erreurs qui casseraient l’accessibilité (par ex. deux mêmes id en doublon, ce qui perturberait l’association label/champ). Chaque page a une balise <title> unique et significative. Les attributs ARIA utilisés le sont à bon escient et respectent la spécification (pas d’aria-label redondant sur un élément déjà labellisé par <label>, etc.).
Dynamique et interaction : aucune action automatique irréversible ne se produit sans que l’utilisateur en soit informé. Par exemple, si un contenu se met à jour en temps réel (actualités, scores…), l’utilisateur en est averti ou a la possibilité de le contrôler. Si une session a une expiration temporelle (ex: délai de connexion), une alerte préalable est donnée et l’utilisateur peut prolonger le temps si besoin. De plus, aucun élément de l’interface ne clignote à une fréquence pouvant provoquer des malaises (les effets clignotants rapides sont à proscrire au-delà de 3 flashes par seconde).
Aide et alternatives : si certaines fonctionnalités sont complexes à utiliser, une page d’aide ou une notice d’utilisation est fournie (par exemple pour expliquer les raccourcis clavier disponibles sur le site, ou la navigation d’une carte interactive). Si un contenu ne peut être pleinement accessible, une alternative accessible est proposée : par exemple, pour une carte géographique non accessible aux lecteurs d’écran, fournir en complément une liste d’adresses ou de coordonnées géographiques consultables textuellement.

Cette liste de contrôle permet déjà de couvrir les exigences principales du RGAA. En l’appliquant, vous devriez détecter la plupart des problèmes fréquents avant même un audit formel. Pour une vérification exhaustive, référez-vous au référentiel complet des 106 critères, mais notre check-list constitue une base pratique pour un suivi régulier de la qualité d’accessibilité de votre site.

Bonnes pratiques en accessibilité numérique : exemples concrets

Pour illustrer plus concrètement ce qu’implique la mise en conformité RGAA, voici quelques exemples de bonnes pratiques (et en creux, des mauvaises pratiques à éviter) appliquées à des cas courants :

Alternative textuelle pour les images – Mauvaise pratique : <img src="graphique-ventes.png" alt=""> (aucun texte alternatif fourni) ou bien un texte non informatif du type alt="graphique". Bonne pratique : fournir un texte alternatif qui décrit le sens ou l’information clé de l’image. Par exemple : <img src="graphique-ventes.png" alt="Graphique montrant l'évolution des ventes de 2020 à 2024, en hausse constante">. Ainsi, un utilisateur aveugle entendant le lecteur d’écran aura connaissance des données présentées. Pour une image purement décorative (p.ex. image d’arrière-plan sans lien avec le contenu), on utilisera un attribut alt vide pour la rendre invisible aux technologies d’assistance.
Intitulés de liens explicites – Mauvaise pratique : une série de liens “Cliquez ici” ou “En savoir plus” qui, pris isolément, ne disent pas où ils mènent. Par exemple : <a href="rapport.pdf">Cliquez ici</a> (sans autre contexte). Bonne pratique : formuler le lien de façon à indiquer clairement sa destination ou action. Par exemple : <a href="rapport.pdf">Télécharger le rapport annuel 2023 (PDF)</a>. On peut éventuellement conserver un court “En savoir plus” si le contexte l’entourant est explicite (par ex. dans un bloc d’actualité, juste après le résumé de l’article, un “En savoir plus” qui suit un titre d’article identifiable peut passer, bien que le RGAA préfère l’explicite seul). De même, si un lien ouvre une nouvelle fenêtre, on ajoutera une mention dans l’intitulé, par ex. “Site de l’entreprise X (nouvelle fenêtre)”. Ces bonnes pratiques profitent à tous les usagers, pas seulement aux personnes aveugles, en rendant la navigation plus intuitive.
Formulaires accessibles – Mauvaise pratique : ne pas associer de label aux champs de formulaire (le visiteur ne sait pas ce qu’il doit saisir, ou un lecteur d’écran énoncera seulement “zone de texte, non renseigné” sans contexte). Par exemple, un champ <input> avec seulement un texte placeholder grisé qui disparaît au focus. Bonne pratique : utiliser la balise <label> pour chaque champ, ou une alternative équivalente, afin de fournir un intitulé. Exemple : htmlCopierModifier<label for="email">Adresse email :</label> <input type="email" id="email" name="email"> Ainsi, le champ a une étiquette lisible associée. Si pour des raisons de design l’étiquette visuelle n’est pas affichée, on peut la cacher tout en la laissant accessible (via des classes CSS type “sr-only”), ou utiliser un attribut aria-label="Adresse email" sur le champ. Par ailleurs, indiquez clairement les champs obligatoires (par ex. en ajoutant “(obligatoire)” dans le label). En cas d’erreur de validation, ne vous contentez pas de colorer le champ en rouge : affichez un message d’erreur en texte, et idéalement liez-le au champ (aria-describedby) pour que le lecteur d’écran le lise lorsque le focus revient sur le champ erroné. Une bonne pratique consiste aussi à regrouper les messages d’erreur en tête de formulaire en reprenant la liste des champs à corriger, tout en mettant le focus sur le premier champ non valide pour guider l’utilisateur. En résumé, un formulaire accessible guide l’utilisateur dans la saisie et le prévient en cas de problème de manière explicite.
Navigation clavier et focus – Mauvaise pratique : un menu déroulant accessible uniquement au survol de la souris (hover) sans support clavier, ou des éléments focalisables mais sans style de focus visible (on “perd” le curseur visuel en tabulant). Bonne pratique : s’assurer que toutes les fonctionnalités interactives sont accessibles au clavier. Pour un menu, cela implique qu’avec la touche Tab on puisse accéder au menu et sous-menu, et avec Entrée/Espace activer un lien. Si un composant complexe (comme un carrousel, un accordéon) nécessite des interactions au clavier spécifiques (flèches directionnelles, échappement avec Échap, etc.), documentez-les dans la page ou rendez-les intuitives via le rôle ARIA approprié. Toujours veiller à afficher le focus : par défaut, les navigateurs dessinent un contour autour de l’élément focalisé, il ne faut pas le désactiver sans le remplacer par un équivalent visible. Par exemple, ajoutez du CSS du type a:focus { outline: 2px solid #000; } pour que le lien focalisé soit bien démarqué. Une bonne navigation clavier profite également aux utilisateurs sans handicap qui préfèrent le clavier, et elle est indispensable pour les personnes ayant des problèmes moteurs ou de vision.
Contenus animés et timing – Mauvaise pratique : un diaporama d’images qui défile automatiquement sans possibilité de pause, ou une fenêtre popup qui disparaît après quelques secondes sans que l’utilisateur ait eu le temps de la lire. Bonne pratique : donner à l’utilisateur le contrôle sur ce type de contenu. Par exemple, pour un slider automatique, inclure un bouton “Pause/Play” accessible (et labellisé pour les lecteurs d’écran) afin qu’il puisse stopper le défilement. Pour une notification temporaire, prévoir qu’un focus ou une interaction utilisateur puisse la maintenir affichée plus longtemps. D’une manière générale, évitez d’imposer des délais stricts : si une action utilisateur est requise dans un temps imparti (ex. saisie d’un code), proposez une option pour demander plus de temps. Autre point : si votre site utilise des animations ou effets visuels, assurez-vous qu’ils n’entraînent pas de clignotements rapides. Respectez la règle des 3 flashs par seconde maximum pour tout contenu susceptible de clignoter, afin de ne pas déclencher de crise chez les personnes épileptiques photosensibles.

En appliquant ces bonnes pratiques, on constate souvent une amélioration générale de l’ergonomie du site, pour tous les utilisateurs. Par exemple, des libellés de liens explicites ou des formulaires bien construits bénéficient aussi aux utilisateurs sans handicap (meilleure compréhension, moins d’erreurs). L’accessibilité numérique s’inscrit dans une démarche “design universel” où l’interface est conçue pour s’adapter aux besoins variés. N’hésitez pas à consulter les ressources officielles du RGAA qui donnent des cas d’école et exemples supplémentaires pour chaque critère, ainsi que les techniques suffisantes pour y satisfaire.

Conclusion

Ce guide vous a fourni un cadre complet – du rappel légal aux astuces de mise en œuvre – pour aborder sereinement la mise en conformité RGAA. Récapitulons les points essentiels :

Connaître ses obligations : Identifiez si votre organisation est soumise légalement au RGAA et quelles sont les échéances (pour beaucoup d’acteurs privés, juin 2025). Même sans obligation stricte, visez l’accessibilité par conviction et anticipation réglementaire.
Maîtriser le référentiel : Familiarisez-vous avec les 13 thématiques du RGAA et les grands principes d’accessibilité (perceivable, utilisable, compréhensible, robuste). Cela vous aidera à dialoguer avec vos équipes techniques et à comprendre les rapports d’audit.
Adopter une démarche projet : Traitez la mise en conformité comme un projet à part entière, avec un audit initial, un plan d’action, des ressources allouées, un suivi et une validation. Ne cherchez pas des “solutions miracles” toutes faites : c’est un travail d’équipe qui implique développeurs, designers, rédacteurs et décideurs.
Utiliser les outils à bon escient : Profitez des outils d’évaluation automatique pour détecter rapidement les problèmes, des plugins de CMS pour corriger certaines lacunes structurelles, et des guides de bonnes pratiques pour former vos contributeurs. Ces outils facilitent le travail mais ne remplacent pas l’expertise humaine, ils la complètent.
Impliquer les utilisateurs : Quand c’est possible, faites tester votre site par des personnes en situation de handicap (il existe des sociétés ou associations qui proposent ce service). Leur retour est inestimable pour repérer des problèmes qu’un audit technique pur ne verrait pas, et pour prioriser les améliorations qui comptent vraiment pour l’expérience utilisateur.
Documenter et communiquer : Préparez soigneusement votre déclaration d’accessibilité et tenez-la à jour. C’est non seulement une obligation, mais aussi le reflet de votre transparence et de votre engagement. Indiquez clairement sur votre site comment les utilisateurs peuvent vous faire part de difficultés : cette interaction vous permettra d’améliorer continuellement votre service.

En fin de compte, la conformité au RGAA ne doit pas être vue comme une contrainte administrative, mais comme une opportunité d’amélioration continue de votre site web. En suivant ce guide, vous disposez d’une feuille de route complète pour rendre votre site plus accessible, plus inclusif et conforme aux normes. Il ne vous reste plus qu’à passer à l’action – étape par étape – en mobilisant vos équipes autour de cet objectif commun. Un web accessible à tous est un web meilleur pour chacun, et votre entreprise a tout à y gagner. Bonne mise en conformité RGAA !

Sources : Les informations et recommandations de ce guide s’appuient sur le référentiel officiel RGAA 4.1.2 et sur les ressources institutionnelles relatives à l’accessibilité numérique en France, notamment le portail gouvernemental d’accessibilité, les directives européennes transposées en droit français, ainsi que sur des guides pratiques publiés par des experts du domaine

Pour aller plus loin, vous pouvez consulter : le site officiel accessibilite.numerique.gouv.fr (documentations, outils et modèles officiels), les articles d’Access42 détaillant les évolutions légales, ou encore le blog de la FEVAD pour l’application de la loi aux sites e-commerce. En synthèse, ce guide réunit les exigences et bonnes pratiques unanimement reconnues pour vous accompagner vers une conformité totale au RGAA, gage d’accessibilité et de qualité pour votre site web.