Label AccessiWeb

[petit-ourson]

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]

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]

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]

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]

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]

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]

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]

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]

Ne suis-je pas réveiller ?

transport commun

transports 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]

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]

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]

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]

oui en fait on est pas censé voir les 45 liens si je comprends, ils servent que pour google.

[petit-ourson]

Bon finalement je vois plus l'intérêt de Acessiweb maintenant ;o)

[Raphael]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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