Aller au contenu Eleven Ways (Home)

Tous les articles

Navigation multiniveau : le défi de l’identification des sections parentes pour les lecteurs d’écran

Écrit par Régine Lambrecht le 21 avril 2026 (temps de lecture moyen: 4 minutes)

De nombreux guides expliquent comment créer un menu de navigation accessible, mais ils négligent la complexité de la navigation « vous êtes ici ». Comment traduire la mise en évidence visuelle de l'élément parent actif en un message compréhensible par un utilisateur de lecteur d'écran ?

La nécessité UX : l'état « parent actif »

Dans un méga-menu comportant plusieurs sous-niveaux, il est d'usage courant en ergonomie de distinguer visuellement la section parente d'une page de niveau 2 ou 3. Cela aide l'utilisateur à se situer dans l'architecture du site et à retrouver facilement les pages sœurs ou parentes.

Solution visuelle : Généralement, les développeurs utilisent une classe CSS dynamique telle que .active-parent.

Le problème : Ce style est purement visuel et reste invisible pour les utilisateurs de lecteurs d'écran, à moins d'être associé à un attribut sémantique.

La limite du fil d'Ariane

Bien qu'un fil d'Ariane puisse techniquement remplacer cette identification visuelle, il ne constitue pas une solution de secours infaillible. Les fils d'Ariane sont souvent tronqués sur mobile, voire masqués pour gagner de l'espace. Dans ces cas-là, la mise en évidence visuelle de la section parente dans la navigation devient le seul moyen de comprendre la hiérarchie du site.

La lacune sémantique du HTML

L'accessibilité dicte que toute information visuelle doit être fournie de manière non visuelle. Idéalement, cela devrait se faire via le HTML natif. Cependant, il n'existe aucune balise HTML standard pour distinguer une "section parente" de la "page actuelle". Nous sommes donc contraints de nous tourner vers ARIA.

Si l'attribut aria-expanded nous indique si un menu est ouvert, il ne dit rien sur le fait que cette section contient ou non la page active. Cela nous amène à aria-current. Selon le W3C, aria-current est utilisé lorsqu'un élément au sein d'un ensemble est stylisé visuellement pour indiquer qu'il est l'élément courant.

Les valeurs de aria-current les plus intéressantes dans notre cas sont :

  • aria-current="page": Doit être strictement réservé à la page exacte sur laquelle se trouve l'utilisateur.
  • aria-current="location": Souvent présent dans les fils d'Ariane ; les lecteurs d'écran l'annoncent généralement comme "emplacement en cours"
  • aria-current="true": Un état générique, annoncé simplement comme "en cours"

Peut-on utiliser plusieurs attributs aria-current ?

L'utilisation de plusieurs balises aria-current dans un même groupe peut être déroutante, car un utilisateur aveugle entendra le mot "en cours" à plusieurs reprises. En effet, combiner la valeur "page" pour le lien actif avec des valeurs comme "location" ou "true" pour les éléments parents peut entraîner une confusion importante. Un utilisateur de lecteur d'écran pourrait avoir du mal à distinguer quelle entrée représente sa destination réelle par rapport à un simple repère structurel.

Cependant, les spécifications WAI-ARIA 1.2 concernant aria-current précisent : "les auteurs devraient (SHOULD) ne marquer qu'un seul élément d'un ensemble comme courant". L'utilisation du terme "devraient" (plutôt que "doivent") implique une certaine flexibilité. Dans un méga-menu multi-niveaux, chaque ancêtre de la page actuelle pourrait théoriquement porter l'attribut aria-current="location". Cet attribut bénéficie d'un excellent support sur les lecteurs d'écran modernes, y compris Narrator avec Edge.

Solutions alternatives : l'approche du "libellé masqué"

L'exemple de barre de menu de navigation du W3C propose une voie différente en utilisant l'attribut title. Ajouter title="contient le lien de la page en cours" à l'entrée parente fournit une information supplémentaire. Comme title ne remplace pas le libellé visible dans l'arbre d'accessibilité, il agit comme un indice utile.

Une autre solution est la balise span avec une classe sr-only. Cela consiste à ajouter un élément masqué visuellement à l'intérieur du lien : <a href="...">produits <span class="sr-only">(section en cours)</span></a>. Avec cette méthode, le nom accessible commence toujours par le libellé visible, ce qui est conforme aux exigences d'accessibilité.

Conclusion

Navigating the nuances of digital accessibility requires more than just following a checklist; it requires balancing technical standards with real-world user experience. Choosing between an unusual ARIA implementation—which might suffer from inconsistent assistive technology support or confuse screen reader users—and a less semantic "patch" like a hidden span is a complex architectural decision. There is rarely a "one-size-fits-all" answer, as the best approach often depends on the specific context of your site's navigation and its users. Naviguer dans les nuances de l'accessibilité numérique requiert plus que le simple suivi d'une liste de contrôle ; cela demande de trouver un équilibre entre les normes techniques et l'expérience utilisateur réelle. Choisir entre une implémentation ARIA inhabituelle — qui pourrait souffrir d'un support incohérent des technologies d'assistance — et un "correctif" moins sémantique comme un span masqué est une décision architecturale complexe. Il existe rarement une réponse universelle, car la meilleure approche dépend souvent du contexte spécifique de la navigation de votre site et de ses utilisateurs.

Chez Eleven ways, nous nous spécialisons dans la résolution de ces énigmes complexes. Nous pensons que la véritable accessibilité va au-delà de la simple conformité ; il s'agit de rendre les produits numériques intuitifs pour tous. Notre équipe apporte l'expertise approfondie nécessaire pour auditer, conseiller et former vos développeurs, garantissant que même les méga-menus les plus complexes sont inclusifs dès leur conception. Que vous exploriez les dernières spécifications WAI-ARIA ou que vous recherchiez des solutions pragmatiques pour vos utilisateurs, nous sommes là pour vous aider à combler le fossé entre le code et l'utilisabilité.

Derniers articles

Des conseils d'accessibilité pratiques dans votre boîte de réception

Grâce à nos conseils pratiques, vous apprendrez à rendre le site Web ou l'application de votre organisation (ou client) accessible à tous.

Vous pouvez vous désabonner en un seul click.

Comment pouvons-nous vous aider ?

Toutes les coordonnées