Normes · WCAG 2.2

SC 2.4.13 Niveau AAA WCAG 2.2 Nouveau dans la 2.2

Apparence du focus

L'indicateur de focus clavier doit satisfaire une barre visuelle mesurable : au moins 2 pixels CSS d'épaisseur sur le périmètre, au moins 3:1 de contraste par rapport à l'état non focalisé, et non masqué. Nouveau dans WCAG 2.2 ; la règle de style de focus la plus concrète jamais publiée dans la spécification.

Ce que le critère exige

Le critère 2.4.7 (Focus visible) indique que l’indicateur doit exister. Le critère 2.4.13 (Apparence du focus) précise exactement à quoi il doit ressembler. Pour être conforme, l’indicateur de focus doit :

  1. Avoir une surface au moins aussi grande qu’un périmètre solide de 2 pixels CSS autour du contrôle ayant le focus, ou une ligne d’1 px d’épaisseur de même surface totale.
  2. Atteindre un contraste de 3:1 entre les états focalisé et non focalisé des mêmes pixels.
  3. Ne pas être masqué par d’autres contenus (ce qui relève également des critères 2.4.11 et 2.4.12).

C’est la première fois que WCAG fixe des chiffres sur le style du focus, et cela a redéfini la façon dont les systèmes de conception gèrent les styles clavier. Tous les audits d’accessibilité de 2026 devraient le mentionner explicitement.

Comment s’y conformer

  • Utiliser un contour solide d’au moins 2 px d’épaisseur. Modèle courant : outline: 2px solid currentColor; outline-offset: 2px;.
  • Choisir une couleur de focus atteignant 3:1 par rapport à la couleur adjacente, pas seulement l’arrière-plan de la page — les boutons se posent sur des états de survol, des dégradés, des images.
  • Pour les modes sombre et clair, livrer deux couleurs de focus et les permuter via prefers-color-scheme ou un système de tokens.
  • Éviter de se fier à un halo ou à un anneau box-shadow à faible contraste ; en cas d’utilisation de box-shadow, lui donner un bord net et une épaisseur suffisante.
  • Préférer :focus-visible pour éviter que les utilisateurs à la souris voient l’anneau, mais s’assurer qu’il s’active à chaque focus clavier, y compris le focus programmatique.
:focus-visible {
  outline: 2px solid #1d4ed8;       /* 3:1 sur fond blanc et états de survol gris */
  outline-offset: 2px;
  border-radius: inherit;
}

Échecs courants

  • Indicateurs de focus de 1 px (valeurs par défaut de la plupart des navigateurs avant 2023 pour les bibliothèques de composants).
  • Anneau de focus bleu marque sur un bouton dont l’état de survol est également bleu marque — couleur identique, contraste 1:1.
  • Focus stylisé uniquement avec un box-shadow doux sans bord défini, qui disparaît sur des arrière-plans à motifs.
  • Champs personnalisés dont l’état de focus ne modifie que la couleur de la bordure sans en changer l’épaisseur ni le contraste — trop subtil pour être pris en compte.
  • Anneaux de focus « en incrustation » sur les petits boutons d’icônes qui se peignent à l’intérieur de la zone de clic 16×16 et finissent invisibles derrière le glyphe de l’icône.
  • Composants conformes sur fond blanc mais non conformes en mode sombre que personne n’a testé.

Liste de contrôle pratique du contraste

Pour chaque composant interactif, lister tous les états de surface sur lesquels il peut se poser (par défaut, survol, pressé, désactivé, dans une carte, dans une modale, sur une image hero) et vérifier que l’anneau de focus atteint 3:1 pour chacun. C’est fastidieux ; les bibliothèques de composants qui ne le font pas livrent des défauts cachés. L’automatisation via Storybook + pa11y ou axe-playwright est rentable ici.

Pourquoi c’est important

Le critère 2.4.13 comble la faille la plus courante de 2.4.7 : un indicateur de focus qui existe techniquement mais est trop fin, trop peu contrasté ou trop rogné positionnellement pour être utile. Les utilisateurs malvoyants qui dépendent de l’anneau pour suivre le focus bénéficient d’une garantie mesurable et testable. Les designers disposent d’une règle claire qu’ils peuvent valider avant la mise en production plutôt que de négocier après.

Même les équipes engagées formellement sur le niveau AA uniquement adoptent largement le critère 2.4.13 comme cible, car les modes d’échec sont faciles à repérer lors des audits et faciles à invoquer dans les contentieux. Si une seule règle AAA de WCAG 2.2 doit être adoptée, c’est celle-ci.