Les menus géants et leurs dérives...

Bonjour à tous,

alors que les menus dits "géants" sont acclamés par les ergonomes et qu'on les voit proliférer sur les sites à contenu dense (notamment pour la vente en ligne), je me questionne sur certaines dérives dont ils font l'objet :

* ergonomiquement parlant tout d'abord, puisque certains intègrent désormais des outils de recherche comme sur laredoute.fr.
Un champ de recherche peut être considéré comme un outil de navigation, mais a-t'il vraiment sa place dans un menu déroulant ?
(personnellement, je préfère l'approche 3suisses.fr pour ce point).

* sémantiquement parlant ensuite, car les techniques (html/css/js) mises en place pour les afficher viennent parfois "casser" l'imbrication logique d'une arborescence en ul/li et sous niveaux. A ce titre celui du site Adidas me paraît assez mauvais avec un mix de listes et de tableaux.

Qu'en pensez-vous ? Avez-vous d'autres exemples de bonnes et/ou de mauvaises pratiques ?

Je ne suis pas sûr que les dropdowns soient à ce point "acclamés par les ergonomes", d'ailleurs certains gros portails comme Yahoo ont fait marche arrière sur ce point.

Personnellement je trouve ça assez nul, il est souvent possible de s'en passer et c'est fréquemment le reflet d'une ergo qui veut mettre trop de choses dans sa nav principale au lieu de sélectionner intelligemment. C'est très pénible à rendre accessible de surcroît.

Cela étant sur des gros gros sites c'est parfois une bonne idée, dans les exemples élégants je pense notamment au site de Philadelphie : http://www.visitphilly.com/

Salut,

Pour ma part, je considère qu'un formulaire de recherche est un outil de navigation en ce sens qu'il constitue une aide facilitant la navigation, au même titre qu'un plan de site ou un menu de navigation. Cela dit, il n'a pas sa place dans un menu, fût-il déroulant.

STPo a écrit :
Personnellement je trouve ça assez nul, il est souvent possible de s'en passer et c'est fréquemment le reflet d'une ergo qui veut mettre trop de choses dans sa nav principale au lieu de sélectionner intelligemment. C'est très pénible à rendre accessible de surcroît.

En termes d'accessibilité, ça dépend de la manière dont l'ensemble du menu est conçu. Si les sous-menus « n'empiètent » pas sur le territoire des autres sous-menus, il est tout à fait possible de laisser tous les sous-menus déroulés sans qu'un bout soit masqué lorsque JavaScript est désactivé. Quant à la navigation au clavier, il convient de se rappeler que tous les liens d'un menu (y compris ceux de premier niveau) doivent être de vrais liens et non un simple renvoi vers l'ancre à notation raccourcie (le #) et JavaScript permet d'apporter une touche d'amélioration progressive en émulant le comportement de la pseudo-classe :hover sur un élément qui ne peut recevoir le focus, comme li.

STPo a écrit :
Cela étant sur des gros gros sites c'est parfois une bonne idée, dans les exemples élégants je pense notamment au site de Philadelphie : http://www.visitphilly.com/

Un exemple d'autant plus élégant qu'il est accessible : lorsque JavaScript est désactivé, à défaut de sous-menus déroulés (ce qui serait impossible dans cet exemple, compte tenu de la mise en forme, qui fait que les sous-menus « empiètent » sur le territoire de leurs semblables), les liens dont dépendent les sous-menus sont de vrais liens pointant vers une page rappelant la liste des sous-menus concernés.

Après, en termes d'ergonomie, c'est sûr que la multiplication de sous-menus, voire de niveaux de sous-menu, est très discutable. D'où, indirectement, l'intérêt de mettre en place des liens d'évitement : imaginez un utilisateur qui, contraint à utiliser exclusivement le clavier, appuie des dizaines de fois sur la touche de tabulation avant d'avoir le focus sur un élément du contenu, et ce à chaque page...
Modifié par Victor BRITO (26 Jul 2010 - 17:12)

STPo a écrit :
Je ne suis pas sûr que les dropdowns soient à ce point "acclamés par les ergonomes", [...]

Oui, surtout quand ils s’échappent tout seul.

Je trouve le persistant plus ergonomique : on clique pour ouvrir, on clique pour fermer... c’est quand-même plus de maitrise, c’est plus stable.

bonjour,

"tabindex=0" n'est pas suffisant pour recevoir le focus sur un élément de type li ?

knarf a écrit :
bonjour,

"tabindex=0" n'est pas suffisant pour recevoir le focus sur un élément de type li ?

Hello,

Je dis peut-être une bêtise, mais je crois bien que le focus ne peut être atteint que par les liens ou les éléments de formulaires (input, select, option). Il me semble bien que tabindex ne s'applique pas aux autres éléments. A confirmer bien entendu...

Tabindex=0 offre bien le focus aux éléments n'en disposant pas au départ.

À noter que, d'après la spécification HTML 4.01, l'attribut tabindex ne s'applique qu'aux éléments a, area, button, input, object, select et textarea. Par conséquent, la présence d'un attribut tabindex sur un élément li n'est pas valide syntaxiquement en HTML 4 et XHTML 1.

En revanche, aucune contre-indication de ce genre en HTML 5, a priori.

Mais cela fait bien partie de ARIA donc standards même si cela fait couiner le validateur ?

Victor BRITO a écrit :
À noter que, d'après la spécification HTML 4.01, l'attribut tabindex ne s'applique qu'aux éléments a, area, button, input, object, select et textarea.

Tu m’ôte les mots des mains, c’est ce que je me disais.

Patidou a écrit :
Tabindex=0 offre bien le focus aux éléments n'en disposant pas au départ.

Même si ça contredit la référence, j’ai remarqué ce phénomène aussi. Mais il est variable selon les navigateurs, justement peut-être parce que ça n’est pas dans la référence. J’ai revue hier une note laissée en commentaire dans un source HTML, ou j’avais ajouté un TabIndex="-1", un sacrilège de valeur qui est même interdite, et le commentaire disait pourtant qu’il fallait laisser ça pour que FireFox donne le focus à un élément IMG quand on clique dessus. Le commentaire date d’il y a un an.

Avec les IFRAME, même histoire, un TabIndex=0 semble parfois donner le focus à un IFRAME avec la touche de tabulation, ...mais parfois pas. Ça semble aussi compliqué que les AccessKey.

Ça me semble tellement inconsistant que j’ai viré tout les TabIndex de quelque chose (les AccessKey avec), pour faire le ménage, et tout reprendre zéro.

Puis en parlant de TabIndex, même si je vais faire hors-sujet pour le coup, une chose que je ne trouve pas commode, c’est qu’à un moment ou un autre dans le cycle des appuies sur la touche de tabulation, on se retrouve toujours à faire un tour dans les contrôles du navigateur. Ça aurait été préférable d’avoir quelque chose qui permette de ne faire le tour que dans la page, sans sortir de celle-ci, et d’avoir éventuellement une touche pour entrer et sortir de la page, je veux dire, pour activer le focus sur les contrôles du navigateur ou ceux de la page, un choix entre les deux sans les mélanger.
Modifié par hibou57 (27 Jul 2010 - 09:53)

Pour éviter les problèmes j'ajoute le tabindex=0 par programmation (comme sur cette page de test), je ne sais pas si c'est la meilleure méthode.

La valeur -1 est valide seulement par js je pense.

Patidou a écrit :
La valeur -1 est valide seulement par js je pense.

En tout cas, valide en HTML 5 (qui autorise les entiers négatifs), mais ni en HTML 4 ni en XHTML 1.

Si l'on passe par JavaScript, sauf à se faire soumettre le code (X)HTML généré, le validateur ne verra rien, bien entendu.

Cela dit, ne jamais oublier que cet attribut est à employer avec un zeste de parcimonie.

Bonjour,

Patidou a écrit :
Pour éviter les problèmes j'ajoute le tabindex=0 par programmation (comme sur cette page de test), je ne sais pas si c'est la meilleure méthode.

Dans ton exemple, tu aurais pu générer des liens en JS.

Plus généralement , le fait de passer par JS pour générer des constructions DOM qui auraient été invalidées par les outils qui opèrent sur le code "statique" est assez étrange (je ne suis pas sûr que telle était ton intention ici) : quel est l'intérêt de ces outils sinon prévenir des erreurs liées à un traitement différent du code invalide d'un navigateur sur l'autre ?

Julien Royer a écrit :
Bonjour,

Dans ton exemple, tu aurais pu générer des liens en JS.

Ok je changerai ça dès que possible.

Julien Royer a écrit :
Plus généralement , le fait de passer par JS pour générer des constructions DOM qui auraient été invalidées par les outils qui opèrent sur le code "statique" est assez étrange (je ne suis pas sûr que telle était ton intention ici) : quel est l'intérêt de ces outils sinon prévenir des erreurs liées à un traitement différent du code invalide d'un navigateur sur l'autre ?

Effectivement, le but n'était pas de bluffer les navigateurs et les validateurs : je cherchais une méthode pour rendre la navigation au clavier possible.
Modifié par Patidou (27 Jul 2010 - 12:15)