WCAG 2.4.13 : Apparence du focus

Ce que signifie cette règle

WCAG 2.4.13 Focus Appearance est un critère de niveau AAA introduit dans WCAG 2.2 qui définit des exigences précises et mesurables pour l’apparence visuelle des indicateurs de focus clavier. Alors que le critère de niveau inférieur 2.4.11 (Focus Not Obscured, niveau AA) garantit que l’élément focalisé n’est pas entièrement masqué, et que 2.4.7 (Focus Visible, niveau AA) exige simplement qu’un indicateur de focus existe, 2.4.13 va plus loin en définissant à quel point cet indicateur doit être visible.

Pour satisfaire ce critère, l’indicateur de focus clavier doit remplir toutes les conditions suivantes :

• Zone minimale : L’indicateur de focus doit avoir une surface au moins égale au périmètre du composant non focalisé multiplié par 2 pixels CSS. En pratique, pour un bouton rectangulaire typique, cela signifie que le contour de focus doit avoir une surface égale ou supérieure au périmètre du bouton multiplié par 2px — un anneau de focus d’au moins 2px d’épaisseur autour de toute la bordure est conforme.
• Ratio de contraste de l’indicateur de focus : Les pixels qui forment l’indicateur de focus doivent avoir un ratio de contraste d’au moins 3:1 entre leurs états focalisé et non focalisé. Ainsi, si un bouton a un arrière-plan blanc dans son état par défaut, l’anneau de focus dessiné autour doit présenter un contraste d’au moins 3:1 par rapport à cet arrière-plan blanc.
• Aucune réduction de contraste pour le contenu inclus : L’indicateur de focus ne doit pas réduire le contraste du texte ou d’un autre contenu à l’intérieur du composant focalisé en dessous de 4.5:1 (pour le texte inférieur à 18pt / 14pt gras) ou 3:1 (pour le texte de grande taille et le contenu non textuel).

Les trois conditions doivent être remplies simultanément pour qu’un composant soit conforme. Un indicateur de focus suffisamment grand mais avec un contraste insuffisant échoue. De même, un indicateur très contrasté mais trop petit échoue également.

La spécification WCAG définit une exception notable : si l’indicateur de focus par défaut du navigateur (le focus par défaut de l’agent utilisateur) répond aux exigences, l’auteur n’a pas besoin d’ajouter un style personnalisé. Cependant, les valeurs par défaut des navigateurs varient considérablement — les navigateurs basés sur Chromium fournissent généralement un contour bleu, tandis que Safari peut afficher un anneau qui manque de contraste suffisant dans certains jeux de couleurs. Les auteurs doivent vérifier que l’indicateur par défaut atteint le seuil requis ou fournir un style personnalisé robuste.

Le critère s’applique à tous les composants interactifs et focalisables : liens, boutons, champs de formulaire, menus select, cases à cocher, boutons radio, composants de widgets personnalisés construits avec des rôles ARIA, et tout élément rendu focalisable via tabindex. Il s’applique également aux indicateurs de focus créés uniquement via CSS sur des pseudo-éléments ou via des changements de classes contrôlés par JavaScript.

Pourquoi c’est important

La visibilité du focus est un repère de navigation essentiel pour un large éventail d’utilisateurs. Lorsque les indicateurs de focus sont fins, peu contrastés ou totalement absents, ces utilisateurs perdent leur orientation spatiale dans une page — ils ne peuvent pas savoir où ils se trouvent ni où ils peuvent aller ensuite.

Les utilisateurs uniquement clavier — y compris les personnes ayant des limitations motrices telles que des tremblements, une paralysie ou des troubles musculo-squelettiques — dépendent entièrement du clavier pour naviguer. Pour ces personnes, un indicateur de focus invisible ou à peine visible n’est pas seulement une gêne ; il rend toute l’interface inutilisable. Selon l’Organisation mondiale de la Santé, environ 1,3 milliard de personnes vivent avec une forme de handicap, et les limitations motrices représentent l’une des plus grandes catégories parmi les personnes qui évitent ou ne peuvent pas utiliser une souris.

Les utilisateurs malvoyants qui utilisent un logiciel de grossissement mais pas un lecteur d’écran complet dépendent également de l’anneau de focus pour s’orienter. À des niveaux de zoom élevés, un contour par défaut de 1px peut être rogné par la fenêtre d’affichage ou simplement invisible sur un arrière-plan de couleur similaire. Ces utilisateurs naviguent souvent au clavier précisément parce que le ciblage précis à la souris est difficile à forte magnification.

Les handicaps cognitifs et liés à l’attention tels que le TDAH, les troubles anxieux et les traumatismes crâniens peuvent rendre difficile le suivi des informations visuelles sur une page. Un indicateur de focus très visible et clairement différencié réduit la charge cognitive de la navigation en fournissant un repère indiscutable de la position actuelle de l’utilisateur.

Les handicaps situationnels comptent aussi : un développeur testant sur un ordinateur portable à faible luminosité en extérieur, ou une personne âgée avec une sensibilité au contraste diminuée liée à l’âge, peuvent avoir du mal avec des anneaux de focus fins ou peu contrastés même sans diagnostic clinique.

Considérons un scénario réel : le formulaire en ligne d’une banque pour transférer des fonds contient dix champs de saisie et quatre boutons d’action. Une personne atteinte de la maladie de Parkinson parcourt le formulaire au clavier. Si l’indicateur de focus est un contour pointillé par défaut de 1px en gris clair sur fond blanc, cette personne ne peut pas suivre de manière fiable le champ qu’elle est en train de modifier. Elle peut soumettre par erreur un virement vers le mauvais compte parce qu’elle n’a pas vu que le focus avait dépassé le champ du bénéficiaire. Un contour de focus robuste et à fort contraste aurait entièrement évité ce problème.

Au-delà de l’accessibilité, un indicateur de focus clair est une amélioration d’ergonomie pour tous les utilisateurs. Les utilisateurs avancés qui naviguent fréquemment dans des formulaires et des menus au clavier — un schéma courant chez les développeurs, les professionnels de la saisie de données et les utilisateurs de lecteurs d’écran — bénéficient d’une orientation rapide et fiable. Il existe également un signal SEO indirect : les sites fortement accessibles ont tendance à avoir des taux de rebond plus faibles et une meilleure réussite des tâches, deux facteurs corrélés à des signaux de classement positifs.

Règles axe-core associées

WCAG 2.4.13 nécessite des tests manuels car les outils automatisés ne peuvent pas évaluer pleinement la taille et le contraste d’un indicateur de focus dans tous les contextes possibles de rendu du navigateur. Axe-core n’a pas de règle automatisée unique qui signale directement les échecs de 2.4.13. Les raisons sont techniques :

• Pourquoi l’automatisation est insuffisante : Calculer la surface exacte en pixels d’un indicateur de focus nécessite de simuler le focus clavier sur chaque élément interactif, de mesurer la géométrie du contour rendu (qui dépend du navigateur, du système d’exploitation, du niveau de zoom et du CSS), de calculer le ratio de contraste des pixels de l’indicateur par rapport à leurs voisins, et de vérifier qu’aucun de ces éléments ne viole l’exigence de contraste pour le contenu inclus. Aucun moteur d’accessibilité automatisé actuel n’exécute de manière fiable toutes ces étapes sur tous les composants. Axe-core peut signaler l’absence de tout style de focus (lié à 2.4.7) mais ne peut pas mesurer si le style qui est présent respecte les seuils de surface et de contraste de 2.4.13.
• Couverture partielle via des règles liées au focus : La règle focus-visible d’axe-core vérifie si les éléments ont un indicateur de focus visible. Si un élément a outline: none ou outline: 0 sans indicateur visuel alternatif, cette règle le signalera. Cependant, le fait de passer cette règle ne garantit pas la conformité à 2.4.13 — un élément peut avoir un contour techniquement visible qui reste trop fin ou trop peu contrasté.
• Les tests manuels sont la méthode de référence : Les testeurs doivent inspecter visuellement chaque composant interactif à l’état focalisé, mesurer ou estimer les dimensions du contour et vérifier les ratios de contraste à l’aide d’un analyseur de contraste de couleurs. C’est pourquoi WCAG répertorie 2.4.13 comme un critère nécessitant uniquement des tests manuels pour les besoins d’axe-core.

Comment tester

1. Analyse automatisée (signal partiel uniquement) : Exécutez axe DevTools ou Lighthouse sur la page. Recherchez les échecs liés à focus-visible ou focus-order-semantics. Bien qu’ils ne signalent pas directement les violations de 2.4.13, ils peuvent faire apparaître des éléments dont le style de focus a été entièrement supprimé, ce qui constitue un échec préalable. Dans Chrome DevTools, ouvrez le panneau Accessibility et utilisez le mode d’inspection « Tab » pour parcourir les éléments focalisables.
2. Test visuel de navigation au clavier : Débranchez ou mettez de côté votre souris. Appuyez sur Tab pour parcourir chaque élément interactif de la page. Pour chaque élément focalisé, inspectez visuellement l’indicateur de focus. Demandez-vous : y a-t-il un anneau ou un autre indicateur clairement visible ? Semble-t-il avoir au moins 2px d’épaisseur ? Contraste-t-il fortement avec l’arrière-plan environnant ? Notez tout élément pour lequel vous hésitez ou avez du mal à voir où se trouve le focus.
3. Mesure du contraste : Utilisez le WebAIM Contrast Checker ou l’outil de bureau Colour Contrast Analyser. Avec le focus sur un composant, faites une capture d’écran. Échantillonnez la couleur des pixels de l’indicateur de focus et la couleur de l’arrière-plan immédiatement adjacent. Vérifiez que le ratio de contraste est d’au moins 3:1.
4. Mesure des dimensions : Utilisez les DevTools du navigateur (Chrome ou Firefox). Sélectionnez un élément focalisé et inspectez ses styles calculés. Vérifiez outline-width, outline-offset et tout box-shadow utilisé comme anneau de focus. Multipliez le périmètre de l’élément (2 × largeur + 2 × hauteur) par 2px pour calculer la surface minimale. Vérifiez que la surface rendue de l’indicateur atteint ou dépasse cette valeur.
5. Test lecteur d’écran + clavier (NVDA + Firefox) : Ouvrez la page dans Firefox avec NVDA en cours d’exécution. Naviguez à l’aide de Tab et des flèches. Confirmez que l’indicateur de focus visuel se déplace en synchronisation avec le focus annoncé par NVDA. Portez une attention particulière aux widgets personnalisés (carrousels, modales, accordéons) où la gestion du focus peut être assurée via JavaScript.
6. VoiceOver + Safari (macOS/iOS) : Activez VoiceOver avec Command + F5. Utilisez Tab pour naviguer entre les éléments interactifs. Vérifiez que le curseur VoiceOver (le cadre noir) ne se substitue pas à un véritable indicateur de focus CSS — la page elle-même doit en fournir un indépendamment.
7. Test en mode contraste élevé : Sous Windows, activez le mode High Contrast (Paramètres → Options d’ergonomie → Contraste élevé). Rechargez la page et répétez le test de navigation au clavier. Certains styles CSS de focus sont remplacés par le système d’exploitation en mode contraste élevé ; vérifiez qu’un indicateur visible apparaît toujours. Utilisez la requête média CSS forced-colors: active pour ajuster conditionnellement les styles si nécessaire.

Comment corriger

Contour par défaut du navigateur supprimé — Incorrect

<!-- Many stylesheets globally suppress the default focus outline -->
<style>
  * {
    outline: none; /* Removes ALL focus indicators site-wide */
  }
  a:focus, button:focus {
    outline: 0; /* Redundant removal; no replacement provided */
  }
</style>
<button>Submit Payment</button>

Contour par défaut du navigateur supprimé — Correct

<!-- Remove the default only when providing a superior custom indicator -->
<style>
  /* Only suppress default outline when :focus-visible applies, then provide a strong replacement */
  :focus-visible {
    outline: 3px solid #0057b8; /* 3px ensures area requirement is met for typical elements */
    outline-offset: 2px;       /* Offset separates indicator from element edge for clarity */
  }
  /* Respect forced-colors (Windows High Contrast) by using system keywords */
  @media (forced-colors: active) {
    :focus-visible {
      outline: 3px solid ButtonText;
    }
  }
</style>
<button>Submit Payment</button>

Anneau de focus à faible contraste sur fond coloré — Incorrect

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus {
    outline: 2px solid #3399ff; /* Light blue outline on dark blue background: contrast ratio ~1.4:1 — fails */
  }
</style>
<button class='cta-button'>Book Now</button>

Anneau de focus à faible contraste sur fond coloré — Correct

<style>
  .cta-button {
    background-color: #0057b8;
    color: #ffffff;
  }
  .cta-button:focus-visible {
    /* White outline contrasts strongly against the dark blue button (contrast ~8:1) */
    outline: 3px solid #ffffff;
    outline-offset: 2px;
    /* A dark offset box-shadow behind the white ring ensures contrast against light page backgrounds */
    box-shadow: 0 0 0 5px #0057b8;
  }
</style>
<button class='cta-button'>Book Now</button>

Widget interactif personnalisé basé sur un div sans style de focus — Incorrect

<style>
  .tab-item { cursor: pointer; padding: 12px 20px; }
  /* No :focus or :focus-visible style defined for custom tab */
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Widget interactif personnalisé basé sur un div sans style de focus — Correct

<style>
  .tab-item {
    cursor: pointer;
    padding: 12px 20px;
    border-radius: 4px;
  }
  /* Explicit :focus-visible style — outline-width 3px with offset meets area threshold */
  .tab-item:focus-visible {
    outline: 3px solid #d4550a; /* 3:1+ contrast against white background */
    outline-offset: 3px;
  }
</style>
<div role='tab' tabindex='0' class='tab-item'>Reservations</div>

Box-shadow fin utilisé comme indicateur de focus — Incorrect

<style>
  .form-input:focus {
    outline: none;
    /* 1px box-shadow spread: likely too small in area for most input sizes */
    box-shadow: 0 0 0 1px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Box-shadow fin utilisé comme indicateur de focus — Correct

<style>
  .form-input:focus-visible {
    outline: none;
    /*
      3px spread provides sufficient area around a typical 300px-wide input.
      #005fcc on white background yields ~5.9:1 contrast — passes both 2.4.13 (3:1) and 1.4.3 (4.5:1).
    */
    box-shadow: 0 0 0 3px #005fcc;
  }
</style>
<input type='text' class='form-input' placeholder='Your email' />

Erreurs courantes

• Utiliser outline: none dans un reset CSS sans fournir de remplacement pour l’indicateur de focus. De nombreux resets CSS populaires (anciennes versions de Normalize.css, resets personnalisés) suppriment les contours de manière globale. Associez toujours cette suppression à un remplacement :focus-visible qui respecte les exigences de taille et de contraste.
• Fournir un style de focus uniquement pour :focus mais pas pour :focus-visible, ce qui provoque l’affichage d’anneaux de focus lors des clics souris sur les boutons et agace les utilisateurs voyants à la souris — ce qui conduit les développeurs à les supprimer complètement plutôt qu’à utiliser la bonne séparation via le pseudo-classe.
• Choisir une couleur d’anneau de focus très proche de la couleur d’arrière-plan du composant. Par exemple, un anneau bleu clair #99ccff sur un arrière-plan blanc #ffffff a un ratio de contraste d’environ 1.5:1, bien en dessous du 3:1 requis.
• Utiliser outline-width: 1px sur de petits composants tels que des boutons icône ou des cases à cocher. Un anneau de 1px autour d’une icône de 24×24px a une surface d’environ 96 pixels carrés, mais la surface minimale requise pour un élément de 24×24 est (24+24+24+24) × 2 = 192 pixels carrés — soit exactement 2px d’épaisseur. Un contour de 1px échoue à ce calcul.
• Oublier de tester l’apparence du focus sur les widgets ARIA personnalisés tels que role='combobox', role='listbox' ou role='slider'. Ces composants ont souvent un focus géré par JavaScript qui contourne les pseudo-classes CSS natives sauf si elles sont gérées explicitement.
• Appliquer un style de focus uniquement aux balises a et button tout en négligeant input, select, textarea et tout élément avec tabindex='0'.
• Remplacer les styles de focus en profondeur dans une bibliothèque de composants ou un widget tiers sans se rendre compte que ce remplacement supprime l’indicateur visible. Les coupables fréquents incluent des kits UI comme Bootstrap 4 (qui définissent un box-shadow en lueur subtile) qui peuvent ne pas respecter le seuil de 2.4.13.
• Ne pas tester l’apparence du focus en mode contraste élevé sous Windows. Certaines techniques CSS basées sur outline et box-shadow deviennent invisibles en mode contraste élevé. Utilisez le bloc @media (forced-colors: active) pour garantir un repli visible basé sur les couleurs système.
• Utiliser outline-offset avec une valeur négative très élevée pour déplacer le contour à l’intérieur de la bordure de l’élément. Cela peut amener l’indicateur à se superposer à l’arrière-plan de l’élément, réduisant le contraste effectif en dessous de 3:1.
• Supposer que l’indicateur de focus sur un conteneur parent est suffisant pour les éléments interactifs enfants. Chaque élément focalisable doit respecter indépendamment le critère ; une ligne surlignée dans un tableau ne satisfait pas l’exigence pour un lien dans une cellule de cette ligne.

Lien avec la réglementation d’accessibilité en Turquie

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences contraignantes en matière d’accessibilité web et mobile pour un large ensemble d’entités opérant en Turquie. La circulaire adopte WCAG 2.2 comme norme de référence technique et impose la conformité au niveau AA pour les entités concernées. WCAG 2.4.13 Focus Appearance est un critère de niveau AAA et n’est donc pas directement imposé par la circulaire pour la conformité standard.

Cependant, le champ d’application de la circulaire est très large. Les entités concernées incluent les institutions publiques et les agences gouvernementales, les banques et prestataires de services financiers, les hôpitaux et organisations de santé, les opérateurs de télécommunications comptant 200,000 abonnés ou plus, les plateformes de e-commerce, les agences de voyage, les entreprises de transport privé et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE). Pour toutes ces organisations, démontrer une conformité de niveau AAA sur les critères applicables — y compris 2.4.13 — témoigne d’un engagement envers une accessibilité de premier plan qui dépasse le seuil légal.

Il existe des raisons pratiques et d’image pour que les entités turques concernées mettent en œuvre volontairement 2.4.13. Les banques et prestataires de services financiers, en particulier, servent des clients ayant des limitations motrices qui dépendent de la navigation au clavier pour des transactions sécurisées. Le portail de banque en ligne d’une banque turque qui respecte 2.4.13 dépasse non seulement les exigences réglementaires, mais réduit aussi le risque d’erreur utilisateur et démontre une responsabilité sociale d’entreprise. De même, les hôpitaux et portails de santé où les patients prennent des rendez-vous ou accèdent à leurs dossiers médicaux devraient veiller à ce que tous les utilisateurs — y compris les personnes âgées avec une motricité fine réduite ou une basse vision — puissent naviguer dans ces interfaces en toute confiance.

Les opérateurs de télécommunications ayant une large base d’abonnés comptent parmi les services numériques les plus fréquentés en Turquie. Leurs portails clients et applications en libre-service touchent des millions d’utilisateurs, y compris une proportion significative de personnes âgées et de personnes handicapées. La mise en œuvre volontaire de 2.4.13 sur l’ensemble de ces plateformes garantit un accès équitable pour tous les abonnés et positionne favorablement l’opérateur en cas de durcissement réglementaire futur qui étendrait l’obligation de conformité aux critères AAA.

Pour les organisations cherchant à atteindre une conformité complète WCAG 2.2 AAA — que ce soit en raison d’exigences d’achat public, d’exportation vers des marchés de l’UE soumis à l’European Accessibility Act, ou de politiques internes d’accessibilité — la mise en œuvre de 2.4.13 est un élément nécessaire. Le SDK d’overlay d’Accsible fournit des fonctionnalités configurables d’amélioration du focus qui peuvent aider les organisations à faire apparaître des indicateurs de focus robustes et conformes sur l’ensemble de leurs interfaces, en complément des correctifs CSS au niveau auteur décrits dans cet article.