WCAG 3.2.3 : Navigation cohérente

Ce que signifie cette règle

Le critère de succès 3.2.3 des WCAG — Navigation cohérente (Niveau AA) stipule que les composants de navigation répétés sur plusieurs pages d’un site web doivent apparaître dans le même ordre relatif chaque fois qu’ils sont rencontrés, sauf si l’utilisateur lui-même a déclenché un changement dans cet ordre. Le critère s’applique à tout ensemble de pages web qui partagent un objectif commun ou qui font partie du même site ou de la même application.

L’expression « même ordre relatif » est importante : les WCAG n’exigent pas que la navigation contienne toujours le même nombre d’éléments, ni qu’aucun autre élément ne puisse apparaître entre les éléments de navigation. Ce qui est exigé, c’est que la séquence des liens de navigation, telle qu’elle apparaît à un utilisateur se déplaçant dans l’interface, reste cohérente d’une page à l’autre. Par exemple, si votre navigation principale liste « Home », « Products », « About » et « Contact » dans cet ordre sur la page d’accueil, les mêmes éléments doivent apparaître dans la même séquence sur toute autre page où ce bloc de navigation existe.

Le critère couvre tous les mécanismes de navigation répétés : menus de navigation principaux du site, fils d’Ariane, groupes de liens en pied de page, menus latéraux, liens de contournement de la navigation, barres de recherche, et tout autre composant interactif qui aide un utilisateur à se déplacer sur un site. Il s’applique indépendamment du fait que ces composants soient implémentés comme repères <nav>, listes de liens <ul>, menus personnalisés enrichis avec ARIA, ou tout autre modèle de balisage.

Ce qui est considéré comme conforme : Les blocs de navigation apparaissent dans le même ordre relatif sur chaque page où ils sont répétés. Des éléments peuvent être ajoutés, mis en évidence ou marqués comme actifs (par exemple, le lien de la page actuelle est visuellement distingué), tant que la séquence globale ne change pas. Un réagencement initié par l’utilisateur — comme un tableau de bord personnalisable où l’utilisateur fait glisser des panneaux vers de nouvelles positions — est également conforme, car le changement provient de l’utilisateur.

Ce qui est considéré comme non conforme : Une navigation principale qui liste « Home → Products → Contact → About » sur la page d’accueil mais « Home → About → Products → Contact » sur une page de détail produit ne respecte pas le critère 3.2.3. De même, un site qui insère de manière conditionnelle des liens supplémentaires à des positions arbitraires dans la navigation en fonction d’une logique interne (sans action de l’utilisateur) serait non conforme.

Exception officielle : La spécification indique explicitement que l’exigence ne s’applique pas lorsque l’utilisateur a initié le changement d’ordre. Il s’agit de la seule exception normative. Les changements pilotés par le système, la logique serveur ou des algorithmes de personnalisation — non déclenchés directement par l’utilisateur — ne relèvent pas de cette exception.

Pourquoi c’est important

Une navigation cohérente est fondamentale pour l’accessibilité cognitive. Les utilisateurs qui s’appuient sur la mémoire spatiale et des schémas prévisibles pour s’orienter — y compris les personnes avec des handicaps cognitifs, des troubles de l’attention, des traumatismes crâniens ou un déclin cognitif lié à l’âge — dépendent fortement de l’hypothèse que la navigation d’un site sera au même endroit et dans le même ordre à chaque fois qu’ils la rencontrent. Lorsque la navigation se déplace de manière inattendue, ces utilisateurs doivent réapprendre la mise en page sur chaque page, ce qui augmente considérablement la charge cognitive et la probabilité d’erreurs ou d’abandon.

Pour les utilisateurs aveugles ou malvoyants qui naviguent avec des lecteurs d’écran (NVDA, JAWS, VoiceOver), une navigation cohérente réduit le temps passé à rechercher des repères connus. Un utilisateur de lecteur d’écran qui a mémorisé que le lien « Contact » est le quatrième élément de la navigation principale peut appuyer quatre fois sur la touche Tab sur n’importe quelle page pour l’atteindre — mais seulement si l’ordre est garanti comme restant le même. Un ordre incohérent détruit cette efficacité et oblige l’utilisateur à écouter l’intégralité de la navigation à chaque chargement de page.

Pour les utilisateurs avec des limitations motrices qui s’appuient sur la navigation au clavier uniquement, l’accès par contacteur ou le suivi oculaire, chaque pression de touche ou mouvement de tête supplémentaire a un coût réel. Une navigation prévisible réduit le nombre d’interactions nécessaires pour atteindre des destinations fréquemment visitées. Selon l’Organisation mondiale de la Santé, plus de 1,3 milliard de personnes dans le monde vivent avec une forme de handicap, dont beaucoup s’appuient sur des technologies d’assistance qui bénéficient directement d’interfaces cohérentes et prévisibles.

Pour les utilisateurs avec des troubles de la lecture tels que la dyslexie, le balayage d’une barre de navigation demande déjà un effort. Un positionnement et un ordre cohérents signifient qu’ils peuvent s’appuyer sur des repères visuels — position, forme, couleur — plutôt que de relire les libellés à chaque fois.

Un scénario concret du monde réel : imaginez un patient utilisant le site web d’un hôpital pour réserver des rendez-vous de suivi. La navigation sur la page d’accueil liste « Services », « Appointments », « Doctors » et « Contact » dans cet ordre. Le patient se rend sur la page de profil d’un médecin et cherche « Appointments » en deuxième position — mais sur cette page, la navigation a été réorganisée pour commencer par « Doctors » suivi de « Appointments ». Le patient, déjà stressé, doit rebalayer l’ensemble du menu. Pour un utilisateur avec un handicap cognitif ou une littératie limitée, cette friction peut faire la différence entre accomplir la tâche et abandonner complètement.

Au-delà de l’accessibilité, une navigation cohérente présente des bénéfices mesurables en SEO et en utilisabilité. Les robots d’indexation des moteurs de recherche parcourent les liens de navigation pour découvrir et indexer le contenu ; une structure de liens stable améliore l’efficacité d’exploration et l’équité du maillage interne. Les tests d’utilisabilité montrent de manière constante qu’une navigation prévisible réduit le temps d’accomplissement des tâches et les taux d’erreur pour tous les utilisateurs, pas seulement pour ceux en situation de handicap.

Règles Axe-core associées

Le critère WCAG 3.2.3 nécessite un test manuel. Il n’existe aucune règle axe-core automatisée capable de signaler un ordre de navigation incohérent, car les outils automatisés n’ont pas le contexte inter-pages nécessaire pour comparer les séquences de navigation. Un analyseur automatisé évalue une seule page isolément et ne peut pas observer si la navigation sur cette page diffère de la navigation sur vingt autres pages du même site.

• Comparaison manuelle inter-pages (pas d’ID de règle axe) : Les testeurs doivent visiter plusieurs pages au sein du même site et consigner manuellement l’ordre des éléments de navigation sur chaque page, puis comparer ces relevés. Les outils automatisés ne peuvent pas effectuer cette vérification car ils devraient analyser plusieurs pages simultanément, maintenir un état entre les chargements de page et appliquer un jugement sémantique pour déterminer quels éléments constituent le même composant de navigation — autant de tâches qui nécessitent un raisonnement contextuel humain.
• Pourquoi l’automatisation est insuffisante : Même les outils heuristiques qui signalent des problèmes liés à la navigation vérifient généralement la présence de repères de navigation (comme la règle axe landmark-one-main ou region), et non la cohérence de l’ordre entre les pages. La comparaison d’ordre nécessite une méthodologie d’audit à l’échelle du site, et non une analyse page par page. C’est pourquoi le critère 3.2.3 est classé comme nécessitant un examen manuel dans tous les principaux cadres de test d’accessibilité, y compris axe-core, Lighthouse et IBM Equal Access Checker.

Comment tester

1. Exécuter une analyse automatisée pour un contexte de base : Utilisez axe DevTools, Lighthouse ou une extension de navigateur sur des pages représentatives pour confirmer que les éléments de navigation sont correctement balisés comme repères <nav> ou avec role='navigation'. Bien que ces outils ne signalent pas les incohérences d’ordre, ils vous aident à identifier ce qui est traité comme navigation sur les différentes pages. Documentez tout problème de structure de repères avant de passer aux vérifications manuelles.
2. Sélectionner un échantillon de pages représentatif : Choisissez au moins cinq à dix pages provenant de différentes sections du site — page d’accueil, page de catégorie, page de détail produit ou d’article, page de formulaire et page de contact. Si le site comporte des milliers de pages, utilisez un échantillon stratifié couvrant tous les principaux gabarits. Notez l’URL et le type de page pour chacune.
3. Cartographier manuellement l’ordre de navigation : Sur chaque page de l’échantillon, ouvrez l’arborescence d’accessibilité du navigateur (Chrome DevTools → panneau Accessibility, ou Firefox Accessibility Inspector) et listez chaque lien au sein de la navigation principale dans l’ordre où ils apparaissent dans le DOM. Notez également l’ordre tel qu’il apparaît visuellement. Si le CSS réorganise les éléments visuellement (par exemple, en utilisant flex-direction: row-reverse ou des propriétés order), l’ordre visuel peut différer de l’ordre du DOM — les deux doivent être cohérents.
4. Comparer entre les pages : Placez vos listes d’ordre de navigation côte à côte. Signalez toute page où la séquence des éléments de navigation partagés diffère de la référence établie sur la page d’accueil. Notez quels éléments ont été déplacés et dans quelle direction.
5. Test de navigation au clavier (NVDA + Firefox) : Ouvrez NVDA, lancez Firefox et accédez à la page d’accueil. Appuyez sur D pour passer au repère suivant et localiser la navigation principale. Utilisez la touche Tab pour parcourir les liens de navigation et dites à voix haute ou notez l’ordre. Ensuite, accédez à une deuxième page (par exemple, une page d’article interne) et répétez. Écoutez tout changement dans la séquence d’annonce des liens.
6. Test avec lecteur d’écran (VoiceOver + Safari sur macOS) : Activez VoiceOver (Commande + F5), ouvrez Safari et utilisez le Web Rotor (Contrôle + Option + U) pour ouvrir le menu Liens ou Repères. Accédez à la navigation principale et notez l’ordre des éléments. Répétez sur au moins trois types de pages différents et comparez.
7. Test JAWS + Chrome : Ouvrez JAWS, lancez Chrome et appuyez sur R pour faire défiler les régions jusqu’à atteindre la navigation principale. Parcourez les liens avec Tab et consignez l’ordre. Répétez sur différents types de pages.
8. Vérifier les exceptions initiées par l’utilisateur : Si le site propose des fonctionnalités de personnalisation ou de configuration de la navigation, vérifiez que tout réagencement ne se produit qu’après une action explicite de l’utilisateur (par exemple, l’utilisateur clique sur « Customize Menu » et fait glisser des éléments). Confirmez que l’état réorganisé est ensuite conservé de manière cohérente — le nouvel ordre doit lui-même rester cohérent sur toutes les pages après que l’utilisateur l’a défini.

Comment corriger

Rendu côté serveur incohérent — Incorrect

<!-- Homepage navigation -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<!-- Product detail page navigation — order changed by CMS template -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
    <li><a href='/products'>Products</a></li>
  </ul>
</nav>

Rendu côté serveur incohérent — Correct

<!-- Shared navigation partial (e.g., _nav.html or a component) used on every page -->
<!-- The active page is indicated with aria-current, not by reordering -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/' aria-current='page'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- On the Products page, only aria-current moves — the order stays identical -->

Réorganisation visuelle en CSS créant une incohérence — Incorrect

<!-- DOM order: Home, Products, About, Contact -->
<!-- CSS on interior pages uses flex order to visually move Contact first -->
<style>
  /* Applied only on interior page templates */
  nav ul li:last-child { order: -1; }
</style>
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Visual order becomes Contact, Home, Products, About — inconsistent with homepage -->

Réorganisation visuelle en CSS créant une incohérence — Correct

<!-- Use consistent DOM order and consistent CSS across all templates -->
<!-- Do not use CSS 'order' property to rearrange navigation items differently per template -->
<nav aria-label='Main navigation'>
  <ul style='display:flex'>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Same DOM order and same CSS flex order on every page template -->

Navigation dynamique réorganisée par algorithme — Incorrect

<!-- JavaScript reorders nav links based on most-visited analytics without user action -->
<script>
  // Anti-pattern: fetches user behaviour data and reorders nav items automatically
  fetch('/api/user-nav-preferences').then(r => r.json()).then(order => {
    const nav = document.querySelector('nav ul');
    order.forEach(id => nav.appendChild(document.getElementById(id)));
  });
</script>
<nav aria-label='Main navigation'>
  <ul>
    <li id='nav-home'><a href='/'>Home</a></li>
    <li id='nav-products'><a href='/products'>Products</a></li>
    <li id='nav-about'><a href='/about'>About</a></li>
    <li id='nav-contact'><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Navigation dynamique réorganisée par algorithme — Correct

<!-- If personalisation is desired, require an explicit user action and keep order stable otherwise -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>
<!-- Personalisation button lets user reorder — change only applies after they interact -->
<button type='button' aria-controls='main-nav-list' id='customize-nav'>Customize Navigation Order</button>
<!-- The user-chosen order is then persisted consistently across all pages -->

Erreurs courantes

• Utiliser différents gabarits de CMS qui définissent chacun la navigation de manière indépendante, ce qui entraîne l’apparition progressive de différences subtiles d’ordre au fil du temps, à mesure que les gabarits sont mis à jour séparément plutôt qu’à partir d’un composant ou fragment partagé unique.
• Promouvoir des éléments de navigation « mis en avant » ou « saisonniers » à différentes positions en fonction de campagnes marketing sans s’assurer que le reste de l’ordre de navigation reste inchangé — par exemple, déplacer temporairement « Sale » en deuxième position sur certaines pages et en cinquième position sur d’autres.
• Utiliser la propriété CSS order, flex-direction: row-reverse ou le placement CSS Grid pour réorganiser visuellement les éléments de navigation différemment selon les gabarits de page, créant un décalage entre l’ordre visuel (vu par les utilisateurs voyants) et l’ordre du DOM (suivi par les utilisateurs au clavier et les lecteurs d’écran).
• Insérer des éléments de navigation contextuels à des positions arbitraires — par exemple, ajouter un lien « Back to Category » comme deuxième élément sur les pages produit mais pas sur les autres pages, décalant ainsi tous les éléments suivants d’une position et rompant la séquence attendue.
• Autoriser des plateformes d’A/B testing ou d’analytique à réorganiser les liens de navigation dans le cadre de variantes d’expériences, sans considérer que cette réorganisation s’applique de manière incohérente entre les pages et les sessions.
• Considérer à tort que le fil d’Ariane est exempté de ce critère alors qu’il s’agit en réalité d’un mécanisme de navigation répété — des fils d’Ariane qui apparaissent à des positions différentes par rapport aux autres éléments de la page selon les gabarits violent également le critère 3.2.3.
• Réorganiser la navigation en pied de page différemment de la navigation principale lorsque les liens du pied de page dupliquent la navigation principale — si les deux apparaissent sur chaque page, ils doivent tous deux maintenir un ordre cohérent indépendamment et l’un par rapport à l’autre.
• Appliquer des améliorations de navigation pilotées par JavaScript qui réorganisent les éléments en fonction de la position de défilement, de la taille de la fenêtre ou des données de session sans initiation par l’utilisateur — par exemple, un méga-menu qui fait remonter dynamiquement différentes catégories de premier niveau selon la section du site dans laquelle se trouve l’utilisateur.
• Ne pas auditer la cohérence de la navigation après une refonte de site ou une migration de CMS, en supposant que les développeurs reproduiront naturellement l’ordre d’origine alors qu’en réalité différents types de pages sont reconstruits de zéro par différentes équipes.
• Confondre « navigation cohérente » avec « même navigation sur chaque page » — certaines équipes concluent à tort que l’ajout ou la suppression d’éléments de navigation pour certains rôles utilisateurs (par exemple, connecté vs invité) viole le critère 3.2.3. Ce n’est pas le cas, tant que l’ordre relatif des éléments partagés reste inchangé.

Lien avec la réglementation d’accessibilité de la Turquie

La Circulaire présidentielle n° 2025/10 de la Turquie, publiée au Journal officiel (n° 32933) le 21 juin 2025, établit des obligations d’accessibilité contraignantes pour un large éventail d’entités publiques et privées exploitant des services numériques en Turquie. La Circulaire impose la conformité à des normes d’accessibilité reconnues au niveau international — les WCAG 2.2 Niveau AA servant de référence technique principale — et lie la conformité à l’Erişilebilirlik Logosu (Logo d’accessibilité), une marque de certification délivrée par le ministère de la Famille et des Services sociaux aux entités qui atteignent le seuil d’accessibilité requis.

Le critère WCAG 3.2.3 Navigation cohérente est un critère de Niveau AA, ce qui signifie qu’il s’agit d’une exigence obligatoire pour les entités souhaitant obtenir l’Erişilebilirlik Logosu. Les organisations qui ne fournissent pas une navigation cohérente sur l’ensemble de leurs services numériques ne satisferont pas au profil complet de conformité AA requis pour la certification, quel que soit leur niveau de performance sur les autres critères.

Les types d’entités suivants sont couverts par la Circulaire présidentielle 2025/10 et doivent donc considérer la conformité au critère 3.2.3 comme une obligation légale plutôt qu’une simple recommandation de bonnes pratiques :

• Les institutions publiques et organismes gouvernementaux à tous les niveaux, y compris les ministères, les municipalités et les organismes affiliés à l’État, dont les sites web et portails numériques doivent être navigables de manière cohérente dans toutes les sections.
• Les plateformes de commerce électronique opérant en Turquie, où la cohérence de la navigation est particulièrement critique étant donné que les utilisateurs se déplacent entre la page d’accueil, les pages de catégorie, de produit, de panier et de paiement — qui partagent généralement toutes la même barre de navigation.
• Les banques et institutions financières réglementées par la législation bancaire turque, dont les portails de banque en ligne et les sites d’information doivent fournir une navigation prévisible pour servir tous les clients, y compris ceux avec des limitations cognitives ou motrices.
• Les hôpitaux et prestataires de soins de santé, où les patients — souvent en situation de stress — s’appuient sur une navigation cohérente pour trouver la prise de rendez-vous, les résultats d’examens et les informations de contact d’urgence sans friction cognitive.
• Les entreprises de télécommunications comptant 200,000 abonnés ou plus, dont les portails clients, sites d’assistance et interfaces de gestion de compte doivent maintenir une navigation cohérente sur potentiellement des milliers de pages et de gabarits orientés utilisateur.
• Les agences de voyage et entreprises de transport privé, où les parcours de réservation en plusieurs étapes couvrant la recherche, la sélection, les informations passager et les pages de paiement doivent présenter la navigation dans un ordre cohérent tout au long du parcours.
• Les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE), dont les sites web s’adressent aux élèves, aux parents et au personnel — y compris des personnes avec des troubles d’apprentissage qui s’appuient fortement sur une navigation prévisible pour accéder aux ressources éducatives.

Pour les organisations en Turquie qui créent ou auditent des services numériques, le critère 3.2.3 doit être intégré au processus d’assurance qualité dès la phase de conception des gabarits et des composants. L’utilisation d’un composant de navigation partagé rendu à partir d’une source de vérité unique — qu’il s’agisse d’une inclusion côté serveur, d’un composant de framework front-end ou d’un élément global dans un CMS headless — est à la fois l’approche technique la plus fiable et la posture de conformité la plus défendable au regard des exigences de la Circulaire. Les audits d’accessibilité soumis dans le cadre du processus de demande de l’Erişilebilirlik Logosu doivent inclure une vérification de l’ordre de navigation inter-pages comme étape de test documentée.