RGAA et WCAG : comprendre les différences pour être conforme

Claire, responsable de la communication numérique dans une collectivité, prépare une refonte. Le prestataire annonce : « Nous respecterons les WCAG ». Sur le papier, cela paraît solide. Dans les faits, Claire doit publier une déclaration d’accessibilité, justifier un niveau de conformité, et être en mesure de répondre à un contrôle. Même scène côté tourisme : Catherine, responsable communication dans un office de tourisme, veut rendre son site plus inclusif sans perdre en attractivité. Elle entend parler de WCAG, de RGAA, de niveaux A et AA… et se demande surtout comment transformer ces mots en décisions concrètes.

Si vos équipes hésitent entre « standard international » et « obligation en France », cet article vise une chose : clarifier la différence RGAA et WCAG, puis traduire cette différence en actions réalistes pour les collectivités et les destinations touristiques.

Les WCAG (Web Content Accessibility Guidelines) sont le standard international publié par le W3C. Elles définissent des principes et des critères de succès (niveaux A, AA, AAA) applicables quel que soit le pays. Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) est la déclinaison française : il transpose les WCAG dans le cadre public français et, surtout, les transforme en tests vérifiables et en méthode d’audit. En pratique, pour une collectivité ou une destination touristique publique, les WCAG servent de boussole « by design », et le RGAA sert de référentiel de contrôle et de preuve de conformité.

WCAG : le standard international (la boussole)

Ce que sont réellement les WCAG

Les WCAG structurent l’accessibilité autour de principes et de critères de succès. L’idée est de décrire ce que doit pouvoir faire un utilisateur, indépendamment des technologies employées.

Elles sont conçues pour être :

Transversales : applicables à différents contextes techniques et organisationnels ;
Interprétables : suffisamment génériques pour être adaptées à des sites vitrines, des démarches en ligne, des applications ;
Évolutives : avec des versions (2.0, 2.1, 2.2) et des niveaux de conformité (A, AA, AAA).

Concrètement, les WCAG vous aident à penser : contrastes, navigation clavier, alternatives textuelles, sous-titrage, structure des contenus, prévention des erreurs sur les formulaires, Etc. Elles donnent un cadre cohérent pour intégrer l’accessibilité dès la conception.

Pourquoi les WCAG ne suffisent pas, seules, à « être conforme » en France

C’est un point souvent mal compris : les WCAG ne deviennent contraignantes que lorsqu’un cadre national les intègre. Pour le secteur public français, c’est précisément le rôle du RGAA. C’est lui qui vous permet de dire, de manière démontrable, si un service est conforme, partiellement conforme ou non conforme, et sur quels éléments vous vous appuyez.

Autrement dit : un prestataire peut annoncer « WCAG AA », mais une collectivité a besoin d’un langage opérationnel pour auditer, publier, suivre et corriger. C’est le RGAA qui apporte cette couche intermédiaire.

RGAA : l’adaptation française (la méthode)

Un référentiel conçu pour l’audit et la preuve

Le RGAA traduit les exigences d’accessibilité en une grille détaillée : des critères et des tests associés à des situations d’usage. Là où les WCAG restent intentionnelles (« l’utilisateur doit pouvoir… »), le RGAA formalise des contrôles (« dans tel cas, vérifier que… »), avec des résultats attendus.

Trois différences reviennent constamment quand on compare RGAA et WCAG :

La granularité : le RGAA est plus détaillé, car il découpe les exigences en contrôles plus concrets ;
La méthodologie d’audit : échantillonnage, taux de conformité, rapport, suivi ;
La prise en compte de technologies d’assistance de référence : le RGAA cadre le test dans des conditions reproductibles.

Le RGAA dans la vraie vie d’un site public

Dans la pratique, une collectivité se réfère rarement aux WCAG seules. Elle s’appuie sur le RGAA comme référentiel opérationnel, car il permet de :

Produire un audit compréhensible et opposable ;
Prioriser les corrections (bloquants, majeurs, mineurs) ;
Publier une déclaration d’accessibilité (et l’actualiser) ;
Justifier des écarts, y compris lorsque certains contenus sont temporairement hors périmètre.

Pour un organisme touristique public, la logique est identique : l’accessibilité n’est pas qu’une exigence technique. Elle touche la chaîne éditoriale, les parcours de réservation, les contenus multimédias, et les services tiers (cartographies, moteurs de réservation, widgets). Le RGAA permet de poser un cadre de pilotage.

WCAG vs RGAA : tableau comparatif pour décider plus vite

Point de comparaison	WCAG	RGAA	Ce que cela change pour vous
Rôle	Standard international ; principes et critères de succès ; niveaux A / AA / AAA	Référentiel français opérationnel ; critères + tests ; méthode d’audit	WCAG pour concevoir, RGAA pour contrôler et prouver
Niveau visé dans les projets publics	Souvent AA	Souvent AA (a minima)	Vous devez pouvoir démontrer le niveau atteint
Formulation	Générique et intentionnelle	Détaillée et testable, par type de contenu et situation d’usage	Les équipes savent quoi vérifier, page par page
Évaluation	Peut être interprétée selon contexte	Auditable : échantillonnage, taux, rapport	Vous pouvez piloter la progression et publier une déclaration crédible
Finalité	Accessibilité « by design »	Conformité, preuve et suivi	Utile pour cadrer un prestataire, puis sécuriser l’exploitation

Ce tableau résume un point clé : pour des sites institutionnels, le RGAA structure la conformité, tandis que les WCAG structurent la conception.

Ce que cela change concrètement dans vos projets (collectivités et tourisme)

1) Cadrage : écrire des exigences qui ne créent pas d’ambiguïté

Beaucoup de projets se mettent en difficulté dès le départ, parce que le cahier des charges mélange les concepts. L’objectif n’est pas de « citer le bon sigle », mais de formuler une exigence testable.

Une formulation solide contient généralement : le niveau attendu, la méthode de vérification, les livrables, et la gouvernance.

Exemples de formulations utiles (à adapter) :

Objectif d’accessibilité : viser au minimum un niveau AA ;
Référentiel de vérification : conformité évaluée selon la méthode RGAA ;
Livrables : audit initial, plan d’actions priorisé, contre-audit ;
Exploitation : déclaration d’accessibilité mise à jour, processus de correction continue.

Vous gagnez un bénéfice immédiat : plus de clarté dans le dialogue avec les prestataires, et moins de surprises en fin de projet.

2) Conception : penser « parcours » avant de penser « pages »

Dans une collectivité, les parcours critiques sont rarement les pages « vitrines ». Ce sont les démarches : inscription scolaire, prise de rendez-vous, formulaires, documents, contact, recherche.

Dans un office de tourisme ou une destination, les parcours critiques sont souvent : recherche d’activités, filtrage, consultation de fiches, réservation, information pratique, accessibilité des contenus (horaires, tarifs, localisation), et médiathèques (images / vidéos).

WCAG et RGAA convergent sur un point : l’accessibilité n’est pas un correctif ajouté à la fin. Elle se décide dans :

Le design (contrastes, tailles, repères visuels, état de focus, cohérence) ;
Les contenus (structure, clarté, alternatives, sous-titres, langage simple) ;
L’expérience globale (navigation clavier, erreurs compréhensibles, formulaires, retours système).

3) Développement : éviter l’illusion du « tout-outil »

Un outil d’audit automatique peut repérer des erreurs fréquentes (alternatives manquantes, contrastes insuffisants, attributs ARIA incohérents, structure de titres). C’est utile, mais incomplet.

Le RGAA met en avant la nécessité d’un contrôle reproductible et d’un audit structuré. Cela implique, tôt ou tard, une part de vérification manuelle, notamment sur :

Les parcours au clavier ;
Les messages d’erreur et la compréhension ;
Les composants interactifs ;
Les contenus éditoriaux et médias.

Dans les projets web publics, le risque est toujours le même : produire un site visuellement réussi, mais fragile sur l’accès aux services. L’accessibilité devient alors un « chantier post-livraison » qui coûte plus cher et démobilise les équipes.

4) Pilotage : la conformité n’est pas un état, c’est une trajectoire

Les contenus comparatifs insistent sur l’impact organisationnel. Un projet RGAA réussi repose sur une gouvernance impliquée, un accompagnement (interne ou externe) et une démarche continue : audits, corrections, contrôle des régressions.

Autrement dit, il ne s’agit pas seulement de « faire un audit ». Il s’agit de mettre en place un cycle de vie : publier, corriger, maintenir.

Comprendre la mécanique d’audit : ce que le RGAA ajoute aux WCAG

L’échantillonnage : pourquoi « 100 % du site » n’est presque jamais audité

Dans un audit RGAA, on ne teste généralement pas chaque page une par une. On sélectionne un échantillon représentatif : pages gabarits, parcours clés, types de contenus (articles, formulaires, documents, recherche, etc.).

Cela peut surprendre, mais c’est une force : vous obtenez une photographie pragmatique, exploitable, et vous pouvez comparer les résultats d’une année sur l’autre.

Le taux de conformité : un indicateur utile, à condition de savoir ce qu’il signifie

Le taux de conformité est un indicateur de pilotage. Il doit être lu avec prudence : un bon taux ne compense pas un parcours bloquant pour une démarche critique. Inversement, un taux moyen peut coexister avec un service très accessible sur les parcours essentiels, si vous avez bien priorisé.

L’enjeu, pour des sites institutionnels, est d’éviter deux extrêmes :

Le « taux vitrine » qui masque des blocages sur les démarches ;
L’obsession du 100 % qui bloque la progression faute de priorisation.

Les différences qui comptent vraiment, côté terrain

Différence n°1 : le niveau de détail (et donc l’effort de mise en œuvre)

Les WCAG sont pensées pour être universelles. Le RGAA, lui, est pensé pour être actionnable. Ce niveau de détail est un avantage, mais il a une conséquence : il faut organiser le travail, répartir les responsabilités, et outiller les contrôles.

Pour une collectivité avec une équipe réduite, cela peut sembler lourd. En réalité, c’est souvent l’inverse : un référentiel détaillé évite les débats interminables sur « ce qui est acceptable ». Les tests aident à trancher.

Différence n°2 : le statut (et donc la responsabilité)

Le statut n’est pas un sujet théorique. Il impacte votre communication et vos obligations : déclaration d’accessibilité, transparence sur les non-conformités, mécanisme de contact, et capacité à répondre aux retours utilisateurs.

Pour une destination touristique, cette transparence peut aussi devenir un levier d’image : montrer qu’on progresse, qu’on écoute, et qu’on traite les retours.

Différence n°3 : les technologies d’assistance et la reproductibilité

Un test « qui marche chez moi » ne suffit pas. L’approche RGAA vise une reproductibilité : vérifier que les parcours fonctionnent dans des conditions représentatives, notamment pour des utilisateurs de lecteurs d’écran ou de navigation au clavier.

Dans un projet, cela change la façon de valider : on ne valide pas seulement « en visuel ». On valide des comportements, des annonces, des états, des retours d’erreur.

Par quoi commencer (sans transformer cela en chantier interminable)

L’erreur la plus fréquente est de vouloir tout traiter à la fois. Un chemin plus robuste consiste à articuler conception (WCAG) et conformité (RGAA).

Voici une trajectoire simple, conçue pour des structures publiques avec des contraintes de temps et de budget :

Cadrer le périmètre : services concernés, parcours critiques, contenus à risque (PDF, vidéos, formulaires, widgets tiers) ;
Faire un diagnostic initial : outils automatiques + revue manuelle sur les parcours clés ;
Prioriser : corriger d’abord ce qui bloque l’accès aux services (navigation clavier, formulaires, contrastes, alternatives, structure) ;
Formaliser : plan d’actions, pilotage, et déclaration d’accessibilité alignée sur la réalité ;
Maintenir : intégrer des contrôles réguliers, éviter les régressions, former les contributeurs.

Cette liste est volontairement courte. L’objectif est de sécuriser le projet, pas de créer un dispositif administratif.

Collectivités et destinations touristiques : des points d’attention spécifiques

Les PDF : l’angle mort le plus fréquent

Les retours de terrain montrent souvent un décalage entre un site web « correct » et des documents téléchargeables difficiles, voire impossibles à utiliser avec des technologies d’assistance. Pour un service public, c’est critique : beaucoup d’informations importantes passent encore par des PDF.

Une stratégie réaliste consiste à :

Traiter en priorité les PDF les plus consultés et les plus sensibles (démarches, inscriptions, informations pratiques) ;
Mettre en place une chaîne de production documentaire accessible ;
Prévoir, si nécessaire, une mise en conformité progressive avec un accompagnement des usagers.

Les formulaires et la réservation : l’accessibilité « business-critical » en tourisme

Côté destinations touristiques, l’accessibilité n’est pas seulement un sujet de conformité. Elle impacte directement :

La capacité à réserver une activité ;
La compréhension des conditions (tarifs, dates, accessibilité des lieux) ;
La confiance et la conversion.

Sur ces parcours, quelques défauts suffisent à exclure un public : focus invisible, messages d’erreur non annoncés, champs obligatoires non compris, boutons non accessibles au clavier, captcha mal géré.

Les services tiers : cartographies, widgets, lecteurs, formulaires externes

C’est un point délicat, et très courant : une partie des composants vient de prestataires (cartes, agendas, moteurs de réservation, cookies, chatbots). Sur le terrain, ces éléments peuvent faire chuter l’accessibilité d’un site pourtant bien construit.

L’approche la plus efficace est contractuelle et organisationnelle : exiger des garanties d’accessibilité, tester tôt, et prévoir des alternatives lorsque le composant ne permet pas un usage équivalent.

Deux cas d’usage inspirants (et ce qu’ils montrent)

Collectivité : une refonte pilotée par l’exigence

Certaines collectivités ont intégré une exigence forte d’accessibilité dès le cahier des charges de refonte, puis ont travaillé par cycles : audit initial, corrections techniques et éditoriales, contre-audit, et formation des équipes pour maintenir le niveau. Ce type de démarche montre un point clé : la conformité n’est pas un « sprint de fin de projet ». Elle se construit avec une gouvernance claire et une progression mesurable.

Destination touristique : une démarche structurée et collective

Côté tourisme, on retrouve des approches similaires : désigner un référent, former les équipes, auditer, corriger, et maintenir. Les bénéfices dépassent le juridique : expérience plus fluide, informations plus claires, et image plus inclusive. Ces démarches mettent aussi en évidence une réalité : certains contenus externes ou documents peuvent rester difficiles à rendre accessibles immédiatement, d’où l’importance d’un plan d’amélioration continue.

Les erreurs fréquentes (et comment les éviter)

« On vise WCAG AA » n’implique pas automatiquement « on est conforme RGAA »

Un objectif WCAG AA peut être une bonne base, mais il doit être associé à une méthode de vérification et à des livrables. Sans cela, vous risquez de découvrir en fin de projet qu’il manque des preuves, une déclaration, ou que certains tests essentiels n’ont jamais été réalisés.

L’audit « one shot » qui n’est jamais maintenu

Beaucoup de sites se dégradent après une refonte, simplement parce que la chaîne éditoriale n’est pas formée et que les évolutions ne sont pas contrôlées. Une démarche durable implique de prévoir un minimum de contrôle régulier, même léger.

L’accessibilité « seulement côté dev »

Les contenus rappellent que l’accessibilité ne se limite pas au code. Un site techniquement propre peut devenir difficile à utiliser si les contenus sont mal structurés, si les titres sont incohérents, si les alternatives d’images sont absentes, ou si les vidéos ne sont pas sous-titrées.

Outils et ressources : quoi utiliser sans se disperser

Il existe de nombreuses solutions, mais le bon réflexe consiste à combiner :

Un outil automatique pour repérer rapidement des erreurs récurrentes ;
Une revue manuelle sur quelques parcours critiques ;
Un audit expert lorsque vous devez produire une preuve solide et un plan d’actions.

L’objectif n’est pas d’empiler des outils, mais d’installer une routine : détecter, corriger, vérifier.

Conclusion : mieux comprendre pour mieux décider

WCAG et RGAA ne s’opposent pas. Ils se complètent.

Les WCAG vous aident à concevoir un service accessible « by design », cohérent et universel. Le RGAA vous aide à transformer cette ambition en conformité démontrable, avec une méthode, des tests et un pilotage.

Pour une collectivité ou une destination touristique, la meilleure stratégie consiste souvent à : intégrer l’accessibilité dès le cadrage, viser un niveau au moins AA, auditer avec une méthode claire, publier une déclaration honnête, puis maintenir dans le temps.

Si vous souhaitez sécuriser une refonte, un appel d’offres, ou un plan de mise en conformité, une bonne première étape est souvent un diagnostic cadré sur vos parcours critiques. Cela donne une feuille de route réaliste, adaptée à votre budget et à vos priorités.

FAQ

Le RGAA est-il basé sur les WCAG ?

Oui. Les WCAG constituent le socle international, et le RGAA en est une déclinaison opérationnelle pour le cadre public français. En pratique, cela signifie que les objectifs d’accessibilité restent alignés, mais que le RGAA formalise des tests et une méthode d’audit pour produire une mesure de conformité et des preuves exploitables.

Quelle différence entre « standard » (WCAG) et « référentiel » (RGAA) ?

Les WCAG sont un standard : elles décrivent des principes et des critères de succès universels, indépendants d’un contexte national. Le RGAA est un référentiel : il traduit ces exigences en contrôles vérifiables et en méthode de mesure. Pour un site public, le référentiel est essentiel pour piloter l’audit, la déclaration d’accessibilité et le suivi.

Quel niveau viser : A, AA ou AAA ?

Dans la majorité des projets publics, l’objectif opérationnel est de viser au minimum le niveau AA. Le niveau A constitue un socle, mais il est rarement suffisant pour garantir une expérience réellement inclusive. Le niveau AAA est très exigeant et difficile à atteindre sur l’ensemble d’un site ; il peut cependant inspirer des améliorations sur des parcours sensibles.

Peut-on se dire « conforme » si on a juste appliqué des bonnes pratiques WCAG ?

Appliquer des bonnes pratiques est une étape utile, mais la conformité implique généralement une capacité à le démontrer : tests, périmètre évalué, rapport, et déclaration d’accessibilité mise à jour. Sans méthode de vérification et sans livrables, il est difficile d’affirmer un niveau de conformité de manière robuste, notamment en contexte public.

Pourquoi le RGAA paraît-il plus « strict » que les WCAG ?

Le RGAA paraît plus strict car il est plus détaillé et orienté audit. Il traduit des exigences générales en situations concrètes à vérifier, avec une logique de résultats attendus. Ce niveau de précision réduit l’ambiguïté et facilite le pilotage, mais il rend aussi les écarts plus visibles, notamment sur les composants interactifs, les formulaires et les contenus multimédias.

Qu’est-ce qu’un audit RGAA, concrètement ?

Un audit RGAA consiste à vérifier un échantillon représentatif de pages et de parcours au regard de critères et de tests. Il produit un taux de conformité, un rapport détaillé, et une liste d’écarts priorisés. L’audit est particulièrement utile pour cadrer un plan de correction, préparer une déclaration d’accessibilité crédible, et objectiver la progression dans le temps.

Quels contenus posent le plus souvent problème pour les collectivités et les destinations ?

Les difficultés reviennent fréquemment sur les PDF, les formulaires, les vidéos (sous-titrage et alternatives), les cartes et widgets tiers, ainsi que sur les composants de navigation (menus, filtres, carrousels). Ces contenus cumulent souvent des enjeux techniques et éditoriaux. Une approche efficace consiste à traiter d’abord les parcours critiques et les contenus les plus consultés.

Comment maintenir l’accessibilité après une refonte ?

La conformité se maintient grâce à une démarche continue : règles éditoriales, formation des contributeurs, contrôles réguliers (automatiques et manuels), et gestion des régressions lors des mises à jour. Un pilotage léger mais constant est souvent plus efficace qu’un audit isolé tous les deux ans. L’important est de garder un rythme de vérification sur les parcours essentiels.

Pour une destination touristique, l’accessibilité est-elle compatible avec l’attractivité ?

Oui, et c’est même souvent un levier d’expérience. Un site accessible est plus clair, plus lisible, et plus fiable sur mobile. Il facilite la réservation, la compréhension des informations pratiques, et la confiance. En tourisme, l’accessibilité s’inscrit dans une logique d’accueil : elle renforce l’image d’une destination inclusive et attentive à tous les publics, y compris les besoins temporaires.

Par quoi commencer si le budget est limité ?

Une approche pragmatique consiste à cadrer le périmètre, identifier deux à trois parcours critiques, puis réaliser un diagnostic initial mêlant outils automatiques et vérifications manuelles. Ensuite, il faut corriger d’abord les blocages majeurs (clavier, contrastes, formulaires, alternatives, structure). Cette logique de priorisation permet d’améliorer rapidement l’expérience tout en préparant un audit plus complet lorsque c’est nécessaire.

RGAA et WCAG : comprendre les différences pour mieux se conformer