[Débat] La place des liens du menu

Bonjour à tous,

Je me demande parfois où je dois placer la liste de liens qui est mon menu : avant, ou après le contenu ?
J'ai d'abord pensé que le contenu devrait être le premier élément de la page. J'avais entendu le témoignage d'un aveugle qui disait que lorsqu"il allait sur télécharger.com, il devait se taper tout les liens (et les pubs ) de la page avant d'arriver à la fiche produit.
De plus, quelque chose qui m'est arrivé il n'y a pas 15 minutes : je regardais un article d'Alsa, et j'ai voulu utiliser la touche TAB pour accéder directement au résultat du tutorial. Le premier appuis m'a mené aux liens "Wishlist", "Alsacréations", CV, etc. Bon, je me dis "ça ira plus vite de continuer à appuyer sur TAB que d'attraper la souris qui se repose à trente centimètres de là". Seulement, après le menu, la touche TAB s'est mise à sélectionner la pub Google, les pubs pour les livres chez Amazon, etc. Et je me suis dis qu'un handicapé moteur qui n'avait accès qu'à la touche tab pour passer d'un lien au suivant devait se taper tous les liens pour avoir droit au contenu...
Voilà pour ce qui me fait penser qu'il faut mettre les liens du menu à la fin de la page.

Mais j'ai lu quelque part (peut-être même sur ce forum) quelqu'un qui disait "Moi, quand je navigue avec mon portable, je préfère avoir les liens avant le contenu". En outre, j'ai aussi lu que Google tenait "plus compte" des liens placé en début de page que des liens qui font partie du reste de la page...
Donc il vaudrait mieux placer son menu en début de page.

Donc : Faut-il mieux placer son menu au début de la page, ou en fin de page ? Ai-je oublié des arguments ?

Je sais aussi que quelle que soit la place des liens, on peut la contourner avec des tabindex. Mais là, même question : le premier appuis sur TAB doit-il amener vers le premier lien du contenu de la page, ou vers le premier lien du menu ?

Je suis tout ouïe à vos réponses...

Perso, j'utilise une navigation principale (accueil, plan du site, contact, liens) avant le contenu, avec un lien "passer la navigation" avant celle-ci.

Puis une navigation secondaire après le contenu (voir aussi..., archives, liens externes, liens de courtoisie, etc...).

Alors à la question avant ou après ? je répondrais : les deux.
Modifié le 01 Dec 2004 - 22:11

Je déplace dans le salon des Discussions.
J'espère que Monique passera par là

Bonjour,

Je pense qu'il faut traiter le sujet sous deux aspects :

1/ les personnes ayant un navigateur alternatif, type vocal, qui eux préférent certainement avoir le contenu en premier pour éviter à chaque page d'avoir à se le retaper systématiquement.
Mais un lien "accéder au contenu" peut résoudre le problème si le menu est placé d'abord.
Notez au passage que le contenu en premier, pour le référencement, c'est mieux !

2/ les personnes utilisant un navigateur classique et qui se déplacent au clavier.
Là il suffit de bien déclarer ses tabulations et de prévoir deux accesskey : un pour le contenu, l'autre pour le menu. Une page sur l'accessibilité résumant le tout.

à l'occasion de différents tests que j'ai fait j'en suis arriver au sentiment suivant :

que ce soit avec un lecteur vocal ou un navigateur texte le fait au bout d'une quinzaine de pages de devoir ne serait ce qu'activer un lien d'évitement est vraiment très pénible. Celà milite donc plutôt pour les menus placer à la fin.

les accesskeys pour rejoindre les menus me paraissent bien pour quitter une consultation de contenu en cours. Dans le même ordre d'idée je trouve qu'une structuration telle que :

<h1>titre page</h1>
contenu..........
...................
..................

<h1>Menus</h1>

Peut être assez efficace dans une navigation par titre.

Je penche également pour l'option de Stephan.

Sur la nouvelle version de mon site (en cours d'écriture), j'ai prévu un sommaire principal avec un lien direct pour accéder aux données, il y a un menu secondaire pour des accès direct à certaines pages et une localisation dans le site.

C'est d'ailleurs conforme aux recommandations.

Maintenant, ça dépend aussi de la présentation prévue pour le site, si la déco permet ou prévoit le sommaire en bas de page, pourquoi pas

Donc, en résumé :
Dans la source (x)HTML, les liens seront à la fin, et avec les CSS, on peut mettre les liens là où on veut, par exemple à gauche.
On peut éventuellement reprendre les liens importants et haut de page.

C'est bien ça ?

Bonjour à toutes et tous, j'espère que vous avez passé un bon WE

Plusieurs points me gênent dans la tournure que prend cette discussion

- Lorsque l'on fait des tests, il peut nous paraître pénible de devoir utiliser le lien pour passer le sommaire à chaque page, mais n'est ce pas le fait que nous avons l'habitude de naviguer avec la souris ? Il faudrait arriver à naviguer comme un non-voyant pour mieux se rendre compte. Ce qui est proposé plus haut, me semble compliquer la navigation, en effet, si vous placez systématiquement les sommaires des sites en bas de page,
- on arrivera à des sites qui se ressemblent tous,
- on ne résout plus le problème d'origine qui est de permettre aux non-voyants de pouvoir passer le sommaire, là ils sont contraints de le lire, mais en bas de page, alors que l'idée d'origine est d'alléger les visites en permettant justement de ne pas avoir à lire le sommaire sur chaque page.

Un autre point est important, je viens de lire :

a écrit :
avec les CSS, on peut mettre les liens là où on veut

A ça, je répond oui... mais non

Techniquement, bien sur que c'est possible, mais les règles d'accessibilité nous l'interdisent (si j'ai bien tout compris...)

Référence W3C/WAI (WCAG1.0) 6.1, 9.4 - Source : Référentiel accessibilité des service Internet de l'administration française - version 2004.

De niveau bronze, le premier niveau d'accessibilité :

a écrit :

L'ordre d'apparition de l'information doit être identique lorsqu'une mise en forme spécifique est désactivée.
Certaines techniques permettent de construire la page html avec des feuilles de styles. Lorsque les feuilles de styles sont désactivées par l'utilisateur, il faut que la structure logique de la page soit respectée.
Il faut veiller que l'ordre d'apparition des divisions (DIV), par exemple, soit équivalent entre l'affichage sur un navigateur graphique et l'affichage sur un navigateur en mode textuel.

Je pensais justement que si les menus de navigation sont en bas de page, un navigateur braille ou vocal pourrait accéder au contenu sans devoir lire/entendre la navigation à chaque page (il est vrai que ce que je sais d'un navigateur vocal est très ténu...)

a écrit :
Il faut veiller que l'ordre d'apparition des divisions (DIV), par exemple, soit équivalent entre l'affichage sur un navigateur graphique et l'affichage sur un navigateur en mode textuel.

Justement, dans la plupart des cas, on met le menu de navigation à gauche ou à droite, et le contenu en vis-à-vis. Avec un navigateur graphique, le menu de navigation et le contenu apparaissent en même temps à l'écran. Mais dans la source (et donc sur un navigateur texte, etc.), lequel doit être en premier ?

Toi, tu dirais plutôt que le menu de navigation peut être en premier dans la source, cela ne pose pas de problèmes.

Je viens de faire un tour sur Opquast et sur OpenWeb, il n'y a pas de conseils répondant formellement à cette question.
Il est à noter que sur Openweb, les liens du menu de navigation principal sont en fin de la source, et à gauche de la page.
Sur le site du W3C, les liens sont au début de la source, et sur la gauche de la page.

Une question préalable: dormez-vous avec la barbe en dessous ou au-dessus de la couverture ?

... !

Cette question familière aux lecteurs d'Hergé résume bien le problème de la navigation-avant-ou-après-le-contenu:
- on peut passer des nuits blanches à argumenter pour l'un comme pour l'autre,
- dans tous les cas, une seule certitude: on mécontentera une moitié de la population.

Et encore, on oublie les adeptes du bouc à deux pointes qui coupent leur menu en 2 (voir le message de Stephan)...
Finalement, la seule vrai solution au problème est de raser la barbe, et de virer enfin les menus de navigation des contenus Web où ils n'ont le plus souvent rien à faire, en exploitant vraiment les liens relatifs. Je sais, ce n'est actuellement pas envisageable pour des questions d'implémentation deffectueuse... Donc, en attendant, on se contente de solutions nécessairement insatisfaisantes.

Je me permettrais en fait de dire froidement: mettons les menus comme on le sent, mais:
- comme dit plus haut par d'autres intervenants, fournissons en tête de page et si nécessaire en cours de route les liens d'accès direct au contenu et au menu, les liens d'évitements de la navigation, etc.
- idem, soyons attentif aux tabindex si l'ordre naturel des liens en HTML n'est pas satisfaisant. Attention cependant aux conflits tabindex/accesskey/liens skip navigation (article de Derek Featherstone sur http://www.wats.ca ... dont je n'ai pas le lien sous la main tout de suite)
- surtout, faisons des menus brefs dans tous les cas.
- enfin, pensons que l'accessibilité n'est pas la seule problématique, et que le seul défaut d'AccessiWeb est de réduire parfois l'accessibilité à la lorgnette de brailleNet très orientée mal-voyants, un peu handicapés moteurs et pas du tout handicapés autres. Les problématiques de l'accès aux "mals-comprenant" (sic pour l'expression politiquement correcte), de l'indexation par les moteurs de recherche ou du rendu dans un mobile sont tout aussi importantes (A ce propos, un beau menu de navigation répété en tête de chaque page, sans lien d'accès au contenu, c'est exaspérant sur mon mobile).

Pour ce qui est du critère accessiWeb sur l'ordre du contenu HTML et de la présentation CSS à l'écran: BrailleNet a pris au pied de la lettre une recommandation très elliptique de la WCAG1.0, et l'a ultracisée avec un bon gros bon sens témoignant surtout d'une approche encore très hésitante de la problématique CSS:
- si un contenu a une raison fonctionnelle de figurer en haut de la page graphique... il a effectivement la même raison d'être lu en premier par un lecteur d'écran, ou rendu en premier par un navigateur texte. Bref, il a effectivement une raison structurelle de figurer en début de contenu HTML.
- mais un contenu peut tout aussi bien être "déplacé" graphiquement sans raison fonctionelle, uniquement en choix de design, et sans remettre en cause l'ergonomie ou l'accessibilité.
- Un site ne se réduit pas à une seule CSS. Pourquoi ne pas exploiter les CSS alternatives pour gérer cette problématique des layouts bousculant le HTML et d'un nécessaire layout plus proche de l'ordre HTML du contenu ?
- Un site ne se réduit pas à une CSS unique pour le media screen: il se décline avec des CSS handheld, tv, projection...

Laurent Denis a écrit :
Une question préalable: dormez-vous avec la barbe en dessous ou au-dessus de la couverture ?

... !

Cette question familière aux lecteurs d'Hergé résume bien le problème de la navigation-avant-ou-après-le-contenu:
- on peut passer des nuits blanches à argumenter pour l'un comme pour l'autre,
- dans tous les cas, une seule certitude: on mécontentera une moitié de la population.

il n'y a pas 50% de la population qui a une barbe

Le lien exact vers l'article de D. Featherstone mentionné dans mon message précédent:
http://www.wats.ca/articles/keyboardusageandtabindex/62

Donc si je comprends bien, trancher la question "liens de navigation avant ou après le contenu" revient à décider si la poule ou l'oeuf est venu en premier...
Ni l'un ni l'autre n'avait de barbe, d'ailleurs, si j'ai bien suivi mes cours de bio.

Enfin, bon, tout cela laisse le débat sans un oui ou un non définitif...

Selon l'article que M'sieur Denis citait, ils nous disent que les navigateurs gèrent mal dans leur ensemble les tabindex couplés à un lien "Aller au contenu".
Mais en même temps, si on met des tabindex, c'est pour éviter que la première pression sur tab ne conduise sur le menu ou (pire) la pub.

On en déduit que l'utilisation de tabindex peut être une bonne solution.

Donc les menus où on (v|p)eut, et les tabindex vont en premier dans le contenu.

Le tout étant de ne pas mélanger le menu de navigation et le contenu.

Bonjour,

Nous avons discuté de ce problème lors de ma formation d'expert AccessiWeb...
L'avis d'une des formatrice, non-voyante :
- pour les sites qu'elle connaît très bien, l'emplacement du menu n'a aucune importance parce qu'elle utilise toujours l'affichage de la liste des liens
- pour les sites qu'elle découvre ou connaît peu, elle préfère trouver d'abord le menu pour se faire une idée du contenu du site mais apprécie la présence de liens "Aller au menu"... en haut de page car il lui suffit d'une commande clavier pour y retourner

Je rejoins l'avis de Laurent : l'accessibilité est trop souvent comprise uniquement comme un problème d'handicap visuel.
Il ne faut cependant pas oublier que d'une part les premières initiatives sont venues du monde des non-voyants (Braillenet en France, Blindsurfer en Belgique) et que d'autre part c'est dans ce domaine que les directives à suivre par les webmasters sont les plus nombreuses - et les plus marquantes.
Je trouve que, contrairement à Blindsurfer (le nom est évocateur !), AccessiWeb a pas mal évolué dans le sens d'une prise en compte de tous les types de handicaps :
Les usages de l 'Internet par les personnes handicapées: réalités et besoins
J'ai assisté à cette journée... l'émotion du public était palpable et personne n'est sorti de là "comme avant", après avoir reçu ce que stef appelle la douche froide du développeur consciencieux
Modifié le 20 Dec 2004 - 17:41

En fait Monique, voici réellement ce qui nous manque,

- c'est soit de pouvoir tester nos sites avec les divers outils de navigations,
- soit pouvoir faire intervenir dans ce forum, de temps en temps, des personnes ayant différents handicaps dans les échanges de ce genre...

C'est un appel

Bonjour,

D'accord avec toi dominique... enfin presque, je supprimerais le mot soit

Bonjour monique,

Voui !!! tu as raison !

Et tu connais des personnes susceptibles de nous rendre visite ?
Modifié le 21 Dec 2004 - 14:40

Bonjour

Etant donné que je reprend cette discussion au vol, j'ai pus lire pas mal d'avis, et le problème est que même chez les non-voyants, les avis semblent partagés (pour prendre l'exemple des non-voyants bien entendu, je n'oublie pas les handicapés moteurs et autres handicapés ).

Au final, je pense aussi que tout dépend du site. Mon site par exemple ne comporte aucune pub, mais le menu peut paraître assez long (24 rubriques...). Donc on serait tenté de dire que passer le menu n'est pas gênant vu qu'il n'y a que le menu, mais d'autre part il est assez long... A mon avis, il faut donc adapter le codage à chaque site. On ne peut pas dire que chaque site doit utiliser tel outil, pour le mien par exemple il faudrait que je mette mon menu en fin de source et que je le positionne ensuite grâce à une CSS, alors que certains comme le site d'un copain qui ne comporte que 5 rubriques peuvent très bien laisser leur menu. Mais là encore, cela pose un problème, car comme plusieurs le disent, les personnes handicapées n'ont pas forcément les mêmes attentes, et la personne qui veut lire mon menu doit, si je place celui-ci en fin de source, se taper tout le contenu qui peut être assez long également...

C'est donc un problème très complexe, mais je ne sais pas ce que sont les acceskey etc... Si j'ai bien compris, c'est un moyen de contourner le menu pour atteindre le contenu par exemple, n'est-ce pas ? Eh bien, je pense que c'est une bonne solution, à mon avis, la plus utile d'après moi pour palier ce genre de problèmes actuellement.

Comme le proposent Dominique et Monique : le mieux serait d'avoir sur ce forum l'avis de personnes plus concernées que nous

Apparté : Juste pour info Skybattle

Les "acceskey" ne sont pas un moyen de passer outre les sommaires, c'est la possibilité d'associer à un lien un raccourci clavier. En d'autres termes, si tu navigues sans souris, une association de touches du clavier te permettra d'atteindre directement le lien que tu souhaites.

Ok Dominique, merci, je vais pas faire du HS total, j'vais me documenter moi-même sur le sujet (vi, j'ai des questions là-dessus lol mais je devrais trouver ça en cherchant ^^)