Bonsoir,
j'ai mis à jour mes modèles pour img et doc gérant mieux l'accessibilité normalement en l'état c'est intégrable au core
http://zone.spip.org/trac/spip-zone/browser/modeles/accessible/prive/modeles
http://trac.rezo.net/trac/spip/ticket/1053
Reste à venir :
- amélioration de l'accessibilité des modèles de pagination (title récupérant le nom de la boucle sur les item)
- amélioration de l'accessibilité des modèles emb (gestion des alternatives)
Aurélien
- amélioration de l'accessibilité des modèles de pagination (title
récupérant le nom de la boucle sur les item)
tu es sûr ? le nom de la boucle n'est pas une info pertinente pour les
humains...
-- Fil
Il y a deux genre de choses à faire passer sur les intitulés des liens dans la pagination.
- à quoi correspondant l'item exemple : page 1, page 2, page 3 etc
- sur quoi porte la pagination article, rubriques etc.
C'est notamment important dans les pages qui comporte plusieurs pagination différentes.
Actuellement, j'ai effectivement un moyen assez simple de faire cela en ce basant sur le nom de la boucle mais à la base j'ai pris cette solution car la balise pagination n'acceptait pas plus d'un paramètre. Maintenant que ce bug est corrigé il est effectivement plus pertinent d'utiliser un paramètre supplémentaire optionnel
Je viens d'ajouter la gestion des descriptions longues sur le modèle img.
Si l'on rempli le champ description d'une image mais ne l'affiche pas en utilisant la balise img au lieu de la balise doc (qui dans ce cas sert généralement plus le rôle de légende) cela ajoute l'attribut longdesc qui pointe vers une page géré par un squelette contenant la description. Cela permet notamment aux utilisateurs de lecteur d'écran d'avoir accès à une description précise des images complexes lorsque le contexte le nécessite (exemple: un graphique statistique, un schéma, etc).
Aurélien
Ton approche est un bon aiguillon pour trouver des solutions, mais en
l'état des choses elle pose plusieurs problèmes :
* les longdesc, c'est quelque chose qui ne fonctionne pas ; aucun
navigateur ne les gère, à l'exception des lecteurs d'écran. Plutôt que
cette voie de garage, il faudrait chercher une solution pour les
documents qui permette à tous les navigateurs d'afficher toutes les
infos nécessaires.
J'ai une idée là-dessus qui consisterait à avoir un squelette de
document qui affiche le doc en petit (si c'est une image) ou en embed
(une video, un son), et/ou en icone à télécharger ; plus le titre,
descriptif, poids etc, voire les balises EXIF si le plugin est là etc.
Ce squelette serait chargé éventuellement en thickbox (ou nyromodal)
qund on cliquerait sur l'icone (au lieu de charger directement le
document).
* la langue du document : tu dis qu'il faut l'ajouter dans le
raccourci <doc3|lang=es> ; mais la langue est une propriété du
document, pas une propriété de sa présentation. Si donc on veut
iniquer la langue du doc, il faut ajouter cette donnée dans la table
spip_documents, avec une interface de saisie. Cette remarque vaut
pour tous les ajouts de type "données" que tu préconises.
-- Fil
Ton approche est un bon aiguillon pour trouver des solutions, mais en
l'état des choses elle pose plusieurs problèmes :* les longdesc, c'est quelque chose qui ne fonctionne pas ; aucun
navigateur ne les gère, à l'exception des lecteurs d'écran.
oui et c'est déjà très utile rien que pour cela
Plutôt que
cette voie de garage, il faudrait chercher une solution pour les
documents qui permette à tous les navigateurs d'afficher toutes les
infos nécessaires.J'ai une idée là-dessus qui consisterait à avoir un squelette de
document qui affiche le doc en petit (si c'est une image) ou en embed
(une video, un son), et/ou en icone à télécharger ; plus le titre,
descriptif, poids etc, voire les balises EXIF si le plugin est là etc.
Ce squelette serait chargé éventuellement en thickbox (ou nyromodal)
qund on cliquerait sur l'icone (au lieu de charger directement le
document).
Oui c'est l'autre solution que je préconise parfois, à savoir mettre la description longue directement dans le contenu.
Par contre, le problème des thickox et autres, c'est que ça aussi ce n'est pas souvent très accessible notamment
lors d'une navigation au clavier. Donc j'ai pris l'option solution de base.
* la langue du document : tu dis qu'il faut l'ajouter dans le
raccourci <doc3|lang=es> ; mais la langue est une propriété du
document, pas une propriété de sa présentation. Si donc on veut
iniquer la langue du doc, il faut ajouter cette donnée dans la table
spip_documents, avec une interface de saisie. Cette remarque vaut
pour tous les ajouts de type "données" que tu préconises.
En fait c'est plus compliqué que cela (et j'ai sans doute mal expliquer dans le fichier), cela peut également être la langue du contenu de l'attribut alt (le titre) ou du descriptif. Je peux très bien avoir un document anglais avec un titre français. Donc oui, il serait pratique d'avoir en base la possibilité de déclarer la langue des documents mais ma solution de surcharge est toujours utile.
Si par ajouts de type "données" tu entends surcharge des alt et descriptif c'est le même problème. Une même image peut être utilisée plusieurs fois dans une page différente ou identique avec un contexte différent. Cela demandera donc une alternative différente en fonction de chaque contexte d'utilisation (image lien, image deco, image illustration, etc). Il faudrait donc que chaque instance d'un document puisse avoir un champ alternative (ou au min un titre et un descriptif différent). Mais la encore dans tout les cas il est utile de laisser la possibilité de surcharger ces éléments ponctuellement car l'utilisateur peut vouloir mettre autre chose que ce que propose le modèle par défaut.
Encore une fois j'ai pris cette solution parce qu'elle ne casse pas l'existant, répond dès maintenant à des problèmes d'accessibilité réel que rencontrent les visiteurs de site spip et aussi, je l'avoue, parce que faire un plugin ou des modifs dans le core qui modifient les bases c'est largement au dessus de mes compétences.
Aurélien