Accessibilité web : que demandent les WCAG et le RGAA ?

Vous gérez un site, on vous parle d’accessibilité web, de WCAG, de RGAA, de directive européenne… et honnêtement, vous avez l’impression qu’on vous parle une autre langue ? Vous n’êtes pas seul. La bonne nouvelle, c’est qu’on peut parler d’accessibilité numérique sans jargon, sans plonger dans le code, et avec un objectif très concret : respecter les obligations légales en France, éviter les sanctions, et rendre votre site utilisable par tout le monde, y compris les personnes en situation de handicap, les seniors, les utilisateurs sur mobile ou avec une mauvaise connexion. Bref, on va transformer des normes en gestes pratiques.

Accessibilité numérique : de quoi parle-t-on concrètement ?

Un site “qui marche” n’est pas forcément un site accessible. Techniquement, votre page peut s’afficher sans bug, mais être quasiment inutilisable pour une personne malvoyante, quelqu’un qui ne peut pas utiliser la souris, ou une personne dyslexique qui se perd dans un texte indigeste. L’accessibilité numérique, c’est tout simplement le fait que chacun puisse utiliser un service en ligne de façon autonome, sans devoir demander de l’aide pour des choses basiques comme remplir un formulaire ou télécharger un document.

Concrètement, imaginez :

• Un texte en gris clair sur fond blanc : lisible pour vous, illisible pour une personne malvoyante ou juste fatiguée.
• Un menu impossible à utiliser au clavier : une personne qui navigue sans souris reste bloquée sur votre page d’accueil.
• Une image “Contactez-nous” sans alternative textuelle : pour un lecteur d’écran, il n’y a… rien.
• Un formulaire qui affiche simplement “Erreur” : l’utilisateur ne sait pas quel champ corriger ni pourquoi.

Ce n’est pas un sujet “réservé aux développeurs”. L’inclusion numérique, ça concerne autant le contenu (texte, images, vidéos), le design (couleurs, tailles, structure) que la technique. Dès que vous publiez un article, mettez une image ou créez un formulaire, vous influencez directement l’accessibilité de votre site.

WCAG en version vulgarisée : les 4 grands principes expliqués sans jargon

Les WCAG (Web Content Accessibility Guidelines) sont un guide international publié par le W3C pour rendre les contenus web accessibles aux personnes en situation de handicap. Ce n’est pas un texte obscur réservé aux geeks, c’est un ensemble de bonnes pratiques que les gouvernements et les entreprises utilisent partout dans le monde comme référence.

Les WCAG reposent sur 4 grands principes qu’on résume souvent par l’acronyme POUR : Perceptible, Utilisable, Compréhensible, Robuste. On va les regarder avec des exemples très concrets.

Perceptible : que le contenu soit “visible” ou “audible” pour chacun

Perceptible, ça signifie que l’information est accessible, que ce soit par la vue, l’ouïe ou via un lecteur d’écran. Une image importante doit avoir un texte alternatif, une vidéo doit posséder des sous-titres, et les contrastes entre texte et arrière-plan doivent être suffisants pour que la lecture ne devienne pas un défi.

Exemples parlants :

• Un graphique “chiffre d’affaires 2026” expliqué uniquement par une image. Sans description, une personne aveugle ne saura jamais si l’entreprise progresse ou recule.
• Une vidéo de présentation sans sous-titres : inaccessible pour une personne sourde ou simplement quelqu’un qui regarde la vidéo sans son dans le train.

Utilisable : que l’on puisse vraiment interagir avec le site

Utilisable (dans les WCAG on parle d’“opérable”) veut dire : toutes les fonctionnalités doivent fonctionner au clavier, sans piège, sans interaction impossible. La navigation doit être claire, et votre site ne doit pas contenir de contenus à risque, comme des animations qui clignotent au point de déclencher des crises chez certaines personnes.

Si on caricature, un site où l’on ne peut pas tout faire au clavier n’est pas accessible. C’est aussi simple que ça. Les WCAG insistent : boutons, menus, formulaires, tout doit répondre correctement aux touches du clavier.

Compréhensible : que le fonctionnement et le texte ne perdent pas l’utilisateur

Là, on touche directement votre façon d’écrire. Un contenu accessible est compréhensible : langage clair, phrases raisonnables, explications concrètes, mais aussi comportement prévisible de l’interface. Si un clic sur “Valider” entraîne une suppression de compte, c’est violent.

Les WCAG demandent notamment des messages d’erreur explicites, des aides à la saisie, et une navigation qui ne change pas de logique selon les pages. C’est la base d’un contenu numérique inclusif.

Robuste : que le site fonctionne avec les technologies d’assistance

Enfin, un site robuste est un site qui fonctionne avec différents navigateurs, terminaux et technologies d’assistance (lecteurs d’écran, plages braille, commandes vocales…). En France, cette robustesse est directement liée aux normes WCAG 2.1 et à leur traduction en RGAA.

L’idée, c’est que le contenu soit lisible par les outils utilisés par les personnes en situation de handicap, aujourd’hui et demain. On ne fait pas un site qui ne fonctionne que sur un combiné de conditions ultra spécifiques, sinon l’audit d’accessibilité va faire mal.

Niveaux A, AA, AAA : minimum, recommandé, expert

Les normes WCAG sont organisées en trois niveaux de conformité : A (minimum), AA (standard recommandé), AAA (niveau avancé pour des cas spécifiques). En Europe, le niveau attendu pour les sites publics et beaucoup de services privés, c’est le niveau AA.

Un point de vocabulaire qui prête souvent à confusion : WCAG 2.2 est une recommandation officielle du W3C depuis décembre 2024, mais elle ne rend pas WCAG 2.0 ni WCAG 2.1 caduques — le W3C précise qu’un contenu conforme à 2.2 reste conforme aux versions précédentes. En pratique, en France, c’est encore WCAG 2.1 niveau AA qui sert de référence, parce que c’est sur cette version que s’appuie le référentiel national.

On peut voir ça comme un permis de conduire : A, vous avez juste les bases ; AA, vous conduisez correctement partout ; AAA, vous êtes pilote de course. La plupart des organisations visent AA, y compris via le RGAA.

RGAA : la traduction française des WCAG, vue du terrain

Le RGAA en termes simples

Le RGAA (Référentiel Général d’Amélioration de l’Accessibilité) est le référentiel officiel français qui traduit les WCAG en critères concrets pour les sites et services numériques. Il est publié par la DINUM et décline les règles WCAG 2.1 niveau AA en 106 critères techniques d’accessibilité répartis en 13 thématiques (images, formulaires, médias, navigation, etc.). La version en vigueur est le RGAA 4.1.2 ; une version 5 est en cours de rédaction, annoncée pour fin 2026 par la DINUM. Ce qui suit reste donc valable, mais les numéros de critères sont à revérifier le jour où la v5 sortira.

Où est la différence ? Les WCAG disent “une image doit avoir une alternative textuelle”. Le RGAA, lui, détaille comment vérifier ça, critère par critère, avec des tests précis pour savoir si votre site est conforme ou non. C’est le “mode d’emploi” français pour mesurer votre niveau de conformité RGAA.

Lien entre RGAA et WCAG : deux faces d’une même pièce

On peut le résumer ainsi :

• WCAG donne le “quoi” : chaque image importante doit avoir une alternative textuelle, chaque formulaire doit être compréhensible, chaque contenu doit être perceptible, utilisable, compréhensible et robuste.
• RGAA donne le “comment vérifier” : quels critères contrôler, quels tests réaliser, comment calculer un taux de conformité, comment rédiger une déclaration d’accessibilité.

Respecter le RGAA revient, en pratique, à respecter les WCAG 2.1 niveau AA, qui servent de base légale en Europe via la norme EN 301 549 et le European Accessibility Act. C’est pour ça que, en France, on parle d’audit RGAA plutôt que d’audit WCAG : le référentiel français intègre automatiquement les normes internationales.

WCAG vs RGAA : les différences utiles à connaître

Vous vous demandez probablement “mais du coup, je suis censé suivre quoi, WCAG ou RGAA ?”. Pour un site ou un service numérique en France, la réponse est assez directe : on regarde le RGAA en priorité, tout en sachant qu’il s’appuie sur les WCAG 2.1 AA.

Référentiel	Portée	Structure	Usage en France
WCAG	International, utilisé par les gouvernements et entreprises dans de nombreux pays.	4 principes (POUR), critères de succès, niveaux A / AA / AAA.	Cadre général des normes d’accessibilité, référence technique de fond.
RGAA	Référentiel français officiel pour les services numériques.	106 critères vérifiables, 13 thématiques, méthode de calcul du taux de conformité.	Base des obligations légales, audit officiel et conformité RGAA.

Personnellement, je conseille toujours : en France, visez la conformité RGAA, vous serez automatiquement aligné sur les normes WCAG 2.1 niveau AA et donc sur les exigences européennes. Pour un rédacteur ou un responsable de site, ce choix n’est pas théorique : il influence la façon dont on écrit les pages, dont on structure les titres, dont on décrit les images. Ce n’est pas “juste du code”.

Qui doit respecter le RGAA et les WCAG en France ? Obligations sans langage d’avocat

Depuis la loi “handicap” de 2005, l’accessibilité numérique est une obligation légale pour les services publics. Cette obligation s’est renforcée avec la directive européenne 2016/2102 sur l’accessibilité des sites publics, puis avec l’European Accessibility Act, transposée en droit français, qui élargit le périmètre à certains services privés, notamment e-commerce, banques, transport et télécommunications.

En pratique, sont concernés :

• Les organismes publics : État, collectivités, établissements publics, sites institutionnels, intranets, applications mobiles… Ils doivent se conformer au RGAA, auditer leurs services, publier une déclaration d’accessibilité et afficher clairement leur niveau de conformité (“non conforme”, “partiellement conforme”, “totalement conforme”) sur la page d’accueil.
• Les grandes entreprises privées : en particulier celles dont le chiffre d’affaires dépasse 250 millions d’euros en France, et depuis 2025 beaucoup de sites e-commerce à cause de l’EAA.
• Les services concernés par l’EAA : e-commerce, services bancaires, transport, télécoms, livres numériques, médias audiovisuels, sauf microentreprises en dessous de seuils précis.

Ce qu’on vous demande concrètement :

• Réaliser un audit d’accessibilité (souvent un audit RGAA) pour évaluer le niveau réel de conformité de vos parcours principaux.
• Publier une déclaration d’accessibilité sincère, avec votre niveau de conformité, la liste des contenus non accessibles et un contact pour signaler les problèmes.
• Mettre en place un schéma pluriannuel et un plan d’action annuel pour traiter les écarts identifiés, puis suivre ce programme dans le temps.

Les sanctions administratives ne sont pas théoriques, et elles sont chiffrées dans la loi. L’article 47-1 de la loi de 2005 prévoit une sanction pouvant aller jusqu’à 50 000 € pour le non-respect de l’obligation d’accessibilité, et jusqu’à 25 000 € pour le non-respect des obligations déclaratives (déclaration d’accessibilité, schéma pluriannuel, plan d’action manquants). Ces sanctions interviennent après mise en demeure, et une nouvelle sanction peut être prononcée si le même manquement perdure six mois après la première. Depuis l’ordonnance du 6 septembre 2023, c’est l’Arcom qui met en demeure et prononce ces sanctions.

Mais au-delà de l’argent, la non-conformité a un coût en image de marque et en perte d’utilisateurs. Honnêtement, personne n’a envie d’apparaître comme l’entreprise qui exclut les personnes en situation de handicap de ses services.

Ce que les WCAG et le RGAA changent pour vos contenus

Beaucoup de problèmes d’accessibilité viennent du contenu, pas du serveur. Les WCAG et le RGAA impactent directement votre manière de rédiger et d’organiser les pages. C’est tout l’intérêt de parler d’contenu numérique inclusif.

Quelques impacts concrets :

• Des titres hiérarchisés : un seul titre principal, des sous-titres logiques, une structure claire qui aide autant les lecteurs que les moteurs de recherche.
• Des textes clairs : phrases raisonnables, jargon limité, explications concrètes, surtout sur les pages d’aide et les formulaires.
• Des liens explicites : “Télécharger le rapport annuel 2026” est beaucoup plus accessible que “cliquez ici”. Un lecteur d’écran peut lister les liens, et l’utilisateur comprend où il va.
• Des descriptions d’images : distinguer une image purement décorative (qu’on peut laisser silencieuse) d’une image porteuse d’information (qu’on doit décrire avec une alternative textuelle).
• Des sous-titres vidéo et des messages d’erreur détaillés : “Le champ email n’est pas valide, utilisez le format exemple@domaine.fr” aide vraiment, là où “Erreur” agace tout le monde.

Côté SEO, c’est tout bénéfice : un site accessible est souvent mieux structuré, plus clair, avec des titres cohérents et des contenus lisibles. Les moteurs de recherche adorent ce type de structuration, et la mesure de l’efficacité d’accessibilité rejoint souvent la mesure de l’efficacité UX et SEO.

Accessibilité côté interface : exemples concrets que tout le monde comprend

Pour visualiser l’impact, prenons quelques composants ultra courants : header, menu, boutons, formulaires, modales, pagination, bannière de consentement. Ce sont eux que l’on retrouve dans les critères techniques d’accessibilité et les audits RGAA.

Sur un menu de navigation, un site accessible :

• Accepte la navigation clavier de bout en bout (Tab, Entrée, etc.).
• Affiche un focus visible sur les éléments sélectionnés, pour que l’utilisateur sache où il se trouve.

Sur un bouton, un site accessible :

• Propose un libellé explicite (“Valider ma commande”, “Envoyer le message”), plutôt que “OK” dans tous les contextes.
• Utilise des couleurs contrastées pour que le texte reste lisible sur mobile comme sur desktop.

Sur une modale (popup), un site accessible :

• Annonce clairement la modale aux technologies d’assistance et bloque le fond pendant qu’elle est ouverte.
• Permet une fermeture au clavier, sans piéger l’utilisateur dans la fenêtre.

Le but, c’est que vous puissiez regarder votre propre site et vous dire : “OK, là, concrètement, une personne qui ne voit pas bien ou qui ne peut pas cliquer facilement, elle fait comment ?”. Si la réponse est “elle ne peut pas”, alors l’audit d’accessibilité vous le rappellera assez vite.

Webflow, WordPress, Wix : ce que votre CMS change (et ce qu’il ne change pas)

Question qui revient sans arrêt : « mon site est fait avec Webflow (ou WordPress, ou Wix) — est-il conforme au RGAA ? » La réponse tient en une phrase : aucun CMS n’est conforme ou non conforme en soi. Le RGAA et les WCAG évaluent le résultat livré au navigateur, pas l’outil qui l’a produit. Deux sites bâtis avec le même outil peuvent obtenir des taux de conformité très différents.

Ce que l’outil influence réellement, c’est la quantité de travail nécessaire pour y arriver, et l’endroit où se situent les points durs.

• Ce qui dépend du thème ou du gabarit : la structure des titres, la présence d’un vrai repère de navigation, le contraste par défaut, le focus clavier visible, les composants interactifs (menus déroulants, onglets, carrousels, fenêtres modales). C’est là que se concentrent la majorité des non-conformités, et c’est la partie la plus coûteuse à rattraper après coup — d’où l’intérêt de vérifier ces points avant de choisir un thème.
• Ce qui dépend de l’éditeur visuel : les constructeurs de pages laissent souvent choisir librement le niveau de titre pour des raisons de style, ce qui produit des hiérarchies incohérentes. Ils génèrent aussi facilement des blocs cliquables qui ne sont ni des liens ni des boutons : invisibles au clavier et pour les lecteurs d’écran.
• Ce qui dépend de vous, quel que soit l’outil : les alternatives textuelles des images, la pertinence des intitulés de liens, les libellés de champs de formulaire, les sous-titres des vidéos, la langue de la page. Aucun CMS ne les écrira à votre place.
• Ce que les extensions ne règlent pas : les surcouches qui promettent une mise en conformité automatique ne remplacent pas un audit. Elles peuvent améliorer certains réglages d’affichage, mais elles ne corrigent ni une structure de titres fausse, ni une alternative textuelle absente, ni un composant inutilisable au clavier — et une déclaration d’accessibilité doit refléter l’état réel du site, pas la présence d’un outil.

La démarche pratique est donc la même partout : on part des parcours principaux, on vérifie ce qui sort effectivement dans la page, et on corrige d’abord ce qui bloque totalement (navigation clavier impossible, information portée uniquement par la couleur, champ sans libellé) avant les écarts de confort.

Comment démarrer un audit accessibilité sans devenir expert technique

La bonne nouvelle, c’est qu’on n’a pas besoin d’être développeur pour repérer déjà une grosse partie des problèmes d’accessibilité, surtout côté contenu et parcours utilisateur. Un audit d’accessibilité, en réalité, c’est juste une méthode pour vérifier votre site par rapport à une série de critères, puis pour prioriser les corrections.

Les différents types de tests et audits d’accessibilité

On distingue généralement plusieurs approches :

• Tests automatiques d’accessibilité : des outils repèrent les problèmes évidents comme les images sans alternatives textuelles, les contrastes trop faibles, les erreurs de balisage ou les formulaires sans étiquettes.
• Audit guidé par un expert : un spécialiste vérifie la pertinence des textes alternatifs, la logique de navigation, les messages d’erreur, la cohérence des composants UI. C’est l’audit RGAA classique.
• Tests utilisateurs handicap : des personnes en situation de handicap testent les parcours (commande, contact, espace client) avec leurs outils (lecteurs d’écran, navigation clavier, commande vocale). Là, on touche l’expérience réelle.

Aucun outil automatique ne remplace l’humain. Les méthodes d’évaluation des performances d’accessibilité combinent toujours les deux : robots pour les erreurs “mécaniques”, experts et utilisateurs pour l’expérience. Les meilleurs programmes d’accessibilité travaillent avec cette double approche.

Premières actions simples pour rendre un contenu plus accessible

Si vous voulez agir dès maintenant, sans toucher au code, voici quelques gestes très concrets :

• Décrire les images importantes avec des alternatives textuelles précises (“Graphique montrant une hausse de 15 % des ventes en 2026” plutôt que “image1”).
• Tester vos pages au clavier : est-ce qu’on peut accéder à tous les liens, boutons et champs de formulaire sans souris ? Si non, il y a un problème.
• Vérifier les contrastes texte / arrière-plan grâce à un outil simple : si vos sous-titres sont en gris clair sur fond blanc, il faudra les renforcer.
• Utiliser des titres clairs, avec une structure logique : un h1 pour le sujet, des h2 pour les grandes parties, des h3 si besoin pour le détail.
• Éviter de mettre des informations importantes uniquement dans les images (comme des horaires ou des promotions) sans texte équivalent.

Pour les termes ARIA, imaginez simplement des “étiquettes invisibles” collées sur les éléments de la page pour que les lecteurs d’écran comprennent leur rôle (bouton, menu, onglet, alerte). Vous n’avez pas besoin de les maîtriser en détail pour comprendre le principe : on explique au logiciel ce que chaque élément fait, comme on étiqueterait des tiroirs dans un bureau.

Mettre l’accessibilité dans votre routine de publication (et éviter les régressions)

Le vrai enjeu, c’est la routine. L’environnement numérique inclusif, ce n’est pas un chantier unique tous les 10 ans, c’est une habitude de production. On refond rarement tout, mais on publie des contenus toutes les semaines, voire tous les jours. C’est là qu’on gagne ou qu’on perd en accessibilité.

Quelques réflexes utiles :

• Fixer des règles de rédaction pour les images (toujours une alternative utile pour les images d’information), les titres (structure logique), les liens (libellés explicites) et les formulaires (étiquettes et messages d’erreur clairs).
• S’appuyer sur un design accessible, avec des composants déjà validés : boutons, modales, champs de formulaire, bannière de consentement, pagination… Une fois les patterns accessibles, on les réutilise.
• Intégrer une mini “recette accessibilité” avant chaque mise en ligne : vérifier les contrastes, les alternatives textuelles, les messages d’erreur, les titres.
• Publier une déclaration d’accessibilité et la mettre à jour après chaque audit RGAA, avec un backlog de corrections priorisé par impact utilisateur.

Honnêtement, mieux vaut avancer étape par étape que viser les 106 critères RGAA en une fois. L’objectif n’est pas de devenir juriste ni spécialiste des normes d’accessibilité, mais d’ancrer un réflexe : chaque nouveau contenu doit respecter quelques règles simples d’accessibilité web. Si vous sentez que le sujet vous dépasse, travailler avec des experts de l’accessibilité n’est pas une faiblesse, c’est un gain de temps et de qualité.

La vraie question, maintenant, c’est : quel premier geste vous allez poser sur votre site cette semaine ? Une meilleure alternative d’image, un formulaire plus clair, un test clavier sur votre menu… Peu importe, tant que vous commencez. L’accessibilité numérique avance rarement par miracles spectaculaires, mais par petites corrections régulières qui, pour une personne en situation de handicap, font la différence entre “je peux utiliser ce service” et “je suis exclu”.

Questions fréquentes sur les WCAG et le RGAA

WCAG ou RGAA : lequel dois-je suivre en France ?

Le RGAA. Il reprend WCAG 2.1 niveau AA et y ajoute la méthode de test et de calcul du taux de conformité attendue par l’administration française. En le respectant, vous êtes aligné sur les WCAG sans avoir à mener deux démarches.

Un site Webflow ou WordPress peut-il être conforme au RGAA ?

Oui. La conformité s’évalue sur la page produite, pas sur l’outil. Ce qui varie d’un CMS à l’autre, c’est l’effort à fournir : le thème ou le gabarit choisi détermine une grande partie du résultat de départ.

Quelle différence entre WCAG 2.1 et WCAG 2.2 ?

WCAG 2.2 est une recommandation W3C depuis décembre 2024 ; elle ajoute des critères de succès sans annuler les versions précédentes, et un contenu conforme à 2.2 reste conforme à 2.1 et 2.0. Le référentiel français en vigueur s’appuie encore sur WCAG 2.1 AA.

Mon entreprise privée est-elle concernée ?

Deux régimes coexistent. Celui issu de la loi de 2005 vise les entreprises dont le chiffre d’affaires en France dépasse le seuil fixé par décret (250 millions d’euros). Celui issu de l’European Accessibility Act vise, indépendamment de ce seuil, une liste de services : commerce en ligne, banque, transport, télécommunications, livres numériques, avec des exemptions pour les microentreprises. Beaucoup de sites marchands relèvent du second sans relever du premier.