RGAA 5 : ce qui change pour Drupal

Le Référentiel général d’amélioration de l’accessibilité (RGAA) est la déclinaison française des règles d’accessibilité numérique. Sa version actuelle, le RGAA 4, s’appuie sur les WCAG 2.1. Une nouvelle version, le RGAA 5, est attendue et devrait intégrer les WCAG 2.2, publiées en octobre 2023 par le W3C. Pour les organisations qui exploitent un site Drupal, c’est le bon moment pour comprendre ce qui se profile et pour anticiper sereinement plutôt que de subir une mise en conformité dans l’urgence.

Précisons d’emblée un point important : à ce jour, le calendrier de publication du RGAA 5 reste prévisionnel. Les éléments qui suivent décrivent les évolutions attendues sur la base des WCAG 2.2 et des annonces publiques. Il faut donc les lire comme une préparation raisonnée, pas comme une obligation déjà gravée dans le marbre. La bonne nouvelle, c’est que les nouveaux critères vont dans le sens d’une meilleure expérience pour tous les utilisateurs et que la plupart sont accessibles à anticiper dès aujourd’hui.

Le contexte : du RGAA 4 au RGAA 5

Le RGAA 4 est aligné sur les WCAG 2.1, niveau AA. Il s’impose aux services publics et à un nombre croissant d’acteurs privés en France, sous l’effet de la transposition des directives européennes et de l’élargissement progressif du périmètre des obligations. La logique du référentiel est stable : il traduit les critères WCAG en tests concrets et vérifiables, applicables à un site réel.

Le passage attendu vers les WCAG 2.2 introduit neuf nouveaux critères de succès et en retire un (le critère 4.1.1 Parsing, devenu obsolète avec l’évolution des navigateurs). Le RGAA 5 devrait reprendre cette base en l’adaptant à sa méthodologie de tests. Pour un décideur, l’enjeu n’est pas de connaître chaque critère par cœur, mais de savoir lesquels auront un impact réel sur un site Drupal existant et lesquels demanderont une intervention.

Les nouveaux critères des WCAG 2.2

Voici les principaux apports des WCAG 2.2, présentés selon ce qu’ils changent concrètement pour un site web.

Taille des cibles de pointage (Target Size, niveau AA). Les éléments interactifs (boutons, liens, cases à cocher) doivent offrir une zone cliquable d’au moins 24 par 24 pixels CSS, sauf exceptions (espacement suffisant entre cibles, lien dans un bloc de texte, équivalent disponible ailleurs). Ce critère bénéficie directement aux personnes ayant une motricité fine réduite et aux utilisateurs sur écran tactile. Concrètement, il invite à revoir les petites icônes, les menus denses et les boutons d’action rapprochés.

Focus non masqué (Focus Not Obscured, niveau AA). Lorsqu’un élément reçoit le focus clavier, il ne doit pas être entièrement caché par un autre contenu : une barre de navigation collante (sticky header), une bannière de cookies ou un bouton flottant. Ce critère touche un grand nombre de sites modernes, car les en-têtes fixes et les composants superposés sont devenus courants. C’est souvent un ajustement CSS et JavaScript ciblé, mais il faut le tester sur chaque parcours au clavier.

Authentification accessible (Accessible Authentication, niveau AA). Un processus d’authentification ne doit pas reposer uniquement sur un test cognitif comme la mémorisation d’un mot de passe complexe, la résolution d’une énigme ou un CAPTCHA inaccessible. Des solutions conformes existent : autoriser le collage du mot de passe, accepter les gestionnaires de mots de passe, proposer une alternative au CAPTCHA visuel. Pour un site Drupal, cela concerne les formulaires de connexion, l’inscription et tout espace protégé.

Mouvements de glissement avec alternative (Dragging Movements, niveau AA). Toute fonctionnalité reposant sur un glissement (drag and drop, curseur à faire glisser, carrousel manipulable au doigt) doit proposer une alternative actionnable par un simple clic ou appui. Cela concerne typiquement les sliders, les réordonnancements de listes et certains composants d’interface riches. L’objectif est de ne jamais enfermer une action dans un geste que tout le monde ne peut pas réaliser.

À ces quatre points souvent cités s’ajoutent d’autres critères des WCAG 2.2 : l’aide cohérente (Consistent Help), qui demande que les mécanismes d’assistance apparaissent au même endroit d’une page à l’autre, la saisie redondante (Redundant Entry), qui évite de redemander une information déjà fournie dans un même parcours et des précisions sur l’apparence du focus (Focus Appearance). Tous poursuivent la même logique : réduire la charge et les obstacles pour les utilisateurs, en particulier ceux en situation de handicap moteur ou cognitif.

Le calendrier prévisionnel

Soyons prudents sur les dates. Les WCAG 2.2 sont stabilisées depuis fin 2023. L’écosystème français de l’accessibilité se prépare à les intégrer dans une future version du référentiel. Une publication du RGAA 5 est évoquée pour la fin 2026, mais ce calendrier reste prévisionnel et peut évoluer en fonction des travaux officiels et de la consultation des parties prenantes.

Ce qu’il faut retenir : il y a généralement une période de transition entre la publication d’un nouveau référentiel et son application effective dans les obligations légales. Les organisations ne se retrouvent donc pas conformes ou non conformes du jour au lendemain. Cette fenêtre est précisément celle qu’il faut mettre à profit. Attendre la publication officielle pour découvrir l’écart de conformité de son site, c’est s’exposer à une remise à niveau pressée. Anticiper, à l’inverse, permet d’étaler l’effort et de l’intégrer au cycle de vie normal du site.

Ce que ça change concrètement pour un site Drupal

La plupart des nouveaux critères ne sont pas spécifiques à Drupal, mais leur application dépend de la façon dont le site est construit. Voici les zones à surveiller en priorité.

Le thème et les composants front. La taille des cibles, le comportement du focus et l’apparence du focus relèvent essentiellement du thème (CSS, templates Twig) et des comportements JavaScript. Un thème custom bien tenu absorbe ces critères sans difficulté majeure. Un thème ancien ou fortement personnalisé demandera un passage en revue plus attentif.

Les formulaires et l’authentification. Drupal gère nativement de nombreux aspects de l’accessibilité des formulaires, mais l’authentification accessible mérite une vérification : présence d’un CAPTCHA, blocage du collage de mot de passe, dépendance à un module tiers. Ce sont des points concrets et localisables.

Les composants interactifs. Sliders, carrousels, glisser-déposer dans l’interface : tout composant reposant sur un mouvement de glissement doit offrir une alternative. Ces composants proviennent souvent de modules contribués ou de bibliothèques JavaScript intégrées, qu’il faut auditer un par un.

Les contenus produits par les rédacteurs. L’accessibilité ne se joue pas que dans le code. Les textes alternatifs, la structure des titres, les liens explicites et la qualité des contrastes dépendent aussi des pratiques éditoriales. Drupal offre des leviers (champs obligatoires, aide à la saisie, garde-fous dans l’éditeur de texte) pour outiller les contributeurs.

L’écosystème Drupal est plutôt favorable sur ce terrain. La communauté investit de longue date dans l’accessibilité du core. De nombreux modules s’inscrivent dans cette dynamique. Pour structurer la démarche, mon approche de l’accessibilité RGAA Drupal combine l’analyse technique, les correctifs de thème et l’accompagnement des équipes éditoriales.

Comment anticiper dès maintenant

Pas besoin d’attendre le texte définitif pour agir. Les WCAG 2.2 étant connues, on peut déjà préparer le terrain avec une démarche progressive.

Établir un état des lieux. La première étape consiste à mesurer l’écart entre l’existant et les critères à venir. Un audit Drupal orienté accessibilité identifie les points qui passeraient les nouveaux critères et ceux qui demanderaient une intervention, en distinguant les corrections de thème, les ajustements de modules et les pratiques éditoriales. C’est la base d’une feuille de route réaliste.

Prioriser par impact et par effort. Tous les écarts ne se valent pas. Le focus masqué par un en-tête collant peut toucher l’ensemble des pages et se corriger une fois pour toutes. Une cible de pointage trop petite sur un composant rarement utilisé est moins prioritaire. Classer les chantiers permet de livrer vite les corrections à fort impact.

Intégrer l’accessibilité au cycle de développement. Plutôt qu’un grand projet ponctuel, l’accessibilité gagne à devenir un réflexe : vérification au moment des évolutions de thème, contrôle des nouveaux composants avant mise en ligne, formation des rédacteurs aux bonnes pratiques. Des outils d’analyse automatisée (axe, Lighthouse, pa11y) attrapent une partie des problèmes en continu, même s’ils ne remplacent pas une vérification humaine et le test au clavier et au lecteur d’écran.

Documenter et suivre. Tenir à jour une déclaration d’accessibilité et un schéma pluriannuel n’est pas qu’une formalité réglementaire : c’est un outil de pilotage qui rend visible la progression et qui sécurise l’organisation en cas de contrôle.

Anticiper le RGAA 5, c’est avant tout transformer une échéance réglementaire en amélioration concrète de l’expérience utilisateur. Les critères des WCAG 2.2 servent toutes les personnes qui utilisent votre site, pas uniquement celles en situation de handicap : des cibles plus grandes, un focus toujours visible et une authentification sans friction profitent à l’ensemble de votre audience.

Vous voulez savoir où en est votre site Drupal face aux critères du RGAA 5 et construire une feuille de route sereine ? Parlons de votre projet.