WCAG 3.2.1 : Au focus

Ce que signifie cette règle

Le critère de succès 3.2.1 de WCAG, Au focus (Niveau A), stipule : « Si un composant reçoit le focus, il ne provoque pas de changement de contexte. » En termes simples, le fait de déplacer le focus vers un élément interactif — en appuyant sur Tab, Shift+Tab, les touches fléchées ou tout autre mécanisme clavier — ne doit pas, à lui seul, provoquer quelque chose de spectaculaire et d’inattendu sur la page.

Un changement de contexte est défini par WCAG comme une modification majeure du contenu de la page qui, si elle est effectuée sans que l’utilisateur en ait conscience, pourrait le désorienter. La spécification identifie quatre types concrets de changement de contexte : les changements de l’agent utilisateur (comme l’ouverture d’une nouvelle fenêtre ou d’un nouvel onglet du navigateur), les changements de la fenêtre d’affichage (comme un défilement automatique vers une partie éloignée de la page), les changements de focus lui-même (comme le déplacement automatique du focus vers un autre endroit) et les changements de contenu qui modifient de manière significative la signification de la page (comme l’envoi d’un formulaire ou le chargement d’une vue complètement différente).

La distinction clé que fait ce critère est entre le fait de recevoir le focus et celui d’activer un contrôle. Arriver sur un bouton par tabulation et, ce faisant, provoquer l’envoi d’un formulaire constitue une violation. En revanche, appuyer sur Entrée ou Espace lorsque ce bouton a le focus — une activation intentionnelle et délibérée — est parfaitement acceptable et même attendu. L’intention de l’utilisateur est ce qui sépare une interaction prévisible d’une interaction désorientante.

Les schémas courants qui enfreignent ce critère incluent :

• Une liste déroulante <select> qui navigue automatiquement vers une nouvelle URL dès qu’une option reçoit le focus (et non lorsque l’utilisateur confirme son choix).
• Un sélecteur de date qui ouvre une boîte de dialogue modale au moment où l’un de ses champs de saisie reçoit le focus, sans aucune activation de la part de l’utilisateur.
• Un carrousel ou diaporama qui passe automatiquement à la diapositive suivante lorsque ses points de navigation reçoivent le focus.
• Une info-bulle ou un popover qui, lorsqu’il est déclenché par le focus, déplace simultanément le focus clavier sur lui-même sans avertissement, laissant l’utilisateur bloqué à un endroit inattendu.
• Un champ de recherche qui envoie immédiatement le formulaire et recharge la page lorsqu’il reçoit le focus.

Les schémas qui ne constituent explicitement pas des violations incluent : une info-bulle ou un panneau de description qui apparaît visuellement mais ne déplace pas le focus et ne modifie pas le contenu principal de la page ; un indicateur de focus (comme un contour ou un anneau) qui apparaît autour de l’élément focalisé ; ou un élément qui se déploie pour afficher du contenu supplémentaire en ligne, tant que le focus reste là où l’utilisateur l’a placé.

Il n’existe aucune exception officielle définie dans WCAG 3.2.1. Le critère s’applique universellement à tous les composants d’interface utilisateur d’une page. Cependant, le document d’interprétation de WCAG précise que les changements de contexte déclenchés par une activation délibérée de l’utilisateur (clic, Entrée, Espace) ne relèvent pas du champ de ce critère, qui ne concerne que l’acte passif de recevoir le focus.

Pourquoi c’est important

Le critère Au focus s’inscrit dans le Principe 3 — Compréhensible — car la prévisibilité est un prérequis fondamental de l’utilisabilité. Lorsque la page se comporte de manière inattendue en réponse au seul focus, les conséquences vont d’une légère confusion à une perte totale d’accès, selon les besoins et les outils de l’utilisateur.

Les utilisateurs uniquement clavier (personnes qui ne peuvent pas utiliser une souris en raison de déficiences motrices, de troubles musculo-squelettiques ou de paralysie) s’appuient exclusivement sur la navigation au clavier. Lorsque le fait d’atteindre un champ de formulaire par tabulation déclenche un rechargement de la page, ils peuvent perdre toutes les données déjà saisies et se retrouver redirigés loin de leur objectif. Se remettre d’une telle interruption peut prendre beaucoup de temps et d’efforts — ou ils peuvent tout simplement abandonner.

Les utilisateurs de lecteurs d’écran (qui sont souvent aussi des utilisateurs uniquement clavier) font face à une couche supplémentaire de désorientation. Les lecteurs d’écran annoncent à l’utilisateur l’élément actuellement focalisé. Si le focus se déplace de manière inattendue vers un nouvel élément — par exemple, une modale qui s’ouvre automatiquement — le lecteur d’écran annonce le nouveau contexte sans donner à l’utilisateur aucun repère sur ce qui vient de se passer ni pourquoi. C’est analogue au fait d’être physiquement soulevé et déplacé dans une autre pièce sans avertissement.

Les utilisateurs ayant des troubles cognitifs, y compris ceux ayant un TDAH, des troubles anxieux ou des troubles de la mémoire, dépendent d’interfaces prévisibles pour construire et maintenir un modèle mental de la page. Des changements de contexte soudains et inexpliqués brisent ce modèle, créant confusion, anxiété et erreurs. Une étude du projet WebAIM Million constate de manière récurrente que les composants interactifs complexes aux comportements inattendus figurent parmi les principales sources de plaintes en matière d’accessibilité de la part des utilisateurs ayant des troubles cognitifs.

Les utilisateurs malvoyants qui utilisent des logiciels de grossissement d’écran (comme ZoomText ou Windows Magnifier) ne voient qu’une petite portion de l’écran à la fois. Si le focus provoque un défilement ou une navigation automatiques, le contenu pertinent peut sortir complètement de leur fenêtre agrandie, les laissant face à une zone vide ou sans rapport de l’écran.

Considérons un scénario concret du monde réel : le formulaire de virement en ligne d’une banque turque contient une liste déroulante pour sélectionner la banque destinataire. Le développeur a implémenté un événement de type onchange sur l’élément <select> qui se déclenche non pas à la confirmation, mais dès qu’une option reçoit le focus via les flèches. Un utilisateur de lecteur d’écran qui arrive dans le champ par tabulation et appuie sur la flèche Bas pour explorer les banques disponibles déclenche immédiatement l’envoi du formulaire ou le rechargement de la page. Il ne termine jamais le virement et ne peut pas déterminer ce qui s’est mal passé. Ce scénario n’est pas hypothétique — c’était un schéma documenté dans de nombreuses premières applications monopage.

Au-delà de l’accessibilité, il existe des bénéfices tangibles en termes d’utilisabilité et de performance commerciale. Les formulaires qui ne détournent pas le focus ont des taux d’abandon plus faibles. Les pages qui se comportent de manière prévisible obtiennent de meilleurs résultats lors des tests d’utilisabilité auprès de tous les publics. Les robots d’indexation des moteurs de recherche bénéficient également de flux de navigation prévisibles, car des redirections inattendues déclenchées par des événements de focus peuvent perturber la logique d’exploration dans certains scénarios de rendu dynamique.

Règles Axe-core associées

WCAG 3.2.1 Au focus nécessite des tests manuels, car les outils automatisés ne peuvent pas déterminer de manière fiable l’intention de l’utilisateur ni prévoir tous les changements de contexte possibles. Axe-core et des analyseurs automatisés similaires peuvent analyser le HTML statique et les attributs ARIA, mais ils ne peuvent pas observer le comportement JavaScript à l’exécution en réponse aux événements de focus — en particulier pour déterminer si ce comportement constitue un changement de contexte « majeur » tel que défini par WCAG. Un script qui déplace le focus, envoie un formulaire ou navigue vers une URL sur l’événement focus est invisible pour un analyseur statique, à moins que l’outil ne simule effectivement les interactions de focus sur chaque élément interactif, puis n’analyse ce qui a changé dans le DOM, la fenêtre d’affichage et l’URL après coup. Ce niveau de simulation comportementale n’est pas réalisable de manière fiable dans un passage automatisé sans un taux de faux positifs prohibitif.

• Test manuel requis — Changement de contexte au focus : Les testeurs doivent parcourir manuellement par tabulation chaque élément interactif de la page (liens, boutons, champs de saisie, listes déroulantes, widgets personnalisés) et observer si le seul focus — sans aucune activation — déclenche un changement de contexte tel que défini par WCAG. Cela inclut la surveillance des changements d’URL, de l’ouverture de nouvelles fenêtres ou de nouveaux onglets, du déplacement du focus hors de l’élément sur lequel on vient d’arriver, de l’envoi de formulaires et des remplacements majeurs de contenu. Les outils automatisés signalent les écouteurs d’événements JavaScript attachés aux événements liés au focus (focus, focusin, onfocus) comme candidats à un examen manuel, mais ne peuvent pas déterminer si ces gestionnaires provoquent un changement de contexte disqualifiant.

Comment tester

1. Pré-analyse automatisée : Exécutez axe DevTools (extension de navigateur ou CLI) ou Google Lighthouse sur la page. Bien qu’aucun de ces outils ne puisse signaler de manière définitive les violations du critère Au focus, axe DevTools peut faire remonter des problèmes liés à la gestion du focus (comme les schémas scrollable-region-focusable ou de piège de focus) qui méritent une inspection manuelle plus approfondie. Utilisez le panneau « Needs Review » d’axe DevTools — les éléments qui y sont signalés sont souvent liés à des comportements de composants interactifs nécessitant un jugement humain.
2. Identifier tous les éléments interactifs : Avant les tests au clavier, dressez la liste de tous les composants interactifs : liens, boutons, champs de formulaire, listes déroulantes, cases à cocher, boutons radio, sélecteurs de date, carrousels, accordéons, onglets, modales et tout widget personnalisé utilisant tabindex. Portez une attention particulière aux widgets JavaScript personnalisés qui écoutent les événements focus ou focusin.
3. Test de navigation uniquement au clavier : En utilisant uniquement le clavier (sans souris), appuyez sur Tab de manière séquentielle pour parcourir chaque élément focalisable de la page. Après chaque pression sur Tab, avant d’appuyer sur quoi que ce soit d’autre, observez : L’URL a-t-elle changé ? Une nouvelle fenêtre ou un nouvel onglet se sont-ils ouverts ? Le focus s’est-il déplacé hors de l’élément sur lequel vous venez d’arriver ? Un formulaire a-t-il été envoyé ? Le contenu principal de la page a-t-il changé de manière spectaculaire ? Toute réponse « oui » constitue un candidat à la violation.
4. Test des éléments select : Donnez le focus à toute liste déroulante <select>. Utilisez les flèches Haut et Bas pour parcourir les options sans appuyer sur Entrée ou Espace. Vérifiez que la navigation dans les options ne déclenche aucune navigation, aucun envoi de formulaire ni aucun changement de contexte. C’est l’un des schémas les plus fréquemment violés.
5. NVDA + Firefox : Activez NVDA (gratuit, Windows). Ouvrez Firefox et accédez à la page. Appuyez sur Tab pour parcourir tous les éléments interactifs. Écoutez les annonces de NVDA — si NVDA commence à annoncer une partie complètement différente de la page ou un nouveau contexte de page après une pression sur Tab (sans que vous ayez appuyé sur Entrée ou Espace), c’est un signal fort de violation.
6. JAWS + Chrome : Activez JAWS. Ouvrez Chrome. Utilisez Tab pour naviguer. JAWS annoncera chaque élément focalisé. Surveillez les annonces inattendues de nouvelles boîtes de dialogue, de nouvelles pages ou de nouvelles positions de focus vers lesquelles vous n’avez pas navigué délibérément.
7. VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Cmd+F5 sur macOS). Naviguez avec Tab (ou par balayage sur iOS). Surveillez les changements de contexte inattendus. Sur iOS, testez également avec l’accès par commutateur pour simuler les utilisateurs ayant des déficiences motrices sévères qui naviguent par balayage séquentiel.
8. Inspection des écouteurs d’événements dans les DevTools du navigateur : Dans Chrome DevTools, sélectionnez tout élément interactif suspect, allez dans le panneau Elements et cliquez sur « Event Listeners ». Recherchez des écouteurs focus ou focusin. Le cas échéant, examinez le JavaScript associé pour déterminer si le gestionnaire déclenche une navigation, un envoi de formulaire, un déplacement du focus ou d’autres actions modifiant le contexte.

Comment corriger

Liste déroulante qui envoie automatiquement le formulaire — Incorrect

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Liste déroulante qui envoie automatiquement le formulaire — Correct

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Ouverture d’une modale au focus sur un champ de saisie — Incorrect

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Ouverture d’une modale au focus sur un champ de saisie — Correct

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Carrousel qui avance automatiquement au focus — Incorrect

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Carrousel qui avance automatiquement au focus — Correct

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Erreurs courantes

• Utiliser onfocus comme substitut de onclick sur des éléments de navigation : Les développeurs attachent parfois des gestionnaires onfocus à des liens ou boutons de navigation pour « précharger » une destination, déclenchant accidentellement une navigation complète au lieu d’un simple préchargement. Utilisez toujours onclick ou onkeydown (en vérifiant Entrée/Espace) pour toute action qui change le contexte.
• Lier onchange sur des éléments <select> sans action de soumission : Dans les navigateurs de bureau, onchange sur un <select> se déclenche lorsqu’une option est confirmée, mais dans certaines anciennes implémentations et certains navigateurs mobiles, il peut se déclencher lorsque les flèches parcourent les options. Associez toujours la navigation pilotée par un select à un bouton de soumission explicite ou utilisez un <form> avec un <button type='submit'>.
• Déplacer le focus par programmation à l’intérieur d’un gestionnaire d’événement focus : Appeler element.focus() à l’intérieur du gestionnaire onfocus ou focusin d’un autre élément crée un saut de focus inattendu. C’est une violation directe — l’utilisateur a tabulé vers l’élément A et le focus s’est déplacé silencieusement vers l’élément B. Ne déplacez le focus qu’en réponse à des actions délibérées de l’utilisateur.
• Ouvrir des boîtes de dialogue modales sur des événements de focus de tout élément déclencheur : Un raccourci courant consiste à attacher un gestionnaire d’ouverture de modale à l’événement focus d’un bouton ou d’un champ de saisie déclencheur. Les modales ne doivent s’ouvrir qu’en réponse à un clic, à la touche Entrée ou à la barre d’espace — jamais sur le seul focus.
• Lancer automatiquement des médias ou des animations qui modifient le contexte de la fenêtre d’affichage au focus : Une bannière principale qui lance une vidéo plein écran ou une grande animation au moment où son bouton de lecture reçoit le focus modifie significativement le contexte visuel. Associez les actions de lecture à des événements d’activation, pas à des événements de focus.
• Déclencher des mises à jour de régions dynamiques qui font défiler la page vers un nouveau contenu au focus : Certains widgets dynamiques mettent à jour une région dynamique (live region) puis font défiler la fenêtre d’affichage vers cette région dès qu’un champ reçoit le focus. Cela modifie le contexte de la fenêtre d’affichage et désoriente les utilisateurs de logiciels de grossissement d’écran. Décorrélez autant que possible les mises à jour de régions dynamiques des événements de focus.
• Implémenter des pièges de focus personnalisés qui piègent immédiatement les utilisateurs sans les en informer : Un composant personnalisé qui intercepte toutes les pressions sur Tab dès qu’il reçoit le focus, sans annoncer à l’utilisateur qu’il se trouve dans un piège de focus, viole à la fois la lettre et l’esprit de ce critère. Les pièges de focus ne sont appropriés que dans des boîtes de dialogue modales pleinement ouvertes, et les utilisateurs doivent être informés de la manière d’en sortir.
• Utiliser le sélecteur CSS :focus pour déclencher display: block sur des menus déroulants contenant des éléments focalisables, provoquant des déplacements de focus en cascade inattendus : Les menus pilotés uniquement par le focus en CSS, qui révèlent des éléments focalisables, peuvent provoquer des sauts déroutants lorsque l’ordre de focus du navigateur se déplace ensuite dans les nouveaux éléments visibles. Assurez-vous que les menus révélés sont attendus et clairement communiqués via des attributs ARIA comme aria-expanded.
• Se fier à des bibliothèques de widgets tierces sans auditer leur comportement de focus : De nombreuses bibliothèques de composants d’interface (sélecteurs de date, éditeurs de texte enrichi, listes déroulantes de type select2) ont historiquement enfreint le critère 3.2.1 en ouvrant des popups ou en déplaçant le focus sur des événements focus. Auditez toujours manuellement les composants tiers avant leur déploiement, quels que soient les engagements d’accessibilité de la bibliothèque.
• Oublier de tester dans des contextes de routage d’applications monopage (SPA) : Dans les SPA React, Vue et Angular, les événements de focus sur les liens de navigation peuvent parfois déclencher des changements de route via la logique de préchargement du routeur ou la propagation des événements, en particulier lorsque les événements de focus ne sont pas correctement empêchés de se propager. Testez explicitement les composants de navigation des SPA pour vérifier leur conformité au critère 3.2.1.

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

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences obligatoires en matière d’accessibilité du web qui font explicitement référence à WCAG 2.2 comme norme technique. WCAG 3.2.1 Au focus est un critère de niveau A, ce qui signifie qu’il se situe au niveau de base de la conformité obligatoire en vertu de la circulaire. Il n’existe aucune exemption pour les critères de niveau A — toutes les entités concernées doivent les respecter dans les délais définis.

Les institutions publiques sont tenues d’atteindre une conformité totale dans un délai de un an à compter de la date de publication de la circulaire. Les entités du secteur privé entrant dans le champ d’application disposent de deux ans. Les entités couvertes par la circulaire présidentielle 2025/10 incluent un large éventail d’organisations : toutes les institutions et agences publiques, les plateformes de commerce électronique et les places de marché en ligne, les banques et institutions financières, les hôpitaux et prestataires de soins de santé privés, les entreprises de télécommunications comptant 200 000 abonnés ou plus, les agences de voyage et plateformes de réservation, les entreprises de transport privées, ainsi que les écoles et établissements d’enseignement privés autorisés par le ministère de l’Éducation nationale (MoNE).

La pertinence de WCAG 3.2.1 Au focus pour ces types d’entités est directe et pratique. Considérez une plateforme de commerce électronique où une liste déroulante de catégories de produits déclenche une navigation automatique au focus — un client utilisant le clavier en raison d’une déficience motrice ne peut pas parcourir les catégories de produits et abandonnera l’achat. Un formulaire de virement en ligne d’une banque avec des envois déclenchés par le focus pourrait provoquer des transactions financières involontaires ou des tentatives répétées infructueuses pour les utilisateurs de lecteurs d’écran. Un système de prise de rendez-vous hospitalier où les champs de date ouvrent des modales au focus peut empêcher des patients en situation de handicap de planifier leurs soins de manière autonome.

En vertu de la circulaire, le non-respect expose les entités concernées à des sanctions administratives et à un risque réputationnel. Pour les entités actuellement engagées dans une transformation numérique ou dans l’acquisition de nouveaux systèmes web, intégrer dès maintenant la conformité à WCAG 3.2.1 dans les exigences de passation de marchés et les guides de développement — plutôt que de procéder à des correctifs après une plainte — est à la fois plus rentable et plus conforme à l’esprit de la réglementation. Les organisations utilisant le SDK de surcouche Accsible bénéficient d’outils de gestion du focus intégrés qui aident à identifier et à corriger les comportements inattendus liés au focus dans le cadre d’un flux de travail plus large de conformité au niveau A de WCAG 2.2.