WCAG 2.4.3 : Ordre de focus

Ce que signifie cette règle

WCAG 2.4.3 Ordre de focus est un critère de succès de niveau A relevant du principe « Utilisable ». Il stipule : « Si une page Web peut être parcourue séquentiellement et que les séquences de navigation ont une incidence sur la signification ou le fonctionnement, les composants focalisables reçoivent le focus dans un ordre qui préserve la signification et l’opérabilité. »

En pratique, cela signifie que lorsque l’utilisateur appuie sur la touche Tab pour se déplacer entre les éléments interactifs d’une page — liens, boutons, champs de formulaire, widgets personnalisés et tout autre composant focalisable — la séquence dans laquelle ces éléments reçoivent le focus doit avoir un sens logique. Les utilisateurs ne doivent pas se retrouver à passer de manière inattendue du milieu d’un formulaire à un lien de pied de page, puis à un bouton de fenêtre modale, puis à un élément du menu de navigation.

Ce critère s’applique à la navigation séquentielle au clavier, qui est le principal moyen pour les utilisateurs n’utilisant que le clavier et les utilisateurs de lecteurs d’écran de parcourir une page. L’ordre du DOM est la source par défaut de l’ordre de focus dans les navigateurs : les éléments apparaissent dans la séquence de tabulation dans l’ordre où ils apparaissent dans le Document Object Model (DOM), sauf si le CSS ou JavaScript modifie délibérément cet ordre. Des problèmes surviennent lorsque la mise en page visuelle diverge de l’ordre du DOM (par exemple, via un réordonnancement avec CSS Flexbox ou Grid), ou lorsque des valeurs de tabindex imposent une séquence artificielle.

Ce qui est considéré comme conforme : L’ordre de focus doit être logique et significatif — pas nécessairement identique à l’ordre de lecture visuel, mais suffisamment cohérent pour que les utilisateurs puissent comprendre et utiliser la page. Une boîte de dialogue modale qui déplace le focus sur elle-même lorsqu’elle s’ouvre, garde le focus piégé à l’intérieur tant qu’elle est ouverte, et renvoie le focus à l’élément déclencheur lorsqu’elle se ferme respecte ce critère. Un formulaire en plusieurs étapes où Tab progresse à travers chaque champ dans l’ordre dans lequel un utilisateur les remplirait (de haut en bas, de gauche à droite dans les langues s’écrivant de gauche à droite) est également conforme.

Ce qui est considéré comme non conforme : Un focus qui passe du champ « Nom d’utilisateur » d’un formulaire de connexion à une bannière promotionnelle totalement sans rapport avant d’atteindre le champ « Mot de passe » est non conforme. Une application monopage qui ouvre une boîte de dialogue mais laisse le focus sur la page d’arrière-plan est non conforme. L’utilisation de valeurs entières positives de tabindex (par exemple, tabindex='2', tabindex='5') qui imposent une séquence de tabulation illogique sur la page est non conforme.

Exceptions officielles : WCAG précise explicitement que l’ordre de focus n’a pas besoin de correspondre à l’ordre de lecture visuel tant qu’il préserve la signification et l’opérabilité. Il existe également une tolérance pour les cas où les séquences de navigation n’affectent pas la signification ou le fonctionnement — par exemple, une page avec un seul élément focalisable n’a pas de séquence à évaluer. De plus, lorsqu’il existe plusieurs ordres valides qui préservent tous la signification, n’importe lequel de ces ordres est acceptable.

Les principaux mécanismes HTML et JavaScript qui affectent l’ordre de focus incluent : l’ordre naturel du DOM des éléments interactifs, l’attribut tabindex (en particulier les valeurs entières positives), les propriétés CSS qui réorganisent la mise en page visuelle sans modifier le DOM (comme order dans Flexbox/Grid, position: absolute et float), la gestion du focus pilotée par JavaScript (appel de .focus() sur des éléments), et les modèles de dialogue ARIA qui nécessitent une gestion explicite du focus.

Pourquoi c’est important

L’ordre de focus n’est pas un détail technique mineur — c’est l’ossature de la navigation sur le web pour une part significative des utilisateurs. Plusieurs groupes de personnes handicapées distincts dépendent d’une séquence de focus logique pour utiliser efficacement les produits numériques.

Les personnes ayant un handicap moteur qui ne peuvent pas utiliser une souris s’appuient entièrement sur le clavier (ou des dispositifs équivalents au clavier tels que les contacteurs souffle-et-aspiration, les pointeurs de tête ou les systèmes de suivi oculaire) pour naviguer. Pour ces personnes, un ordre de focus désordonné n’est pas seulement gênant — il peut rendre une page totalement inutilisable. Si la touche Tab amène l’utilisateur au mauvais endroit de la page, il se peut qu’il n’ait aucun moyen efficace d’atteindre le contrôle dont il a besoin, et il ne peut pas simplement déplacer sa main pour cliquer ailleurs.

Les personnes aveugles et les personnes malvoyantes qui utilisent des lecteurs d’écran tels que NVDA, JAWS ou VoiceOver entendent les éléments annoncés au fur et à mesure que le focus se pose sur eux. Un ordre de focus logique signifie que le flux audio qu’elles reçoivent reflète le déroulement prévu de l’interface. Lorsque le focus saute de manière erratique, les utilisateurs perdent leur modèle mental de l’endroit où ils se trouvent sur la page. Selon l’Organisation mondiale de la Santé, environ 2,2 milliards de personnes dans le monde présentent une forme de déficience visuelle, et pour beaucoup de celles qui utilisent des lecteurs d’écran, l’ordre de focus est leur principal moyen de percevoir la structure de la page.

Les personnes ayant un handicap cognitif bénéficient également de séquences de focus prévisibles. Un saut de focus inattendu au milieu d’un formulaire peut provoquer de la confusion, obliger les utilisateurs à recommencer des parcours, ou les amener à manquer des champs obligatoires. Les personnes ayant des difficultés d’attention ou de mémoire à court terme ont besoin d’une navigation cohérente et prévisible pour acquérir de l’assurance dans l’utilisation d’un site.

Un scénario concret du monde réel : Imaginez une page de paiement d’un site e-commerce turc. La conception visuelle utilise CSS Grid pour placer le récapitulatif de commande à gauche et le formulaire de paiement à droite. Cependant, dans le DOM, le formulaire de paiement vient en premier et le récapitulatif de commande en second. La mise en page visuelle semble correcte pour les utilisateurs voyants qui utilisent la souris, mais un utilisateur au clavier qui appuie sur Tab arrivera dans les champs du formulaire de paiement avant d’avoir eu la possibilité de consulter le récapitulatif de commande. Il pourrait confirmer sans le savoir une commande erronée. Pire encore, si un bouton « Confirmer l’achat » reçoit le focus avant un champ « Appliquer un coupon » en raison d’une mauvaise gestion de tabindex positif, un utilisateur pourrait soumettre par inadvertance un achat qu’il avait l’intention de réduire. Il s’agit d’une conséquence financière réelle et directe d’un ordre de focus défaillant.

Au-delà de l’accessibilité, un ordre de focus logique améliore l’expérience des utilisateurs avancés qui préfèrent la navigation au clavier pour gagner en rapidité. Il soutient également indirectement le SEO : un DOM bien structuré qui produit un ordre de focus naturel tend à refléter un balisage sémantique pertinent, que les moteurs de recherche utilisent pour comprendre la hiérarchie et l’importance du contenu.

Règles Axe-core associées

WCAG 2.4.3 nécessite un test manuel pour une évaluation définitive. Les outils automatisés comme axe-core ne peuvent pas déterminer algorithmiquement si une séquence de focus particulière « préserve la signification et l’opérabilité » — ce jugement nécessite une personne qui comprend l’objectif de la page et les relations entre les contenus. Cependant, axe-core et les outils associés peuvent signaler certains schémas qui sont de forts indicateurs de problèmes d’ordre de focus :

• tabindex (valeurs positives) — signal heuristique : Certains outils de linting et d’audit avertissent lorsque des éléments portent des valeurs entières positives de tabindex (toute valeur supérieure à 0). Les valeurs positives de tabindex remplacent l’ordre naturel du DOM et placent ces éléments au début de la séquence de tabulation, ce qui crée presque toujours un ordre de focus illogique et imprévisible. Bien que le jeu de règles principal d’axe-core n’inclue pas de règle automatisée dédiée « focus-order » (car la correction logique de la séquence ne peut pas être calculée), des outils comme axe DevTools Pro et les audits manuels vérifient spécifiquement l’utilisation de tabindex positifs comme indicateur indirect.
• scrollable-region-focusable : Axe-core inclut une règle qui signale les régions défilables qui ne sont pas focalisables au clavier. Bien qu’il ne s’agisse pas directement d’une règle sur l’ordre de focus, une région défilable qui ne peut pas recevoir le focus rompt la séquence de navigation globale, amenant les utilisateurs au clavier à passer outre du contenu avec lequel ils doivent interagir.
• Inspection manuelle du contenu réordonné par CSS : Les outils automatisés ne peuvent pas détecter quand l’utilisation de order avec CSS Flexbox ou le placement Grid crée un décalage entre l’ordre visuel et l’ordre du DOM. Un testeur humain doit comparer visuellement la mise en page à l’écran avec la séquence de focus observée lors de la navigation au clavier. Il s’agit de la source la plus fréquente d’échecs au critère 2.4.3 dans les conceptions responsives modernes, et elle est totalement invisible pour les scanners automatisés.
• Inspection manuelle de la gestion du focus JavaScript dans le contenu dynamique : Les applications monopage, les implémentations de défilement infini, les modales et les menus déroulants nécessitent tous que JavaScript déplace le focus de manière appropriée à mesure que le contenu change. Les outils automatisés exécutent un instantané statique du DOM et ne peuvent pas simuler la séquence d’interactions utilisateur nécessaire pour déclencher ces scénarios de gestion du focus. Seuls des tests manuels au clavier peuvent vérifier que le focus se déplace vers une modale nouvellement ouverte, revient au bon déclencheur à la fermeture, et ne laisse pas l’utilisateur bloqué dans une couche d’arrière-plan inaccessible.

Comment tester

1. Analyse automatisée comme point de départ : Exécutez axe DevTools (extension de navigateur) ou Google Lighthouse sur la page. Recherchez tout avertissement concernant des valeurs positives de tabindex et des régions défilables signalées. Notez qu’un résultat automatisé sans erreur ne signifie pas que le critère 2.4.3 est satisfait — des tests manuels sont toujours nécessaires. Enregistrez tout problème signalé pour un examen plus approfondi.
2. Débranchez votre souris et naviguez uniquement avec Tab : En partant de la barre d’adresse du navigateur ou du haut de la page, appuyez de manière répétée sur Tab pour parcourir chaque élément focalisable. Observez attentivement la séquence. Demandez-vous : le focus se déplace-t-il dans un ordre qui correspond au flux logique de lecture et d’interaction de la page ? Le focus saute-t-il parfois vers une zone inattendue ? Se retrouve-t-il parfois piégé (impossible d’avancer ou de reculer) en dehors d’une boîte de dialogue intentionnelle ?
3. Testez les composants dynamiques : Activez au clavier toutes les modales, boîtes de dialogue, menus déroulants, accordéons, panneaux d’onglets, sélecteurs de date ou autres widgets interactifs. Vérifiez que le focus se déplace immédiatement dans le contenu nouvellement révélé lors de l’activation. Après la fermeture d’une boîte de dialogue, confirmez que le focus revient à l’élément qui l’a déclenchée — et non en haut de la page ou à un emplacement arbitraire.
4. Testez avec NVDA + Firefox : Ouvrez NVDA, lancez Firefox et accédez à la page. Utilisez Tab pour parcourir les éléments interactifs et écoutez les annonces. Vérifiez que la séquence annoncée a un sens dans son contexte. Utilisez le mode navigation de NVDA (touches fléchées) pour lire le contenu statique et confirmez que l’ordre de lecture s’aligne avec l’ordre de focus des éléments interactifs au sein de ce contenu.
5. Testez avec VoiceOver + Safari (macOS/iOS) : Activez VoiceOver et utilisez Tab (sur ordinateur) ou les gestes de balayage (iOS) pour parcourir les éléments focalisables. Confirmez que la séquence de focus est logique. Sur iOS, testez que les modales et superpositions piègent correctement le focus et le restituent à la fermeture.
6. Testez avec JAWS + Chrome : Utilisez la navigation par Tab de JAWS et confirmez que la séquence de focus annoncée est cohérente. Utilisez le curseur virtuel de JAWS pour recouper l’ordre de lecture avec l’ordre de focus des éléments interactifs et identifier toute divergence.
7. Inspectez le DOM par rapport à la mise en page visuelle : Ouvrez les DevTools du navigateur et examinez la structure du DOM. Comparez l’ordre des éléments interactifs dans le DOM avec leur position visuelle à l’écran. Si des propriétés CSS comme order, position: absolute ou float créent des différences significatives, suivez manuellement la séquence de tabulation pour déterminer si la signification ou l’opérabilité est affectée.
8. Vérifiez les valeurs de tabindex dans le DOM : Dans la console du navigateur, exécutez document.querySelectorAll('[tabindex]') pour lister tous les éléments avec des attributs tabindex explicites. Examinez tout élément avec une valeur entière positive et évaluez si sa position dans l’ordre de tabulation modifié est logique.

Comment corriger

Valeurs positives de tabindex créant un ordre illogique — Incorrect

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Valeurs positives de tabindex créant un ordre illogique — Correct

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

Réordonnancement visuel CSS ne correspondant pas à l’ordre du DOM — Incorrect

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

Réordonnancement visuel CSS ne correspondant pas à l’ordre du DOM — Correct

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Boîte de dialogue modale ne gérant pas le focus — Incorrect

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Boîte de dialogue modale ne gérant pas le focus — Correct

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Erreurs courantes

• Utiliser des valeurs entières positives de tabindex (par exemple, tabindex='1', tabindex='5') pour « contrôler » l’ordre de focus au lieu de corriger la structure du DOM. Les valeurs positives de tabindex placent les éléments avant tous les éléments naturellement focalisables de la page, créant une séquence de tabulation globale chaotique, extrêmement difficile à maintenir et qui introduit presque toujours des erreurs.
• Appliquer la propriété CSS order dans Flexbox ou CSS Grid pour réorganiser visuellement le contenu sans réorganiser le DOM, puis ne pas tester la navigation au clavier. La mise en page visuelle semble correcte pour les utilisateurs voyants, mais la séquence de tabulation suit l’ordre du DOM, et non l’ordre visuel — une divergence invisible mais grave pour les utilisateurs au clavier.
• Ouvrir une modale ou une boîte de dialogue sans déplacer le focus de manière programmatique à l’intérieur à l’aide de la méthode .focus() de JavaScript. Les utilisateurs de lecteurs d’écran et de clavier restent bloqués dans le contenu d’arrière-plan, souvent incapables de trouver ou d’utiliser la boîte de dialogue.
• Ne pas renvoyer le focus à l’élément déclencheur après la fermeture d’une modale, d’un tiroir ou d’un menu déroulant. Renvoyer le focus en haut de la page ou le laisser sur un élément désormais masqué oblige les utilisateurs à renaviguer depuis le début, perdant leur position sur une page potentiellement longue.
• Insérer du contenu chargé dynamiquement (par exemple, un message d’erreur en ligne, une notification toast ou une section chargée paresseusement) dans le DOM après des éléments focalisables qui le précèdent visuellement, de sorte que les utilisateurs au clavier rencontrent le nouveau contenu hors séquence ou pas du tout.
• Utiliser tabindex='-1' pour retirer des éléments de la séquence de tabulation sans fournir de moyen alternatif d’accès au clavier. Bien que tabindex='-1' soit en soi un outil valide (il rend un élément focalisable par programmation mais le retire de l’ordre naturel de tabulation), l’appliquer de manière inappropriée à des contrôles dont les utilisateurs ont réellement besoin revient à cacher ces contrôles aux utilisateurs au clavier.
• Construire des transitions de routes dans une application monopage qui réinitialisent le focus sur le corps du document ou l’interface du navigateur au lieu de déplacer le focus vers le nouveau titre de page ou un repère de contournement de navigation. Les utilisateurs sont alors contraints d’appuyer sur Tab à travers toute la navigation à chaque changement de route.
• Implémenter des widgets de carrousel ou de diaporama personnalisés où la navigation avec les flèches n’est pas implémentée et où Tab déplace le focus à travers chaque diapositive masquée, obligeant les utilisateurs à tabuler à travers des dizaines d’éléments hors écran avant d’atteindre le contenu suivant de la page.
• Placer un lien de contournement de navigation « invisible » dans le DOM qui est toujours en display:none (plutôt que visuellement masqué avec une technique .sr-only / clip). Un lien en display:none est entièrement retiré de l’ordre de tabulation, n’apportant aucun bénéfice, tandis qu’un lien de contournement correctement implémenté reçoit le focus avec Tab et devient visible, soutenant directement un flux de focus logique vers le contenu principal.
• Imbriquer des éléments interactifs à l’intérieur d’autres éléments interactifs (par exemple, un <button> à l’intérieur d’une balise <a>), ce qui produit un comportement de tabulation incohérent selon les navigateurs et peut amener le focus à se poser plusieurs fois sur le même contrôle logique ou à le sauter complètement.

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

WCAG 2.4.3 Ordre de focus est directement pertinent pour la législation phare de la Turquie en matière d’accessibilité : la Circulaire présidentielle 2025/10, publiée au Journal officiel n° 32933 le 21 juin 2025. Cette circulaire établit des normes obligatoires d’accessibilité Web pour un large éventail d’entités publiques et privées opérant en Turquie, exigeant la conformité aux lignes directrices reconnues au niveau international — y compris tous les critères de succès de niveau A de WCAG 2.x, dont 2.4.3 fait partie.

La circulaire couvre un large éventail de types d’entités. Les institutions publiques — y compris les ministères, les municipalités, les universités d’État et les agences gouvernementales — doivent 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é dans les catégories couvertes doivent atteindre le même niveau de conformité dans un délai de deux ans. Les catégories du secteur privé couvertes incluent les plateformes de commerce électronique, 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, les entreprises de transport privé et les écoles privées opérant sous l’autorisation du ministère de l’Éducation nationale (MoNE).

Pour toutes ces organisations, un ordre de focus défaillant ou illogique n’est pas seulement un défaut d’ergonomie — c’est une non-conformité réglementaire qui peut exposer l’entité à des conséquences juridiques et administratives au titre des dispositions d’application de la circulaire. Imaginez le portail de banque en ligne d’une banque turque où l’ordre de focus sur l’écran de virement de fonds passe du champ montant au bouton de confirmation, en contournant le champ IBAN du bénéficiaire. Un utilisateur n’utilisant que le clavier — peut-être un client ayant un handicap moteur — pourrait initier par inadvertance un virement sans avoir correctement rempli tous les champs obligatoires. Ce scénario représente à la fois un échec au critère WCAG 2.4.3, une violation des exigences de la circulaire et un préjudice financier potentiellement grave pour l’utilisateur.

De même, un site e-commerce couvert par la circulaire qui utilise un réordonnancement CSS Grid pour afficher une page produit visuellement attrayante, mais dont la séquence de tabulation passe des images du produit aux liens de pied de page avant d’atteindre le bouton « Ajouter au panier », serait en violation directe du critère 2.4.3 et donc non conforme à la circulaire. Les délais d’un et deux ans signifient que les organisations doivent traiter la correction de l’ordre de focus comme une priorité dans leurs feuilles de route d’accessibilité — et non comme une amélioration différée. Étant donné que les problèmes d’ordre de focus découlent souvent de décisions architecturales concernant la structure du DOM et les modèles d’interaction JavaScript, les traiter tôt dans le processus de développement est nettement moins coûteux que de les corriger après le lancement.

Le SDK de superposition d’Accsible aide les organisations dans leur parcours vers la conformité en fournissant des améliorations configurables de gestion du focus, mais il est important de noter que les solutions de superposition fonctionnent mieux en complément — et non à la place — d’une structure HTML sémantique appropriée et d’une gestion responsable du focus dans le code même de l’application. Atteindre une conformité durable et vérifiable avec la Circulaire présidentielle 2025/10 exige que le produit sous-jacent respecte le critère 2.4.3 grâce à de bonnes pratiques de développement.