Votre site est-il lisible par quelqu'un qui ne voit pas l'écran ?
Combien de vos visiteurs naviguent au clavier, utilisent un lecteur d'écran ou peinent à lire un gris clair sur fond blanc ? Personne ne le sait, parce qu'ils partent sans rien dire. Le RGAA existe pour que ce départ silencieux cesse. Et depuis juin 2025, l'accessibilité web n'est plus une obligation réservée au secteur public et aux très grandes entreprises : elle s'impose à une part croissante des entreprises.
Dans cet article, vous allez découvrir :
- •Ce qu'est vraiment le RGAA, et ce qui le distingue des WCAG
- •Qui est concerné par la loi française et la réglementation européenne
- •Les 4 principes et les 3 niveaux qui structurent tout audit d'accessibilité
- •Les 7 erreurs que nous retrouvons sur presque tous les sites de PME
- •Comment un site Next.js se met en conformité, et ce que cela rapporte en SEO
L'accessibilité n'est pas une couche que l'on ajoute à la fin. C'est la qualité du code HTML que Google lit déjà, et que vos visiteurs subissent déjà.
RGAA : définition et rapport avec les WCAG
Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le référentiel officiel français qui permet de vérifier qu'un site ou une application web est accessible aux personnes en situation de handicap. Il est publié et maintenu par l'État (DINUM), et sa version 4 (4.1.2 au moment où nous écrivons) est la référence ; la version en vigueur est consultable sur le site officiel accessibilite.numerique.gouv.fr.
Le RGAA ne réinvente rien : il décline les WCAG (Web Content Accessibility Guidelines), le standard international publié par le W3C, en une méthode de test applicable au droit français. Le RGAA 4 s'appuie sur les WCAG 2.1 et vise le niveau AA.
La différence tient à la nature des deux documents :
| WCAG | RGAA | |
|---|---|---|
| Auteur | W3C (standard international) | État français (DINUM) |
| Nature | Recommandations et critères de succès | Méthode technique de vérification |
| Structure | 4 principes, 13 règles, critères A, AA, AAA | 13 thématiques, 106 critères, tests détaillés |
| Usage | Référence mondiale, base des lois nationales | Audit de conformité opposable en France |
Qui est concerné, et depuis quand ?
Deux cadres juridiques coexistent en France. Nous décrivons ici les principes ; pour toute décision, référez-vous aux textes officiels publiés sur Légifrance et sur le site de la DINUM, qui font foi.
Le cadre français : la loi de 2005
L'article 47 de la loi du 11 février 2005 pour l'égalité des droits et des chances impose l'accessibilité des services de communication au public en ligne. Historiquement centrée sur les administrations et les organismes publics, cette obligation a été étendue par la loi pour une République numérique de 2016, puis précisée par un décret de 2019, aux délégataires de service public et aux entreprises dont le chiffre d'affaires en France dépasse 250 millions d'euros. Les sites concernés doivent publier une déclaration d'accessibilité, afficher leur niveau de conformité sur la page d'accueil et tenir un schéma pluriannuel de mise en accessibilité.
Pour la grande majorité des PME, cette première obligation ne s'applique pas directement. Elle a toutefois fixé la méthode : le RGAA est la grille de référence pour tout audit en France. Et hors obligation, l'accessibilité reste un avantage concurrentiel : plus de visiteurs servis, un code plus propre, un meilleur référencement.
Le cadre européen : l'acte européen sur l'accessibilité
La directive européenne 2019/882, dite European Accessibility Act, change l'échelle. Transposée en droit français par la loi du 9 mars 2023 et son décret d'application du 9 octobre 2023, elle s'applique depuis le 28 juin 2025 à une liste de produits et services définis par le texte : commerce électronique, services bancaires aux consommateurs, transport de passagers, communications électroniques, livres numériques, entre autres.
Deux points à retenir, en restant prudent sur le détail :
- •Le secteur prime sur la taille. Une boutique en ligne entre dans le périmètre du commerce électronique, quelle que soit la notoriété de l'entreprise, sous réserve de l'exemption ci-dessous.
- •Une exemption existe pour les micro-entreprises qui fournissent des services (moins de 10 personnes et chiffre d'affaires annuel ou total de bilan n'excédant pas 2 millions d'euros, selon la définition reprise par la directive). Elle ne couvre pas tout le monde.
Les manquements peuvent faire l'objet de sanctions administratives, dont des amendes, prononcées par les autorités de contrôle désignées. Montants, procédures et délais de mise en conformité sont fixés par les textes : vérifiez-les avec votre conseil juridique plutôt que de vous fier à un chiffre lu sur un blog, y compris celui-ci.
Les 4 principes et les 3 niveaux à connaître
Tout le référentiel se résume à quatre principes, hérités des WCAG. Un contenu accessible doit être :
- 1.Perceptible : l'information peut être perçue par au moins un sens. Une image a une alternative textuelle, une vidéo des sous-titres, un texte un contraste suffisant.
- 2.Utilisable : toutes les fonctionnalités sont opérables au clavier, sans limite de temps piégeuse, avec une navigation prévisible.
- 3.Compréhensible : la langue est déclarée, les libellés sont clairs, les erreurs de formulaire sont expliquées, l'interface se comporte de façon cohérente.
- 4.Robuste : le code est valide et interprétable par les navigateurs comme par les technologies d'assistance.
Les critères se répartissent ensuite en trois niveaux :
| Niveau | Ce qu'il couvre | Statut en France |
|---|---|---|
| A | Le minimum sans lequel certains utilisateurs sont totalement bloqués | Inclus dans la cible |
| AA | Le niveau exigé par le RGAA : contrastes, redimensionnement du texte, navigation cohérente | Cible légale |
| AAA | Niveau d'excellence (langue des signes, contrastes renforcés) | Non exigé |
Les erreurs les plus fréquentes sur les sites de PME
Nous auditons régulièrement des sites vitrines et des applications métier avant refonte. Les mêmes défauts reviennent, et aucun n'est difficile à corriger quand il est pris au bon moment. Le constat dépasse nos clients : l'étude WebAIM Million relevait en 2025 des erreurs WCAG détectables automatiquement sur près de 95 % du million de pages d'accueil testées.
1. Les contrastes insuffisants
Le gris clair sur blanc, si élégant sur la maquette, est le critère le plus souvent échoué. Le niveau AA exige un ratio de 4,5:1 pour le texte courant et de 3:1 pour les grands textes et les composants d'interface.
2. Les images sans alternative textuelle
Un attribut alt absent, vide alors que l'image porte du sens, ou rempli avec le nom du fichier. Un lecteur d'écran lit soit rien, soit du bruit. À l'inverse, une image décorative doit avoir un alt="" explicite pour être ignorée.
3. Les liens et boutons sans intitulé
« En savoir plus » répété huit fois, des icônes cliquables sans libellé, des boutons construits avec des <div> que le clavier ne peut pas atteindre. L'utilisateur d'un lecteur d'écran entend « lien, lien, lien » sans savoir où il va.
4. Les formulaires sans étiquettes
Un champ dont le seul libellé est le placeholder, qui disparaît dès que l'on tape. Des erreurs signalées uniquement par une bordure rouge. Des champs obligatoires marqués par une astérisque jamais expliquée.
5. La navigation clavier cassée
Le focus invisible (un outline: none ajouté pour « faire propre », sans style de remplacement), des menus qui ne s'ouvrent qu'au survol de la souris, des modales dont on ne sort pas avec Échap.
6. La structure de titres incohérente
Des <h3> choisis pour leur taille et non pour leur niveau, plusieurs <h1> par page. Les utilisateurs de lecteurs d'écran naviguent de titre en titre ; une hiérarchie désordonnée les perd. Google aussi.
7. La langue non déclarée
Un attribut lang manquant sur la balise <html> fait lire du français avec une prononciation anglaise. Le correctif tient en un mot ; l'oubli est pourtant très courant.
À lire aussi : Éco-conception web : green code label 2026 - Un site sobre et un site accessible reposent sur la même exigence : un code HTML propre, léger et structuré.
Comment un site Next.js se met en conformité RGAA
Un framework ne rend pas un site accessible par magie. Mais Next.js et React permettent d'ancrer l'accessibilité dans le code plutôt que de la rattraper après coup. Voici comment nous procédons sur les projets livrés dans le cadre de notre offre de création de site internet sur-mesure.
Sémantique HTML d'abord, ARIA ensuite
React pousse à empiler des <div>. Nous imposons la règle inverse : chaque composant rend l'élément HTML natif qui correspond à sa fonction. Un bouton est un <button>, une navigation un <nav>, un contenu principal un <main>. Les éléments natifs embarquent gratuitement la gestion du focus, du clavier et des rôles.
ARIA n'intervient qu'en complément, quand aucun élément natif ne couvre le besoin : aria-expanded sur un accordéon, aria-live sur une zone qui annonce un résultat, aria-describedby pour lier un champ à son message d'erreur. Le premier principe d'ARIA reste : si vous pouvez ne pas l'utiliser, ne l'utilisez pas.
Les contrastes dans le design system
Les couleurs ne se décident pas composant par composant. Elles vivent dans des tokens (variables Tailwind ou CSS custom properties) validés une fois pour toutes avec un ratio AA. Personne ne choisit un gris au hasard dans une maquette.
C'est ce que nous avons appliqué pour Enovacom : un design system de 70 composants harmonisant 10 applications dans le secteur de la santé. Quand les contrastes, les états de focus et les tailles de cible sont fixés au niveau du composant, chaque application qui l'utilise hérite de la conformité. Cohérence d'interface et accessibilité sont le même sujet.
La navigation clavier et le focus
Sur un site Next.js, trois points demandent une attention particulière :
- •Le lien d'évitement (« Aller au contenu ») placé en premier dans le DOM, visible au focus.
- •La gestion du focus lors des changements de route. En navigation côté client, la page change sans rechargement et le focus reste perdu sur l'ancien lien. Nous le replaçons sur le titre principal ou le conteneur
<main>à chaque navigation. - •Les composants interactifs (modales, menus, onglets) qui piègent le focus à l'ouverture, le libèrent à la fermeture et répondent à Échap. Des bibliothèques comme Radix UI ou Headless UI le font correctement ; nous les privilégions aux composants maison.
Les formulaires
Chaque champ possède un <label> relié par son attribut for. Les messages d'erreur sont des textes liés au champ par aria-describedby, pas seulement une couleur. Les champs invalides portent aria-invalid="true", les groupes de boutons radio un <fieldset> et une <legend>. Et le formulaire reste soumissible au clavier.
Les images
Le composant next/image exige l'attribut alt : un bon garde-fou, qui oblige à se poser la question. Reste à y répondre correctement. Une image informative décrit ce qu'elle apporte ; une image décorative reçoit alt="" ; une image-lien décrit la destination, pas l'image.
Les tests automatisés, puis les tests humains
Nous intégrons des tests d'accessibilité automatisés sur notre propre site : analyse axe-core sur les pages clés, audit Lighthouse dans le pipeline de déploiement, lint des règles JSX accessibles. Une régression détectable bloque la mise en production.
Mais soyons clairs : les outils automatiques ne détectent qu'une partie des critères RGAA. Ils voient qu'un alt manque, pas qu'il est faux. Un parcours complet au clavier et une session avec un lecteur d'écran (VoiceOver, NVDA) restent indispensables avant toute déclaration de conformité. C'est ce que couvre notre audit de code et d'accessibilité : la partie que les robots ne voient pas.
Ce que l'accessibilité apporte à votre SEO
Google ne lit pas votre site comme un humain voyant. Il le lit comme un lecteur d'écran : par le DOM, les balises, les attributs, le texte. Chaque critère RGAA que vous respectez améliore donc la façon dont le moteur comprend vos pages :
- •La hiérarchie de titres structure la compréhension thématique de la page par Google, comme elle structure la navigation d'un lecteur d'écran.
- •Les alternatives textuelles sont la principale information que Google Images exploite pour comprendre une image.
- •Les intitulés de liens descriptifs transmettent du sens aux pages liées. « Découvrir notre audit RGAA » vaut infiniment plus que « cliquez ici ».
- •Le HTML sémantique (
<nav>,<main>,<article>) aide Google à distinguer le contenu principal de l'habillage.
Le lien n'est pas mécanique : Google ne mesure pas un « score RGAA ». Mais tout ce que vous faites pour un utilisateur non voyant, vous le faites pour un robot d'indexation qui, lui non plus, ne voit pas votre écran. Ajoutez un public élargi, et l'accessibilité devient un des investissements SEO les plus rentables.
FAQ : vos questions sur le RGAA et l'accessibilité web
Notre agence React intègre l'accessibilité dès les composants : HTML sémantique, gestion du focus et attributs ARIA sont écrits une fois et réutilisés sur toute l'interface.
Le RGAA est-il obligatoire pour une PME ?
Quelle différence entre RGAA et WCAG ?
Combien coûte un audit d'accessibilité RGAA ?
Un outil automatique suffit-il pour être conforme ?
L'accessibilité dégrade-t-elle le design ?
Conclusion : l'accessibilité se décide au moment où l'on écrit le code
Le RGAA n'est pas une case à cocher pour les juristes. C'est la grille qui révèle si votre site est construit proprement, pour tous vos visiteurs et pour les moteurs qui les précèdent. Dans le périmètre réglementaire ou non, la démarche est la même : auditer, corriger ce qui bloque, puis verrouiller la conformité dans le design system et dans les tests.
Vous voulez savoir où en est votre site face au RGAA, et ce qu'il faudrait pour le rendre accessible sans tout reconstruire ? Parlons-en lors d'un échange sans engagement : nous vous dirons ce qui bloque, et par quoi commencer.
