WCAG 2.2 : les 9 critères que le RGAA ne teste pas

Un audit RGAA ne vous reprochera jamais un bouton de 16 pixels, ni un réordonnancement qui n'existe qu'au glisser-déposer, ni un formulaire qui redemande votre adresse trois fois. Ces trois situations sont pourtant des échecs caractérisés au regard des WCAG 2.2.

La raison est simple et souvent mal comprise : le RGAA 4.1.2 est adossé aux WCAG 2.1. Cet article fait l'inventaire des 9 critères manquants, sépare ceux qui valent l'investissement immédiat de ceux qui peuvent attendre, et donne le code pour les trois plus rentables.

La vérification, dans le texte officiel

L'affirmation « le RGAA ne couvre pas les WCAG 2.2 » circule beaucoup. Elle se vérifie directement.

Chaque critère du RGAA 4.1.2 publie ses correspondances WCAG, consultables dans le référentiel officiel. En cherchant les neuf identifiants ajoutés par les WCAG 2.2 (recommandation W3C du 12 décembre 2024) dans l'intégralité des 106 critères et de leurs tests, le résultat est net : aucune occurrence. Ni 2.4.11, ni 2.5.7, ni 2.5.8, ni 3.2.6, ni 3.3.7, ni 3.3.8, ni les trois de niveau AAA.

Pour la chronologie complète du référentiel et de ses versions, voir notre article sur les évolutions du RGAA.

Les quatre critères qui changent le quotidien

2.5.8 Taille de cible (minimum), niveau AA

Toute cible de pointage doit mesurer au moins 24 par 24 pixels CSS, sauf exceptions (lien dans un texte, cible dont l'espacement compense, contrainte essentielle).

C'est le critère au meilleur rapport effort/bénéfice de la liste. Les icônes d'action dans les tableaux, les croix de fermeture et les puces de pagination sont les fautifs habituels.

/* Mauvais : la zone cliquable épouse l'icône */
.btn-icone { padding: 2px; }

/* Bon : la cible atteint 24px sans changer la taille visuelle de l'icône */
.btn-icone {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-inline-size: 24px;
  min-block-size: 24px;
}

2.5.7 Mouvements de glissement, niveau AA

Toute fonction qui repose sur un glissement doit avoir une alternative en simple pointage. Réordonner une liste, ajuster un curseur de prix, déplacer une carte dans un tableau de suivi : chacune de ces interactions doit exister en boutons.

<!-- Le glisser-déposer reste disponible, l'alternative aussi -->
<li draggable="true">
  Tâche à traiter
  <button type="button" aria-label="Monter : Tâche à traiter">↑</button>
  <button type="button" aria-label="Descendre : Tâche à traiter">↓</button>
</li>

3.3.7 Saisie redondante, niveau A

Une information déjà fournie dans un même parcours ne doit pas être redemandée, sauf exceptions (confirmation d'un mot de passe, réponse à un test). L'adresse de facturation identique à l'adresse de livraison est le cas d'école.

Le remède n'est pas technique mais fonctionnel : une case « identique à l'adresse de livraison », ou une valeur pré-remplie modifiable.

3.3.8 Authentification accessible (minimum), niveau AA

Aucune étape de connexion ne doit reposer sur un test cognitif (retenir un code, résoudre un puzzle, recopier des caractères) sans mécanisme alternatif. Concrètement, le collage doit fonctionner dans les champs de mot de passe et de code à usage unique.

<!-- Mauvais : le collage est bloqué, le gestionnaire de mots de passe aussi -->
<input type="password" onpaste="return false" autocomplete="off" />

<!-- Bon : le navigateur et le gestionnaire font leur travail -->
<input type="password" autocomplete="current-password" />
<input type="text" inputmode="numeric" autocomplete="one-time-code" />

Ce critère recoupe un piège que nous avons documenté : une validation branchée sur keyup empêche un gestionnaire de mots de passe de débloquer un formulaire. Le détail figure dans notre article sur le bouton désactivé et les angles morts du RGAA.

Les trois critères de focus, et le seul qui compte vraiment

Les WCAG 2.2 ajoutent trois exigences sur le focus. Deux sont de niveau AAA, donc hors du périmètre habituel d'une mise en conformité.

Le seul de niveau AA, 2.4.11, exige que l'élément qui reçoit le focus ne soit pas entièrement masqué par un autre contenu. Le coupable est presque toujours le même : un en-tête collant qui recouvre le champ vers lequel la tabulation vient d'amener l'utilisateur.

/* L'ancrage de défilement réserve la hauteur de l'en-tête collant */
:root { --hauteur-entete: 72px; }
main :target,
main :focus-visible { scroll-margin-block-start: var(--hauteur-entete); }

À ne pas confondre avec la visibilité du focus, qui est déjà exigée en France par le critère RGAA 10.7 et que nous détaillons dans notre article sur les indicateurs de focus. Le critère 2.4.11 ne parle pas du style du focus mais de son occultation par un autre élément.

3.2.6 Aide cohérente, et la question de la priorité

Le neuvième critère, 3.2.6 Aide cohérente (niveau A), demande que les mécanismes d'aide présents sur plusieurs pages (numéro de téléphone, formulaire de contact, fenêtre de discussion, lien d'aide) apparaissent dans le même ordre relatif d'une page à l'autre. Un gabarit unique suffit à le satisfaire, ce qui en fait généralement un non-sujet.

Reste la vraie question : que faire de ces neuf critères aujourd'hui ?

Cinq à traiter, un déjà réglé par la structure du site, trois à laisser de côté sauf exigence particulière.

Une précision d'honnêteté : rien de tout cela n'entre dans votre déclaration d'accessibilité. Le taux publié se calcule sur les 106 critères du RGAA 4.1.2 et sur eux seuls. Ce travail est un investissement d'usage et d'anticipation, pas une amélioration de score.

Conclusion

Les WCAG 2.2 comblent des angles morts que les WCAG 2.1, et donc le RGAA, laissent ouverts : viser une cible, se passer du glissement, ne pas ressaisir, se connecter sans effort de mémoire. Ces situations touchent en premier lieu des utilisateurs à mobilité réduite ou à troubles cognitifs, pour qui la conformité française actuelle ne dit rien.

Cinq critères valent le détour dès maintenant. Trois sont l'affaire d'une feuille de style et d'une paire de boutons.

Pour situer d'abord votre page sur ce qui est réellement opposable aujourd'hui, lancez une analyse : le scan remonte les anomalies sur les critères RGAA en vigueur et vous laisse la liste de ce qui demande un test humain.