RGAA vs WCAG : quelles différences entre ces référentiels d’accessibilité ?

RGAA vs WCAG cristallise une question que beaucoup d’équipes numériques se posent encore : faut-il suivre le référentiel français, le standard international, ou jongler avec les deux sans trop savoir comment les articuler. Entre les exigences très concrètes du RGAA, la largeur de vue des WCAG et la pression croissante des textes européens, le risque est réel de se perdre dans les sigles et d’oublier l’essentiel : rendre les interfaces utilisables par tous. Les débats sur le niveau de conformité A, AA ou AAA, sur la portée de l’accessibilité des sites web ou encore sur la place des PDF dans tout cela prennent souvent l’ascendant sur les besoins des personnes concernées.

Pour une équipe projet, ce flou se traduit par des arbitrages compliqués. Un DSI veut un site « conforme RGAA », un product owner entend partout parler de normes web internationales, un designer lit des articles sur un « web inclusif » sans toujours voir le lien avec les audits. Pendant ce temps, un usager malvoyant se bat avec un formulaire impossible à remplir au clavier. Cet article propose de remettre de l’ordre dans ces référentiels d’accessibilité, en expliquant comment RGAA et WCAG s’emboîtent, où ils divergent en pratique, et comment choisir une stratégie réaliste. Objectif assumé : permettre de passer du « on nous demande d’être accessibles » à « on sait où l’on va et pourquoi ».

En bref

• Les WCAG sont le standard international de référence en accessibilité numérique, structuré autour de quatre principes (perceptible, utilisable, compréhensible, robuste) et de trois niveaux de conformité (A, AA, AAA).
• Le RGAA transpose ces lignes directrices au contexte français avec des critères d’accessibilité testables, une méthodologie d’audit précise et des obligations légales assorties de contrôles et de sanctions.
• Les différences RGAA WCAG tiennent moins au fond qu’à la forme : même socle technique, mais granularité, vocabulaire et périmètre d’obligation distincts.
• Les entreprises exposées à plusieurs marchés doivent composer avec un écosystème plus large : PDF/UA, directive européenne, European Accessibility Act, Section 508, etc.
• La stratégie la plus solide consiste souvent à viser les WCAG 2.1 niveau AA, puis à décliner les exigences RGAA via des outils concrets comme une checklist RGAA détaillée ou un plugin d’accessibilité pour WordPress.

RGAA vs WCAG : poser les bases pour comprendre les référentiels d’accessibilité

Quand une organisation commence à parler de référentiels d’accessibilité, les mêmes questions reviennent souvent : « RGAA ou WCAG, lequel prime ? », « Faut-il deux audits ? », « Que va regarder l’administration en cas de contrôle ? ». Sans un minimum de cartographie, ces interrogations se traduisent vite par de la paralysie. Or le paysage est moins opaque qu’il n’y paraît si l’on accepte une idée simple : les WCAG définissent le fond, le RGAA encadre la forme en France.

Les WCAG (Web Content Accessibility Guidelines) sont publiées par le W3C et forment la référence mondiale pour l’accessibilité des sites web, des applications et, plus largement, de nombreux contenus numériques. Elles énoncent des règles comme « fournir des alternatives textuelles » ou « rendre tout fonctionnel au clavier », organisées autour de quatre grands principes. Ces règles restent toutefois volontairement générales. Elles disent par exemple qu’un composant doit être « navigable au clavier », sans détailler test par test comment vérifier cette propriété sur un bouton, un menu ou une carte interactive.

Le RGAA (Référentiel général d’amélioration de l’accessibilité) part de ce socle conceptuel et le décline en une série de critères et de tests applicables à chaque type d’élément d’interface. Pour un même principe WCAG, le RGAA détaille les cas à passer en revue : lien texte, lien image, bouton, média, tableau, etc. Dans les audits, cela se traduit par des feuilles de calcul, des résultats critère par critère et des taux de conformité chiffrés. L’enjeu de conformité n’est plus théorique, il devient mesurable.

Cette articulation explique pourquoi les deux référentiels ne s’opposent pas. Un site « conforme RGAA » respecte par construction les normes web définies par les WCAG, au niveau couvert par la version de référence choisie. L’inverse n’est pas toujours vrai en France. Une interface pourra techniquement respecter le niveau AA des WCAG tout en étant jugée insuffisamment documentée ou mal auditée au regard du cadre national. C’est exactement ce qui arrive quand une organisation publie une déclaration de conformité sans analyse sérieuse.

Autre point souvent mal compris : RGAA et WCAG ne couvrent pas que les sites institutionnels. La montée de la dématérialisation a étendu le périmètre à des démarches clés pour la vie quotidienne : inscription scolaire, démarches fiscales, suivi bancaire, réservation de transport, etc. Plus les procédures sont critiques, plus un défaut d’accessibilité numérique a un impact direct sur les droits des personnes, en particulier celles en situation de handicap. C’est dans ce contexte que RGAA et WCAG prennent tout leur sens.

Une bonne manière de démarrer consiste à explorer un guide synthétique comme le guide d’accessibilité RGAA, puis à revenir au texte des WCAG quand une question dépasse le cadre strictement français. Ce va-et-vient permet d’éviter deux écueils fréquents : la vision uniquement juridique, coupée des usages, ou au contraire la vision purement UX qui néglige la conformité réglementaire.

Les principes WCAG et leurs niveaux de conformité, socle du web inclusif

Pour démêler les différences RGAA WCAG, il faut d’abord regarder ce que posent les WCAG comme cadre conceptuel. Ces lignes directrices reposent sur quatre piliers, souvent rappelés mais rarement reliés à des situations concrètes. Dès qu’on les ancre dans le réel, ils deviennent pourtant beaucoup plus parlants pour une équipe produit ou une direction métier.

Le premier principe, Perceptible, demande que le contenu puisse être perçu par différents canaux sensoriels. Dans la pratique, cela implique des textes alternatifs pour les images, des sous-titres pour les vidéos, des contrastes suffisamment élevés entre texte et arrière-plan, ou encore la possibilité d’agrandir le texte sans casser la mise en page. Quand ces règles ne sont pas respectées, une personne malvoyante se retrouve face à un carrousel d’actualités que son lecteur d’écran ne peut pas interpréter, ou face à une vidéo institutionnelle muette pour elle faute de sous-titrage.

Le second principe, Utilisable, s’intéresse au fonctionnement. Toutes les fonctionnalités doivent pouvoir être exploitées au clavier, les focus visibles, les éléments interactifs cohérents dans leur comportement. Un exemple concret souvent rencontré en audit : un menu burger « accessible à la souris », mais dont l’ouverture au clavier ne déplace pas le focus, laissant l’utilisateur perdu dans une zone invisible. D’un point de vue légal, l’interface est non conforme. D’un point de vue humain, elle crée un blocage net pour des personnes qui ne peuvent pas utiliser la souris.

Le principe Compréhensible ajoute une dimension de clarté, à la fois du contenu et de la navigation. Formulaires logiques, messages d’erreurs explicites, libellés de boutons cohérents : tout cela conditionne l’expérience. Un bouton « Valider » qui se transforme en « Suivant » ou « Confirmer » sans logique claire complique la tâche de tous les usagers, et davantage encore celle de ceux qui s’appuient sur une synthèse vocale. Côté critères d’accessibilité, cela conduit à vérifier la cohérence des intitulés, l’ordonnancement des champs et la manière dont les erreurs sont annoncées.

Enfin, le principe Robuste rappelle qu’une interface doit rester interprétable par différentes technologies d’assistance, aujourd’hui et demain. Cela suppose un code suffisamment propre, des balises correctement hiérarchisées, une gestion rigoureuse des rôles ARIA. Les WCAG insistent ici sur la compatibilité avec une large gamme de navigateurs, de lecteurs d’écran et de dispositifs, là où certains projets se contentent encore de « tester sur la dernière version de Chrome ».

Les trois niveaux de conformité (A, AA, AAA) forment un escalier d’exigence plutôt qu’une étiquette marketing. Le niveau A évite les barrières les plus manifestes. Le niveau AA, visé par la majorité des lois nationales, traite des points qui, cumulés, font une grande différence au quotidien pour les utilisateurs. Le niveau AAA demande des efforts supplémentaires parfois difficiles à tenir sur des sites très riches en contenu. Pour des services publics ou des grands acteurs privés, viser AA de façon systématique et sélectionner une poignée de critères AAA pertinents (par exemple un meilleur sous-titrage ou des alternatives textuelles plus détaillées) constitue souvent un bon compromis.

Une nuance qui mérite d’être soulignée : les WCAG couvrent tout type de contenu web, mais restent assez générales sur certains médias, notamment les PDF complexes. C’est là qu’intervient la norme ISO 14289, dite PDF/UA, qui va détailler ce que doit être un PDF balisé, avec une structure logique, des signets, des champs de formulaires étiquetés et des textes alternatifs. En audit de documents, on s’appuie souvent simultanément sur les WCAG et sur ce référentiel spécialisé pour évaluer la qualité réelle d’un corpus de factures, de contrats ou de rapports annuels.

Pour les équipes qui débutent, une ressource utile consiste à s’appuyer sur un parcours de formation structuré. Des dispositifs comme une formation dédiée aux fondamentaux du RGAA et des WCAG permettent de transformer ce cadre théorique en réflexes opérationnels lors des ateliers de conception ou des revues de maquettes.

Le RGAA : traduction française, critères d’accessibilité et mécanismes de contrôle

Une fois les WCAG posées, reste à comprendre comment la France a décidé d’en faire un outil opposable. C’est tout l’enjeu du RGAA, qui ne se contente pas d’être un texte de recommandations. Il s’inscrit dans un cadre juridique précis, lié notamment à la loi de 2005 sur l’égalité des droits et des chances, puis aux textes qui ont suivi la directive européenne sur l’accessibilité des sites publics.

Le premier rôle du RGAA est de traduire les principes WCAG en critères opérationnels. Au lieu d’une règle générale sur les images, on trouve une liste de cas : images porteuses d’information, images décoratives, graphes, captcha visuel, etc. Pour chaque cas, un critère explique ce qui est attendu et un test détaille comment vérifier. Cela structure le travail des auditeurs, mais aussi celui des développeurs qui doivent corriger les anomalies.

En parallèle, le RGAA définit une méthodologie d’audit : échantillon de pages, typologie de contenus, modalités de test manuel et automatique. Ce cadre évite des déclarations fantaisistes où tout serait soi-disant conforme sur la foi d’un simple passage d’outils automatiques. Des services spécialisés, comme ceux présentés sur cette page consacrée à l’audit d’accessibilité RGAA, s’appuient sur cette méthode pour produire des rapports détaillés et hiérarchiser les corrections.

Les obligations varient selon les acteurs, mais le schéma général reste similaire : afficher une déclaration d’accessibilité à jour, indiquer le niveau de conformité, lister les contenus non accessibles et les raisons, prévoir un mécanisme de contact ou de recours en cas de difficulté. La plupart des administrations et des grandes entreprises couvertes par le RGAA sous-estiment encore l’enjeu de transparence. Une déclaration vague ou obsolète est souvent un signe avant-coureur d’audit insuffisant.

Sur le plan des risques, la France ne se contente plus de rappeler les obligations. Des contrôles sont menés, avec la possibilité de sanctions financières pour les organisations qui persistent à publier des interfaces inaccessibles sans plan de mise en conformité crédible. Les détails des montants et des procédures font l’objet de ressources spécialisées, comme l’analyse des sanctions et amendes liées au RGAA. Ce durcissement peut paraître sévère, mais il reflète le fait que l’accessibilité n’est pas un simple sujet d’image : elle touche aux droits fondamentaux.

Du côté des équipes, la conséquence concrète est claire. Se déclarer conforme sans audit sérieux revient à prendre un risque juridique et réputationnel inutile. À l’inverse, investir dans un audit approfondi, puis dans un plan d’actions réaliste, permet de documenter la progression et de démontrer une bonne foi en cas de contrôle. Des outils comme un test en ligne de conformité RGAA ou une checklist en 106 points servent alors de garde-fous entre deux audits complets.

Un tableau comparatif aide souvent les directions à saisir les différences pratiques entre un appui sur les WCAG seuls et une démarche structurée autour du RGAA :

Aspect	WCAG	RGAA
Statut	Lignes directrices internationales publiées par le W3C	Référentiel officiel français adossé à la réglementation nationale
Niveau de détail	Règles générales et critères de succès	Critères testables, cas d’usage détaillés, méthode d’audit
Obligations	Dépend des lois qui s’y réfèrent (UE, USA, etc.)	Obligatoire pour les acteurs publics et certaines entreprises privées
Évaluation	Souvent volontaire, dépend du contexte	Audit RGAA formalisé, déclaration de conformité, contrôles possibles
Communication	Pas de format de déclaration imposé	Modèle de déclaration d’accessibilité attendu sur chaque site

Pour les organisations françaises, la conclusion est assez nette. Les WCAG servent de boussole internationale, mais c’est bien le RGAA qui structure les obligations quotidiennes, les audits, les budgets et les plans de correction. Ne pas intégrer le référentiel national dans la gouvernance de projet revient à construire un bâtiment sans tenir compte du code de l’urbanisme local.

Au-delà de RGAA et WCAG : PDF/UA, directive européenne, EAA et autres normes web

Se limiter au couple RGAA / WCAG peut donner l’illusion de couvrir tout le périmètre de l’accessibilité numérique. Dans les faits, beaucoup de difficultés rencontrées par les utilisateurs se situent dans les zones grises : documents PDF non balisés, applications métiers internes, terminaux physiques associés à des services en ligne. C’est là que des normes comme PDF/UA et des textes comme la directive européenne ou l’European Accessibility Act (EAA) entrent en scène.

La norme ISO 14289, ou PDF/UA, vise à rendre les documents PDF lisibles par des technologies d’assistance. Elle impose une structure logique balisée (titres, paragraphes, listes), des textes alternatifs pour les images, une navigation claire via des signets, et une étiquetage précis des champs de formulaires. Un rapport annuel converti en PDF sans ces éléments devient vite un « bloc » indéchiffrable pour un lecteur d’écran, même si le site qui l’héberge est par ailleurs impeccable sur le plan RGAA.

Au niveau européen, la directive sur l’accessibilité des sites publics a joué un rôle de catalyseur. Elle impose aux administrations de respecter les WCAG 2.1 niveau AA pour leurs sites et applications mobiles. Les États membres ont ensuite décliné cette exigence dans leur droit national, la France s’appuyant notamment sur le RGAA pour opérationnaliser ces attentes. Là encore, on retrouve le duo concept international / mise en musique locale.

L’European Accessibility Act (EAA) vient compléter ce dispositif en touchant cette fois-ci des entreprises privées qui proposent des services considérés comme essentiels : banques, transport, e-commerce, télécoms, livres numériques, etc. Derrière ce texte, l’idée est de ne pas laisser un usager bloqué sur une interface bancaire ou un terminal de paiement sous prétexte qu’il ne s’agit pas strictement d’un « site public ». Pour ces acteurs, ignorer les WCAG et PDF/UA à la veille de la pleine entrée en application de l’EAA revient à se préparer des contentieux et des refontes en urgence.

À l’international, d’autres cadres se rattachent également aux WCAG, comme la Section 508 aux États-Unis ou certaines législations nationales hors UE. Pour une entreprise qui opère sur plusieurs continents, une stratégie cohérente consiste souvent à prendre les WCAG comme base commune, puis à adapter les déclinaisons locales : RGAA en France, Section 508 pour certains contrats publics américains, etc. Cette approche limite les silos et évite de maintenir différents niveaux d’accessibilité selon les pays, ce qui est difficilement défendable sur le plan éthique.

Pour s’y retrouver, beaucoup d’équipes gagnent à construire une sorte de « carte mentale » des normes et des textes, en distinguant ce qui relève des normes web (WCAG, PDF/UA) de ce qui relève des lois et directives (RGAA, directive européenne, EAA). Un outil de synthèse, comme une définition simplifiée du RGAA replacée dans ce paysage, permet de rassurer les interlocuteurs non spécialistes. Sans ce travail pédagogique, chaque nouveau sigle vient ajouter de la confusion au lieu d’apporter de la clarté.

Au fond, ce maillage croissant de normes et de directives traduit la même idée : l’accessibilité des sites web et des documents associés n’est plus un supplément facultatif, c’est une condition d’accès à des services essentiels. Se contenter d’un vernis « conforme sur la page d’accueil » ne tient plus face à cette réalité.

Stratégies concrètes pour aligner RGAA et WCAG dans vos projets d’accessibilité numérique

Une fois le paysage clarifié, reste la question la plus opérationnelle : comment faire, projet par projet, pour concilier exigences RGAA, socle WCAG et contraintes du terrain. Beaucoup d’organisations oscillent entre deux extrêmes peu productifs. D’un côté, un perfectionnisme paralysant qui veut tout corriger d’un coup, quitte à ne jamais livrer. De l’autre, un minimalisme risqué qui se contente de corriger trois contrastes et d’ajouter une page « accessibilité » standard.

Une approche pragmatique consiste à planifier la montée en conformité en plusieurs paliers. Premier palier : traiter les bloquants majeurs repérés par un audit RGAA de base. Il s’agit souvent d’éléments très concrets : absence totale de navigation au clavier, formulaires impossibles à utiliser avec un lecteur d’écran, documents PDF critiques non balisés. Ce premier lot vise à empêcher que des usagers ne se retrouvent purement et simplement exclus d’une démarche en ligne.

Deuxième palier : aligner les composants clés sur les critères d’accessibilité les plus courants des WCAG niveau AA. Menus, boutons, modales, carrousels, onglets, tableaux de données : tous ces éléments reviennent en boucle dans les audits. Construire ou refondre un petit « design system accessibilité » avec des composants testés, documentés et alignés sur le RGAA et les WCAG permet ensuite de diffuser de bonnes pratiques sur l’ensemble du produit.

Troisième palier : intégrer l’accessibilité dans le fonctionnement ordinaire des équipes. Revues de code avec check RGAA, tests de navigation au clavier sur chaque nouvelle fonctionnalité, vérification systématique des textes alternatifs lors des mises à jour de contenu. À ce stade, des outils comme un expert RGAA intégré à l’équipe ou un accompagnement régulier par un cabinet externe jouent un rôle de garde-fou, sans transformer chaque sprint en audit complet.

Pour aider à prioriser, certains utilisent des matrices d’impact : critère bloquant pour une population bien identifiée, critère irritant mais contournable, critère d’optimisation. Un champ de formulaire non étiqueté qui empêche de déposer une demande d’aide sociale ne se traite pas au même niveau d’urgence qu’un défaut de contraste léger sur un texte secondaire. Sans cette hiérarchisation, les ressources des équipes se diluent dans des micro-détails, au détriment des problèmes structurels.

Une liste de repères concrets peut servir de fil rouge à chaque release :

• Vérifier au clavier tous les parcours critiques (création de compte, paiement, dépôt de dossier).
• Contrôler la cohérence des balises de titres (h2, h3…) sur les gabarits principaux.
• Repasser sur les nouveaux contenus pour ajouter ou corriger les textes alternatifs.
• Tester au moins une fois la nouvelle version avec un lecteur d’écran sur un scénario réel.
• Actualiser au besoin la déclaration de conformité RGAA si des progrès significatifs ont été réalisés.

Côté gouvernance, les directions qui réussissent à tenir dans la durée sont celles qui cessent de voir l’accessibilité comme un chantier ponctuel. Elles l’intègrent dans les critères de validation de projet, au même titre que la sécurité, la performance ou la compatibilité mobile. À terme, le coût d’un audit RGAA régulier est largement inférieur à celui d’une refonte dans l’urgence après signalements répétés ou à celui d’une image de marque abîmée auprès des publics les plus fragiles.

Une remarque souvent entendue mérite d’être challengée : « Notre site n’est pas parfait, mais nos usagers n’ont jamais râlé ». Les personnes en situation de handicap se fatiguent vite de signaler des problèmes sans retour. Elles vont parfois jusqu’à renoncer à utiliser un service plutôt que de batailler avec un formulaire inaccessible. Se baser uniquement sur les remontées spontanées comme indicateur de qualité d’accessibilité revient donc à naviguer à vue, avec des instruments défaillants.

Faut-il choisir entre RGAA et WCAG pour un site français ?

Non. Pour un site destiné au public en France, les WCAG servent de socle technique international, mais c’est le RGAA qui structure les obligations légales et la manière d’évaluer la conformité. La démarche la plus robuste consiste à viser les WCAG 2.1 niveau AA en conception, puis à vérifier et documenter la conformité via un audit RGAA et une déclaration d’accessibilité publiée sur le site.

Un site conforme RGAA est-il automatiquement conforme aux WCAG ?

Dans la pratique, un site réellement conforme au RGAA respecte le socle des WCAG sur le niveau couvert par le référentiel. Le RGAA s’appuie explicitement sur ces lignes directrices. En revanche, un site qui se revendique « conforme WCAG » sans suivre la méthode RGAA peut ne pas répondre aux attentes spécifiques de la réglementation française, notamment sur la déclaration d’accessibilité et le périmètre audité.

Les PDF publiés en ligne sont-ils concernés par RGAA et WCAG ?

Oui. Dès qu’un document PDF est mis à disposition sur un site, il entre dans le champ de l’accessibilité numérique. Les WCAG posent des règles générales (alternatives textuelles, structure, navigation), tandis que la norme PDF/UA (ISO 14289) détaille les exigences techniques propres à ce format. Le RGAA prend ces éléments en compte et les audits sérieux évaluent la qualité des documents autant que celle des pages HTML.

Comment débuter une mise en conformité sans tout refondre ?

Une approche réaliste consiste à commencer par un audit limité mais solide sur un échantillon représentatif de pages et de documents. À partir de là, il devient possible de prioriser les corrections en fonction de l’impact sur les utilisateurs : navigation au clavier, formulaires, contenus PDF essentiels. Des outils comme les tests en ligne, les checklists RGAA ou l’appui ponctuel d’un expert aident ensuite à intégrer l’accessibilité dans les sprints sans bloquer la feuille de route.

L’European Accessibility Act change-t-il la donne pour le secteur privé ?

Oui, surtout pour les entreprises qui proposent des services jugés essentiels comme la banque en ligne, l’e-commerce, les télécoms ou les transports. L’European Accessibility Act impose une accessibilité renforcée des sites, applications, terminaux et documents associés, en s’appuyant notamment sur les WCAG. Pour ces acteurs, anticiper ces exigences en alignant dès maintenant leurs produits sur les référentiels d’accessibilité évite des mises en conformité précipitées et coûteuses à court terme.