Menus déroulants en accordéons

Ce composant utilise le principe des accordéons pour obtenir un effet de menus déroulants. La navigation contient une liste de boutons qui représentent diverses sections d’un site web et permettent d’étendre ou de réduire des menus de liens associés. Tout en reprenant des principes d’accessibilité déjà couverts dans la fiche Accordéons, ce composant comporte quelques requis additionnels, notamment pour les interactions au clavier.

Outre les accordéons, il existe une autre approche de conception pour créer des menus déroulants : les menus interactifs ARIA, qui utilisent des rôles tels que  menubar et menu. Cependant, comme l’explique le W3C dans son Guide des pratiques de conception ARIA, les menus ARIA sont associés à une plus grande complexité d’interactions, notamment avec des outils d’adaptation. C’est pourquoi le Guide estime que l’approche des accordéons (disclosure pattern) est généralement mieux adaptée aux sites Web typiques qui ne nécessitent pas la complexité des interactions clavier d’un menu interactif ARIA.

La présente fiche s’inscrit dans cette recommandation, privilégiant l’approche en accordéons. Les exemples proposés ne couvrent pas tous les cas d’usages de menus déroulants, mais illustrent deux modèles de conception parmi les plus courants :

• une navigation composée exclusivement de menus déroulants en accordéons, à un seul niveau d’affichage;
• une navigation combinant des menus accordéons et des liens simples comme rubriques de premier niveau.

D’autres modèles de menus accordéons sont discutés dans la section Préoccupations complémentaires d’utilisabilité.

Voici les principaux comportements attendus avec les outils d’adaptation (lecteurs d’écran, commandes vocales, etc.) ainsi que la navigation au clavier.

• Les menus déroulants s’ouvrent ou se ferment à l’aide d’un bouton et non d’un lien. 
• Les menus déroulants d’une même navigation sont regroupés dans une liste. Les niveaux d’imbrication de cette liste communiquent la hiérarchie de la navigation, où chaque bouton déclencheur est le parent direct de son menu associé.
• La liste est incluse dans une région de navigation annoncée par les lecteurs d’écran.
• Chaque bouton de menu :
  • comporte un libellé évocateur du menu contrôlé;
  • est focusable au clavier et s’active avec la touche Entrée ou la barre d’espacement.
• L’état étendu ou réduit est communiqué aux lecteurs d’écran lorsque le focus atteint le bouton.
• Tout changement d’état résultant de l’activation du bouton est immédiatement annoncé par les lecteurs d’écran.
• Lorsque le focus clavier est positionné sur un bouton de menu, ou sur un lien à l’intérieur de ce menu : la touche Échap referme le menu, s’il était ouvert, et le focus revient sur le bouton déclencheur.
• Lorsqu’un menu déroulant est ouvert :
  • Le focus demeure sur le bouton déclencheur, car l’annonce du changement d’état suffit à confirmer le résultat de l’action. C’est l’utilisateur qui déplace le focus pour parcourir le menu.
  • Tout menu déroulant précédemment ouvert se referme automatiquement.
  • Si le menu a été ouvert par navigation au clavier : l’affichage du menu persiste tant que le focus demeure sur le bouton déclencheur ou dans le menu.
  • Si le menu a été ouvert en cliquant à l’aide d’un pointeur (un doigt, une baguette de saisie, une souris, etc.) : l’affichage du menu persiste tant que l’utilisateur n’a pas activé un lien dans celui-ci, ou cliqué hors du menu.
• Lorsqu’un menu déroulant est fermé : la navigation n’est pas exposée aux outils d’adaptation et ses contenus ne font pas partie du parcours de navigation au clavier.

Autres points à surveiller

• Chaque bouton de menu déroulant est reconnu et activable par les outils de commandes vocales, lorsqu’on dicte les mots du libellé visible.
• Dans des menus utilisant le principe des accordéons, la touche Tabulation permet de naviguer (avec ou sans lecteur d’écran) parmi les boutons et les liens.
• (Optionnel) Il est également possible d’ajouter un support des touches directionnelles pour parcourir les menus. Cependant, cette option ne doit pas empêcher ni remplacer la navigation avec Tabulation.
• (Optionnel) Pour une navigation au clavier plus conviviale, on peut prévoir la fermeture automatique d’un menu actif quand le focus quitte celui-ci. Plus précisément :
  • Lorsque le focus de Tabulation sort du menu courant, à partir du dernier lien : le menu se referme.
  • Lors du déplacement inverse du focus (Majuscule + Tabulation) : le menu se referme si le focus quitte son bouton pour se déplacer sur la rubrique de premier niveau précédente. Le menu se ferme également si le focus sort de la navigation.
  • Ces comportements doivent être réservés aux menus déroulants d’une navigation horizontale. En effet, dans les navigations verticales (ex. : menus mobiles), la fermeture automatique provoque une fluctuation visuelle de l’emplacement des boutons déclencheurs, nuisant au parcours visuel de lecture.

Rôles, états et propriétés ARIA

• Les menus déroulants d’une même navigation sont groupés dans une liste avec les balises <ul> et <li>. Ces balises sont imbriquées pour structurer chaque bouton déclencheur (premier niveau) et son menu enfant (deuxième niveau).
• La liste est placée dans une région de navigation (balise <nav>, ou élément auquel on a assigné role="navigation").
• (Bonne pratique) La région de navigation reçoit un attribut aria-label dont la valeur précise le type de navigation (ex. : aria-label="Navigation principale").
• Chaque bouton déclencheur d’un menu est codé avec la balise <button> (ou encore, est un élément auquel on a assigné  role="button", comme dans les exemples accompagnant cette fiche).
• Les liens présents à l’intérieur d’un menu déroulant (balise <a>) conservent leur rôle natif et ne reçoivent pas d’attribut ARIA spécifique.
• Si le menu est ouvert, le bouton déclencheur a l’attribut aria-expanded défini sur true. Si le menu est fermé, aria-expanded est défini sur false.
• (Optionnel) Le bouton hamburger est associé à son menu depuis l’attribut aria-controls. La valeur de cet attribut correspond à l’identifiant unique (ID) donné à la balise de liste (<ul>) du menu.
  • Remarque : L’usage de cet attribut fait l’objet de certaines réserves pour des composants utilisant le principe des accordéons. Voir à ce sujet la fiche Accordéons.

Autres considérations techniques

• Les principaux aspects gérés par JavaScript sont :
  • Les comportements d’ouverture et de fermeture des menus déroulants, déclenchés par l’activation de leur bouton.
  • Les comportements de fermeture des menus dans certains contextes décrits plus tôt à la section Critères fonctionnels.
  • Le changement dynamique de la valeur de l’attribut aria-expanded, pour déclarer l’état étendu (true) ou réduit (false).
  • Le comportement de la touche Échappe, pour fermer un menu et rediriger le focus sur son bouton déclencheur.
• Lorsque le bouton est codé avec la balise <button>, il est d’emblée focusable au clavier avec Tabulation, et activable avec les touches Entrée ou Barre d’espacement. Cependant, si le bouton est un autre élément HTML auquel on a assigné role="button", tous les comportements, incluant le fonctionnement attendu au clavier, doivent être recréés avec JavaScript. Au besoin, l’élément est rendu focusable avec tabindex="0".
• Le nom accessible du bouton reprend tous les mots de son libellé visible, dans le même ordre relatif, afin d’en permettre l’activation par commandes vocales.
• Les icônes qui indiquent l’état étendu ou réduit des menus reçoivent un traitement décoratif (ex. : alt="" ou aria-hidden="true").
• La mise en forme CSS display:none est appliquée au menu fermé. Cela permet de masquer ses contenus aux outils d’adaptation et évite qu’ils ne soient inclus dans le parcours de tabulation.

Libellé du bouton de menu déroulant

Puisque le changement d’état du bouton est déjà communiqué par l’attribut aria-expanded, il faut éviter d’introduire cette information dans le nom accessible du bouton. Dans le cas contraire, cela peut générer de la confusion, comme exemplifié dans la fiche Menu hamburger en accordéons.

Navigation incluant à la fois des boutons et des liens comme rubriques de premier niveau

Certains sites web utilisent une navigation combinant des menus accordéons et des liens comme rubriques de premier niveau. Lors du développement de nos exemples, nous nous sommes interrogés sur l’utilisabilité de certains modèles de conception répondant à ce besoin. Nous partageons ici quelques observations effectuées dans le cadre de tests utilisateurs, sur trois modèles de navigation décrits plus bas. Bien que les résultats obtenus émanent d’un petit échantillon de personnes, nous estimons qu’ils amènent des pistes de réflexion intéressantes :

• Modèle 1 : premier exemple de cette fiche. La navigation contient uniquement des menus accordéons.
• Modèle 2 : deuxième exemple de cette fiche. Les premières rubriques sont des boutons déclenchant des accordéons, alors que la dernière rubrique est un lien simple conduisant à une destination.
• Modèle 3 (non retenu) : s’inspire d’un exemple du W3C. Il consiste en quatre liens de premier niveau, qui pointent chacun vers une section du site. À droite des trois premiers liens, un bouton accordéon permet d’accéder à une liste de pages apparentées. Un quatrième lien, sans bouton accordéon, a été ajouté à la fin de la navigation.

Quelques observations

• Le troisième modèle est celui qui a causé le plus de confusion et d’obstacles pour les personnes utilisant des lecteurs d’écran. Celles-ci avaient de la difficulté à percevoir « l’association » entre chaque lien et son bouton accordéon. Nous croyons que la découverte séquentielle du menu et l’absence de vue d’ensemble pourraient contribuer à cette difficulté, qui s’est résorbée chez certains personnes après quelques minutes d’exploration.
• Les premier et second modèles ont été nettement plus appréciés par le groupe de test. Parmi les commentaires recueillis, on note une plus grande facilité à reconstituer mentalement la structure de la navigation.
• Nous nous interrogions sur l’impact de l’amalgame des liens et boutons commes rubriques de premier niveau pour les personnes qui utilisent les fonctionnalités de lecteurs d’écran listant les liens d’une page. En effet, dans ce type de navigation, certaines rubriques de premier niveau apparaissent dans la liste des liens, alors que d’autres apparaissent dans la liste des boutons. Nos tests n’ont pas permis de dégager de tendance précise à ce sujet et aucune personne n’a tenté l’emploi de ces fonctionnalités. Néanmoins, une personne a mentionné qu’elle préférait parcourir un menu dans son ensemble lorsqu’elle consulte une page Web pour la première fois. Pour cette raison, les inconvénients lui semblaient limités.

Pistes pour accroître l’utilisabilité

• Lorsque l’architecture du site le permet, privilégier l’un ou l’autre des modèles exemplifiés dans cette fiche.
• Lorsqu’une structure de site Web comprend à la fois des pages portails de section et des pages secondaires, certaines solutions plus conviviales peuvent être envisagées en remplacement du modèle 3 (exemple du W3C). Par exemple :
  • Créer une navigation principale qui inclut seulement les liens vers les pages portails (sans menus déroulants), et ajouter une navigation latérale dans les pages secondaires;
  • Utiliser des menus accordéons comme dans le deuxième exemple, mais prévoir, dans le premier lien du menu déroulant associé, un accès à la page qui fournit la vue d’ensemble de la section.
• Dans tous les cas, une rubrique de navigation doit se limiter à un seul type d’action : elle ne devrait pas jouer à la fois un rôle de lien (mène vers une destination) et de bouton (déclenche un comportement, ici l’affichage d’un menu).

Comportements de JAWS et NVDA lors de la fermeture avec Échap

• Environnement d’observation : Versions les plus récentes de JAWS, NVDA et Chrome en date du 21 mars 2025.
• Résumé du problème :
  • Avec JAWS et NVDA, lorsqu’on utilise le mode Navigation avec les flèches haut et bas, l’activation d’Échap dans un accordéon ouvert entraîne une mauvaise redirection du focus. Le focus clavier est correctement redirigé vers le bouton, mais le focus du lecteur d’écran ne suit pas. Des tests révèlent que ce focus demeure à l’endroit où l’utilisateur se trouvait en activant Échap. Comme le menu disparaît à la fermeture, le lecteur d’écran tente de relocaliser le focus.
  • Avec JAWS, cette relocalisation se fait de manière aléatoire, à proximité de la navigation qui héberge le menu. Avec NVDA, le problème est plus subtil, car le lecteur d’écran parvient souvent à replacer le focus très près du bouton cible.
  • Le problème de focus ne se produit pas si l’utilisateur navigue dans les menus avec Tabulation avant d’appuyer sur Échap. Le focus du lecteur d’écran rejoint alors le focus clavier sur le bouton d’accordéon.
• Comportement attendu : En appuyant sur Échap pour fermer le menu, le focus du lecteur d’écran devrait rejoindre le focus clavier sur l’élément cible, peu importe la manière de naviguer.
• Pistes et analyses techniques : 
  • Seul le focus clavier peut être contrôlé par voie de programmation. Par conséquent, la gestion du focus des lecteurs d’écran dépend de la manière dont ces outils d’adaptation sont conçus.
  • Un dépôt artificiel du focus clavier sur des éléments de menus, dans le but de corriger le comportement, créerait d’autres problèmes d’accessibilité et susciterait de la confusion.
• Impact estimé : Important. Les utilisateurs de lecteurs d’écran n’ont pas nécessairement le réflexe de naviguer avec Tabulation dans les menus. De plus, la fermeture avec Échap demeure un aspect fondamental du motif de conception des menus. Cela dit, le problème touche tous les menus accordéons respectant les requis d’accessibilité, incluant ceux du W3C.
• Décision : Un suivi sera effectué auprès des équipes de développement de ces lecteurs d’écran. Nous maintenons l’emploi du composant dans sa forme actuelle, car malgré ses limites, il demeure généralement plus facile à utiliser que les menus interactifs ARIA pour des personnes utilisatrices de lecteur d’écran.

Le code employé est une conception du Regroupement des aveugles et amblyopes du Montréal métropolitain (RAAMM).

Pour le moment, l’exemple utilise la bibliothèque JavaScript jQuery. Une version en JavaScript Vanille sera également fournie sous peu.

Notons que le script de l’exemple combine les fonctionnalités des menus déroulants à celles d’un menu hamburger, pour illustrer une gestion harmonisée de ces composants en affichage adaptatif.