Hermann a écrit :
la règle d'accessibilité qui conseille d'ordonner les éléments
au niveau du code dans l'odre qu'ils devraient prendre pour une
lecture logique et pertinente de la page, ceux-ci devant
être le plus souvent placés le plus haut possible dans le code?
Attention,
"ceux-ci devant être le plus souvent placés le plus haut possible dans le code" ne correspond à aucune règle d'accessibilité.
Ce qui est en cause en fait, et essentiellement avec
float:right, c'est un critère accessiweb (10.3) dont la formulation s'écarte nettement des WCAG1.0:
- Accessiweb:
a écrit :
Avec les feuilles de style désactivées, l'ordre d'apparition de l'information est-il respecté par rapport à l'ordre d'apparition initialement défini ?
- WCAG1.0:
a écrit :
9.4 Create a logical tab order through links, form controls, and objects.
6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.
When content is organized logically, it will be rendered in a meaningful order when style sheets are turned off or not supported.
Cas-type: un menu horizontal aligné à droite avec des blocs <li> en
float:right (au lieu de
text-align:right et
display:inline, pour autoriser un
display:block sur les liens) crée effectivement un ordre de tabulation qui peut être déroutant, puisqu'elle commence par l'élément situé le plus à droite. Mais:
- est-il illogique pour autant, au sens où il rendrait la navigation dans le menu et la page dans son ensemble non fonctionnelle ?
- il n'empêche pas le document d'être lu sans feuille de style.
Ce type de mise en page n'est certes pas satisfaisant. Mais il faut se souvenir que cette insatisfaction tient avant tout au suremploi massif et obligé des flottants pour compenser les défauts d'implémentation CSS2.1 des deux principaux navigateurs (FF, IE) : la boîte à outils comporte tout ce qu'il faut pour éviter ces problèmes, mais les bons outils ne sont actuellement utilisables que dans Safari/Konqueror et Opera. Il faut donc opter parfois pour des compromis inconfortables entre design et accessibilité maximale.
Bref, ce critère est assez discuté. D'un côté, il est tout à fait justifié par la possibilité de créer des mises en pages dont la cohérence ne tient qu'aux feuilles de style. Mais d'un autre côté, il déborde largement de son objectif (en réunissant deux critères WCAG de portées et de priorités très différentes et en les interprétant très librement).
Enfin, pour ce qui est de placer tel ou tel partie (contenu, navigation...) le plus haut possible dans la page, il s'agit d'une
"best practice" proposée dans le contexte du web mobile :
a écrit :
Ensure that material that is central to the meaning of the page precedes material that is not... Because it is important for the user to gain an idea of the content of the page on initial view, there should be a minimum amount of clutter preceding this - including navigation, decorative images, advertising and other material that is not central to the user's experience of the page. The user should not have to scroll significantly to find the primary content of the page.
Notez cependant que la formulation (encore imparfaite) en est très prudente, et n'exclut pas la présence d'éléments de navigation en tête de page : il s'agit d'en limiter les effets sur le scroll
Modifié par Laurent Denis (17 Jul 2006 - 06:21)