[site associatif] votre avis sur ce "tuto interne"

[herisson]

Bonjour,

Voilà je pense que vous pourriez me conseiller de façon constructive : j'explique le contexte de la page que je soumets à vos avis.

Je suis membre d'une association qui revoit complètement son site web dans les semaines à venir.

Dans notre cas, qui dit association dit bénévoles de bonne volonté... et (comme moi) pas nécessairement très au point sur les techniques... or notre asso s'adresse (entre autre !!!) aux non-voyants ou mal-voyants !!!! Donc la question du handicap est familier à tous les membres susceptibles d'être "web-rédacteurs" : je pense que chacun est d'accord pour rendre le site accessible à tous, qu'ils soient novices dans le domaine de l'asso ou que le visiteur ait un handicap quelconque !

J'ai pas mal consulté les tuto en ligne pour apprendre le html les css etc : j'ai bien envie de partager mes petites connaissances avec les autres bénévoles donc j'ai pensé à un document qui centralise les informations techniques !

le but de cette page :

1. faire gagner du temps aux bonnes volontés qui vont participer à la refonte du site et sa mise aux standards actuels (xhtml 1.0 et css notamment)

2. que tout le monde fasse pareil et que toutes les pages de notre site soient facilement accessibles à TOUS.

3. sensibiliser efficacement les membres à l'accessibilité du web pour tous en leur fournissant les "outils-codes" directement adaptés à notre site pour que le travail fourni soit propre quelque soit le bénévole qui s'en charge !

Voilà le contexte !

Concernant l'état de la page : je précise que je dois encore rédiger les parties traitant des tabindex et accesskey... mais j'ai pas encore trop potassé le sujet

Obsolète : page en cours

25/05/2005 : Nouvelle version

merci d'avance à tous ceux qui prendront le temps de commenter ce document et n'hésitez pas à me corriger si j'y dis des anneries plus grosses que moi

(désolée si ce message est un peu long : comme c'est ma première intervention j'ai pensé que vous expliquer le contexte pouvait vous être utiles pour vous faire une idée correcte du but de ce que je vous soumets à critique)

Modifié 25 Mai 2005 par herisson

[adatim]

Bonsoir,

je viens de lire le document et bien que celui là parte d'une très bonne volonté je pense qu'il aurait besoin de se nourrir de conseils beaucoup plus pratiques et précis. En effet, tu donnes ici quelques recommandations -qui me semblent parfois assez étranges- mais tu ne parles pas de moyens à mettre en oeuvre pour respecter ces recommandations.

Exemple :

Balise de bloc si l'ensemble du bloc est d'une autre langue, sinon une balise en ligne abbr, acronym, ... et span en dernier recours)

Je pense que chaque balise a sa raison d'être et une balise abbr servira uniquement si abréviation et non pas pour un changement de langue sauf si l'abréviation comporte un changement de langue mais il n'y a pas de hiérarchie à suivre c'est la logique qui décide ...

Je pense que tu devrais peut-être réaliser un tel document pour une base mais reprendre les nombreux blogs, sites, etc qui donnent de très bons conseils pas à pas et faire des liste bien ordonnées et triées de toutes ces informations afin que chacun puisse s'y référer quand nécessaire. En effet .... pourquoi voudrais tu réexpliquer le fonctionnement de qqch si bien fait par ailleurs ?

En tout cas si tu as besoin que quelqu'un jette un coup d'oeil au site une fois avancé je pense que tu trouveras bcp de monde ici pour te rendre ce service et je le ferais aussi avec plaisir car je pense que de bonnes initiatives comme celles-ci doivent être encouragées.

Modifié 23 Mai 2005 par adatim

[Steph. K.]

Il faudrait rajouter quelques paragraphes :

les images (alt...)

les liens (nouvelle fenetre, intitulé, hreflang...)

Pour les abbréviation il serait bon de les développer <abbr title="Société Nationale des Chemins de fer Français">SNCF</abbr>.

Voilà, je regarderais plus attentivement plus tard.

[herisson]

Je pense que chaque balise a sa raison d'être et une balise abbr servira uniquement si abréviation et non pas pour un changement de langue sauf si l'abréviation comporte un changement de langue mais il n'y a pas de hiérarchie à suivre c'est la logique qui décide ...

Vu ta réaction, je vais reformuler car dans mon esprit évidemment qu'on met pas une balise abbr pour un changement de langue ! Je voulais dire que s'il y a une balise par exemple abbr ben on ajoute pas un étage à la fusée en encadrant la balise d'un span... mais apparemment ma phrase est mal tournée

En effet .... pourquoi voudrais tu réexpliquer le fonctionnement de qqch si bien fait par ailleurs ?

pourquoi ? Cette page n'a aucune vocation externe à cette association et en aucun cas être une référence pour une autre structure (je me suis peut-etre mal exprimée dans mon message...)

le but est tout simplement de faire un récapitulatif qui sert de référence pour les bénévoles de ce site afin que chacun perde pas des heures à parcourir le web dans tous les sens comme je l'ai fait... pour simplement qu'un autre bénévole comprendre en quelque lignes pourquoi il y a telle ou telle balise et tel ou tel attribut...

sinon bien sûr ce n'est pas fini et j'ai bien l'intention de mettre des liens vers les sites qui m'ont aidé à comprendre les quelques trucs que je pense avoir compris Mais je ne me leurre pas : si moi j'ai voulu apprendre et faire le plus simple et le plus propre possible, je sais que certains peuvent vouloir rédiger du contenu mais pas passer des heures à chercher le pourquoi du comment : certains sont "utilisateurs" d'un canevas ils feront correctement le boulot qu'ils prennent en charge mais ne seront pas intéressés pour approfondir

En tout cas si tu as besoin que quelqu'un jette un coup d'oeil au site une fois avancé je pense que tu trouveras bcp de monde ici pour te rendre ce service et je le ferais aussi avec plaisir car je pense que de bonnes initiatives comme celles-ci doivent être encouragées.

<{POST_SNAPBACK}>

c'est prévu mais comme c'est une refonte j'aimerai avoir quelques avis sur le judicieux des choix pour un site qui se veut accessible à tous avant de passer des heures à reprendre le code actuel.

[adatim]

en aucun cas être une référence pour une autre structure (je me suis peut-etre mal exprimée dans mon message...)

Oui tout à fait je le comprends bien et comme je le disais l'intention est louable mais même pour une référence internet pourquoi ne reprends tu pas (avec l'autorisation de leurs auteurs bien sûr) certains tutos très simples comme celui de Monique posté sur le hub ? ou bien d'autres encore que je ne pourrais pas lister ici ... Je comprends tout à fait que beaucoup de personnes ne voudront pas se pencher sur les mécanismes internes parfois complexes de l'accessibilité mais c'est vouloir la résumé ne sera pas chose facile. Je pense que le plus simple dans ton cas serait de développer l'interface globale de façon accessible puis de mettre un gestionnaire de contenu basique pour les gens qui devront enrichir le site et générer les pages à la volée par php.

Ainsi ils ne toucheront pas vraiment au code et n'auront qu'à apprendre quelques règles en terme de contenu (balises lang par exemple, règles ergonomiques ...)

Sinon un conseil si tu veux quand même développer un petit manuel d'accessibilité enrichis le de nombreux exemples ca parlera beaucoup plus et puis même si ce n'est pas toujours universel ca permet de copier coller puis d'implémenter comme bon nous semble ...

Rajoute aussi un sommaire cliquable en haut du document qui renvoie sur chaque partie ca fera gagner du temps.

[fre]

Si je peux me permettre juste une remarque sur l'accessibilité technique à mettre en oeuvre, il existe le toujours très bon guide BrailleNet (un peu vieillot mais si je me refere au site accessiweb, il ,semblerait que l'association soit entrain de repondre une version)

Guide Braillenet

fred

[fre]

Pour les abbréviation il serait bon de les développer <abbr title="Société Nationale des Chemins de fer Français">SNCF</abbr>.

C'est plutôt un accronyme qu'une abbréviations non ?? --> balise <accronym> ??

[adatim]

oui tout à fait ... enfin la balise c <acronym title='société ...>

(pas deux c)

Modifié 24 Mai 2005 par adatim

[herisson]

... pourquoi ne reprends tu pas (avec l'autorisation de leurs auteurs bien sûr) certains tutos très simples comme celui de Monique posté sur le hub ?

<{POST_SNAPBACK}>

tu fais référence à cet article ?

Vous avez peut-être raison de souligner que je m'y prends mal

merci à tous pour vos réflexions : elles font avancer le document (même si à terme il me servira peut-etre seulement de pense-bête )

j'en profite pour vous demander si vous avez un(des) lien(s) qui feraient un comparatif des balises abbr et acronym : j'avoue qu'actuellement je ne saisis pas toute la subtilité des deux... mais si c'est détaillé dans le "guide braillenet" dont Fre a mis le lien ma question est sans objet (je vais m'y plonger de suite)

[Steph. K.]

C'est plutôt un accronyme qu'une abbréviations non ?? --> balise <accronym> ??

<{POST_SNAPBACK}>

En français c'est un... sigle ;-)

En HTML c'est une <abbr> (un accronyme est un sigle qui se lit comme un mot ex. : Sida ou Unesco)

En XHTML c'est une <abbr>... puisque la balise <acronym> devrait disparaître.

En pratique il faut utiliser <abbr> et définir avec les CSS la façon de prononcer :

speak: spell-out; pour prononcer une abréviation lettre par lettre, ce qui est correct pour le cas qui nous interesse.

Dans les faits, IE n'interpretant pas la balise <abbr>, il vaut mieux baliser les sigles avec des span et spécifier ce que l'on veut comme rendu grace aux CSS :

.acro {

cursor:help;

border-bottom: #990000 1px dotted;

}

et

.sigle {

cursor:help;

border-bottom: #990000 1px dotted;

speak:spell-out;

}

Après quelques essais avec Home Page Reader de la société IBM, il apparaît que les portions de texte en majuscule sont lues lettre par lettre, par contre ce logiciel ne semble pas du tout prendre en compte le contenu de l'attribut title="..." ce qui est fort dommage notamment pour ce qui est des abréviations qui passent très mal l'oral.

Pour conclure et pour embrouiller un petit peu plus les choses, le truc a éviter à tous prix, c'est l'utilisation d'abréviations comme av. pour avenue car seule la lecture du title serait judicieuse et ce n'est pas le fonctionnement par défaut des logiciels.

[herisson]

Merci Steph K. : c'est clair est précis ! je crois que j'ai tout compris

[Matthieu Faure]

Salut,

Voici quelques informations qui (je l'espère) pourront t'aider:

- l'accessibilité ne concerne pas que les personnes aveugles, mais aussi mal-voyante (ex. Dossier Daltonisme) et plus généralement tous les types de handicap (auditifs, moteurs, cognitifs).

- le guide BrailleNet est un peu vieux (2002), autant ne pas le mentionner. Une nouvelle version doit sortir au mois de juin sous le nom de Guide AccessiWeb.

- pour ce qui est des critères d'accessibilité, fais la distinction entre ceux qui concernent le designer (toi a priori) et les "producteurs de contenu" (les autres membres de ton asso). L'idée est de faciliter la tâche aux rédacteurs et d'éviter de leur parler de doctype et autres CSS qui ne les intéresseront probablement pas.

- enfin pour mettre le pied à l'etrier avec les critères d'accessibilité, et savoir par lesquels commencer, tu peux jeter un oeil à Accessibilité: pourquoi comment.

Bon courage

Matthieu

[herisson]

l'accessibilité ne concerne pas que les personnes aveugles, mais aussi mal-voyante (ex. Dossier Daltonisme) et plus généralement tous les types de handicap (auditifs, moteurs, cognitifs).

Si je présente surtout l'aspect vers non-voyants ou mal-voyants c'est parce que c'est l'un des publics cibles de notre asso : mais normalement les règles établies doivent assurer la navigation quelque soit le handicap : nous sommes bien d'accord !

Et puis j'envisage de proposer plusieurs présentations (même démarche que le switch de acces-pour-tous.net)

- pour ce qui est des critères d'accessibilité, fais la distinction entre ceux qui concernent le designer (toi a priori) et les "producteurs de contenu" (les autres membres de ton asso). L'idée est de faciliter la tâche aux rédacteurs et d'éviter de leur parler de doctype et autres CSS qui ne les intéresseront probablement pas.

t'as tout compris : c'est exactement le but de ce document ! mais je pense qu'il faut un peu parler de css pour qu'ils aillent pas nous ajouter de la mise en forme dans le code c'est justement le problème de mettre trop de liens de référence... va falloir se faire bien comprendre : la mise en forme "design" peut être discutée et revue (je suis pas vraiment de tendance despotique) mais par une discussion et non par l'ajout par Pierre Paul Jacques de ses préférences dans le code...

j'ai pensé qu'un récapitulatif était bien pour cela : genre un bénévole se dit "comment je fait tel truc" et hop en regardant ce document il le sait très vite...

Exemple : en regardant des sites en ligne, ils peuvent me "pondre" des "retour page précédente" etc avec des tableaux alors qu'on a décidé (je suis pas toute seule à décider, on a une aveugle dans le pool actif par exemple) qu'il n'y aurait aucun tableau de mise en page !

- enfin pour mettre le pied à l'etrier avec les critères d'accessibilité, et savoir par lesquels commencer, tu peux jeter un oeil à Accessibilité: pourquoi comment.

<{POST_SNAPBACK}>

je l'ai téléchargé et je m'y appuie grandement

Suite aux remarques que vous m'avez faites et à mes recherches connexes, nouvelle version du document : par ici

[Steph. K.]

Suite aux remarques que vous m'avez faites et à mes recherches connexes, nouvelle version du document : par ici

<{POST_SNAPBACK}>

Je viens de regarder un petit peu la nouvelle version et il y a quelques erreurs nottamment à propos des images. Le W3C ne tolère pas l'attribut alt vide, il le préconise ! Une image non significative doit en être munie sans quoi un logiciel comme Jaws lira le nom de l'image ce qui est gênant. Pour ce qui est des longesc, la limite (150 caractères) est erronée. Il se peut même qu'une image toute simle en apparence nécesite un tableau assez complexe pour qu'un non-voyant ai la même information (cas d'un graphique par exemple). L'attribut longdesc n'étant pas ou trés peu interprété par les navigateurs il faut les doubler d'un lien D

http://www.acces-pour-tous.net/fichiers_co....php?rub=images

Bonne continuation dans ta démarche.

[Monique]

Bonjour,

Le sens de cette phrase ne me semble pas clair

Les standards actuels acceptent l'attribut vide alt="" pour les images non significatives. A l'association, on ne les accepte jamais et les listes avec des "puces images" sont également refusées.

Le refus par l'association concerne-t-il les attributs alt vides ou les images non significatives ?

Pour les liens, il ne faut pas oublier que Jaws par exemple ne lit pas le contenu de l'attribut title par défaut, configuration la plus souvent utilisée (voir ce message)

Sur une même page, un même intitulé de lien (texte sur lequel le lien est fait) ne peut pas pointer vers des cibles différentes. Je n'ai pas souvenir que la même précision soit donnée à propos du contenu de l'attribut title mais cela me semble logique.

[herisson]

Bonjour,

Le sens de cette phrase ne me semble pas clair Le refus par l'association concerne-t-il les attributs alt vides ou les images non significatives ?

Dans l'état actuel des choses, le site de l'asso est plus tourné vers le contenu qu'un design très élaboré... donc le refus concerne les images non-significatives (et donc les puces-images par exemple), par voie de conséquence il concerne l'alt vide : ou j'ai rien compris ?

D'après ce que j'ai lu, je considère comme image significative une image de flèche cliquable (par exemple pour revenir en haut de page ou aller à la page suivante) : j'ai tout faux ?

Pour les liens, il ne faut pas oublier que Jaws par exemple ne lit pas le contenu de l'attribut title par défaut, configuration la plus souvent utilisée (voir ce message)

Ce genre de remarque, comme celles de Steph. K., me confirme que j'ai bien fait de venir vous demander votre avis : je savais que j'avais de grosses lacunes de compréhension... c'est confirmé par vos remarques

Merci de prendre le temps de commenter ce document et de me donner des liens quand c'est nécessaire

Sur une même page, un même intitulé de lien (texte sur lequel le lien est fait) ne peut pas pointer vers des cibles différentes. Je n'ai pas souvenir que la même précision soit donnée à propos du contenu de l'attribut title    mais cela me semble logique.

<{POST_SNAPBACK}>

ça me parait également logique

mais tu as raison, j'ai confondu l'intitulé du lien et le title (dans le document Accessibilite-pourquoi-comment page 18)

Donc le système actuel de présenter un lien externe comme ça

blablabla <a href="www.lien1" title="contenu_significatif" alt="">[www]</a>

est mauvais ?

(pour la navigation du clavier de lien en lien par exemple, bien que je ne me sois pas encore penchée sérieusement sur le sujet)

Modifié 26 Mai 2005 par herisson

[shangailily]

Bonsoir herisson !

blablabla <a href="www.lien1" title="contenu_significatif" alt="">[www]</a>est mauvais ?

1ère remarque :

Attention, l'attribut ALT est réservé aux images et non aux liens.

2ème remarque :

Le TITLE est utile si tu veux apporter une information supplémentaire par rapport à l'intitulé du lien.

Exemple :

Le site de l'<a href="..." Title="Se rendre sur le site de l'ANPE (nouvelle fenêtre" target="_blank">A.N.P.E</a>

.

3ème remarque :

Il est mieux d'avoir un intitulé de lien explicite plutôt qu'une URL. C'est tout de même plus confortable pour les utilisateurs de Jaws. Entendre l'URL d'un site, c'est pas génial.

Voilà

Modifié 31 Mai 2005 par shangailily