petit-ourson Posté 14 Janvier 2005 Posté 14 Janvier 2005 Bonsoir, Je suis tombé sur un site de paris qui présente des infos sur le futur tramway des Maréchaux ! Visiblement ils ont obtenu un label mais quand on voit le contenu des 50 premières lignes, je veux bien croire que c'est un tableau accessible mais bon... Comme quoi google pour les yeux de certains est plus important ... Sinon, c'est tout de même une belle initiative ;o) Pour ne pas montrer du doigt (je crois que je peux pas), voici le rapport de accessiweb rapport.
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 (modifié) Quelques remarques rapides: - le label en question est de niveau bronze, c'est à dire le niveau minimal (donc, des ambitions d'accessibilité explicitement modestes qu'il ne faut pas juger avec des critères surévalués) - le label est récent, mais des changements ont pu être apporté depuis au site. Dans ce cas, BrailleNet précise bien que BrailleNet n'est pas responsable des modifications que les concepteurs du site pouront apporter au site après la date indiquée en début de rapport. - la démarche de BrailleNet est d'accessibiliser l'existant, avec les moyens disponibles, donc les tableaux, en effet. - le site n'utilise pas, à première vue, de tableaux imbriqués, mais des tableaux minimaux. Leur linéarisation ne semble pas compromettre l'accès au contenu. Je n'ai pas examiné le site en détail, et certains détails sont sans doute problématiques ([edit] quoique contrairement à ce qu'il m'avait semblé d'abord, il y a bien un lien d'évitement de la navigation [/edit] ), mais le problème me semble plutôt relever d'une certaine incompréhension (fréquente) de la démarche de BrailleNet dans le petit monde des Standards (ce qui n'exclut pas un problème probable de lisibilité de cette démarche, qui n'est pas toujours bien expliquée) Modifié 15 Janvier 2005 par LaurentDenis
Monique Posté 15 Janvier 2005 Posté 15 Janvier 2005 Bonjour, Les directives du WCAG n'interdisent pas l'utilisation de tableau, même pour la mise en page. Elles recommandent cependant d'en limiter l'usage aux tableaux de données. Une mise en page à l'aide de tableaux correctement utilisée n'est pas un obstacle à l'accès au contenu de la page. Mais il ne faut pas oublier que - en plus du contenu, une synthèse vocale donne des informations sur la nature et la fonction des éléments utilisés dans le code (en bleu dans les exemples ci-dessous) - même si l'utilisateur y est habitué, la navigation à l'aide d'une synthèse vocale est peu confortable et fait continuellement appel à la mémoire auditive. Il me semble donc important, quand le choix existe, de choisir la solution qui entraînera le moins de surcharge auditive possible. La lecture du menu tel qu'il existe sur le site en question : Summary colon Navigation principale Table with five columns and one row Link Graphic Pourquoi le tram ? Link Graphic Suivez la ligne Link Graphic Les plus du tram Link Graphic Ca change la ville Link Graphic Les acteurs du projet Table end La lecture du menu s'il était présenté sous forme de liste et sans image : List of five items bullet Link Pourquoi le tram ? bullet link Suivez la ligne bullet link Les plus du tram bullet link Ca change la ville bullet link Les acteurs du projet List end
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 Je n'ai pas examiné le site en détail, et certains détails me semblent en effet problématiques (gestion de l'interminable menu de navigation sans lien Skip navigation, par exemple), mais le problème me semble plutôt relever d'une certaine incompréhension (fréquente) de la démarche de BrailleNet dans le petit monde des Standards (ce qui n'exclut pas un problème probable de lisibilité de cette démarche, qui n'est pas toujours bien expliquée) <{POST_SNAPBACK}> C'est surtout que l'interminable menu n'est pas dispo pour un navigateur graphique. On a l'impression que c'est un plan de site sans structure qui plus est pointe sur des erreurs ;o) Je vais leur poser la question ce sera plus simple.
Raphael Posté 15 Janvier 2005 Posté 15 Janvier 2005 Les directives du WCAG n'interdisent pas l'utilisation de tableau, même pour la mise en page. Elles recommandent cependant d'en limiter l'usage aux tableaux de données. Pour aller dans le sens de Monique, je signale en passant que la page de la WAI est elle-même en tableaux : http://w3c.org/WAI/
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 (modifié) Oups. Contrairement à ma première impression, erronée, il y a bien un lien d'évitement. (Comme quoi, ce type de test ne se fait pas en 5mn et nécessite bien une expertise justifiant des organismes comme Accessiweb Modifié 15 Janvier 2005 par LaurentDenis
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 Tu parles de la <A NAME="ht"></A> pour l'échappement. Enfin bon les 45 liens en début de page, ne sont pas super super bien placé non ? On a l'impression que c'est un plan du site non hierarchisé. Enfin surtout qu'ils pointent tous sur des erreurs ;o)
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 Enfin bon les 45 liens en début de page, ne sont pas super super bien placé non ? On a l'impression que c'est un plan du site non hierarchisé. Enfin surtout qu'ils pointent tous sur des erreurs ;o) <{POST_SNAPBACK}> Il faut bien que ces liens soient quelque-part Qu'ils soient en tête de page ou en fin de page, ils n'en formeront pas moins une liste de liens. Sans doute est-elle un peu longue, et pourrait-elle être dotée de plus de liens slik navigation (Le site du Grand Châlon est beaucoup mieux fait de ce point de vue). Mais je suis sur le site du Tram en ce moment avec IBM HPR, et je ne rencontre pas de liens erronés... sauf justement le seul lien d'évitement de la navigation qui, dans les pages intérieur, semble me ramener en boucle sur le menu Curieux... Heureusement, la navigation de tableau en tableau, ou de titre en itre, permet de se déplacer facilement dans la page.
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 Ne suis-je pas réveiller ? transport communtransports communs transports en commun transport paris transports paris transport urbain transport parisien transports parisiens Ce n'est pas super explicite quand même. Visiblement les liens marche pas avec le javascript ;o)
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 mdr J'oubliais de préciser que je n'utilise IE (et donc les lecteurs d'écrans) qu'en mode totalement paranoïaque : je ne profite donc ni des activeX ni des javascript du site en question... Et c'est amusant, mais ça marche beaucoup mieux comme ça
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 oui et j'ai installé IBM HPR et il ne lit pas les display:none ;o) on va pouvoir le renommé en display:motclef ... Bon visiblement ca passe bien sous IBM HPR
Monique Posté 15 Janvier 2005 Posté 15 Janvier 2005 Ben en fait, ces liens sont dans un bloc ayant la propriété display:none; donc pas lus par les synthèses vocales
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 oui en fait on est pas censé voir les 45 liens si je comprends, ils servent que pour google.
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 Bon finalement je vois plus l'intérêt de Acessiweb maintenant ;o)
Raphael Posté 15 Janvier 2005 Posté 15 Janvier 2005 Ben en fait, ces liens sont dans un bloc ayant la propriété display:none; donc pas lus par les synthèses vocales <{POST_SNAPBACK}> Attention : selon Laurent Denis, cette idée reçue est fausse : display none est malheureusement aussi interprété par les synthèses vocales : http://blog-and-blues.org/weblog/2004/08/1...-titre-en-image : Tous les medias non graphiques devraient ignorer la feuille de style et restituer le contenu du span... Mais en réalité, la plupart des lecteurs d'écrans actuels ont un comportement non conforme qui leur fait tenir compte d'une feuille de style destinée à l'écran, et appliquer fréquemment les propriétés display: none aussi bien que visibility: hidden. Le procédé aboutit donc à l'inverse de l'effet recherché, puisque l'intitulé textuel du titre disparaît tout autant que l'image dans Jaws ou IBM Home Page Reader
Raphael Posté 15 Janvier 2005 Posté 15 Janvier 2005 oui en fait on est pas censé voir les 45 liens si je comprends, ils servent que pour google. <{POST_SNAPBACK}> Oui d'ailleurs http://www.google.fr/intl/fr/webmasters/guidelines.html : Évitez texte caché et liens cachés.
Monique Posté 15 Janvier 2005 Posté 15 Janvier 2005 Attention : selon Laurent Denis, cette idée reçue est fausse : display none est malheureusement aussi interprété par les synthèses vocales :http://blog-and-blues.org/weblog/2004/08/1...-titre-en-image : <{POST_SNAPBACK}> Ben oui, c'est bien ce que j'ai dit, ou voulu dire (ma phrase était mal formulée ) Ces liens étant présents dans un bloc affecté de cette propriété, ils ne sont pas lus par la plupart des synthèses vocales (et dans ce cas il vaut mieux ). Par contre ils sont affichés dans un navigateur texte (je viens de faire le test avec Lynx) et comme les liens "Sauter le menu..." se trouvent après ce bloc, il faut obligatoirement "lire" la liste complète !
Raphael Posté 15 Janvier 2005 Posté 15 Janvier 2005 Ben oui, c'est bien ce que j'ai dit, ou voulu dire (ma phrase était mal formulée )Ces liens étant présents dans un bloc affecté de cette propriété, ils ne sont pas lus par la plupart des synthèses vocales (et dans ce cas il vaut mieux ). Par contre ils sont affichés dans un navigateur texte (je viens de faire le test avec Lynx) et comme les liens "Sauter le menu..." se trouvent après ce bloc, il faut obligatoirement "lire" la liste complète ! <{POST_SNAPBACK}> Autant (au temps) pour moi, c'est cerainement moi qui ai mal interprété ton message. En fait, il semblerait (toujours selon Laurent qui confirmera au besoin) que display none cumule tous les inconvénients dès lors que l'on ne s'addresse pas aux navigateurs graphiques : - les lecteurs d'écrans lisent cette propriété donc ne prennent pas en compte le contenu - les navigateurs texte (Lynx), sans styles CSS ou anciens navigateurs, même s'ils sont visuels, n'appliquent pas cette propriété et affichent le contenu alors qu'on tient à le cacher.
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 (modifié) il y a un media spécifique (supporté) pour les navigateurs d'ecran lorsque l'on veut definir une feuille de style particuliere ? media aural ou media braille sont supportés par ces navigateurs ? Visiblement IBM HPR utilise le javascript et les lit les feuilles de styles externes ce qui n'arrange pas mes affaires ;o) Modifié 15 Janvier 2005 par petit-ourson
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 Il faudra trouver le temps de revenir sur ce site, d'en analyser de près les techniques et les problèmes éventuels, car il me semble très instructif. Mais pour l'instant: - display: none, même placé dans une feuille de style explicitement réservée à l'écran, sera appliqué par les lecteurs d'écrans dans un certain nombre de cas. Il est très difficile de définir des critères généraux, car les cas de figures sont très variés en fonction du mode de lien avec la CSS, du lecteur d'écran, de la configuration utilisateur. - il n'existe à l'heure actuelle aucun lecteur d'écran ou navigateur vocal (à l'exception éventuelle du confidentiel Emacspeak, à confirmer) qui tienne compte d'une règle réservant des styles au media auditif : les descripteurs de media aural (CSS2) et speech (CSS3) ne sont pas implémentés. Même Opera 8.0 (le plus récent et le plus orienté "Standards") implémente les propriétés CSS auditives mais pas le descripteur de media lui-même (c'est en fait une nécessité pour qu'il puisse lire ce que l'utilisateur sélectionne à l'écran). Il faut bien se souvenir que les lecteurs d'écran (Jaws, Windows Eyes) sont à l'heure actuelle à peu près totalement indifférents à l'accessibilité "normalisée" et à l'approche WAI-W3C. IBM HPR est déjà plus ouvert à cette perspective, mais ce n'est qu'une ouverture...
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 Finalement l'affichage du site sans css et images decorative semble le moyen le plus facile pour mettre en place un site accessible. non ? (dans le cas ou on a pas 45 liens pour les moteurs de recherche en début de page) Je faisais mes tests sous lynx, mais visiblement c'est beaucoup plus subtil que cela.
jpv Posté 15 Janvier 2005 Posté 15 Janvier 2005 Le cas de ce site est effectivement très intéressant, puisque qu'on pourrait même discuter du bien fondé du label bronze Les 45 liens sont une grossière tentative de spam-indexing, d'autant plus stupide qu'ils ne pointent sur rien Dans le même genre on à une pollution permanente de commentaires chargés de mots clés (le plus rigolo sur la page Je suis un as du référencement !) Concernant le label bronze il faut bien reconnaitre que le niveau WAI/A est tellement peut exigeant que ça permets de valider à peut près n'importe quoi... Ce qui est intéressant c'est d'aller jeter un oeil sur le site des concepteurs/réalisateurs notamment la page :Je fais du texte en image, c'est quand même plus simple.. Pour ma part je trouve que sur ce site ils ont fait d'incroyables efforts... Plus sérieusement cela montre effectivement les "limites" de la méthode accessiweb. Comme le dit Laurent, accessiweb est focalisé sur l'accessibilité de l'existant au détriment évident d'une reflexion, en amont, sur l'ergonomie du code et des structures de page. D'un autre coté, c'est une approche qui se défendait à l'époque de la création de braillenet, parcequ'à cette époque là quand vous parliez d'accessiblité du web la première question qui venait c'était : "ha bon ? parceque les handicapés utilisent internet ???". Si en plus il fallait pointer la nécessité de réécrire le code c'était plié ! Les deux récents sites labels OR d'accessiweb, posent le même genre de problème, sur le grand chalon on trouve par exemple cette page : Zut j'ai oublié de décrire mon frameset qui invalide ipso facto le label OR. De même qu'on trouve des coqueteries de code inquiétantes chez Intégrance, l'autre label OR avec par exemple cette page : Ca c'est du code Coco ! et ses superbes : <td colspan="2" class="bgwhite"><img src="../images/common/pixel.gif" alt="|" width="1" height="1"></td> pour séparer des liens adjacents. Le problème là ne viens pas de la méthode mais bien d'un surmenage évident de l'expertise. JP
petit-ourson Posté 15 Janvier 2005 Auteur Posté 15 Janvier 2005 si si les liens pointent sur quelques choses, mais il faut désactiver le javascript. Les sites se labelisent pour leur publicité ? Avant c'était les marques de lessive qui parlait sans cesse d'écologie... Les temps changent ;o)
LaurentDenis Posté 15 Janvier 2005 Posté 15 Janvier 2005 (modifié) Je faisais mes tests sous lynx, mais visiblement c'est beaucoup plus subtil que cela. <{POST_SNAPBACK}> On a souvent dit, ou répété d'après X qui l'avait lu chez Y, etc... que les navigateurs textes étaient de bons simulacres en matière d'accessibilité (ou de sémantique, tiens, aussi : vous savez, Google est un 'utilisateur aveugle' ?) je crois de plus en plus que c'est une légende urbaine très confortable, dans les deux cas Finalement, je me demande dans quelle mesure nous ne sommes pas aujourd'hui dans un cas comparable à celui de la grande époque NS4 v. IE4 (toutes proportions gardées) : - pour les aides à l'accessibilité du type lecteur d'écran, promouvant des implémentations propriétaires en diable et totalement indifférentes à la notion de standard - dans un autre domaine (mais c'est trop évident pour ne pas le dire ici), pour les navigateurs embarqués sur les mobiles, qui se comportent de manière similaire. Bref, les acquis actuels des standards ne sont guère qu'une petite partie de l'iceberg, et ce qui est en dessous représente encore beaucoup à faire Modifié 15 Janvier 2005 par LaurentDenis
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant