Menu mobile : tester les sous-menus, le retour et le clavier

Les quatre points à retenir

• Définissez une navigation témoin et un état de départ identique pour chaque essai.
• Séparez ouverture, changement de niveau, fermeture et retour du navigateur.
• Contrôlez au clavier les éléments accessibles et la position du focus après chaque transition.
• Signalez un défaut avec des étapes numérotées, un résultat attendu, un résultat observé et un environnement précis.

Préparer un scénario que deux personnes peuvent reproduire

Prenons « Atelier des Rives », une entreprise entièrement fictive utilisée pour les essais. Son site possède quatre entrées : Accueil, Prestations, Réalisations et Contact. Prestations ouvre un deuxième niveau avec Réparation et Installation. Pour ce protocole, le libellé Prestations et son bouton d’ouverture sont distincts si le libellé mène aussi à une page. Cela permet de vérifier séparément la destination et le dépliage.

La version témoin utilise un panneau non modal : le reste de la page demeure disponible. Le bouton Menu l’ouvre ; un bouton Fermer le referme. Dans le deuxième niveau, Retour aux rubriques réaffiche la liste principale. Ces choix constituent notre contrat de recette, pas une obligation graphique universelle. Si votre interface utilise un véritable dialogue modal ou des sous-listes qui se déplient sur place, adaptez les attentes avant de commencer.

Inscrivez l’adresse de la page, la version livrée, le navigateur, le système, la largeur et la hauteur de la fenêtre. Notez aussi le zoom et la présence éventuelle d’un clavier externe. Commencez en haut de page, menu fermé, sans connexion administrateur. Les mêmes essais seront ensuite repris depuis une page intérieure et après défilement. Dans une création ou refonte de site web, ce scénario peut devenir une condition explicite de livraison.

Décrire le parcours d’écrans avant de cliquer

Voici le parcours de référence. Il sert de support commun au responsable du site et à la personne qui corrige le menu. Les numéros désignent des étapes, pas des pages supplémentaires à créer.

1. Page d’accueil, panneau fermé. Le bouton Menu est visible. Les liens des niveaux masqués ne participent pas au parcours de tabulation.
2. Premier niveau ouvert. Accueil, Prestations, Réalisations et Contact sont disponibles. Un moyen de fermeture reste accessible.
3. Rubrique Prestations ouverte. Réparation et Installation apparaissent ; Retour aux rubriques indique clairement le niveau précédent.
4. Retour au premier niveau. Les rubriques principales réapparaissent. Au clavier, le focus revient sur le bouton qui ouvrait Prestations dans notre version témoin.
5. Page Installation atteinte. Le titre et l’adresse correspondent au lien choisi. Le panneau ne masque pas durablement le nouveau contenu.
6. Retour du navigateur. La page précédente redevient utilisable, sans écran assombri résiduel ni défilement définitivement verrouillé.

Ce parcours évite une confusion fréquente : Retour aux rubriques agit dans le panneau, alors que Retour du navigateur agit sur l’historique. Si ouvrir un sous-menu ne change pas l’adresse et n’ajoute pas d’entrée d’historique, le navigateur ne doit pas être supposé remonter d’un niveau. Documentez le comportement réellement choisi au lieu de déclarer ce fonctionnement défectueux par principe.

Faire une première passe au doigt

Sur un téléphone disponible pour la recette, ouvrez Menu, puis Prestations. Touchez le libellé et le bouton voisin séparément. Vérifiez que chacun déclenche son action prévue sans exiger un premier toucher pour simuler un survol, puis un deuxième pour naviguer. Une rubrique qui renvoie immédiatement vers sa page ne permet pas de juger l’accès au sous-menu : il faut tester les deux zones.

Descendez jusqu’au dernier lien du panneau. Si la liste dépasse l’écran, elle doit rester parcourable et permettre de retrouver la fermeture. Répétez après avoir fait défiler la page avant l’ouverture. Fermez, puis essayez de défiler le contenu : un verrouillage conservé après fermeture constitue un défaut concret, même lorsque tous les liens fonctionnent.

Testez ensuite une rotation du téléphone et le passage à une largeur où le menu de bureau apparaît. Revenez à la largeur initiale. Recherchez surtout les états incohérents : panneau invisible mais voile présent, deux navigations superposées, lien actif appartenant à une liste cachée. L’émulation du navigateur aide à explorer les dimensions ; elle ne remplace pas cette passe tactile sur un appareil réel.

Refaire le trajet sans souris et suivre le focus

Le focus désigne l’élément qui recevra la prochaine action du clavier. Depuis le début du document, utilisez Tab pour atteindre Menu, puis Maj + Tab pour vérifier le trajet inverse. Activez le bouton avec Entrée, recommencez avec Espace après réinitialisation, puis parcourez les liens affichés. Sur un lien ordinaire, utilisez Entrée pour naviguer ; n’imposez pas Espace comme commande d’activation des liens.

Le repère visuel doit permettre de suivre cette progression. Le document WAI sur le critère 2.4.7, visibilité du focus explique cette exigence pour une utilisation au clavier ; il ne prescrit pas une couleur unique. Notre test consiste à identifier l’élément actif sans deviner sa position à partir du nombre de pressions.

Dans notre panneau non modal, Tab peut sortir de la navigation : nous n’attendons pas une boucle forcée. En revanche, le panneau ne doit pas rendre l’élément suivant introuvable sous une couche opaque. Le critère WCAG 2.4.11, focus non masqué au minimum concerne notamment les éléments entièrement cachés par un contenu créé par le site. Pour cette recette, nous choisissons une cible pratique plus confortable : garder l’élément actif entièrement visible.

Ouvrez Prestations, atteignez Installation, puis appuyez sur Échap. Notre contrat prévoit la fermeture du sous-niveau et le retour du focus sur son bouton d’ouverture ; une seconde pression ferme le panneau. Testez également Fermer depuis le clavier. Après fermeture, le focus doit retrouver un point utilisable, ici Menu, et ne pas rester dans un élément devenu invisible.

L’exemple WAI de navigation avec dépliage fournit un repère : boutons de dépliage, états ouvert ou fermé, tabulation et fermeture avec Échap. Les flèches y sont facultatives ; une navigation de site ordinaire n’a pas à recevoir le rôle ARIA menu. C’est un exemple pédagogique, pas un composant prêt à copier en production : la compatibilité avec les navigateurs et technologies d’assistance doit être testée.

Consigner une matrice courte de résultats

Cette matrice complète les étapes détaillées. Écrivez « non testé » quand le matériel manque ; une case vide ne signifie pas réussite. Les attentes décrivent notre panneau témoin et doivent être adaptées si votre interface suit un autre contrat.

Ajoutez une passe avec un lecteur d’écran disponible : notez son nom, sa version et le navigateur associé. Vérifiez que le bouton est identifiable, que son état ouvert ou fermé est compréhensible et que les liens cachés ne sont pas proposés comme s’ils étaient visibles. Un résultat satisfaisant sur une combinaison ne certifie pas toutes les autres. Un accompagnement WordPress peut aider à relier les défauts observés aux composants réellement utilisés.

Rédiger un signalement exploitable avec attendu et observé

Évitez « le menu bugue sur mobile ». Ce message ne dit ni où commencer, ni ce qui échoue. L’exemple suivant est entièrement fictif : il ne décrit aucun client, aucun test exécuté sur Blue Strat et aucun incident mesuré.

Objet

Après Retour aux rubriques, le focus reste sur Installation masqué.

Environnement

Préproduction fictive, version recette A ; Firefox sur ordinateur, fenêtre 390 × 844 pixels CSS, zoom 100 %, clavier seul. Versions exactes du navigateur et du système à joindre au ticket réel.

Précondition

Page d’accueil rechargée, menu fermé, aucun autre panneau ouvert.

1. Atteindre Menu avec Tab et l’ouvrir avec Entrée.
2. Atteindre le bouton Prestations et ouvrir le deuxième niveau.
3. Atteindre Retour aux rubriques et l’activer avec Entrée.
4. Observer le repère de focus puis presser Tab une fois.

Attendu : les rubriques principales sont visibles ; le focus revient sur le bouton Prestations et la tabulation continue dans le premier niveau. Observé dans cet exemple inventé : le premier niveau s’affiche, mais le focus reste sur Installation caché ; la pression suivante atteint un autre contrôle invisible. Impact : une personne au clavier perd son point de repère. Joindre une courte vidéo et les étapes en texte, sans identifiant ni donnée personnelle.

Précisez si le problème se reproduit après rechargement, sur une page intérieure et dans une seconde largeur. Si ces variantes ne sont pas testées, dites-le. Ne concluez pas « incompatibilité générale » après une seule combinaison. Séparez aussi observation et hypothèse : un conflit de script peut être une piste, mais la position du focus constitue la preuve à transmettre.

Décider de la correction et refaire les essais voisins

Traitez d’abord les défauts qui empêchent d’atteindre une destination, de fermer le panneau ou de récupérer la page. Un espacement imparfait mérite un ticket distinct, mais ne doit pas détourner la recette d’un lien inaccessible. Confiez la correction avec le contrat attendu et les preuves, sans imposer une extension supplémentaire avant le diagnostic. Un besoin réellement spécifique peut relever d’un module WordPress adapté au site.

Après correction, reprenez les mêmes étapes depuis l’état initial, puis testez les chemins voisins : autre rubrique, fermeture directe, retour du navigateur et changement de largeur. Une correction validée seulement à la souris ne clôt pas un défaut trouvé au clavier. Conservez la version corrigée et le résultat de chaque essai ; une capture finale seule ne démontre pas le bon déroulement des transitions.

Terminez le parcours sur la page réellement attendue. Si Contact est une destination importante, contrôlez son chargement et l’accès aux champs, sans envoyer de demande pendant cette recette. Le contrôle de la navigation et celui du formulaire sont deux tâches différentes ; le guide pour qualifier une demande de devis sans décourager permet de préparer la seconde.

Votre prochaine action peut rester simple : choisir une page, écrire les six étapes du parcours et les faire exécuter par une autre personne. Si elle peut reproduire le défaut et vérifier sa disparition sans explication orale, le protocole remplit son rôle. Pour faire examiner un menu mobile, préparez ce compte rendu et l’environnement concerné plutôt qu’une liste générale de préférences graphiques.

Sources et repères techniques

• W3C WAI, exemple de navigation avec dépliage : repères d’interaction et limites de l’exemple.
• W3C WAI, comprendre le critère 2.4.7 : visibilité du focus clavier.
• W3C WAI, comprendre le critère 2.4.11 : élément actif non entièrement masqué.

Le protocole et le ticket fictif sont des propositions pratiques propres à cet article. Cette recette ciblée ne constitue pas un audit complet de conformité.

Auteur

Nicolas Tissot

Gérant de Blue Strat. WordPress, développement web et référencement pour les artisans, TPE et PME.

Découvrir Nicolas Tissot