Standards : être plus royaliste que le roi ?

(reprise du message précédent)

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

Laurent Denis a écrit :

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...

Que veux-tu dire par "pas implémenté" ? Il doit y avoir une signalisation spécifique?
Je veux dire que le menu du W3C s'affiche très correctement sur Firefox et IE, que devrait-il avoir de spécial en plus ?

Le fait que "ça s'affiche bien" n'est vraiment une preuve d'implémentation. Map a été conçu pour apporter des fonctionnalités supplémentaires, telles l'évitement des listes de liens. La question avait été abordée sur le Hub: http://www.webmaster-hub.com/index.php?showtopic=4767&view=findpost&p=38087

Laurent Denis a écrit :
Map a été conçu pour apporter des fonctionnalités supplémentaires, telles l'évitement des listes de liens.

En quoi ne fait-elle pas son travail ? Où as-tu trouvé des informations quant à une volonté d'apporter de fonctionnalités supplémentaires ?
Signifier une zone avec <map> suffit pour désigner un menu de navigation puisque c'est la fonction de cette balise.
Pourquoi extrapoler et supposer que cette balise aurait dû en faire plus ?
En tout cas, je n'ai vu nulle part dans les specs que cette balise est censée être vouée à toutes les suppositions proposées dans le topic du hub :

Laurent Denis a écrit :
Cette utilisation de map est donc valide, mais à ma connaissance, elle n'apporte rien faute de support dans les agents utilisateurs...

Elle n'a rien à "apporter" : son seul emploi suffit à définir le menu de navigation. C'est déjà un emploi fort intéressant que n'ont pas les listes (sauf si on leur prête à elles aussi des fonctionnalités supplémentaires)

Sur l'exploitation possible de MAP comme support de l'évitement des séries de liens, voir http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass

Mais quelque-chose m'échappe, Raphael, dans l'intérêt de définir un menu de navigation dans le seul but de le définir, sans que cela ait d'application concrète ?

Si je prends la peine de faire un choix de balisage, c'est avec l'intention d'en tirer un bénéfice, que ce soit au niveau auteur ou utilisateur, que ce bénéfice soit actuel ou futur.

Bien-sûr, ici, on peut utiliser l'élément MAP pour définir des séries de liens (Mais pas spécifiquement des menus de navigation de site: "L'élément MAP peut s'employer sans image associée pour des mécanismes de navigation généraux.", http://www.la-grange.net/w3c/html4.01/struct/objects.html#edef-MAP ), même si cela n'est d'aucun profit actuellement : il s'agit de se dire que c'est un moyen de favoriser l'exploitation de cet élément par tel ou tel outil. C'est la proposition que faisait Gunderson pour MAP dans http://www.webaim.org/discussion/mail_message.php?id=845 et que Karl Dubost justifie très bien d'une manière plus générale dans http://www.la-grange.net/2004/10/08.html#html4

K. Dubost a écrit :

On a commencé à voir fleurir sur le Web des articles tentant de déterminer le bon usage des balises HTML, on peut donc espérer que des produits spécialisés, des moteurs de recherche, etc, profiteront de ces éléments.

Dans cette optique, je comprendrais mieux que l'on mettre en avant l'élément MAP comme balisage des séries de liens en général.

Laurent Denis a écrit :
Mais quelque-chose m'échappe, Raphael, dans l'intérêt de définir un menu de navigation dans le seul but de le définir, sans que cela ait d'application concrète ?

Le fait de définir explicitement ce qu'est le menu dans la page me paraît déjà une application des plus concrêtes et des plus importantes.

Pour l'instant, aucune balise ne permet cela : <menu> n'existe plus (ou plutôt "est déconseillé"); <ln> n'existe pas encore.

Donc à l'heure actuelle, entre ces deux choix, il n'y a rien. Quand je dis "rien", je veux dire "rien de spécifique" (ne me fais pas dire ce que je n'ai pas dit) : une liste <ul> est parfaitement adaptée (elle est d'ailleurs conseillée) mais n'a pas ce rôle spécifique et exclusif de désigner le menu de navigation.

Comme je l'ai écrit dans le billet :

a écrit :
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.

Si un élément comme <map> était désigné comme ayant la fonction de baliser le menu de navigation, ce serait simplement la réponse à ma question.
Ensuite, si "fonctionnalités supplémentaires" il y a, je suis tout à fait preneur également.

Raphael a écrit :

Donc à l'heure actuelle, entre ces deux choix, il n'y a rien. Quand je dis "rien", je veux dire "rien de spécifique" (ne me fais pas dire ce que je n'ai pas dit) : une liste <ul> est parfaitement adaptée (elle est d'ailleurs conseillée) mais n'a pas ce rôle spécifique et exclusif de désigner le menu de navigation.
(...)
Si un élément comme <map> était désigné comme ayant la fonction de baliser le menu de navigation, ce serait simplement la réponse à ma question.

Mais il faut être bien conscient que:
- MAP n'est pas spécifiquement destiné à cet usage : il désigne n'importe quelle série de liens, en fait.
- son seul intérêt est justement dans ces "fonctionnalités supplémentaires" tel que l'évitement des listes de liens, et non dans la définition d'un type de contenu pour le principe de le définir.
-

Raphael a écrit :
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 ?

Exemple un CV, ne donne pas de « données tabulaires » (à la Excel), pourtant, la présentation en tableau me paraît tout à fait appropriée : information => valeur

David Latapie a écrit :


Exemple un CV, ne donne pas de « données tabulaires » (à la Excel), pourtant, la présentation en tableau me paraît tout à fait appropriée : information => valeur

Est-ce que tu peux préciser ton propos ?

Question débile d'un profane, pour alimenter ce débat passionnant qui n'en n'a pas besoin :

Puisque nous cherchons à séparer le contenu de la présentation, en utilisant des feuilles de style, pourquoi ne pas définir une feuille spécifique à l'accessibilité compatible avec les navigateurs spéciaux afin de présenter à ces navigateurs une information conformes et nettoyé de tous les éléments parasitant la bonne compréhensions de la page ?

Je ne comprends pas pourquoi il n'est pas définit de "règles" clair dans le domaine de l'accessibilité. Si le problème du handicap est pris en compte à sa juste valeur, les penseurs du Web se doivent de répondre à armes égales à ce besoin, non ?

ernstein a écrit :

Je ne comprends pas pourquoi il n'est pas définit de "règles" clair dans le domaine de l'accessibilité.

Tout simplement parce qu'il faudrait presque autant de règles que de personnes différentes.
Chaque handicap est différent. Chacun, avec le même handicap se comporte différemment... etc.

Des règles ont été proposées par le WAI, il S'agit des WCAG (version 2 en préparation), mais aucune liste de règles ne parviendra à prendre en compte l'ensemble des cas.

a écrit :
afin de présenter à ces navigateurs une information conformes et nettoyé de tous les éléments parasitant la bonne compréhensions de la page ?

Ce genre de chose existe : il s'agit d'une page dénuée de mise en forme (CSS désactivée) : si la structure est parfaitement navigable et compréhensible, le plus grand pas est fait.

Ok...

Ce qui me fou les boules, c'est qu'il semble qu'un certains nombres de personnes s'en foutes plein les poches sur le dos des handicapés en proposant des solutions propriétaires.

Donc le phantasme d'une solution simple n'est pas pour demain...

Il est vrai que de se faire une opinion perso sur le sujet de la structure d'un menu n'est pas simple...

Ce qui me fou aussi sur le cul, c'est que la "norme" prône l'usage sémantique des balises, sans pour autant définir de règles simples sur la mise en place d'un système de navigation, comme si nous étions dans le monde du papier, ou la seule solution pour lire un texte est de tourner la page...

Enfin quoi on parle de Web ou pas ?

Il est excellent cet échange, très enrichissant, grand merci aux intervenants...

Je refais mon site et je vais devoir revoir ma copie, en effet, comme beaucoup et par soucis de présentation, j'ai caché tout plein beaucoup de trucs destinés aux utilisateurs de navigateurs texte, je vais donc revoir ma copie

Après mûre reflexion, je me demande vraiment si je vais modifier ce que je suis en train de coder (je ne parle pas du site actuellement en ligne, je le refais).

Voici ma reflexion :

Mon site n'est pas accessible à tous, je me penche sur les standards pour le refaire. Comme je ne souhaite pas exclure les personnes qui utilisent des navigateurs texte, je sépare la présentation du contenu, ensuite j'ajoute des raccourcis clavier et met tout en oeuvre (dans les limites de mes compétences) pour augmenter l'accessibilité.

Mais quand même, je pense,
Autant il appartient aux créateurs de sites de respecter les standards,
autant il appartient aux éditeurs de navigateurs de respecter les standards,
autant il appartient aux internautes de choisir les meilleurs outils pour naviguer.

pourquoi tous les efforts devraient-ils être fait par les webmestres ?

Si on fait tout pour palier aux défaillances des navigateurs, je ne suis pas convaincu que ça fera avancer les choses plus vite. En effet, sans passer d'un extrème à l'autre bien sûr, il faut garder un juste milieu, si on imagine qu'un navigateur est abandonné au fil du temps parce qu'il ne permet pas une navigation sans problème, il est à parier que l'éditeur fera des efforts pour faire vivre son produit et corrigera un max d'erreurs ou que le produit sera abandonné.

Dans le même ordre d'idée, si un éditeur développe un navigateur texte qui interprète les feuilles de styles alors qu'il ne devrait pas, il appartient à l'internaute de choisir un produit qui lui permettra de naviguer tranquillement.

Je ne cherche surtout pas à provoquer, d'ailleurs je n'ai pas encore choisi entre le "display:none" ou gâcher ma présentation graphique. mais je me pose quand même sérieusement la question.

dominique a écrit :

Je ne cherche surtout pas à provoquer, d'ailleurs je n'ai pas encore choisi entre le "display:none" ou gâcher ma présentation graphique. mais je me pose quand même sérieusement la question.

Il me semble que l'utilisation de "clip" est une alternative viable à display: none;
Utiliser Clip pour masquer du contenu de manière accessible ?

Voici une alternative intéressante à étudier bien quelle ne soit pas complètement garantie, merci beaucoup Stephan

Merci d'avoir partagé cette discussion très instructives.

Raphael a écrit :
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.

Là il y a un truc que j'ai du mal à comprendre... sur ce site il y a un bouton permettant de passer à une mise en page sans tableaux. Donc la présence même de ce bouton implique que la mise en page par tableaux n'est pas accessible à tous mais est quand même utilisée par la W3C. De plus, n'a t'on pas dit qu'adapter le code en fonction du visiteur était une mauvaise solution ?

e-t172 a écrit :

Donc la présence même de ce bouton implique que la mise en page par tableaux n'est pas accessible à tous mais est quand même utilisée par la W3C.

Il y eu un débat (mais je ne sais plus ou ! [blog-and-blues ou alsacreations.com ou dream.media-box.net]) sur ce sujet.
Il y a moyen de construire des tableaux qui sont parfaitement accessible à toutes personnes. Il faut respecter une certaine manière et spécification pour ce tableau.
Donc en gros le tableau n'est pas bannis ! Loin de la, il est nécessaire pour le type de données correspondantes à celui-ci.

P.S. si quelqu'un serait retrouver ce topics ce serait idéal :lol:, je perd toujours tout en premier temps la tête !

Bonjour à tous

Groumphy a écrit :

Donc en gros le tableau n'est pas bannis ! Loin de la, il est nécessaire pour le type de données correspondantes à celui-ci.

C'est bien là la clé. Il faut distinguer tableau de présentation et tableau de données.

Utiliser des tableaux pour organiser une page, c'est à dire pour placer des images ou du texte, pour structurer et découper la page, n'est pas, à mon sens, "accessible". Un tableau est lu de gauche à droite, donc la première cellule d'une ligne doit correspondre, en général, à une suite logique contenue dans les cellules suivantes de la ligne.
En revanche, utiliser des tableaux pour ordonner des données, les classer, leur donner du sens ... est indispensable.
Si on avait du présenter ce tabeau : caratères invalides sans tableau, ça aurait été hard ! D'ailleurs, j'utilise le terme "présenter" mais je devrai dire "afficher" ... mais là, nous sortons de la sémantique pour entrer dans la dialectique

A mon sens, il ne faut pas bannir les tableaux. Ils sont souvent utiles, voire indispensables. Il suffit juste de les utiliser à bon escient et ne surtout pas s'en servir pour découper, organiser, présenter, architecturer une page. Les CSS sont suffisamment puissants pour s'occuper, toutes seules comme des grandes, de la présentation d'une page.