Aller au contenu principal
référentielsrgaa

RGAA 5 • Une mise à jour attendue, mais quelques questions restent ouvertes

Par Geoffrey CroftePublié le 2026-05-05

La Direction interministérielle du numérique (Dinum) a annoncé début mars 2026 qu'elle travaillait, avec des acteurs publics, associatifs et privés, à la rédaction du RGAA 5, la prochaine version du Référentiel Général d'Amélioration de l'Accessibilité.

Publication prévue : fin 2026. Le sujet mérite qu'on s'y attarde, avec un regard un peu moins institutionnel que les communiqués officiels.


Qu'est-ce que le RGAA, et pourquoi ça compte ?

Le RGAA est le référentiel associé au cadre légal français qui fixe les obligations d'accessibilité numérique pour les services publics et les grandes entreprises.

La version actuelle, la 4.1.2, s'appuie sur les WCAG 2.1 du W3C. Elle définit des critères concrets que les développeurs et designers doivent respecter pour que leurs interfaces soient utilisables par des personnes handicapées.

Ce n'est pas un sujet abstrait : 12 à 15 millions de personnes sont handicapées en France, et la loi impose l'accessibilité numérique depuis 2005. Vingt ans plus tard, le niveau de conformité reste largement insuffisant (environ 40 sites en conformité totale, sur un échantillon de 7000+ sites web), et ce même sur la majorité des services publics. C'est dans ce contexte que le RGAA 5 arrive.


Ce qui change (vraiment)

Alignement sur les WCAG 2.2

Le changement le plus structurant est le passage des WCAG 2.1 aux WCAG 2.2, publiées en décembre 2024 par le W3C. Concrètement, cela introduit plusieurs critères nouveaux ou renforcés.

  • Sur la visibilité du focus : trois critères viennent préciser les exigences. Le focus ne doit pas être masqué par d'autres éléments de la page (2.4.11, niveau AA), avec une exigence encore plus stricte en AAA (2.4.12), et des contraintes minimales de taille et de contraste pour le focus lui-même (2.4.13, AA). C'est une évolution utile, le focus étant souvent le parent pauvre des revues d'accessibilité.

  • Sur les interactions : les gestes de type glisser-déposer (drag and drop) devront désormais proposer une alternative accessible par simple pointeur (WCAG 2.5.7, AA). Un point souvent oublié dans les interfaces modernes, notamment les outils de gestion de contenu ou les tableaux Kanban.

  • Sur les CAPTCHA : potentiellement, les tests cognitifs (puzzle, mémoire...) ne devront plus être imposés dans les processus d'identification (WCAG 3.3.8 et 3.3.9) ou autres types de formulaires. Une excellente nouvelle, les CAPTCHA étant notoirement inaccessibles pour de nombreux profils. (Et d'après ces CAPTCHA, je serais un robot 😁)

  • Sur les cibles (click, tactile) : une taille minimale de 24x24 pixels CSS est fixée (WCAG 2.5.8, AA). Avec une formulation qui laisse à interprétation, modeste, mais mieux que rien.

  • Sur la cohérence des interfaces : les mécanismes d'aide comme la mise à disposition de moyens de contact ou les FAQ devront apparaître de façon cohérente sur toutes les pages (WCAG 3.2.6, A). Là encore, un angle souvent négligé.

  • Sur les formulaires : les informations déjà saisies dans un processus ne devront pas être redemandées sans raison (WCAG 3.3.7, A). Bon sens et accessibilité font ici alliance.

Extension à de nouveaux types de contenus

Le RGAA 5 devrait pour la première fois définir des critères techniques pour les applications mobiles et les documents bureautiques (PDF, Word, etc.), ce que le Service Info Presse propose déjà avec le RAWeb, le RAAM et le RAPDF pour le Luxembourg. C'est une avancée réelle. Ces formats représentent une part importante des échanges entre les services publics et les usagers, et ils étaient jusqu'ici largement absents du périmètre formel. Les sociétés privées ne pourront plus non plus se cacher derrière des PDFs et applications mobiles inaccessibles.

Des évolutions institutionnelles

Sur le plan légal, deux changements sont prévus : la désignation de l'Arcom (Autorité de régulation de la communication audiovisuelle et numérique) comme autorité de contrôle, et la mise en place d'un téléservice dédié pour le dépôt des déclarations d'accessibilité. Ce dernier point est bienvenu : aujourd'hui, le suivi des déclarations reste peu outillé et peu lisible.


Ce qui reste à préciser

L'annonce officielle est volontairement prudente, et c'est compréhensible pour une version encore en rédaction. Mais quelques zones d'ombre méritent d'être signalées.

  • La reformulation des critères est évoquée comme un objectif de simplification. C'est positif en théorie, mais une reformulation peut aussi introduire des ambiguïtés nouvelles. Sans voir le texte, impossible de juger. À surveiller de près lors de la consultation publique. D'après ce que j'ai compris, le format sous forme de questions serait abandonné. Information à confirmer.

  • Le calendrier reste flou. "Fin 2026" est une cible, pas une date ferme. Or, les projets numériques publics ont besoin de visibilité. Une publication tardive ou un retard risque de créer une période d'incertitude inconfortable pour les équipes qui travaillent actuellement à la mise en conformité.

  • L'enforcement reste la vraie question. Le RGAA existe depuis des années, les obligations légales aussi. Pourtant, les taux de conformité restent très bas. L'arrivée de l'Arcom comme autorité de contrôle est présentée comme une évolution, mais sa capacité réelle à instruire des signalements et à sanctionner reste à prouver. L'accessibilité numérique souffre moins d'un manque de règles que d'un manque de contrôle effectif.

  • La dépendance aux WCAG reste encore et toujours discutable. Quand on voit la vitesse d'évolution de ce référentiel (relativement lent considérant l'évolution des usages), et le fait qu'il a fallu 2 ans au RGAA pour se mettre à jour, cela créé, selon moi, un frein à l'évolution des normes.


Faut-il attendre le RGAA 5 pour agir ou puis-je encore utiliser RGAA 4.1.2 ?

Inutile d'attendre le RGAA 5, et la Dinum le dit elle-même avec une clarté appréciable : les travaux en cours sur la base du RGAA 4.1.2 ne doivent pas être suspendus. Plusieurs arguments solides soutiennent cette position.

D'abord, les critères du RGAA 5 viendront préciser et compléter ceux du RGAA 4.1.2, pas les invalider. Les différences entre WCAG 2.1 et 2.2 sont réelles mais limitées. Ce qu'on fait correctement aujourd'hui restera correct demain.

Ensuite, les déclarations d'accessibilité publiées avant la sortie du RGAA 5 resteront valables 18 mois après sa publication (dans la limite de trois ans à partir de leur date d'émission). Pas de remise à zéro brutale donc.

Enfin, et c'est peut-être l'argument le plus direct : chaque mois sans mise en conformité exclut des usagers. L'attente d'une nouvelle version du référentiel n'est pas un argument recevable face à cette réalité.

Il est même possible d'anticiper dès maintenant en intégrant les critères des WCAG 2.2 absents du RGAA 4.1.2 dans les projets en cours. C'est la démarche la plus cohérente pour les équipes sérieuses. (Ce que vous pouvez déjà faire avec les "Custom Guidelines" dans CheckFox)


Lecture checkfox

Le RGAA 5 est une mise à jour logique et attendue, qui comble des lacunes réelles (applications mobiles, documents, WCAG 2.2). L'alignement sur les standards internationaux est une bonne chose, et la volonté de simplifier les critères peut faciliter leur appropriation par des équipes non spécialistes.

Mais l'accessibilité numérique en France a moins besoin d'un meilleur référentiel que d'une meilleure culture de son application. Les outils existent. Le cadre légal existe. Ce qui manque souvent, ce sont les ressources humaines dédiées, les budgets accordés, et la volonté réelle de traiter l'accessibilité comme une contrainte non négociable plutôt que comme une case à cocher.

La vraie question posée par le RGAA 5 n'est pas "quels nouveaux critères ?" mais "comment passe-t-on enfin d'une conformité de façade à une accessibilité effective ?". C'est sur ce terrain-là que les prochains mois seront révélateurs.


Sources :

Mettez-le en pratique avec CheckFox

CheckFox aide les équipes à mener des audits WCAG, RGAA et RAWeb, à collecter des preuves visuelles et à générer des rapports conformes et des déclarations d'accessibilité.