Bonjour à tous,

Après une période de maniement un peu anarchique des langages web je me suis décidé à commencer une démarche plus rigoureuse.

La première étape de ce travail étant plus ou moins réalisée , je souhaiterais avoir quelques avis éclairés.

Je vous propose donc ce lien :

http://www.freewebs.com/emmconcarneau/accueiltest.html

Merci d'avance.

Hum... J'aurais envie de dire que les meilleures solutions sont généralement les plus simples et les plus communes: les listes de définitions utilisées pour le menu de navigation n'apportent pas grand-chose du point de vue "sémantique"... Elles n'apportent en tout cas rien de plus que de simple titres <h2>Navigation</h2> et <h3>Menu général</h3>, <h3>Menu de rubrique</h3> avec des listes <ul>. En fait, elles sont moins accessibles que ceux-ci, puisque de nombreux lecteurs d'écrans permettent de naviguer à travers les titres d'une page.

Le menu de rubriques ne devrait pas apparaître en page d'accueil, puisqu'il est vide dans ce cas. Il serait par ailleurs mieux placé après le menu général qu'il développe (aller du général au particulier).

Idem pour le pied de page : quelle est l'information ajoutée par le choix d'une liste de définition au lieu de simples paragraphes ou listes ?

Les liens d'accessibilité gagneraient à être regroupés dans un menu unique en tête de page, incluant " Raccourcis", "Plan du site", "Aller au menu général". La page "politique d'accessibilité" relève plutôt du menu général.

Au passage, attention à éviter les liens différents ayant le même intitulé (2 liens Accessibilité pointent vers des cibles différentes), dont la répétition est peu compréhensible hors contexte.

Enfin, sur le fait d'éviter autant que possible <div> et <span>:
- Il y a un "anathème" excessif sur ces éléments qui sont explicitement destinés à permettre d'ajouter du style (ou du sens). Certes, il ne faut pas "remplacer" un élément HTML significatif par un <div> ou un <span>, et il est plus élégant de styler directement les éléments existants que d'ajouter des éléments neutres... Mais il ne faut pas tomber dans une chasse aux sorcières
- En revanche, le <div id="conteneur"> me surprend... puique la page est naturellement déjà contenue dans son body

à LaurentDenis

merci pour la réponse, c'est critique et c'est celà que je souhaitais.

Pour les listes de définition, je n'avais effectivement pas pensé à l'aspect navigation suivant les titres des lecteurs d'écran. Je considérais les 2 types de listes ul dl comme pouvant l'une comme l'autre être utilisées, venant de découvrir le tag dl j'en ai profité pour m'exercer. L'argument concernant l'accessibilité est incontournable donc je vais revoir ça.

Je suis surpris par la considération sur le placement relatif des 2 menus car de la même manière que j'ai placé le contenu avant les menus il me paraissait logique de poursuivre dans l'ordre du plus particulier au plus général.

Pour la chasse aux sorcières pas de souci ça ne sera pas de mon fait. Il ne s'agit pour moi que d'une méthode d'autodidactisme (j'ai vraiment 1 don pour la neolocutionalisation nulle moi ) : avant d'intégrer des div pour une mise en page particulière, être capable d'avancer à partir des éléments structurants déjà présents.

Justification du <div id="conteneur"> !!!



yen à pas (re )

g craqué. C'est quand j'ai essayé le dernier style de la liste, je me suis dit "ce srait zoli si je le centrais verticalement"... et boum

Ce que je reproche aux couples Hn + ul, c'est qu'il n'y a rien qui témoigne de leur relation directe.
Hn est un titre général, de partie de page ou de paragraphe... mais rien ne spécifie explicitement qu'il s'agit d'un titre de menu, surtout si le menu est composé de plusieurs parties et plusieurs titres (ou encore dans le cas de menus déroulants).

En fait, je compare cela aux titres de tableaux (<th>) : s'il n'existait pas ces balises pour indiquer clairement les titres, il aurait fallu trouver des alternatives moins intéressantes.

A l'époque du HTML 2, la balise <lh> indiquait clairement que cet élément de liste était le titre de la liste : la relation était directe, imbriquée dans la liste elle-même.
C'est ce que je reproche aux couples Hn + ul et que je retrouve dans les listes de définitions.

Tout cela remet en cause une page que je suis en train de mettre en place. Pour le menu j'avais penser a quelques choses comme cela :



C'est tiré par les cheveux ?

Oui, je ne vois pas l'intérêt dans ton cas d'imbriquer deux listes.

Il serait plus simple de procéder ainsi :


Ou avec les listes non ordonnées :


Quelques explications sur les listes de définitions : http://pompage.net/pompe/listesdefinitions/

Sibelius t'es trop rapide

et moi suis trop lent !

en plus il a fallu que je vérifie au validateur <dd><ul></ul<</dd>

Comme j'avais déjà été échaudé avec <dt><hn></hn></dt> (non valide)...

Sauf qu'il faut faire avec la technique disponible, et qu'HTML4.01, et par là également XHTML1.x, sont des langages de structuration à peu près "plats", sans notions de "sections" hiérarchisées et titrées. C'est frustrant, certes, mais c'est comme ça.

Utiliser <dl> à cette fin revient à tenter de transformer HTML4.01 et XHTML1.x en XHTML2.0 (élément <section> et titres <h>)... ce qui ne relève guère que de l'exercice de style (ce qui n'ôte rien à son intérêt dans ce cadre étroitement "expérimental", mais qui le déconseille en situation de production réelle).

Même remarque que précédemment. Ce code :
- est finalement plus lourd (d'un poil) qu'une simple alternance titre / liste
- sera moins accessible et efficace qu'une simple alternance titre / liste navigable via les titres.

On pourrait rétorquer qu'en bonne logique, un navigateur (graphique, vocal ou autre) devrait être capable d'extraire aussi bien les <dt> que les <h2>, <h3>... d'une page, et devrait permettre de naviguer entre ceux-ci... Sauf que ce n'est pas le cas aujourd'hui, et que nous codons aujourd'hui.

Demain, nous coderons en XHTML2.0, dans un contexte très différent

ce sont deux problématiques différentes, AHMA :
- le contenu précède les menus car il faut simplement qu'il soit restitué en premier dans les medias non CSS, pas pour le particulier et le général, mais pour que la page ne soit pas au premier regard "toujours la même" avec son fichu menu au premier écran (il faut naviguer avec un navigateur texte pour en faire l'expérience)
- le menu "principal" passe avant le menu spécifique des rubriques, parce qu'il y a effectivement là le jeu du "général" qui passe avant le "particulier", le répertoire racine accessible avant les sous-repertoire, le menu avant le sous-menu, etc.




Bravo ! Saine réaction

à LaurentDenis



perso l'expérience la plus convaincante de celà c'est quand j'ai testé mes pages (au départ structurées menu général/titre h1/sous menu/contenu) avec jaws car même avec un navigateur texte (lynx en l'occurence) le regard lui peut synthétiser donc celà reste simplement désagréable (ok très désagréable), en mode lecture d'écran celà devient vraiment insupportable.

pour les listes de définitions je remarque quand même que si l'argument de la faiblesse sémantique et la non navigabilité entre titres sont des points incontournables, le rendu vocal de ces listes est néanmoins très efficace avec jaws et que le relation terme générique/termes associés est rendu avec une grande clarté. De plus sous lynx un h1 ne donne lieu à aucune visualisation particulière (moins que l'inline strong par exemple) alors que la relation <dt><dd> si.


Ouè ouè des saines réactions j'en ai quand même de temps en temps
mais n'empêche, mes petites méthodes de travail un peu cossardes je trouve qu'elles me font pas mal progresser.

Je reprend le sujet à partir d'un des éléments de la critique de LaurentDenis



Ce point me parait pointer le défaut le + grave de mon travail.

Tout d'abord une explication de la présence du sous menu dans la page d'accueil. Il n'est là que pour mettre le message suivant "menus de rubrique, faites d'abord votre choix dans le menu général".

Or il est évident que si un tel message doit être présent c'est bien qu'il y a un problème d' ergonomie pour la navigation dans le site, le visiteur ayant cliqué une fois dans le menu général se voit obligé de penser à utiliser un autre menu à un autre emplacement.

Ce point n'est pas un problème de mise en page mais bien un problème de choix au niveau du document xhtml lui même.

Je dois dire que je peine pas mal pour sortir de l'impasse. Je ne souhaite pas utiliser de solution javascript.

Je reste sur cette idée simple: un site a un menu de navigation, pas deux ou trois. Un, c'est déjà suffisamment difficile à gérer, aussi bien pour l'auteur que pour l'utilisateur

Si, donc, un menu unique est variable selon la rubrique :
- il doit avoir d'abord une permanence, c'est à dire les items de navigations communs à tout le site, en premier.
- puis il se poursuit en se déclinant selon la rubrique, avec des séries d'items différents.

De la sorte:
- En page d'accueil, carte, Accessibilité... bref, toutes pages hors-rubrique, seule la partie générique apparaît. Dire qu'un sous-menu apparaîtra si on clique quelque-part ne sert pas à grand-chose, sauf à plonger l'utilisateur dans la perplexité : "qu'est-ce que c'est que ce menu qui avait l'air simple, et qui serait plus compliqué qu'il n'y paraît ?"
- En page "rubriquée"... l'utilisateur soupire d'aise en retrouvant son menu générique (ses repères, ses marques...), et porte son attention sur le menu spécifique qui le suit ("tiens, il y a plus à voir ici ? Voilà qui n'est pas bête !").

Finalement, ce n'est ni un problème de structure ni un problème de présentation : c'est un simple problème d'ergonomie (ou de qualité, si on veux).

Bonjour,

Lors de ma formation Accessiweb, une discussion assez animée a eu lieu sur le fait de placer d'abord le contenu ou le menu.
Un des arguments avancés par les partisans de "d'abord le contenu" est qu'il est pénible pour l'utilisateur de navigateur vocal de devoir écouter chaque fois le menu.
La position d'Accessiweb est claire cependant : d'une manière générale, d'abord le menu.
Mais Sylvie (une des formatrices, non-voyante) a nuancé.
Si le plus souvent elle apprécie d'accéder directement au contenu, il lui est pénible de devoir tout écouter si elle veut prendre connaissance du menu.

Conclusion : la présence des liens d'accès directs (au menu, au contenu...) en début de page est vraiment indispensable, dans les deux cas.

Oui bien sur et c'est bien ainsi que j'ai fait en rajoutant des accesskeys (avec précaution étant donné les limites de ceux ci que m'a indiquées LaurentDenis) comme ça si un visiteur en mode vocal veux fiche le camp de la page au milieu du contenu c'est très facile