Tester la navigation et les menus d’un site web

Partir de tâches réelles

Choisissez quelques intentions concrètes : trouver un prix, comparer deux services, accéder à un contact ou retrouver une information déjà vue. Demandez à des personnes qui ne connaissent pas le site de montrer où elles commenceraient. Notez leur premier choix et les retours en arrière sans les guider.

Comparez les mots du menu avec ceux employés par les visiteurs. Une rubrique « Solutions » peut sembler claire à l’équipe et rester opaque pour une personne extérieure. Le guide des pages service aide à aligner intitulé, contenu et décision.

• Tâches et publics définis.
• Premier choix observé sans aide.
• Libellés corrigés selon les hésitations.

Vérifier plusieurs chemins

Une page importante doit rester accessible depuis un chemin prévisible, même si le visiteur arrive directement depuis un moteur. Testez navigation principale, liens dans le contenu, fil d’Ariane et pied de page. Vérifiez que les intitulés d’un même service ne changent pas sans raison.

Contrôlez les menus profonds : plus une rubrique contient de niveaux, plus il faut vérifier que la relation parent-enfant reste compréhensible. Évitez de placer une destination essentielle uniquement dans un effet de survol qui disparaît sur écran tactile.

• Pages clés accessibles sans détour.
• Liens contextuels cohérents.
• Aucune destination dépendante du seul survol.

Tester clavier et petit écran

Parcourez tout le menu avec Tab, Entrée, Espace et Échap selon les composants utilisés. Le focus doit être visible et le sous-menu ouvert doit pouvoir être quitté. Sur téléphone, contrôlez l’ouverture, la fermeture, la taille des cibles et le comportement lorsque le texte est agrandi.

Testez une page longue et une page courte. Un menu fixe peut masquer le titre après un lien d’ancre ; un tiroir peut garder le défilement bloqué après fermeture. Les exemples de menus du W3C donnent des repères de structure et de comportement.

Pour une navigation ordinaire composée de liens et d’un bouton de dépliage, définissez le résultat attendu dans chacun des quatre états ci-dessous. aria-expanded décrit l’état ; cet attribut ne masque pas les liens à lui seul. Vérifiez simultanément visibilité, parcours au clavier et annonce par les aides techniques. Un panneau fermé dont les liens reçoivent encore le focus ne respecte pas ce contrat, même si sa capture d’écran paraît correcte.

Dans le modèle de dépliage retenu ici, Échap ferme le panneau et rend le focus à son bouton. Ce panneau non modal ne doit pas enfermer la navigation au clavier. Ne lui attribuez pas automatiquement les rôles menu ou menubar : ces composants impliquent d’autres interactions. L’exemple APG du W3C illustre un modèle, ce n’est pas du code prêt à publier ; les essais avec navigateurs et aides techniques restent nécessaires et ne valent pas certification de tout le site.

• Focus et fermeture testés.
• Cibles tactiles utilisables.
• Ancres et défilement contrôlés.

Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.

• W3C APG : Disclosure Navigation

  W3C APG, consulté le 22 octobre 2026 : navigation à dépliage, clavier et limites de l’exemple. Le changement de largeur complète notre contrat de test.

Mesurer puis corriger les impasses

Regroupez les problèmes selon leur effet : page introuvable, intitulé ambigu, boucle, lien cassé ou élément impossible à atteindre. Corrigez d’abord les parcours liés aux demandes réelles, puis refaites le test avec une personne qui ne connaît pas la correction.

Après publication, regardez les recherches internes, les pages de sortie et les demandes répétées sans conclure à partir d’un seul chiffre. Une question posée au téléphone peut révéler un menu confus. Le guide de mesure aide à relier ces signaux à une amélioration vérifiable.

• Impasses classées par conséquence.
• Correction retestée.
• Signaux de terrain revus après mise en ligne.

Tester une navigation ouverte puis refermée

Ouvrez les rubriques avec le clavier, choisissez une destination et revenez en arrière. Contrôlez que les liens d’un panneau fermé ne reçoivent plus le focus et que le lecteur retrouve un contexte utile. Séparez le test d’un lien qui ouvre une page de celui d’une commande qui affiche un sous-menu.

Changez ensuite la largeur de la fenêtre pendant que la navigation est ouverte. Ce cas révèle les états conservés entre versions mobile et ordinateur. Notez les intitulés qui ne permettent pas de deviner la destination et corrigez-les à la source plutôt que d’ajouter une explication uniquement dans le compte rendu.

Concevoir une navigation mobile et ses sous-menus · Choisir et tester des onglets dans une interface web

Tester le retour dans un menu

Cas proposé : un sous-menu s’ouvre sur mobile mais ne rend pas le focus à son déclencheur après fermeture. Le visiteur perd son point de départ.

Testez ouverture, changement de niveau et fermeture avec différents moyens d’entrée. Gardez ordre des liens, état du panneau et chemin de retour ; un menu visible ne prouve pas une navigation maîtrisée.

• Identifier le déclencheur
• Tester entrée et sortie du panneau
• Vérifier le retour au contexte

• Tester un parcours au clavier

  Tester l’accessibilité d’un site web avec méthode