WCAG 2.4.8 : Emplacement

Ce que signifie cette règle

WCAG 2.4.8 Location est un critère de niveau AAA relevant du principe « Opérable ». Il stipule : « Des informations sur l’emplacement de l’utilisateur au sein d’un ensemble de pages Web sont disponibles. » Concrètement, cela signifie que votre site Web doit fournir des signaux clairs et persistants qui indiquent aux utilisateurs exactement où ils se trouvent dans la structure globale du site à tout moment.

Ce critère s’applique chaque fois qu’un site Web est constitué de plusieurs pages organisées dans une hiérarchie ou une séquence significative — par exemple, un site e-commerce avec des catégories, des sous-catégories et des pages produit, ou un portail gouvernemental avec des ministères et des sous-sections. Si un utilisateur arrive sur une page, il doit pouvoir répondre à la question « Où suis-je sur ce site ? » sans avoir à deviner ni à se fier uniquement à sa mémoire.

Les techniques acceptables pour satisfaire ce critère incluent, sans s’y limiter :

• Fils d’Ariane (breadcrumbs) — une aide à la navigation qui montre le chemin depuis la page d’accueil du site jusqu’à la page actuelle (par exemple, Home > Products > Laptops > 15-inch Models).
• Plans de site — une page ou un panneau dédié qui affiche la structure globale du site et met en évidence ou marque l’emplacement actuel.
• Liens de navigation surlignés ou visuellement distincts — des menus de navigation qui marquent clairement la section ou la page active, souvent complétés par un attribut aria-current pour les utilisateurs de technologies d’assistance.
• Étapes numérotées dans un processus en plusieurs étapes — des indicateurs tels que « Step 2 of 5 » dans un tunnel de commande ou un assistant de formulaire qui communiquent la position séquentielle.

Une page répond à ce critère si au moins un mécanisme fiable est disponible pour informer l’utilisateur de son emplacement actuel dans la structure du site. Une page échoue si aucun mécanisme de ce type n’existe — par exemple, si la barre de navigation n’a aucune indication visuelle ou programmatique de la page actuelle, s’il n’y a pas de fil d’Ariane et qu’aucun indicateur d’étape n’est affiché.

Il est important de noter que WCAG 2.4.8 n’impose pas une technique spécifique ; il exige qu’un indicateur d’emplacement efficace soit présent. Cependant, pour que l’indicateur soit réellement accessible, il doit aussi être perceptible par les technologies d’assistance telles que les lecteurs d’écran, et pas seulement visuellement apparent pour les utilisateurs voyants. Cela signifie que des indicateurs purement visuels (comme un lien en gras sans changement d’intitulé accessible) peuvent être insuffisants s’ils ne sont pas exposés de manière programmatique.

Il n’existe pas d’exceptions officielles prévues par les WCAG pour ce critère, au-delà de la compréhension générale selon laquelle il s’applique aux ensembles de pages liées. Une page Web autonome qui ne fait pas partie d’un ensemble plus vaste n’a pas besoin de satisfaire ce critère, puisqu’il n’y a pas « d’emplacement dans un ensemble » à communiquer.

Pourquoi c’est important

Savoir où l’on se trouve dans un environnement numérique est un besoin d’orientation fondamental que la plupart des utilisateurs considèrent comme acquis — jusqu’à ce que les repères soient absents. WCAG 2.4.8 traite d’un obstacle réel et répandu, rencontré par plusieurs groupes d’utilisateurs distincts.

Les utilisateurs ayant des handicaps cognitifs sont parmi les plus fortement impactés. Des conditions telles que le trouble déficitaire de l’attention, les troubles de la mémoire et les lésions cérébrales acquises peuvent rendre difficile le suivi de son parcours sur un site complexe. Sans fil d’Ariane ou signal similaire, un utilisateur peut se désorienter, ne plus savoir comment revenir à une catégorie parente ou ne pas comprendre comment la page actuelle se rapporte au contenu déjà consulté. Selon l’Organisation mondiale de la Santé, plus d’un milliard de personnes dans le monde vivent avec une forme de handicap, et les déficiences cognitives représentent une part significative et souvent mal desservie de cette population.

Les utilisateurs de lecteurs d’écran — qui sont généralement aveugles ou malvoyants — s’appuient fortement sur la structure programmatique pour comprendre le contexte de la page. Un utilisateur voyant peut jeter un coup d’œil à un lien de navigation surligné ou à un élément de fil d’Ariane en gras pour s’orienter instantanément. Un utilisateur de lecteur d’écran, en revanche, doit interpréter la page via une sortie audio séquentielle. Sans attribut aria-current="page" sur le lien de navigation actif ou sans fil d’Ariane correctement structuré avec des libellés accessibles, il ne reçoit aucun signal d’orientation équivalent et peut devoir naviguer longuement simplement pour déterminer où il se trouve.

Les utilisateurs ayant des déficiences motrices qui naviguent au clavier, via un contacteur ou des dispositifs de suivi oculaire bénéficient des indicateurs d’emplacement car ils réduisent la nécessité d’une navigation redondante et pénible. Si un utilisateur sait déjà qu’il se trouve dans la section « Support » d’un site d’entreprise, il n’a pas besoin de rebalayer toute la structure de navigation à chaque chargement de page.

Considérez un scénario concret : une personne atteinte de démence à un stade précoce navigue sur le portail en ligne d’une banque turque pour trouver des informations sur les taux hypothécaires. Elle clique sur plusieurs pages et ne sait plus si elle se trouve toujours dans la section banque de détail ou si elle a basculé dans la banque d’entreprise. Sans fil d’Ariane ni élément de navigation surligné indiquant clairement la section actuelle, elle peut fermer le navigateur par frustration ou commettre une erreur coûteuse — comme demander le mauvais produit. Un fil d’Ariane simple et bien implémenté (par exemple, Ana Sayfa > Bireysel Bankacılık > Krediler > Konut Kredisi) résoudrait immédiatement cette confusion.

Au-delà de l’accessibilité, les indicateurs d’emplacement offrent des bénéfices mesurables en termes d’ergonomie et de SEO. Les données structurées de type fil d’Ariane (en utilisant Schema.org BreadcrumbList) peuvent apparaître directement dans les résultats de recherche Google sous forme d’extraits enrichis, améliorant les taux de clic. Une structure de site claire réduit également les taux de rebond, car les utilisateurs qui comprennent où ils se trouvent sont plus susceptibles d’explorer du contenu connexe plutôt que d’abandonner le site.

Règles Axe-core associées

WCAG 2.4.8 nécessite des tests manuels car les outils automatisés ne peuvent pas déterminer de manière fiable si un mécanisme d’emplacement est présent, pertinent et accessible dans tous les contextes. Aucune règle axe-core ne correspond directement à ce critère. Voici pourquoi l’automatisation est insuffisante et ce que l’évaluation manuelle doit couvrir :

• Présence d’un mécanisme d’emplacement (manuel) — Un analyseur automatisé peut détecter si un élément de fil d’Ariane existe dans le DOM, mais il ne peut pas déterminer si ce fil d’Ariane reflète fidèlement l’architecture de l’information du site, s’il est présent sur chaque page de l’ensemble ou s’il s’agit du type d’indicateur d’emplacement approprié pour le modèle de navigation du site. Un outil peut trouver un élément <nav aria-label="breadcrumb"> et ne signaler aucun problème, même si le fil d’Ariane n’apparaît que sur certaines pages ou contient une hiérarchie incorrecte.
• Exactitude et exhaustivité (manuel) — Les outils automatisés ne peuvent pas vérifier que l’information d’emplacement est exacte. Un fil d’Ariane qui affiche toujours « Home > Current Page » quel que soit le niveau réel dans la hiérarchie passerait un scan automatisé mais échouerait à ce critère, car il ne représente pas fidèlement l’emplacement de l’utilisateur dans l’ensemble de pages.
• Exposition programmatique (partiellement automatisée) — Bien que axe-core puisse signaler l’absence d’attributs aria-current sur les liens de navigation dans certaines configurations, il ne peut pas déterminer de manière concluante si cette absence constitue une violation de 2.4.8 sans comprendre la structure globale du site et le rôle de chaque élément de navigation.
• Cohérence à travers l’ensemble de pages (manuel) — Un mécanisme d’emplacement doit être disponible sur l’ensemble des pages concernées, et pas seulement sur certaines. Les analyses automatisées évaluent généralement une page à la fois et ne peuvent pas vérifier si un mécanisme est présent de manière cohérente sur tout un site ou une section.

Comment tester

1. Identifier l’ensemble de pages : Déterminez si la page testée appartient à un ensemble de pages liées avec une hiérarchie définie (par exemple, une structure de navigation à plusieurs niveaux, un assistant étape par étape ou une bibliothèque de contenu catégorisée). Si la page est un document autonome, ce critère peut ne pas s’appliquer.
2. Lancer une analyse automatisée comme base : Utilisez axe DevTools (extension de navigateur) ou Lighthouse dans Chrome DevTools pour lancer un audit d’accessibilité. Bien qu’aucun de ces outils n’audite directement 2.4.8, recherchez les problèmes connexes tels que l’absence d’attributs aria-current sur les liens de navigation, les repères <nav> non étiquetés et l’absence de structure de fil d’Ariane. Ces résultats soutiennent — mais ne remplacent pas — la revue manuelle.
3. Inspecter visuellement la présence d’un mécanisme d’emplacement : Recherchez un fil d’Ariane, un lien actif surligné ou visuellement distinct dans la navigation, un compteur d’étapes ou un lien vers un plan de site. Vérifiez que le mécanisme reflète fidèlement la position de la page actuelle dans la hiérarchie du site.
4. Tester avec un lecteur d’écran — NVDA + Firefox : Ouvrez NVDA, accédez à la page et appuyez sur D pour parcourir les repères. Repérez le ou les repères de navigation et écoutez toute indication de la page ou section actuelle. Vérifiez si l’élément de navigation actif est annoncé différemment (par exemple, « current page » ou similaire, généralement transmis via aria-current="page"). Parcourez le fil d’Ariane s’il est présent et vérifiez que chaque niveau est annoncé avec son texte de lien et que l’emplacement actuel est clairement identifié.
5. Tester avec VoiceOver + Safari (macOS/iOS) : Activez VoiceOver (Command + F5), accédez au fil d’Ariane ou à la navigation principale en utilisant VO + U pour ouvrir le Rotor, puis sélectionnez « Links » ou « Landmarks ». Écoutez comment l’élément de navigation actif ou l’élément actuel du fil d’Ariane est annoncé. Vérifiez que l’emplacement actuel se distingue des autres éléments de navigation.
6. Tester avec JAWS + Chrome : Utilisez Insert + F7 pour ouvrir la liste des liens et Insert + F6 pour ouvrir la liste des titres. Accédez au fil d’Ariane ou à la zone de navigation et confirmez que la page ou section actuelle est identifiable de manière programmatique. Vérifiez que aria-current est lu à voix haute (JAWS annonce cet attribut comme « current » pour l’élément concerné).
7. Tester sur plusieurs pages de l’ensemble : Naviguez à travers au moins trois à cinq pages au sein de la même section ou hiérarchie et confirmez que le mécanisme d’emplacement se met correctement à jour sur chaque page et qu’il est présent de manière cohérente dans tout l’ensemble.
8. Inspecter le DOM : Utilisez les DevTools du navigateur pour vérifier que les liens du fil d’Ariane ont des noms accessibles descriptifs, que l’élément actuel utilise aria-current="page" (pour la page actuelle) ou aria-current="true" (pour l’étape actuelle dans un processus), et que le fil d’Ariane est encapsulé dans un élément <nav> avec une étiquette accessible telle que aria-label="Breadcrumb".

Comment corriger

Navigation par fil d’Ariane manquante — Incorrect

<!-- No breadcrumb or location indicator present.
     Users have no way to determine their location in the site hierarchy. -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Navigation par fil d’Ariane manquante — Correct

<!-- A breadcrumb nav is added above the main content.
     aria-label distinguishes it from main navigation.
     aria-current="page" marks the current location for screen readers.
     The list structure communicates hierarchy. -->
<nav aria-label='Breadcrumb'>
  <ol>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
    <li><a href='/products/laptops/15-inch' aria-current='page'>15-inch Laptops</a></li>
  </ol>
</nav>
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Lien de navigation actif sans indicateur programmatique — Incorrect

<!-- The active link is styled differently in CSS, but there is no
     programmatic signal. Screen reader users cannot distinguish it
     from the other navigation links. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Lien de navigation actif sans indicateur programmatique — Correct

<!-- aria-current="page" is added to the active link.
     Screen readers will announce this link as "current" or "current page"
     depending on the assistive technology, giving users a clear
     programmatic location signal in addition to the visual styling. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active' aria-current='page'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Formulaire multi-étapes sans indicateur d’étape — Incorrect

<!-- A multi-step checkout form with no indication of current step.
     Users cannot determine how far they are through the process
     or how many steps remain. -->
<form>
  <h1>Shipping Information</h1>
  <!-- form fields -->
  <button type='submit'>Next</button>
</form>

Formulaire multi-étapes sans indicateur d’étape — Correct

<!-- A progress indicator communicates the user's position in the sequence.
     aria-label on the nav provides context.
     aria-current="step" marks the active step for assistive technologies.
     The visible text "Step 2 of 4" is also available for all users. -->
<nav aria-label='Checkout progress'>
  <ol>
    <li><a href='/checkout/cart'>Cart</a></li>
    <li aria-current='step'><strong>Shipping</strong></li>
    <li>Payment</li>
    <li>Confirmation</li>
  </ol>
</nav>
<form>
  <h1>Shipping Information <span>(Step 2 of 4)</span></h1>
  <!-- form fields -->
  <button type='submit'>Next: Payment</button>
</form>

Erreurs courantes

• Fournir un fil d’Ariane uniquement sur la page d’accueil ou uniquement sur les pages feuilles : Le fil d’Ariane doit être présent de manière cohérente sur toutes les pages de l’ensemble. L’afficher uniquement sur les pages de détail produit mais pas sur les pages de catégorie crée des lacunes dans les informations d’orientation.
• Utiliser un lien actif stylé visuellement sans ajouter aria-current="page" : Un lien de navigation actif en gras ou souligné communique l’emplacement visuellement, mais les utilisateurs de lecteurs d’écran n’en tirent aucun bénéfice tant que aria-current="page" n’est pas également présent sur cet élément.
• Encapsuler le fil d’Ariane dans un <div> au lieu d’un élément <nav> : Utiliser un conteneur non sémantique signifie que le fil d’Ariane n’est pas exposé comme repère de navigation, ce qui le rend plus difficile à trouver et à interpréter pour les utilisateurs de lecteurs d’écran.
• Omettre aria-label sur le <nav> du fil d’Ariane lorsqu’un repère de navigation principal existe également : Deux repères <nav> non étiquetés sur la même page créent une ambiguïté. Les lecteurs d’écran peuvent annoncer les deux simplement comme « navigation », laissant les utilisateurs incapables de les distinguer.
• Utiliser aria-current="true" sur un lien de page au lieu de aria-current="page" : La valeur page est la valeur sémantiquement correcte pour identifier la page actuelle dans un contexte de navigation. Utiliser true est moins descriptif et peut être annoncé différemment ou de manière moins claire par les technologies d’assistance.
• Se fier uniquement au titre de la page pour indiquer l’emplacement : Un élément <title> descriptif (par exemple, « Laptops — 15-inch Models | Acme Store ») est utile et requis par WCAG 2.4.2, mais il ne satisfait pas à lui seul 2.4.8, qui exige un mécanisme transmettant la position dans la structure de l’ensemble de pages, et pas seulement le nom de la page actuelle.
• Construire des fils d’Ariane qui reflètent la structure des URL plutôt que la hiérarchie de navigation : Les URL et les structures de navigation ne sont pas toujours alignées. Les fils d’Ariane doivent refléter l’architecture de l’information logique telle qu’un utilisateur la comprendrait, et non le chemin d’URL sous-jacent, qui peut être technique ou opaque.
• Afficher le fil d’Ariane comme texte brut sans liens pour les niveaux ancêtres : Si seule la page actuelle est affichée ou si les niveaux ancêtres ne sont pas liés, le fil d’Ariane perd son utilité en tant qu’indicateur d’emplacement et aide à la navigation. Les éléments ancêtres doivent être liés pour permettre aux utilisateurs de remonter dans la hiérarchie.
• Marquer l’élément actuel du fil d’Ariane uniquement par un changement de séparateur visuel au lieu de aria-current : Changer la couleur ou supprimer le soulignement du dernier élément du fil d’Ariane ne communique pas aux lecteurs d’écran qu’il représente la page actuelle. aria-current="page" doit être explicitement ajouté.
• Oublier de mettre à jour l’indicateur d’emplacement dans les applications monopage (SPA) après une navigation côté client : Dans les SPA construites avec des frameworks tels que React ou Vue, les transitions de page se produisent sans rechargement complet du navigateur. Si le fil d’Ariane ou l’indicateur de navigation actif n’est pas mis à jour de manière programmatique lors du changement de route, il affichera une information d’emplacement obsolète, ce qui est pire que de ne pas avoir d’indicateur du tout.

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

La circulaire présidentielle 2025/10 de la Turquie, publiée au Journal officiel n° 32933 le 21 juin 2025, établit des exigences contraignantes en matière d’accessibilité Web et mobile pour un large éventail d’organisations opérant en Turquie. La circulaire impose le respect de normes d’accessibilité reconnues au niveau international — adoptant de fait le cadre WCAG — et s’applique à un ensemble défini de types d’entités, notamment les institutions et agences publiques, les plateformes d’e-commerce, les banques et institutions financières, les hôpitaux et prestataires de soins de santé, les entreprises de télécommunications comptant 200,000 abonnés ou plus, les agences de voyage agréées, les entreprises de transport privées et les écoles privées autorisées par le ministère de l’Éducation nationale (MoNE).

WCAG 2.4.8 Location est classé comme critère de niveau AAA, ce qui signifie qu’il ne fait pas partie des critères de base légalement requis par la circulaire, qui fait référence à la conformité de niveau A et AA comme seuil minimal. Cependant, cette distinction est importante à plusieurs égards pour les organisations couvertes par la réglementation.

Premièrement, certains services spécialisés — en particulier ceux qui s’adressent à des utilisateurs ayant des difficultés cognitives ou de navigation importantes, comme les portails de santé pour les patients âgés ou les plateformes éducatives pour les élèves ayant des troubles d’apprentissage — peuvent être amenés à dépasser le socle AA afin de répondre véritablement à l’esprit des obligations d’accessibilité prévues par le droit turc et par des textes connexes tels que la loi sur les personnes handicapées n° 5378. La mise en œuvre de 2.4.8 dans ces contextes démontre un engagement substantiel, plutôt que purement procédural, en faveur de l’inclusion.

Deuxièmement, les institutions publiques turques et les entités privées réglementées sont de plus en plus soumises à des mécanismes d’audit et de plainte. Démontrer une conformité de niveau AAA — y compris WCAG 2.4.8 — fournit une preuve défendable de mise en œuvre des bonnes pratiques et réduit le risque réglementaire en cas de plainte formelle relative à l’accessibilité.

Troisièmement, pour les plateformes d’e-commerce et les banques en particulier, les indicateurs d’emplacement tels que les fils d’Ariane ont une valeur commerciale directe en plus de leur fonction d’accessibilité. Un processus de demande de prêt immobilier en ligne d’une banque turque qui inclut des indicateurs d’étapes clairs et une navigation par fil d’Ariane servira non seulement plus efficacement les utilisateurs ayant des handicaps cognitifs, mais réduira également les taux d’abandon et soutiendra la conversion — alignant l’investissement en accessibilité sur des résultats commerciaux mesurables.

Les organisations utilisant le SDK de surcouche Accsible peuvent tirer parti de ses fonctionnalités intégrées d’amélioration des fils d’Ariane et d’injection de aria-current pour rapprocher les sites existants de la conformité à 2.4.8 sans nécessiter une refonte complète de la base de code. Cependant, pour une conformité complète et robuste — en particulier pour les entités couvertes par la circulaire présidentielle 2025/10 — la mise en œuvre côté serveur ou au moment du build d’un balisage sémantique de fil d’Ariane et d’indicateurs de navigation reste l’approche recommandée, car les solutions de surcouche complètent mais ne remplacent pas un balisage accessible de base.