Navigation au clavier : pourquoi un bouton très visible peut rester inutilisable

Le bouton est grand, contrasté et placé au centre de la page. Avec la souris, il ouvre immédiatement le formulaire. Pourtant, une personne utilisant seulement le clavier peut passer devant sans jamais l’atteindre, ou l’atteindre sans réussir à déclencher l’action.

La visibilité graphique et l’utilisation au clavier sont deux propriétés différentes. Pour les contrôler, il faut suivre le parcours avec les touches, puis vérifier ce qui se passe après chaque action.

Un élément peut ressembler à un bouton sans en être un

Sur une page web, un rectangle peut être dessiné avec un élément générique auquel on ajoute une réaction au clic. Le résultat paraît correct à l’écran. Il peut manquer le comportement qui permet de recevoir le focus clavier, d’être annoncé avec le bon rôle et de réagir aux touches attendues.

Un bouton HTML natif fournit déjà une partie essentielle de ces comportements. Un lien natif correspond plutôt à une navigation vers une destination. Choisir l’élément selon sa fonction simplifie le développement et réduit le risque d’oublier des interactions.

Ajouter un rôle ARIA ne crée pas automatiquement le comportement. Un élément déclaré bouton doit encore pouvoir être atteint et activé correctement. L’étiquette accessible doit également expliquer l’action. Le nom « cliquer ici », répété plusieurs fois, ne décrit pas utilement ce que chaque commande va faire.

Les recommandations du W3C distinguent précisément la fonction du bouton de celle du lien. Ce choix technique se traduit directement dans l’expérience : ouvrir une fenêtre, envoyer un formulaire et rejoindre une autre page ne doivent pas être assemblés au hasard sous une même apparence.

Parcourir la page avec Tab révèle une autre interface

Placez la souris de côté et rechargez la page. Utilisez Tabulation pour avancer et Majuscule avec Tabulation pour revenir. Le parcours doit permettre d’atteindre les commandes utiles dans un ordre compréhensible. Il n’est pas nécessaire de faire arrêter le clavier sur chaque morceau de texte.

À chaque étape, vous devez voir quel élément reçoit le focus. Une bordure supprimée pour des raisons esthétiques peut rendre la navigation presque aveugle. Le repère de focus doit rester perceptible pendant l’interaction, y compris sur un fond coloré ou une zone déjà sélectionnée.

Ne confondez pas focus et survol. Un style visible seulement lorsque la souris passe au-dessus de l’élément n’aide pas la personne utilisant le clavier. Le navigateur et le code du site doivent produire un état adapté au mode d’interaction.

Observez aussi l’ordre. Un bouton placé visuellement près du formulaire peut apparaître très loin dans la séquence si la structure de la page ne suit pas sa présentation. Une multiplication de valeurs positives de tabindex peut rendre cet ordre difficile à maintenir. Pour corriger le problème, commencez généralement par la structure plutôt que par une liste d’exceptions.

Activer ne suffit pas : il faut pouvoir poursuivre

Lorsque le focus atteint un bouton, vérifiez son activation avec Entrée et Espace, selon le comportement attendu du composant. Pour un lien, la touche Entrée sert normalement à suivre la destination. Les composants plus complexes peuvent prévoir d’autres touches, mais leur fonctionnement doit rester cohérent et explicable.

Après l’ouverture d’une boîte de dialogue, le focus doit rejoindre un endroit pertinent. S’il reste derrière la fenêtre, la personne peut continuer à parcourir un contenu masqué sans comprendre ce qui vient de se passer. À la fermeture, elle doit retrouver un point logique pour poursuivre, souvent la commande d’origine.

Une fenêtre modale peut contenir volontairement la navigation tant qu’elle est ouverte. Ce fonctionnement ne doit pas devenir un piège : il faut une manière utilisable de fermer la fenêtre et de continuer le parcours. Une publicité ou un sélecteur impossible à quitter peut bloquer l’ensemble de la page.

Testez les erreurs du formulaire. Un envoi refusé doit permettre de repérer les champs concernés et de comprendre la correction attendue. Une simple couleur rouge ne suffit pas à expliquer une erreur ; un message affiché loin du focus peut rester inaperçu.

Tester le vrai parcours, y compris ses obstacles temporaires

Le scénario le plus utile part de l’arrivée sur le site et va jusqu’à une action terminée : demander un devis, choisir une option ou télécharger un document. Il doit inclure le bandeau de consentement, le menu mobile, les listes déroulantes et les éventuels contenus ajoutés dynamiquement.

Les contenus superposés créent souvent des difficultés invisibles lors d’un contrôle rapide. Un en-tête fixe peut recouvrir l’élément actif. Un bandeau peut prendre toute la place sur un petit écran. Un bouton accessible avant l’ouverture d’un menu peut cesser de l’être après.

Refaites le parcours avec un niveau de zoom adapté à l’examen et sur les principaux navigateurs utilisés par votre public. Les problèmes peuvent varier selon le rendu, les réglages et les composants tiers. Notez la page, la touche utilisée, l’élément attendu et le résultat observé pour transmettre une anomalie reproductible.

Les outils automatiques peuvent repérer certaines erreurs de structure ou de nom accessible. Ils ne valident pas à eux seuls l’ordre du parcours, la pertinence du déplacement du focus et la compréhension de toutes les étapes. Une vérification manuelle reste nécessaire.

Les critères WCAG du W3C donnent des repères distincts pour l’utilisation au clavier et la visibilité du focus. Leur examen ne se réduit pas à compter les boutons atteints. Il faut pouvoir réaliser les fonctions proposées, comprendre où l’on se trouve et sortir des composants rencontrés.

Avant de déclarer un formulaire prêt, terminez donc une demande sans reprendre la souris. Ce test court ne constitue pas un audit complet d’accessibilité, mais il peut révéler immédiatement pourquoi un bouton parfaitement visible reste inutilisable pour une partie du public.