Qu'est-ce que Visualiseur d'ordre de focus ?

Collez n'importe quel HTML et visualisez l'ordre de tabulation clavier. Des marqueurs numérotés apparaissent sur chaque élément focalisable pour repérer les problèmes de navigation d'un coup d'œil. Conçu pour les auditeurs d'accessibilité et les développeurs qui vérifient la conformité WCAG.

Le visualiseur détecte les liens, boutons, champs de formulaire, textareas, menus select, composants details/summary, régions contenteditable et tout élément avec un tabindex explicite. Chaque élément focalisable reçoit un badge numéroté et une indication précisant si la position vient de l'ordre du DOM (naturel) ou d'un tabindex qui la remplace (personnalisé). Il attribue aussi un score sur 100 à la page, signale les contrôles sans nom accessible (le problème du bouton qui n'a qu'une icône) et indique combien d'éléments interactifs ne deviennent jamais atteignables au Tab. Exportez les résultats en rapport texte brut ou en CSV structuré pour vos dossiers d'audit et vos outils de suivi.

Comment utiliser

1. Collez le code HTML dans l'éditeur ou importez un fichier HTML pour vérifier l'ordre de tabulation.
2. Des marqueurs numérotés apparaissent sur chaque élément focalisable (liens, boutons, champs de saisie) indiquant la séquence de tabulation.
3. Consultez le score d'accessibilité et le panneau des problèmes, corrigez les éléments mal ordonnés, sans libellé ou inatteignables au clavier, puis exportez les résultats en rapport texte ou en CSV.

Quand l'utiliser

• Vérification préalable avant soumission d'une page pour certification WCAG 2.1 AA.
• Traquer une régression d'ordre de tabulation après refonte d'un composant.
• Valider qu'une modale ou un menu latéral capture bien le focus.

Résultat

Un consultant en accessibilité colle le HTML du formulaire d'inscription d'un client. Le visualiseur repère que le bouton « Envoyer » reçoit le focus avant la case « Conditions d'utilisation », parce qu'un tabindex positif a réordonné les éléments. C'est une violation WCAG 2.4.3.

FAQ

Utiliser un tabindex positif est-il toujours une erreur ?

Presque toujours, oui. Les tabindex positifs (1, 2, 3…) sortent l'élément de l'ordre du DOM et font sauter le curseur dans la page de manière imprévisible. Préférez tabindex="0" pour rendre focalisable un élément non interactif, ou tabindex="-1" pour le retirer de la chaîne Tab tout en gardant le focus programmatique.

Que veulent dire «naturel» et «personnalisé» dans la liste ?

Naturel signifie que la position de tabulation vient de l'emplacement de l'élément dans le HTML source. Personnalisé veut dire qu'un tabindex positif l'a forcé ailleurs. Les positions personnalisées sont signalées car elles sont la cause la plus fréquente d'échecs WCAG 2.4.3.

Les éléments masqués apparaissent-ils dans l'ordre de focus ?

S'ils sont vraiment masqués (display:none ou visibility:hidden), le navigateur les ignore et le visualiseur aussi. Mais aria-hidden seul ne retire pas la focalisabilité, ce qui est un bug courant. La liste les affichera et les données du rectangle vous diront s'ils sont visibles.

L'outil détecte-t-il l'absence de focus trap dans une modale ?

Il vous montre l'ordre, pas si le focus s'échappe de la modale. Collez le HTML de la modale ouverte et vérifiez que le premier et le dernier élément focalisables sont dans la boîte de dialogue. Si l'ordre saute vers le contenu du body, le focus trap manque.

Pourquoi un élément que je pensais focalisable manque-t-il à la liste ?

Les inputs désactivés, les anchor sans href et les div sans tabindex sont ignorés car le navigateur ne peut pas les focaliser. Ajoutez tabindex="0" si un div doit être atteignable, ajoutez href à un anchor, ou retirez l'attribut disabled.

Outils similaires