Pour faire suite à mon article sur la production de contenu rédactionnel accessible depuis SPIP : http://www.spip-contrib.net/Accessibilite-pour-les-redacteurs.
Je trouve qu’il serait bien de laisser la possibilité, sur le modèle de ce que propose Drupal pour ces modules, à l’auteur d’un plugin de signaler si son plugin est accessible (auto déclaration) et qu’il s’engage à corriger si un problème d’accessibilité lui est soumis.
Je pensais donc qu’il serait possible de rajouter dans le xml du plugin un tag genre oui puis de mettre à dispo un moteur de recherche sur la page d’installe des plugins mais je ne sais pas du tout où est défini le formaliseme du xml des plugins.
Plus largement ce système pourrait être étendu pour pouvoir tagguer les plugins et les rechercher plus facilement que dans une liste de 200 classé par ordre alphabétique.
Est ce que vous trouver cette idée, pertinente ? est long à coder ?
Tu as des articles qui décrive la modélisation et l’implémentation proposée et des menus qui permettent d’essayer le prototype. Donc inutile de lancer un débat en parallèle.
Par contre, la notion d’accessibilité n’est pas prise en compte et d’ailleurs je le sens pas trop comme une information à mettre dans plugin.xml. Mais bon j’y ai pas réfléchi non plus !
Pas d'accord avec toi Eric. Une telle information est du même niveau que la balise "categorie" en ce sens qu'elle n'est pas indispensable au fonctionnement du plugin, mais elle donne une information générale intéressante. Je suis donc favorable à ce qu'on mette une telle balise, mais il faudrait préciser le document d'accessibilité qu'il respecte. En revanche, je ne le sens pas trop de demander aux auteurs un engagement de suivi: c'est une grosse contrainte qui risque de freiner d'avance l'adoption de cette balise.
. Une telle information est du même niveau que la balise « categorie » en ce sens qu’elle n’est pas indispensable au fonctionnement du plugin, mais elle donne une information générale intéressante. Je suis donc favorable à ce qu’on mette une telle balise, mais il faudrait préciser le document d’accessibilité qu’il respecte.
J’aurais du préciser ma pensée. Le dev est-il à même de décider si c’est accessible ou pas ? Selon quelle norme ? Et est ce que c’est pérenne ? Pour moi c’est plus une information de « sortie » (d’un test ou autre processus de décision) que d’une information « d’entrée » comme la catégorie. Non ? Donc là je ne suis pas d’accord avec ton parallèle sur la catégorie.
En revanche, je ne le sens pas trop de demander aux auteurs un engagement de suivi: c’est une grosse contrainte qui risque de freiner d’avance l’adoption de cette balise.
Oui, c’est ce que je dis. Déjà que les necessite SPIP ont du mal…
Ecrire une DTD pour lui fournirait une doc fiable et un moyen facile de vérifier plugin.xml en appliquant le validateur intégré à SPIP. Toutefois il faudrait utiliser plus à fond les possibilités de XML.
Une DTD permet de spécifier par une RegExp les différentes valeurs prises par un attribut, en revanche les zones de texte sont totalement libres. En conséquence, je trouve qu'il est maladroit d'avoir mis en zone de texte une info qui ne peut prendre qu'un nombre fini de valeurs; je pense notamment à la balise "etat", qui aurait plutôt dû être un attribut de la balise plugin, et la DTD indiquerait les seules valeurs possibles pour cet attribut. Je pense aussi que les balises qui ne peuvent apparaître qu'une seule fois devraient être des attributs de la balise plugin (version, version_base, licence, icon) avec la RegExp appropriée dans la DTD, et la mention REQUIRED.
A l'inverse, la balise chemin devrait n'avoir que l'attribut type, tandis que l'actuel attribut "dir" aurait pu être dans la zone texte, mais là ça n'a pas vraiment d'importance. A noter aussi une incohérence à mon avis: la balise auteur devrait ne contenir qu'un seul auteur mais être répétable, plutôt que d'être un gros fourtout. Un attribut "mail" et un attribut "website" pour chacune serait aussi une bonne idée.
en fait il peut s’agir de deux besoins différents :
une catégorie/tag/secteur “accessibilité” qui peut etre utilisée par des plugins facilitant la production de contenu accessible au même titre qu’une catégorie “cartographie”, “vidéo”, etc
un engagement d’accessibilité sur l’interface et le contenu produit par le plugin lui meme ( voir http://groups.drupal.org/node/66323 )
Concernant le document à respecter c’est relativement simple c’est WCAG 2.0 AA qui est reconnu comme la référence. Après il s’agit d’un engagement personnel auto-déclaratif donc certes potentiellement imparfait mais qui aidera quand même à repérer les plugins où un effort a été fait, ce qui est clairement mieux que le néant actuel.
La conformité d'accessibilité n'est pas décidable algorithmiquement (exemple type: "toute image est accompagnée d'une légende décrivant son contenu"), ça ne peut donc être une information de sortie. En revanche on peut imaginer un attribut indiquant si l'information vient de l'auteur (qui est donc juge et partie) ou s'il a soumis son code à un expert extérieur.
Et la liste des langues pour lesquelles le plugin dispose d'une traduction :
ne serait il pas utile / intéressant qu'elles puissent figurer
dans plugin.xml lorsque c'est pertinent ?
Oui, une balise lang répétable avec un attribut "nom" conforme à la RegExp du code de langue serait utile.
En regardant plus en détail les différents contenus des plugin.xml, j'en arrive à la conclusion qu'en fait on pourrait n'avoir que des balises auto-fermées (sans zone de texte je veux dire) avec plus d'attributs.
Par exemple au lieu de:
* ça n'a pas grand sens de mettre un accessibilite=oui|non binaire,
sachant qu'il y a une multitude de gradations possibles
* tout devrait, dans l'idéal, être accessible : donc si comme tu dis
"l'auteur s'engage", autant mettre "oui" partout
* ce n'est pas obligatoirement à l'"auteur" d'un plugin de
dire/savoir/programmer, d'ailleurs souvent il n'y a pas "un auteur" ad
vitam aeternam, et chacun peut être co-auteur quand il a quelque chose
à améliorer/ajouter
Bref si l'accessibilité est un vrai chantier, ce n'est pas par de
l'administratif et du déclaratif qu'on va le faire avancer, c'est en
se fadant de la doc et du code. Or en la matière les conseilleurs sont
rarement les payeurs...
ça n’a pas grand sens de mettre un accessibilite=oui|non binaire,
sachant qu’il y a une multitude de gradations possibles
voir le fil SVP et accessibilité il y a 2 besoins différents (catégorie accessibilité et la déclaration).
tout devrait, dans l’idéal, être accessible : donc si comme tu dis
« l’auteur s’engage », autant mettre « oui » partout
certain plugin ne produisent aucun contenu et n’ont aucune interface d’admin
on est pas dans un monde idéal et dans l’état actuel des choses aucune différentiation n’est possible entre un plugin où le mec n’a rien pris en compte et est totalement inaccessible et un plugin qui a pris en compte l’accessibilité. C’est d’autant plus problématique qd il y a plusieurs plugins qui font sensiblement la même choses (forms, newsletter, player video, etc). Si tu vois une meilleur solution pour permettre de les distinguer sans faire une validation/notation par un tiers à postériori de la publication je suis preneur.
ce n’est pas obligatoirement à l’« auteur » d’un plugin de
dire/savoir/programmer, d’ailleurs souvent il n’y a pas « un auteur » ad
vitam aeternam, et chacun peut être co-auteur quand il a quelque chose
à améliorer/ajouter
je n’ai jamais dit qu’un ou plusieurs tiers ne pouvais pas faire la déclaration, l’ajouter dans le xml et maintenir l’accessibilité du dit plugin à la place de l’auteur.
Bref si l’accessibilité est un vrai chantier, ce n’est pas par de
l’administratif et du déclaratif qu’on va le faire avancer, c’est en
se fadant de la doc et du code. Or en la matière les conseilleurs sont
rarement les payeurs…
oui et celui qui se l’ai déjà fadé n’aura aucun moyen de le mettre en avant et donc il n’a aucun intérêt à le faire (oups j’oubliai la beauté de la cause et que le gens code juste pas amour du code dans le but que personne n’utilise leur plugin)
voir le fil SVP et accessibilité il y a 2 besoins différents (catégorie
accessibilité et la déclaration).
je n'ai pas mélangé les deux
1) certain plugin ne produisent aucun contenu et n'ont aucune interface
d'admin
ils sont donc accessible=oui d'entrée de jeu !
2) on est pas dans un monde idéal et dans l'état actuel des choses aucune
différentiation n'est possible entre un plugin où le mec
ou la nana... faut-il qu'on ajoute un paramètre feministe=oui ?
n'a rien pris en
compte et est totalement inaccessible et un plugin qui a pris en compte
l'accessibilité.
si c'est un point fort du plugin, on peut le mettre en avant dans sa
page de doc, ou dans un article. si c'est un point faible, on peut
essayer d'améliorer le plugin, ou d'aider l'auteur à l'améliorer.
C'est d'autant plus problématique qd il y a plusieurs
plugins qui font sensiblement la même choses (forms, newsletter, player
video, etc). Si tu vois une meilleur solution pour permettre de les
distinguer sans faire une validation/notation par un tiers à postériori de
la publication je suis preneur.
Un article comparatif me paraît en effet être la meilleure solution.
oui et celui qui se l'ai déjà fadé n'aura aucun moyen de le mettre en avant
et donc il n'a aucun intérêt à le faire (oups j'oubliai la beauté de la
cause et que le gens code juste pas amour du code dans le but que personne
n'utilise leur plugin)
Je ne vois pas en quoi la procédure bureaucratique que tu proposes
changera quoi que ce soit à cet état de fait.
Il y a certainement des choses à améliorer, mais ça permet de préciser beaucoup de choses et de réduire un peu la taille de ces fichiers. En réécrivant tous les fichiers plugin.xml de la zone conformément à une telle DTD (ce n'est pas difficile à faire), on pourrait remplacer la fonction actuellement fautive xpip_xml_load par un simple appel au validateur XML intégré à SPIP en lui donnant cette DTD pour faire le contrôle d'erreur.
Oui bien sûr. Le plus simple serait de donner un autre nom à ce nouveau fichier, qui serait cherché prioritairement à plugin.xml, lequel serait pris en cas d'échec.
Je signale que plugin.xml n'est vraiment pas XML dans certains cas, par exemple celui du plugin Forum qui contient 3 balises "plugin" successives au premier niveau.
Concernant le nom, je pense que paquet.xml serait pas mal compte tenu de la modélisation proposée par SVP.
ok
Sinon sur la DTD, j'ai pas mal de remarques Emmanuel, en particulier sur les balises nouvellement proposées. Je les fais dans l'article ou dans un forum de l'article ?
dans le forum a priori, ça permettra de garder trace des idées.
Sinon, je viens de voir qu'il est possible d'avoir plusieurs occurrences de "fonctions" (et probablement d'"options") dans plugin.xml, ce qui est gênant pour son passage sous forme d'attribut. Mais ces 2 entrées sont de toutes façons problématique: vu la recommandation qu'il ne faut surtout pas nommer ces fichiers "mes_fonctions.php" et "mes_options.php" parce que ça va mettre le bazar dans find_in_path pour ceux présents dans le noyau, il me semble qu'en fait ces 2 informations ne devraient pas figurer dans plugin.xml et qu'il faut fixer d'autorité que leur nom soient ${prefix}_fonctions.php et ${prefix}_options.php ça évitera définitivement ce risque d'homonymie. Pour ceux qui ont plusieurs balise "fonctions", il leur suffira de faire des include dans leur ${prefix}_fonctions.php.
dans le forum a priori, ça permettra de garder trace des idées.
Ok, ça marche je viens d’ouvrir le forum à tous
Sinon, je viens de voir qu’il est possible d’avoir plusieurs occurrences de « fonctions » (et probablement d’« options ») dans plugin.xml, ce qui est gênant pour son passage sous forme d’attribut. Mais ces 2 entrées sont de toutes façons problématique: vu la recommandation qu’il ne faut surtout pas nommer ces fichiers « mes_fonctions.php » et « mes_options.php » parce que ça va mettre le bazar dans find_in_path pour ceux présents dans le noyau, il me semble qu’en fait ces 2 informations ne devraient pas figurer dans plugin.xml et qu’il faut fixer d’autorité que leur nom soient ${prefix}_fonctions.php et ${prefix}_options.php ça évitera définitivement ce risque d’homonymie. Pour ceux qui ont plusieurs balise « fonctions », il leur suffira de faire des include dans leur ${prefix}_fonctions.php.
Ben j’ai découvert cette possibilité en réalisant SVP. J’ai trouvé ça intéressant et j’allais l’utilisé. J’oublie tout alors
