Menus & accessibilité

[marcimat]

Je vais voir on peut améliorer un peu l’accessibilité des menus de navigation.
Peut être en modifiant le HTML en conséquence. Peut être qu’il existe des librairies supers déjà ?

En tout cas le W3C propose quelques exemples et conseils :

• https://www.w3.org/WAI/tutorials/menus/application-menus/
• https://www.w3.org/WAI/tutorials/menus/application-menus-code/
• https://www.w3.org/TR/wai-aria-practices/#menu
• https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html (barre de navigation)
• https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-2/menubar-2.html (barre d’édition)

Et que contredit http://adrianroselli.com/2017/10/dont-use-aria-menu-roles-for-site-nav.html pour l’usage d’Aria… comme quoi...

Autres discussions

• http://simpleprimate.com/blog/nav-1 (pas besoin d’autre aria si <nav aria-label="une description"> est utilisé.)
• http://simpleprimate.com/blog/nav-2 (sémantique & accessibilité du bouton hamburger)
• https://www.filamentgroup.com/lab/accessible-responsive.html

[marcimat]

• https://www.smashingmagazine.com/2017/11/building-accessible-menu-systems/
• https://medium.com/@heyoka/responsive-pure-css-off-canvas-hamburger-menu-aebc8d11d793 (hamburger sans JS, avec :target sur le lien ! https://developer.mozilla.org/fr/docs/Web/CSS/:target)

[rastapopougros]

Comme dit depuis à peu près le début, avant même que ce soit public sur git :

• au niveau accessibilité, un menu en hover ET en plus où on doit longer finement en horizontal l'entrée de menu pour atteindre le second menu, ça ne va pas du tout, tout le monde n'a pas l'agilité pour ça
• au niveau logique ergonomique
  • si le sous menu prend toute la hauteur, le curseur ou le doigt de l'utilisateurice n'est plus proche de la première entrée de menu, alors qu'on a un ordre logique de préférence (en revanche, quelque soit la longueur du menu on peut tout mettre puis scroller si ça dépasse)
  • si on tente de place le sous menu à la hauteur de la première entrée, on n'est jamais sûr de pouvoir suivant la longueur (donc la hauteur) du sous menu, qui peut être très long, et en plus parfois il s'affiche alors vers le haut, et on se retrouve de nouveau avec la souris proche du dernier élément au lieu du premier (et là non plus on n'est pas sûr de tout placer suivant la longueur, car suivant la hauteur d'écran il peut parfaitement dépasser en haut aussi), et quand ça dépasse on peut pas scroller comme quand ça prend toute la hauteur

Donc pour moi les deux approches ne conviennent pas, on n'est jamais sûr de pouvoir toujours à la fois

• avoir la première entrée de sous-menu étant la plus proche de l'entrée de premier niveau
• ET être sûr en permanence de pouvoir placer autant d'entrée qu'il y en a parfois
• ET ne pas obliger les gens à des mouvements agiles (en plus horizontaux)

Le plus accessible et ergonomie, est à priori de déplier les sous-menus SOUS l'entrée principale.

Il y a plusieurs approches.

• Tout peut être là dans les menus comme actuellement, et on les déplie au clic en js ou css peu importe la technique, on aura ce qu'il faut.
• Ou bien dans WP ou Gitlab, ça ouvre réellement (vrai lien) le premier élément du sous menu + ça ouvre alors le sous menu en cours sous l'entrée de premier niveau + pour celleux qui sont agiles, sur les menus NON ouverts, il y a un sous menu hover raccourci (mais donc le menu hover n'est qu'une amélioration progressive en plus du reste qui marche !)

Actuellement tout de suite maintenant : nous ne sommes PAS capables de produire la navigation de Wordpress ou Gitlab, car nous ne savons pas ouvrir le bon menu en permanence suivant la page où on se trouve. Car pour l'instant l'admin de SPIP n'a aucune structure et on ne sait pas "où on se trouve" réellement, de manière explicite déclarative.

Du coup pour le moment, la seule manière accessible que je vois, c'est d'ouvrir en dépliage js ou css sous le premier niveau.

Quand on aura vraiment amélioré l'admin, on pourra peut-être reproduire comme WP ou gitlab, mais ça c'est pas pour maintenant.

[marcimat]

Je commente juste un point : On peut savoir ouvrir le premier item du menu. Et pour tous les items du menu on peut savoir aussi ouvrir le menu correspondant. Donc le problème de dépliement du menu sur l’entrée active ne se pose pas vraiment pour les éléments du menu, mais pour les éléments hors menu. Par exemple toutes les pages exec=configurer_xx, qui devraient déplier le menu configurer j’imagine.

On pourrait se baser sur une heuristique de nommage. Tout exec qui commence par configurer_ => menu configurer ouvert. Après est-ce que ça apporte réellement qu’il soit ouvert si on ne connait pas la suite de la hiérarchie… pas sûr.

Le principal souci est quand même ce menu configurer à rallonge. Éric souhaitait le découper en 3 sous entrées (mais je ne me rappelle plus lesquelles et ne trouve pas d’article. Il y a bien http://blog.smellup.net/spip.php?article45 mais ça cause pas de menu).

[marcimat]

Faut il respecter les conventions qui semblent présentes sur les outils maintenant ? Et quelles sont elles ?

• L’utilisateur en haut à gauche avec sa trombine, le bouton déplie. Exemple mattermost :

• Recherche et aide à droite (noter dans Discord le dépliement sur la recherche qui propose des aides, et le joli "?" pour l’aide). Mais a-t-on besoin de l’aide encore, vu comme elle n’est point à jour ?

[nd-]

Ou bien dans WP ou Gitlab, ça ouvre réellement (vrai lien) le premier élément du sous menu

Je ne suis pas fan, ça multiplie le nombre de clics / chargements de pages.

Sur le fonctionnement d'un menu entièrement vertical, un mode accordéon ne fonctionnerait pas.
Quand on déplie un menu et que les autres se replient, ce qui est sous le curseur n'est plus ce sur quoi on a cliqué.
Mais avec un simple dépliement/repliement au clic, qui ne change pas l'état des sous menus déjà ouverts, c'est simple et ça fonctionne.
Exemple :
https://codyhouse.co/demo/multi-level-accordion-menu/index.html
(pas pour le code, pour le principe)

[nd-]

J'oubliais : beau boulot, bravo @tcharlss 👍

[rastapopougros]

@nd- oui je pense moi à un plié déplié, pas du tout à un accordéon qui est rarement utilisable.

Pour le clic, si c'est utilisable car dans wordpress et gitlab c'est en conjonction avec un raccourci hover (pour celleux qui peuvent l'utiliser), du coup ça passe (et en nombre de clics c'est le même, mais chargement de page en plus ça oui).

[marcimat]

Bon, j’ai envoyé des menus uniquement dépliants. Pour le bandeau haut la sémantique devrait être plus conforme (nav + button + aria-expanded > liste). Pour le menu de navigation latéral, j’ai juste ajouté le nav, en conservant les listes imbriquées.
On va voir à l’usage. Par contre, il va falloir que @tcharles refasse une passe de décoration je crois ^^

[rastapopougros]

Super @marcimat, merci ! C'est bien à ça que je pensais, dans l'état actuel de nos menus (càd sans qu'on ait de hiérarchie explicite pour l'instant et qu'on sache ouvrir etc). Et je trouve ça immensément plus simple et clair, comme je m'y attendais !

Le nombre de clics n'est pas important du tout, déjà ça ne fait qu'un seul clic en plus, et dans tous les cas, de multiples articles d'ergonomes expliquent depuis un certain temps que le but n'est pas du tout de réduire le nombre de clics au minimum (ni de plafonner à 3 arbitrairement), mais que les clics soient logiques et compréhensibles par rapport à l'action qu'on veut faire ou l'infos qu'on veut atteindre.

Là c'est super, et bien plus simple à naviguer pour tout le monde, handicap ou pas.

[tcharlss]

Pas mal du tout, tout ça, merci @marcimat :)
Plus qu'un bouton pour replier le menu, un petit coup de pinceau et ça devrait être bon.