← Retour au blog
• RGAA, Accessibilité, WCAG, Front-End, CSS

Cap sur le RGAA 5 : Ce que WCAG 2.2 change pour nos interfaces

Depuis plusieurs années, le RGAA 4.1.2 sert de boussole à tous les concepteurs et développeurs web soucieux d'accessibilité en France. Calé sur les WCAG 2.1 (niveau AA), il a accompagné la montée en puissance de l'accessibilité dans le secteur public comme dans le privé, notamment accélérée par l'European Accessibility Act (EAA).

Mais le web évolue, nos interfaces aussi. Avec la finalisation des WCAG 2.2 et les mises à jour de la norme européenne de référence EN 301 549, les travaux autour du RGAA 5 se concrétisent.

Loin d'être une simple mise à jour cosmétique, cette nouvelle mouture apporte des exigences techniques très concrètes pour le front-end et le design d'interface. Faisons le point sur les changements majeurs et sur les bonnes pratiques à adopter sans attendre.

1. Focus non masqué : la fin des headers fixes qui recouvrent la navigation clavier

Combien de fois avez-vous navigué au clavier sur un site pour voir l'anneau de focus disparaître sous une barre de navigation fixe (position: sticky ou fixed) ou un bandeau de cookies ?

Jusqu'ici, tant que l'élément recevait le focus, le critère technique était souvent validé, même si l'utilisateur ne voyait plus où il se trouvait à l'écran.

Avec les critères 2.4.11 (Focus Not Obscured - Minimum, niveau AA) et 2.4.12 (Enhanced, niveau AAA) :

  • Au niveau AA : l'élément actif ne doit pas être totalement masqué par un autre composant de l'interface lors de la navigation au clavier.
  • Au niveau AAA : aucune portion de l'élément focalisé ne doit être masquée.

La solution CSS moderne : les propriétés logiques de scroll

Plutôt que des marges physiques dépendantes de l'orientation de lecture, privilégions les propriétés logiques CSS (scroll-padding-block et scroll-margin-block) :

/* Marge de scroll globale équivalente à la hauteur du header sticky */
html {
  /* Équivalent logique moderne de scroll-padding-top */
  scroll-padding-block-start: 5rem; /* Hauteur de la barre de navigation + marge */
}

/* Ciblage précis des éléments interactifs et sections */
:focus-visible {
  /* Définit les dégagements de scroll en début et fin de bloc */
  scroll-margin-block-start: 5rem;
  scroll-margin-block-end: 2rem;
}

Ce simple ajustement garantit que le navigateur arrête le défilement avant que l'élément interactif ne vienne se glisser sous votre menu fixe, quel que soit le mode d'écriture.

2. Taille minimale des cibles tactiles : 24×24px minimum

Sur mobile ou écran tactile, rien n'est plus frustrant que de devoir viser une icône de suppression minuscule ou une croix de fermeture de modale de 14px.

Le critère 2.5.8 (Target Size - Minimum, niveau AA) impose que toute cible interactive fasse au minimum 24×24 pixels CSS, ou qu'un espacement suffisant compense une taille inférieure.

Note : Le niveau AAA (2.5.5) demande quant à lui 44×44px, standard déjà recommandé par le guide de style iOS et Material Design.

L'astuce front-end : étendre la zone de clic avec des propriétés logiques

Si votre design impose une icône compacte de 16px, inutile de déformer la maquette. On étend la zone cliquable avec un pseudo-élément en utilisant les dimensions logiques (inline-size, block-size et inset) :

.btn-icon-compact {
  position: relative;
  /* Dimensions visuelles compactes du bouton */
  inline-size: 16px;
  block-size: 16px;
}

/* Zone d'interaction invisible mais active d'au moins 24x24px (ou 44x44px sur mobile) */
.btn-icon-compact::before {
  content: "";
  position: absolute;
  inset-block-start: 50%;
  inset-inline-start: 50%;
  transform: translate(-50%, -50%);
  min-inline-size: 24px;
  min-block-size: 24px;
  /* Élargit la hitbox sans altérer le flux ni l'aspect visuel */
}

3. Apparence et contraste du focus : adieu au outline: none négligent

La visibilité de l'indicateur de focus est l'un des piliers de l'accessibilité au clavier. Le critère 2.4.13 (Focus Appearance) apporte un cadre rigoureux :

  • Une surface minimale pour l'indicateur de focus (au moins une bordure de 2px de large).
  • Un ratio de contraste d'au moins 3:1 entre l'état avec et sans focus, et par rapport à l'arrière-plan environnant.

La bonne pratique moderne avec :focus-visible

Ne désactivez jamais l'outline sans fournir une alternative robuste :

/* Suppression propre du contour pour les clics souris, préservation au clavier */
:focus:not(:focus-visible) {
  outline: none;
}

/* Indicateur ultra-visible au clavier, décollé du composant */
:focus-visible {
  outline: 3px solid var(--accent-color, #0056b3);
  outline-offset: 3px;
  border-radius: 2px;
}

4. Authentification accessible : stop aux tests cognitifs

Se connecter à un service ne devrait pas ressembler à une épreuve de jeu télévisé. Le critère 3.3.8 (Accessible Authentication - Minimum, niveau AA) interdit de faire reposer la connexion uniquement sur un « test de mémoire cognitive ».

Sont particulièrement visés :

  • La mémorisation forcée de mots de passe complexes sans assistance.
  • Les puzzles visuels ou calculs mentaux servant de Captcha.
  • La transcription manuelle de codes de sécurité (OTP).

Ce que nous devons garantir côté code :

  1. Autoriser le copier-coller : Ne bloquez jamais l'événement paste sur les champs d'identifiant et de mot de passe.
  2. Prendre en charge les gestionnaires de mots de passe : Renseigner scrupuleusement les attributs autocomplete (username, current-password, one-time-code).
  3. Privilégier les solutions modernes : Adopter l'authentification par lien magique (Magic Link) ou par clés d'accès (Passkeys / WebAuthn).
<!-- Exemple d'input OTP compatible gestionnaires et SMS Autofill -->
<label for="otp-code">Code de confirmation à 6 chiffres</label>
<input
  type="text"
  id="otp-code"
  name="otp"
  inputmode="numeric"
  autocomplete="one-time-code"
  pattern="[0-9]{6}"
  required
/>

5. Saisie redondante : simplifier les formulaires longs

Dans les parcours d'achat ou les démarches administratives, devoir ressaisir deux fois la même information (comme l'adresse de facturation identique à l'adresse de livraison) est une cause fréquente d'abandon pour les personnes ayant des troubles cognitifs ou moteurs.

Le critère 3.3.7 (Redundant Entry, niveau A) exige que toute information déjà renseignée soit soit :

  • Auto-remplie automatiquement,
  • Sélectionnable par l'utilisateur (ex. : case à cocher « Utiliser la même adresse pour la facturation »).

6. Ce qui disparaît : l'adieu au critère de parsing (WCAG 4.1.1)

Une excellente nouvelle pour les auditeurs et intégrateurs : le critère 4.1.1 (Parsing / Analyse syntaxique) est désormais officiellement obsolète.

Introduit à l'époque où les navigateurs géraient très mal le HTML mal formé, ce critère mobilisait beaucoup de temps pour des erreurs mineures (un attribut dupliqué inoffensif, une balise fermée dans le mauvais ordre) qui n'avaient aucun impact réel sur les lecteurs d'écran modernes.

Le RGAA 5 concentre ainsi l'effort là où il a un impact direct sur l'expérience utilisateur.

En résumé : anticiper dès aujourd'hui dans vos Design Systems

L'arrivée du RGAA 5 et des WCAG 2.2 ne doit pas être attendue passivement. Les bénéfices pour l'expérience globale (UX) sont immédiats :

  • [x] Vérifiez les cibles tactiles de vos boutons et liens sur mobile (24px min via min-inline-size et min-block-size).
  • [x] Testez la navigation au clavier avec vos bandeaux fixes (scroll-padding-block-start).
  • [x] Supprimez les blocages de copier-coller dans les formulaires d'authentification.
  • [x] Harmonisez vos états :focus-visible dans votre Design System.

L'accessibilité n'est pas une contrainte normative figée : c'est la garantie d'une application robuste, inclusive et performante pour chacun de nos utilisateurs.