RGAA 5 : ce qu'on sait, ce qu'on devine, et ce qu'on peut faire dès maintenant

Le RGAA 5 est annoncé pour fin 2026.

Prenons ça comme une intention plus que comme un engagement : la version définitive est plutôt à attendre en 2027. Cependant, rien ne nous empêche de prendre les devants : son contenu se dessine déjà et ses nouvelles exigences sont des bonnes pratiques que l’on peut mettre en place dès maintenant.

On fait le point : pourquoi cette nouvelle version, et ce qui change pour les équipes, calendrier compris.

Note : le texte du RGAA 5 n'est pas encore public, tout ce qui suit vient des communications de la DINUM et de sources non officielles, à confirmer à la publication du texte.

Historique : de la loi de 2005 au RGAA 4.1.2

Le RGAA découle de l’article 47 de la loi du 11 février 2005, qui rend l’accessibilité obligatoire pour les services en ligne publics. La version en vigueur est le RGAA 4.1.2, mis à jour le 18 avril 2023, quelques mois avant la publication des WCAG 2.2 le 5 octobre 2023.

Côté réglementation, trois textes ont fait évoluer les obligations d’accessibilité numérique ces dernières années :

• L’ordonnance du 6 septembre 2023 qui confie à l’Arcom le contrôle du respect de ces obligations.
• Le décret du 9 octobre 2023 qui étend les obligations à de nouveaux secteurs, comme la banque, les transports ou le commerce électronique.
• La directive européenne 2019/882 (EAA) qui impose des exigences d’accessibilité à certains produits et services du secteur privé. Elle s’applique depuis le 28 juin 2025.

Le RGAA 5 arrivera avec davantage d’acteurs concernés et un contrôle mieux identifié.

Pourquoi une nouvelle version ?

Parce que le RGAA 4.1.2 a pris un peu de retard sur son propre standard de référence. À peine 6 mois après la publication de la dernière version du RGAA sortaient les WCAG 2.2 et avec eux, 9 nouveaux critères qui n’ont donc pas été prévus par le référentiel français.

Le RGAA 5 répond à quatre besoins:

• Rattraper le WCAG 2.2 : La DINUM confirme que le RGAA 5 intègre les WCAG 2.2 et reformule et simplifie les critères. Le niveau visé serait très probablement A et AA uniquement.
• Suivre la norme européenne : Le RGAA s'appuie sur l'EN 301 549, référencée par le décret du 24 juillet 2019. La version 4.1 de la norme, approuvée le 2 septembre 2026, repose déjà sur les critères WCAG 2.2.
• Élargir le périmètre : les applications mobiles et documents bureautiques entrent enfin dans le même référentiel.
• Clarifier le cadre : l'Arcom comme autorité de contrôle et un téléservice de dépôt des déclarations, ainsi que la notion de non-conformité bloquante.

Le lien avec WCAG 2.2 est le cœur du sujet. Selon la DINUM, les critères du RGAA 5 précisent ou complètent ceux du 4.1.2 sans les contredire, il s’agit plutôt d’un rattrapage.

Une bêta publique est attendue d'ici fin 2026 (intitulés des critères uniquement), puis une version définitive plutôt en 2027. Quant à la date d’entrée en vigueur du RGAA 5, aucune information n’est disponible actuellement : elle dépend d'un arrêté que la DINUM ne maîtrise pas. Cependant, la DINUM est explicite : les travaux fondés sur le RGAA 4.1.2 « ne doivent en aucun cas être suspendus ou reportés ». Les déclarations d'accessibilité publiées avant la sortie du RGAA 5 resteront valables 18 mois, dans la limite de 3 ans à compter de leur publication.

Les principaux changements

Mise en place d’un téléservice dédié pour les déclarations

Il collectera toutes les informations via un formulaire en ligne et générera les déclarations d'accessibilité. L’utilisation du téléservice serait obligatoire, d’abord pour les entités publiques, sans possibilité de déléguer à un prestataire.

Celui-ci aura plusieurs intérêts :

• Pour l'autorité de contrôle : avoir une base de données avec l’ensemble des déclarations et faciliter le contrôle.
• Pour l'État : la centralisation facilite le suivi, l’accompagnement et la construction du rapport pour la Commission européenne.
• Pour les déclarants : la déclaration est construite automatiquement et au bon format avec toutes les informations nécessaires/obligatoires.
• Pour les utilisateurs : le service assurera que les déclarations sont accessibles à tous.

Des intitulés de critères simplifiés

La simplification passe par l'abandon de la forme interrogative, les critères deviennent des affirmations.

Exemple tiré d'une diapositive de la présentation de la DINUM à Paris Web :

RGAA 4	RGAA 5
Pour chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente (hors cas particuliers) ?	L'alternative textuelle de chaque image informative est pertinente (hors cas particuliers)

Prise en compte de six nouveaux critères issus du WCAG 2.2

Six critères WCAG 2.2 de niveau A et AA devraient être repris : 2.4.11 Focus non masqué, 2.5.7 Mouvements de glissement, 2.5.8 Taille de cible, 3.2.6 Aide cohérente, 3.3.7 Saisie redondante et 3.3.8 Authentification accessible. Un critère disparaît : le 4.1.1 (Analyse syntaxique), ce qui concerne les critères 8.1 et 8.2 du RGAA 4.1.2. Nous y reviendrions plus loin dans l'article.

Ajout du mobile et des documents bureautiques dans le référentiel

Le RGAA 5 définira des critères et des tests pour les applications mobiles et les documents bureautiques (DINUM), qui seraient déclinés en trois versions (web, mobile, bureautique).
Un même critère pourra se tester différemment selon le support.

Exemple de tests multi support que l’on pourrait retrouver :

WEB	Mobile
WCAG 5.6.1 : Pour chaque contenu de balise s'appliquant à la totalité de la ligne ou de la colonne, la balise respecte une de ces conditions (hors cas particuliers) ? - La balise <th> possède un attribut id unique ; - La balise <th> possède un attribut scope ; - La balise <th> possède un attribut WAI-ARIA role="rowheader" ou role="columnheader".	WCAG 5.6.1 : Pour chaque combinaison possible des en-têtes de ligne et/ou de colonnes, l'association d'au moins une cellule avec ceux-ci est vérifiée à l'aide du lecteur d'écran.

Mention les non-conformités bloquantes obligatoire sur la déclaration

C’est-à-dire celles qui empêchent d’utiliser le site. Il est annoncé une définition de cette notion de "bloquant" plutôt qu’une liste de critères. Un site comportant des points bloquants pourrait être automatiquement qualifié de « non conforme ».

Focus sur les 6 nouveaux critères issus du WCAG 2.2

Ces six critères viennent de WCAG 2.2, avec les niveaux du W3C. Ce n'est pas le texte du RGAA 5, qui n'est pas encore publié. Ils peuvent se mettre en œuvre dès aujourd'hui.

Critère WCAG 2.2	Niveau	Exigence	Pistes de mise en œuvre
2.4.11 Focus non masqué (min)	AA	Le focus clavier n'est pas caché par un élément fixe	Tester l'en-tête sticky, le bandeau cookies et les barres flottantes avec le focus actif
2.5.7 Mouvements de glissement	AA	Toute action au glisser a une alternative simple	Prévoir un bouton ou un clic pour les sliders, le tri, le drag-and-drop
2.5.8 Taille de cible (min)	AA	Cible d'au moins 24 × 24 px CSS, ou espacement suffisant	Dimensionner boutons, icônes et liens de pagination ; espacer les cibles denses
3.2.6 Aide cohérente	A	L'aide proposée est au même endroit d'une page à l'autre	Fixer l'emplacement du contact, du chat et de la FAQ dans le gabarit
3.3.7 Saisie redondante	A	Une information déjà saisie n'est pas redemandée dans le parcours	Préremplir ou proposer la réutilisation des données en fin de formulaire multi-étapes
3.3.8 Authentification accessible (minimum)	AA	L'authentification ne repose pas sur un test cognitif, sauf alternative ou aide (collage, gestionnaire de mots de passe)	Prévoir une alternative aux tests cognitifs (retenir ou recopier un code) dans les écrans d'authentification

Deux précisions sur les nouveaux critères:

• Le contraste des composants d'interface (1.4.11) vient de WCAG 2.1 : il n'est pas nouveau en 2.2, contrairement à ce que présentent certains articles.
• Les critères 2.4.12, 2.4.13 et 3.3.9 sont de niveau AAA et ne devraient très probablement pas entrer dans le RGAA 5.

Note : les critères 8.1 et 8.2 du RGAA actuel sont voués à disparaître.
WCAG 2.2 retire le critère 4.1.1 (Analyse syntaxique) : « This criterion no longer has utility and is removed », dit le W3C, les technologies d'assistance n'analysant plus le HTML directement. Dans le RGAA 4.1.2, ce critère correspond à deux critères : 8.1 et 8.2. Il est recommandé par les experts de les considérer dès maintenant comme systématiquement conformes.

Conclusion : n’attendons pas le texte final pour mettre en place les bonnes pratiques

Le RGAA 5 complète le RGAA 4.1.2 sans le contredire, et son calendrier a toutes les chances de glisser en 2027.
Ces actions relèvent de la bonne pratique, non opposable à ce jour, mais elles sont à lancer dès maintenant :

• Poursuivre les chantiers et les audits sur la base du RGAA 4.1.2, comme le demande la DINUM.
• Intégrer les six critères WCAG 2.2 A et AA listés plus haut dans les revues de maquettes, les définitions de « terminé » et les recettes.
• Suivre la bêta publique annoncée d'ici fin 2026, qui ne devrait contenir que les intitulés des critères, puis la sortie de l'EN 301 549 v4.1 prévue le 16 décembre 2026.
• Cartographier le périmètre mobile et bureautique de chaque projet, puisqu'il entrera dans le référentiel.

Sur l’automatisation, n’attendons pas non plus. L’IA est un allié précieux, et chez Niji, des travaux sont en cours pour voir ce qu’elle peut apporter aux tests d’accessibilité (nous aurons l’occasion d’en reparler prochainement). Avec une limite assumée : tout ne s’automatise pas, et le verdict final reste humain.

Attendre le texte final pour s'y mettre, c'est prendre le risque d'accumuler du retard.
Bref, pas besoin d’attendre le texte final pour avoir de bons réflexes !

Sources officielles :

DINUM, « Nouvelle version du RGAA »
W3C, nouveautés de WCAG 2.2
Paris Web 2026, « Et un beau jour le RGAA 5 arrivera ! »