Focus non masqué WCAG (2.4.11) : en-tête collant, bannière cookies et scroll-padding

Ce que dit exactement le critère 2.4.11 Focus non masqué

Le texte normatif est court : lorsqu'un composant d'interface reçoit le focus clavier, il n'est pas entièrement masqué par du contenu créé par l'auteur. Le mot important est « entièrement » : au niveau AA, un composant partiellement recouvert peut passer. Le W3C justifie cette tolérance par la complexité des designs responsives actuels, tout en rappelant qu'un composant plus il est recouvert, moins il est facile à voir. Les auteurs devraient donc chercher à réduire le degré et la fréquence de ce recouvrement partiel.

Le résultat idéal, aucun recouvrement du tout, relève d'un autre critère, de niveau AAA : Focus non masqué (amélioré). Pour viser la meilleure visibilité, considérez donc le niveau AA comme un plancher, pas comme un objectif.

Le critère évalue le composant focalisé, et non l'indicateur de focus. L'indicateur de focus n'est pris en compte que s'il est à l'intérieur du composant, ou si le focus est signalé par une modification du composant lui-même. Le W3C précise que ce choix donne une mesure plus claire, mais qu'un indicateur de focus totalement caché échouerait probablement au critère 2.4.7 Visibilité du focus.

• Note 1 : si l'utilisateur peut déplacer un contenu dans une interface configurable, seule la position initiale de ce contenu est évaluée.
• Note 2 : un contenu ouvert par l'utilisateur peut masquer le composant focalisé ; si l'utilisateur peut révéler ce composant sans faire avancer le focus clavier, le composant focalisé n'est pas considéré comme masqué par du contenu créé par l'auteur.

Focus non masqué WCAG : pourquoi un en-tête collant ou une bannière de cookies peut cacher le focus

Le W3C cite justement les pieds de page collants, les en-têtes collants et les boîtes de dialogue non modales comme types de contenu qui peuvent typiquement recouvrir les éléments focalisés : à mesure que l'utilisateur avance dans la page avec la touche Tab, ces couches peuvent masquer l'élément qui reçoit le focus, ainsi que son indicateur de focus.

Le W3C cite explicitement la bannière de cookies comme exemple. Une notification implémentée comme contenu collant, par exemple une bannière de cookies, échoue au critère si elle masque entièrement un composant qui reçoit le focus. Pour les personnes voyantes qui utilisent le clavier, ou un dispositif qui passe par l'interface clavier comme un contacteur ou la commande vocale, savoir où se trouve le focus est essentiel : sans le voir, elles risquent de ne pas savoir comment continuer, voire de penser que le système ne répond plus.

Un autre cas mérite l'attention : les surcouches semi-transparentes, floutées ou assombries. Il se peut que l'élément focalisé ne soit pas entièrement masqué par ces surcouches, et qu'il réussisse donc le critère 2.4.11, tout en échouant séparément au critère 1.4.11 Contraste du contenu non textuel : l'indicateur de focus doit alors être évalué au regard des exigences de contraste du 1.4.11, tel qu'il apparaît sous la surcouche.

Corriger avec scroll-padding : la technique CSS C43

La technique suffisante citée par le W3C pour ce critère est la technique C43 : utiliser la propriété CSS scroll-padding pour démasquer le contenu. Le principe, illustré par l'exemple du W3C : sur une page dotée d'un pied de page collant, l'élément focalisé n'est pas complètement masqué, parce que le contenu de la fenêtre défile pour toujours afficher l'élément qui a le focus clavier grâce au scroll padding. Le W3C mentionne aussi le scroll padding pour les bannières : il permet que la bannière ne chevauche pas le reste du contenu.

L'exemple ci-dessous est une illustration de notre part, à adapter : la page Understanding du W3C cite la technique C43 sans en détailler la syntaxe. Nous y donnons à scroll-padding une valeur correspondant à la hauteur de chaque barre collante ; vérifiez le résultat au clavier à chaque point de rupture.

/* Illustration : réserver la place de l'en-tête et du pied de page collants */
html {
  scroll-padding-top: 5rem;    /* hauteur de l'en-tête collant */
  scroll-padding-bottom: 4rem; /* hauteur du pied de page collant */
}

.site-header {
  position: sticky;
  top: 0;
}

/* Indicateur de focus visible au clavier (technique C45) */
a:focus-visible,
button:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 2px;
}

Bannières, dialogues et contenus ouverts : les autres solutions

Le scroll-padding n'est pas la seule voie. Pour une bannière de cookies ou une notification collante, le W3C décrit plusieurs façons de réussir le critère :

• Rendre la bannière modale : l'utilisateur doit la fermer avant de naviguer dans la page. Une boîte de dialogue modale correctement construite réussit toujours ce critère, car elle prend le focus à son apparition et empêche toute interaction en dehors d'elle jusqu'à sa fermeture.
• Utiliser le scroll padding pour que la bannière ne chevauche pas le reste du contenu.
• Pour une notification qui n'exige pas d'action, la fermer lorsqu'elle perd le focus.

Contenus persistants ouverts par l'utilisateur

Pour un contenu persistant que l'utilisateur ouvre lui-même, comme un accordéon, un chatbot ou une navigation latérale dépliable, le W3C décrit d'autres approches qui évitent de masquer le focus :

• Le contenu ouvert déplace le contenu existant, comme un accordéon qui repousse la suite de la page vers le bas.
• Le contenu existant se réorganise pour faire de la place, comme une barre latérale qui réduit la largeur de la zone principale.
• Le contenu ouvert prend le focus et la navigation au clavier y reste limitée jusqu'à sa fermeture ; le W3C conseille de l'utiliser avec prudence, car cela peut créer une expérience inégale entre utilisateurs du clavier et du pointeur.
• Le contenu s'ouvre dans une zone de la page qui ne contient aucun autre contenu, à condition de vérifier qu'il ne masque rien à chaque point de rupture responsive.
• Le contenu se masque automatiquement quand le focus le quitte, ou via une commande clavier dédiée comme la touche Échap.

Le lien avec la visibilité du focus (critère 2.4.7)

Le critère 2.4.7 Visibilité du focus, également de niveau AA, exige que toute interface utilisable au clavier dispose d'un mode de fonctionnement dans lequel l'indicateur de focus clavier est visible. Son objectif : permettre à chacun de savoir quel élément a le focus. Le W3C précise que l'indicateur ne doit pas être limité dans le temps : une fois affiché, il doit rester visible.

Les deux critères sont complémentaires. Le 2.4.7 vérifie que l'indicateur de focus est visible, dans au moins un mode de fonctionnement ; le 2.4.11 vérifie que le composant focalisé n'est pas entièrement caché par du contenu créé par l'auteur. Un contour de focus parfaitement dessiné ne sert à rien s'il disparaît sous un en-tête collant. Parmi les techniques suffisantes du 2.4.7 figurent C15 (changer la présentation d'un composant au focus avec CSS), C40 (indicateur bicolore pour un contraste suffisant) et C45 (utiliser :focus-visible). Parmi les échecs, F78 vise les styles de contour ou de bordure qui suppriment ou rendent invisible l'indicateur de focus, et F55 le script qui retire le focus à sa réception.

Tester le focus non masqué sur votre site

Un test manuel au clavier permet de vérifier ce critère. Parcourez chaque gabarit de page uniquement au clavier, avec Tab et Maj+Tab, en observant à chaque étape si l'élément focalisé reste visible.

• Testez avec l'en-tête collant affiché, et avec la bannière de cookies encore ouverte.
• Parcourez toute la page, vers le bas avec Tab puis vers le haut avec Maj+Tab, pour vérifier aussi bien le pied de page que l'en-tête collants.
• Répétez le test à chaque point de rupture responsive.
• Ouvrez les contenus persistants (chat, panneau de retour d'expérience, navigation latérale), puis vérifiez qu'Échap ou le défilement au clavier permet de révéler l'élément focalisé.
• Vérifiez en parallèle que l'indicateur de focus est visible et contrasté.

Questions fréquentes

À lire aussi sur Conformly

• Corriger la visibilité du focus en HTML
• Fiche du critère RGAA 10.7
• Tout savoir sur le RGAA 5

Sources

Article appuyé sur les sources officielles citées en fin de page.

• W3C — Comprendre 2.4.11
• W3C — Comprendre 2.4.7