Sur beaucoup de sites, le menu paraît fonctionner. Il s’ouvre, il se ferme, il se replie sur mobile, il affiche des sous-menus, et tout semble correct tant qu’on le teste rapidement à la souris.
C’est justement ce qui rend le sujet trompeur.
Parce qu’un menu visible ne veut pas dire un menu accessible. Et comme la navigation commence souvent par lui, c’est aussi l’un des premiers endroits où un utilisateur peut se retrouver bloqué.
Si le menu principal ne reçoit pas correctement le focus, s’il ne s’ouvre pas au clavier, si les sous-menus dépendent du survol de la souris, ou si l’ordre de tabulation devient incohérent, le reste du site perd déjà une partie de son utilité. Peu importe ensuite que le contenu soit bon ou que les pages soient bien conçues : si l’entrée dans le site est fragile, l’expérience entière devient plus difficile.
C’est pour cela que les menus sont un très bon terrain de démonstration. Ils montrent immédiatement la différence entre une interface qui paraît fonctionner et une interface réellement utilisable.
1. Pourquoi le menu est souvent le premier obstacle
Le menu est une zone stratégique. C’est souvent par lui qu’on découvre les grandes rubriques, qu’on change de section, qu’on accède aux pages clés, ou qu’on cherche rapidement une information.
Quand cette zone fonctionne mal, le problème est plus grave qu’un simple défaut local. Il touche le parcours d’ensemble.
Sur un site peu accessible, les difficultés les plus fréquentes apparaissent vite :
- le focus n’arrive pas correctement sur le bouton de menu ;
- le menu mobile est visible, mais pas vraiment utilisable au clavier ;
- un sous-menu semble présent, mais ne s’ouvre qu’au survol ;
- les liens ne sont pas atteignables dans un ordre logique ;
- la fermeture n’est pas claire ;
- ou l’utilisateur ne sait plus où il se trouve.
Le menu devient alors un obstacle d’entrée. Et comme il intervient très tôt dans l’expérience, la gêne est immédiate.
2. Un menu visible ne veut pas dire un menu accessible
Beaucoup de défauts passent sous le radar parce qu’ils sont compensés par la souris ou par l’évidence visuelle.
Un bouton de menu “hamburger” peut sembler clair pour une personne qui voit bien l’écran et qui clique dessus directement. Mais encore faut-il qu’il soit identifié comme un vrai bouton, qu’il reçoive le focus, qu’il annonce son état, et qu’il permette ensuite d’accéder au contenu du menu sans rupture.
Même logique pour un sous-menu. Visuellement, on peut parfois deviner qu’il existe, voir qu’un petit signe le signale, ou qu’il s’ouvre lorsqu’on passe dessus à la souris. Mais cela ne suffit pas à en faire un composant accessible.
Le vrai test n’est donc pas seulement : est-ce que le menu s’affiche ?
Le vrai test est plutôt :
- est-ce qu’on peut l’atteindre ;
- est-ce qu’on comprend ce que l’on focus ;
- est-ce qu’on peut l’ouvrir ;
- est-ce qu’on peut le parcourir ;
- et est-ce qu’on peut en sortir proprement.
3. Le menu principal doit fonctionner sans souris
Le menu principal est souvent le premier point de rupture visible en navigation clavier, surtout en version mobile.
On pense parfois qu’un menu responsive est “bon” parce qu’il s’ouvre correctement au toucher. Mais un menu accessible doit aller plus loin. Il doit être utilisable aussi au clavier et compréhensible par les technologies d’assistance.
Cela veut dire concrètement :
- que le bouton de menu doit être atteignable ;
- qu’un focus visible doit apparaître ;
- que le composant doit être annoncé correctement ;
- que son ouverture doit fonctionner sans souris ;
- que les liens du menu doivent être parcourables ;
- et qu’on doit pouvoir refermer le tout proprement.
Menu principal responsive
Cette démonstration est utile parce qu’elle montre une différence qui peut sembler minime visuellement, mais qui change complètement l’usage réel. Dans une version non accessible, le menu existe à l’écran mais reste mal repéré ou mal parcouru. Dans une version corrigée, il devient un véritable point d’entrée utilisable.
4. Un sous-menu doit pouvoir s’ouvrir et se refermer au clavier
Les sous-menus sont souvent encore pensés comme des éléments de survol. Cela reste un réflexe très courant dans la conception des interfaces.
Le problème, c’est qu’un sous-menu dépendant uniquement de la souris devient fragile dès qu’on change de mode de navigation.
Au clavier, plusieurs questions deviennent immédiatement importantes :
- peut-on ouvrir le sous-menu sans souris ;
- peut-on entrer dans ses liens ;
- peut-on comprendre son état ;
- peut-on en sortir ;
- et peut-on refermer le composant sans casser la suite de navigation.
Sous-menu au clavier
Cette démonstration aide bien à rendre le sujet concret. Elle montre qu’un sous-menu ne devient pas accessible parce qu’il est visible. Il le devient lorsqu’il peut s’ouvrir, se parcourir et se refermer de manière fiable au clavier.
5. L’ordre de tabulation change toute la navigation
Même quand un menu semble techniquement accessible, l’ordre de tabulation peut encore dégrader fortement l’expérience.
Un parcours clavier cohérent suit la logique de lecture et la logique d’usage. Si l’on saute sans raison d’un élément à un autre, si le focus revient en arrière, ou si des zones arrivent trop tôt ou trop tard, l’utilisateur doit constamment reconstruire ce qu’il se passe.
Ce point compte particulièrement dans les zones de navigation, parce qu’elles servent justement à se repérer vite.
Navigation clavier simple
Cette vidéo montre qu’une action atteignable n’est pas encore une action bien intégrée dans le parcours. Il faut aussi que l’ordre, le focus et les retours soient clairs.
Ordre de tabulation cohérent
Cette démonstration complète très bien la précédente. Elle rappelle qu’un bon ordre de tabulation n’est pas un détail technique secondaire. C’est une condition de lisibilité du parcours.
6. Ce que ces démonstrations montrent sur les menus accessibles
Ces démonstrations montrent quelque chose de simple mais très utile : un menu accessible ne se résume pas à un composant “joli” ou “moderne”. Il doit rester utilisable dans des conditions réelles, sans dépendre uniquement de la souris ou du contexte visuel.
Autrement dit, un menu accessible doit être :
- atteignable ;
- compréhensible ;
- ouvrable ;
- parcourable ;
- refermable ;
- et intégré dans un ordre de navigation cohérent.
C’est cette combinaison qui fait la différence entre un site qui paraît fonctionner et un site réellement praticable.
Sur WordPress, ces problèmes apparaissent souvent dans :
- les menus mobiles personnalisés ;
- les en-têtes de thème trop dépendants du JavaScript ;
- les sous-menus conçus pour le survol ;
- les composants injectés par des builders ;
- ou les reprises CSS / JS qui dégradent le focus et le parcours clavier.
Et comme le menu est l’un des premiers composants utilisés, il mérite souvent d’être vérifié tôt dans un audit ou dans une reprise d’accessibilité.
En pratique, si un menu casse déjà l’accès au site, le reste des corrections devient secondaire. D’où l’intérêt de le traiter comme une priorité de navigation, pas comme un simple détail d’interface.
Comprendre l’accessibilité web à partir des usages réels
Les menus, le clavier, le focus et l’ordre de navigation montrent bien que l’accessibilité ne se juge pas seulement à l’apparence d’un composant, mais à sa capacité à rester utilisable.
