Focus non masqué (minimum)
Lorsqu'un élément reçoit le focus clavier, il ne doit pas être entièrement masqué par un autre élément d'interface — en-têtes fixes, bandeaux de cookies, widgets de chat, pieds de page fixes. Nouveau dans WCAG 2.2, ce critère redéfinit la façon dont les équipes construisent les éléments fixes.
Ce que le critère exige
Lorsqu’un utilisateur accède à un contrôle par tabulation, au moins une partie de ce contrôle doit rester visible. Le cas d’échec le plus courant : un utilisateur navigue au-delà d’un en-tête fixe, la page défile automatiquement de sorte que le lien ayant le focus se retrouve derrière la barre fixe, et l’utilisateur ne voit plus l’indicateur de focus. Le contrôle a toujours le focus et répond toujours à Entrée, mais l’utilisateur ne peut pas le voir.
Le critère fixe un seuil minimum : l’élément ayant le focus peut être partiellement recouvert, mais pas entièrement. Le critère 2.4.12 de niveau AAA élève cette exigence à « pas du tout masqué ».
Il s’agit de l’un des quatre nouveaux critères d’opérabilité introduits dans WCAG 2.2 et qui a eu un impact considérable parce que les en-têtes fixes, pieds de page fixes, bandeaux de cookies et bulles de widgets de chat sont omniprésents.
Comment s’y conformer
- Ajouter la propriété CSS
scroll-margin-topaux éléments pouvant recevoir le focus, égale à la hauteur de l’en-tête fixe, afin que les navigateurs fassent automatiquement défiler le contrôle ayant le focus au-dessus de l’en-tête. - Pour les pieds de page fixes et les bulles de chat, s’assurer qu’ils ne recouvrent entièrement aucun élément pouvant recevoir le focus. Les réduire au focus ou les ancrer de façon à laisser une marge en bas de page.
- Bandeaux de cookies et superpositions fermables : ne jamais les rendre fixes de façon à ce que les points de tabulation ultérieurs se retrouvent en dessous. Les rendre modaux (avec piège à focus) ou non bloquants.
- Pour les pages dotées à la fois d’un en-tête fixe et d’un pied de page fixe, tester la séquence de tabulation autour du centre vertical de la fenêtre — c’est là que l’élément ayant le focus se trouve comprimé.
- Utiliser
scroll-padding-topsur le conteneur de défilement comme solution de repli pour les navigateurs plus anciens.
html { scroll-padding-top: 80px; } /* correspond à la hauteur de l'en-tête fixe */
:target, :focus { scroll-margin-top: 80px; }
Échecs courants
- En-tête fixe sans compensation
scroll-padding: chaque tabulation dans la moitié supérieure de la fenêtre masque l’indicateur de focus. - Bandeau de consentement aux cookies épinglé en bas qui recouvre la dernière rangée de champs de formulaire lorsque ceux-ci reçoivent le focus.
- Bulle de widget de chat en bas à droite qui chevauche un bouton « Envoyer » dans un coin de formulaire.
- Barres fixes promotionnelles (bandeaux du vendredi noir) ajoutées par les équipes marketing sans mise à jour des tokens
scroll-padding. - En-têtes de tableau fixes dans les tableaux de bord où Tab vers la première ligne de données atterrit derrière la ligne d’en-tête.
Pourquoi c’est important
Ce critère corrige une catégorie de problèmes qui frustre les utilisateurs du clavier quotidiennement mais qui apparaît rarement dans les analyses automatisées — aucune règle axe ne peut prévoir à quelle position de défilement un élément fixe chevauchera un élément ayant le focus. Il affecte aussi de façon disproportionnée les utilisateurs de loupes d’écran, dont la fenêtre visible est déjà réduite au quart de l’écran, de sorte que l’élément fixe occupe une part encore plus grande.
Le critère 2.4.11 sera l’une des nouvelles anomalies les plus citées dans les rapports d’audit de 2026. La correction est minime (quelques tokens CSS) mais nécessite la coordination de chaque équipe propriétaire d’un élément fixe — en-tête, pied de page, bandeau, widget.