[Résolu] Le flux idéal d'une page Xhtml avec CSS (menu, contenu, ...)

Bonjour tout le monde.

Dans certains sites remarquables sur l'accessibilité je remarque que l'ordre du flux est :

Liens d'évitements
------------------------
Menu principal
Contenu de la page
------------------------
Pied

Et sur d'autres sites également remarquables je remarque l'inverse :

Liens d'évitements
------------------------
Contenu de la page
Menu principal
------------------------
Pied

Tout en tenant compte de la qualité d'encodage, séparation du fond de la forme à l'aide des CSS, des acceskeys, etc ... quel est l'ordre idéal dans le flux ?

Est-il préférable dans le flux de faire passer le contenu du site avant ou après le menu principal ?

Il y a ce topic intéressant mais il ne répond pas à ma question.

http://forum.alsacreations.com/topic.php?fid=23&tid=20608&s=ordre+flux

Bonne année à toute l'équipe d'Alsacréations.
Modifié par Cinecriture (04 Jan 2007 - 15:46)

Bonjour,

Si il y a des liens d'évitements, je ne vois pas bien l'intérêt de faire passer le menu après le contenu principal... sauf si c'est pour une question de référencement.

Bonjour Benjamin

Benjamin D.C. a écrit :
Si il y a des liens d'évitements, je ne vois pas bien l'intérêt de faire passer le menu après le contenu principal... sauf si c'est pour une question de référencement.

C'est une réflexion que je me suis faite en désactivant les CCS de certains sites et en lisant ces sites en mode texte.

En mode texte, si les liens d'évitements sont suivis immédiatement par le menu principal, ça fait beaucoup de liens en début de page, il peut également avoir redondance de liens comme Aide à la navigation etc ….

En mettant le contenu de la page entre les liens d'évitement et le menu principal la lecture est tout de même plus aisée (toujours en mode texte), mais alors si le contenu de la page est conséquent le menu principal peut être très bas dans la page.

Je pose cette question car deux sites majeurs en accessibilité procèdent tout les deux de facon différente dans l'ordre de ce flux, l'un fait passer le contenu avant le menu principal et l'autre c'est l'inverse d'ou cette interrogation.

Ha oui dans mon cas, le référencement n'a pas d'importance.
Modifié par Cinecriture (03 Jan 2007 - 12:45)

Bonjour,

Cette question de l'ordre menu/contenu est un vieux démon de l'accessibilité qui revient nous hanter à intervalle régulier et qui reviendras toujours parce qu'il n'y à pas de réponse, pas d'ordre idéal, pas de recommandation.

Il n'y à que du "contexte" : du site, de son sujet, de la nature du "menu" et du périphérique de consultation.

Ce qui dois nous guider ce sont essentiellement les répercussions sur l'utilisabilité de l'ensemble.

Ce que l'on peut en dire :

Il n'y à pas de préférence sur l'ordre de la structure générale du point de vue des utilisateurs, notamment de lecteurs d'écran.

Pour l'un qui trouveras que l'ordre idéal c'est contenu/menu, vous en trouverez un autre qui affirmeras le contraire.

De même on peut considérer que le menu de navigation principal permet de contextualiser la page dans l'ensemble plus vaste du site.

Il y à par exemple une vraie différence d'approche selon que le site est une classique collection de pages "désordonnée" ou au contraire une collection fortement hiérarchisée (du genre documentation technique...).

Dans ce dernier cas un menu de navigation en tête du flux peut jouer rôle supplémentaire, surtout si l'information "page active" est rétrocédée au niveau du lien référent et qu'elle indique une "position" dans la collection.

Enfin, le "haut de page" est moins ambigüe que "quelque part dans la page" ou "le bas de page" qui n'à aucun sens dans un média non paginé.

De tous les arguments pour ou contre celui-ci est le seul qui milite vraiment pour conserver un ordre "menu/contenu", peut-être faut-il y voir la raison pour laquelle, confusément, on à une tendance naturelle à privilégier cet ordre.

En conclusion : pas de règles, "où est le site" est la seule réponse intelligente.

Mais... il y à en revanche au moins deux objectifs à respecter absolument

1. Le menu principal de navigation doit toujours être clairement identifiable, particulièrement dans le plan de la page et encore plus précisement quand il existe des structures sous-jacentes de listes de liens.

2. L'ordre de la tabulation au clavier ne doit pas poser de problème : Donc si votre menu conclus le flux et qu'il est repositionné en tête de la représentation, posez vous la question de savoir si c'est vraiment "naturel" de tabuler le contenu puis de revenir tabuler le "haut de page".

Attention, je ne dis pas que ce sera toujours problématique, mais qu'il faut se poser la question.

Jean-Pierre

jpv a écrit :
En conclusion : pas de règles, "où est le site" est la seule réponse intelligente.

Mais... il y à en revanche au moins deux objectifs à respecter absolument

1. Le menu principal de navigation doit toujours être clairement identifiable, particulièrement dans le plan de la page et encore plus précisement quand il existe des structures sous-jacentes de listes de liens.

2. L'ordre de la tabulation au clavier ne doit pas poser de problème : Donc si votre menu conclus le flux et qu'il est repositionné en tête de la représentation, posez vous la question de savoir si c'est vraiment "naturel" de tabuler le contenu puis de revenir tabuler le "haut de page".

Attention, je ne dis pas que ce sera toujours problématique, mais qu'il faut se poser la question.

Jean-Pierre

Merci infiniment Jean-Pierre.

Tu réponds parfaitement à ma question.
Modifié par Cinecriture (03 Jan 2007 - 16:28)

... j'ajouterais après JPV que si l'on tient à respecter le fameux point 10.3 il peut être préférable de placer le menu avant le contenu s'il est placé sur la gauche, et après s'il est placé à droite du contenu, mais c'est un argument qui n'a pas un poids suffisant pour être vraiment décisif.

A+

Arsene a écrit :
... j'ajouterais après JPV que si l'on tient à respecter le fameux point 10.3 il peut être préférable de placer le menu avant le contenu s'il est placé sur la gauche, et après s'il est placé à droite du contenu, mais c'est un argument qui n'a pas un poids suffisant pour être vraiment décisif.A+

Justement mon menu principal est placé à droite du contenu dans la page xhtml et dans le flux j'ai mis ce menu principal après le contenu.
Modifié par Cinecriture (03 Jan 2007 - 20:51)

Arsene a écrit :
... j'ajouterais après JPV que si l'on tient à respecter le fameux point 10.3 il peut être préférable de placer le menu avant le contenu s'il est placé sur la gauche, et après s'il est placé à droite du contenu, mais c'est un argument qui n'a pas un poids suffisant pour être vraiment décisif.

A+

Salut arsene et bonne année

AMHA ce n'est pas que l'argument n'est pas décisif mais plutôt qu'il n'a aucune valeur. Depuis quand changerait on le code html en fonction d'un rendu css déterminé ? ... Et que fait on quand on change d'avis ? ... Et que ce passe t'il quand on change d'avis toutes les 5 minutes ?



Par contre une réflexion que je me faisais dernièrement sur l'interaction possible entre un travail de construction html et un travail sur le rendu css (media screen s'entend).

Dans le rendu à l'écran trois possiblités sont très souvent exploitées pour le placement d'un menu général de navigation :
1. Au dessus du contenu (c'est le cas d'alsaS)
2. A gauche du contenu (c'est un cas très courant)
3. A droite du contenu (c'est la css par défaut de dotclear par exemple)

Ce que l'on ne trouve jamais c'est le cas de ce menu placé, dans le cas d'un rendu non paginé, sous le contenu.

Les situations 1, 2, 3 sont tout à fait gérables en css à partir d'un html "menu puis contenu".

Dans le cas d'un html "contenu puis menu" le cas 1 devient extrèmement difficile à gérer. Perso je l'ai déjà fait mais en dehors du plaisir de la jonglerie css c'est assez stérile.

Je ferai donc les mêmes réserves que les tiennes, il n'y a là toujours rien de décisif. Cela me semble néanmoins constituer une piste intéressante pour la réflexion.



Par ailleurs je dirai que la question du placement dans le flux d'un menu de navigation s'aborde de manière beaucoup plus sereine quand les menus sont ce qu'ils doivent être et non des plans de sites déroulants, et ce quelque soit la solution technique mise en oeuvre. Parce qu'évidemment le coup des 42 liens en menus, sous menus, sous sous menus, pour arriver au contenu, accès direct ou pas, ben ça fiche quand même un sacré malaise.
Modifié par clb56 (03 Jan 2007 - 21:01)

Bonjour,

a écrit :
j'ajouterais après JPV que si l'on tient à respecter le fameux point 10.3 il peut être préférable de placer le menu avant le contenu s'il est placé sur la gauche, et après s'il est placé à droite du contenu, mais c'est un argument qui n'a pas un poids suffisant pour être vraiment décisif.

Petite correction : Il n'est pas "peut être préférable" mais "il est obligatoire" : Dans un processus de validation Accessiweb un menu placé avant le contenu et repositionné à droite sur la représentation invaliderais l'item 10.3

Jean-Pierre

jpv a écrit :

Petite correction : Il n'est pas "peut être préférable" mais "il est obligatoire"

Il est surtout contestable...

... Ce qui ne change rien à l'aspect obligatoire en l'état, on est bien d'accord.

Bonjour,

a écrit :

Il est surtout contestable...

C'est un peut plus compliqué que ça...

L'objectif de Accessiweb 10.3 est de prendre en charge des scénarios d'usage où la perception de la page est "destructurée".

C'est le cas par exemple lorsqu'on utilise une loupe d'écran couplé à un lecteur vocal.

Il est facile de comprendre alors le dilemne : Le lecteur vocal va lire le flux et l'utilisateur va parcourir la page avec la loupe.

Si on inverse l'ordre menu/contenu entre le flux et sa représentation les deux aides ne vont pas restituer le même contenu et patatras.

D'où l'idée première de Accessiweb 10.3 qui est de dire qu'il faut garantir une certaine cohérence entre la structure du flux et sa représentation.

La position que je défends s'articule en plusieurs points :

1. En liant de manière définitive le flux et la représentation Accessiweb 10.3 est à contre-sens du concept de séparation structure/contenu et représentation, notamment des objectifs sous-jacents à WCAG 6.1 "Organize documents so they may be read without style sheets (en) "

2. Il interdis de fait l'utilisation de styles CSS adaptés à des périphériques spécifiques et, mais c'est une question purement technique, se révèle quasi-impossible à évaluer dés lors que sont utilisées des propriétés "délicates" comme position:fixed.

Dans ce dernier cas d'ailleurs, l'item valide ou pas selon le navigateur ce qui la fiche mal pour un item aussi "pesant"....

3. Nous avons, au travers de l'application raisonnée de WCAG, tous les items nécessaires pour garantir une cohérence entre le flux et sa représentation, essentiellement :

WCAG 9.4 "Create a logical tab order through links, form controls, and objects.." et les objectifs de linéarisation attachés à WCAG 5.3 "Do not use tables for layout unless the table makes sense when linearized".

Tout tiens évidemment dans le "raisonné", le seul avantage de Accessiweb 10.3 étant justement de contraindre l'auteur à respecter les objectifs de ces items.

Enfin le champs d'application de Accessiweb 10.3 est plus que problématique.
Dans une version très restrictive il interdis tout simplement la propriété CSS float:right, ainsi que les repositionnement à base de marges négatives, de double flottants ect...

C'est tout un pan de la conception CSS qui se retrouve bannis...

Donc cet item est effectivement contestable dans sa forme actuelle mais pas du tout, bien au contraire, dans le fond...

Jean-Pierre
Modifié par jpv (03 Jan 2007 - 22:33)

Hello et bonne année jpv

jpv a écrit :

Donc cet item est effectivement contestable dans sa forme actuelle mais pas du tout, bien au contraire, dans le fond...

a écrit :

garantir une cohérence entre le flux et sa représentation

Bon ben désolé pour mes obsessions sémantiques mais tout le problème est là justement. Il ne s'agit pas du tout de "garantir une cohérence" mais simplement d'éviter une incohérence complète, ou pour le dire de manière plus fine de garantir contre le risque d'une incohérence complète. En vouloir plus c'est en vouloir trop.
Modifié par clb56 (03 Jan 2007 - 22:43)

Une suggestion intéressante :
lis donc avec un browser texte le premier des agencements, puis le deuxième.
Et tu te rendras compte que l'un est certainement plus contraignant que l'autre...
dans ce contexte-là. C'est une des raisons qui poussent certains développeurs web, dont moi, à écrire le menu après le texte principal, même si le menu de contournement est un objectif à propos.

En effet, il semble plus "naturel" de faire passer le texte à lire avant puis de retrouver le menu en suivant.

En fait, le propos est à contextualiser non pas avec un browser web graphique, mais à réfléchir sous l'angle du browser texte, d'appareils de type handhelp (PDA), et très certainement de lecteur d'écrans... donc, à ne pas réfléchir sous l'angle de nos habitudes et de notre vision graphique des choses.

après pour les browsers graphiques, les CSS permettent de l'afficher à peu près comme il se doit d'être fait, et ensuite comme on le souhaite.
Modifié par ste (27 Jan 2007 - 18:53)