Implémenter les nouveaux critères WCAG 2.2 en code

WCAG 2.2 n’est pas une refonte : c’est la version 2.1 augmentée de neuf critères, dont plusieurs se règlent par quelques lignes de CSS et de HTML. Le problème, c’est que ces critères sont souvent traités comme l’affaire des auditeurs, à la fin du projet. Pris à l’envers, ils deviennent une dette coûteuse. Pris pendant le développement, ce sont des réflexes peu coûteux. Ce tutoriel implémente, un par un, les nouveaux critères les plus concrets pour un développeur front-end.

🎯 Ce que vous allez apprendre

• Situer WCAG 2.2 par rapport à 2.1 : ce qui a été ajouté, ce qui a été retiré.
• Garantir une taille de cible tactile suffisante (critère 2.5.8) en CSS.
• Empêcher qu’un en-tête collant masque l’élément qui reçoit le focus (critère 2.4.11).
• Rendre le focus clavier franchement visible (critères 2.4.7 et 2.4.13).
• Offrir une alternative aux gestes de glissement (2.5.7) et faciliter l’authentification (3.3.8).

🛠️ Ce que vous allez construire

Une page de formulaire de connexion et son menu, durcis selon les nouveaux critères : boutons assez grands, focus jamais caché ni invisible, champ de mot de passe qui accepte le collage et l’autocomplétion, et un réglage de volume manipulable autrement qu’au glissement. Chaque correctif est isolé pour que vous puissiez le transposer tel quel à votre projet.

Prérequis

• Des bases solides en HTML et CSS. Le JavaScript reste minimal.
• Une page sur laquelle expérimenter — idéalement un formulaire et un menu.
• Savoir naviguer au clavier (touche Tab) pour tester le focus. Test express : si vous savez atteindre un bouton sans la souris, vous êtes prêt.
• ⏱️ Temps estimé : ~40 minutes.

Étape 1 — Situer WCAG 2.2

WCAG 2.2 a été publiée comme recommandation du W3C le 5 octobre 2023. Elle conserve l’intégralité des critères de 2.1, avec une seule exception : le critère 4.1.1 « Analyse syntaxique » est devenu obsolète et a été retiré, car les navigateurs corrigent désormais le balisage mal formé de façon homogène. À l’inverse, neuf nouveaux critères font leur entrée, répartis sur trois niveaux (A, AA, AAA). Pour la conformité courante visée par la plupart des organisations — le niveau AA — six d’entre eux comptent. Plutôt que de les apprendre par cœur, implémentons les plus opérationnels.

Étape 2 — Taille de cible minimale (critère 2.5.8, AA)

Une cible trop petite est difficile à atteindre pour qui a des tremblements, utilise un écran tactile en mouvement, ou vise mal. Le critère 2.5.8 demande que chaque cible interactive mesure au moins 24 × 24 pixels CSS, ou qu’un espacement suffisant l’entoure (un cercle de 24 px centré sur la cible ne doit pas en chevaucher un autre). En CSS, on garantit la taille minimale ainsi :

.btn, .icon-button {
  min-width: 24px;
  min-height: 24px;
  /* confort recommandé : viser plutôt 44px sur tactile */
  padding: 10px 14px;
}

Le minimum normatif est 24 px, mais visez plus large quand c’est possible : un confort de 44 px (la valeur recommandée de longue date sur mobile) reste un meilleur objectif. Des exceptions existent — les liens au fil du texte, les cibles dont la taille est imposée par le navigateur, ou celles ayant un équivalent plus grand ailleurs sur la page. Mais pour les petits boutons à icône (fermer, supprimer, options), c’est précisément là que le critère mord : ne les laissez pas descendre sous 24 px.

Étape 3 — Focus jamais masqué (critère 2.4.11, AA)

Les en-têtes collants (position: sticky) sont partout. Le problème : quand l’utilisateur tabule vers un champ situé juste sous l’en-tête, le navigateur fait défiler le champ en haut de la zone visible… où l’en-tête le recouvre. L’élément a le focus mais reste invisible. Le critère 2.4.11 exige qu’il ne soit pas entièrement masqué. La parade est purement CSS, grâce à scroll-margin-top :

:root { --header-h: 64px; }

header.sticky { position: sticky; top: 0; height: var(--header-h); }

/* réserve la hauteur de l'en-tête lors du défilement vers une cible */
:target, a, button, input, select, textarea {
  scroll-margin-top: calc(var(--header-h) + 8px);
}

La propriété scroll-margin-top indique au navigateur de s’arrêter un peu plus tôt lorsqu’il amène un élément dans la vue, en réservant la hauteur de l’en-tête. Testez en tabulant à travers la page : chaque champ atteint doit apparaître sous l’en-tête, entièrement visible. Si un champ se cache encore, augmentez la marge.

✅ Point d’étape — En parcourant la page à la touche Tab, aucun élément focalisé ne disparaît derrière l’en-tête. Si l’un reste à moitié couvert, c’est que sa scroll-margin-top est inférieure à la hauteur réelle de l’en-tête.

Étape 4 — Un focus franchement visible (critères 2.4.7 et 2.4.13)

Le réflexe le plus nuisible à l’accessibilité tient en une ligne : outline: none. Le supprimer rend la navigation clavier impossible à suivre. Le critère 2.4.7 impose un focus visible ; le nouveau 2.4.13 (niveau AAA) en précise la qualité : contour assez épais et contrasté. On garde donc toujours un indicateur, et on le rend net avec :focus-visible, qui n’affiche le contour qu’à la navigation clavier — pas au clic souris :

:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
  border-radius: 4px;
}
/* ne JAMAIS faire : *:focus { outline: none; } */

Le pseudo-sélecteur :focus-visible règle le vieux compromis entre esthétique et accessibilité : les utilisateurs souris ne voient pas de contour au clic, mais les utilisateurs clavier conservent un repère évident. Un contour de 3 px avec un décalage offre le contraste demandé. Vérifiez en tabulant : le contour doit être impossible à manquer sur chaque élément.

Étape 5 — Une alternative au glissement (critère 2.5.7, AA)

Régler un volume, réordonner une liste, déplacer un curseur : ces gestes reposent souvent sur le glissement, impossible pour qui ne peut pas maintenir un mouvement précis. Le critère 2.5.7 exige qu’une action accessible par glissement le soit aussi par une action ponctuelle simple. Pour un curseur de volume, on ajoute donc des boutons d’incrément :

<label for="vol">Volume</label>
<button type="button" aria-label="Baisser le volume">−</button>
<input id="vol" type="range" min="0" max="100" value="50">
<button type="button" aria-label="Monter le volume">+</button>

Le champ range reste glissable pour ceux que cela arrange, mais les deux boutons offrent la même action par simple clic ou appui. Ce doublon n’est pas une redondance inutile : c’est exactement ce que demande le critère. La même logique s’applique à une liste réordonnable, qui doit proposer des boutons « monter / descendre » en plus du glisser-déposer.

Étape 6 — Authentification accessible (critère 3.3.8, AA)

Le critère 3.3.8 vise les obstacles cognitifs à la connexion. Concrètement, trois réflexes le satisfont. D’abord, ne jamais bloquer le collage dans le champ de mot de passe : interdire le collage casse les gestionnaires de mots de passe, sur lesquels reposent énormément d’utilisateurs. Ensuite, déclarer l’autocomplétion pour que le navigateur et les gestionnaires remplissent les champs. Enfin, éviter les énigmes (reconnaître des images, résoudre un calcul) sans alternative.

<input type="email" name="email" autocomplete="username">
<input type="password" name="password" autocomplete="current-password">
<!-- ne PAS ajouter onpaste="return false" -->

Les valeurs autocomplete="username" et autocomplete="current-password" sont reconnues par les navigateurs et les gestionnaires de mots de passe, qui proposent alors le remplissage. C’est à la fois un gain d’accessibilité et un gain de conversion. Si vous devez lutter contre les robots, préférez des mécanismes invisibles à une énigme imposée à tous.

✅ Point d’étape — Vous pouvez coller un mot de passe dans le champ, et votre gestionnaire propose le remplissage. Si le collage est refusé, cherchez un gestionnaire d’événement paste qui l’empêche et retirez-le.

Étape 7 — Aide cohérente et saisie non redondante (3.2.6 et 3.3.7)

Deux critères de niveau A complètent l’ensemble. Le 3.2.6 « Aide cohérente » demande que les moyens d’obtenir de l’aide (lien de contact, numéro, chat) apparaissent toujours au même endroit relatif d’une page à l’autre — typiquement en fin d’en-tête ou de pied de page. C’est une décision de gabarit : on place le bloc d’aide dans le composant partagé, pas page par page.

Le 3.3.7 « Saisie redondante » interdit de redemander une information déjà fournie dans le même parcours, sauf exceptions (re-saisie volontaire d’un mot de passe, donnée périmée). En pratique : pré-remplissez l’adresse de livraison à partir de l’adresse de facturation, ou proposez une case « identique à ». Le bénéfice dépasse l’accessibilité : moins de saisie, moins d’abandons.

Vérifier ces critères à la main en cinq minutes

Les outils automatisés ne détectent qu’une partie des problèmes d’accessibilité ; plusieurs des critères ci-dessus échappent en partie à la machine et se contrôlent mieux à la main. Voici un protocole court à passer avant chaque livraison, sans installer quoi que ce soit.

Premier contrôle, la navigation clavier seule. Posez la souris, et parcourez la page entière à la touche Tab, puis Maj+Tab dans l’autre sens. Trois choses doivent être vraies en permanence : vous voyez toujours où se trouve le focus (critères 2.4.7 et 2.4.13), l’élément focalisé n’est jamais caché par un en-tête collant (2.4.11), et l’ordre de parcours suit la logique visuelle. Si le focus disparaît ne serait-ce qu’une fois, vous avez un défaut bloquant — la majorité des utilisateurs de lecteurs d’écran et des personnes à mobilité réduite naviguent ainsi.

Deuxième contrôle, la taille des cibles. Ouvrez les outils de développement du navigateur, sélectionnez un petit bouton à icône, et lisez ses dimensions dans le panneau. Si l’un descend sous 24 px de côté sans espacement compensatoire, le critère 2.5.8 n’est pas tenu. Les coupables habituels sont les croix de fermeture, les chevrons et les puces d’action dans les tableaux denses.

Troisième contrôle, le zoom à 200 %. Augmentez le zoom du navigateur à 200 % et vérifiez que rien ne se chevauche, ne se tronque, ni n’exige de défilement horizontal pour lire un paragraphe. Ce test, hérité de 2.1, révèle souvent des cibles qui se collent les unes aux autres au point d’invalider l’espacement prévu pour 2.5.8.

Quatrième contrôle, le parcours de connexion. Tentez de coller un mot de passe et de laisser votre gestionnaire remplir les champs. Si le collage est refusé ou si l’autocomplétion ne se déclenche pas, revoyez l’étape 6. Ce protocole de cinq minutes ne remplace pas un audit complet ni les tests automatisés du tutoriel dédié, mais il intercepte l’écrasante majorité des régressions au moment où elles coûtent le moins cher à corriger : juste avant de livrer.

🐞 Pièges fréquents

✅ Récapitulatif

Vous avez implémenté, en code, les nouveaux critères de WCAG 2.2 les plus concrets : taille de cible, focus non masqué et bien visible, alternative au glissement, authentification accueillante, aide cohérente et saisie non redondante. Aucun ne demande de bibliothèque : ce sont des décisions de CSS, de HTML et de gabarit, prises au moment du développement plutôt que subies à l’audit.

🧾 Aide-mémoire

💪 À vous de jouer

Reprenez une fenêtre modale de votre projet et vérifiez trois choses : que le bouton de fermeture fait au moins 24 px, que le focus entre dans la modale à l’ouverture et que son contour est visible, et qu’une éventuelle action de glissement (par exemple un curseur de réglage) dispose d’une alternative cliquable.

Tutoriels de la série

• Construire des composants React accessibles avec ARIA — la gestion du focus et des rôles, au-delà du CSS.
• Tester l’accessibilité en intégration continue — pour ne plus régresser.

Pour aller plus loin

• 🔝 Retour au guide principal : Du design au code : Figma, tokens et WCAG 2.2.
• Approche conçue côté conception : Accessibilité web : concevoir pour tous les utilisateurs.
• Référence officielle : W3C — What’s New in WCAG 2.2.

FAQ

Dois-je viser AA ou AAA ?
La conformité de référence est le niveau AA ; c’est ce qu’exigent la plupart des cadres légaux. Le niveau AAA (critères 2.4.12, 2.4.13, 3.3.9) est un objectif d’excellence, rarement requis sur l’ensemble d’un site.

Le retrait de 4.1.1 signifie-t-il que le HTML mal formé n’a plus d’importance ?
Non. Un balisage propre reste essentiel pour les technologies d’assistance ; simplement, ce critère précis ne capturait plus de bénéfice réel et faisait doublon avec d’autres règles.

WCAG 2.2 remplace-t-elle 2.1 ?
Elle l’étend. Un site conforme 2.2 niveau AA l’est aussi en 2.1, puisque 2.2 ajoute des critères sans en retirer (hormis 4.1.1, désormais sans objet).

Ces critères s’appliquent-ils aux applications mobiles ?
Les principes oui, et la taille de cible y est même plus critique. La déclinaison technique diffère selon la plateforme, mais l’intention reste identique.