Menus déroulants accessibles

Les menus de navigation déroulants sont des composants censés simplifier la vie des utilisateurs en leur donnant un accès rapide à toutes les pages d'un site, tout en ne prenant pas trop de place.

Un menu déroulant est accessible si tout le monde peut l'utiliser : avec une souris ou autre pointeur, même si on ne maîtrise pas bien ses mouvements, avec un clavier, avec un lecteur d'écran, avec un logiciel de reconnaissance vocale, etc.

Un menu déroulant accessible, idéalement, c'est aussi un menu qui n'est pas encombrant : l'utilisateur ne doit pas être obligé d'afficher le menu déroulant, ou de le traverser entièrement au clavier, quand il n'en a pas besoin.

Conseils généraux

Ne pas confondre une liste déroulante (select, combobox) et un menu de navigation déroulant. Dans un menu de navigation, les sous-menus sont composés de listes de liens.

Ne pas utiliser les rôles menubar,menu et menuitem pour des menus de navigation : ces rôles sont destinés aux menus applicatifs de type toolbar, ils escamotent la sémantique présente dans le code HTML (listes, liens) et rendent l'interaction difficile pour les utilisateurs de lecteurs d'écran.

Structurer correctement le menu en HTML :

Placer le tout dans un élément nav

Structurer le menu comme une liste avec un ou plusieurs niveaux d'imbrication et automatiquement les sous-menus suivront directement le bouton qui déclenche leur affichage dans le code source

Utiliser des liens pour déclencher la navigation vers une autre page et des boutons pour afficher un sous-menu

Éviter tous les attributs ARIA inutiles qui sont sources de bruit et de confusion : pas besoin de aria-haspopup, aria-owns ou aria-controls

Veiller à ce que le focus soit visible lors de la tabulation sur les éléments du menu, et que quand un élément se trouve dans l'ordre de tabulation, il soit visible. Quand les sous-menus sont cachés, ils ne doivent pas être accessibles avec TAB

Prévoir des contrastes suffisants pour les liens du menu, dans tous leurs états (défaut, focus, hover)

Prévoir une version adaptée à un écran mobile (ou à l'utilisation avec zoom).

Différents types de menus déroulants

Les deux méthodes utilisées pour afficher les menus déroulants avec un pointeur sont

le clic sur l'élément parent

le survol de l'élément parent (hover)

Dans les deux cas, il faut faire en sorte qu'il y ait un comportement équivalent au clavier :

si le sous-menu s'affiche en cliquant sur les éléments parents, cela doit aussi fonctionner avec ENTER,

si le sous-menu s'affiche au survol de l'élément parent (hover), il faut également qu'il s'affiche avec TAB, quand l'élément parent reçoit le focus.

Nous préférons nettement la première méthode (clic et ENTER) car elle donne plus de contrôle à l'utilisateur. Mais vous trouverez ci-dessous des conseils pour rendre accessibles les deux types de menus.

Menus qui s'affichent au clic et avec ENTER

Ce type de menu est en principe le plus simple, et le plus accessible. Les sous-menus ne s'affichent que sur une action délibérée de l'utilisateur : un clic ou l'utilisation de ENTER sur l'élément parent.

Exemple : Disclosure navigation menu .

Le gros avantage de cette solution est que l'utilisateur qui parcourt le menu au clavier n'est pas obligé de parcourir tous les niveaux de la liste.

Chaque élément du menu doit être implémenté simplement comme un bouton pour afficher ou cacher un menu.

Le sous-menu s'affiche quand on clique sur l'élément parent. Un deuxième clic masque le sous-menu.

Les éléments visibles du menu sont accessibles avec TAB. Ce sera automatiquement le cas si ce sont des éléments button.

L'état de chaque élément du menu (replié ou déplié) est indiqué au moyen d'un attribut aria-expanded avec une valeur true ou false.

Quand le focus se trouve sur un élément parent, ENTER affiche le sous-menu ou le masque.

Le contenu du sous-menu peut être parcouru au moyen de TAB.

Les sous-menus sont cachés avec display:none, pour être invisibles avec un lecteur d'écran et pas focusables tant qu'ils sont cachés.

Cela fonctionne bien quand les éléments principaux de menu ne servent pas aussi de liens vers des landing pages. Si c'est le cas, on a un problème, car ce n'est pas une bonne idée qu'un même élément interactif puisse déclencher deux actions différentes : naviguer vers une page et afficher un sous-menu. On a donc besoin de deux éléments au lieu d'un seul : un lien pour aller vers une page du site, et un bouton séparé pour afficher le sous-menu.

Voir un exemple de menu hybride où chaque élément du menu est dédoublé en un lien, et un bouton qui affiche un sous-menu.

Dans ce cas, les boutons doivent aussi être implémentés en suivant le motif de conception des panneaux dépliants. Il y a un point d'attention en plus : il faut donner un nom pertinent au bouton pour que sa fonction soit claire.

Menus qui s'affichent au survol et au TAB

Exemple ⁣ : menu déroulant responsive basé sur un exemple de Simply Accessible.

Les désavantages de cette solution sont :

L'utilisateur qui navigue au clavier est obligé de parcourir tous les sous-menus, même quand il n'en a pas besoin. Cela rallonge énormément la navigation au clavier. L'ajout d'un lien d'évitement au début de la page (aller au contenu) peut être une solution partielle.

Les utilisateurs qui utilisent un pointeur (souris ou autre) risquent d'afficher les sous-menus sans le vouloir. C'est d'autant plus dérangeant que l'écran est petit ou le facteur de zoom élevé. Prévoir de pouvoir cacher un sous-menu en utilisant ESC atténue le problème.

Les actions de survol sont plus difficiles à faire qu'un clic avec des logiciels de reconnaissance vocale.

Le comportement attendu du menu est le suivant :

Le sous-menu s'affiche au survol (hover) de l'élément parent. En cliquant sur l'élément parent, on navigue vers la page correspondante, s'il y en a une.

Au clavier, le sous-menu s'affiche dès que le focus arrive sur l'élément parent (avec TAB). ENTER sur l'élément parent sert à naviguer vers la page correspondante s'il y en a une.

Le contenu du sous-menu peut être parcouru au moyen du TAB

On ne cache pas les sous-menus avec display:none mais en 'screenreader only' pour qu'ils soient toujours visibles pour les utilisateurs de lecteur d'écran, même quand ils sont cachés.

Il ne faut pas utiliser aria-expanded puisque les sous-menus restent toujours visibles pour un utilisateur de lecteur d'écran.

Il faut prévoir un moyen de masquer le sous-menu sans déplacer le pointeur ni le focus du clavier, par exemple la touche ESC.

Note : En principe, on voudrait cacher les sous-menus avec display:none, mais cela peut poser un problème lors de la navigation avec certains lecteurs d'écran. L'affichage visuel du menu est déclenché par un événement onFocus(). L'événement onFocus est déclenché quand on arrive sur le lien avec TAB. Mais quand on utilise un lecteur d'écran, on peut parcourir le contenu d'une page web en utilisant la flèche vers le bas. Avec JAWS, et avec la configuration par défaut de NVDA cela ne déclenche pas d'événement onFocus. Le menu ne s'affichera donc pas pour un utilisateur de JAWS ou NVDA qui parcourt le menu. Pour pallier ce problème, on utilise plutôt une technique 'screenreader only' (offscreen ou clipping) pour cacher les sous-menus. Cela signifie que, même si leur affichage visuel se déclenche uniquement avec hover et focus, les sous-menus sont toujours visibles pour les utilisateurs de lecteur d'écran.