Navigation clavier et Drupal

La navigation clavier est l’un des piliers de l’accessibilité web et c’est aussi l’un des plus faciles à négliger. Tant qu’on conçoit et teste un site à la souris, on ne voit jamais les problèmes : un focus invisible, un ordre de tabulation incohérent, une modale dont on ne peut plus sortir. Pourtant, pour une partie significative de vos visiteurs, le clavier est le seul moyen d’utiliser votre site. Si la navigation au clavier est cassée, le site est inutilisable pour eux, quel que soit le soin apporté au design visuel.

La bonne nouvelle, c’est que Drupal fait beaucoup de choses correctement par défaut. Le travail consiste surtout à ne pas casser ce qui fonctionne déjà et à corriger quelques erreurs courantes. Cet article explique pourquoi la navigation clavier est essentielle, quels critères RGAA sont concernés, ce que Drupal fournit nativement et quelles sont les erreurs à éviter sur votre projet.

Pourquoi la navigation clavier est essentielle

La navigation clavier ne concerne pas une niche marginale. Elle touche plusieurs populations d’utilisateurs aux besoins très différents, qui représentent ensemble une part loin d’être négligeable de votre audience.

Les utilisateurs de lecteurs d’écran. Les personnes aveugles ou malvoyantes naviguent au clavier (ou via des commandes équivalentes) et s’appuient sur la synthèse vocale pour comprendre la page. Le lecteur d’écran suit l’ordre du focus et la structure du DOM. Si l’ordre de tabulation est chaotique, le contenu leur est restitué dans le désordre, ce qui rend la compréhension de la page très difficile.

Les personnes en situation de handicap moteur. Certains utilisateurs ne peuvent pas manipuler une souris avec la précision requise. Ils utilisent le clavier, un système de balayage, une commande vocale ou des dispositifs adaptés qui simulent une navigation clavier. Pour eux, chaque interaction passe par la touche Tab, Entrée et les flèches.

Les power users. Une partie de vos visiteurs les plus engagés (administrateurs, contributeurs, utilisateurs réguliers) naviguent au clavier par efficacité. Sur un back-office Drupal, la saisie clavier est souvent plus rapide que la souris. Une bonne navigation clavier améliore leur productivité au quotidien.

Au-delà des utilisateurs, c’est aussi une obligation. En France, le RGAA impose la conformité à de nombreux organismes publics et para-publics. La directive européenne sur l’accessibilité étend progressivement ces exigences au secteur privé. La navigation clavier est au cœur de ces critères. C’est précisément le type de sujet que couvre une démarche structurée d’accessibilité RGAA Drupal, qui aligne votre site sur les attentes réglementaires et sur les besoins réels des utilisateurs.

Les critères RGAA concernés

Le RGAA (référentiel général d’amélioration de l’accessibilité) reprend les critères de succès des WCAG. Plusieurs d’entre eux portent directement sur la navigation clavier. Voici les principaux à connaître.

Le focus visible. À tout moment, l’utilisateur doit voir clairement quel élément a le focus. C’est l’équivalent clavier du curseur de la souris : sans indicateur visible, impossible de savoir où l’on se trouve dans la page. Le critère exige un indicateur de focus perceptible, avec un contraste suffisant par rapport à l’arrière-plan.

L’ordre de tabulation logique. Quand on appuie sur Tab, le focus doit se déplacer dans un ordre cohérent et prévisible, généralement de gauche à droite et de haut en bas, en suivant la logique de lecture. Un ordre incohérent désoriente l’utilisateur et casse la compréhension de la page.

Les liens d’évitement (skip links). En haut de page, un lien d’évitement permet de sauter directement au contenu principal sans avoir à traverser tout le menu de navigation à chaque page. Pour un utilisateur clavier, devoir tabuler à travers vingt liens de menu sur chaque page est épuisant. Le skip link est une réponse simple et standardisée à ce problème.

L’absence de piège clavier. Aucun composant ne doit emprisonner le focus. Si l’utilisateur peut entrer dans un élément (une modale, un carrousel, un lecteur vidéo) au clavier, il doit pouvoir en sortir au clavier. Un piège clavier bloque complètement la navigation et oblige l’utilisateur à recharger la page.

Ces critères ne sont pas indépendants : ils forment un ensemble cohérent. Un site qui les respecte offre une expérience clavier fluide et c’est généralement le signe d’un front-end bien construit dans son ensemble.

Ce que Drupal fait nativement

Drupal part d’une bonne base. Le core et ses thèmes d’administration intègrent depuis longtemps une attention réelle à l’accessibilité, portée par une communauté active sur ces sujets.

Les liens d’évitement intégrés. Les thèmes du core (Olivero pour le front, Claro pour l’administration) fournissent un lien d’évitement vers le contenu principal. Il est masqué visuellement par défaut et apparaît dès qu’il reçoit le focus au clavier. Le markup HTML5 utilisé par ces thèmes (balises header, nav, main, footer) structure correctement la page pour les technologies d’assistance.

Une gestion correcte du focus dans le core. Les composants JavaScript du core (modales, menus déroulants, tableaux interactifs) sont conçus pour gérer le focus correctement. Drupal s’appuie largement sur les attributs ARIA et sur des patterns reconnus pour annoncer les changements d’état aux lecteurs d’écran.

Des formulaires accessibles par défaut. Le Form API génère des labels correctement associés aux champs, des messages d’erreur reliés aux champs concernés et des éléments natifs (boutons, champs de saisie) qui sont nativement focusables et utilisables au clavier. C’est un atout majeur, car les formulaires sont souvent le point de friction principal pour l’accessibilité.

Une attention soutenue de la communauté. L’accessibilité fait partie des critères de validation des contributions au core Drupal. Les nouveaux composants sont testés sous cet angle, ce qui maintient un niveau de qualité élevé au fil des versions.

Tout cela signifie qu’un site Drupal bien construit, avec un thème qui respecte les bases du core, démarre avec une navigation clavier saine. Les problèmes apparaissent presque toujours dans le code custom : un thème sur mesure, un module spécifique, une intégration front qui passe à côté des règles.

Les erreurs courantes

C’est ici que se concentre l’essentiel du travail correctif. La plupart des sites Drupal qui échouent sur la navigation clavier le font à cause d’une poignée d’erreurs récurrentes, presque toujours évitables.

Supprimer le focus visible avec outline: none. C’est de loin l’erreur la plus fréquente. Pour des raisons esthétiques, on supprime le contour de focus par défaut du navigateur sans rien mettre à la place :

/* À ne jamais faire seul : le focus devient invisible */
:focus {
  outline: none;
}

Le résultat : l’utilisateur clavier ne voit plus du tout où il se trouve. La page devient inutilisable au clavier. Si le contour par défaut ne convient pas au design, il faut le remplacer par un indicateur visible et contrasté, pas le supprimer :

/* Correct : on remplace par un focus visible et contrasté */
:focus-visible {
  outline: 2px solid #1a5fb4;
  outline-offset: 2px;
}

L’usage de :focus-visible plutôt que :focus est recommandé : il affiche l’indicateur lors d’une navigation clavier, sans l’afficher systématiquement au clic souris, ce qui satisfait à la fois les exigences d’accessibilité et les attentes des designers.

Un focus présent mais imperceptible. Variante plus subtile : le focus existe mais son contraste est trop faible pour être réellement visible ou il est masqué par un autre élément (un sticky header, un overlay). Le critère RGAA n’exige pas seulement un focus, mais un focus perceptible. Un indicateur gris clair sur fond blanc ne suffit pas.

Les pièges clavier dans les composants interactifs. Les modales, carrousels et menus custom sont les coupables habituels. Une modale ouverte en JavaScript qui ne gère pas le focus laisse l’utilisateur tabuler derrière l’overlay ou, pire, l’enferme sans possibilité de sortie. Une modale accessible doit capturer le focus à l’ouverture, le maintenir à l’intérieur tant qu’elle est ouverte, le restituer à l’élément déclencheur à la fermeture et se fermer avec la touche Échap. C’est exactement ce que gèrent les composants du core, raison de plus pour s’appuyer dessus plutôt que de réinventer.

Un ordre DOM incohérent avec l’ordre visuel. Avec CSS (flexbox, grid, positionnement absolu), il est facile de réorganiser visuellement des éléments sans changer leur ordre dans le DOM. Or le focus suit le DOM, pas l’affichage. Si un bloc apparaît visuellement en premier mais se trouve à la fin du HTML, l’utilisateur clavier l’atteindra en dernier. La règle : l’ordre du DOM doit correspondre à l’ordre de lecture logique. Réorganisez avec CSS sans rompre cette correspondance et évitez les valeurs de tabindex positives, qui forcent un ordre artificiel difficile à maintenir.

Des éléments non natifs rendus interactifs. Utiliser une div ou un span avec un gestionnaire de clic au lieu d’un vrai button ou a est une source classique de problèmes : ces éléments ne sont pas focusables au clavier et ne réagissent pas à Entrée ou Espace. Privilégiez toujours les éléments HTML natifs, qui apportent gratuitement la focusabilité, la sémantique et le comportement clavier attendu.

Tester et fiabiliser la navigation clavier

La bonne nouvelle, c’est que tester la navigation clavier ne demande aucun outil sophistiqué. Débranchez la souris (au sens propre ou figuré) et parcourez vos parcours critiques uniquement avec Tab, Maj+Tab, Entrée, Espace, les flèches et Échap. Vérifiez que vous voyez toujours le focus, que l’ordre est logique, que le skip link fonctionne et qu’aucun composant ne vous emprisonne. En quelques minutes, vous détectez la majorité des problèmes.

Pour aller plus loin, les outils automatisés (axe, Lighthouse, WAVE) repèrent une partie des défauts, mais ils ne remplacent pas le test manuel au clavier. L’idéal combine les deux : automatisation pour le contrôle continu, test humain pour ce que la machine ne sait pas évaluer. Sur les parcours les plus sensibles, des tests end-to-end peuvent même valider la navigation clavier à chaque déploiement, ce qui évite les régressions silencieuses.

Si vous souhaitez savoir où en est votre site, un audit Drupal permet de dresser un état des lieux précis de la navigation clavier et plus largement de la conformité RGAA, avec des recommandations priorisées. C’est le point de départ logique avant d’engager des corrections, car il évite de disperser l’effort et concentre le budget sur ce qui a le plus d’impact pour vos utilisateurs.

La navigation clavier n’est pas un sujet réservé aux experts en accessibilité. C’est une dimension de qualité du front-end qui bénéficie à tout le monde, des utilisateurs de technologies d’assistance aux power users de votre back-office. Drupal vous donne une base solide. Le reste est une question de rigueur et de vigilance dans le code custom.

Vous voulez vérifier la navigation clavier de votre site Drupal ou engager une mise en conformité RGAA ? Parlons de votre projet : je vous propose un diagnostic et un plan d’action adapté à votre contexte.