Comment vérifier que le focus clavier reste toujours visible ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre focus visible

Le focus clavier indique quel élément recevra la prochaine action. Lorsqu’il disparaît visuellement, une personne naviguant avec Tab peut encore déplacer le focus sans savoir où elle se trouve. Le problème concerne donc la perception du parcours, pas seulement un détail décoratif.

Inspecter le comportement réellement servi

Parcourez la page uniquement avec Tab, Maj+Tab et les touches attendues par les composants. Notez chaque élément interactif dont l’indicateur est absent, masqué, coupé par overflow ou trop proche du style normal pour être reconnu rapidement.

Distinguer les notions qui se ressemblent

Distinguez focus, hover et état actif. Un changement au survol ne remplace pas un indicateur clavier. De même, supprimer outline en CSS sans fournir d’alternative perceptible crée souvent l’anomalie. L’objectif n’impose pas une forme graphique unique mais un repère réellement visible.

Identifier les causes les plus probables

Les régressions viennent fréquemment d’un reset CSS, d’un outline:none global, d’un composant tiers, d’un contraste insuffisant ou d’un anneau dessiné hors d’un conteneur qui le rogne. Les overlays et en-têtes fixes peuvent aussi cacher l’élément focalisé.

Décider ce qui mérite d’être corrigé en premier

Priorisez les parcours qui permettent d’acheter, se connecter, lancer un audit, remplir un formulaire ou naviguer dans les menus. Un focus discret sur un lien secondaire est gênant ; un focus introuvable dans une modale peut bloquer complètement la tâche.

Corriger à la bonne couche

Définissez un style :focus-visible cohérent avec le design system, suffisamment distinct de l’état normal et utilisable sur plusieurs arrière-plans. Évitez d’appliquer la correction uniquement à quelques boutons si liens, champs et composants personnalisés restent sans repère.

Traiter les cas limites sans automatisme

Les composants composites, menus, onglets ou carrousels peuvent gérer leur focus avec des règles spécifiques. Vérifiez alors quel élément est réellement focalisable et ne multipliez pas plusieurs anneaux concurrents. Un focus programmatique après ouverture de modale doit également rester perceptible.

Valider la correction sur des cas réels

Refaites le parcours sans souris, sur fonds clairs et foncés, avec les états désactivé, erreur et sélectionné. Contrôlez qu’aucun changement de layout ne masque l’indicateur et que l’ordre de tabulation reste logique après la correction.

Prévenir la régression dans le temps

Centralisez les styles de focus dans les composants partagés et ajoutez un test clavier aux critères d’acceptation. Une capture visuelle ou un test automatisé peut signaler certaines suppressions, mais une vérification réelle du parcours reste nécessaire.

Clôturer le contrôle sur focus visible

Pour clôturer le contrôle « Comment vérifier que le focus clavier reste toujours visible ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /site/accessibilite, /site/verifier-navigation-clavier, /site/verifier-contraste-couleurs afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Expliquer qu’un indicateur de focus visible aide l’utilisateur à savoir quel composant reçoit les actions clavier. Ne pas prescrire une apparence unique si le focus reste clairement perceptible. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur focus visible est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Testez un parcours complet plutôt qu’un composant isolé : ouverture du menu, passage au champ de recherche, sélection d’un résultat, ouverture d’une modale, fermeture puis retour au déclencheur. À chaque étape, notez la position du focus et la forme du repère visible. Essayez un fond clair, un bandeau sombre et un élément proche du bord d’un conteneur avec overflow. Un anneau correctement dessiné mais rogné par le parent doit être considéré comme un défaut réel. Vérifiez aussi le cas :focus-visible afin que l’expérience souris ne serve pas d’argument pour supprimer le repère clavier. Sur les onglets ou menus composites, contrôlez que le déplacement interne ne crée pas plusieurs indicateurs concurrents. Cette séquence permet de relier le style CSS, l’ordre de tabulation et la gestion programmatique du focus dans un même scénario reproductible. Conservez enfin une courte vidéo ou une séquence de captures montrant le parcours au clavier avant et après correction : elle permet de vérifier le retour du focus, les états de modale et la visibilité du repère sans dépendre d’une appréciation abstraite du CSS. Documentez outline-width, outline-offset, box-shadow, :focus, :focus-visible, tabindex, inert, overflow, z-index et position sticky lorsque ces propriétés interviennent. Sur une dialog, notez l’élément qui reçoit le focus à l’ouverture, la boucle de tabulation et le déclencheur qui le récupère à la fermeture. Cette fiche CSS et DOM rend le diagnostic beaucoup plus précis qu’une capture montrant seulement un anneau bleu absent. Sur mobile avec clavier externe, vérifiez aussi les contrôles du menu hamburger, le carrousel et le bouton de fermeture du consentement. Un composant qui reste focalisé derrière un overlay ou sous un bandeau fixe révèle un problème de gestion spatiale différent d’un simple contraste insuffisant. Dans une feuille de contrôle, distinguez focus initial, focus déplacé, focus piégé, focus restauré et focus perdu après suppression d’un élément. Testez skip link, menu déroulant, accordéon, toast, modal, popover et champ en erreur. Ces composants sollicitent des transitions différentes et permettent de vérifier si la stratégie de focus du design system reste cohérente au-delà d’un simple lien.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• w3c focus visible