Témoignage de jean-Philippe... Non Voyant

(reprise du message précédent)

a écrit :

En tout état de cause, si il est démontré que la gêne occasionné par ces aides est réelle pour une catégorie d'utilisateurs et vu le peu de bénéfice qu'on en attends, puisqu'ils ne sont réellement utiles que pour éviter "ressource", on est dans le cas ou "le mieux est l'ennemi du bien".

Dans ce cas précis le manque de liens des menus et et le nombre réduit de menus fait que effectivement la gène est beaucoup plus importante que le gain.

de plus c'est vrai que equipe editoriale et forum est à double emploie et donc permet un gain en le supprimant.


Plaçons nous maintenant dans une configuration ou les liens sont relativement nombreux d'une rubrique à l'autre.

Ressources handicaps.

Dans ce cas là de tels liens pourraient avoir leur utilités et un gain suffisant par rapport à l'eventuelle gène occasionnée non?

Dans ce cas là tout en sachant que les listes s'etofferons cela fait rajouter 4 liens pour 37 actuellement.


Si l'utilité et la pertinence dans le 2eme cas sont avérés ne pourrais t on pas par l'intermédiaire des personnes concernés savoir à partir de quel nombre de liens ou de menu une tel organisation peut être bénéfique et ou le gain sera supérieur à la gène.
Modifié par knarf (02 Jul 2005 - 23:23)

A l'évidence sur la page de ressource cela semble effectivement plus pertinent...

Je n'ai pas souvenir d'avoir eu de demande au sujet de la navigation dans des listes longues, mais tu à raison ça mérite vérification.

Les problèmes de navigation clavier sont plus sensibles sur les formulaires, les liens graphiques, les evenements javascripts, les pop-up, le rich-média et evidemment la structure de tabulation des documents, particulièrement sur des structures à trois colonnes ou il est assez difficile de synchroniser la tabulation avec le plan (l'organisation graphique).

Le recours à tabindex peut alors être une solution si on prends soin de vérifier que le chemin créé reste utilisable pour les non-voyants, problème exactement similaire à celui décrit dans ce fil...

En passant, trois autres petits détails :
- le lien accueil sur la page d'accueil mène à la page d'accueil il est donc inutile sur la page d'accueil, sinon on pourrrait croire qu'il y à une autre page d'accueil et qu'en conséquence on n'est pas sur la page d'accueil...

Blague à part, c'est très important de supprimer ce genre de lien redondant qui ne mène nul-part et sont, inévitablement source de confusion.

- Il y à encore un autre lien qui pointe vers la page "éditoriale" en pied de page avec un troisième titre différent.

- Le lien admin ne sert strictement à rien, en tout cas pour les utilisateurs, il serait préférable de le supprimer et de demander aux admins d'utiliser l'url direct.
Ce ferait un autre lien en moins (et hop... ).

JP
Modifié par jpv (03 Jul 2005 - 00:17)

a écrit :
- le lien accueil sur la page d'accueil mène à la page d'accueil il est donc inutile sur la page d'accueil, sinon on pourrrait croire qu'il y à une autre page d'accueil et qu'en conséquence on n'est pas sur la page d'accueil...

N y a t il pas une bonne pratique d'opquast spécifiant que 2 possibilité de revenir à l'accueil doivent etre présente.

En l'occurence le logo et le lien accueil.

a écrit :
Il y à encore un autre lien qui pointe vers la page "éditoriale" en pied de page avec un troisième titre différent.

Idem ce n'est pas aussi une bonne pratique opquast permettre de contacter le ou les webmasters de 2 maniéres.

par contre c'est vrai que les titres de liens ne sont pas les mêmes pour une même adresse.
Modifié par knarf (03 Jul 2005 - 00:43)

a écrit :
N y a t il pas une bonne pratique d'opquast spécifiant que 2 possibilité de revenir à l'accueil doivent etre présente.

Oui mais, un lien "accueil" sur la page d'accueil à quoi ça sert concretement ?

Pour le lien vers la page éditoriale je ne parlais que du titre.

JP

Pour le retour à l'accueil je n'ai pas retrouvé dans les bonnes pratiques d'opquast peut etre est ce dans un des labels accessiweb mais je suis sur de l'avaoir dejà vu quelquepart.

Pour le lein editoriale ok je ne l'avais pas compris comme cela

jpv a écrit :

Oui mais, un lien "accueil" sur la page d'accueil à quoi ça sert concretement ?


JP

Le sujet est un peu délicat,

Ne préconise t on pas de faire des sites dont la structure est identique sur toutes les pages? Si c le cas, le menu doit etre identique sur toutes les pages aussi et la il est question d'enlever un lien.

Ce n'est pas tres rationel tout ça

Conserver la même structure de page de page n'à rien à voir avec le contenu lui-même.

La question est de savoir si il faut désactiver les liens qui pointent sur la page active, car ma remarque est également vrais pour les autres liens.

Je n'arrives toujours pas à comprendre pourquoi on laisse le lien de la page active actif, ça me parait totalement illogique.
Ceci dit ça n'empêche pas de laisser l'intitulé pour conserver une structure identique des menus.

C'est exactement comme mettre un lien "version française" sur les pages française, on à beau retourner le problème dans tous les sens, je ne vois pas à quoi ça sert...
Modifié par jpv (03 Jul 2005 - 01:50)

knarf a écrit :
Est ce que si nous arrivons à un consensus en ce qui concerne l'intitulé des liens ou l'explication du système et qu'une tel navigation peu s'avérer être utile pour un autre type de handicap, les non voyants ou mal voyant sont ils prêt à cette petite concession pour permettre à d'autre une meilleur accessibilité.

Pourquoi vous, non voyants et mal voyants ne travailleriez vous pas à améliorer la navigation pour un autre type de handicap en prenant comme base vos propres attentes.

Avant tout, merci de ne pas m'attribuer une attitude d'indifférence envers les autres handicaps, qui n'est en aucun cas la mienne et qui est à l'opposé de tout mon engagement dans ce domaine.

Ensuite, l'orientation actuelle de l'accessibilité (WCAG, Accessiweb en particulier), est la suivante : retenir côté "sites" des solutions qui forment une base d'accessibilité commune, quelque-soit le handicap, et même hors des handicaps. C'est à dire :
- ne pas "optimiser" successivement pour chaque handicap en conciliant les inévitables contradictions rencontrées.
- mais optimiser sur une base technique potentiellement utile à tous les handicaps et acceptable par tous les utilisateurs .
- ne pas oublier que l'accessibilité a deux versants : les contenus Web, mais aussi les logiciels et matériels d'accès. C'est à ces derniers qu'il revient de personnaliser l'accès au contenu en fonction du handicap.

En matière de navigation, ces techniques communes à tous les handicaps sont en particulier:
- créer un ordre de tabulation logique à travers liens, contrôles de formulaires et objets
- prévoir des racourcis clavier vers les liens les plus importants, les contrôles de formulaires et les objets
- identifier clairement la cible de chaque lien
- grouper les liens et fournir un moyen de passer le groupe de liens en attendant que les agents utilisateurs prennent eux-mêmes en charge cette fonctionalité

Le dernier item doit être bien compris :

- contrairement aux autres, c'est une disposition temporaire, pour une fonctionnalité qui n'est pas, en fait, du ressort du contenu, mais de celui du client. Ceci invite à ne pas le privilégier par rapport aux autres techniques : c'est un pis-aller parfois indispensable actuellement, mais problématique par nature.

- contrairement aux tabindex et aux accesskeys, il conduit à ajouter des mécanismes de navigation en tant que contenu (les liens d'évitement), et non en tant que metadonnée. Autrement dit, à complexifier l'interface utilisateur. Il s'agit donc de le faire avec de grandes précautions, et de garder à l'esprit l'obligation de s'assurer que les documents soient clairs et simples, de manière à ce qu'ils puissent être facilement compris..

knarf a écrit :

pourquoi ne pas l'expliquer clairement dans la page d'accessibilité à ce moment là.

Tout mécanisme qui nécessite une explication mérite d'être revu, pour envisager d'autres approches plus intuitives. A titre d'exemple, Elie Sloim et moi-même sommes en plein dans ce travail pour l'interface utilisateur de l'atelier Opquast : nous sommes loin d'en avoir fini, mais en une semaine, plus de la moitié des mécanismes apparents ont tout simplement disparus de cet interface (aussi frustant que cela ait été pour leur développeur persuadé d'avoir mis le doigt sur l'invention du siècle ).

Revenons maintenant à ces liens d'évitements, avec ce souci de simplification.

Comme l'a bien montré jpv, l'ordre de tabulation est suffisant pour naviguer dans le menu de la page d'accueil de http://www.web-pour-tous.org/ , et l'ajout de mécanismes de navigation supplémentaire ne fait que le complexifier.

Maintenant, sur la page http://www.web-pour-tous.org/Outils-handicaps-et-accessibilite , ces liens d'évitement sont manifestement plus justifiés. Mais quid d'une table des matières en début de contenu et d'un lien de retour en fin de chaque section du contenu ?

La table des matières répond à plusieurs souci :
- donner du contenu une version synthétique, plus accessible aux handicaps cognitifs, mais surtout d'intérêt commun à tous les utilisateur (la base commune ci-dessus)
- fournir un mécanisme d'accès immédiat à chaque partie du contenu
- conjuguée à des liens de retours, permettre une navigation aisée aussi bien sans dispositif de pointage que dans un lecteur d'écran.

Il faudrait, je crois, comparer la version actuelle de http://www.web-pour-tous.org/Outils-handicaps-et-accessibilite et une version avec TOC et liens retour.
Modifié par Laurent Denis (03 Jul 2005 - 11:07)

knarf a écrit :
- le lien accueil sur la page d'accueil mène à la page d'accueil il est donc inutile sur la page d'accueil, sinon on pourrrait croire qu'il y à une autre page d'accueil et qu'en conséquence on n'est pas sur la page d'accueil...

N y a t il pas une bonne pratique d'opquast spécifiant que 2 possibilité de revenir à l'accueil doivent etre présente.

En l'occurence le logo et le lien accueil.



La BP en question indique que :

a écrit :
Il est possible de revenir à la page d'accueil depuis toutes les pages.

( http://www.opquast.org/atelier/index.php/Projet:Navigation_:_possibilité_de_revenir_à_la_page_d'accueil_depuis_toutes_les_pages - désolé, mais le forum a du mal avec les IRI de l'atelier et ne me permet pas d'utiliser la mise en forme. Probablement un test sur le caractère : deux-points à revoir, plus le fait que le forum est encore en iso-8859-1, que les IRI nécessitent le support d'utf-8, et qu'il manque au forum une fonction d'échappement des url)

Effectivement, ses solutions techniques précisent qu'on peut :

a écrit :
Prévoir un lien vers la page d'accueil sur chaque page du site. Veiller à ce que ce lien soit de préférence toujours au même endroit. Si vous placez un logo, veillez également à ce qu'il soit cliquable et revienne vers l'accueil.

D'un côté, le lien explicite vers l'accueil est la nécessité de base. D'un autre côté, l'usage a donné l'habitude aux utilisateurs de cliquer sur le logo... D'où la formulation ci-dessus.

Faut-il revoir cette solution technique ? Peut-être. C'est le moment d'en discuter dans l'atelier.

knarf a écrit :

Il y à encore un autre lien qui pointe vers la page "éditoriale" en pied de page avec un troisième titre différent.

Idem ce n'est pas aussi une bonne pratique opquast permettre de contacter le ou les webmasters de 2 maniéres.

par contre c'est vrai que les titres de liens ne sont pas les mêmes pour une même adresse.

Attention à une erreur d'interprétation sur WCAG13.1 :

a écrit :
Si plusieurs liens sur une même page ont le même libellé, tous ces liens doivent viser la même ressource

Traduction : deux libellés identiques => 2 urls identiques.

Cela ne veut pas dire qu'à l'inverse, deux urls identiques => deux libellés identiques !

La présence de 2 liens vers la même ressource avec deux intitulés différents n'est pas problématique. Et heureusement d'ailleurs, car nous aurions, sinon, un gros problème avec les liens du type http://example.org#foo1 et http://example.org#foo2 (Précision importante : ressource signifie ici URI, c'est à dire http://example.org , et les deux liens précédents visent la même ressource, même s'ils diffèrent apparemment).

Les liens de Web-pour-tous vers la page http://www.web-pour-tous.org/Equipe-Editoriale ne sont donc pas concernés par WCAG13.1. Il est vrai, cependant, que le lien en pied de page paraît inutile.
Modifié par Laurent Denis (03 Jul 2005 - 08:52)

jpv a écrit :
La question est de savoir si il faut désactiver les liens qui pointent sur la page active, car ma remarque est également vrais pour les autres liens.

Je n'arrives toujours pas à comprendre pourquoi on laisse le lien de la page active actif, ça me parait totalement illogique.
Ceci dit ça n'empêche pas de laisser l'intitulé pour conserver une structure identique des menus.

Problème beaucoup plus redoutable à l'usage qu'on ne le croit au premier abord

Voir cette belle empoignade sur l'ancien forum Opquast, où sont soulevés plusieurs problèmes suscités par la disparition ou la désactivation du lien vers la page active. (je précise que je m'y étais fait un peu l'avocat du diable, et que je me rallierais en fait à la proposition Signaler le lien en cours, oui, le désactiver, non... si cela ne faisait pas une n-ième information à différencier sur les liens (après les liens visités, les liens internes/externes, la langue cible, etc.

Le moindre mal est finalement de laisser ce lien vers la page courante sans autre forme de procès.

Quelques exemples de difficultés rencontrées par la désactivation du lien :
- Formulaire de contact : je poste un message, je valide, je serveur me renvoie la version "Votre message a été bien reçu" de la page contact. Or, je m'aperçois que mon message était incomplet et que je dois en envoyer un deuxième. Pas de lien vers la page active => Je fais comment ???
- Je veux suivre un des liens de la page dans l'onglet ou la session active de mon navigateur, mais en ouvrant la page courante à l'arrière-plan, pour pouvoir y revenir : je fais comment sans lien vers la page courante à ouvrir en arrière-plan ?
- Je navigue dans un lecteur d'écran de liens en liens dans le menu du site que j'ai bien mémorisé. Ce menu n'a plus le même contenu de page en page si le lien vers la page courante est remplacé par une simple mention du nom de page.
- je veux enregistrer la page courante et j'ai l'habitude de le faire via le menu contextuel : pas de lien vers la page courante => je ne peux pas.
- etc.
Modifié par Laurent Denis (03 Jul 2005 - 09:16)

Une dernière remarque, et je vous promets de me taire enfin

(Mais il faut dire que les questions soulevées par le message de départ de dominique et vos interventions sont très riches et très pertinentes.)

knarf a écrit :
Plaçons nous maintenant dans une configuration ou les liens sont relativement nombreux d'une rubrique à l'autre.

Ressources handicaps.

Dans ce cas là de tels liens pourraient avoir leur utilités et un gain suffisant par rapport à l'eventuelle gène occasionnée non?

Dans ce cas là tout en sachant que les listes s'etofferons cela fait rajouter 4 liens pour 37 actuellement.


Si l'utilité et la pertinence dans le 2eme cas sont avérés ne pourrais t on pas par l'intermédiaire des personnes concernés savoir à partir de quel nombre de liens ou de menu une tel organisation peut être bénéfique et ou le gain sera supérieur à la gène.

Les limites numériques peuvent être de deux types :

- limite liée à une contrainte technique objective, mesurable même si elle peut évoluer. C'est le cas pour la recommandation sur les 80 caractères au plus pour un libellé de lien, liée aux capacités de rendu des plages brailles ( http://www.opquast.org/atelier/index.php/Projet:Accessibilité_:_libellé_des_liens_inférieur_à_80_caractères et même recommandation AccessiWeb)

- limite issue d'un consensus... toujours partiel, sans contrainte mesurable, qui risquent toujours de tomber dans la généralisation abusive, faute de tenir compte de multiples autres paramètres potentiels.

Nous serions ici typiquement dans le second cas.

Tiens, prenons le référentiel Accessiweb. Nous tombons sur une limite de même nature :

a écrit :
6.7 : Y a-t-il moins de 40 liens actifs dans la page, hors liens nécessaires à la navigation ?

Pourquoi 40 ? En vertu d'un de ces consensus décrits ci-dessus, qui ne tient compte :
- ni de la structure du document : organisation titrée ?
- ni du codage du document : navigabilité par section permise par des tableaux successifs, des titres ?
- ni du contenu du document : longueur des libellés ?
- ni d'autres mécanismes d'accessibilité : table des matières ?
- ni de l'évolution des capacités du client : capacité à "paginer" un long document en plusieurs brèves pages successives, à la maniède d'Opera en mode plein écran sur les pages compatibles OperaShow, ou des proxy adaptant le contenu Web en WAP ?
- ni du choix qui peut être offert à l'utilisateur (via des préférences et un cookie) sur le nombre maximal de liens affichés par page
- etc.

A titre d'exemple :
- une page de 10 liens peut être très pénible en mode "liste de liens" lorsque les intitulés sont interminables, comme c'est typiquement le cas pour les grands quotidiens en ligne.
- A l'inverse, un glossaire alphabétique de 500 liens avec un mot unique par libellé et une structure de titrage et de navigation alphabétique n'est pas foncièrement problématique, dès lors qu'on peut aller aisément de la liste des lettres (la TOC) aux sections concernées, ou surtout utiliser un "find in page".

De telles limites numériques ne sont pas à rejeter a priori. Mais je crois qu'il faut les aborder avec prudence, et vérifier auparavant s'il n'y a pas un autre moyen qui éviterait d'avoir à quantifier le qualitatif
Modifié par Laurent Denis (03 Jul 2005 - 10:29)

a écrit :

vos interventions sont très riches et très pertinentes

Les tiennes ne sont pas mal non plus

La démonstration sur le lien de la page active me semble assez claire (sauf peut-être sur la logique applicative du formulaire que tu décris mais c'est hors-sujet).

J'aurais du préciser ma pensée en revanche pour l'item 13.1 du WCAG.
Rien à redire sur tes précisions c'est une évidence, néanmoins il faudrait alors ajouter "si c'est pertinent".
Le problème que je releve est d'avoir trois intitulés de liens très différents "contacter l'équipe","Equipe éditoriale" et "intégration:l'équipe de web-pour-tous" qui mènent vers une seule et unique page.
Cela me semble être source de confusion car ce n'est pas clair et qu'on s'attends à arriver sur trois page différentes.
D'où ma tentation de recourir au WCAG 13.1 "Identifier clairement la cible de chaque lien", c'est vrai pour chacun d'entres eux, en revanche cela me semble douteux l'un par rapport à l'autre, dans la mesure où rien ne le justifie par le contexte d'implémentation de ces liens.

Mais bon, je veux bien reconnaitre que le rappel à cet item peut paraitre un chouia abusif.

JP
Modifié par jpv (03 Jul 2005 - 11:53)

a écrit :
merci de ne pas m'attribuer une attitude d'indifférence envers les autres handicaps, qui n'est en aucun cas la mienne et qui est à l'opposé de tout mon engagement dans ce domaine.

Je crois que je me suis encore exprimé comme un pied.
Donc si je t'ai heurté toutes mes excuses ce n'etais pas du tout le but recherché.

Je voyais un truc du genre évaluation du rapport gène --> gain.

a écrit :
vos interventions sont très riches et très pertinentes
Les tiennes ne sont pas mal non plus

+1

En ce qui concerne les différentes remarque qui ont été faites on vas faire les modifications suivantes .


-Le menu projet qui est inutile puisque double emploie avec la barre de navigation.

-La suppression du lien "admin"

-Suppression des liens d'évitements dans le menu (gène plus importante que le gain)

-Suppression du petit menu "acces direct" (même raison que précedemment)

-Mettre un libellé identique à celui de la barre de navigation au lien du footer menant à équipe éditoriale.

En ce qui concerne le lien "Accueil" étant donné que le débat fait rage pour l'instant on laisse.

a écrit :
Le dernier item doit être bien compris :

- contrairement aux autres, c'est une disposition temporaire, pour une fonctionnalité qui n'est pas, en fait, du ressort du contenu, mais de celui du client. Ceci invite à ne pas le privilégier par rapport aux autres techniques : c'est un pis-aller parfois indispensable actuellement, mais problématique par nature.

- contrairement aux tabindex et aux accesskeys, il conduit à ajouter des mécanismes de navigation en tant que contenu (les liens d'évitement), et non en tant que metadonnée. Autrement dit, à complexifier l'interface utilisateur. Il s'agit donc de le faire avec de grandes précautions, et de garder à l'esprit l'obligation de s'assurer que les documents soient clairs et simples, de manière à ce qu'ils puissent être facilement compris..

Tout en prenant en compte le coté temporaire de tels mesures et le fait de ne pas les priviligier ne peut on pas comme nous nous l'étions dit au début du projet de créer plusieurs pages.

On laisse la page d'accueil en ne prenant aucune mesure particuliére autres que celles recommandées.

Mais par contre on créer comme des pages laboratoires ou justement les mesures particulières sont implémentées et ou l'on pourrais tester le rapport gain et gène.

Si de ces pages sort un consensus on passe à une application direct sur le site.

Ce que nous pensions avec web-pour-tous c'est que ce rapport gain gène soit définis par des utilisateurs.

Même si sur ce forum des personnes ont des connaissances pointues dans le domaine j'ai l'impression de traiter un problème qui touche des millions de personnes avec uniquement une poignée d'irreductibles .