Motif de conception ARIA Menu : pourquoi l’utiliser le moins possible ?

7 mars, par Équipe Access42

Il y a quelques mois, Marco Zehe publiait sur son blog un article intitulé « WAI-ARIA menus, and why you should generally avoid using them ». Cet article soulevant des points très intéressants, nous lui avons proposé d’en réaliser la traduction française. Nous le remercions chaleureusement pour son autorisation.

Les standards WAI-ARIA définissent un certain nombre de rôles liés au motif de conception Menu. Mais dans 99% des cas, il vaudrait mieux ne pas les utiliser.

Retraçons un peu l’histoire

Au milieu des années 2000, on se demandait lequel de HTML 4.01 ou XHTML 1.x était le meilleur standard. Les deux langages avaient pour point commun leur absence totale de gestion des composants riches. Ceux-ci étaient de plus en plus convoités par les développeur·ses partout dans le monde. Malheureusement, les processus d’évolution des standards prenaient beaucoup de temps, et les éditeurs de navigateurs n’étaient pas aussi nombreux qu’aujourd’hui. En somme, les choses avançaient bien trop lentement.

Les développeur·ses web se sont alors mis·es à implémenter ces éléments avec des div ou des span, en les stylisant pour qu’ils ressemblent aux composants qu’on trouvait traditionnellement dans les interfaces logicielles. L’objectif était de créer une expérience utilisateur plus riche sur le web. En réalité, c’était la lente transition vers le concept d’applications web qui s’amorçait.

À cette époque, on utilisait surtout des applications logicielles arborant des barres de menu classiques avec une liste déroulante pour chaque entrée de menu, sur des systèmes d’exploitation comme Windows XP. Sur Mac, ces menus sont toujours d’actualité, mais sur Windows, les applications modernes s’en sont depuis éloignées.

WAI-ARIA à la rescousse

Le standard WAI-ARIA a été créé par un groupe de personnes talentueuses pour tenter de prendre en charge ces expériences web naissantes. Il s’agissait d’importer les concepts du monde du logiciel sur le web, en donnant aux développeur·ses des moyens d’indiquer aux lecteurs d’écran à quel équivalent logiciel correspondait le composant qu’ils voulaient concevoir. On fournissait alors aux lecteurs d’écran les informations nécessaires pour gérer ces composants de la même manière que dans les applications logicielles.

Parmi ces fameux composants, figuraient les éléments menubar, menu, menuitem et leurs cousins menuitemradio et menuitemcheckbox. On pouvait ainsi reproduire sur le web les barres de menu, leurs sous-menus déroulants et les différents types d’éléments (bouton radio, case à cocher ou simple option de menu) que l’on retrouvait sous Windows, Linux/GNOME et Mac. Les lecteurs d’écran interagissaient avec ces menus de la même façon que dans les applications logicielles.

Restés des années sans réelle API sur laquelle se reposer, en particulier sous Windows, les lecteurs d’écran ont dû bricoler des sortes de modes menu pour applications, puisque techniquement, le focus se trouvait à deux endroits en même temps, ou du moins c’était tout comme [1]. Et il ne s’agit là que de l’une des nombreuses bizarreries liées à ces menus.

Ce qu’il faut retenir, c’est que lorsque les lecteurs d’écran et leurs utilisateurs rencontrent des éléments de la famille de menuitem, ils s’attendent à des comportements bien spécifiques. En effet, une barre de menu est constituée uniquement de menus, qui sont eux-mêmes uniquement constitués d’éléments menuitem, etc. Le comportement au clavier doit lui aussi répondre à certaines exigences : l’utilisateur doit pouvoir naviguer de gauche à droite (ou de droite à gauche en fonction de la langue) dans les entrées de la barre de menu, les menus doivent s’ouvrir grâce aux touches Entrée ou Flèche du bas, et la touche Echappe doit permettre, quant à elle, de les fermer.

Le problème

Aujourd’hui, et notamment avec la disparition de ces menus sous Windows, on se rend compte que ces concepts sont de moins en moins connus. La plupart des développeur·ses web ignorent l’histoire de ces composants et les interactions qu’impliquent leur utilisation. L’une des erreurs d’utilisation de l’API ARIA la plus fréquente concerne justement le recours inapproprié à des rôles menu.

Souvent, les propriétés menuitem sont implémentées sans parents dotés d’un rôle menu, provoquant ainsi des comportements incongrus pour les technologies d’assistance. Par exemple, un lecteur d’écran peut se retrouver bloqué en « mode menu » parce que les développeur·ses n’ont pas indiqué la fermeture dudit menu.

En général, après s’être renseignés sur ces rôles menu, lorsque les développeur·ses sont face à une liste de liens pouvant s’ouvrir pour présenter une sous-liste de liens, ils ou elles pensent qu’il s’agit forcément d’un menu ARIA. Eh bien non. Tout simplement parce que cette liste de liens ne se comporte pas comme une barre de menu. Les liens permettent d’atteindre une autre page et non pas de réaliser une action comme le font des boutons. Il s’agit donc d’un autre type de composant.

De la même façon, un bouton qui permet d’ouvrir un ensemble d’options est souvent implémenté comme un menu ARIA. Si au premier abord, ce choix semble logique, cela implique également d’implémenter au moins un rôle menu et un rôle menuitem, sans oublier l’ensemble des raccourcis clavier appropriés.

En général, compte tenu de tous les problèmes que les lecteurs d’écran doivent gérer avec les menus dans les applications logicielles, il vaut mieux épargner cette expérience aux utilisateur·ices. En effet, bien souvent, le composant fonctionne correctement avec une combinaison donnée, par exemple avec NVDA et Firefox, mais il en est tout autre avec JAWS, sans parler de VoiceOver. Il ne s’agit là que d’un exemple, parfois c’est une autre combinaison qui fonctionne bien et les autres qui sont défaillantes. Faites-moi confiance, j’en ai fait l’expérience au fil des années [2].

La solution

La solution est on ne peut plus simple : n’utilisez jamais menu, menuitem, menubar, menucheckbox ou encore menuitemradio, à quelques exceptions près. Par exemple, dans un cas comme Google Docs, pour rendre accessible ce qui apparaît en appuyant sur ALT+F (ou ALT+SHIFT+F dans Firefox), c’est bien le motif de conception ARIA Menu qui sera le plus approprié. À ces très rares occasions près, oubliez ce motif de conception.

Même pour un bouton ayant pour attributs aria-haspopup="true" et aria-expanded="true" si la zone est affichée, ou false si la zone est masquée, l’expérience utilisateur sera bien meilleure si les éléments (liens, boutons, etc.) de la zone contrôlée sont structurés dans une liste ul ou li. Rien ne vous empêche ensuite d’implémenter une navigation au clavier pour :

  • permettre de se déplacer de bouton en bouton grâce aux flèches de direction ;
  • permettre la fermeture de la zone grâce à la touche Echap ;
  • après fermeture, replacer le focus sur le bouton qui permet de l’ouvrir.

Le simple fait d’éviter les rôles du motif de conception Menu améliore considérablement l’expérience utilisateur. Sans oublier que les rôles ARIA écrasent la sémantique native. Or, un·e utilisateur·ice a besoin de savoir si l’élément qu’il rencontre est un lien, qui permet généralement d’atteindre une autre page du site, ou un bouton, qui génère d’autres actions.

Quand les barres de menus n’existent pas

J’ai volontairement gardé cet aspect pour la fin : dans l’environnement mobile, ces concepts de barres de menus aux multiples tiroirs déroulants n’existent tout simplement pas.

Sur mobile, l’utilisation de ces rôles rend l’expérience utilisateur encore plus imprévisible. À l’inverse, les boutons et les liens sont très bien gérés, même sur mobile.

Les composants qui permettent d’afficher ou de masquer des zones dans les interfaces natives des systèmes d’exploitation mobiles font toujours appel à des boutons. C’est donc totalement cohérent d’en retrouver sur le web en responsive.

Conclusion

Je pense que ces rôles menu devraient être obsolètes dans WAI-ARIA 2.0, mais je comprends tout à fait que ce ne soit pas réalisable. Sans oublier qu’il y a tout de même quelques applications comme Google Docs qui implémentent ce genre de barres de menus. Ces rôles restent donc nécessaires. Mais alors, il faudrait au moins que les spécifications et les documentations ARIA déconseillent clairement leur utilisation dans 99,9 % des cas.

C’est l’une des choses les plus mal comprises par les développeur·ses web, à qui ces subtilités échappent facilement à moins d’y être aguerri·es. L’une des raisons qui les poussent à utiliser ces rôles se limite généralement à « C’est un menu qui ouvre des sous-menus, donc j’utilise les rôles menu ».

On assiste au même phénomène avec le rôle application, qui ne devrait pas être utilisé juste parce que l’on créé une application web.

Pour résumer, je dirais donc : n’utilisez jamais les rôles menu, ils n’ont que très peu de chances de s’appliquer à votre composant. Malgré toute votre bonne volonté, vous ferez plus de mal que de bien à l’expérience utilisateur. Il y a bien évidemment des exceptions, mais vous en serez probablement averti·es si vous en croisez. 😉

Notes

[1Précision du traducteur : lorsque l’on ouvre un menu contenant plusieurs entrées qui contrôlent chacune un sous-menu, on se retrouve avec deux éléments liés au focus : l’entrée qui affiche ou contient des sous-menus et les options des sous-menus. Lorsque ces éléments sont imbriqués, le focus peut concerner l’un ou l’autre de ces éléments ce qui complique la gestion du focus. C’est la raison pour laquelle ARIA ajoute des propriétés spécifiques, comme aria-activedescendant qui permet d’indiquer quelle est la position active du focus sur une liste d’items de menu.

[2Marco Zehe, l’auteur de cet article, est expert en accessibilité numérique et également un utilisateur aveugle.