RGAA 5 : se conformer avant la sortie de la nouvelle version
Le 24 septembre 2026, à Paris Web, Aurélien Levy (Temesis) et Stéphanie Nazarian (DINUM) ont présenté le futur RGAA 5. Nous y étions. Le chiffre qui a fait réagir la salle : le référentiel passe de 106 à environ 146 critères. Selon Aurélien Levy, seuls 6 à 10 sujets sont réellement nouveaux et à fort impact, et un tiers d'entre eux concerne directement le code.
Ceux-là, vous pouvez les traiter dès maintenant.
Ce que le RGAA 5 change dans votre code
#Pourquoi commencer avant la publication du RGAA 5 ?
L'essentiel du RGAA 5 existe déjà. Deux tiers à trois quarts des nouveaux critères viennent des WCAG 2.2 (Web Content Accessibility Guidelines, les règles internationales du W3C) et de la norme européenne EN 301 549. Ces textes sont publiés, stables et lisibles aujourd'hui, avant même la version bêta du RGAA 5.
Passer de 106 à environ 146 critères, c'est environ 38 % de plus. Près de quatre critères de plus pour dix existants.
Des textes déjà figés. Les WCAG 2.2 sont une recommandation du W3C depuis le 5 octobre 2023. L'EN 301 549 V4.1.1, publiée le 2 septembre 2026, les intègre à son tour. Le RGAA 5 (référentiel général d'amélioration de l'accessibilité) reprendra ces exigences sous une autre forme, sans les réinventer.
La consigne officielle. La DINUM (direction interministérielle du numérique) l'a écrit noir sur blanc dans son annonce du 4 mars 2026 : les travaux sur le RGAA 4.1.2 ne doivent pas être suspendus ou reportés (les déclarations établies sur le RGAA 4.1.2 restent valables 18 mois après la sortie du RGAA 5), et les critères du RGAA 5 viendront préciser ou compléter ceux du RGAA 4, sans les contredire.
Attendre ne fait gagner aucun temps. Chaque composant livré aujourd'hui sans tenir compte de ces exigences sera à reprendre en 2027.
RGAA 5 : comment préparer la transition sans payer deux fois
#Six critères WCAG 2.2 à vérifier dans votre code
Les WCAG 2.2 ont ajouté neuf critères, dont six de niveau A ou AA. Ce sont ces six-là qui entrent dans le RGAA 5, qui ne couvre que les niveaux A et AA. Voici ce que chacun demande à votre code.
| Critère WCAG 2.2 | Niveau | Où regarder dans votre code |
|---|---|---|
| 2.4.11 Focus non masqué (minimum) | AA | En-têtes et pieds collants, bannière cookie |
| 2.5.7 Mouvements de glissement | AA | Glisser-déposer, tableaux kanban, curseurs |
| 2.5.8 Taille de la cible (minimum) | AA | Boutons icônes, puces de carrousel, liens serrés |
| 3.2.6 Aide cohérente | A | Gabarit, pied de page, widget de chat |
| 3.3.7 Saisie redondante | A | Tunnels de commande, formulaires en plusieurs étapes |
| 3.3.8 Authentification accessible (minimum) | AA | Connexion, codes à usage unique, CAPTCHA |
#2.4.11 Focus non masqué (minimum)
Ce que dit le W3C. Quand un composant reçoit le focus clavier, il ne doit pas être entièrement caché par un contenu ajouté par l'auteur. La formulation RGAA 5, provisoire, demande que chaque composant qui reçoit le focus reste au moins partiellement visible.
Le cas typique. Un en-tête collant de 80 px. L'utilisateur remonte avec Maj+Tab, le navigateur fait défiler juste assez pour afficher le lien focalisé, et le lien finit sous l'en-tête. Le W3C décrit ce cas comme l'échec F110. Une bannière cookie collée en bas de l'écran produit le même effet dans l'autre sens.
La correction tient en deux lignes de CSS, documentées par le W3C dans la technique C43 :
/* Avant : l'en-tête collant recouvre l'élément focalisé */
.site-header { position: sticky; top: 0; height: 5rem; }
/* Après : le défilement réserve la place de l'en-tête et du pied collants */
html {
scroll-padding-top: 6rem;
scroll-padding-bottom: 5rem;
}Le test. Tabulez vers le bas jusqu'au pied de page, puis remontez avec Maj+Tab. Si un élément focalisé disparaît complètement, même une seconde, le composant est en échec.
#2.5.7 Mouvements de glissement
Ce que dit le W3C. Toute fonction qui utilise un mouvement de glissement doit pouvoir être réalisée avec un pointeur unique, sans glisser, sauf si le glisser est essentiel.
Le cas typique. Un tableau kanban où les cartes ne se déplacent qu'en les faisant glisser. C'est l'exemple même de l'échec F108. Pour une personne qui a des tremblements, maintenir le bouton de la souris pendant tout le trajet est un obstacle réel.
Le critère parle de pointeur : il exige une alternative au clic simple, même quand le clavier fonctionne.
<!-- Avant : la carte ne bouge qu'au glisser-déposer -->
<li draggable="true">Rédiger la FAQ</li>
<!-- Après : le glisser reste, des clics simples suffisent aussi -->
<li draggable="true">
Rédiger la FAQ
<label>
Déplacer vers
<select name="colonne">
<option>À faire</option>
<option selected>En cours</option>
<option>Terminé</option>
</select>
</label>
</li>Pour un curseur, un clic sur la piste ou un champ numérique à côté font l'affaire. Un <input type="range"> natif accepte déjà le clic sur la piste.
Le test. Faites chaque action de glisser de la page avec des clics simples uniquement.
#2.5.8 Taille de la cible (minimum)
Ce que dit le W3C. Une cible cliquable mesure au moins 24 × 24 pixels CSS, sauf exceptions : espacement suffisant, contrôle équivalent ailleurs, lien dans une phrase, contrôle natif du navigateur, taille essentielle.
Ce qu'il faut comprendre. La zone cliquable fait foi. Exemple : des puces de carrousel de 2 × 2 px restent acceptables si leur zone de clic est assez grande. Un bouton icône de 16 px sans marge échoue, même s'il est parfaitement lisible.
/* Avant : zone cliquable de 16 × 16 px */
.icon-button { width: 16px; height: 16px; padding: 0; }
/* Après : l'icône garde sa taille, la zone de clic passe à 24 px */
.icon-button {
min-width: 24px;
min-height: 24px;
display: inline-grid;
place-items: center;
}
/* Puce de carrousel : petit point visible, grande zone de clic */
.carousel-dot {
box-sizing: border-box;
width: 24px;
height: 24px;
padding: 8px; /* point visible de 8 px, zone de clic de 24 px */
border-radius: 50%;
background-clip: content-box;
}Pour les commandes importantes (fermer une modale, valider un paiement), visez 44 px, la valeur du critère 2.5.5 de niveau AAA.
Le test. Mesurez la zone cliquable de l'élément dans l'inspecteur du navigateur.
#3.2.6 Aide cohérente
Ce que dit le W3C. Si un mécanisme d'aide se répète sur plusieurs pages (coordonnées, formulaire de contact, chat, FAQ), il apparaît dans le même ordre par rapport au reste du contenu. Le W3C parle d'ordre relatif dans le code.
Le piège. Le lien « Nous contacter » dans l'en-tête sur l'accueil, en bas de page sur les fiches produit, absent du tunnel de commande. Ce genre d'écart naît quand chaque page place l'aide à la main.
// Avant : chaque page ajoute son propre lien d'aide, où elle veut
// Après : un seul composant de gabarit, partagé par toutes les pages
export function Layout({ children }) {
return (
<>
<Header />
<main>{children}</main>
<footer>
<HelpLinks /> {/* contact, FAQ, chat : toujours ici, dans cet ordre */}
</footer>
</>
);
}Le test. Ouvrez cinq gabarits différents et comparez l'ordre des éléments d'aide.
#3.3.7 Saisie redondante
Ce que dit le W3C. Une information déjà fournie dans le même processus est pré-remplie ou proposée à la sélection, sauf si la ressaisir est essentiel, sert la sécurité ou si l'information n'est plus valide. Le W3C précise que l'autocomplétion du navigateur reste insuffisante.
Le cas typique. Le tunnel de commande qui redemande l'adresse de facturation deux écrans après l'adresse de livraison.
<!-- Avant : le client retape son adresse -->
<fieldset>
<legend>Adresse de facturation</legend>
<input name="billing-street" autocomplete="billing street-address">
</fieldset>
<!-- Après : une case cochée par défaut reprend l'adresse de livraison -->
<label>
<input type="checkbox" name="same-address" checked>
Adresse de facturation identique à l'adresse de livraison
</label>
<fieldset id="billing" hidden>
<legend>Adresse de facturation</legend>
<input name="billing-street" autocomplete="billing street-address">
</fieldset>// Les champs de facturation n'apparaissent que si la case est décochée
const same = document.querySelector('[name="same-address"]');
same.addEventListener('change', () => {
document.getElementById('billing').hidden = same.checked;
});Côté serveur, si la case est cochée, reprenez l'adresse de livraison déjà enregistrée.
Le test. Parcourez chaque formulaire en plusieurs étapes et notez toute information demandée deux fois.
#3.3.8 Authentification accessible (minimum)
Ce que dit le W3C. Aucune étape de connexion ne repose sur un test de fonction cognitive (mémoriser, recopier, résoudre une énigme), sauf s'il existe une alternative ou une aide : gestionnaire de mots de passe, copier-coller, reconnaissance d'objets, contenu personnel.
Une nouvelle thématique CAPTCHA. Dans le RGAA 5, ce critère ouvre une thématique dédiée aux CAPTCHA (tests pour distinguer un humain d'un robot). Un CAPTCHA reste possible s'il existe une alternative. Exemple : service-public.fr affiche un CAPTCHA à la connexion et propose aussi FranceConnect, qui permet de se connecter sans passer le test.
Le piège le plus courant. Bloquer le collage dans le champ mot de passe, ou découper un code à six chiffres en six champs qui refusent le collage. Le W3C décrit les deux dans l'échec F109.
<!-- Avant : collage bloqué, gestionnaire de mots de passe ignoré -->
<input type="password" autocomplete="off" onpaste="return false">
<!-- Après : le gestionnaire remplit, le collage fonctionne -->
<input type="password" name="password" autocomplete="current-password">
<!-- Code à usage unique : un seul champ, remplissage automatique possible -->
<input type="text" name="otp" autocomplete="one-time-code"
inputmode="numeric" maxlength="6" pattern="\d{6}">
<!-- Clés d'accès (passkeys) proposées dès le champ identifiant -->
<input type="text" name="username" autocomplete="username webauthn">Les jetons current-password, one-time-code et webauthn sont documentés sur MDN. Pour les passkeys, le guide MDN sur les clés d'accès montre l'appel JavaScript qui va avec.
Le test. Connectez-vous avec un gestionnaire de mots de passe, puis en collant chaque valeur à la main.
#Trois exigences européennes à ajouter à votre liste
L'EN 301 549 contient les WCAG et d'autres exigences. Certaines étaient absentes du RGAA 4, comme les outils d'édition ou la communication en temps réel. Le référentiel luxembourgeois RAWeb 1.1 (référentiel d'évaluation de l'accessibilité web) les couvre déjà avec 136 critères, et le RGAA 5 s'en inspire. Trois exigences sont détaillées ci-dessous.
#Commandes des médias (EN 301 549, exigence 7.3)
Quand un lecteur vidéo propose des sous-titres ou une audiodescription, leurs commandes sont aussi accessibles que les commandes principales, lecture et pause. Elles s'affichent à côté de Lecture.
<!-- Après : sous-titres et audiodescription au même niveau que Lecture -->
<div class="player-controls">
<button type="button">Lecture</button>
<button type="button" aria-pressed="false">Sous-titres</button>
<button type="button" aria-pressed="false">Audiodescription</button>
</div>Un contre-exemple : un grand lecteur vidéo en ligne où il faut ouvrir trois sous-menus pour activer les sous-titres.
#Préférences utilisateur (EN 301 549, exigence 11.7)
L'interface respecte les réglages du système et du navigateur : texte clair sur fond sombre, taille de caractères agrandie. La Commission européenne classe cette exigence parmi celles qui ne viennent pas des WCAG, et la V4.1.1 demande aux sites et aux documents de mieux respecter ces préférences, avec une nouvelle clause 9.7 pour les pages web. Le groupe de travail discute encore du périmètre, car tester toutes les combinaisons de réglages serait ingérable.
La norme ne dicte pas de technique. Côté CSS, trois habitudes vont dans son sens :
/* Avant : la taille choisie dans le navigateur est écrasée */
html { font-size: 14px; }
/* Après : la préférence de l'utilisateur sert de base */
html { font-size: 100%; }
body { font-size: 1rem; }
@media (prefers-color-scheme: dark) {
:root { --bg: #111; --text: #eee; }
}
@media (forced-colors: active) {
.button { border: 1px solid ButtonText; }
}#Biométrie (EN 301 549, exigence 5.3)
Toute identification par une caractéristique biologique, Face ID ou empreinte digitale, dispose d'une méthode alternative. Exemple : l'écran de connexion d'une application bancaire qui propose Face ID et un mot de passe classique. Une personne dont le visage ou les doigts ne sont pas reconnus n'est jamais enfermée dehors.
#Ce qui change dans la grille de l'auditeur
La méthode d'audit évolue sur la forme et le calcul du taux reste le même en 5.0.
Des critères à l'affirmatif. Les critères abandonnent la question et deviennent une bonne pratique à respecter. Les tests, eux, restent formulés en questions. Exemple sur l'alternative textuelle des images :
| RGAA 4 | RGAA 5 (formulation provisoire) |
|---|---|
| Chaque image porteuse d'information ayant une alternative textuelle, cette alternative est-elle pertinente ? | L'alternative textuelle de chaque image informative est pertinente. |
Vos images n'ont pas besoin de texte alternatif
Un référentiel multi-support. Chaque test pourra avoir une déclinaison mobile ou bureautique, sur le modèle des référentiels luxembourgeois (RAWeb pour le web, RAAM pour les applications mobiles, RAPDF pour les PDF). Exemple donné pour les tableaux de données : en web, on vérifie la présence de balises th ; en mobile, on vérifie ce que restitue le lecteur d'écran.
Un taux de conformité inchangé. La méthode de calcul reste la même dans la version 5.0. Vos tableaux de suivi n'ont pas à changer de formule. Le futur modèle de déclaration ajoutera les points bloquants, ces défauts qui empêchent d'aller au bout d'une tâche. Avec un seul point bloquant, un service devrait rester non conforme, même au-dessus de 50 % de taux de conformité. Le détail est dans notre article RGAA 5 : comment préparer la transition sans payer deux fois.
Générateur de texte alternatif gratuit : l'alt de chaque image, selon son rôle
#Vérifier vos pages dès aujourd'hui, gabarit par gabarit
Presque tout ce qui précède se vérifie à la main. La taille des cibles est la seule à être en partie détectable automatiquement, et même là, les exceptions du W3C imposent un contrôle humain. axe-core, le moteur de test le plus répandu, ne compte d'ailleurs qu'une seule règle WCAG 2.2, target-size, et sa documentation indique qu'elle est désactivée par défaut.
Travaillez par gabarit : un défaut dans le composant d'en-tête se répète sur tout le site, et se corrige une seule fois.
- Tabulez vers le bas puis vers le haut sur chaque gabarit qui a un en-tête, un pied de page ou une bannière collants.
- Mesurez la zone cliquable des boutons icônes, des puces et des liens serrés dans l'inspecteur.
- Refaites chaque action de glisser avec des clics simples uniquement.
- Comparez l'ordre des liens d'aide sur cinq gabarits différents.
- Parcourez chaque formulaire en plusieurs étapes et relevez toute information demandée deux fois.
- Connectez-vous avec un gestionnaire de mots de passe, puis en collant le mot de passe et le code.
- Vérifiez que les boutons sous-titres et audiodescription sont visibles à côté de Lecture.
- Passez le système en mode sombre et en contraste élevé, agrandissez le texte du navigateur, puis relisez la page.
Pour la partie automatisable, l'outil Includdy scanne une page ou un composant à la fois en quelques secondes et associe un guide de correction à chaque erreur détectée. Elle prend en charge ce qu'une machine voit et vous laisse le temps pour les tests manuels de la liste ci-dessus.
Le RGAA 5 contrôlera ce que vous pouvez déjà livrer.
EAA et accessibilité web : ce qui change pour votre entreprise en 2026
Pour repérer les erreurs détectables sur vos pages avant de passer aux tests manuels, essayez Includdy.
