Les WCAG 2.2 expliquées : Guide technique d'ingénierie

Vue d'ensemble des changements des WCAG 2.2

Le W3C a officiellement publié la recommandation WCAG 2.2 afin de combler des manques majeurs concernant l'ergonomie mobile, la navigation au clavier pour les personnes malvoyantes et l'accessibilité cognitive. Point notable : le critère 4.1.1 (Analyse syntaxique) a été supprimé, les navigateurs modernes appliquant désormais une correction d'erreurs HTML standardisée.

• 9 nouveaux critères de succès introduits (6 aux niveaux A/AA, 3 au niveau AAA).
• 1 critère obsolète déprécié (4.1.1 Analyse syntaxique / Parsing).
• Accent renforcé sur les interactions de pointage, la charge cognitive et la netteté des indicateurs de focus.

Apparence et visibilité du focus

Selon le critère 2.4.11 (Focus non masqué - Minimum, Niveau AA), les barres d'en-tête fixes ou bannières de cookies ne doivent pas masquer complètement un élément recevant le focus clavier. Selon le critère 2.4.13 (Apparence du focus, Niveau AAA), l'indicateur de focus doit garantir un ratio de contraste d'au moins 3:1 et une bordure minimale de 2px.

/* Recommended CSS for WCAG 2.2 compliant focus styling */
:focus-visible {
  outline: 3px solid #0284C7;
  outline-offset: 2px;
  scroll-margin-top: 5rem; /* Prevents sticky headers from obscuring focus */
  scroll-margin-bottom: 5rem;
}

Taille minimale des cibles de clic

Le critère 2.5.8 (Taille de la cible - Minimum, Niveau AA) impose aux cibles interactives une surface d'au moins 24 par 24 pixels CSS, à moins qu'un espacement suffisant n'empêche le chevauchement avec une autre cible.

• Les liens textuels intégrés dans des paragraphes sont exemptés.
• Les cibles intrinsèquement denses (comme des repères cartographiques précis) bénéficient d'exceptions.
• La recommandation pour les cibles tactiles reste de 44x44px (iOS) et 48x48px (Android).

Mouvements de glisser-déposer et alternatives

En vertu du critère 2.5.7 (Mouvements de glisser, Niveau AA), toute interface reposant sur le glisser-déposer (tableaux Kanban, curseurs) doit proposer une alternative par simple clic, comme des boutons haut/bas ou un champ numérique.

// Example: Pairing drag-and-drop with accessible button controls
<div role="listitem">
  <span>Task Name</span>
  <div className="flex gap-2">
    <button aria-label="Move task up" onClick={moveUp}>↑</button>
    <button aria-label="Move task down" onClick={moveDown}>↓</button>
  </div>
</div>

Saisie redondante et authentification accessible

Le critère 3.3.7 (Saisie redondante, Niveau A) interdit de demander à nouveau des données déjà renseignées au cours d'une même session. Le critère 3.3.8 (Authentification accessible, Niveau AA) exige que la connexion ne repose pas uniquement sur des tests cognitifs (mémorisation ou CAPTCHAs complexes) sans proposer d'alternative comme le remplissage automatique ou les passkeys.

Liste de contrôle technique d'implémentation

Consultez cette liste lors des revues de code pour garantir la conformité aux WCAG 2.2 avant le déploiement en production :

• Vérifier que les en-têtes fixes ne masquent pas les éléments actifs (utiliser scroll-margin).
• S'assurer que les boutons et icônes d'action disposent d'au moins 24x24px de zone réactive.
• Proposer des raccourcis clavier ou des boutons haut/bas pour toute réorganisation par glisser.
• Autoriser le copier-coller dans tous les champs de mot de passe et codes de vérification.
• Pré-remplir automatiquement les coordonnées répétées dans les formulaires multi-étapes.