Commencez par les tâches et une petite architecture de l'information
L'architecture de l'information est la manière dont le contenu et les fonctions sont regroupés, nommés et reliés. Dressez la liste des tâches des visiteurs, puis cartographiez pour chaque tâche la page de départ, la page suivante et l'état final réussi. Cela montre si un élément de menu est utile ou s'il s'agit d'un libellé interne que les visiteurs doivent décoder. Gardez la navigation principale axée sur les sections qui initient ces tâches.
La navigation n'est pas un plan du site. GOV.UK conseille d'énumérer des sections de premier niveau utiles plutôt que chaque partie d'un service. Lorsqu'un parcours exige un ordre, indiquez-le dans le contenu ou une liste de tâches au lieu de faire deviner cet ordre à partir d'un menu global.
Regroupez les pages lorsque les visiteurs attendent la même réponse ou le même usage, pas parce qu'une équipe en est propriétaire.
Utilisez des pages d'atterrissage et des liens contextuels pour les détails plutôt qu'un en-tête dense.
Utiliser des libellés qui prédisent la destination
Un libellé est une promesse sur ce qui suit. Préférez des noms familiers tels que « Tarifs », « Documentation », « Obtenir de l'aide » ou « Gérer le compte » quand ils correspondent à la destination. Évitez les libellés vagues comme « Ressources » ou « Explorer » sauf si les visiteurs peuvent en prédire le contenu. Maintenez la cohérence du vocabulaire et de l'ordre.
Google recommande des textes de lien concis et pertinents, compréhensibles hors de leur contexte. Les « cliquez ici » génériques et les liens bourrés de mots-clés ne remplissent pas cette fonction. Donnez à un contrôle uniquement icône un nom accessible qui décrit son action.
Utilisez « Voir les offres » plutôt que « En savoir plus » quand la destination est une page d'offres.
Indiquez visuellement et programmatiquement la destination active ; W3C décrit aria-current=page pour la page affichée.
Rendre les destinations crawlables et structurellement claires
Une destination de navigation devrait normalement être une ancre HTML avec un href qui résout une adresse web réelle. Google indique qu'il peut en général explorer cette forme, y compris les ancres insérées dynamiquement lorsque le markup rendu conserve cette structure. Un gestionnaire de clics ou un attribut personnalisé seul n'est pas un substitut fiable. Inspectez le rendu final, pas seulement le code source du framework.
Utilisez une structure sémantique autour des navigations principales. W3C recommande un élément nav et, pour une navigation de site ordinaire, une liste. Si une page contient plusieurs régions de navigation, étiquetez chacune afin qu'un utilisateur de lecteur d'écran puisse distinguer la navigation principale du pied de page ou de la navigation locale.
Confirmez que les destinations importantes sur desktop et mobile ont des ancres et des valeurs href après le rendu côté client.
L'inspection d'URL fournit des informations sur l'exploration, l'indexation et la diffusion par Google ; elle ne prouve pas que les visiteurs peuvent trouver une page.
Concevoir le menu mobile comme une interaction complète
La navigation responsive peut se replier, mais les destinations qui restent doivent conserver le même libellé, ordre et cible sur toutes les tailles d'écran. W3C autorise de replier ou masquer des éléments de sous-navigation tout en appelant à la cohérence. Ne rendez pas un itinéraire critique uniquement accessible sur desktop parce que l'en-tête est chargé ; déplacez le contenu de moindre priorité ou reconsidérez la hiérarchie.
Pour un menu affiché/masqué, utilisez un bouton pour contrôler le groupe de liens et communiquez s'il est ouvert. L'exemple disclosure-navigation du W3C utilise aria-expanded et aria-controls et documente Tab, Shift+Tab et Escape. C'est un guide ; testez votre composant avec les combinaisons que votre audience utilise.
Quand la page parente et ses liens enfants sont tous deux nécessaires, distinguez le lien de la page du contrôle qui l'ouvre.
Tout ce qui est révélé par le survol au pointeur doit être découvrable au clavier et au toucher.
Soutenir l'orientation et la navigation au clavier
L'accès au clavier n'est pas une finition secondaire. WCAG 2.1 Success Criterion 2.1.1 exige que la fonctionnalité soit exploitable via une interface clavier sauf pour les saisies dépendantes d'un parcours. Dans un en-tête, les visiteurs doivent pouvoir Tabuler entre les contrôles, voir la mise au point, activer les liens et boutons et s'en éloigner sans être piégés.
Les liens répétés dans l'en-tête peuvent rendre la traversée des pages lente. Un lien de saut (skip link) situé près du début donne aux utilisateurs clavier un chemin vers le contenu principal. GOV.UK explique qu'il est visuellement caché jusqu'à ce que l'utilisation du clavier l'active. Testez qu'il arrive sur une cible significative.
Ne supprimez pas l'indicateur de focus du navigateur sans une alternative claire qui reste visible lors d'un zoom.
Utilisez Tab, Shift+Tab, Enter, Space et Escape depuis l'en-tête jusqu'à la page de destination.
Tester la trouvabilité avant et après la mise en production
Demandez à des personnes représentatives d'accomplir une tâche réaliste, comme trouver des instructions d'annulation ou comparer des offres. Observez où elles s'attendent à aller, quels libellés elles lisent mal et si elles préfèrent la recherche parce que la navigation a échoué. Ne les guidez pas vers le libellé prévu. Enregistrez chaque obstacle et le plus petit changement susceptible de le supprimer.
Associez les tests de tâches à des vérifications techniques. Les Easy Checks du W3C recommandent de tester sans souris, y compris la visibilité du focus, l'ordre des tabulations, les pièges clavier et les menus déroulants. Répétez les tâches clés à des largeurs étroites et avec des tailles de texte augmentées. Les contrôles automatisés peuvent signaler des problèmes de balisage, mais ne peuvent pas établir qu'un libellé est compréhensible.
Enregistrez le point d'arrivée prévu et l'appareil ou la méthode d'entrée supportée avant le test.
Testez l'ancien et le nouveau itinéraire sur les mêmes tâches plutôt que de vous fier à la préférence des parties prenantes.
Considérer les changements de navigation comme des versions sensibles à la disponibilité
Un en-tête peut se charger alors qu'un parcours critique est effectivement indisponible : une page de paiement, d'identification, d'assistance ou de documentation peut être derrière un état cassé, un lien obsolète ou une mauvaise redirection. Avant la mise en production, inventairez les destinations critiques, testez les itinéraires desktop et mobile et confirmez que les liens rendus atteignent la page prévue. Utilisez des environnements autorisés pour les chemins authentifiés ou régionaux.
Le rôle de SIU est la remédiation proactive : effectuez un préflight, vérifiez les chemins essentiels après déploiement et rendez la correction réversible. Conservez une configuration de menu versionnée, nommez la personne pouvant la restaurer et validez les chemins restaurés. Cela limite l'impact d'une publication ; cela ne remplace pas la recherche d'utilisabilité ni la surveillance du statut en direct.
Bloquez la publication lorsqu'une destination critique est manquante, incorrecte ou inaccessible au clavier et au toucher.
Documentez la configuration antérieure, le responsable, le déclencheur et les étapes de validation avant la restructuration.