Bonjour,
Signalée par un ami aujourd'hui, l'accessibilité de spip aux visiteurs
en braille-interface vocale est assez perturbée par l'absence contenus
de balises "alt" pourtant présentes, chaque fois qu'un logo de rubrique,
d'article ou de lien est sensé s'afficher?
Il perçois des IMG/siteon6 par exemple, ce qui n'est pas très
"user-friendly" lors de sa visite, il faut le dire...
Des correctifs sont-ils en route ?
Bonne soirée.
Marcel
Certainement pas !
Car ce n'est pas pertinent. Ça dépend de leur usage, ce que SPIP, qui n'est pas un dieu omniscient, ne peut prévoir.
- Soit les logos sont utilisés comme image décorative (complémentaire du titre, par exemple) : il ne leur faut pas de alt dans ce cas
- Soit ils sont utilisés seuls (pour faire un lien visuel par exemple) et dans ce cas un alt est effectivement préconisé... que tu peux ajouter grâce au filtre magique |inserer_attribut, utilisé comme ceci par exemple : [(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]
-- Romy
romy@rezo.net a écrit :
Signalée par un ami aujourd'hui, l'accessibilité de spip aux visiteurs
en braille-interface vocale est assez perturbée par l'absence contenus
de balises "alt" pourtant présentes, chaque fois qu'un logo de rubrique,
d'article ou de lien est sensé s'afficher?Il perçois des IMG/siteon6 par exemple, ce qui n'est pas très
"user-friendly" lors de sa visite, il faut le dire...Des correctifs sont-ils en route ?
Certainement pas !Car ce n'est pas pertinent. Ça dépend de leur usage, ce que SPIP, qui n'est pas un dieu omniscient, ne peut prévoir.
- Soit les logos sont utilisés comme image décorative (complémentaire du titre, par exemple) : il ne leur faut pas de alt dans ce cas
- Soit ils sont utilisés seuls (pour faire un lien visuel par exemple) et dans ce cas un alt est effectivement préconisé... que tu peux ajouter grâce au filtre magique |inserer_attribut, utilisé comme ceci par exemple : [(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]-- Romy
Merci Romy pour ce conseil que je vais suivre. Juste une remarque
quand-même, c'est qu'en terme d'accessibilité braille-interface vocale,
toute balise alternative à l'affichage d'une image est souhaitable -
même si elle n'est pas "pertinente"...
Si les efforts pour aménager une accessibilité de plus en plus
conviviale à spip sont remarquables pour la branche 2, ce manque est
tout de même dommage.
Disons qu'en terme de comportement par défaut, j'aurais bien imaginé que
la balise alt reprenne le titre de l'objet associé eu logo et qu'un
champ à compléter sur le modèle des images doc, s'il était complété,
remplace ce titre.
Car en définitive, ce que tu décris n'est rien moin qu'une simple
alternative entre deux choix.
Bonne journée.
Marcel
Non, justement.
Ce qu'explique Romy c'est que si image est purement décorative, et ne véhicule pas d'information, son attribut alternatif ne doit pas être rempli. Il est contre productif d'y répéter le titre de l'article, car cela alourdit très vite la lecture de la page avec une double lecture de chaque titre d'article dans le cas par exemple d'une liste d'article avec logo (page d'accueil).
En revanche, il me semble que dans ce cas, un attribut alt vide est plus pertinent, pour indiquer clairement que le contenu alternatif est vide. Ce qui évite je crois la lecture du nom du fichier, qui est absolument sans intérêt dans le cas des logos de SPIP qui plus est.
Cédric
Si, si, il faut un "alt" vide dans ce cas !
-Nicolas
Ah oui, pardon, ma réponse prêtait à confusion :
il FAUT TOUJOURS un alt,
mais vide dans ce cas là.
C'est bien le cas.
romy@rezo.net a écrit :
Car ce n'est pas pertinent. Ça dépend de leur usage, ce que SPIP, qui n'est pas un dieu omniscient, ne peut prévoir.
- Soit les logos sont utilisés comme image décorative (complémentaire du titre, par exemple) : il ne leur faut pas de alt dans ce cas
Si, si, il faut un "alt" vide dans ce cas !
Ah oui, pardon, ma réponse prêtait à confusion :
il FAUT TOUJOURS un alt,
mais vide dans ce cas là.C'est bien le cas.
--
Romy_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
Re,
Le problème c'est que si le "alt" existe mais qu'il est vide (le cas
actuel), les interfaces braille et vocales se rabattent vers le nom du
fichier et l'écrivent/le lisent. Et c'est précisément ce qu'on m'a
exprimé être gênant...
Autrement dit un "alt' vide revient exactement au même pour les
non-voyants que pas de "alt" dutout...
Marcel
marcel a écrit :
Le problème c'est que si le "alt" existe mais qu'il est vide (le cas
actuel), les interfaces braille et vocales se rabattent vers le nom du
fichier et l'écrivent/le lisent. Et c'est précisément ce qu'on m'a
exprimé être gênant...
Autrement dit un "alt' vide revient exactement au même pour les
non-voyants que pas de "alt" dutout...
il serait intéressant de savoir quel lecteur adopte ce comportement.
jaws ?
(le alt doit être vide : alt="" et pas alt=" ")
voir le chapitre '3. Images'
de http://handy.univ-lyon1.fr/access/charte.html
romy@rezo.net a écrit :
> filtre magique |inserer_attribut :
> [(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]
ça mériterait un raccourci plus sympa !
JLuc
Comment SPIP devinerait quel est l'élément textuel à insérer (car le titre n'est pas toujours pertinent) ?
Comment satisfaire ceux qui refusent de couper le titre et les autres qui respectent le critère Accessiweb n°1.4 qui veut que le alt contienne moins de 80 caractères, limite qui était auparavant ou par ailleurs, de 60 caractères, etc. ?
Comment raccourcir, tout en maintenant ces libertés ?
denisb a écrit :
marcel a écrit :
Le problème c'est que si le "alt" existe mais qu'il est vide (le cas
actuel), les interfaces braille et vocales se rabattent vers le nom du
fichier et l'écrivent/le lisent. Et c'est précisément ce qu'on m'a
exprimé être gênant...
Autrement dit un "alt' vide revient exactement au même pour les
non-voyants que pas de "alt" dutout...il serait intéressant de savoir quel lecteur adopte ce comportement.
jaws ?(le alt doit être vide : alt="" et pas alt=" ")
voir le chapitre '3. Images'
de http://handy.univ-lyon1.fr/access/charte.html_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip
Renseignement pris , cette personne me répond :
"Je navigue alternativement avec IE 6 ou firefox 3."
C'est tout ce quelle dit.
D'autre part, en ce qui me concerne, si
http://handy.univ-lyon1.fr/access/charte.html affirme que pour une image
de décor le contenu de "alt" n'a aucune utilité, ce n'est pas sur ce
niveau que ma remarque se situait : je parlais juste de confort de
visite ; peut-être l'indication "logo", dans le cas qui nous occupe,
serait-elle plus conviviale à l'usage qu'un "alt" vide, redondant ou
absent....
Après tout, une forme de "décor" est toute aussi concevable à l'adresse
des non-voyants et l'accessibilité n'a pas obligatoirement qu'une
acception restrictive.
enfin je ne sais pas ; c'est à vous de voir.
Bonne journée.
Marcel
> filtre magique |inserer_attribut :
> [(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]ça mériterait un raccourci plus sympa !
Oui possiblement, mais lequel ? #LOGO_ARTICLE_ALT ??
Comment SPIP devinerait quel est l'élément textuel à insérer (car le titre n'est pas toujours pertinent) ?
Comment satisfaire ceux qui refusent de couper le titre et les autres qui respectent le critère Accessiweb n°1.4 qui veut que le alt contienne moins de 80 caractères, limite qui était auparavant ou par ailleurs, de 60 caractères, etc. ?
Comment raccourcir, tout en maintenant ces libertés ?
pourquoi ces libertés disparaîtraient-elles ?
-- Fil
Plus généralement, il me semble que les filtres d'image pourraient ajouter un attribut alt vide quand il n'y a pas déjà un alt. Il me semble bien qu'actuellement ça n'est pas le cas, du coup les filtres image peuvent parfaitement produire du code pas compliant dans certaines situations.
Arnaud
#LOGO_ARTICLE|alt{#TITRE}
serait déjà plus convivial tout en restant générique
On peut aussi y prévoir un second argument optionnel de longueur de coupe, préréglé à la « bonne » valeur.
Cédric
cedric.morin@yterium.com a écrit :
filtre magique |inserer_attribut :
[(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]ça mériterait un raccourci plus sympa !
Oui possiblement, mais lequel ? #LOGO_ARTICLE_ALT ??
#LOGO_ARTICLE|alt{#TITRE}
serait déjà plus convivial tout en restant générique
On peut aussi y prévoir un second argument optionnel de longueur de
coupe, préréglé à la "bonne" valeur.Cédric
Oui mais...
Celà ne répond pas au problème d'absence de champs éditables associés
aux images-logos via l'interface privée de spip ; ce qui, pour qui
utilise les logos d'articles ou autres objets comme illustrations, reste
impossible pour le moment.
Sur ce plan la question sera : est-ce envisageable ?
Marcel
Sur ce plan, la réponse est clairement non, pas sans un gros refactoring de code.
C'est prévu à moyen terme dans la mediatheque, mais c'est un gros chantier pas commencé.
Cédric
cedric.morin@yterium.com a écrit :
cedric.morin@yterium.com a écrit :
filtre magique |inserer_attribut :
[(#LOGO_ARTICLE||inserer_attribut{alt,[(#TITRE|attribut_html|couper{60})]})]
ça mériterait un raccourci plus sympa !
Oui possiblement, mais lequel ? #LOGO_ARTICLE_ALT ??
#LOGO_ARTICLE|alt{#TITRE}
serait déjà plus convivial tout en restant générique
On peut aussi y prévoir un second argument optionnel de longueur de
coupe, préréglé à la "bonne" valeur.Cédric
Oui mais...
Celà ne répond pas au problème d'absence de champs éditables associés
aux images-logos via l'interface privée de spip ; ce qui, pour qui
utilise les logos d'articles ou autres objets comme illustrations, reste
impossible pour le moment.
Sur ce plan la question sera : est-ce envisageable ?
Sur ce plan, la réponse est clairement non, pas sans un gros refactoring de code.
C'est prévu à moyen terme dans la mediatheque, mais c'est un gros chantier pas commencé.Cédric
Ok,
Je comprend. Ce chantier me paraît intéressant mais effectivement
complexe : il conduira à voir disparaïtre les disgrâcieux fichiers
stockés pelle-mêle à la racine de /IMG, mais les logos deviendraient
alors des objets très différents...sans compter les difficultés de
mises-à-jour posées à l'implémentation !
Merci pour toutes vos précisions et votre réactivité loin d'être en défaut !
Marcel
cedric.morin@yterium.com a écrit :
#LOGO_ARTICLE|alt{#TITRE}
serait déjà plus convivial tout en restant générique
On peut aussi y prévoir un second argument optionnel de longueur de coupe, préréglé à la "bonne" valeur.
Oui !
Ainsi, c'est très invitant à utiliser.
Ou attribut_alt, moins générique.
JLuc
Si une image est purement décorative, elle ne devrait rien avoir à faire dans
le HTML. Sa place est en fond CSS sur le H1, par exemple. C'est ce que fait
par exemple CSS Zen Garden, en ajoutant un <span> à l'intérieur du <h1> pour
donner la possibilité de masquer le texte du titre, dans le cas où le logo le
reprend.
Après, j'ai conscience qu'en l'état actuel, les CSS de SPIP ne sont par défaut
pas dynamiques, et donc qu'il serait difficile d'y inclure le logo configuré pour
le site, mais c'est une difficulté technique, qui ne doit pas masquer la
recherche des bonnes pratiques.
On peut toujours les foutres dans une balise <style> dans le <head> pour les quelques règles qui doivent justement être dynamiques, sans pour autant sortir les CSS en squelettes.