RGAA 4.1 : comment auditer l'accessibilité de son site web (méthodo + outils)

#Qu'est-ce que le RGAA 4.1 et son lien avec les WCAG 2.1 ?

Le RGAA (Référentiel Général d'Amélioration de l'Accessibilité) est le standard officiel français d'accessibilité numérique, publié et maintenu par la DINUM (Direction interministérielle du numérique). La version 4.1, publiée en 2021, constitue la référence en vigueur.

Le RGAA n'invente pas ses propres règles : il opérationnalise les WCAG 2.1 (Web Content Accessibility Guidelines) du W3C pour les rendre applicables concrètement par les équipes techniques et éditoriales françaises. Là où les WCAG formulent des critères de succès en anglais et sous forme de principes abstraits, le RGAA les traduit en tests de contrôle précis, avec des méthodes de test définies et des conditions de validation explicites.

Les quatre principes fondateurs des WCAG — et donc du RGAA — se résument par l'acronyme POUR :

• Perceptible : l'information doit être présentable à tous les utilisateurs, quels que soient leurs sens fonctionnels
• Utilisable : les composants d'interface et la navigation doivent être opérables
• Compréhensible : l'information et l'interface doivent être compréhensibles
• Robuste : le contenu doit être suffisamment robuste pour être interprété par les technologies d'assistance

Le niveau de conformité exigé par le RGAA est le niveau AA des WCAG — ni le niveau A (exigences minimales), ni le niveau AAA (exigences maximales souvent inapplicables à l'ensemble d'un site). Le niveau AA représente le point d'équilibre entre accessibilité réelle pour la grande majorité des utilisateurs en situation de handicap et faisabilité technique.

#Les technologies d'assistance concernées

L'accessibilité numérique vise l'ensemble des situations de handicap : visuel (cécité, malvoyance, daltonisme), auditif (surdité, malentendance), moteur (navigation au clavier uniquement, dispositifs alternatifs à la souris), cognitif (dyslexie, troubles de l'attention) et neurologique. Les lecteurs d'écran (NVDA, JAWS, VoiceOver), les plages braille, les logiciels de navigation au clavier et les outils de grossissement constituent les principales technologies d'assistance à prendre en compte lors de l'audit.

#Qui est obligé par le RGAA ?

Le cadre législatif français de l'accessibilité numérique repose sur la loi n° 2005-102 du 11 février 2005 pour l'égalité des droits et des chances des personnes handicapées, renforcée par l'ordonnance n° 2023-857 du 6 septembre 2023 qui a étendu le périmètre d'obligation.

#Les administrations publiques (obligation depuis 2012)

Sont obligatoirement soumises au RGAA :

• L'État, les collectivités territoriales et leurs groupements
• Les établissements publics
• Les organismes chargés d'une mission de service public
• Les services de communication audiovisuelle publics

Cela couvre l'intégralité des mairies, départements, régions, ministères, universités, hôpitaux publics et services de l'État qui disposent d'un site web ou d'une application mobile.

#Les entreprises privées (obligation étendue en 2023)

Depuis le 28 juin 2023, les entreprises dont le chiffre d'affaires annuel dépasse 250 millions d'euros sont également soumises à l'obligation de conformité RGAA pour leurs sites web, applications mobiles et logiciels. Cette extension est issue de la transposition de la directive européenne (UE) 2019/882 sur les exigences en matière d'accessibilité.

En pratique, cette obligation concerne les grands groupes industriels, les retailers en ligne de grande taille, les banques et assurances, les opérateurs télécoms et les plateformes numériques à fort trafic. Les éditeurs de logiciels servant ces organisations sont également concernés.

#Les 106 critères RGAA 4.1 organisés en 13 thématiques

Le RGAA 4.1 structure ses exigences en 13 thématiques, chacune couvrant un aspect spécifique de l'accessibilité. Ces thématiques regroupent au total 106 critères de contrôle.

#Thématique 1 — Images (9 critères)

Alternatives textuelles des images informatives, images décoratives avec attribut alt vide, images-liens, images-captchas, images porteuses d'information via attribut CSS. Chaque image doit disposer d'une alternative appropriée à sa fonction.

#Thématique 2 — Cadres (4 critères)

Titres des <iframe> et <frame>, pertinence des titres de cadres. Les cadres intégrant des contenus tiers (vidéos, cartes, formulaires) sont particulièrement concernés.

#Thématique 3 — Couleurs (5 critères)

Contraste entre le texte et son arrière-plan (ratio minimum 4,5:1 pour le texte normal, 3:1 pour le grand texte), information transmise uniquement par la couleur. Ce critère est l'un des plus fréquemment échoués dans les audits.

#Thématique 4 — Multimédia (13 critères)

Sous-titres et transcriptions des vidéos, audio-descriptions, accessibilité des lecteurs média (navigation au clavier, contrôle du son), absence de contenu en autoplay sans contrôle utilisateur.

#Thématique 5 — Tableaux (5 critères)

En-têtes de colonnes et de lignes correctement marqués (<th> avec attributs scope ou id/headers), résumés des tableaux complexes, absence de tableaux de mise en page.

#Thématique 6 — Liens (9 critères)

Intitulés explicites des liens (hors contexte de la phrase), liens dont l'intitulé n'est pas pertinent mais dont le contexte l'est, liens d'évitement ou de navigation rapide, liens vers de nouveaux onglets avec avertissement.

#Thématique 7 — Scripts (9 critères)

Accessibilité au clavier des composants JavaScript interactifs (menus déroulants, modales, onglets, carrousels), compatibilité des scripts avec les technologies d'assistance, messages de statut programmatiques.

#Thématique 8 — Éléments obligatoires (8 critères)

Langue de la page (lang sur <html>), titre de la page (<title> unique et pertinent), ordre de tabulation cohérent, présence d'une page d'aide à l'accessibilité, validité du code source (critère supprimé en RGAA 4.1 mais recommandé).

#Thématique 9 — Structuration (7 critères)

Hiérarchie des titres (<h1> à <h6>) cohérente et exhaustive, utilisation des listes (<ul>, <ol>, <dl>), citations (<blockquote>, <q>). Une structure sémantique correcte bénéficie à la fois aux lecteurs d'écran et au SEO.

#Thématique 10 — Présentation de l'information (12 critères)

Redimensionnement des textes jusqu'à 200% sans perte de contenu, contenus lisibles sans feuille de style CSS, absence de textes justifiés sans option de désactivation, espacement entre les lignes, lettres et mots modifiable sans perte de contenu.

#Thématique 11 — Formulaires (15 critères)

Étiquetage des champs (<label> lié via for/id), regroupement des champs connexes (<fieldset>/<legend>), messages d'erreur explicites et rattachés au champ concerné, auto-complétion activée pour les champs personnels.

#Thématique 12 — Navigation (12 critères)

Présence de plusieurs systèmes de navigation (menu, plan du site, moteur de recherche), plan du site accessible, navigation cohérente entre les pages, liens d'évitement fonctionnels.

#Thématique 13 — Consultation (8 critères)

Absence de limites de temps sans avertissement ni possibilité de prolongation, absence de contenu en mouvement automatique sans contrôle, absence de clignotements à plus de 3 Hz (risque épileptique), accessibilité des documents en téléchargement (PDF, Word).

#Méthodologie d'audit RGAA en 5 étapes

#Étape 1 — Définition du périmètre d'audit

Avant de tester le moindre critère, l'équipe d'audit doit délimiter précisément ce qui sera audité. Le périmètre inclut :

• Les services numériques visés (site web institutionnel, application mobile, intranet, extranet)
• La version du service auditée (version desktop uniquement, ou desktop + mobile)
• L'environnement de test : couple navigateur + système d'exploitation + technologie d'assistance (par exemple : Firefox 120 + Windows 11 + NVDA 2023, et Safari + macOS + VoiceOver)

Le choix de l'environnement de test n'est pas libre : le RGAA définit dans sa documentation technique un ensemble de combinaisons de test validées à utiliser.

#Étape 2 — Constitution de l'échantillon de pages

L'audit ne peut pas couvrir l'intégralité des pages d'un site. Le RGAA préconise un échantillon représentatif comprenant au minimum :

• La page d'accueil
• Le plan du site
• La page de contact
• La page d'aide ou FAQ
• La page de mentions légales et déclaration d'accessibilité
• Au moins un exemple de chaque type de page : page de contenu éditorial, page de liste/catalogue, page de formulaire, page avec tableaux de données, page avec multimédia
• Les pages les plus visitées selon les données analytiques

Un échantillon de 20 à 30 pages est généralement retenu pour un site institutionnel de taille standard. Pour les applications web complexes, l'échantillon doit inclure les principaux écrans applicatifs (tableau de bord, formulaire de saisie, résultats de recherche).

#Étape 3 — Tests manuels

La majorité des critères RGAA ne peut pas être vérifiée par des outils automatiques. Les tests manuels représentent 60 à 70 % du travail d'audit. Ils impliquent :

• L'inspection du code source HTML (via les DevTools du navigateur)
• La navigation au clavier sur l'ensemble des fonctionnalités
• Les tests avec un lecteur d'écran (NVDA sous Windows, VoiceOver sous macOS/iOS)
• La vérification des contrastes avec un outil de mesure
• Le contrôle de la cohérence sémantique (titres, listes, tableaux)

Chaque critère est évalué manuellement page par page selon sa fiche de test officielle disponible sur accessibilite.numerique.gouv.fr. Le résultat est conforme, non conforme ou non applicable (si le critère ne s'applique pas à la page).

#Étape 4 — Tests avec outils automatisés

Les outils automatiques permettent de détecter rapidement certaines catégories d'erreurs et de couvrir un grand nombre de pages en peu de temps. Ils complètent les tests manuels sans les remplacer. Les principaux outils utilisés dans les audits RGAA :

Axe DevTools (Deque Systems) Extension Chrome/Firefox. Détecte environ 30 à 40 % des erreurs d'accessibilité automatiquement : attributs alt manquants, contrastes insuffisants, rôles ARIA incorrects, labels de formulaires absents. Version gratuite disponible, version Pro avec tests guidés.

WAVE (WebAIM) Extension navigateur avec retour visuel direct sur la page. Affiche les erreurs, alertes et éléments structurels (headings, landmarks, liens) directement incrustés dans la page. Particulièrement pédagogique pour les équipes non techniques.

Arc Toolkit (TPGi) Extension Chrome orientée audit professionnel. Tests spécifiques sur les lecteurs d'écran, ARIA live regions, gestion du focus. Complémentaire à Axe pour les composants JavaScript complexes.

Tanaguru Solution open source française développée spécifiquement pour le RGAA. Permet l'audit automatisé en masse de sites entiers avec génération de rapports au format RGAA. Disponible en mode SaaS ou auto-hébergé.

Contrast Checker (WebAIM / Colour Contrast Analyser) Outil dédié à la vérification des ratios de contraste entre texte et arrière-plan. Le Colour Contrast Analyser (outil desktop de TPGi) permet de mesurer les contrastes sur n'importe quel élément de l'écran, y compris les images et les SVG.

#Étape 5 — Rédaction de la déclaration d'accessibilité

La déclaration d'accessibilité est le document officiel qui conclut l'audit. Elle doit être publiée sur le site concerné (généralement depuis un lien dans le pied de page) et mise à jour à chaque audit significatif.

La déclaration doit obligatoirement mentionner :

• L'état de conformité : totalement conforme (100 % des critères applicables satisfaits), partiellement conforme (50 % minimum), ou non conforme
• Le taux de conformité calculé sur l'ensemble des critères applicables de l'échantillon
• Les non-conformités : liste des critères échoués avec description des difficultés rencontrées par les utilisateurs
• Les contenus exemptés : les dérogations pour charge disproportionnée dûment justifiées
• Les technologies utilisées pour la création du site
• L'environnement de test utilisé pour l'audit
• Les outils utilisés pour évaluer l'accessibilité
• Les pages de l'échantillon ayant servi à la déclaration de conformité
• Les coordonnées du contact accessibilité (personne ou formulaire dédié)
• Les voies de recours : Défenseur des droits, juridictions compétentes

Le modèle officiel de déclaration est disponible sur le site de la DINUM.

#Les niveaux de conformité RGAA : A, AA, AAA

Les WCAG 2.1 — et par extension le RGAA — définissent trois niveaux de conformité croissants :

Niveau A — exigences minimales Le niveau A couvre les erreurs les plus bloquantes : absence d'alternatives textuelles, navigation au clavier impossible, vidéos sans sous-titres. Un site ne satisfaisant pas le niveau A est quasiment inutilisable pour les personnes en situation de handicap lourd. Le RGAA exige ce niveau comme plancher.

Niveau AA — exigences standard (niveau requis par le RGAA) Le niveau AA ajoute les exigences de contraste des couleurs, l'absence de perte de contenu lors du redimensionnement, des messages d'erreur de formulaires explicites, la cohérence de la navigation entre pages. C'est le niveau exigé par le RGAA pour les organismes assujettis. Un taux de conformité de 100 % des critères AA applicables est l'objectif à atteindre.

Niveau AAA — exigences avancées (non requis, recommandé pour les services publics prioritaires) Le niveau AAA inclut des exigences très strictes (langue des signes pour toutes les vidéos, contraste 7:1 pour les textes normaux, absence de toute limite de temps). Le W3C lui-même reconnaît qu'il n'est pas réaliste d'atteindre le niveau AAA pour l'ensemble d'un site. Certains services publics prioritaires (services d'urgence, plateforme Ameli) visent néanmoins des critères AAA spécifiques.

#Déclaration d'accessibilité obligatoire : contenu et publication

La déclaration d'accessibilité est une obligation légale en France depuis le décret n° 2019-768 du 24 juillet 2019. Son absence constitue en elle-même une non-conformité, indépendamment du niveau d'accessibilité réel du site.

Elle doit être :

• Facilement accessible : lien depuis toutes les pages du site (pied de page recommandé)
• Mise à jour au moins une fois par an (ou après chaque audit significatif)
• Publiée en ligne et non uniquement disponible sur demande
• Rédigée en français pour les services destinés au public français

Le formulaire de déclaration standardisé fourni par la DINUM à l'adresse accessibilite.numerique.gouv.fr/déclaration génère automatiquement une déclaration conforme au format attendu par les superviseurs.

Le mécanisme de signalement est un élément souvent oublié : la déclaration doit indiquer un moyen de contact permettant aux utilisateurs de signaler des obstacles d'accessibilité et d'obtenir une alternative accessible. Ce contact doit être réactif — un délai de réponse raisonnable est attendu.

#Sanctions pour non-conformité : jusqu'à320 000 €

Le cadre répressif de l'accessibilité numérique en France est défini par le décret n° 2019-768 et les arrêtés associés. La supervision est assurée par l'ARCOM (Autorité de régulation de la communication audiovisuelle et numérique) pour les services de communication audiovisuelle, et par le ministère chargé du numérique pour les autres organismes.

Les sanctions encourues :

• Amende administrative jusqu'à 20 000 euros par service numérique non conforme
• Astreinte pouvant atteindre 2 000 euros par jour en cas de non-régularisation après mise en demeure
• Obligation de publication d'un plan de mise en conformité sous 18 mois

Le mécanisme de sanction fonctionne en deux temps : une mise en demeure est d'abord notifiée, laissant un délai pour se mettre en conformité. L'amende est prononcée seulement en cas de non-régularisation dans le délai imparti. En pratique, les premières mises en demeure ont visé des organismes publics disposant de délais depuis longtemps dépassés.

Le Défenseur des droits peut également être saisi par tout utilisateur rencontrant un obstacle d'accessibilité, notamment lorsque le mécanisme de signalement prévu dans la déclaration n'a pas reçu de réponse satisfaisante.

#Cas pratique : audit d'une page de formulaire — 10 erreurs fréquentes

La thématique «Formulaires» (15 critères) est statistiquement l'une des plus défaillantes dans les audits RGAA. Voici les 10 erreurs les plus fréquentes observées lors de l'audit d'une page de formulaire de contact ou de devis :

Erreur 1 — Champs sans étiquette programmatique Le champ <input> est accompagné d'un texte visible (placeholder ou texte adjacent), mais sans balise <label> liée via for/id. Le lecteur d'écran annonce «champ de saisie» sans préciser ce qui est attendu.

Erreur 2 — Placeholder utilisé comme seul étiquetage Le placeholder disparaît dès que l'utilisateur commence à saisir. Il ne peut pas servir d'étiquette permanente. Les personnes avec troubles cognitifs, et les utilisateurs qui reviennent sur le champ après l'avoir rempli, perdent le contexte.

Erreur 3 — Champs obligatoires non identifiés programmatiquement L'astérisque visuel ne suffit pas. L'attribut required (HTML5) ou aria-required="true" doit être présent. Sans lui, le lecteur d'écran n'avertit pas l'utilisateur avant la soumission.

Erreur 4 — Messages d'erreur non reliés au champ Après soumission du formulaire, le message d'erreur «Ce champ est obligatoire» apparaît visuellement à côté du champ, mais sans liaison programmatique (aria-describedby ou aria-errormessage). Le lecteur d'écran ne fait pas le lien entre l'erreur et le champ concerné.

Erreur 5 — Focus non géré sur les erreurs Après soumission avec erreurs, la page ne recentre pas le focus sur le récapitulatif des erreurs ou le premier champ erroné. L'utilisateur naviguant au clavier ne sait pas que des erreurs se sont produites.

Erreur 6 — Captcha inaccessible Le recaptcha visuel sans alternative audio bloque complètement les utilisateurs aveugles. Une alternative non visuelle (recaptcha audio, alternative textuelle, token honeypot) est obligatoire.

Erreur 7 — Groupement de cases à cocher sans <fieldset>/<legend> Un groupe de cases à cocher «Vos centres d'intérêt» sans <fieldset> et <legend> associés prive les lecteurs d'écran du contexte de groupe. Chaque case est annoncée isolément, sans référence à la question posée.

Erreur 8 — Listes déroulantes sans étiquette La balise <select> pour le choix d'un département ou d'un sujet de contact sans <label> associé est un cas très fréquent. La valeur par défaut «Choisissez...» n'est pas une étiquette.

Erreur 9 — Bouton de soumission avec texte non descriptif Un bouton <input type="submit" value="OK"> ou <button>Envoyer</button> sans contexte supplémentaire est ambigu dans un formulaire multi-étapes. La valeur du bouton doit décrire l'action ("Envoyer le message", "Valider ma demande de devis").

Erreur 10 — Auto-complétion désactivée sur les champs personnels L'attribut autocomplete doit être renseigné pour les champs nom, prénom, adresse, email, téléphone. Sa désactivation force les utilisateurs avec troubles moteurs à ressaisir manuellement leurs informations à chaque formulaire.

Ces 10 erreurs sont toutes détectables par un audit RGAA standard et corrigeables dans des délais raisonnables par une équipe frontend.

#Accompagnement Nehos : audit RGAA et roadmap de mise en conformité

Nehos accompagne les administrations, collectivités et entreprises dans leur démarche d'accessibilité numérique selon une approche structurée en trois phases.

Phase 1 — Audit RGAA complet

Nous réalisons un audit de conformité RGAA 4.1 sur l'échantillon de pages représentatif de votre service numérique. L'audit couvre les 106 critères selon la méthodologie officielle DINUM, avec tests manuels (navigation clavier, lecture d'écran NVDA/VoiceOver) et tests automatisés (Axe DevTools, WAVE, Tanaguru). Le livrable est un rapport d'audit détaillé avec taux de conformité par thématique et liste des non-conformités classées par criticité.

Phase 2 — Roadmap de mise en conformité

À partir du rapport d'audit, nous construisons une roadmap de correction priorisée selon deux axes : l'impact sur les utilisateurs (erreurs bloquantes vs. gênantes) et l'effort de correction (développement simple vs. refonte structurelle). La roadmap est découpée en sprints réalisables, avec critères d'acceptation pour chaque correction.

Phase 3 — Rédaction de la déclaration d'accessibilité

Nous rédigeons la déclaration d'accessibilité conforme au modèle DINUM, prête à être publiée sur votre site. Elle intègre le taux de conformité final, les non-conformités résiduelles documentées, les dérogations pour charge disproportionnée justifiées et les coordonnées du contact accessibilité.

Nos équipes maîtrisent également les exigences d'accessibilité des documents PDF et des applications mobiles (iOS/Android), soumises aux mêmes obligations depuis 2019.