5139 sujets

Le Bar du forum

Standards : être plus royaliste que le roi ?

Pages :
Administrateur
Les Standards sont à la mode.
Les webmasters ont redécouvert depuis quelques mois (une ou deux années au plus), des balises qui leur étaient totalement étrangères (ou plutôt qui leur paraissaient peu utiles) auparavant. C'est le cas des Listes de Définition (<dl>), ou des classiques <strong> et <em> venus "remplacer" les déclassées <b> et <i>.

Un vent nouveau de sémantique souffle dans le milieu bien pensant du webmastering : "des <div> tu n'abuseras point", "les <hn> tu utiliseras pour tes titres et non les paragraphes", "les listes tu choisiras pour tes menus", etc.
Ce qui ne dérangeait (presque) personne avant devient un sacrilège aujourd'hui.

Cette prise de conscience est tout à fait légitime. Nous savons tous que les Standards sont une brique essentielle pour l'avenir d'un Internet pour tous.

Par contre, j'ai l'occasion d'observer de plus en plus fréquemment une sorte de "sur-standardisation", de sémantisation à outrance (voir à ce sujet la "strictite aveugle" en fin de ce billet).

De plus en plus d'"experts" dans le domaine ont une interprétation des recommandations W3C qui leur est propre, confondant souvent ce que l'on peut faire et ce que l'on doit faire.
Les Standards W3C sont fréquemment clairs et stricts, mais peuvent parfois se révéler vagues ou même contradictoires (erronés ?).

Parmi ces "Règles-à-ne-pas-enfreindre-sous-peine-de-châtiment-exemplaire", j'ai retenu trois points qui paraissent des évidences mais qui mériteraient peut-être une révision de point de vue :

1. XHTML 1.1 tu utiliseras
2. Des Listes pour tes menus tu choisiras
3. Les Tableaux tu banniras

XHTML 1.1 tu utiliseras

On lit de plus en plus fréquemment des exclamations comme "Hey, mais tu n'es même pas en XHTML 1.1, pauvre de toi ! Ne sais-tu pas (arriéré) qu'il s'agit de la norme actuelle à adopter, malheureux ?".

XHTML 1.1 est effectivement la norme actuelle officielle du langage Web, et comme le recommande le W3C lui-même, chacun est invité à employer les dernières normes en date lorsqu'elles sont disponibles.

Soit. Mais avant d'être plus royaliste que le roi, passez faire une visite sur le site du W3C pour vous assurer qu'il est bien déclaré en… XHTML 1.0 ! Ce n'est pas une critique ni un reproche, loin de là. L'explication est d'ailleurs très simple : XHTML 1.1 n'est tout simplement pas encore "adapté à son environnement", c'est à dire - entre autre - à certains navigateurs (Internet Explorer par exemple).

On peut même aller plus loin en disant que le site du W3C n'est pas en XHTML, mais en… HTML (ou un langage approchant).
D'ailleurs Alsacréations est dans le même cas... et votre site soit-disant "XHTML 1.0 ou 1.1 Valid !", n'est très certainement rien d'autre qu'une sorte de "soupe" en pseudo-HTML. Pour généraliser, on peut dire que plus de 99% des sites actuellement déclarés en XHTML sont du HTML.

Tout simplement parce que tous nos sites sont présentés avec un type mime "text/html" (ce que vous déclarez dans le "content" de votre <head>)... ainsi qu'un type mime correspondant, envoyé par le serveur.

XHTML peut être présenté comme du HTML (type mime "text/html") ou du XML type mime "application/xml+xhtml"... problème : Internet Explorer ne reconnaît pas ce second type mime et personne (ou presque) ne l'utilise.
En clair, presque tous les sites actuels ne sont en fait interprétés que comme du HTML.

Laurent Denis en parle bien mieux que moi dans un billet très clair : http://blog-and-blues.org/weblog/2004/06/11/243-xhtml11-beaucoup-de-bruit-pour-rien

Pour élargir le débat, voici deux lectures anglophones très intéressantes sur le sujet : "Sending XHTML as text/html Considered Harmful" (Ian Hickson) et XHTML is invalid HTML" (Ann Van Kesteren).
Administrateur
Des Listes pour tes menus tu choisiras

La sémantique demande que l'on choisisse chaque balise en fonction de son rôle et non de son aspect par défaut.

Un menu de navigation n'est rien d'autre qu'une liste de liens et le choix sémantique est vite fait : balises de listes non ordonnées (ou ordonnées plus rarement).

Une liste permet aux navigateurs textuels ou dont les styles CSS ont été désactivés de s'afficher structurellement, les items les uns sous les autres et de manière claire.

En y réfléchissant, il n'existe pas (plus) de balise réellement adéquate pour structurer un menu de navigation : <ul> est évidemment approprié, mais ne relève que de l'extrapolation de la définition originelle d'une liste.

Pour info, selon mon dictionnaire, "liste" :

dico a écrit :
Suite continue, hiérarchisée ou non, de noms (de personnes ou d'objets) ou de signes généralement présentés en colonne.


La liste convient à un menu, mais n'est pas faite spécifiquement pour ça au départ.
En effet, qu'est-ce qui me dit objectivement qu'une liste de liens est un menu ? Bien-sûr qu'on s'en doute, mais finalement en allant faire un tour sur un site web (prenons un blog), on y trouve des Listes de liens amis, des listes d'autres blogs suivis, des listes de sponsors, etc. Tout cela sans oublier la liste qui désigne le "vrai" menu de navigation.

Toutes ces listes sont structurées à l'identique. Pourquoi celle-ci indiquerait le menu est pas une autre ? Comment permettre d'identifier clairement le menu parmi les autres listes ? Un id='menu' suffit-il ? Un title='menu' est-il plus approprié ?

Pour ce genre de raisons, l'argument de dire : "c'est une liste de liens donc c'est le menu" est un peu fragile.

Le dossier "Plongez dans l'Accessibilité" du site La Grange a choisi une solution qui me paraît relativement intéressante :

* Le menu de navigation général du site est structuré dans une liste <ul>
* Le menu horizontal ("plongez dans...") n'est qu'une suite de liens séparés par un caractère "pipe" (|)
* Le sommaire du chapitre (titre + description s'y rapportant) est structuré en liste de définition <dl>

Cette méthode permet d'isoler clairement le menu général des autres structures similaires.

Les menus horizontaux

Même s'il s'agit d'une généralisation ou d'une extrapolation, l'utilisation de listes <ul> pour construire un menu est tout à fait approprié et a un avantage indéniable : sur un navigateur texte ou lorsque les CSS ne sont pas activés, les éléments s'affichent de façon ordonnée en colonne.

Mais justement, une question concerne la présentation de menus horizontaux : pourquoi se forcer à les afficher sous forme de colonne sur les navigateurs textuels ?

Un menu horizontal conçu à l'aide de listes affichées de façon linéaire, aura un rendu vertical sur ces navigateurs, ce qui a des effets sur sa fonction : si le menu a été créé pour être horizontal, c'est pour remplir une fonction qui a été étudiée au départ.

Or, sans feuilles de styles, ce menu aura un rendu tout à fait différent du rendu sur les autres navigateurs.

Le site de La Grange n'utilise pas une liste non ordonnée pour son menu horizontal, il s'affiche de façon linéaire également sur les navigateurs textuels et ne pose aucun soucis de sémantique : il reste un groupe de liens délimités dans un bloc.

Nous en arrivons au fait : si les listes <ul> ont prouvé leur utilité en ce qui concerne les menus verticaux, sont-elles vraiment aussi performantes dans le cas de menu horizontaux ?

Le seul soucis qui me vient à l'esprit serait que des liens disposés les uns à côtés des autres seraient plus difficiles à cerner et à différencier, d'où la technique de séparation utilisée par le site de La Grange (utilisation de caractères spéciaux).
Si vous préférez ne pas afficher de caractères spéciaux de séparation, placez-les simplement dans un <span> muni d'un "visibility : hidden" ou donnez-leur la même couleur que le fond du menu.

Pour information, le site de La Grange n'est pas le seul dans son cas, le site du W3C lui-même dispose d'un menu horizontal sans liste.
Sa structure est d'ailleurs assez... originale :


<div>
<map name="introLinks" id="introLinks" title="Introductory Links">
<div class="banner">
<span class="invisible"><a class="bannerLink" title="Skip introductory links and the mission statement" 
href="#technologies" shape="rect">Skip to Technologies</a> |</span> <a class="bannerLink" title="W3C 
Activities" accesskey="A" href="/Consortium/Activities" shape="rect">Activities</a> | <a class="bannerLink" 
title="Technical Reports and Recommendations" accesskey="T" href="/TR/" shape="rect">Technical Reports</a> | 
<a class="bannerLink" title="Alphabetical Site Index" accesskey="S" href="/Help/siteindex" shape="rect">Site 
Index</a> | <a class="bannerLink" title="Help for new visitors" accesskey="N" href="/2002/03/new-to-w3c" 
shape="rect">New Visitors</a> | <a class="bannerLink" title="About W3C" accesskey="B" href="/Consortium/" 
shape="rect">About W3C</a>

| <a class="bannerLink" title="Join W3C" accesskey="J" href="/Consortium/Prospectus/Joining" shape="rect">Join 
W3C</a> | <a class="bannerLink" title="Contact W3C" accesskey="C" href="/Consortium/Contact" 
shape="rect">Contact W3C</a>
</div>
</map>
</div>


Titres de menu

Il n'existe pas (plus) de méthode pour associer un titre explicitement à un menu. La balise <hn> définit un titre de section.

Un menu est un moyen de naviguer entre ces sections ou à l'intérieur de la section... mais en lui-même fait-il partie de la section ? Fait-il partie du contenu s'il sert à naviguer dans ce contenu ? Le sommaire d'un livre fait-il partie du contenu de ce livre ?

Il me paraît incongru d'employer le même balisage pour le titre de contenu et le titre de menu.
D'autant plus qu'en appliquant un titre <hn> à un menu, on l'applique à toute la section et non explicitement à ce menu.

Bien sûr, il reste possible d'ajouter encore une balise supplémentaire générique pour entourer tout ce beau monde, voir un billet de Laurent Denis à ce sujet.

C'est là qu'interviennent les Listes de Définition autrefois quasi inutilisées et qui à présent, portés par une mode nouvelle, reviennent en force.

En l'état actuel du XHTML 1.0, les listes de définition couvrent un manque flagrant. Leur champ d'action autorisé par le W3C est large et leur efficacité l'est également : plutôt que d'utiliser des balises génériques ou des titres de section, la structure en <dl> est très claire : "titre / élément se rapportant au titre".

L'un des exemples proposés par le W3C :
a écrit :
Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words...


A moins d'être plus puriste que le W3C lui-même, les Listes de Définitions sont tout à fait adaptées à la conception de menus hiérarchiques avec une structure de la forme "titre / liens se rapportant au titre"
Administrateur
Les Tableaux tu banniras

Dernier point qui réunit les puristes des Standards du Web : le refus catégorique de l'utilisation des tableaux pour les données de présentation.

Là encore, le principe est tout à fait louable mais ce qui est à critiquer est l'excessive agressivité qui accompagne en général ce précepte : la moindre trace de cellule devient vite une verrue à cautériser d'urgence (ne le faites pas chez vous).

Effectivement, les tableaux posent des problèmes qu'il est nécessaire de prendre en compte pour permettre une Accessibilité maximale du document.

Le W3C déconseille lui-aussi l'utilisation de tableaux pour la mise en page :

W3C a écrit :
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.


Le premier hic est qu'il n'existe pas de définition objective et exhaustive de ce qu'est une donnée tabulaire : les forums, livres d'or, calendrier ou blogs font-ils partie de ce qu'on peut admettre comme donnée tabulaire ?

Ce qui pose problème avec les tableaux sont leurs enchevêtrements et imbrications, les colonnes et cellules liées (colspan, rowspan) et autres éléments de mise en forme incrustés (spacer.gif, etc.). L'ensemble forme effectivement un imbroglio déstructuré et incompréhensible lorsqu'il est proposé à un visiteur non voyant.

Ce que l'on oublie de plus en plus, avec cette mode de la standardisation à outrance, c'est qu'un tableau de présentation, simple et proprement conçu, ne pose pas de problèmes d'Accessibilité aux médias non graphiques.

A force de "déconseiller", on en vient à écarter violemment certaines utilisations des tableaux que le W3C lui-même ne réprouverait pas.

Comment s'en rendre compte ? Simplement, encore une fois en refusant d'être plus royaliste que le roi : la section WAI du W3C, celle qui informe sur ses recommandations pour l'Accessibilité, est construite... avec un tableau de présentation.

Conclusion personnelle

Les Standards sont nécessaires, mais comme toutes les bonnes choses, le mieux est souvent l'ennemi du bien. Il est souvent préférable de ne pas trop en faire ou faire à l'aveugle, de s'accorder des petites incartades en fonction du public visé par exemple... Rappelons qu'il ne s'agit finalement que de recommentations, après tout.
Raphael a écrit :
Il est souvent préférable de ne pas trop en faire ou faire à l'aveugle, de s'accorder des petites incartades en fonction du public visé par exemple... Rappelons qu'il ne s'agit finalement que de recommentations, après tout.


Exactement... dans un cadre de production, il est vivement conseillé de ne pas perdre de vu qu'un site est créer pour une cible précise dont on connait plus ou moins les habitudes d'utilisation... et que dans une moindre mesure, des cibles secondaires vont venir voir le site et eventuellement quelques utilisateurs perifériques.

Cette notion de cible (issu de principes fondamentaux de communication) permet de savoir qu'elle attitude prendre vis-a-vis des standards web et de l'utilisation que l'on peut (veut ?) en faire

Ainsi, il n'est pas necessaire de jetter la pierre à quelqu'un ayant développé un site peu ou pas semantique ou accessible si le coeur de cible est un utilisateur equipé d'un navigateur graphique
A l'inverse, il est primordiale de tenir compte des recommendations d'accessibilité dans le cas de sites destinés à des personnes victimes d'un handicape (par exemple)... et même dans ce dernier cas, les contraintes sont différentes suivant le type de handicape cible !

Concernant les normes d'accessibilités, il faut faire attention car le W3C n'est pas tout... en effet, de plus en plus d'association ou d'administration edicte leur propre règles d'accessibilités... là encore, pour répondre aux besoins d'une cibles plus ou moins spécifique. (A ce titre, les regles d'accessibilités de l'administration americaine sont plus rigoureuses que celles du W3C)

Ainsi, la connaissance des standards est une bonne choses, mais leur application doit se faire sur la base d'une refexion préalable sur l'utilisation réel qui sera faite du site et dans quel mesure et de quel manière on veut étendre le public visé.
Modifié le 08 Nov 2004 - 11:47
Je dois avouer que cette discussion a le mérite de nuancer les attitudes extrémistes qu'on commence à voir un peu partout, entre farouches défenseurs du "tout XHTML 1.1" (donc, sans AUCUN tableau), et conservationnistes avérés (que des tableaux, balises obsolètes, mais "on ne change rien, parce qu'on fait comme ça depuis des années").
Entre les deux se situent à des degrés divers des webmasters qui s'appliquent consciencieusement à décortiquer les directives du W3C et à les intégrer à leurs sites, avec plus ou moins de parcimonie (exemple : garder un tableau de structure générale - header, menu, contenu, footer - tout le reste étant en full CSS), de façon à progresser à leur rythme sur la voie qui mène au respect des standards (respect "intelligent", oserais-je dire, et non application rigoureuse et aveugle des données du W3C au mépris des autres règles élémentaires de la construction d'un site Web, ergonomie, par exemple).
Je dirais qu'autant de prosélytisme commencait à devenir douteux, et je suis heureux (si si) de lire enfin ce billet de ta part, Raphael.
Pour les tableaux, même si j'évite d'en mettre si celà est possible et simple (pour mes compétences du moment), lorsqu'on me demande de mettre en page des données type "excel" (10 colonnes, 20 lignes), je ne cherche pas midi à 14 heures et j'y vais joyeusement de belles balises <table> et autres <tr> ou <td>, sans aucune honte.
Regardons autour de nous, je veux dire du monde réel : tout n'est pas accessible à tous, même si on (qui est-ce, ce "on" au fait ?) devrait faire des efforts pour augmenter cette accessibilité.
Mais le handicap est aussi une notion floue socialement parlant, non ?
ne pas suivre aveuglément des recommandations ça me parait effectivement plutôt sain.

Par contre arguer d'un public cible pour relativiser des recommandations concernant l'accessibilité est une position qui demanderait à être elle même largement relativisée je l'ai déjà écrit dans un autre post mais je me répète.

1. L 'accessibilité est en soi préférable
2. L'accessibilité est possible
3. Pour bon nombre d'aspects c'est assez aisé à mettre en oeuvre

Si ces 3 points sont admis alors je dis que pour tout un chacun c'est idiot de ne pas faire quelques efforts là dessus et que pour les professionnels je trouve qu'une réflexion qui prenne systématiquement en compte (dans une certaine mesure) cet aspect de la création de sites web est obligatoire.

je me permet de dire ça et donc de me meler de ce qui ne me regarde pas. Mais en fait je crois que c'est à vous, Jep, Raphaël, et d'autre de définir quels sont les fondamentaux incontournables de votre métier. Celà dit je crois que
http://www.opquast.com/ avance pas mal là dessus.
Tout cela va dans le bon sens, en effet.

Quelques remarques rapides:

Il n'existe pas, et ce sera de plus en plus illusoire, "une norme", la dernière en date, la plus mieux que nec ultra. Toutes les normes HTML sont et resteront valides... longtemps, avec leurs capacités, leurs atouts, leurs limites. Les normes XHTML1.x+ sont modulaires au-dela de la période de transition "pédagogique" du XHTML1.0 : le principe de la modularité ne fait que renforcer l'idée la plus importante: la DTD qu'il faut employer est celle qui est en adéquation avec vos moyens et vos intentions.
- je m'amuse à utiliser du "vrai" XHTML1.0, car je peux techniquement le faire et que j'ai besoin d'apprendre à m'en servir (d'ailleurs, je m'en sers mal).
- Mais je pourrai aussi bien passer HTML4.01 frameset (je ne m'en suis jamais vraiment servi... il serait temps de m'y mettre) ou repasser en XHTML1.1, ou plutôt passer à une DTD personnalisée XHTML1.1 + le module target, histoire de pouvoir ouvrir validement des liens dans de nouvelles fenêtres. Ma seule raison de le faire serait que c'est possible, que c'est amusant, et que mon intention est d'apprendre: XHTML est pour partie une norme "pédagogique" destinée à introduire à l'utilisation des dialectes XML.
- mais j'utilise du bon vieux HTML4.01 lorsque les contraintes syntaxiques du XHTML me gênent, et ça arrive parfois.
- mais j'utilise du transitional quand j'ai besoin des balises dépréciées, et ça arrive souvent.
- mais je n'utilise pas de standard quand j'ai besoin de ne pas les utiliser, et même ça, ça arrive exceptionnellement.
Une norme n'est pas une question idéologique : c'est un choix technique qui se négocie au cas par cas selon des paramètres très prosaïques.

-------------

Note: le fait que le site du W3C "soit en XHTML1.0" ne montre rien et n'indique rien en dehors du choix fait par le W3C pour une partie de ses documents en ligne. C'est juste le choix actuel d'un développeur, selon ses moyens, ses intentions et l'état des implémentations.
Il arrive même aux auteurs des documents du W3C de baliser leurs documents n'importe comment, voire de diffuser des documents invalides. Bref, le W3C n'est pas le Graal, juste un organisme normatif dont il faut lire le contenu.

-------------

En matière de sémantique, évitons de faire appel aux définitions du Larousse ou d'une quelconque référence littéraire : nous ne parlons pas du sens des mots dans le langage courant, mais du sens d'un vocabulaire technique liée à des conventions normatives. En d'autres termes, <ul> est un concept normatif qui peut très bien ne pas avoir grand chose à voir avec le dictionnaire courant. Ce qui compte est son sens conventionnel dans le cadre du HTML, tel que défini par une norme concensuelle (N'oublions pas au passage que le W3C est un consortium dans lequel le concensus joue un rôle essentiel.)

-------------

"Si vous préférez ne pas afficher de caractères spéciaux de séparation, placez-les simplement dans un <span> muni d'un "display : none"."
Non, non et encore non ! Display:none:
- est conçu pour astraire un contenu du rendu quelque-soit le media, y compris vocal
- est abusivement appliqué par les navigateurs vocaux et lecteurs d'écran auquel vous voulez justement que ce contenu ne soit pas caché. Si vous ne voulez pas vous aventurer dans un domaine d'exploration délicat, ne cachez aucun contenu en vous disant qu'il sera visible dans les aides à l'accessibilité.

-------------

Les listes de définition sont inadaptées à la structuration de menus, si nous ne voulons pas les travestir en élément de structuration générique bouche-trou,
- ce qu'elles ne sont pas selon la norme
- ce qui les rendraient à peut près vides de sens et d'utilité par ailleurs.

-------------

Il n'y a pas de "mieux" ou "d'ennemi du bien". Il y a des normes:
- nécessaires pour éviter que le Web devienne une tour de Babel et pour qu'il devienne un outil plus puissant, capable de réaliser des opérations trop fastidieuses ou trop complexes pour l'utilisateur.
- des normes qui posent d'une part des exigences explicites "quantitatives", simples à appliquer, et d'autre part des exigences "qualitatives" qui demandent une réflexion au cas par cas, pour chaque contenu, en fonction de la nature de celui-ci
- qui sont en pleine évolution, ont une histoire, et comportent à ce titre des ambiguïtés, des imperfections, des manques flagrants.
L'idée est donc plutôt "la norme et rien que la norme... sachant qu'elle me demande de réfléchir".
Si vous voulez des choses simples, uniquement de l'immédiatement applicable: utilisez HTML4.01 transitional, et en cas de doute, fiez-vous aux éléments de présentation qu'elle normalise. Vous êtes assurés de limiter la casse : le Web actuel tout entier est conçu en ce sens.
Modifié le 08 Nov 2004 - 19:19
Administrateur
Merci pour ces précisions Laurent.

Laurent a écrit :
Non, non et encore non ! Display:none:
- est conçu pour astraire un contenu du rendu quelque-soit le media, y compris vocal
- est abusivement appliqué par les navigateurs vocaux et lecteurs d'écran auquel vous voulez justement que ce contenu ne soit pas caché. Si vous ne voulez pas vous aventurer dans un domaine d'exploration délicat, ne cachez aucun contenu.

Le display none est volontaire et n'a rien à voir avec le masquage des textes de contenu.
Il s'agit ici de masquer un caractère de séparation.
Peux-tu m'expliquer en quoi cela pose un problème :
- aux navigateurs sans CSS ? le caractère sera affiché, donc tout va bien
- aux navigateurs non graphiques ? que display none soit ou non pris en compte, le menu ne posera pas de problème non-plus.

Je vais remplacer par un visibility hidden, puisque cela créera au-moins un espace au cas où ce serait interprété.

Si abus il y'a, quel est exactement le problème et sur quel navigateur ?

Laurent a écrit :
Les listes de définition sont inadaptées à la structuration de menus

C'est ton avis et tu le défends.
Si les listes non ordonnées sont adaptées, alors - pour les raisons sus-décrites - les listes de définition le sont tout autant.

M'enfin, on va pas se taper dessus pour du chipotage sur des recommandations pas claires.
Raphael a écrit :
Merci pour ces précisions Laurent.
Le display none est volontaire et n'a rien à voir avec le masquage des textes de contenu.
Il s'agit ici de masquer un caractère de séparation.
Peux-tu m'expliquer en quoi cela pose un problème :
- aux navigateurs sans CSS ? le caractère sera affiché, donc tout va bien
- aux navigateurs non graphiques ? que display none soit ou non pris en compte, le menu ne posera pas de problème non-plus.

Je vais remplacer par un visibility hidden, puisque cela créera au-moins un espace au cas où ce serait interprété.


Le display:none sera pris en compte dans beaucoup de cas par les lecteurs d'écran, et l'absence de caractère "lu" entre les deux liens est problématique, que ce soit une simple gêne ou un problème ajourd'hui plus rare de liens adjacents confondus.

Visibility: hidden ne devrait effectivement pas être pris en compte par les lecteurs d'écrans, puisque c'est une propriété non vocale... Sauf qu'il est pris en compte en raison de bugs. Désolé, mais c'est la dure réalité de la non-implémentation des standards Web par les lecteurs d'écran, qui ont actuellement encore intérêt à jouer une carte strictement propriétaire, plus rentable pour eux.

Ce problème d'accessibilité est une des raison, mais pas la plus importante sur le fond, pour laquelle les listes devraient être autant que possible balisées en tant que telles. Sur le fond, une liste qui n'est pas structurée en tant que tel est inexploitable en tant que liste. Ce n'est pas une liste... Ce peut être justifié selon le contenu, peut-être. Mais c'est un choix qui doit être fait sans considération de présentation, que ce soit sur un navigateur graphique ou texte.
Administrateur
Laurent Denis a écrit :

Visibility: hidden ne devrait effectivement pas être pris en compte par les lecteurs d'écrans, puisque c'est une propriété non vocale...

Pourtant j'avais l'impression que le message était clair : que le visibility hidden soit pris en compte ou non, cela ne gênera en rien la lecture de ce menu :
- s'il est pris en compte, il y'aura simplement un espace à la place du caractère de séparation
- s'il n'est pas pris en compte, le caractère de séparation apparaît

Donc tout va bien dans tous les cas, non ?

Laurent Denis a écrit :
mais pas la plus importante sur le fond, pour laquelle les listes devraient être autant que possible balisées en tant que telles. Sur le fond, une liste qui n'est pas structurée en tant que tel est inexploitable en tant que liste. Ce n'est pas une liste...

Oui sans aucun doute : les listes doivent être structurées sous forme de liste, ça me paraît tout à fait clair.
Je suis entièrement d'accord sur ce point.
Cela n'empêche, comme cela a été dit, qu'une liste de lien ne signifie pas forcément un menu.
Raphael a écrit :

s'il est pris en compte, il y'aura simplement un espace à la place du caractère de séparation


L'espace n'est PAS un caractère imprimable. Il n'est pas lu, n'apparaît pas, n'a pas d'incidence suffisante sur le rythme de lecture...

Si l'espace était suffisant, pourquoi se casserait-on les pieds à mettre des boulets, des | et autres séparateurs, et pas simplement des espaces ?
Administrateur
Laurent Denis a écrit :

L'espace n'est PAS un caractère imprimable. Il n'est pas lu, n'apparaît pas, n'a pas d'incidence suffisante sur le rythme de lecture...

Attends, je ne suis pas sûr d'avoir compris : deux liens séparés par un espace sont bien séparés dans la lecture je suppose. Il ne va quand-même pas les lire ensemble (et les interprêter comme un lien unique) ?
Selon toi, il serait préférable que le navigateur lise "pipe" (|) ou "boulet"? Cela aurait plus de sens à l'oreille ?

Laurent Denis a écrit :

Si l'espace était suffisant, pourquoi se casserait-on les pieds à mettre des boulets, des | et autres séparateurs, et pas simplement des espaces ?

Pour faire joli visuellement. Les séparateurs sont des caractères de présentation et non de contenu.
Je ne suis pas sûr que - dans le cas de menus avec séparateurs - les concepteurs aient tous fait ce choix pour des raisons d'accessibilité, tu en conviendras.

En fait, pour ne pas rester sur ce point précis, je vais simplement proposer une solution encore plus simple : mettre des séparateurs de la même couleur que la couleur de fond du menu !
Raphael a écrit :

Attends, je ne suis pas sûr d'avoir compris : deux liens séparés par un espace sont bien séparés dans la lecture je suppose. Il ne va quand-même pas les lire ensemble (et les interprêter comme un lien unique) ?


Si, justement. Pour les lecteurs "anciens" : la distinction des liens sera très difficile à l'écoute de la page.
C'est ce que je me tue à t'expliquer ;)

C'est le sens de la réserve faite par la WAI. je cite le sens de celle-ci de mémoire: "Tant que les medias oraux ne différencieront pas les liens adjacents, on les évitera".
Il y a eu une controverse intéressante récemment sur une liste de discussion spécialisée sur l'accessibilité (WATS.ca) qui a montré rapidement que ces lecteurs un peu anciens étaient toujours uilisés.

Raphael a écrit :

Selon toi, il serait préférable que le navigateur lise "pipe" (|) ou "boulet"? Cela aurait plus de sens à l'oreille ?


Oui. C'est un séparateur efficace, à défaut d'être beau, "sémantique" ou gratifant pour l'auteur.



Raphael a écrit :

Les séparateurs sont des caractères de présentation et non de contenu.

Non.
Les séparateurs sont une simple exigence d'accessibilité en l'état de la technique, sans aucun rapport avec les questions dites "sémantiques", de contenu, de présentation.
Il s'agit tout simplement de faire avec l'état de la technologie non standard des outils d'aide à l'accessibilité.

[
Raphael a écrit :

Je ne suis pas sûr que - dans le cas de menus avec séparateurs - les concepteurs aient tous fait ce choix pour des raisons d'accessibilité, tu en conviendras.


Eh ben si. Tu voyais une autre raison à ces | ?

Raphael a écrit :

En fait, pour ne pas rester sur ce point précis, je vais simplement proposer une solution encore plus simple : mettre des séparateurs de la même couleur que la couleur de fond du menu !


C'est une solution comme une autre, sauf qu'elle échoue si l'utilisateur joue sur ses préférences de couleur d'avant-plan et d'arrière-plan.
Remarque, dans ce cas, toute cette belle présentation a de forte chance de se casser la figure, vu qu'elle est en général beaucoup trop présomptueuse et rigide. Donc cela n'a guère d'importance.
Modifié le 08 Nov 2004 - 21:44
Administrateur
a écrit :
Eh ben si. Tu voyais une autre raison à ces | ?

Tu es sérieux en disant ça ?
Tu veux dire que si on demande à une large population de webmaster pourquoi ils séparent leur menu horizontal par des grigris, ils vont répondre que c'est uniquement une question d'accessibilité aux non voyants ?
Malheureusement, c'est être très optimiste sur les travaux de la WAI et sur sa portée actuelle. Si 10% des webmasters s'en soucient, je serais déjà étonné.

a écrit :
Remarque, dans ce cas, toute cette belle présentation a de forte chance de se casser la figure, vu qu'elle est en général beaucoup trop présomptueuse et rigide. Donc cela n'a guère d'importance.

Je ne suis pas sûr d'avoir compris une nouvelle fois : des simples liens sur une ligne seraient une présentation rigide par rapport à une structure encapsulée dans des listes ?
C'est possible, je veux bien le croire, mais c'est difficile à croire quand-même.
Raphael a écrit :
Eh ben si. Tu voyais une autre raison à ces | ?

Tu es sérieux en disant ça ?


A demi. Il a des raisons historiques liés à l'esthétique, avec les moyens de l'époque. Evidemment, à l'heure des onglets en CSS, ça paraît dérisoire.
Mais on continue à s'en servir aujourd'hui chez beaucoup d'auteurs standards... pour ne pas se faire sermonner par Bobby, qui ne manque pas de réagir au moindre lien adjacent.
Le problème est qu'il est très difficile de trancher: peut-on considérer que suffisamment de lecteurs d'écrans actuels différencient les liens adjacents ? La version finale de la WCAG2.0 sera intéressante à ce sujet.
Administrateur
Raphael a écrit :
des simples liens sur une ligne seraient une présentation rigide par rapport à une structure encapsulée dans des listes ?
C'est possible, je veux bien le croire, mais c'est difficile à croire quand-même.

Tiens, pour revenir sur ce point, je viens de tester plusieurs structures sous l'outil vocal d'Opera 7.6 :

<a href="">lien 1</a> <a href="">lien 2</a>


<a href="">lien 1</a> - <a href="">lien 2</a>


<a href="">lien 1</a> | <a href="">lien 2</a>


<ul>
<li><a href="">lien 1</a></li>
<li><a href="">lien 2</a></li>
<li><a href="">lien 3</a></li>
</ul> (avec li {display: inline})


.. Et le résultat m'a étonné :
- Dans le 2è extrait, le tiret est lu comme un espace (temps d'arrêt)
- Le troisième extrait est ponctué par des caractères incompréhensibles qui, certes, séparent les liens.
- Mais surtout : le 1er extrait et le 4è extrait sont lus exactement de la même manière, même temps d'arrêt entre chaque liens.

Mais je suppose que cela dépend des outils vocaux, là encore et que celui d'Opera n'est pas performant dans ce cas précis. Enfin j'espère que les autres navigateurs vocaux montrent plus de différence avec les listes.
Administrateur
Pour calmer un peu le débat qui s'enfonce et qui s'anime, je reprends rapidement les recommandations : http://www.la-grange.net/w3c/html4.01/struct/lists.html#h-10.4

W3C a écrit :
L'élément DIR était conçu pour la création de listes de répertoires multicolonnes. L'élément MENU était conçu pour les listes de menu sur une seule colonne. Les deux éléments ont la même structure que l'élément UL, seule leur restitution diffère. En pratique, l'agent utilisateur restituera une liste DIR, ou MENU, exactement comme une liste UL.

Nous recommandons fortement d'utiliser l'élément UL à leur place.


Donc nous savons ce qui nous est recommandé de faire en attendant la balise "Liste de Navigation" avec XHTML 2 : http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-list.html#sec_11.2.

Puisque <menu> n'existe plus et que <ln> n'existe pas encore, rien pour l'instant ne définit strictement un menu de navigation... donc il nous est conseillé d'utiliser <ul>, faute de mieux.

En attendant, si on se penche sur le menu horizontal très original du W3C, on remarque des choses intéressantes comme un <map> sans image.

<div>
<map name="introLinks" id="introLinks" title="Introductory Links">
<div class="banner">
<span class="invisible"><a class="bannerLink" title="Skip introductory links and the mission statement" 
href="#technologies" shape="rect">Skip to Technologies</a> |</span> <a class="bannerLink" title="W3C 
Activities" accesskey="A" href="/Consortium/Activities" shape="rect">Activities</a> | <a class="bannerLink" 
title="Technical Reports and Recommendations" accesskey="T" href="/TR/" shape="rect">Technical Reports</a> | 
<a class="bannerLink" title="Alphabetical Site Index" accesskey="S" href="/Help/siteindex" shape="rect">Site 
Index</a> | <a class="bannerLink" title="Help for new visitors" accesskey="N" href="/2002/03/new-to-w3c" 
shape="rect">New Visitors</a> | <a class="bannerLink" title="About W3C" accesskey="B" href="/Consortium/" 
shape="rect">About W3C</a>

| <a class="bannerLink" title="Join W3C" accesskey="J" href="/Consortium/Prospectus/Joining" shape="rect">Join 
W3C</a> | <a class="bannerLink" title="Contact W3C" accesskey="C" href="/Consortium/Contact" 
shape="rect">Contact W3C</a>
</div>
</map>
</div>


Ce qui est encore plus intéressant : http://www.la-grange.net/w3c/html4.01/struct/objects.html#h-13.6.1
W3C a écrit :
L'élément MAP peut s'employer sans image associée pour des mécanismes de navigation généraux.

Ça tombe bien, des "mécanismes de navigation généraux", c'est justement très spécifique par rapport à une liste de liens qui n'est pas forcément un menu.

Avant de tirer des conclusions hâtives qui me vaudraient encore des heures de justification, je résume en 4 points :

1- le W3C utilise map dans son menu horizontal (d'ailleurs avec des <a shape="rect"> dont je ne comprend pas l'usage dans ce cas précis)
2- L'élément MAP spécifie une image cliquable côté client
3- L'élément MAP peut s'employer sans image associée pour des mécanismes de navigation généraux.
4- Map peut être soit avec AREA soit avec des éléments blocs. Dans le cas d'éléments blocs + <a> : "Les auteurs devraient utiliser cette méthode pour créer des documents plus accessibles".
Raphael a écrit :

Tiens, pour revenir sur ce point, je viens de tester plusieurs structures sous l'outil vocal d'Opera 7.6 :


Le fait que les listes à puces ne posent pas de problème d'accessibilité dus à des liens adjacents dans les lecteurs d'écran tient simplement à une question de rendu par défaut dans ceux-ci : les liens contenus dans des <li> sont clairement distingués par l'indication du changement d'item, de nature variable mais toujour s de même effet.

Pour le moteur vocal d'Opera, qui est en gros celui d'IBM HPR, Voir Opera 7.60 et la lecture vocale du balisage HTML : il ne "lit" pas par défaut les puces, mais une simple règle CSS cue-before: suffit à y remédier (A priori, elle figurera dans la CSS utilisateur en version finale).

Sinon, à propos de MAP utilisé pour signaler une série de lien de navigation : ce n'est pas implémenté dans les navigateurs actuels, ni à ma connaissance dans aucun autre media. ah... si, il y a une exception, mais tellement marginale que j'ai réussi à oublier laquelle...
Modifié le 08 Nov 2004 - 22:38
Pages :
Sujet clos
Aller à