Lorsqu’un composant d’interface utilisateur reçoit le focus clavier, l’indicateur de focus doit présenter un contraste des couleurs d’au moins 3:1 par rapport à la couleur adjacente et couvrir au minimum le périmètre d’un contour plein de 2 pixels CSS autour de l’élément focalisé, ou une zone d’indicateur équivalente. Ce critère est l’une des rares additions WCAG qui spécifie une géométrie mesurable plutôt qu’un comportement.

Les anneaux de focus navigateur par défaut que les designers ont passé quinze ans à supprimer pour des raisons esthétiques échouent à cette mesure sur la majorité des sites en production audités. Les styles de focus personnalisés ont tendance à utiliser des contours de 1 px ou des couleurs d’accent à faible contraste qui paraissent corrects dans les outils de design mais obtiennent un score inférieur à 3:1 par rapport à l’arrière-plan de l’élément focalisé réel.

Le chiffre compte même si le critère est AAA : il indique ce qui se passerait si un futur régulateur épinglait WCAG 2.2 au niveau AAA, ou si un contrat de marché public élevait ce critère spécifique.

Définir un contour de 2 pixels CSS d’une couleur obtenant au moins 3:1 par rapport à l’arrière-plan de l’élément ; vérifier avec un vérificateur de contraste plutôt qu’à l’œil. Lorsque le système de design remplace le focus navigateur, exposer un token de style de focus que les designers ne peuvent pas faire descendre accidentellement sous le seuil de contraste.

La cible de frappe de chaque entrée pointeur doit mesurer au moins 24 par 24 pixels CSS, sauf si la cible est intégrée dans une phrase, si elle est dimensionnée par l’agent utilisateur, si une cible équivalente est disponible, ou si la fonction de la cible est essentielle. Le critère mesure la cible de frappe, non l’icône visible.

Le critère détecte un schéma UI spécifique : les barres d’outils à icônes denses, notamment dans les éditeurs, les tableaux de bord et les en-têtes de tableaux de données. La plupart des bibliothèques de boutons à icônes utilisent des tailles d’icônes visuelles de 16×16 ou 20×20 pixels dans une cible de frappe légèrement plus grande. Lorsque la cible de frappe est également inférieure à 24×24, le critère échoue — et les designers de barres d’outils réduisent systématiquement les espaces pour faire tenir davantage d’icônes dans l’espace horizontal disponible.

Définir un token de taille de cible de frappe minimale de 24 par 24 pixels CSS dans le système de design, appliqué via la marge intérieure plutôt que les dimensions propres de l’icône. Lorsque les barres d’outils ne peuvent pas accommoder le plancher, ajouter un espacement suffisant pour que les cibles adjacentes ne se trouvent pas dans l’exclusion de chevauchement du critère. Fournir un équivalent de niveau paramètres (un menu plus grand) pour les surfaces réellement contraintes.

L’étape d’authentification d’un site web ou d’une application ne peut pas reposer sur un test de fonction cognitive — résoudre un puzzle, transcrire une image déformée, reconnaître des objets dans une grille — sauf si une méthode d’authentification alternative est fournie, qu’un mécanisme d’assistance est disponible, ou qu’une exception de reconnaissance d’objets s’applique. Mémoriser un mot de passe est considéré comme un test de fonction cognitive, ce qui explique pourquoi les gestionnaires de mots de passe sont explicitement pris en compte.

La plupart des CAPTCHA basés sur des images échouent d’emblée. De même pour les défis « cliquez sur les cases avec des feux de circulation », les tests de transcription de texte déformé, et tout flux qui colle un code à usage unique dans un champ mais désactive l’interaction de collage. Ce schéma se concentre dans les flux de connexion, de réinitialisation de mot de passe et de création de compte — précisément les points à fort enjeu où un blocage a le coût le plus élevé.

Les flux d’authentification sont également le domaine où la portée du critère est la plus nette, parce que l’échec ne dégrade pas l’expérience — il y met fin.

Remplacer les CAPTCHA à fonction cognitive par une alternative non cognitive — attestation par l’appareil, liens magiques, clés d’accès (passkeys), ou notation de risque invisible. Autoriser le remplissage automatique par les gestionnaires de mots de passe. S’assurer que le copier-coller fonctionne dans les champs de code à usage unique. Lorsqu’un CAPTCHA doit être conservé, proposer une alternative audio qui n’exige pas elle-même la transcription d’un discours déformé.

Lorsqu’un composant d’interface utilisateur reçoit le focus clavier, l’élément focalisé ne doit pas être entièrement masqué par du contenu créé par l’auteur. L’occlusion partielle est autorisée à ce niveau (un en-tête fixe chevauchant la moitié supérieure d’un champ focalisé est permis) ; l’occlusion totale ne l’est pas.

La collision la plus fréquente est un en-tête fixe — parfois une bannière de cookies ou un widget de chat flottant — qui chevauche le champ de formulaire focalisé lorsqu’un utilisateur clavier y accède par tabulation. Les sites en production qui ont superposé un en-tête fixe à un formulaire existant lors de la vague de refonte 2020–2022 ont systématiquement manqué le comportement focus-et-défilement parce que le formulaire d’origine avait été créé avant l’existence des éléments fixes.

Définir scroll-margin-top (ou scroll-padding-top sur le conteneur de défilement) égal à la hauteur de toute superposition fixe. Vérifier que la navigation par tabulation dans un formulaire long fait défiler l’élément focalisé entièrement en dessous de tout en-tête. Associer cela à des styles focus-visible pour que l’utilisateur puisse voir où le focus a atterri.

Toute fonctionnalité utilisant un mouvement de glissement doit également être opérable via une action à pointeur unique — un appui, un clic, ou un équivalent ne nécessitant pas de mouvement de pointeur soutenu. Les interactions de glisser-déposer ne sont pas interdites ; elles ne peuvent simplement pas être le seul chemin disponible vers la fonction.

Les interfaces de réorganisation de listes et de style kanban sont fréquemment livrées avec une réorganisation uniquement par glisser-déposer. De même pour les contrôles de curseur implémentés comme des pouces déplaçables sans entrée numérique ou champ de texte correspondant, et pour les interfaces de recadrage d’image qui nécessitent un glissement pour définir les limites. Le critère les détecte systématiquement.

Pour chaque interaction de glissement, livrer une alternative par appui/clic équivalente — boutons « monter » et « descendre » à côté des éléments de liste déplaçables, une entrée numérique à côté d’un curseur, un mode de clic pour définir les limites dans le recadreur. Lorsque l’alternative est masquée dans un menu contextuel, s’assurer qu’elle est accessible via le clavier.

Dans le cadre d’un même processus authentifié, l’utilisateur ne doit pas être contraint de saisir deux fois la même information — sauf si la re-saisie est essentielle, si l’entrée précédente n’est plus valide, ou si l’information concerne la sécurité (la confirmation d’un mot de passe lors de la création d’un compte est l’exception canonique). Le pré-remplissage ou la sélection à partir de valeurs préalablement saisies satisfait tous deux le critère.

Les flux de paiement multi-étapes, les formulaires de candidature multi-pages et les demandes de visa ou de permis demandent systématiquement la même adresse, le même nom ou les mêmes coordonnées en deux étapes distinctes parce que ces étapes ont été créées par des équipes différentes et n’ont jamais été harmonisées. Les valeurs préalablement saisies par l’utilisateur ne sont pas conservées dans une session partagée entre les étapes.

Conserver les valeurs saisies par l’utilisateur entre les étapes d’un même processus ; préremplir les champs correspondants dans les étapes suivantes ; ou exposer un contrôle « utiliser la même adresse » en un clic. Ce schéma remonte généralement lors de la cartographie des processus plutôt qu’au cours d’un audit front-end, de sorte qu’une revue de flux inter-équipes est l’étape pratique de correction.

Si un mécanisme d’aide est fourni — un lien de contact, un lien d’aide, un widget de chat, un numéro de téléphone d’assistance, un lien d’auto-assistance — il doit apparaître au même emplacement relatif sur les pages où il est proposé. Le critère n’exige pas la présence d’une aide ; seulement que, lorsqu’elle est présente, son emplacement soit cohérent.

Le critère est simple en principe et détecte un ensemble restreint de sites qui ont un lien « Nous contacter » dans l’en-tête sur certaines pages, dans un pied de page sur d’autres, et dans un widget de chat flottant sur un troisième ensemble — résultat fréquent de plusieurs sections de site gérées par des équipes différentes avec des modèles distincts.

Auditer l’emplacement des mécanismes d’aide dans tous les modèles ; choisir un emplacement canonique unique (en-tête, pied de page permanent ou widget flottant) et corriger les exceptions. La correction est rarement technique ; c’est une étape de gouvernance de contenu et de modèles.

La version AAA de 2.4.11 : lorsqu’un composant d’interface utilisateur reçoit le focus clavier, l’élément focalisé ne doit pas du tout être masqué par du contenu créé par l’auteur. L’occlusion partielle est interdite à ce niveau — un en-tête fixe couvrant une partie du champ focalisé constitue un échec.

Les mêmes collisions avec des superpositions fixes qui causent les échecs 2.4.11 persistent à 2.4.12. Les sites qui ont adopté scroll-margin-top pour satisfaire le critère minimum tendent encore à laisser quelques pixels CSS de chevauchement sur des hauteurs de fenêtre particulières. Au niveau AAA, ce chevauchement constitue l’échec.

Régler scroll-margin-top pour dépasser confortablement la hauteur de toute superposition créée par l’auteur, y compris les dynamiques (bannières de cookies apparaissant à la première visite, widgets de chat qui se développent au survol). Ajouter des tests de régression explicites pour le comportement tabulation-dans-formulaire aux tailles de fenêtre courantes.

La version AAA de 3.3.8 : l’authentification ne peut pas reposer sur un test de fonction cognitive, point. Les exceptions pour la reconnaissance d’objets et le contenu personnel qui s’appliquent au niveau AA ne s’appliquent pas ici. Les tests de mémorisation, les tests de transcription et les défis de reconnaissance d’images échouent tous à ce niveau.

Même les sites qui ont remplacé les CAPTCHA traditionnels par des défis de reconnaissance d’objets (l’exception AA) échouent 3.3.9. Le critère est le signal du groupe de travail sur l’orientation que devrait prendre l’authentification : s’éloigner totalement des défis cognitifs, et vers l’attestation par l’appareil ou la vérification biométrique.

Adopter les clés d’accès (WebAuthn) comme mécanisme d’authentification principal ; traiter la combinaison mot de passe + clé d’accès comme un état de transition plutôt que comme une destination. Lorsque la reconnaissance d’images a été conservée pour la notation de risque, l’exécuter côté serveur à partir de signaux comportementaux plutôt que comme un défi visible par l’utilisateur.