Accessibilité web : intégrer WCAG 2.2 dès la conception

La version 2.2 des Web Content Accessibility Guidelines est une recommandation du W3C depuis octobre 2023. Elle ne renverse pas les versions précédentes : elle reste rétrocompatible et se contente d’ajouter neuf critères de succès qui visent surtout la navigation au clavier, les interactions tactiles et l’authentification. Traiter l’accessibilité au moment de la conception, plutôt qu’en correctif de fin de projet, change radicalement le coût de mise en conformité. Un projet qui l’anticipe absorbe ces critères sans surcoût visible ; un projet qui les découvre à la recette paie chaque correction au prix fort.

#Ce que WCAG 2.2 ajoute

Les neuf nouveaux critères se répartissent sur les trois niveaux de conformité. La majorité relève du niveau AA, celui que visent les cadres réglementaires.

Deux critères méritent une attention immédiate. La taille de cible minimale (2.5.8) impose des zones cliquables d’au moins 24 par 24 pixels CSS, sauf exceptions : un menu de navigation dense ou des icônes trop serrées deviennent non conformes. L’authentification accessible (3.3.8) interdit d’exiger un test cognitif, comme retenir un mot de passe ou résoudre un puzzle, sans alternative : un champ compatible avec le gestionnaire de mots de passe suffit à la respecter.

Les autres critères visent des irritants concrets. Les mouvements de glissement (2.5.7) exigent qu’une action réalisable par glisser-déposer dispose d’une alternative par simple pointeur, au bénéfice des personnes atteintes de tremblements comme des utilisateurs sur écran tactile. L’aide cohérente (3.2.6) demande que les mécanismes d’assistance, formulaire de contact ou lien vers l’aide, apparaissent au même endroit d’une page à l’autre. La saisie redondante (3.3.7) interdit de redemander une information déjà fournie au cours d’un même parcours, sauf nécessité réelle : une adresse de livraison ne devrait pas être ressaisie à l’étape de facturation.

#Trois niveaux, une cible réaliste

Les critères se rangent en trois niveaux cumulatifs. Viser AAA sur un site entier n’est ni exigé ni toujours possible ; le niveau AA constitue la cible de référence.

#Traduire les critères en code

La plupart des critères se satisfont avec du HTML correct et quelques règles CSS, sans bibliothèque. Un champ de formulaire accessible associe une étiquette explicite, un type adapté et une aide reliée par aria-describedby.

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="email-aide">
<p id="email-aide">Format attendu : [email protected]</p>

L’attribut autocomplete satisfait directement l’authentification accessible : il laisse le navigateur et le gestionnaire de mots de passe remplir le champ, sans effort cognitif. Côté présentation, la taille de cible et la visibilité du focus se règlent en quelques lignes, en s’appuyant sur les variables du thème.

/* 2.5.8 Taille de cible (minimum) : 24 x 24 px */
.btn-icone {
  min-block-size: 24px;
  min-inline-size: 24px;
}

/* 2.4.11 Focus non masqué : un focus toujours visible */
:focus-visible {
  outline: 3px solid var(--focus, #1a9694);
  outline-offset: 2px;
}

Centraliser la couleur de focus dans une variable évite de la réintroduire à chaque composant et garde un rendu cohérent en thème clair comme sombre, dans la logique des design tokens. La même approche vaut pour l’espacement des cibles : définir une hauteur de ligne minimale sur les listes de navigation règle en une fois la conformité de dizaines de liens.

La saisie redondante se traite autant côté serveur que côté balisage. Un formulaire multi-étapes gagne à conserver les valeurs déjà saisies et à les pré-remplir, plutôt qu’à présenter des champs vides. Là encore, un attribut autocomplete bien choisi et la persistance de l’état entre les étapes suffisent, sans composant sur mesure.

#Le cadre légal européen

L’accessibilité n’est plus seulement une bonne pratique. L’European Accessibility Act s’applique depuis le 28 juin 2025 à de nombreux services numériques vendus aux particuliers dans l’Union : commerce en ligne, banque, billetterie, plateformes de contenu. En pratique, la norme technique de référence, EN 301 549, renvoie aux critères WCAG de niveau AA. En France, le RGAA transpose la même exigence pour les acteurs concernés, avec un principe désormais bien établi : l’absence de déclaration de conformité et de plan d’action est en soi un manquement, indépendamment de la qualité réelle du site.

Le périmètre concerné est large et souvent sous-estimé. Une place de marché, une application de réservation ou un espace client bancaire entrent dans le champ, quand un site strictement vitrine peut en rester exempté selon les cas. Vérifier son exposition en amont d’une refonte évite de découvrir l’obligation une fois le budget engagé, et un site non conforme s’expose désormais à un risque juridique, pas seulement à une critique d’ergonomie.

Un critère d’accessibilité corrigé sur la maquette coûte quelques minutes ; le même, repris en production, mobilise une équipe.

#Intégrer l’accessibilité au flux de travail

L’automatisation attrape une partie des défauts sans remplacer le contrôle humain. Un audit avec un moteur comme axe ou l’onglet Lighthouse du navigateur signale les contrastes insuffisants, les étiquettes manquantes et les cibles trop petites. Ces contrôles gagnent à être lancés au fil du développement plutôt qu’à la livraison, exactement comme le suivi d’un site s’installe en continu et non en fin de course. Intégrés à la chaîne d’intégration continue, ils bloquent une régression avant qu’elle n’atteigne la production, au même titre qu’un test unitaire cassé.

Le balisage sémantique, qui sous-tend l’accessibilité, sert aussi le référencement : un titre correctement structuré profite au lecteur d’écran comme au moteur de recherche, et une hiérarchie de titres claire aide autant l’un que l’autre. Investir dans une base sémantique propre revient donc à servir deux objectifs d’un seul geste, ce qui rend l’arbitrage budgétaire nettement plus facile à défendre auprès d’un client.

#Ce qu’il faut retenir

WCAG 2.2 ne bouleverse rien mais resserre les exigences là où les utilisateurs butent le plus : cibles tactiles, focus clavier, authentification. Le niveau AA est la cible concrète, désormais adossée à une obligation légale en Europe. La bonne démarche consiste à intégrer ces critères dès la conception, à s’appuyer sur du HTML sémantique et des variables de thème, et à compléter les audits automatiques par des tests humains. C’est moins un chantier ponctuel qu’une habitude à installer dans le flux de travail.

Pour aller plus loin : la spécification de référence, Web Content Accessibility Guidelines (WCAG) 2.2 (W3C).