Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2011

Aide pour un tableau

Bonjour je relisais un article et tout en bas de cette section se trouve un tableau mis en forme de façon un peu trop complexe pour que j'arrive à y toucher sans faire n'importe quoi. Je crois qu'il existe des class spéciales pour laisser les couleurs des colonnes différentes deux à deux pour éviter le orange et gris faits maison. D'autres améliorations esthétiques (bordures fines par exemple) tout en restant accessible (comment qu'on doit faire pour les colspan ?) sont bienvenues. Bref, à l'aide ! Totodu74 (devesar…) 10 décembre 2010 à 23:09 (CET)

autant que possible. Les classes auxquelles tu penses concernent l'alternance des couleurs de lignes, mais pas les colonnes hélas. Cordialement, --Lgd (d) 11 décembre 2010 à 10:39 (CET)

Chic, un beau tableau tout vert ! OK pour les couleur des colonnes, l'important c'est que le contenu reste lisible après tout. Merci beaucoup ! Totodu74 (devesar…) 11 décembre 2010 à 14:00 (CET)

J’ai moi aussi essayé de m’attaquer à un tableau : Modèle:Résultats de l'APXS de Mars Pathfinder. Malheureusement, il reste du rouge... (scope col/row doit il obligatoirement être précéder d’un "!" ?). Cdlt, Vigneron * ^discut. 17 décembre 2010 à 16:00 (CET)

Je crois que oui, le ! signifie que la cellule est une cellule d'en-tête (en html th, table header) et le paramètre scope en définit la portée, alors qu'une cellule de données n'a pas de portée. J'ai fait un test pour confirmer, et ton tableau verdit. --Anneyh (d) 17 décembre 2010 à 16:08 (CET)

(méchante Édith) Oui, ! signale une cellule d'entête, sur laquelle tu vas indiquer sa portée (le « scope »; ligne ou colonne). Les autres cellules dans un tableau sont des cellules de données, qui n'ont d'autre portée qu'elle mêmes et pour lesquelles le scope n'aurait pas de sens. Tu ne peux indiquer de scope que pour les cellules commençant par !. Par défaut, une telle cellule d'entête est en gras (comme pour tout titre), et il est possible qu'ici des contributeurs soient attachés à la mise en forme (sans gras). Modifie les cellules en cellules d'entête, attends les cris de protestation : s'il y en a, tu pourras toujours appliquer un style à tes cellules d'entête pour les mettre en graisse normale. Litlok (m'écrire) 17 décembre 2010 à 16:11 (CET)

Je note d'améliorer le message d'alerte actuel du gadget quand il rencontre un TD (code wiki |) suivi d'un SCOPE, pour qu'il soit plus explicite sur l'action à entreprendre (remplacer par !). Une prochaine version du gadget (pas la prochaine, cependant, je pense, qui a d'autres priorités) apportera un système d'aide contextuel pour chaque alerte, permettant de mieux aider les correcteurs. Cordialement, --Lgd (d) 31 décembre 2010 à 10:24 (CET)

modèle lang pour langue sans code iso 639

Bonjour,

Quel code utilisé pour les langues ne possédant pas de code ISO 639 ? Typiquement pour le gallo, puis-je utiliser fr-FR-E (code iso 639 du français + code ISO 3166-2:FR), sinon quel code utiliser ? partir de frm ou fro plutôt que fr ? Comment savoir et où trouver l’information ? Je ne trouve rien sur les sites habituels… Cdlt, Vigneron * ^discut. 12 décembre 2010 à 13:23 (CET)

Si une recherche approfondie sur cet outil n'aboutit pas, ou en cas d'incertitude après celle-ci : ne rien mettre. Cordialement, --Lgd (d) 12 décembre 2010 à 14:02 (CET)

Merci, je ne connaissais pas cet outil.

Je ne comprends pas trop son fonctionnement mais apparemment, il ne comprend pas la norme ISO 3166…

Question subsidiaire : est-il possible de et comment faire ajouter une langue ?

Cdlt, Vigneron * ^discut. 12 décembre 2010 à 14:20 (CET)

Les codes de langue théoriquement disponibles pour le contenu Web dépendent d'un ensemble assez complexe de normes ISO. Mais concrètement, les tags valides sont ceux répertoriés dans le registre de l'IANA. L'outil d'Ishida que j'ai indiqué est en fait un simple outil de recherche dans ce registre, et de validation de la syntaxe. Le subtag E que tu souhaites utilisé n'est apparemment pas valide (je n'ai pas creusé plus loin). Cordialement, --Lgd (d) 13 décembre 2010 à 11:01 (CET)

caption et summary

La balise caption et summary permettent de donner un commentaire à un tableau, le premier apparait alors que le second n'est pas visible sur les écrans mais est lisible. Il serait intéressant d'indiquer que l'un et surtout l'autre existe. Ce qui permet de commenter un tableau, lisible par les lecteurs d'écran, mais sans être visible. Crochet.david (d) 20 décembre 2010 à 15:29 (CET)

Oui mais non. Si certains utilisent caption et summary de la même manière, ils sont différents. Le caption indique quel est le sujet du tableau, et est toujours nécessaire. Le summary donne des informations sur la structure du tableau, ou son utilisation, ou résume le contenu du tableau. Summary n'est pas toujours nécessaire.

D'un point de vue éditorial, il est préférable et plus facilement gérable d'encourager l'usage de caption. C'est utile pour tout le monde, tous les éditeurs le voient, et savent quoi mettre dans un caption. Pour le summary, c'est un grand flou.

Pour ces raisons, summary n'est à utiliser que dans quelques cas excetionnels. Bien à toi, Dodoïste ^{[ dring-dring ]} 20 décembre 2010 à 17:51 (CET)

Une première quand même !

Pour vous aussi.

Bonjour. La maladie m’a éloignée de WP ces derniers jours et je vois aujourd’hui que personne ne semble ici avoir signalé ce qui est, quand même, une première pour l’accessibilité sur WP !

J’ai donc le plaisir de vous prier de bien vouloir vous rendre sur Wikipédia:Wikiconcours/septembre 2010/Résultats pour admirer le premier prix jamais attribué dans un wikiconcours « pour les efforts réalisés en matière d'accessibilité ». Et, dans la foulée, je m’attribue sans vergogne une décoration supplémentaire parce que, quand même, si j’en avais pas lancé l’idée…

Dans la foulée aussi, je prends sur moi pour remercier, au nom des concurrents et du jury, l’atelier d’accessibilité, et tout particulièrement Lgd, qui nous ont offert des outils de travail infiniment précieux.

Que 2011 voie vos efforts encore davantage récompensés ! --Égoïté (d) 25 décembre 2010 à 13:41 (CET)

Merci à toi, surtout: bricoler des outils n'est pas très difficile, en susciter l'usage là où il faut est une paire de manche ;-) --Lgd (d) 27 décembre 2010 à 13:11 (CET)

Modèle lang

Bonjour. J'aurais aimé savoir si le modèle {{lang}} devait être utilisé pour les noms de jeux vidéo comme dans cette palette ? Merci. Ascaron ¿! 28 décembre 2010 à 12:03 (CET)

Ce modèle {{lang}} aide entre autres les liseuses à prononcer correctement du texte… donc oui, sa présence est pertinente. — MetalGearLiquid ^{[m’écrire]} 28 décembre 2010 à 14:27 (CET)

C'est nécessaire lorsque la prononciation du mot (ici en anglais) est différent de la prononciation à la française. Dans ce cas, ce n'est pas nécessaire dans la majorité des mots. C'est nécessaire sur "Mario Strikers Charged Football", par exemple, car à la française cela donnerait l'horrible "Mario str-i-kèrss chargède football". Bon, dans le doute, ne pas s'inquiéter : le modèle Lang ne fait pas de mal lorsque la prononciation anglaise est identique à la prononciation française. Dodoïste ^{[ dring-dring ]} 29 décembre 2010 à 16:29 (CET)

Voyons même un peu plus loin, la prononciation d’une langue par rapport à une autre est un critère un petit peu mince à mon avis, tout d’abord d’un pays à l’autre la prononciation peut différer (voire même d’une région à l’autre), mais manifestement d’après ce qu’un très bon prof. d’anglais m’a expliqué, la prononciation de l’anglais a fortement varié au fil du temps (tout particulièrement celui des voyelles… d’ailleurs, toujours selon cette source, les différences de prononciations observées selon les pays découleraient entre autres des diverses dates auxquelles ont eu lieu les flux migratoires, conquêtes, etc.). Dès lors, il me semble très peu recommandable de se passer de la spécification du code langue au prétexte que la prononciation serait identique en français et en anglais.
Et outre cette question purement orientée prononciation, il y a celle plus importante encore du web sémantique… et de la traduction (manuelle, assistée, voire complètement automatisée) qui exige de ne pas se faire l’économie d’un ajout des balises (en cherchant un peu, il est peut-être possible de trouver des sortes d’homonymes et homophones qui seraient de faux amis…), on aurait bien tort de vouloir économiser quelques octets (bien qu’ils ne soient pas homophones, « (en)main » ≠ « main »… et pour ceux qui ne voient pas du premier coup d’œil la différence entre « principal » et « (en)hand », je préfère le préciser). En bref, à mon avis, la spécification de la langue est tout sauf facultative ! — MetalGearLiquid ^{[m’écrire]} 30 décembre 2010 à 13:12 (CET)

Merci pour vos réponses. Ascaron ¿! 30 décembre 2010 à 14:57 (CET)

Bonsoir, je me permets d'en profiter pour poser une autre question, sur les lecteurs d'écrans celle-ci :

• est-ce qu'ils recourent à un dictionnaire de mots pour trouver la prononciation, ou
• est-ce qu'ils interprètent la graphie au cas par cas ?
  Par exemple un nom comme « football » n'aurait aucune raison d'être lu correctement dans le deuxième (*), bien qu'il soit intégré dans le vocabulaire français et donc lu correctement avec le premier (*). Mais dans le message de Dodoïste ci-dessus (concernant "Mario str-i-kèrss chargède football") je comprends plutôt que c'est selon le premier (*) que fonctionnent les lecteurs d'écrans.
  P.S. Encore une autre question : et s'il y a des signes de ponctuation dans le texte, comment réagit le modèle Lang ?
  Merci d'avance pour vos réponses et bonne soirée ! Denhetreil ^{[Prendre une chope]} 30 décembre 2010 à 21:02 (CET)

La transcription phonétique préalable à la lecture s'appuie à la fois sur des règles de prononciation propres à chaque langue (transcription de la graphie au cas par cas) et sur un système de dictionnaires pour des termes spécifiques. L'utilisateur a d'ailleurs la possibilité de compléter ou de modifier ces dictionnaires. Il est également possible de créer de toutes pièces de nouveaux dictionnaires, par exemple pour permettre la lecture correcte des smileys comme :-) ou :-D. La documentation de la synthèse eSpeack donne une illustration assez claire de ce système : eSpeak: Pronunciation Dictionaries.

Deux exemples pour l'illustrer, avec le lecteur d'écran Jaws :

• Le terme « football » : il sera lu légèrement différemment (dans une phrase identifiée comme étant en français) selon qu'il est balisé ou non comme terme en anglais, mais le résultat sera parfaitement compréhensible y compris lorsqu'il est identifié comme étant un terme français. Dans ce cas, ce sont les seules règles de prononciation propres à chaque langue qui jouent.
• Le mot « firefox » : cette fois, Jaws fait appel à son fichier de dictionnaire pour le français, qui lui indique la prononciation « failleurfox ».

Enfin, le modèle lang entraîne la prise en compte de la ponctuation qui y est incluse selon les règles d'intonation etc. propres à la langue concernée. De même, si l'utilisateur active la lecture explicite de la ponctuation, celle-ci est faite dans la langue du contexte au moins dans le cas de Jaws : par exemple, celui-ci annonce « virgule » ou « comma » selon que le texte est balisé comme étant en français ou en anglais.

Cordialement, --Lgd (d) 31 décembre 2010 à 08:58 (CET)

Merci beaucoup pour ta réponse claire et bonne continuation, Denhetreil ^{[Prendre une chope]} 31 décembre 2010 à 11:02 (CET)

{{voyelles}}

yo, j'utilise une grosse police et je n'arrive absolument pas à consulter ce modèle (j'y vois rien). j'ai pas les compétences de régler ca moi-même. un petit coup de main ?  - mirror ☣ Rᴑᴙᴚim  1 janvier 2011 à 01:48 (CET)

Vu la construction CSS disons très particulière du modèle (une véritable horreur), il sera pratiquement impossible de lui permettre de supporter une taille de police aussi élevée (35px si j'en crois Utilisateur:MIRROR/vector.css). Formellement, celle-ci est au-delà du seuil retenu du côté des exigences d'accessibilité : l'exigence maximum est de 200% de la taille par défaut, c'est à dire ici environ 25px. Ce modèle « tient le coup » sans problème jusqu'à environ 20px, les caractères commencent à se superposer entre 20 et 25px sans perte de lisibilité vraiment bloquante.

Les solutions seraient, au choix :

• si on agit du côté du modèle :
  • soit renoncer à sa mise en forme très particulière au profit d'un tableau classique
  • soit conserver cette mise en forme mais en transformant le tout en une image (image map pour conserver les liens)
• ou bien, si tu t'adaptes de ton côté :
  • soit recourir en général au zoom graphique du navigateur plutôt qu'à une modification de la taille de police par défaut (avec le gain d'un agrandissement qui s'étendra aux images)
  • soit garder ton système actuel mais limiter l'agrandissement de la taille du texte pour ce modèle spécifique (ce qui nécessiterait qu'on lui ajoute une classe permettant de le styler spécifiquement dans ton vector.css avec quelque-chose comme #bodyContent .CeModèle { font-size:20px !important; }).

Désolé ne n'avoir pas mieux à proposer.

PS : au cas où l'info serait utile : si tu utilises le navigateur Firefox, l'extension stylish qui permet de réaliser la même chose que le vector.css mais pour n'importe quel site serait peut-être intéressante pour toi ? Cordialement, --Lgd (d) 1 janvier 2011 à 09:23 (CET)

j'ai bien stylish mais je veux pouvoir utiliser mon compte sur n'importe quel PC donc je préfère passer par vector. c'est bien dommage tout ca. merci à toi  - mirror ☣ Rᴑᴙᴚim  1 janvier 2011 à 12:43 (CET)

Nouveau modèle à tester : arbres généalogiques et autres arbos (clagogrammes par exemple).

Attention: les exemples de cladogrammes ci-dessous ne sont plus fonctionnels : le modèle final {{Arbre début}} se limite aux arbres généalogiques et autres arbres qui ne comportent pas de noeuds sans libellé.

Bonjour,
Une chose en entraînant une autre, suite à cette discussion et à cete page de tests, j'ai enfin cessé de de procrastiner sur un vieux sujet qui est celui des différents modèles ou des techniques hors-modèles pour produire dans les articles une arborescence, typiquement un arbre généalogique (les bêbêtologues font aussi de leur côté des cladogrammes C'est mon cadeau de Noël tardif pour Salix, disons)).

Bref, voici un modèle à tester en activant le gadget « Arborescences » dans vos Spécial:Préférences (section « Outils avancés » ; ce qui active la CSS nécessaire pour ce modèle) et le cas échéant en rechargeant le cache de vos navigateurs. Il permet de réaliser un arbre (« horizontal ») structuré côté HTML sous forme de listes imbriquées, et donc d'éviter les arbres en tableau de mise en forme (abomination) ou en art ASCII (l'éternité dans les flammes sans rémission). Il est sommairement documenté avec un exemple dans Modèle:Arbre début.

La solution est évidemment encore très imparfaite (la syntaxe actuelle est proprement imbittable, j'avoue) : tous vos tests et vos retours seront les bienvenus pour la finaliser.

Cordialement, --Lgd (d) 1 janvier 2011 à 15:20 (CET)

C'est super ! Est-ce qu'il y aurait un moyen de contrôler la longueur des branches dans {{Cladogramme}} ou {{Clade}} ? Par exemple : si je veux faire apparaître les feuilles 1, 2 et 3 à la même verticale dans l'exemple suivant ? TED 2 janvier 2011 à 02:32 (CET)

	Feuille1 Feuille2 Feuille3

Attention : il faut actualiser le cache de votre navigateur, j'ai dû modifier la feuille de style pour essayer de gérer ces branches sans libellé. Pour l'instant, cela donnerait quelque-chose comme ci-dessous. Cordialement, --Lgd (d) 2 janvier 2011 à 06:30 (CET)

• Modèle:*!
  • Modèle:*-
    • Modèle:*-
    • Modèle:*~
  • Modèle:*~

Ce n'est pas une « branche sans libellé », c'est un « nœud sans libellé » ? Où alors on ne se comprend pas. TED 2 janvier 2011 à 07:16 (CET)

Oui, noeud sans libellé si tu préfères. Cordialement, --Lgd (d) 2 janvier 2011 à 07:20 (CET)

Est-ce qu'il serait possible d'avoir des images d'exemples des résultats ? Pour montrer le rendu à ceux qui n'ont pas activé (ou n'ont pas compris qu'il fallait activer) le gadget dans leurs préférences. TED 2 janvier 2011 à 07:40 (CET)

rendu type du modèle lors de la tentative de gestion des cladogrammes, qui n'a pas été retenue finalement.

exemple d'un arbre généralogique réel

Vite fait (mal fait), ci-contre. Cordialement, --Lgd (d) 2 janvier 2011 à 08:12 (CET)

Attention : il faut encore actualiser le cache de votre navigateur.

Une question à propos des clades et des noeuds sans libellés : pour le peu que j'ai rapidement compris côté contenu, il s'agit bien d'items non nommés. Est-ce qu'un rendu comme ci-dessous serait une hérésie ? Cordialement, --Lgd (d) 2 janvier 2011 à 12:51 (CET)

• Modèle:*!
  • Modèle:*-
    • Modèle:*-
    • Modèle:*~
  • Modèle:*~

Je pense que les deux peuvent être utiles : un nœud sans libellé du tout ou un nœud avec un ?.

Pour la longueur des branches, on peut faire quelque chose ? TED 4 janvier 2011 à 21:24 (CET)

Oui, on va. Cordialement, --Lgd (d) 5 janvier 2011 à 05:32 (CET)

Bon, ça le fait (actualisez le cache de votre navigateur. Je n'aime pas du tout cette CSS effroyablement verbeuse, mais sauf idée géniale d'ici la fin du WE, ou contribution habile d'un autre intégrateur CSS, je vais passer ça dans Common.css dimanche. Il faudra attendre quelques jours pour que la modification se répercute chez tous les utilisateurs (on va dire une semaine) et ce sera bon pour l'utiliser. Cordialement, --Lgd (d) 8 janvier 2011 à 12:13 (CET)

Cela répond à la question de l'alignement vertical, mais cela ne répond pas du tout à la question : est-il possible de gérer la longueur des branches ? Cf. les arbres de cet article fig. 1 et 2 par exemple où les longueur des branches sont toutes différentes, et ont une signification. (Et aussi : l'épaisseur des branches ?)TED 8 janvier 2011 à 13:05 (CET)

Et pour l'alignement vertical, ce serait mieux sans le décroché, car si on veut faire des choses dans le style de cet article, ça va vite être illisible avec des décrochements partout. TED 8 janvier 2011 à 13:21 (CET)

Hum... avec des documents, on voit enfin mieux ce dont il s'agit. Mais du coup: non, on ne le fera pas, désolé. Cela dépasse les capacités limitées dans le cadre des modèles wiki et d'un peu de mise en forme CSS, si on veut un code sémantique à la base et des modèles raisonnablement complexes. Du coup, on va sans doute s'en tenir finalement aux arbres généalogiques, je pense. Cordialement, --Lgd (d) 8 janvier 2011 à 15:22 (CET)

Pour les arbres phylogénétiques avec annotations, il vaut peut-être mieux utiliser un outil comme TreeVector: Scalable, Interactive, Phylogenetic Trees for the Web puis importer l'image au format SVG ? --Anneyh (d) 8 janvier 2011 à 23:28 (CET)

Disons que ce serait au moins en partie faisable sans les limitations imposées par mediawiki (pas de possibilité de créer des CSS en commentaires conditionnels pour les anciens IE, obligation de s'en tenir aux possibilités syntaxiques des modèles, contrainte de simplicité de la syntaxe de modèles pour les contributeurs). Mais là, non, au moins pas tant qu'on devra faire avec des navigateurs limités dans leur support CSS (c'est un problème de sélecteurs essentiellement). Mais pour l'instant, en effet, il vaut mieux en rester à des outils de production d'image via SVG.

Bref : j'ai basculé dans Mediawiki:Common.css les style nécessaires à l'utilisation des modèles {{Arbre début}}, {{Arbre fin}} et {{Arbre/Branche finale}}, avec au final une syntaxe aussi simple que possible pour les contributeurs, mais pas de support de ces fameux noeuds vides (l'utilisation pour les cladogrammes est donc actuellement exclue : ces modèles sont surtout destinés aux arbres de type généalogique). Il faudra attendre une petite semaine, comme toujours, pour les caches navigateurs des visiteurs de Wikipédia se soient actualisés, et l'utilisation pourra commencer.

Cordialement, --Lgd (d) 9 janvier 2011 à 13:25 (CET)

Et {{Cladogramme}} ou {{Clade}} ? on a le droit de les utiliser ? Je me rends compte que tu ne parles plus que de {{arbre début}} etc., alors que j'avais soulevé une question de longueur de branches pour {{Cladogramme}}. TED 9 janvier 2011 à 17:31 (CET)

Étant donné que pour l'instant il n'y a pas de modèle de remplacement de meilleure qualité, oui, évidemment, {{Cladogramme}} et {{Clade}} restent les modèles de base. Je continue à travailler sur les exigences propres aux cladogrammes (que j'ai fini par bien capter) mais autant ne pas différer ce qui peut déjà être fait pour les arbres généalogiques (à terme, on aura sans doute deux jeux de modèles différents mais reposant sur un lot en partie commun de styles CSS). A vrai dire, j'ai des choses en local qui ne sont pas mal, mais les vieilles versions de navigateurs encore très utilisées posent un souci non négligeable. Cordialement, --Lgd (d) 10 janvier 2011 à 10:14 (CET)

Poème, balise et retrait

La balise poem est souvent utilisé pour mettre en forme les poèmes. En cela elle est bien pratique, mais est-elle accessible ?

Et comment gérer les retraits avec cette balise ? Sur la Wikisource, on trouve deux « écoles », jeter du blanc (pour les plus typographes ?) ou bien mettre des « : » (parce que ça sert aussi à faire des retraits hors de la balise poem ?). Du coup, ne sachant trancher je me tourne vers vous pour me dire ce qui est le mieux entre : s:br:Pajenn:Abgrall_-_Luc_hed_ha_Moged.djvu/15 ou s:br:Pajenn:Abgrall_-_Luc_hed_ha_Moged.djvu/17 (ou bien aucune des deux ou bien indifféremment l'une ou l'autre).

Cdlt, Vigneron * ^discut. 4 janvier 2011 à 21:38 (CET)

PS: au passage, si vous êtes intéressé par améliorer l’accessibilité sur les Wikisources, vous êtes les bienvenues et vous pouvez vous servir de la Wikisource brittophone comme zone de test si besoin.

Merci pour ces bonnes questions. Pour la balise POEM, je crois qu'elle est accessible lorsqu'elle est bien utilisée. « Bien utilisée » étant l'essentiel du problème. Lorsqu'on lui colle des « :: » en plein milieu pour simuler les alinéas, la balise POEM le gère très mal et fait quelque chose d'assez moche pour l'accessibilité.

Qu'est-ce que tu appelles jeter du blanc ? Les espaces insécables ? Je sais pas si ça pose un réel problème, mais il y a un risque qu'un lecteur d'écran fasse une pause longue, car il va respecter la ponctuation à la lettre. Lgd peux-tu confirmer ?

Pour les « : » c'est mal, car cela génère des listes de définitions. En gros, il y a « ; » qui indique un terme défini. Et juste après, il y a « : » qui indique la définition du terme sus-mentionné. Or, il se trouve que ces deux snytaxes ont un rendu par défaut, l'un en gras et l'autre pour l'alinéa. Ceux deux éléments ont été utilisé juste pour la mise en forme, plutôt que la rigueur sémantique. C'est très mal.

Ah, et les beaux titres faits à coup de gras, de majuscules et de « <big> ». Et j'en passe. Il y a vraiment un gros boulot d'accessibilité à faire sur Wikisource. Et c'est dommage, car ce sont à la base simplement des livres contenant du texte, ce devrait être le plus accessible du monde, très simplement. Mais non. :D

On pourrait commencer par quelques bonnes pratiques assez simples pour les rédacteurs. Je veux bien le faire lorsque j'aurai un moment, mais cela risque bien de ne pas être de sitôt. J'ai les pages d'aides à améliorer d'abord. Bien à toi, Dodoïste ^{[ dring-dring ]} 4 janvier 2011 à 22:09 (CET)

Bonjour,
<poem> ne pose pas de problèmes liés à l'accessibilité. Pour les questions d'indentation du texte, les accumulations d'espaces insécables ne poseront pas de problèmes majeurs même si ce n'est pas optimal ; en revanche il faut en effet proscrire le recours à « : » (liste de définition comme expliqué par Dodoïste).

Après... Le code actuellement généré par poem n'a pas la sémantique qui conviendrait dans le cas (c'est un bloc pre avec un choix de police de caractère adapté au contenu qui devrait être produit, il gèrerait de manière correcte les espaces typographiques jugés ici significatifs et faisant partie du contenu). Mais cette balise wiki a l'immense mérite d'exister et de permettre à l'avenir une éventuelle amélioration du code généré par mediawiki. Donc : définitivement oui pour poem même si ce serait perfectible. Cordialement, --Lgd (d) 5 janvier 2011 à 05:30 (CET)

Titre caché -> tableau moche (sous firefox)

Ia ora na i te matahiti 'api

Pour ceux qui avaient suivi, j'avais évoqué un léger "bug" des titres de tableaux cachés sous firefox (quelque part par là je sais plus où...). Alors, mieux que des mots, des exemples.

Exemples de tableaux

Statistiques par saison

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
2001-02	Subways de Dartmouth	NSMHL		74	95	98	193	114		7	11	13	24	0
2002-03	Shattuck-St. Mary's School	High MN		57	72	90	162	-		-	-	-	-	-
2003-2004	Océanic de Rimouski	LHJMQ		59	54	81	135	74		9	7	9	16	10
2004-2005	Océanic de Rimouski	LHJMQ		62	66	102	168	84		13	14	17	31	16
2005-2006	Penguins de Pittsburgh	LNH		81	39	63	102	110		-	-	-	-	-
2006-2007	Penguins de Pittsburgh	LNH		79	36	84	120	60		5	3	2	5	4
2007-2008	Penguins de Pittsburgh	LNH		53	24	48	72	39		20	6	21	27	12
2008-2009	Penguins de Pittsburgh	LNH		77	33	70	103	76		24	15	16	31	14
2009-2010	Penguins de Pittsburgh	LNH		81	51	58	109	71		13	6	13	19	6
Totaux LNH				371	183	323	506	356		62	30	52	82	36

Statistiques par saison

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
2001-02	Subways de Dartmouth	NSMHL		74	95	98	193	114		7	11	13	24	0
2002-03	Shattuck-St. Mary's School	High MN		57	72	90	162	-		-	-	-	-	-
2003-2004	Océanic de Rimouski	LHJMQ		59	54	81	135	74		9	7	9	16	10
2004-2005	Océanic de Rimouski	LHJMQ		62	66	102	168	84		13	14	17	31	16
2005-2006	Penguins de Pittsburgh	LNH		81	39	63	102	110		-	-	-	-	-
2006-2007	Penguins de Pittsburgh	LNH		79	36	84	120	60		5	3	2	5	4
2007-2008	Penguins de Pittsburgh	LNH		53	24	48	72	39		20	6	21	27	12
2008-2009	Penguins de Pittsburgh	LNH		77	33	70	103	76		24	15	16	31	14
2009-2010	Penguins de Pittsburgh	LNH		81	51	58	109	71		13	6	13	19	6
Totaux LNH				371	183	323	506	356		62	30	52	82	36

Statistiques par saison

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
2001-02	Subways de Dartmouth	NSMHL		74	95	98	193	114		7	11	13	24	0
2002-03	Shattuck-St. Mary's School	High MN		57	72	90	162	-		-	-	-	-	-
2003-2004	Océanic de Rimouski	LHJMQ		59	54	81	135	74		9	7	9	16	10
2004-2005	Océanic de Rimouski	LHJMQ		62	66	102	168	84		13	14	17	31	16
2005-2006	Penguins de Pittsburgh	LNH		81	39	63	102	110		-	-	-	-	-
2006-2007	Penguins de Pittsburgh	LNH		79	36	84	120	60		5	3	2	5	4
2007-2008	Penguins de Pittsburgh	LNH		53	24	48	72	39		20	6	21	27	12
2008-2009	Penguins de Pittsburgh	LNH		77	33	70	103	76		24	15	16	31	14
2009-2010	Penguins de Pittsburgh	LNH		81	51	58	109	71		13	6	13	19	6
Totaux LNH				371	183	323	506	356		62	30	52	82	36

 

Deux choses fonctionnent "mal" (pour résumé, c'est « moche ») :

• Le premier exemple fonctionne normalement avec le titre visible
• Le deuxième marche "mal" :
  • disparition aléatoire des lignes de séparation verticale entre "ligue" et "Saisons régulières" et entre "saisons régulières" et "Séries éliminatoires"
  • apparition d'une ligne plus épaisse au-dessus du tableau mais uniquement sur les 2 premières colonnes (sous IE, c'est pas mieux avec une ligne simple au-dessus de la première colonne)
• Le troisième, avec la « class wikitable » fonctionne mieux que le deuxième :
  • toujours apparition d'une ligne plus épaisse au-dessus du tableau sur les 2 premières colonnes
  • les couleurs ne fonctionnent plus (peut-on remédier à ça autrement qu'avec style="background:..."? )

Quelqu'un a-t-il une solution (hormis celle, chère à Dodoïste et que j'essaie le plus possible de mettre en oeuvre, de ne pas cacher les titres de tableaux) ? --'toff ^[discut.] 5 janvier 2011 à 06:22 (CET)

Bonjour,
Il y a plusieurs erreurs, bugs et codes superflus qui s'entremêlent, en fait :

• le titre masqué qui fait apparaître une bordure indésirable au dessus des deux premières colonnes : c'est un effet de bord de la technique utilisée actuellement pour la classe hidden. Il faudra voir exactement ce que donnerait dans les différents navigateurs une variante de celle-ci (qu'on pourrait alors spécifier dans common.css) qui est rapidement illustrée dans l'exemple ci-dessous (remplacer les styles actuels de cette par un simple text-indent négatif dans le cas d'un caption).
• le gras ('''Statistiques par saison''') est inutile pour les captions qui sont déjà en gras via common.css.
• des attributs en trop dans la déclaration du tableau : ne pas conjuger wikitable avec cellpadding, cellspacing ni border. Les styles border-collapse: collapse; et border: gray solid 1px; sont également inutiles.
• l'attribut bgcolor ne doit pas être utilisé : il faut utiliser style="background:..." (les styles CSS de common.css l'emportent systématiquement sur les attributs comme bgcolor).
• les couleurs des cellules d'en-têtes, si elles doivent différer de celle prévue par la classe wikitable, ne doivent pas être indiquée pour la ligne (|-) mais pour chacune des cellules.
• est-ce que la classe alternance (à joindre à wikitable comme ci-dessous) ne conviendrait pas pour les couleurs de lignes alternées ?
• les rowspan des colonnes vides doivent être exacts (ici, 12) pour éviter le défaut de bordure en bas du tableau.

Ci-dessus, l'exemple n°3 rapidement corrigé (attention, pour le caption, c'est un test). Cordialement, --Lgd (d) 5 janvier 2011 à 07:16 (CET)

Statistiques par saison

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
2001-02	Subways de Dartmouth	NSMHL		74	95	98	193	114		7	11	13	24	0
2002-03	Shattuck-St. Mary's School	High MN		57	72	90	162	-		-	-	-	-	-
2003-2004	Océanic de Rimouski	LHJMQ		59	54	81	135	74		9	7	9	16	10
2004-2005	Océanic de Rimouski	LHJMQ		62	66	102	168	84		13	14	17	31	16
2005-2006	Penguins de Pittsburgh	LNH		81	39	63	102	110		-	-	-	-	-
2006-2007	Penguins de Pittsburgh	LNH		79	36	84	120	60		5	3	2	5	4
2007-2008	Penguins de Pittsburgh	LNH		53	24	48	72	39		20	6	21	27	12
2008-2009	Penguins de Pittsburgh	LNH		77	33	70	103	76		24	15	16	31	14
2009-2010	Penguins de Pittsburgh	LNH		81	51	58	109	71		13	6	13	19	6
Totaux LNH				371	183	323	506	356		62	30	52	82	36

Bon, voyons ça :

• effet de bord : fonctionne pour cet exemple (en espérant qu'il puisse être "gommé" sans qu'on ait besoin d'artifice ?)
• gras pour les captions : pourtant ça n'apparaît pas en gras sous mon navigateur ?
• attributs en trop : en fait, j'ai juste rajouté wikitable au code du tableau précédent pour marquer la différence visuellement
• ok, je comprends bien que je dois changer bgcolor par style="background:..." dans l'avenir (je vais corriger mon monobook)
• pfff, ça complique le code !
• est-ce qu'on ne pourrait pas encore plus marquer par défaut la différence entre les couleurs des lignes horizontales (j'avais déjà parlé du contraste trop léger sur le bistrot il me semble)
• l'effet de bordure final est un défaut accepté (et c'est en ce sens que je l'avais laissé), au moins par le projet hockey : en effet, il simplifie l'ajout de donnée par les IP ou contributeurs non habitués de wikipédia qui peuvent rajouter aisément une ligne de statistique sans se préoccuper "trop" du code. Les habitués, se chargent de "fermer" le tableau lorsque le joueur prend sa retraite. C'est une convention de notre projet qui, me semble, permet une certaine souplesse. --'toff ^[discut.] 5 janvier 2011 à 08:06 (CET)

• Si la solution pour le caption masqué fonctionne bien selon les navigateurs, la modification sera totalement transparente pour les contributeurs qui continueront à utiliser la classe hidden (celle-ci sera simplement modifiée dans Common.css dans le cas précis où elle s'applique à un caption).
• le caption en gras ah... Je ne suis décidément pas réveillé ce matin : le caption n'est automatiquement en gras que si la classe wikitable est utilisée. Je me demande s'il ne faudrait pas corriger cette incohérence en modifiant là aussi common.css pour avoir un gras par défaut dans tous les cas ?
• wikitable gère directement via les styles CSS de common.css ce qui doit sinon être précisé au cas par cas par exemple via les attributs HTML. Il n'y a guère que le centrage du contenu dans les cellules et la taille de police qui peuvent nécessiter d'être précisés dans l'attribut style de {|. le mieux, quand on utilise wikitable, est donc de partir systématiquement du code minimal des exemples de l'aide (tiens : malheureusement, le bouton insérer un tableau de la barre d'édition ne produit pas un code correct, mais je crains que l'on n'ait pas la main sur les scripts concernés).
• pour la classe alternance, le choix de couleurs n'est pas encore tout à fait au point, en effet quand wikitable et alternance sont appliquées simultanément. Il faudrait ajouter à Common.css une règle supplémentaire pour les lignes claires.
• ah... Ok pour le coup du rowspan, c'est habile, ça

Cordialement, --Lgd (d) 5 janvier 2011 à 08:24 (CET)

• A priori, ca fonctionne sous IE et Firefox, à voir pour Opera, Safari ou encore Google Chrome ?
• Je suis d'accord avec toi.
• Mon monobook s'adapte
• A améliorer alors ?
• Le mieux est l'ennemi du simple : on ne fait pas que se bagarrer dans le hockey

--'toff ^[discut.] 5 janvier 2011 à 08:41 (CET)

vite fait. Sous chrome c'est joli aussi. Toff, je te laisse mettre en place le tableau définitif des stats sur la page de Crosby et mettre à jour notre page d'aide. et après, paffff je duplique !! --TaraO (d) 5 janvier 2011 à 09:04 (CET)

le défaut d'alternance par contre est le suivant : si un joueur joue au cours de la même saison dans deux équipes différentes ou même dans deux ligues différentes, on aime bien mettre la même couleur de ligne pour deux lignes consécutives. Si on alterne, on pourra pas faire ça (saison 1935-1936). --TaraO (d) 5 janvier 2011 à 09:07 (CET)

Exemples de tableaux

Statistiques de Morenz

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
1919–20	Midgets de Stratford	AHO Jr.		5	14	4	18	—		7	14	12	26	—
1920–21	Midgets de Stratford	AHO Jr.		8	19	12	31	—		13	38	18	56	—
1921–22	Midgets de Stratford	AHO Jr.		4	17	6	23	10		5	17	4	21	—
1921–22	Indians de Stratford	AHO Sr.		4	10	3	13	2		8	15	8	23	21
1922–23	Indians de Stratford	AHO Jr.		10	15	13	28	19		10	28	7	35	36
1923-1924	Canadiens de Montréal	LNH		24	13	3	16	20		6	7	3	10	10
1924-1925	Canadiens de Montréal	LNH		30	28	11	39	46		6	7	1	8	8
1925-1926	Canadiens de Montréal	LNH		31	23	3	26	39
1926-1927	Canadiens de Montréal	LNH		44	25	7	32	49		4	1	0	1	2
1927-1928	Canadiens de Montréal	LNH		43	33	18	51	66		2	0	0	0	12
1928-1929	Canadiens de Montréal	LNH		42	17	10	27	47		3	0	0	0	6
1929-1930	Canadiens de Montréal	LNH		44	40	10	50	72		6	3	0	3	10
1930-1931	Canadiens de Montréal	LNH		39	28	23	51	49		10	1	4	5	10
1931-1932	Canadiens de Montréal	LNH		48	24	25	49	46		4	1	0	1	4
1932-1933	Canadiens de Montréal	LNH		46	14	21	35	32		2	0	3	3	2
1933-1934	Canadiens de Montréal	LNH		39	8	13	21	21		2	1	1	2	0
1934-1935	Black Hawks de Chicago	LNH		48	8	26	34	21		2	0	0	0	0
1935-1936	Black Hawks de Chicago	LNH		23	4	10	14	20
	Rangers de New York	LNH		19	2	5	7	6
1936-1937	Canadiens de Montréal	LNH		30	4	16	20	12
Totaux LNH				550	271	201	472	546		47	21	12	33	6

Statistiques par saison

Saison	Équipe	Ligue		Saison régulière						Séries éliminatoires
				PJ	B	A	PTS	PUN		PJ	B	A	PTS	PUN
1919–20	Midgets de Stratford	AHO Jr.		5	14	4	18	—		7	14	12	26	—
1920–21	Midgets de Stratford	AHO Jr.		8	19	12	31	—		13	38	18	56	—
1921–22	Midgets de Stratford	AHO Jr.		4	17	6	23	10		5	17	4	21	—
1921–22	Indians de Stratford	AHO Sr.		4	10	3	13	2		8	15	8	23	21
1922–23	Indians de Stratford	AHO Jr.		10	15	13	28	19		10	28	7	35	36
1923-1924	Canadiens de Montréal	LNH		24	13	3	16	20		6	7	3	10	10
1924-1925	Canadiens de Montréal	LNH		30	28	11	39	46		6	7	1	8	8
1925-1926	Canadiens de Montréal	LNH		31	23	3	26	39
1926-1927	Canadiens de Montréal	LNH		44	25	7	32	49		4	1	0	1	2
1927-1928	Canadiens de Montréal	LNH		43	33	18	51	66		2	0	0	0	12
1928-1929	Canadiens de Montréal	LNH		42	17	10	27	47		3	0	0	0	6
1929-1930	Canadiens de Montréal	LNH		44	40	10	50	72		6	3	0	3	10
1930-1931	Canadiens de Montréal	LNH		39	28	23	51	49		10	1	4	5	10
1931-1932	Canadiens de Montréal	LNH		48	24	25	49	46		4	1	0	1	4
1932-1933	Canadiens de Montréal	LNH		46	14	21	35	32		2	0	3	3	2
1933-1934	Canadiens de Montréal	LNH		39	8	13	21	21		2	1	1	2	0
1934-1935	Black Hawks de Chicago	LNH		48	8	26	34	21		2	0	0	0	0
1935-1936	Black Hawks de Chicago	LNH		23	4	10	14	20
	Rangers de New York	LNH		19	2	5	7	6
1936-1937	Canadiens de Montréal	LNH		30	4	16	20	12
Totaux LNH				550	271	201	472	546		47	21	12	33	6

 

Hum... Pour le défaut d'alternance dans ce cas : le problème peut se poser plus généralement dans d'autres tableaux, cela vaut vraiment la peine de résoudre ça. je vois à peu près comment le faire sans trop alourdir le script concerné. Je vais regarder en même temps que la question des lignes claires à améliorer (Encore une chose urgente sur ma todo Il n'y a hélas pas grand monde actuellement pour intervenir sur cette technique de script spécifique : il faut vraiment que d'autres contributeurs se mettent au jQuery ). Cordialement, --Lgd (d) 5 janvier 2011 à 09:36 (CET)

Bon, du coup, j'ai installé Opéra sur mon ordi qui ne fonctionnait plus mais qui refonctionne depuis que je l'ai fait surchauffer... et le rendu est aussi efficace. Il ne manque plus qu'un avis "safari".

TaraO, je m'occupe demain de Crosby de l'aide et de mon monobook. (Faut que j'aille me coucher)

Fatiguants ces gars du projet hockey non ? --'toff ^[discut.] 5 janvier 2011 à 09:43 (CET)

Nonon, au contraire : stimulants, ils appuient utilement là où il faut --Lgd (d) 5 janvier 2011 à 10:15 (CET)

Lgd, tu penses toujours à nous hein pour ce sujet ? --TaraO (d) 10 janvier 2011 à 21:36 (CET)

c'est fait pour la couleur des lignes claires et pour le caption masqué (voir ici, il faudra le temps que les caches de navigateurs s'actualisent). Il reste à traiter le cas des lignes commençant par un rowspan. Cordialement, --Lgd (d) 11 janvier 2011 à 06:40 (CET)

Le deutéranope que je suis est content --'toff ^[discut.] 11 janvier 2011 à 17:18 (CET)

C'est bien aussi sous safari. Udufruduhu (d) 11 janvier 2011 à 17:35 (CET)

Citation

Bonjour. Je trouve dans Maltais : {{#tag:ref|« texte de plusieurs lignes »<ref name="DiodoreV12"/>|group=Note}} Comment fait-on dans ce cas pour le balisage de la citation ? Merci déjà pour vos réponses, --Égoïté (d) 5 janvier 2011 à 13:54 (CET)

Comme d'habitude (le fait que la citation soit en note ne change pas la conduite à tenir). Cordialement, --Lgd (d) 5 janvier 2011 à 14:02 (CET)

Grand merci Lgd, --Égoïté (d) 5 janvier 2011 à 15:53 (CET)

Euh... Je ne pige pas : 1/ ta correction n’est pas repérée par le gadget mais surtout 2/ en claire des guillemets entourent Les habitants de Melita sont une colonie de Phéniciens, qui commerçant jusque dans l'Océan occidental, firent un entrepôt de cette île, que sa situation en pleine mer et la bonté de ses ports rendaient très favorable pour eux. alors qu’il n’y en a pas en source et que la balise citation est placée ailleurs... --Égoïté (d) 5 janvier 2011 à 16:01 (CET)

Hum ? Dans la note 6 où se trouve le contenu en question (si j'ai bien suivi), la citation est à présent détectée par le gadget et va de « La première est l'île de Melita, éloignée de huit cents stades de Syracuse... » à « ...Ses ports sont très commodes, c'est aussi une colonie des Phéniciens ». Ou alors, s'agissait-il d'un autre contenu ? Cordialement, --Lgd (d) 5 janvier 2011 à 16:07 (CET)

Je revois ça dans la journée et reviens te dire quoi. --Égoïté (d) 6 janvier 2011 à 09:16 (CET)

Sorry, perdue dans les cavités souterraines, j’ai omis de vérifier. Non, ce n’est pas la note 6, c’est dans le paragraphe qui suit, à regarder en source. En clair les guillemets apparaissent juste après la note 7. Amclt, --Égoïté (d) 8 janvier 2011 à 08:28 (CET)

J'ai balisé la citation... Cordialement, --Lgd (d) 8 janvier 2011 à 08:57 (CET)

Tableaux (encore)

Au fait, à force de chercher la petite bête de plus en plus loin, j'en oublie mes basiques et une question qui me démange depuis quelques temps. Sur l'exemple plus haut on a (je ne reprends qu'une partie pour faire court) :

{| style="font-size: 95%; text-align: center;" class="wikitable alternance"
|+ style="text-indent: -5000px" | Statistiques par saison
|-
! scope=col rowspan="2" style="background: #e0e0e0;" |Saison
! scope=col rowspan="2" style="background: #e0e0e0;" |Équipe
! scope=col rowspan="2" style="background: #e0e0e0;" |Ligue
|-
| 2001-02 || Subways de Dartmouth || NSMHL || 
|- 
|2002-03 || Shattuck-St. Mary's School || High MN || 
|- 
|[[Saison 2003-2004 de la LHJMQ|2003-2004]] || [[Océanic de Rimouski]] || 
|}

C'est quand même un tableau à double entrée alors ne vaudrait-il mieux pas écrire :

{| style="font-size: 95%; text-align: center;" class="wikitable alternance"
|+ style="text-indent: -5000px" | Statistiques par saison
|-
! scope=col rowspan="2" style="background: #e0e0e0;" |Saison
! scope=col rowspan="2" style="background: #e0e0e0;" |Équipe
! scope=col rowspan="2" style="background: #e0e0e0;" |Ligue
|-
! scope=row | 2001-02
| Subways de Dartmouth || NSMHL || 
|- 
! scope=row | 2002-03
| Shattuck-St. Mary's School || High MN || 
|- 
! scope=row | [[Saison 2003-2004 de la LHJMQ|2003-2004]]
| [[Océanic de Rimouski]] || 
|}

Peut-on avoir des en-têtes de ligne sous un en-tête de colonne (je sais pas si je suis clair) ? --'toff ^[discut.] 5 janvier 2011 à 17:06 (CET)

Edit : je viens de voir que tu avais mis un row sur la dernière ligne total, ça me permet de reposer ma question plus simplement : le scope row prend-il le pas sur le scope col au-dessus ou sont-ils interprétés tous les deux ? (tiens, c'est un conseil qui manque dans les tableaux ça non ?) --'toff ^[discut.] 5 janvier 2011 à 17:08 (CET)

<Bonjour Edith /> La frontière entre tableau à double entrée et tableau simple (le premier cas) n'est pas vraiment tranchée. Ici, les deux possibilités se valent, l'essentiel pour l'accessibilité du tableau étant ses en-têtes de colonnes.

Pour mon scope row, disons que c'est déjà plus utile puisqu'il s'agit d'une ligne très particulière. Les deux (row et col) sont interprétés. Cordialement, --Lgd (d) 5 janvier 2011 à 17:12 (CET)

Donc la première version reste une bonne version (et moins codée de surcroit) ? --'toff ^[discut.] 5 janvier 2011 à 17:21 (CET)

Toutafé. Cordialement, --Lgd (d) 5 janvier 2011 à 17:22 (CET)

Devinez qui c'est ? Tiens en regardant tout ça avec le gadget, je m'aperçois que la ligne finale et le scope row croise les deux lignes verticales vides. N'y a-t-il pas conflit ? --'toff ^[discut.] 6 janvier 2011 à 01:45 (CET)

Non, la présence de cellules vides n'est pas problématique. Cela rend le tableau un tout petit peu plus compliqué à comprendre du premier coup dans un lecteur d'écran, mais ce n'est pas bloquant, il n'y a pas lieu de modifier en renonçant à cette mise en forme par ailleurs utile pour les autres utilisateurs.

Bon, je vends la mèche : pour tout te dire, ce tableau comporte effectivement un défaut (toute autre), mais dont la solution serait trop lourde et complexe pour être compatible avec l'utilisation aisée du modèle par les rédacteurs. Comme il s'agit d'un souci mineur pour l'accessibilité dans ce cas précis, je l'ai passée sous silence. Le gadget ne la signale pas mais c'est un point abordé dans les bonnes pratiques... Quelqu'un saura-t-il le trouver ?

Cordialement, --Lgd (d) 6 janvier 2011 à 08:43 (CET)

Hum, tu piques ma curiosité... Vite fait, les seuls trucs que j'ai vu et qu'on n'utilise pas : id / headers et summary. Je chauffe ? ou pas ? --'toff ^[discut.] 6 janvier 2011 à 09:03 (CET)

Et en plus, il est bon, le bougre. --Lgd (d) 6 janvier 2011 à 13:02 (CET)

Merci, mais je n'ai pas encore trouvé l'astuce. Bon, puisqu'il me semble que summary soit trop simple, je suppose que c'est id / headers ?

Le problème viendrait peut-être alors soit des deux scope col sur deux lignes consécutives (saison régulière suivie de PJ, B, A etc.) soit de la ligne totaux. Ma préférence, en l'état actuel de mes réflexions, va à la première explication ? --'toff ^[discut.] 7 janvier 2011 à 05:13 (CET)

Suite de mes réflexions : en fait ça vient peut-être plus du fait qu'il existe deux fois les mêmes colonnes : PJ, B, A, PTS, PUN ? --'toff ^[discut.] 7 janvier 2011 à 05:38 (CET)

Suspens...

En fait le problème est lié à la cellule « Totaux LNH » et aux informations qui lui sont ajoutées via les SCOPE COL des autres cellules d'en-têtes. Tu visualises ? Enfin, visualiser, c'est une façon de parler : c'est dans un lecteur d'écran que le problème se pose, quand on demande le rappel des en-têtes liés à une cellule. Cordialement, --Lgd (d) 7 janvier 2011 à 20:25 (CET)

Bon, c'était la deuxième hypothèse. Si je comprends bien (en jetant entre autres un oeil sur la discussion plus bas a propos de la palette), Totaux LNH est lié aux trois colonnes saison/équipe/ligue/ via les scope col. Pour éviter ça il faudrait utiliser id/header qui a le défaut d'être nécessaire dans chaque cellule et donc alourdir le code (voir être imbuvable pour les non connaisseurs), j'ai bon ? --'toff ^[discut.] 7 janvier 2011 à 22:01 (CET)

Je vais enfin pouvoir prendre ma retraite, la relève est assurée . Cordialement, --Lgd (d) 8 janvier 2011 à 12:18 (CET)

Tu me laisses tes pourcentages (voir la discussion plus bas) ? Sans rire, je progresse (de toute façon, je pouvais pas régresser !) mais y a encore du boulot ! --'toff ^[discut.] 8 janvier 2011 à 19:52 (CET)

Allez, je l'ai tenté sur ce tableau (joueur à la retraite donc ce tableau est "terminé", on peut se permettre d'y insérer des trucs incompréhensibles), tu me dis ce que tu en penses. --'toff ^[discut.] 8 janvier 2011 à 20:05 (CET)

Pour les AdQ

Bonjour. Je me suis mise à la vérification des articles proposés en AdQ en partant des plus anciennes propositions et les remarques que j’ai faites dans les pages de vote ont amené plusieurs contributeurs à faire un sérieux effort. Je me demandais si nous ne pourrions pas proposer l’aide de l’atelier en nous partageant la besogne.

Par ex : je me sens à l’aise avec les alt, je pourrais, pour ce critère, expliquer, relire, corriger si nécessaire ; je peux vérifier aussi les codes langues (même si les alt, ça demande beaucoup de temps, donc si quelqu’un pouvait se charger les Lang..) ; par contre les tableaux... déjà que je les déteste globalement..., je préfèrerais que quelqu’un d’autre s’y colle. Pour les citations, cela ne prend pas tellement de temps à vérifier mais c’est l’accumulation des vérifications qui fait beaucoup au total, donc s’il y avait une autre personne... Globalement les titres et les listes ne posent pas de problème.

Ce serait sans doute plus simple et plus convivial pour les auteurs de connaître la personne à qui s’adresser directement. Qu’en pensez-vous ? Amclt, --Égoïté (d) 6 janvier 2011 à 09:15 (CET)

En parlant des AdQ, j'ai ajouté « notes et références » qui me semblaient manquant pour le changement de langue. Il est plus facile, àmha, de ne pas oublier le modèle lang dans les notes et références. Si quelqu'un y voit une objection ? PS : je n'ai pas mis biblio parce que lorsque le modèle adéquat est utilisé, il génère lui-même son propre modèle lang, mais il ne serait peut-être pas inutile de le préciser sous une manière ou une autre quand on ne s'en sert pas (par exemple, pour l'article Maltais actuellement en cours de labellisation) ?--'toff ^[discut.] 6 janvier 2011 à 10:03 (CET)

J’avoue avoir décidé, à titre perso, de ne pas utiliser les modèles mis à disposition pour les réf et de tout taper « à la main » car ces modèles donnent des trucs parfois tellement bizarres...(ex dans cette discussion) Ce serait chouette de parvenir à une uniformisation qui tienne compte aussi de l’accessibilité... --Égoïté (d) 6 janvier 2011 à 10:31 (CET)

J'aime bien ces modèles. Il facilitent la maniabilité (ancres, donc renvois possibles), donc la lecture, l'accessibilité avec le paramètre lang, et surtout la réutilisation. Quand on a un article anglais comme en:Lemur evolutionary history avec des refs en modèles remplis proprement paramètre par paramètre, on est heureux de pouvoir les remplacer en grande partie très facilement (rechercher... remplacer title= par titre=, first1= par nom1=) et cela en dépit de conventions de présentation différentes. C'est avant tout pour cela que je me force à les utiliser systématiquement. Je rebondis aussi sur la remarque de 'toff pour faire remarquer que {{lien web}} présente le défaut de ne pas avoir de paramètre langue. Pour les raisons ci-avant je l'utilise quand-même, mais je suis obligé de rajouter un {{en}} avent le modèle et un {{lang|en|}} autour du titre que je renseigne dans le modèle. Je propose de rajouter un paramètre quoi, pas d'objection ? Totodu74 (devesar…) 6 janvier 2011 à 12:13 (CET)

La question avait été abordée dans la page de discussion du modèle, et je n'étais pas très chaud sur le moment, mais c'est à approfondir. Cordialement, --Lgd (d) 6 janvier 2011 à 13:09 (CET)

La remarque de l'époque de Lgd me semble logique : pour le titre par exemple, certains vont insérer le titre en anglais quand d'autres vont le traduire en français (je le faisais encore il y a peu) mais il y a peut-être quelque chose à améliorer ? --'toff ^[discut.] 6 janvier 2011 à 16:36 (CET)

Une part du problème est que le contenu géré d'un coup par ces modèles est effroyablement complexe, et que cela limite du coup ce qu'on peut en tirer (une vieille règle de la création de template est tout bêtement qu'une usine à gaz est généralement un truc typiquement soviétique de la bonne époque à peu près aussi productif que les consignes du Plan...). Cordialement, --Lgd (d) 6 janvier 2011 à 18:13 (CET)

Le problème ce serait alors les utilisateurs du modèle, il suffirait de les prévenir Totodu74 (devesar…) 6 janvier 2011 à 18:34 (CET)

A ce point, je vais sagement m'en tenir à une stricte « neutralité de point de vue » . --Lgd (d) 6 janvier 2011 à 19:18 (CET)

La vérification des AdQ et l'aide à apporter : c'est une excellente idée, mais ce serait bien de caller ça avec l'atelier de lecture, je crois, plutôt qu'avec l'atelier Accessibilité (si besoin, je veux bien m'y inscrire pour intervenir sur les tableaux, disons, pour prendre un truc que je comprends bien). Cordialement, --Lgd (d) 6 janvier 2011 à 13:06 (CET)

L’Atelier de relecture commence activement à se préoccuper de l’accessibilité grâce à Prosopee qui m’a aussi contactée. Je vais lui faire part de ma proposition pour les alt et répercuter la tienne pour les tableaux. Grand merci Lgd. --Égoïté (d) 7 janvier 2011 à 09:25 (CET)

Retour d'expérience

Comme Lgd m'y invite je viens sur votre page donner mon avis.

Je n'avais que des idées très vagues et plutôt personnelles sur l'accessibilité et en pensant bien faire je ne faisais rien du tout, il suffit de noter mon intention de faire accessible pour les articles que je présentais dans le cadre du WCC avec le résultat en labellisation AdQ, le jour et la nuit. Cette expérience m'amène à faire plusieurs remarques :

1. Comme contributeur lambda, je n'utilise plus par expérience les divers ateliers, les temps de réaction sont de l'ordre du mois, quand il y a réaction, alors que l'on attendrait quelque chose de plus rapide (ce n'est pas une critique c'est un constat, il ne tiendrait qu'à moi de m'investir dans ces ateliers mais WP n'est qu'un passe-temps pas un job à plein temps, en tous les cas pour moi et pour beaucoup d'autres très certainement) donc je ne me suis pas rapproché de votre atelier comme cela était préconisé pour le WCC. Si j'ai bien compris, peu de membre du jury était compétent et encore moins de participants au vu des résultats. Dommage parce qu'il y avait là une distinction facile à obtenir (il n'a fallu qu'une cinquantaine de modifs en une journée pour être conforme pour l'article sur la langue maltaise).
2. L'action d'Égoïté est un peu hard en labellisation. Il n'est jamais facile de vérifier grandeur nature la qualité de son travail, surtout que se retrouve sur ces pages de labellisation les petites mesquineries et les basses manœuvres, alors devoir faire face en plus à des votes négatifs au motif accessibilité est souvent mal vécu (voir les divers réactions). Je suis plus cool sur ce sujet, le WCC n'était qu'un défi personnel et la labellisation un plus pour wp et non une breloque pour moi (quoi que) . Il faudrait faire préalablement un peu de pédagogie, ouvrir une section de discussion sur la page de labellisation, quitte à utiliser un bandeau/modèle pour ne pas perdre de temps, en indiquant que l'accessibilité est un critère de jugement, que l'article n'est pas conforme aux critères, qu'il existe une boîte à outils spécifiques et un atelier et que sous quinze jours/trois semaines si aucune amélioration est constaté il y aura des votes négatifs. Mais commencer par des votes négatifs c'est risquer le clash.
3. Je reconnais bien la sagesse et la prudence de Lgd dans sa dernière intervention en discussion de labellisation de l'article Maltais mais je ne suis pas de son avis ; soit l'accessibilité est un enjeu important, ce que je crois, soit c'est un gadget :
   • si c'est un gadget, il faut tout arrêter tout de suite, les contributeurs lamda n'ont rien à faire des lubies des uns et des autres, nous sommes déjà trop submergés de modèles de toutes sortes qu'il devient quasiment impossible de contribuer sérieusement, le code mediawiki est le plus impraticable que je connaisse, il est plus facile d'éditer un blog que de contribuer à wp. Si j'étais aujourd'hui un nouveau contributeur je crois bien que j'abandonnerais, quand des contributeurs compétents vont s'intéresseront-ils à la simplification de la page de modification ? C'est un problème de praticité comparable à celui de l'accessibilité même si ce n'est pas aussi important.
   • comme ce n'est pas un gadget, je ne comprends pas les réticences de Lgd à ne pas envisager de mettre d'office le cadre accessibilité dans la colonne gauche de nos écrans. Il s'y trouve déjà des choses beaucoup moins importantes comme imprimer/exporter. Je pense que cela aurait plusieurs avantages :
     • comme moi, des contributeurs pourrait être facilement sensibilisés au problème, j'ignorais cette boîte à outils,
     • des outils simples d'emploi, comme cette boîte, permettraient de faire en connaissance de cause des modifs utiles sur les articles auxquels nous contribuons,
     • cela pourrait être une incitation puissante pour les lecteurs sensibles à ce sujet pour commencer à contribuer en faisant œuvre utile.

Voila mon retour d'expérience, ce n'est que mon avis et vous en faites ce que vous voulez.

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 6 janvier 2011 à 17:16 (CET)

Il y aura d'autres avis je pense pour compléter celui-ci, volontairement parcellaire :

1. Le temps de réaction est un problème fréquent dans les ateliers notamment. Cela dit, je n'ai jamais fait d'évaluation mais celui-ci est plutôt très réactif, je crois. D'un autre côté, l'idée me semble être aussi que ces questions puissent relever de multiples autres lieux, au fur et à mesure que quelques bonnes pratiques d'accessibilité choisies entrent dans les usages. En tous cas, il ne doit absolument pas y avoir de passage obligé par ici dans une procédure d'AdQ, mais tout au plus un recours en cas de souci non résolu autrement. L'une des idées maîtresses est que l'accessibilité se dilue finalement dans les usages et dans les besoins de qualité, qu'on réponde aux questions d'accessibilité sur l'atelier de lecture, dans les projets surtout, etc.
2. Quand les bonnes pratiques d'accessibilité concernées ont été adoptées comme un critère d'AdQ cet été, je suis intervenu dans quelques labellisations mais plutôt en signalant la nouveauté, en ayant déjà effectué une grande partie des corrections dans l'article et en offrant un support, surtout pour contribuer à lancer la chose. Sans doute faudrait-il trouver un moyen terme entre cette approche temporaire et une exigence plus franche inévitable s'il s'agit d'un critère qui entre dans les moeurs. En tous cas, je pense que les contributeurs qui souhaitent promouvoir la prise en compte de ce critère ne doivent pas hésiter à mouiller leur chemise en effectuant des corrections même uniquement à titre d'exemple dans l'article (ce qui avait été fait pour les tableaux dans l'article sur le Maltais, si je ne m'abuse et sauf erreur de ma part).
3. Là, j'ai déjà donné des éléments de réponse rapides dans la page de labellisation de l'article. Pour les compléter, je reprends l'exemple que tu choisis avec les liens imprimer/exporter : ceux-ci correspondent à une fonctionnalité d'usage universel, pour tous les lecteurs de Wikipédia. La petite boîte du gadget de test reste, quelle que soit son importance, un outil d'usage très spécifique, sans utilité pour le lecteur chez qui il dénature le contenu. WP est d'abord un contenu à lire, avant d'être un contenu que nous écrivons : son interface obéit à la même logique. Cela dit, pour intéresser des lecteurs à cette sorte d'améliorations, il y a en effet des choses à faire, mais d'autres choses ayant trait à la communication sur les efforts en matière d'accessibilité. C'est un long chemin... Cordialement, --Lgd (d) 6 janvier 2011 à 17:49 (CET)

ah, une bricole formelle mais assez amusante : le terme « gadget » en usage est effroyable. C'est un bon exemple des tentatives à éviter pour trouver un équivalent vaguement francophone ou compatible de loin avec les souci de francisation, d'un vocable technique précis. Les « gadgets » sont en réalité le plus souvent des « widgets», c'est à dire des petits morceaux d'interface ajoutés aux pages ou au site et qui relèvent de modes d'interaction originaux dans celui-ci et qui reposent sur le recours à des techniques spécifiques (par exemple, le cas le plus connu du grand public est le widget associé à un champ de saisie de date dans un formulaire, qui affiche un joli calendrier sur lequel on clique pour que hop! la bonne date soit dans le formulaire). Le gadget n'est donc en aucun cas, même métaphoriquement, « un gadget ». En revanche, l'image du bout d'interface spécifique et à usage spécifique est tout à fait pertinente . Cordialement, --Lgd (d) 6 janvier 2011 à 17:58 (CET)

En colonne de gauche, j'ai un menu « Accessibilité » avec un carré bleu à côté. Quand je passe la souris sur le carré bleu, j'ai un pop-up avec le texte « Fixer le gadget ». Serait-il possible de changer ce texte ? Peut-être : « Fixer la boîte à outils Accessilibité » ? Et il faudrait remplacer le mot « gadget » dans le titre et dans la page Wikipédia:Atelier accessibilité/Aide gadget, pour bien expliquer que ce n'est pas un gadget. TED 6 janvier 2011 à 18:37 (CET)

Bien vu . C'est noté pour la prochaine version pour le carré bleu (« Boîte à outils » est assez bien, mais cela reste à... fixer). En revanche, on ne changera pas les titres de pages, on ne va pas refaire le monde à coup de maquillage. Cordialement, --Lgd (d) 6 janvier 2011 à 19:21 (CET)

Pourquoi ne pas renommer en Wikipédia:Atelier accessibilité/Aide boîte à outils ? TED 6 janvier 2011 à 19:45 (CET)

Parce que, ergonomiquement, c'est une page d'aide qui concerne fonctionnellement un « gadget », que l'on estime ou non que son nom est pertinent.

Ce débat (que j'ai lancé, j'aurais mieux fait de me taire ) est en fait une question à soulever ailleurs que sur fr.wp : c'est l'extension gadget qui est concernée. Le jour où cela s'appelle autrement ou bien le jour où il aura plus de souplesse du côté de ce nommage, on pourra aviser... Mais bon, c'était juste une remarque en tout petit, sur un truc de détail amusant, je ne voulais surtout inciter personne à refaire le monde, moi, hein... Cordialement, --Lgd (d) 6 janvier 2011 à 19:58 (CET)

À Hamelin : d’accord avec toi dans l’ensemble mais je comprends aussi les réponses de Lgd et je confirme que l’atelier d’accessibilité est beaucoup plus réactif que les autres que j’ai eu l’occasion de consulter. Je te réponds ici pour rapport au « hard » et parce que tu n’as évidemment aucune raison de connaitre l’ensemble des pages où je suis intervenue récemment. Mais cela te permettra peut-être d’apprécier différemment mes interventions.
J’ai voté « attendre » avec le commentaire « critère 5 » uniquement pour les articles qui avaient été proposé au WCC et qui étaient en phase de vote, estimant que l’attention des concurrents avait été largement attirée sur l’accessibilité par la PdD du WCC. Résultats à cette heure :

• David Ier d'Écosse : rien n'a bougé depuis la fin décembre (soit bien avant mon intervention)
• Musée national du Bardo (Tunisie) : belle évolution ; pour améliorer encore, je viens de faire appel au portail architecture
• Maltais : fortement amélioré et j'ai relu
• Alphabet maltais : l'équipe annonce s'y mettre sur la page de vote
• Incube : Prosopee a fait le boulot des alt, et j'ai tout revu et largement amélioré, àmha, parce qu'il était fortement demandeur. N.B. avec le problème de lenteur de téléchargement ce jour-là, ça m'a pris une demi-journée...

J’ai aussi modifié mes votes en fonction des réactions ; mon intervention n’a donc pas nui aux articles. Pour les autres articles, j’ai placé une remarque dans la discussion, ce qui a eu pour résultats :

• Histoire évolutive des lémuriformes : impec !
• Ligne 3 du tramway d'Île-de-France : fait, je vais relire
• Hippogriffe : en attente mais Tsaag fait très bien ça, ce n'est qu'une question de temps
• Djerba : travail commencé, qui va se poursuivre
• Drapé (légende) : Tsaag a réagi et j'ai relu
• Ax 3 Domaines : en attente, mais l'article pose d'autres problèmes et va sans doute fort évoluer (ou rester en BA)
• Paul Bourget : les alt ont été placés ; j'ai relu une partie et espère trouver le temps de terminer. Et il y a un nouveau convaincu de leur utilité.
• Cheval au Moyen Âge : je me suis engagée à placer les alt car ma remarque est arrivée trop près de la date de clôture des votes.

Dans l’ensemble donc, me semble-t-il, le fait d’être intervenue a fait évoluer les choses. Cela met aussi en évidence que ce critère 5 est peu ou mal connu, ou négligé peut-être parce que les votants, à part Ascaron (merci à lui) n’y font pas allusion. Cela a débouché aussi sur une proposition de travail avec l’atelier de relecture et avec Prosopee, ce qui me semble totalement productif. Amclt, --Égoïté (d) 7 janvier 2011 à 10:23 (CET)

Je reprends la numérotation

1. Je remarque effectivement que l'activité et la réactivité de cet atelier change de beaucoup d'autre, tant sérieusement par ses traitements de problèmes techniques, tant ... bistrotière, dirais-je, pour l'amusement de ses participants
2. Merci Égoïté pour tes explications plus complètes que de besoin. Je comprends la finalité de l'action et j'y adhère, mais je ne pense pas que la méthode soit la bonne :
   • Que tu interviennes sur une page ou plusieurs, que ce soit des articles issus du wcc ou pas, c'est le vote attendre qui est « hard ». La procédure de labellisation n'est déjà pas quelque chose d'agréable en soi, se soumettre à la critique n'est pas toujours facile surtout quand des contributeurs viennent déposer un avis pas toujours argumenté et ne repasse jamais sur la page pour constater l'évolution, Je reconnais tout de suite que ce n'est pas ton cas puisque tu fais évoluer ton vote en plus d'aider à l'évolution, ce en quoi je te remercie à titre personnel. Mais l'apparition d'un vote négatif est toujours, en fait c'est ce que je pense cela mériterait un refnec, est toujours donc ressenti comme une sanction assimilable à du « dressage » (mot fort mais non déplacé). Hors pour faire prendre conscience aux contributeurs de l'intérêt de l'accessibilité il faut une méthode plus douce d'apprentissage.
   • C'est pourquoi j'avais pensé que tu devrais remplacer ton vote attendre par l'ouverture d'une section discussion expliquant la problématique et j'envisageais, pour gagner du temps, un modèle/bandeau. Il sera toujours temps ensuite de voter pour ou contre en fonction des efforts d'accessibilité fournis. Cela me paraitrais moins « hard », plus pédagogique et donc plus efficace. Les contributeurs comprenant mieux ainsi dans quel cadre tu agis.
3. Rien de plus à dire, je comprend les arguments de Lgd mais nous ne voyons pas les choses de la même façon. Tout ce qui peut faire avancer la cause de l'accessibilité me parait bonne à prendre mais peut-être ai-je la foi du nouveau converti
4. j'avais utilisé le terme gadget dans deux acceptions :
   • d'abord les préférences utilisent le terme gadget pour qualifier la boîte accessibilité de la colonne de gauche. Peut être qu'en l'occurrence la traduction de widget par boîte à outils serait préférable à gadget,
   • ensuite je l'utilisait bien dans le sens courant de chose-utile-totalement-inutile pour regretter justement que cette boîte à outils ne soit concidérer que comme un gadget-utile-totalement inutile.

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 8 janvier 2011 à 16:50 (CET)

Palette à vérifier : mieux ou usine à gaz ridicule ?

Suite à la remarque de Salix sur le projet herpéto, j'ai essayé de retoucher la {{Palette Les familles de Reptilia}}. Avec le gadget c'est à peu près vert, mais est-ce vraiment bon signe ? (Je me dis qu'une solution accessible aurait déjà remplacé le modèle méta palette le cas échéant ?) Totodu74 (devesar…) 7 janvier 2011 à 14:41 (CET)

Ah... Les palettes, je crois bien que la prochaine version du gadget va les ignorer, à vrai dire. Le problème est très difficile à résoudre complètement, c'est un autre chantier que j'ai lancé mais qui est un peu en panne ces temps-ci.

Dans l'immédiat : ce n'est pas à conserver, mais ce n'est pas ridicule du tout. Bravo pour t'être lancé dans les ID HEADERS. L'un des soucis est que, dans ce cas, l'usage que tu en fais est simplement redondant avec les SCOPE qui eux sont très bienvenus (cela dit, ça ne fait pas de mal, juste un code plus lourd). D'autre part, si on voulais utiliser les ID HEADERS uniquement, il faudrait que les cellules de contenu reprennent dans leur headers les ID de chaque cellule d'en-tête concernée : la première cellule qui a deux en-têtes de ligne doit avoir un code du type headers="Squamata Sauria".

Ce qui coince avec ce genre de corrections sur les palettes, c'est :

• qu'ici, elle est faite sur le modèle spécifique : c'est le méta-modèle qu'il va falloir traiter
• que le méta-modèle comporte des cas de figures impossibles à corriger et qu'il faut donc revoir entièrement celui-ci

Sinon, c'est un bon exemple du souci avec ID HEADERS  : c'est une technique en fait beaucoup plus puissante que SCOPE, qui permet de traiter des cas que SCOPE ne gère pas (ce n'est pas le cas ici, mais ce serait couramment le cas dans les infobox par exemple). Mais... C'est une technique imbittable, trop complexe pour être utilisée dans des modèles qui ne sont fixés une bonne fois pour toute par des développeurs avertis.

Bref, il vaut mieux revenir à la palette par défaut. Cordialement, --Lgd (d) 7 janvier 2011 à 20:45 (CET)

Hum j'avais peur que les SCOPE row ne suffisent pas pour toutes les cases, surtout avec les rowspan qui dédoublaient les cases. J'aurais du me douter que c'était superflu, bref je suis revenu à la version initiale. Avec l'arrivée printemps, peut-être reverdira-t-elle ? Je m'étonne quand même : un simple SCOPE ne peut pas régler la question, un en-tête de groupe s'appliquant toujours à tout le sous-groupe (ex Squamata s'applique aux Sauria, Amphisbaenia, Ophidia et leurs contenus) ? Totodu74 (devesar…) 7 janvier 2011 à 21:02 (CET)

Oui, un SCOPE placé sur le groupe s'applique aux sous-groupes, c'est ce qui est magique et qui fait la simplicité de SCOPE. En fait, SCOPE ROW signifie « ceci est un en-tête à distribuer sur toutes les cellules de la ligne ou des sous-lignes ». Et en cas d'en-têtes multiples, les SCOPE se cumulent.

Mais c'est aussi ce qui fait sa limite si le tableau comporte dans la ligne (ou dans la colonne le cas échéant) une ou des cellules qui ne relèvent pas de cet en-tête global (le cas du tableau de hockey la petite énigme plus haut, les infobox). ID HEADERS, à l'inverse, permet de relier une à une chaque cellule à des en-têtes précis, sans risque de ce genre.

Bienvenu dans l'un des principaux soucis de la gestion de l'accessibilité : les tableaux complexes. Cordialement, --Lgd (d) 7 janvier 2011 à 21:28 (CET)

Hihi j'ai un nouveau cas : Deux en-têtes pour une même colonne. Un bon cas pour les ID HEADERS ? en tout cas avec un SCOPE le tableau vire au rouge. Totodu74 (devesar…) 10 janvier 2011 à 18:13 (CET)

Hum... On est plus dans le tableau de mise en forme que dans le tableau de données, mais sinon, les scope col conviennent pour les en-têtes comme « Divisions embryologiques » et « Divisions anatomiques » qui se partagent une colonne commune. Cordialement, --Lgd (d) 11 janvier 2011 à 06:54 (CET)

Pour info

Attention : Je suis censé être, selon un contributeur dont pour le moment je ne vais pas donner le pseudo, une sorte d'agent sournois du grand capital qui instrumentalise les contributeurs s'intéressant de bonne foi à l'accessibilité et s'y investissant, c'est à dire vous tous. Le tout pour favoriser dans des sphères et des domaines d'intérêt obscurs des solutions commerciales qui, apparemment, me rémunèrent en sous-main.

Bref, faites gaffe : vous êtes manipulés.

La vérité est ailleurs, cordialement, --Lgd (d) 7 janvier 2011 à 22:46 (CET)

J'aurais dû m'en douter ! Je m'en vais sagater quelques ôdes aux sociétés que tu représente, supprimer le modèle {{lang}} et définir les styles par défaut blanc cassé sur gris perle. En fait tu pourrais aussi accepter de partager tes royalties. La nuit porte conseil, rendez vous demain matin sur le champ de bataille. Totodu74 (devesar…) 7 janvier 2011 à 22:53 (CET)

Je n'accepterai aucune négociation au-dessus de 5%, j'ai de gros frais. --Lgd (d) 7 janvier 2011 à 23:02 (CET)

Cela veut dire que tu remets en cause notre accord secret précédent et mes 10 % ? Ou bien cela tient toujours ? TED 7 janvier 2011 à 23:14 (CET)

Si vous entamez tous un round de renégociation, on va repartir sur la base des frais réels et non plus du forfait. Nous autres lobbyistes sommes avant tout des petites entreprises familiales, faut pas déconner. --Lgd (d) 7 janvier 2011 à 23:18 (CET)

J'ai toujours su que Lgd ça voulait dire « Le grand dis-leurs » . --Amicalement, Salix ( converser) 7 janvier 2011 à 23:22 (CET)

<fébrile /> Heu, j'ai des goodies très sympa aussi. Des Mugs 30Go et des clés USB avec logo incrusté ? --Lgd (d) 7 janvier 2011 à 23:34 (CET)

Un porte-clé Jimbo Wales qui dit « maman » ?

Un porte-clefs qui rend les tableaux accessibles sur WP ? TED 8 janvier 2011 à 00:19 (CET)

Il est clair qu’une cabale se forme ici, type Lgda (Le grand discours accessible) Je veux en être ! Pour les frais réels, quel est le salaire horaire ? Comme les alt, ça prend du temps... --Égoïté (d) 8 janvier 2011 à 07:51 (CET)

Heureusement pour toi, mon amour propre ne vaut pas cher. Va pour 5 % et les clés du bar, mais tout juste pour mon silence. Il va falloir revoir tes frais de bouche à la baisse pour obtenir ma complicité. Totodu74 (devesar…) 8 janvier 2011 à 15:48 (CET)

Au secours

J'avais posé le problème à Ascaron qui m'aidait pour les tableaux mais qui ne comprend pas non plus et me renvoie vers vous.

Pour l'article Alphabet maltais pour les deux tableaux de cette section j'ai atteint mon niveau de Peters. Dans un cas on me demande un caption qui n'apparait pas en gras et dans le deuxième tableau il ne faudrait pas de caption ? ? ?

Pour le tableau de cette section, j'ai ramé comme un malade en le pompant des autres articles de linguistique et là je n'ose plus toucher à rien, trop complexe pour moi.

Merci pour votre aide. Cordialement. — Le message qui précède, non signé, a été déposé par Hamelin de Guettelet (discuter)

Le deuxième tableau était considéré comme un tableau de mise en page par le gadget car il ne comportait pas d'entêtes de colonne ou de ligne (! en syntaxe wiki). Je me suis chargée de la transformation, maintenant j'ai un peu les yeux qui se croisent et ne sait pas trop quoi faire pour la légende et si la gestion des titres intermédiaire est correcte (a priori non). --Anneyh (d) 8 janvier 2011 à 23:22 (CET)

Bon, à ce que je (crois) commence(r) à comprendre, et si j'ai bien compris le tableau, il n'est pas correct du point de vue de l'accessibilité. Je parle sous couvert des maitres ès accessibilité : le Ā, codé 0100 sera compris comme table des caractères - latin de base ET table des caractères - supplément latin-1 ET table des caractères - latin étendu A (sans compter le 0 du code de la colonne et le code de la ligne) puisque les scope col et row s'ajoutent. A mon avis, à moins de vouloir laisser le tableau en l'état et insérer des id/headers, il serait peut-être plus judicieux de le séparer en 3 : le titre du premier en serait « table des caractères - latin de base » et il ne subsisterait que les code en scope col et row ? (Mais je dis peut-être des bêtises, mieux vaut attendre l'avis des experts). --'toff ^[discut.] 9 janvier 2011 à 00:33 (CET)

Je ne comprends pas quel est l'objet du paragraphe de Supertoff au sujet de « Ā, codé 0100 ».

Par la seconde partie qui concerne le tableau, je confirme que tu as bien compris, 'toff. Il faudrait séparer le tableau en 3 parties, tu sais bien comment faire.

Mais il y a autre chose : les couleurs, selon Wikipédia:Articles de qualité/Accessibilité#Couleurs et contrastes. Utiliser des couleurs pour ajouter une information dans le tableau (alphabet classique, étendu, etc.) est utile, mais insuffisante si c'est le seul moyen d'avoir cette information. Une personne aveugle ne pourra en effet pas avoir cette information. Il faut donc dupliquer l'information, par exemple par une note en bas de page. Bien à vous, Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 04:06 (CET)

Je parlais du caractère Ā dans la troisième partie du tableau, au croisement de la colonne 0 et de la ligne 010. --'toff ^[discut.] 9 janvier 2011 à 04:20 (CET)

Ah, c'est le code et la formulation qui m'ont perturbés. Alors oui tu as bien compris, mais la formulation est à clarifier. Le « Ā », dans la troisième partie du tableau, est intrinsèquement indiqué comme faisant partie de la « table des caractères - latin de base ET table des caractères - supplément latin-1 ET table des caractères - latin étendu A ». En gros, le « Ā » est associé à tous les titres de colonnes qui précèdent. « Ā » est juste un exemple, c'est pareil pour les autres lettres. Raison pour laquelle il faudrait séparer le tableau en 3 parties. Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 04:33 (CET)

Deux suggestions mises en œuvre dans ma page brouillon Utilisateur:Anneyh/Brouillon#Tableau_unicode:

• Pour les titres intermédiaires, ne pourrait-on pas les transformer en entêtes de ligne ?
• Le tableau étant assez compliqué fournir une version textuelle en summary ? --Anneyh (d) 9 janvier 2011 à 10:21 (CET)

• Non, car ce ne sont pas des en-têtes de ligne. Le même problème se pose avec les infobox. Et pour les infobox, la solution qui limite les dégâts mais qui est imparfaite est de faire un simple titre de tableau (sans scope=col ni scope=row donc). La meilleure solution est de scinder le tableau en 3.
• Et sais-tu précisément ce que tu vas écrire dans ce "summary" ? Si oui, est-ce que les contributeurs suivants le sauront lorsqu'ils mettront à jour ce tableau ? Ajouter un summary pour compenser la complexité du tableau, c'est faire un énorme bricolage fragile pour colmater un problème, plutôt que de le résoudre à la source. Là aussi, séparer le tableau en 3 permet de simplifier suffisamment le tableau pour ne plus avoir besoin de summary.

Pour ta version brouillon, l'idée de faire la séparation par des titres de ligne est bonne. J'ai fait une correction d'accessibilité, maintenant ce tableau est suffisamment accessible. Si tu mets un titre de ligne, il faut impérativement qu'il précède les cellules auxquelles il se rapporte. Comme on ne met pas un titre à la fin d'un paragraphe, mais au début.

Reste à corriger la question des couleurs évoquée ci-dessus. Bien à toi, Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 12:23 (CET)

Vite vu, pour compléter :

• la version avec en-têtes de ligne à droite n'était pas dramatique : ce sera moins bien supporté selon les versions anciennes de lecteurs d'écran, mais rien n'empêche un en-tête de ligne d'être en fin de ligne, voire en plein milieu comme dans les pyramides des âges. Mais bon, c'est bien aussi avec ces en-têtes en début de ligne.
• summary : oubliez summary, ne l'utilisez pas (dans cet exemple, il est mal utilisé)
• Surtout : scinder ce tableau en plusieurs tableaux simples, ce serait tout de même beaucoup mieux pour tous les lecteurs, qu'ils soient d'écran ou pas

Cordialement, --Lgd (d) 9 janvier 2011 à 13:43 (CET)

En même temps, on lit de grauche à droite en français, et les titres de tableaux se mettent à gauche. L'ergonomie n'est pas le sujet de cet atelier, mais quand même. Mettre les titres de tableaux à droite, c'est ajouter une complexité inutile, et vraiment à éviter. Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 14:07 (CET)

Ce ne sont pas des titres mais des en-têtes de ligne. Oui, l'idée de les mettre dans le sens de lecture se tient tout à fait. Simplement, les mettre à droite signifie qu'on en fait une information complémentaire, de second niveau (ergonomiquement), ce qui se défend aussi. Mais dans tous les cas, ce n'est pas l'important : cela reste un tableau complexe moins pertinent pour l'utilisateur que plusieurs tableaux simples (en fait, ces grilles de caractère Unicode obéissent à un modèle historique de WP totalement arbitraire. Sans compter que c'est aussi un type de contenu primaire dont la reproduction dans WP n'a pas un grand intérêt, les sources étant préférables, mais c'est une autre très longue histoire...). Cordialement, --Lgd (d) 9 janvier 2011 à 14:13 (CET)

Euh ! Je ne comprends pas le premier mot de toute votre discussion sinon qu'il faudrait partager le tableau en trois, ok pourquoi pas, mais ... depuis la modif de Anneyh le test tableau de la boîte à outils accessibilité donne du vert partout pour ce tableau et ne signale pas d'anomalie, alors ? ? ?

Pour vous qui êtes des spécialistes, je pense que le codage est quelque chose de banal mais pour un utilisateur qui frappe sur son clavier sans savoir ce qui se passe après cela a été une découverte et je ne doit pas être le seul d'où l'utilité de cette info. De plus en cherchant des infos sur le sujet j'ai cru comprendre de la codification des lettres spécifiques de l'alphabet maltais n'a pas été aussi évidente que cela jusqu'en 1972. Le repompage des tableaux unicode est complété par l'indication des codes de l'alphabet anglo-maltais, ce n'est donc pas uniquement équivalent aux tableaux primaires en ligne ou sur les articles wp. Par contre je suis d'accord avec vous pour convenir que les indications couleurs ne sont pas très accessibles mais comment faire autrement ?

Merci de votre aide. Je ne pensais pas faire couler autant d'encre pour mettre un tableau en conformité. wp est vraiment d'une simplicité déconcertante

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 9 janvier 2011 à 15:40 (CET)

Les tests automatisés d'assistance au contributeur sont déjà un énorme progrès par rapport à leur absence, mais il faut tout de même ne pas leur demander plus qu'ils ne peuvent faire  : une nouvelle fois, je répète que ce n'est qu'un outil d'assistance qui laisse juge son utilisateur et qui ne valide rien (et aucun outil de test ne pourrait faire autrement). Donc, dans des cas de tableaux qui ne sont pas courants, le gadget peut très bien dire « c'est tout vert » sans que le tableau ne soit correct.

Ce n'est pas "Wikipédia" qui est en défaut : c'est aussi une certaine exigence de vouloir à la fois un très haut niveau de qualité et des contraintes ou des moyens à la portée du premier venu, le tout en imposant une transparence totale des questions de code pour le contributeur : c'est impossible.

Il est tout à fait normal qu'une discussion ici :

• comporte à l'occasion des échanges un peu complexes
• tout en aboutissant à donner une solution simplement expliquée ou à ce que quelqu'un d'averti fasse le nécessaire.

Plus concrètement, maintenant, donc :

1. scindre le tableau en 3
2. laisser tomber les problèmes de couleurs, c'est mort en l'état des moyens disponibles. Les BP sur la couleur ne sont pas dans le critère d'accessibilité des AdQ et ce n'est pas par hasard. Ce serait bien que tout le monde accepte enfin de tenir compte de cette sélection de BP pour les AdQ, qui n'a pas été faite pour rien (désolé de devoir faire une mise au point un peu radicale, visant en particulier Egoïté et Dodoïste).

Cordialement, --Lgd (d) 9 janvier 2011 à 16:07 (CET)

Bon, j'ai essayé de scinder le tableau et de rajouter des notes, mais franchement, et je préférais la version d'avant. J'en viens à penser à une solution radicale... une image au format svg avec un bon vieux alt des famille ?

• Version table à gauche,
• Version table à droite,
• Version en trois tableaux (oui, les tableaux n'ont pas la même largeur, mais j'ai craqué !).

Si queqlu'un arrive à tirer quelque chose de la dernière version, je ferai l'effort de remttre les <big> que j'ai supprimé. --Anneyh (d) 9 janvier 2011 à 16:19 (CET)

@Lgd, tu m'excuseras si je t'agace, mais un béotien comme moi est bien obligé de se raccrocher à ce qu'il peut et entre autre à la boîte à outils accessibilité là se situe mon niveau de Peters sur ce sujet:

1. Je vais scinder en trois tableaux, sans comprendre pourquoi mais bon ... c'est vrai que les tableaux sont bien les choses les plus simples de wp
2. Et si j'utilise la technique Anneyh de la note cela devrait permettre aussi l'accès équivalent à l'info couleur, non ?

@Anneyh, les big ne sont pas utiles même si c'est plus lisible, ils font double emploi avec la couleur par contre n'est-il pas possible de fixer la largeur des colonnes ou des tableaux en % ?

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 9 janvier 2011 à 17:02 (CET)

Euh, Lgd ? Si tu estimes que la question des couleurs n'a rien à faire dans les critères pour AdQ, je veux bien. C'est effectivement trop complexe. Mais pour l'instant, elles y sont, raison pour laquelle j'en ai parlé. Wikipédia:Articles de qualité/Accessibilité#Couleurs et contrastes. Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 18:53 (CET)

Mouarf, my fault : c'est la BP sur l'information véhiculée par la couleur je voyais exclue, pour ne retenir que celle sur les contrastes. Cordialement, --Lgd (d) 9 janvier 2011 à 19:52 (CET)

Ah, je pensais pas qu'il s'agissait de so focaliser sur les contrastes. OK. Ceci dit, je ne crois pas que la solution de dupliquer la légende colorée par les notes est très complexe à réaliser pour un Wikipédien. Le tableau sur Alphabet maltais est maintenant scindé, et en plus a ce système de notes. Par contre, c'est une pratique nouvelle, qui n'est pas encore en train d'entrer dans les usages des contributeurs. C'est peut-être pour cela que tu ne veux pas en faire mention ? Bien à toi, Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 20:14 (CET)

Je viens de mettre en 3 tableaux et ai trouvé un moyen d'avoir une même largeur (je suis peut être moins con que je le pensais ;-) Merci à tous, j'espère que cette fois-ci c'est tout bon pour ce tableau. Je pense que l'ajout des notes doit résoudre le problème de l'info couleur. J'ai remis les big pour que les diacritiques soit discernables et lisibles.

Il reste encore le tableau de cette section, j'ai ramé comme un malade en le pompant des autres articles de linguistique et là je n'ose plus toucher à rien, trop complexe pour moi.

Je fini les alt et cet article devrait est OK pour Égoïté et les autres.

Cordialement -- • Hamelin ^{[ de Guettelet ]} • 9 janvier 2011 à 20:03 (CET)

Bravo, le tableau est maintenant correct en effet. :-) Dodoïste ^{[ dring-dring ]} 9 janvier 2011 à 20:14 (CET)

Images et infobox

Bonjour,

Suite à cette discussion, je me pose une question sur l'accessibilité des images dans l'infobox. Le projet:hockey a décidé de régler le problème en encapsulant l'image dans un thumb, ce qui de l'avis de certains (et du mien ) n'est pas top niveau esthétique (exemple). Du coup, j'ai tenté une autre approche avec l'{{infobox rugbyman}} (voir l'exemple de Pelous sur la page de doc). Pourriez-vous me dire si cela est satisfaisant du point accessibilité ? Udufruduhu (d) 12 janvier 2011 à 09:29 (CET)

L'exemple de Pelous dans la doc du modèle répond en effet aux problèmes d'alternative textuelle. Le recours au thumb est aussi une possibilité (mais avec des inconvénients graphiques en effet). Mais le problème des images dans les infobox ne se limite pas à cette question : il y a en particulier un problème tout aussi grave de structure du tableau composite à la base des infobox V2 actuelles (pour être bref, c'est un mélange de tableau de mise en forme et de tableau de données, ce qui est à proscrire).

Résoudre ces problèmes (et quelques autres que posent encore les infobox) nécessite de revoir entièrement la conception de celle-ci (sans modification majeures de leur rendu s'il s'agit de conserver celui-ci). Mais c'est un chantier énorme, qui a d'autre part été différé le temps que le sujet « infobox » se dépassionne enfin après les multiples controverses de ces dernières années. On approche du moment où quelque-chose devrait commencer à être possible. Bref, ces différents essais de corrections sont très utiles pour évaluer ce qu'il faudra faire finalement, mais il ne faut surtout pas qu'ils deviennent un sujet de polémique ou de désaccords frontaux.

Dans l'immédiat, il est probable que la prochaine version du gadget exclue totalement les infobox (et certains autres modèles) de la détection (en signalant visuellement que ces blocs ne sont traités). Cordialement, --Lgd (d) 12 janvier 2011 à 09:49 (CET)

Merci pour la réponse. Encore un (gros) truc à mettre sur ta todolist . Udufruduhu (d) 12 janvier 2011 à 10:24 (CET)

Présence fossile

Ici nous avons : {{Présence fossile}}, nos petits camarades de wp:en ont en:Template:Geological range qu'ils incluent dans l'infobox des articles. Une discussion est en cours sur le projet Biologie sur le placement optimal (article ou infobox). Si en plus on veut rendre la chose accessible, quels sont les bons conseils du doc ? --Anneyh (d) 12 janvier 2011 à 14:02 (CET)

Je me cites froidement de ce matin chez Utilisateur:Totodu74 à propos des modèles actuels de en.wp et de fr.wp  :

Parmi les points-clés :

• revoir autant que possible les choix de couleurs qui sont vraiment bloquants côté contrastes (dans les deux cas)
• conserver la mention textuelle de l'information avant le modèle, comme dans le cas de en.wp (elle joue le rôle d'alternative quand la partie graphique n'est pas perceptible comme prévu)
• bidouiller l'échelle graphique des ères de manière à ce qu'elle ait du sens indépendamment de la mise en forme (le modèle fr.wp n'est pas bon du tout ce ce point de vue)
• conserver un affichage correct en cas d'agrandissement de la taille de caractères (fr.wp bat en.wp à plate couture, là)

Cordialement, --Lgd (d) 12 janvier 2011 à 14:09 (CET)

Si c'est urgent, je partirai plutôt du modèle de en.wp, compte-tenu des défauts, des bons points réciproques et de la facilité de correction. En l'adaptant s'il s'agit de faire « plus grand » pour ce que ce soit éventuellement plus adapté à un affichage hors infobox. Le modèle de fr.wp comporte des contraintes a priori qui seront bcp plus difficiles à corriger en gardant le même contenu. Cordialement, --Lgd (d) 12 janvier 2011 à 17:17 (CET)

Merci pour les conseils. Accessoirement, dans un domaine proche, il y a un an j'avais créé : {{Graphique/Extinctions des espèces marines}}... euh, c'est pas trop grave docteur ? — Le message qui précède, non signé, a été déposé par Anneyh (discuter)

A priori, tu es maudite pour l'éternité, mais tu auras une réponse plus circonstanciée demain. Cordialement, — Le message qui précède, non signé, a été déposé par Lgd (discuter)

Maudite.... alors, pour essayer de me racheter, je viens d'adapter le modèle (ou plutôt les poupées russes) de wp:en pour que la largeur soit variable (en test sur Brouillon de l'utilisatrice Anneyh). Les couleurs viennent apparemment d'une convention dans le domaine... --Anneyh (d) 12 janvier 2011 à 22:59 (CET)

Gadget

Titre accrocheur ici non ? Eh bien non, je ne viens pas parler de celui de l'accessibilité mais d'un autre dans les préférences de wikipédia. J'utilise depuis bien longtemps le gagdet qui rajoute 7 boutons dans la barre d'outils et qui permet, entre autre et pour ce qui est de l'accessibilité, de créer des citations françaises et étrangères quasiment en 1 seul clic. A moins que je l'ai loupé quelque part, il n'existe pas la même chose pour le modèle lang ? Ne serait-il pas possible de l'intégrer à cet outil avec la langue anglaise par défaut (comme citation étrangère) ? Ça faciliterait la tâche des contributeurs accessibilisateurs motivés non ? --'toff ^[discut.] 15 janvier 2011 à 04:21 (CET)

Bonne idée, mais avec une option pour une langue de son choix par défaut si c'est possible ? (parce que selon les domaines, ce n'est pas toujours l'anglais qu'on utilise le plus souvent) TED 15 janvier 2011 à 04:36 (CET)

Cela peut se faire aisément au moins pour monobook (il me semble, mais je n'ai pas suivi cela depuis longtemps, que c'est moins évident sous vector). Le mieux serait de faire la demande au Projet:Javascript. Cordialement, --Lgd (d) 15 janvier 2011 à 07:42 (CET)

--'toff ^[discut.] 15 janvier 2011 à 08:37 (CET)

Et comment s'appelle-t-il ce nouveau gadget ? --Amicalement, Salix ( converser) 15 janvier 2011 à 20:08 (CET)

Je voulais dire que j'avais fait la demande au Projet:Javascript --'toff ^[discut.] 15 janvier 2011 à 21:13 (CET)

Rââââââââââââââââââââââââ (cri de joie intense) J'ai trouvé ! En fait, le gadget en question est personnalisable via notre monobook ! C'est pas super bien expliqué, j'ai beaucoup ramé, mais ça fonctionne ! 'tain c'est bon ! Pour ceux que ça intéresse, j'ai maintenant un bouton et quand je sélectionne une phrase et que je clique dessus, il l'encadre avec le modèle lang (anglaise). Je vais gagner du temps ! --'toff ^[discut.] 15 janvier 2011 à 22:15 (CET)

Bravo mais si ce n'est que ça, il y a longtemps que j'ai (grâce à Totodu74, merci à lui) un bouton lang/la(tin) via mon monobook, que j'en ai bricolé ensuite pour avoir lang/en. Y avait qu'à demander ! Mais comment s'appelle ton gadget ? --Amicalement, Salix ( converser) 15 janvier 2011 à 22:40 (CET)

Le gadget est dans préférences, gadgets : Boutons de la barre d'outils Ajouter sept boutons facilitant l'ajout et la demande de sources lors de l'édition d'un article. --'toff ^[discut.] 15 janvier 2011 à 22:51 (CET)

Bon, par contre je sais pas sous vector si ça fonctionne pareilça fonctionne aussi sous vector (je viens de tester). En tout cas, pour ceux que ça intéresse et qui veulent tester sous monobook ou sous vector, ça donne ça chez moi :

function addCustomButton(imageFile, speedTip, tagOpen, tagClose, sampleText, imageId) {
 mwCustomEditButtons[mwCustomEditButtons.length] =
  {"imageId": imageId,
  "imageFile": imageFile,
  "speedTip": speedTip,
  "tagOpen": tagOpen,
  "tagClose": tagClose,
  "sampleText": sampleText};
}
addCustomButton('http://upload.wikimedia.org/wikipedia/commons/6/63/Button_l_en.png',
 'Lang',
 '{{lang|en|',
 '}}',
 'Modèle lang',
 'mw-editbutton-redirect');

C'est évidemment personnalisable pour la langue en changeant la ligne '{{lang|en|', par la langue souhaitée et pour changer l'apparence du bouton, c'est par là que ça se passe. --'toff ^[discut.] 15 janvier 2011 à 22:49 (CET)

En passant : Ça fonctionne sous Vector, mais pas avec la barre d'outils d'édition de Vector. C'est probablement ce que voulais dire Lgd. Dodoïste ^{[ dring-dring ]} 16 janvier 2011 à 00:32 (CET)

Accessibilité des {{Encadré}}

j'ai utilisé par deux fois le modèle {{encadré}} (voir pour le premier exemple ici) et le gadget me signale qu'il faut ajouter "titre caption". Que faire? Prosopee (d) 16 janvier 2011 à 09:40 (CET)

Bonjour,
C'est une vieille question (que j'aurais peut-être dû traiter quand ce modèle était encore confidentiel et surtout qu'on ne s'était pas mis à l'utiliser dans les AdQ et autres, mais bref).

Ce modèle est, en l'état, à éviter totalement dans les articles :

• du point de vue sémantique, il produit un code HTML impropre quand il est utilisé pour une citation (absence d'élément blockquote contrairement aux modèles de citations)
• du coup, du point de vue accessibilité, il pose un souci lourd.
• éditorialement (c'est l'essentiel), il consiste à mettre au mieux un texte en illustration du contenu de la section : mais dans ce cas, il devrait s'agir d'une citation contextualisée, c'est à dire faite au fil du texte avec les modèles de citation. Quand on tente de remplacer les utilisations de {{Encadré}} par {{Citation bloc}} par exemple, on s'aperçoit immédiatement que la plupart des textes mis en encadré n'ont rien à faire là.

Bref, concrètement :

• on pourrait modifier le code actuel du modèle pour qu'il génère un blockquote.... sauf qu'il n'est en fait pas toujours utilisé pour citer .
• on peut éventuellement améliorer à la marge le code actuel du modèle pour supprimer l'avertissement lié au recours à un tableau de mise en forme, sauf que cela reviendra à cacher le vrai souci.

Je suis ouvert à ces deux options, mais ne cacherai pas que la suppression dudit modèle de l'espace MAIN aura ma préférence si c'est possible (surtout pour les raison éditoriales liées à ces textes cités sans aucune contextualisation). Cordialement, --Lgd (d) 16 janvier 2011 à 09:51 (CET)

Note : je viens de passer corriger d'autres problèmes de code et d'accessibilité dans le modèle. C'est déjà ça . Cordialement, --Lgd (d) 16 janvier 2011 à 10:00 (CET)

Ce modèle est inclus sur une centaine de pages. Ce n'est pas trop tard pour remettre en cause son existence. On pourrait scinder ce modèle en deux versions. L'une pour les citations en encadré, avec un rendu visuel correspondant pour que les éditeurs ne confondent pas les deux modèles. Et l'autre pour les encadrés de textes divers et variés. Dodoïste ^{[ dring-dring ]} 16 janvier 2011 à 12:05 (CET)

Délicat en effet. J'avoue ne pas m'y connaître en la matière... Y'a-t-il une solution en attendant? Autant utiliser {{citation bloc}} mais on n'a pas le même rendu ni la même visée... Prosopee (d) 16 janvier 2011 à 12:14 (CET)

On peut scinder le modèle, en effet. Mais pour l'un des deux usages, je coince totalement sur le fait de mettre une citation (qu'on va donc supposer correctement balisée) en exergue batârde d'une section (si cela gêne de remplacer par {{citation bloc}}, c'est en effet là qu'il faut réfléchir au rôle acceptable de cette citation hors texte). Pour l'autre, je suis dans l'incertitude totale quand à son utilité éditoriale. Parfois, il n'y a pas que les aspects techniques d'accessibilité qui comptent, désolé . Donc : vous assumez vraiment le côté éditorial loupé ? Cordialement, --Lgd (d) 16 janvier 2011 à 18:25 (CET)

Et faire un tableau de données classique mais aux lignes invisibles...? Ou ce genre de cadre : « {| align=center cellpadding=5px cellspacing=0 border=0 style="background-color: #EEE" » Prosopee (d) 16 janvier 2011 à 21:27 (CET)

Le problème ne relève pas de cela. Mais manifestement, ce fameux problème purement éditorial ne soulève aucun intérêt ici, donc oublions-le (désolé de l'avoir évoqué inutilement). Il s'agit à présent simplement de suivre la suggestion de Dodoïste, c'est à dire :

• faire un modèle de citation encadrée (la sorte de thumb actuelle, mettable à droite du texte, avec le BLOCKQUOTE qui va bien)
• conserver celui-ci comme modèle de... texte, chose, truc, disons, encadré aussi (pareil, mais on ne sait pas ce que c'est).

On va tâcher moyen dans un temps raisonnable, comme on dit chez moi. Cordialement, --Lgd (d) 16 janvier 2011 à 21:34 (CET)

Le « problème purement éditorial » est POV. Plus sérieusement, des encadrés sont parfois très pertinents dans de nombreux médias, livres, etc. Lorsqu'ils ont une fonction bien définie, comme a) résumer le chapitre, b) donner une information essentielle, c) donner une information complémentaire. Dans notre cas, cet encadré est un joyeux fourre-tout.

Mais faire un modèle par usage, c'est justement répondre en partie à ce problème. Si on fait une apparence bien définie pour les encadrés citation, c'est déjà ça de gagné. Et dans l'autre modèle, on peut ajouter un titre d'encadré à choisir suivant le type d'encadré. Comme « En bref », « À noter que », « Saviez-vous que », etc. Juste pour donner quelques pistes, je ne propose pas d'adopter cela tel quel. Dodoïste ^{[ dring-dring ]} 18 janvier 2011 à 20:12 (CET)

Le problème n'est pas le POV : bien-sûr que n'importe quelle décision de règle éditoriale est un POV : le POV qu'on baptise « règles éditoriales de WP », dans un domaine où la décision arbitraire est une nécessité quotidienne ici comme ailleurs.

Les encadrés ne posent pas de question de pertinence (ils ne sont pas pertinents), mais ils posent une question d'usage : ils sont à l'évidence du goût de quelques contributeurs impliqués dans un type d'article exemplaire (les AdQ). Cela signifie, ici, qu'il n'y a plus lieu de discuter sur le fond, ce que j'ai déjà clairement accepté.

Passons, donc.

On fera un modèle par usage, en effet, c'est à dire plus simplement deux modèles : le pas trop dramatique (les citations, ce sera {{Citation hors contexte}}, je pense) et le totalement incertain, où la diversité des titres que tu suggères permet en fait de définir dès maintenant le nom du modèle : {{Mon POV à ce propos en encadré}}. Cordialement, --Lgd (d) 18 janvier 2011 à 20:27 (CET)

Je ne dois pas avoir de chance. Sur les quelques pages de [1], j'ai trouvé des cladogrammes et une infobox pour écluses. Il y a aussi {{Encadré texte}} [2]. --Anneyh (d) 18 janvier 2011 à 20:55 (CET)

Si je peux ajouter quelque chose, il serait intéressant de signaler facilement et visiblement les modèles qui sont accessibles...car on est paumé dans cette jungle technique. cordialement Prosopee (d) 20 janvier 2011 à 08:06 (CET)

Oui, tout à fait. Des catégories avaient été mises en place à cet effet, mais sont restées en jachère. Il est temps à présent de les utiliser systématiquement Catégorie:Modèle par accessibilité. Cordialement, --Lgd (d) 20 janvier 2011 à 09:27 (CET)

Et sur quels critères se baser pour remplir correctement ces catégories ? Sur Wikipédia:Atelier accessibilité/Suivi des points améliorables ? --Amicalement, Salix ( converser) 20 janvier 2011 à 20:11 (CET)

Excellente question. Les critères sont les bonnes pratiques accessibilité (Wikipédia:Atelier accessibilité/Suivi des points améliorables est une vieille chose délaissée et sous cette forme à présent peur utile). --Lgd (d) 20 janvier 2011 à 20:13 (CET)

Sans doute mais, à part toi, qui peut alors remplir ces catégories évaluées par priorités ? Il manque je crois une Catégorie:Accessibilité à corriger et Catégorie:Accessibilité à évaluer afin de répertorier peu à peu tous les modèles, même si on n'est pas toi . --Amicalement, Salix ( converser) 20 janvier 2011 à 21:46 (CET)

L'important (pour les contributeurs) serait surtout Catégorie:Modèle accessible. Pour les catégories de modèles à corriger, la priorisation est automatisée via un bot (elle repose simplement sur le nombre d'utilisation du modèle dans les articles). Pour les modèles à évaluer : disons que l'absence des catégories précédente vaut catégorisation dans Catégorie:Accessibilité à évaluer, non  ? Cordialement, --Lgd (d) 22 janvier 2011 à 07:28 (CET)

Bonne idée cette catégorie... par contre un logo spécial accessibilité serait bienvenue pour rapidement discriminer les modèles accessibles des autres, pas beaux. Prosopee (d) 22 janvier 2011 à 20:52 (CET)

Pimpom, pimpom...

Un Samaritain pour empêcher JPS68 (d · c · b) et Sinaloa (d · c · b) (alias 82.127.96.128 (d · c · b) apparemment) d'en venir aux mains à coup d'alternatives textuelles et de salade niçoise, tous les deux en toute bonne foi évidente mais pour des raisons également erronées ? Cordialement, --Lgd (d) 16 janvier 2011 à 18:31 (CET)

Et accessoirement corriger l'article à présent bloqué en {{R3R}} pour une question de ALT (une première, dont je ne sais pas s'il faut se réjouir ou pleurer). Cordialement, --Lgd (d) 16 janvier 2011 à 19:00 (CET)

À première vue, la version correcte (ni plus ni moins, et qui devrait mettre tout le monde d'accord), serait un mélange des versions de JPS68 (d · c) et Sinaloa (d · c), c'est-à-dire des photos en thumb right, avec légende, et des <gallery> correctes (sans "alt=" traînant devant le texte). Il n'y a rien qui me semble sujet à hésitation dans les éléments concernés... od†n ^{[dead words]} 16 janvier 2011 à 19:22 (CET)

Vas-y, lâche-toi, c'est le bon bout. Cordialement, --Lgd (d) 16 janvier 2011 à 19:25 (CET)

Du moment que l'utilisateur Sinaloa (d · c · b) vient de décider de cesser sa croisade contre les alt=, je retire le bandeau 3RR. Cdlt --JPS68 (d) 16 janvier 2011 à 19:30 (CET)

Taxobox CITES

Bonjour, à la faveur des réflexions sur Utilisateur:Anneyh/Stratigraphie y aurait-il un moyen de compacter les informations véhiculées par le modèle {{Taxobox CITES}} (très espaçophage, surtout quand il est en double comme sur notre exemple fictif ou sur Loup) et au passage d'en améliorer l'accessibilité ? Merci d'avance de votre aide. --Amicalement, Salix ( converser) 16 janvier 2011 à 18:42 (CET)

Vu rapidement, quelques suggestions (mais il n'y a pas vraiment de questions d'accessibilité) :

• supprimer l'icône, qui passe au mieux pour un n-ième petit drapeau anecdotique et au sens indiscernable (désolé).
• supprimer la mise en colonne, de peu d'utilité, au profit d'une cellule unique prenant, selon les cas, l'une des deux formes suivantes (avec les liens nécessaires) :
  1. Statut CITES : Document (date, précision)
  2. Statut CITES : Document 1 (date, précision), Document 2 (date, précision)

« Révision du... » est inutile pour les dates. Le tout avec le retour à la ligne inévitable dans le 2e cas. Ou sinon, faire une variante du 2e cas en mettant une liste à puce après « Statut CITES : ».

Cordialement, --Lgd (d) 16 janvier 2011 à 18:56 (CET)

Si j'ai bien compris, tu proposes de supprimer des informations ? pour gagner trois fois rien comme place. Alors qu'il y a les taxobox commons et wikispecies à virer en lien en colonne de gauche pour gagner efficacement de la place. TED 16 janvier 2011 à 19:16 (CET)

Evidemment, vu comme ça . Non, plus sérieusement, pour le contenu, je suggère en effet essentiellement de supprimer une icône à l'utilité improbable et de rendre plus concise une mention de date (mais ce ne sont que des suggestions. Quand on me demande un avis touchant au fond d'un sujet sur lequel je suis ignare, je prends le risque de dire une sottise, c'est aussi mon rôle). Cordialement, --Lgd (d) 16 janvier 2011 à 19:27 (CET)

@ TED. Essayer de compacter ce modèle n'empêche absolument pas de virer Commons et Wikispecies de la Taxobox. Dès qu'il y a un robot capable de les transférer proprement vers {{Autres projets}} tu n'as qu'à lancer le vote ! Personnellement, je dirais oui des deux claviers.

@ Lgd. L'icone donne une micro échelle (c'est le moins qu'on puisse dire, il faut des yeux d'aigle pour voir la flèche !) et indique la gravité du problème à ceux qui ignorent si c'est pire d'être en annexe I ou Annexe III. Pourrait-on la conserver en la disposant autrement pour que cela prenne moins de place en hauteur ? En particulier quand il y en a deux l'une au dessus de l'autre. --Amicalement, Salix ( converser) 16 janvier 2011 à 20:03 (CET)

Sur le premier point (où là, par contre, je suis tout à fait dans mes compétences), je suis en train de compter mes claviers... Bon, 6 votes pour supplémentaires à propos de virer Commons et Wikispecies.

En revanche, pour l'icône en l'état : désolé, c'est totalement indiscernable. C'est mort. Si vous voulez créer un jeu d'icônes du type gros rond blanc, vert puis rouge, peut-être. Cordialement, --Lgd (d) 16 janvier 2011 à 20:12 (CET)

En fait, j'avais mal lu : « « Révision du... » est inutile pour les dates. » : j'avais compris que tu voulais supprimer les dates. Mais ce n'est pas le cas. Je te présente mes excuses.

Pour ce qui est de l'icône : est-ce qu'il y a un truc de ce genre dans CITES ? Est-ce qu'il y a des couleurs avec une convention normalisée ?

Pour commons et wikispecies : j'allais relancer les choses sur le café des biologistes quand a commencé le long débat sur le thème : virer les taxobox, alors je me suis abstenu pour éviter d'ajouter à la confusion. Je vais le faire maintenant, avec deux votes indépendants (commons d'une part et wikispecies d'autre part), car il y avait des divergences lors d ela dernière discussion). TED 16 janvier 2011 à 21:41 (CET)

On gagnerait en effet de la place à supprimer les deux colonnes et « Révision du... », ce qui permettrait peut-être d'économiser une ligne . A part ça, quelqu'un sait faire fonctionner cette foutue base ? J'ai beau entrer Canis lupus dans la recherche elle ne trouve rien alors qu'il y a 2 modèles CITES sur l'article ?! ,--Amicalement, Salix ( converser) 16 janvier 2011 à 22:39 (CET)

Comme ça ? Totodu74 (devesar…) 20 janvier 2011 à 21:51 (CET)

Es-tu sur de ton lien ? --Amicalement, Salix ( converser) 20 janvier 2011 à 21:57 (CET)

Pour le site cites.org je crois qu'il y a que ça, mais WBR donne des liens vers sea.unep-wcmc.org : ici pour ton loup gris Canis lupus, là pour une recherche. Totodu74 (devesar…) 20 janvier 2011 à 22:06 (CET)

Merci, en fait maintenant mon premier lien fonctionne bien. Panne temporaire sans doute--Amicalement, Salix ( converser) 20 janvier 2011 à 23:29 (CET).

Accessibilité du titre ?

Salut, c'est encore moi . J'ai peut-être pas assez fouillé mais je me suis posé une question aujourd'hui : qu'en est-il de l'accessibilité des titres d'articles ? Existe-t-il un moyen, est-ce nécessaire/utile, faut-il s'en préoccuper ? --'toff ^[discut.] 17 janvier 2011 à 05:49 (CET)

{{Titre mis en forme}} ? TED 17 janvier 2011 à 06:33 (CET)

Ca répond à ma question. --'toff ^[discut.] 17 janvier 2011 à 06:47 (CET)

Attention à bien lire la documentation du modèle pour les restrictions de l'utilisation du modèle, et les cas où d'autres modèles sont à utiliser. TED 17 janvier 2011 à 08:34 (CET)

En fait, ma question portait sur la langue du titre (et j'ai oublié de le mentionner...). Mais j'avais bien remarqué que le modèle qui m'intéresse est {{Langue du titre}}. --'toff ^[discut.] 17 janvier 2011 à 16:35 (CET)

Coucou, le {{Titre mis en forme}} se montre souvent utile, la langue allant souvent avec les italiques. Totodu74 (devesar…) 20 janvier 2011 à 21:50 (CET)

info-bulle

J'ai indiqué une alternative textuelle à l'image illustrant cette page via le paramètre alt=. Et, l'info-bulle ne s'affiche pas, lorsque je positionne la souris sur l'image ; comment doit-on faire pour que celle-ci s'affiche ? Merci de la réponse. --Bigfan (d) 18 janvier 2011 à 08:19 (CET)

L'alternative ne sert pas à l'affichage d'une infobulle (techniquement, ce sont deux attributs différents, alt pour l'alternative et title pour l'infobulle). La confusion fréquente est liée au comportement particulier des anciennes versions d'Internet Explorer qui affichaient l'alternative en infobulle.

D'une manière générale, les contributeurs n'ont pas la main sur l'attribut title ni sur le contenu des infobulles des images-liens dans Wikipédia. Cordialement, --Lgd (d) 18 janvier 2011 à 10:48 (CET)

Précision : c'est seulement quand l'image n'arrive pas à s'afficher correctement qu'on voit à la place s'afficher le contenu du « alt= ». Fais l'expérience : si tu as Firefox par exemple, clic sur Outils>Options>Contenu, décoche « charger les images automatiquement » > ok et puis recharge ta page. Tu verras l'aternative textuelle dans le cadre prévu pour l'image (n'oublie pas de recocher la case ensuite ). --Amicalement, Salix ( converser) 18 janvier 2011 à 12:09 (CET)

Ok, merci de l'explication et bonne journée, --Bigfan (d) 18 janvier 2011 à 16:21 (CET)

Modèle Coord

Bonsoir,

Savez-vous si il est possible d'insérer une alternative textuelle avec ce genre de modèle ? Cordialement, — Droop ^[blabla] 19 janvier 2011 à 23:37 (CET)

L'image est générée par une fonction javascript sur laquelle nous n'avons pas la main (et qui nécessiterait en fait d'autres corrections). Cordialement, --Lgd (d) 20 janvier 2011 à 07:13 (CET)

Merci pour la réponse ! Pas d'objection formelle quant à son utilisation malgré cela ? — Droop ^[blabla] 20 janvier 2011 à 07:19 (CET)

Aucune : quand il s'agit d'une fonctionnalité nécessaire pour laquelle il n'y a pas de correction immédiate, il ne s'agit pas de faire obstruction . Cordialement, --Lgd (d) 20 janvier 2011 à 09:39 (CET)

Accessibilité images

Grâce à ta page utilisateur, j'ai enfin trouvé un outil me permettant de vérifier l'accessibilté d'un article. J'ai déjà essayé d'améliorer l'accessibilité des articles dont je suis le principal contributeur et qui font l'objet d'un note BA ou AdQ, mais jusqu'à présent, j'ai fait l'impasse en ce qui concerne les images.

Je vais faire un premier essai dans l'article consacré à la loi allemande des pleins pouvoirs de 1933. Puis-je te recontacter après ma première tentative pour voir si c'est OK. Pourrais-tu également passer cet article au crible, sans la moindre indulgence, afin de me permettre de vérifier si c'est en ordre pour le reste? Cordialement. Couthon (d) 21 janvier 2011 à 18:45 (CET)

À ta disposition (tant que je ne suis pas mobilisé au mauvais moment IRL, ce qui peut entraîner un petit délai. Le WE est un bon moment.). Par curiosité, de quel outil s'agit-il exactement ? Le fameux gadget ?

Sinon, les images et leurs alternatives sont un cas particulièrement épineux, sur lequel je tente plutôt de promouvoir actuellement un attentisme prudent, pour tout dire. Mais toutes les contributions et les essais en ce sens sont justement très utiles pour affiner une sorte de plan de bataille à long terme. Cordialement, --Lgd (d) 21 janvier 2011 à 20:09 (CET)

Une remarque, pour compléter, en attendant ton retour: un travail éditorial rigoureux a manifestement déjà été mené sur cet article. Par exemple, en ce qui concerne les citations, ce qui entraîne immédiatement que la question côté accessibilité est réglée (l'idée générale est faire coïncider les deux à chaque fois que c'est possible : utiliser le bon modèle éditorial pour les citations suffit à les rendre accessibles). De même, hiérarchiser correctement les sections suffit à régler la question d'accessibilité des titres de section. De temps en temps, on manque d'un modèle ou d'un mode d'emploi pour traiter des choses particulières, comme le tableau donnant les deux versions linguistiques du texte de la loi : là, tes retours vont être précieux pour savoir comment et où documenter ça, ou bien quel modèle améliorer ou créer. Cordialement, --Lgd (d) 21 janvier 2011 à 20:31 (CET)

Position d'en tête ?

Salut, ça faisait longtemps. Une petite question con : l'en-tête doit il être placé en début de tableau ou peut-il être n'importe où ? Par exemple :

tableau exemple

truc 1	truc 2	en-tête des trucs et machins	machin 1	machin 2

{| class="wikitable"
|+ tableau exemple
| truc 1 || truc 2
! scope="row" | en-tête des trucs et machins
| machin 1 || machin 2
|}

Est-ce que le scope="row" s'applique à toute la ligne (trucs et machins) ou seulement à ce qui le suit sur la ligne (machins) ? Le gadget est vert en tout cas... Quand je vous dis que je pose des questions cons --'toff ^[discut.] 22 janvier 2011 à 04:37 (CET)

Le scope s'applique théoriquement à toute la ligne. C'est d'ailleurs sur ce principe qu'a été fait le modèle {{Pyramide des âges}}. Maintenant... Cela passe plus ou moins bien selon les versions de lecteur d'écran : quand c'est possible, il est préférable de placer l'en-tête en début de ligne. Cordialement, --Lgd (d) 22 janvier 2011 à 07:06 (CET)

Plus ou moins intelligents les lecteurs d'écran ? En fait, c'est utile, comme pour la pyramide des âges, pour séparer efficacement deux tableaux ayant les mêmes entrées. --'toff ^[discut.] 22 janvier 2011 à 07:17 (CET)

Couleur et abbr incompatibles ?

Salut. Est-il possible d'attribuer une couleur autre que celle par défaut lorsqu'on utilise <abbr title=""></abbr> ? --'toff ^[discut.] 22 janvier 2011 à 20:28 (CET)

Moui (<abbr title="coucou" style="color: red;">Exemple</abbr> donne Exemple. Mais c'est pour réparer quoi, exactement ? Cordialement, --Lgd (d) 22 janvier 2011 à 20:32 (CET)

J'ai accessibilisé les tableaux de Canadiens de Montréal dont les en-têtes sont colorés. Je ne suis pas le principal contributeur de l'article (sensible) et je préfère laisser ces couleurs qui me semblent d'ailleurs relativement accessibles sauf quand la couleur par défaut prend le pas. Pour résumer :

Gardiens de but

Numéro	Joueur	Nat.	Attrape de la	Obtention	Lieu de naissance

deviendrait :

Gardiens de but

Numéro	Joueur	Nat.	Attrape de la	Obtention	Lieu de naissance

C'est mieux non ? --'toff ^[discut.] 22 janvier 2011 à 20:40 (CET)

Oui, tout à fait. Ce qui me titillait, c'est que j'avais le souvenir qu'on avait déjà prévu le coup pour que ce soit automatique. Mais je viens de réaliser qu'on ne l'a fait que dans le cas du modèle {{abbr}} (qui récupère tout seul la couleur indiquée pour la ligne, mais qui ne souligne pas) :

Gardiens de but

Numéro	Joueur	Nat.	Attrape de la	Obtention	Lieu de naissance

Du coup, je me demande s'il ne faudrait pas étendre au tag abbr cette précaution prise pour le moment uniquement dans le cas du modèle (une petit modification simple dans Common.css)... Il faut que je vérifie si cela n'aura pas d'effets de bords quand abbr est utilisé dans des pages d'interfaces (historiques, etc.). Cordialement, --Lgd (d) 23 janvier 2011 à 08:25 (CET)

Bon, c'est fait dans dans common.css : <abbr> peut à présent être utilisé directement sans préciser la couleur du texte quand il y a un arrière-plan coloré (ton premier exemple s'est donc corrigé de lui-même si tu actualises le cache de ton navigateur). Par contre, je ne corrige pas la couleur de bordure (le pointillé en dessous de l'abréviation), je me méfie des cas tordus. S'il s'avère que j'ai cassé quelque-chose dans une page d'interface, cela aura au moins le mérite de montrer que le abbr {color:black} des styles par défaut mediawiki n'était pas habile, donc j'assume. Sgmbl. Cordialement, --Lgd (d) 23 janvier 2011 à 09:54 (CET)

Ca me va très bien comme ça. Merci. --'toff ^[discut.] 23 janvier 2011 à 17:27 (CET)

Pour information, le modèle {{abréviation}} a depuis lors été renommé en {{abréviation discrète}} :

• {{abréviation}} crée désormais des abréviations soulignées (exemple : « foo. »)
• il faut maintenant utiliser {{abréviation discrète}} pour créer des abréviations non soulignées (exemple : « foo. »)

Cordialement, od†n ↗^blah 18 février 2011 à 03:40 (CET)

Déterrage : ce "color:inherit" n'est plus nécessaire depuis quelque temps. Je viens de le supprimer du Common.css. od†n ↗^blah 3 décembre 2017 à 21:18 (CET)

Aperçu du rendu accessible?

Bonsoir, existe-t-il un outil ou site web permettant de voir un article comme un utilisateur concerné par les normes d'accessibilité peut le voir? Merci, Prosopee (d) 22 janvier 2011 à 20:48 (CET)

Il y a une très grande variété de situations de handicap et donc d'adaptations de la page par des aides techniques. On ne pourrait proposer qu'un ou deux exemples, qui ne couvre que très peu de questions ou de critères d'accessibilité. Et malheureusement, il n'y a rien de très probant actuellement.

• on a longtemps utilisé les navigateurs textes (ou des sites d'émulation similaires) pour cela : mais leurs capacités trop limitées ne représentent plus le rendu actuel via des aides techniques et donne une idée trop trompeuse.
• il existe une extension pour le navigateur Firefox, appelée Firevox, qui est simple à installer et à utiliser, et qui tente de reproduire la lecture linéaire de la page par un lecteur d'écran. Mais là encore, c'est un outil trompeur car il ne donne aucune idée de la partie la plus importante, qui est l'interaction avec la page permise par les multiples fonctionnalités d'un lecteur d'écran. Il est certes moins trompeur que le navigateur texte, mais pour ma part, je suis très réservé sur son utilisation « pédagogique ».
• des barres d'outils spécialisées pour FF, IE etc. permettent ou facilitent certaines manipulations de la page comme de remplacer les images par leurs alternatives textuelles, de linéariser les tableaux, de désactiver les couleurs du site, etc. Mais c'est tout de suite complexe, ce sont davantage des outils « experts » que des outils de démonstration.
• bien qu'il ne s'agisse pas de pages Wikipédia, il y a enfin d'excellentes démonstrations vidéos de rendu accessibles ou non (« l'ordinateur des aveugles » est un grand classique).

Ces divers outils sont listés dans Wikipédia:Atelier accessibilité/Ressources et références. Je n'en conseillerai aucun s'il s'agit de permettre aux relecteurs de se rendre compte « in situ ». Mais en fonction du but visé, peut-être peut-on envisager de réaliser une démo vidéo sur les articles Wikipédia (sous réserve des soucis de licence liés à la publication dans Wikipédia de captures vidéos ou audios de rendu visuel ou sonore via des logiciels non libres : je n'ai jamais pu obtenir une réponse claire sur ce point jusqu'ici). Cordialement, --Lgd (d) 23 janvier 2011 à 09:41 (CET)

dommage en effet, il serait bon que Wp planche sur un outil de visualisation. Je vais tester deux trois logiciels, c'est plus pou se rendre compte afin d'affiner les mises en page... Je me suis dit, par exemple, que pour les descriptions alt, un petit exercice sympa serait de regarder un film en audio description, ça donne des idées... beaucoup à faire donc Prosopee (d) 23 janvier 2011 à 13:04 (CET)

Pour amateurs de corrections syntaxiques répétées dans une loooooongue liste

Bonjour,
Au cas où, je signale une oeuvre utile à accomplir : corriger la syntaxe wiki du Glossaire du cinéma récemment réunifié en une seule page (qui sera inévitablement scindée en plusieurs dans quelques mois mais ce n'est pas la question). Il s'agit de l'emploi des listes de définition, et ma contribution s'est arrêtée, je l'avoue, à expliquer l'idée dans Discussion:Glossaire du cinéma , avec un exemple. Cordialement, --Lgd (d) 25 janvier 2011 à 13:31 (CET)

Longue vie à Arkanosis, l'homme qui dégaine ses regexp plus vite que son ombre. --Lgd (d) 25 janvier 2011 à 18:10 (CET)

Au cas où il y aurait d'autres articles à convertir dans le même genre, j'ai utilisé le code Python suivant (qui gère tout sauf les listes imbriquées — ça, j'ai fait à la main ).

Amicalement — Arkanosis ^✉ 25 janvier 2011 à 19:50 (CET)

import re
import sys

_item = re.compile(r"^\*\s*(?:\{\{en\}\}\s*)?'''(.*?)'''(?!')\s*:?\s*(.*)$", re.UNICODE)

with open(sys.argv[1]) as inputFile:
    for line in inputFile:
        if _item.match(line):
            print re.sub(_item, r';\1\n:\2', line.rstrip())
        elif line.rstrip():
            if line[0] == '=':
                print
            print line.rstrip()

Alt automatique?

Je me prends les cheveux avec ces alternatives textuelles, qui allongent vraiment le temps de contribution et souvent sans fruits visibles. Ne serait-il pas envisageable de rapatrier automatiquement les descriptions de Commons (bien entendu cela sous-entend qu'elles soient en français et correctement décrites) ou, inversement, d'exporter celles de WP vers Commons (ou je dis une bêtise)? Prosopee (d) 27 janvier 2011 à 17:24 (CET)

Voir bugzilla:19906. Jean-Fred (d) 27 janvier 2011 à 17:31 (CET)

Bonsoir,

Oui, c'est pour cela, encore une fois, que les alternatives d'images ne figuraient pas dans les critères pour les AdQ et ne sont plus généralement pas sous cette forme une priorité pour les contributeurs. Je vais finir par me lasser un peu de le répéter sans être entendu .

Non, la solution d'une alternative automatique via Commons n'est actuellement pas possible, pour des raisons complexes que je peux détailler si besoin.

Donc : ne pas retenir cette question d'accessibilité pour le moment, c'est improductif.

Pour éviter tout malentendu : personne ne dit ni ne fait de bêtises sur le sujet, il est simplement très complexe ; peut-être l'un des plus complexes en termes d'accessibilité ; et c'est à long terme qu'il pourra être traité dans Wikipédia. Cordialement, --Lgd (d) 27 janvier 2011 à 17:37 (CET)

ne t'inquiète pas tu es entendu! mais c'est vrai que les alt sont chronophages. a+ Prosopee (d) 27 janvier 2011 à 17:47 (CET)

Non, pas vraiment ou pas du tout : Wikipédia:Atelier de lecture retient actuellement les alternatives comme un critère de relecture, là où j'en avais fait une simple illustration de ce qu'on pouvait faire si on souhaitait aller plus loin. Cordialement, --Lgd (d) 27 janvier 2011 à 17:56 (CET)

J'ai précisé que les atl étaient facultatifs...Prosopee (d) 1 février 2011 à 20:15 (CET)

je serais beaucoup plus tranché que cela dans le fait de mettre résolument les alternatives en dehors de la liste des critères, comme dans la proposition que j'avais faite dans ton brouillon, mais c'est un pas dont je te remercie. Cordialement, --Lgd (d) 1 février 2011 à 20:22 (CET)

OK. Je retire donc. Prosopee (d) 1 février 2011 à 20:33 (CET)

Loi des pleins pouvoirs : essai accessibilité

Après avoir obtenu le label BA, j'ai systématiquement revu le texte de l'article consacré à la loi allemande des pleins pouvoirs de 1933 en vérifiant le respect des critères d'accessibilité. Il me reste des doutes, notamment en ce qui concerne le tableau reprenant les versions allemande et française du texte de la loi. Relecture, remarques et corrections bienvenues. Cordialement. Couthon (d) 28 janvier 2011 à 15:59 (CET)

Je bloque sur l'alternative textuelle pour la dernière illustration. Couthon (d) 28 janvier 2011 à 16:01 (CET)

Bonjour,
Avant tout, merci pour ce travail considérable. Un peu bousculé par le temps, je vais déjà aller à l'essentiel, qui concerne les alternatives.

La question est délicate à propos des alternatives textuelles. Pour faciliter les choses, je viens de faire une mise à jour impromptue du gadget accessibilité (il faut donc actualiser le cache de vos navigateurs pour utiliser cette nouvelle version. Le gadget évalue maintenant un point supplémentaire : la longueur des alternatives. Je vous invite à regarder l'article avec cette nouvelle version du gadget.

L'idée est la suivante, si j'essaie de retranscrire au plus simple les normes d'accessibilité WCAG :

• une image a obligatoirement une alternative textuelle qui est immédiatement restituée par un lecteur d'écran : c'est un texte très concis, aussi synthétique que possible. De manière indicative, on peut retenir une limite de 120 caractères, en sachant bien que c'est la pertinence qui compte avant tout et que 10 caractères de plus si on ne peut pas faire autrement ne sont pas un souci majeur. Pourquoi cette alternative doit-elle être concise ? D'une part parce que sa lecture est en partie « imposée » à l'utilisateur d'un lecteur d'écran ; d'autre parce que si elle devient un texte plus complexe, elle devrait être structurée (paragraphes, listes, etc.) ce qui n'est techniquement pas possible dans ce cas.
• une image peut également avoir une seconde métadonnée, qui permet d'accéder (si on le souhaite) à une description étendue. Celle-ci n'a aucune limite de longueur. Elle peut être aussi structurée que nécesaire (avec des paragraphes, des listes, des tableaux, etc.). Dans Wikipédia, les pages des images elles-mêmes fournissent un endroit tout à fait approprié pour écrire cette description.

En d'autres termes : les alternatives actuelles sont de remarquables descriptions étendues. La rédaction d'alternatives concises renvoie à la difficulté que j'ai déjà plusieurs fois soulignée : il faut parvenir à décider (avec une part d'arbitraire) quelle est l'information essentielle apportée par l'image dans son contexte.

Je reviens sur le sujet et sur le reste dès que possible. Encore merci pour l'intérêt que tu portes à ces questions. Cordialement, --Lgd (d) 29 janvier 2011 à 12:05 (CET)

Bonjour lgd et merci de m'avoir indiqué cette discussion, deux questions , -c'est un texte très concis, aussi synthétique que possible. une formulation quasiment "télégraphique" est elle une bonne solution pour essayer de caser le plus d'infos de manière concise ? par exemple au lieu de "alt=portrait en buste de trois quart du roi louis XIV" on met "alt=portrait d'homme , (buste trois-quart)", et deuxième question , comme tu sais j'essaye de rendre plus concis les alt de l'article Opposition à la corrida et j'ai retiré des infos sur les couleurs en privilégiant plutôt les informations de formes , est ce un choix pertinent ? Kirtap^{mémé sage} 29 janvier 2011 à 14:45 (CET)

L'idée n'est pas de tomber dans la recherche de l'optimisation à tous prix : passer en style télégraphique pour raccourcir de quelques caractères n'est pas utile.

Pour le reste, tout est affaire de contexte : il ne me semble pas que l'aspect très coloré de certaines des images liées à la corrida soit un aspect essentiel dans Opposition à la corrida. En revanche, ce serait à voir dans Corrida, dans la mesure où ces couleurs sont un caractéristique du sujet. Cordialement, --Lgd (d) 29 janvier 2011 à 16:23 (CET)

Comme le rouge de la muleta, OK bien compris, merci de ta réponse lgd. Kirtap^{mémé sage} 29 janvier 2011 à 20:22 (CET)

gadget accessibilité mis à jour

Actualisez simplement le cache de votre navigateur : la modification ne concerne que le test sur les images et leurs alternatives, voir ci-dessus. Cordialement, --Lgd (d) 29 janvier 2011 à 12:05 (CET)

J'ai vu la modification avant de voir cette discussion. J'ai cru à une blague au début Fichier:Smilie + Wand.gif (mais s'il faut le faire on le fera ) Totodu74 (devesar…) 1 février 2011 à 18:57 (CET)

Pourquoi l'alternative doit-elle être limitée à 120 caractères ? Parce que bon si elle doit remplacer la photo autant ne pas être radin sur le nombre de mots et décrire le plus précisément possible la photo. Par exemple, je ne vois vraiment pas comment faire en 120 caractères sur cette image. Udufruduhu (d) 2 février 2011 à 10:18 (CET)

Lire le gros bloc de Lgd ci-dessus, sinon j'essaie de résumer en moins de 120 caractères  : La lecture de l'alt est imposée par un lecteur d'écran. Pas de roman, juste l'essentiel de la photo ; 120 est indicatif. Pile poil 120, je suis un maître. Totodu74 (devesar…) 2 février 2011 à 14:59 (CET)

Bonjour, àmha, dans le cas de cette image, il n'y a pas grand chose à mettre dans l'alt puisque tout est (re)dit dans la légende. Un « alt=Dessin humoristique en noir et blanc » devrait suffire. --Amicalement, Salix ( converser) 2 février 2011 à 17:21 (CET)

Oui, je suis désolé que cela fasse un peu « cheveu qui tombe tout à coup dans la soupe ». Ce n'était pas du tout prévu : la priorité étant déjà de faire prendre conscience du problème des alternatives et de la nécessité d'en rédiger, je ne prévoyais pas qu'il faudrait si vite aborder la question de leur concision (en fait, je pensais que de toutes façon, la rédaction des alternatives textuelles ne rencontrerait pratiquement aucun écho...). Le mieux étant souvent l'ennemi du bien, je n'avais pas réagi devant quelques premiers cas où les alternatives étaient un peu verbeuses. Mais il semble que le problème se pose à présent plus vite que prévu .

Je me permets de répéter l'essentiel : ce n'est pas le chiffre de 120 caractères (à vrai dire arbitraire) qui compte, c'est le souci de synthèse de l'information et de concision dans la rédaction.

Ce test ajouté au gadget est un peu une arme à double tranchant : c'est bien si l'essentiel passe, c'est moins bien si cela amène à perdre du temps pour 10 caractères de plus ou de moins. Quand vous voyer que le gadget vous alerte et qu'il vous dit que votre alternative fait plusieurs centaines de caractères, il faut se bouger urgemment. Sinon, c'est à apprécier au cas par cas : même si l'alternative n'est pas parfaite, elle a déjà le mérite d'exister. Cordialement, --Lgd (d) 2 février 2011 à 17:54 (CET)

Ai-je raison de dire que l'alt peut être grandement abrégée quand la légende elle-même est descriptive ? --Amicalement, Salix ( converser) 2 février 2011 à 18:23 (CET)

Oui, pardon : tout à fait. L'alternative vient apporter les informations qui sont spécifiquement portée par l'image et qui sont absentes du texte. Si l'information détaillée est déjà dans la page (pas seulement dans la légende), elle n'a pas à la détailler en double. Cordialement, --Lgd (d) 2 février 2011 à 18:25 (CET)

Ok, merci . --Amicalement, Salix ( converser) 2 février 2011 à 18:42 (CET)

Tableau triable

Salut, c'est encore moi et mes problèmes de tableaux ! (Bouhhhhn, oh nonnnnnnn, pas luiiiiiiiiii ! ). En créant un tableau triable avec 2 lignes d'en-tête, je me suis rappelé (et j'ai vu) que le tri lorsqu'il y a deux lignes d'en-tête ne fonctionne pas bien. Sauf si j'ai pas bien cherché (et c'est bougrement possible) il n'est pas possible d'obtenir un tableau triable avec plusieurs lignes d'en-tête ? (Si oui, je suis fana de la solution). Pour pallier à ce problème, j'ai bidouillé un (deux) tableau(x) et je me demande si c'est bien au niveau de l'accessibilité... Pour mieux comprendre, j'avais ça :

Liste des joueurs

Période	Poste	Nom	Saison régulière					Séries éliminatoires
			PJ	B	A	Pts	Pun	PJ	B	A	Pts	Pun
2002-2003	D	Johnson, AaronAaron Johnson	32	6	31	37	41	11	4	4	8	25
2003-2004	D	Blanchette, AdamAdam Blanchette (en)	56	1	4	5	59	1	0	0	0	0
2006-2007	G	Adrien Lemay	1	0	0	0	0	0	0	0	0	0
1983-1985	D	Côté, AlainAlain Côté (en)	128	12	42	54	213	9	1	4	5	20

et j'ai remplacé par ça :

Saison régulière

Séries éliminatoires

Période	Poste	Nom	PJ	B	A	Pts	Pun	PJ	B	A	Pts	Pun
2002-2003	D	Johnson, AaronAaron Johnson	32	6	31	37	41	11	4	4	8	25
2003-2004	D	Blanchette, AdamAdam Blanchette (en)	56	1	4	5	59	1	0	0	0	0
2006-2007	G	Adrien Lemay	1	0	0	0	0	0	0	0	0	0
1983-1985	D	Côté, AlainAlain Côté (en)	128	12	42	54	213	9	1	4	5	20

Pour le rendu visuel standard, c'est kif-kif et c'est triable. Pour ce qui est de l'accessibilité, j'ai pallié les deux scope col consécutifs par une abréviation plus longue. Est-ce la bonne solution ? --'toff ^[discut.] 1 février 2011 à 06:03 (CET)

Oui, ça ne pose pas de problème d'accessibilité. Cordialement, --Lgd (d) 1 février 2011 à 07:15 (CET)

Déjà une bonne chose mais :

1. Est-ce que ça remplace ? (les deux scope col remplacés par les abrv plus longs) ?
2. Question subsidiaire : c'est quoi le code couleur des "border" de la class wikitable ? (pour uniformiser) --'toff ^[discut.] 1 février 2011 à 07:42 (CET)

Oui, les abbr permettent de remplacer la première ligne d'en-têtes.

La couleur de bordure wikitable est #aaa.

Cordialement, --Lgd (d) 1 février 2011 à 08:06 (CET)

Merci. --'toff ^[discut.] 1 février 2011 à 15:03 (CET)

Pour changer, des listes

Àmha une interrogation qui aura sa place dans la FàQ : Pour que la logique d'enchaînement d'une liste à puces ne soit pas brisé, il convient de ne pas rajouter de saut de ligne entre les puces, etc. Pour les sous-espèces de l'Hirondelle rustique, les photos viennent rompre cet enchaînement. Les insérer plus haut (avant la liste) et en rajouter (des photos) pour que l'entassement finisse par corriger un peu leur emplacement vertical (image de gutturalis face à sa description, etc., ruse pour laquelle j'avais opté ici il y a trois jours, dire si le problème peut se poser souvent), ça peut marcher mais pas partout, pas tout le temps (et surtout ça ne se justifie pas forcément). Komankonfé ? Totodu74 (devesar…) 2 février 2011 à 22:41 (CET)

Je ne sais pas, en général je mets toutes les images en début de section (cf. hérisson). Mais, en fait de listes, entre cette version liste et cette version tableau, est-ce vraiment un progrès pour le lecteur et le lecteur d'écran ? Surtout quand il y a des noms scientifiques au milieu des noms vernaculaires (Blarina brevicauda), que certains noms, mis en 2e colonne, passent à la trappe avec une recherche alphabétique et qu'on perd la correspondance des noms scientifiques en cliquant sur la clé de tri de la dernière colonne --Amicalement, Salix ( converser) 2 février 2011 à 23:22 (CET)

Bonjour,
Liste ou tableau : ce sera indifférent du point de vue accessibilité (si l'une et l'autre sont correctement faites). Cordialement, --Lgd (d) 5 février 2011 à 10:25 (CET)

{{Liste éléments}}

Bonsoir ! J'ai posé une question d'accessibilité à propos des listes sur la page de discussion de ce modèle. Cordialement. Peter17 (d) 3 février 2011 à 22:08 (CET)

Bonsoir, cette question est particulièrement intéressante et a déjà été évoquée... le problème étant d'ordre technique, pour ne pas dégrader le rendu pour les utilisateurs ordinaires, de mon côté je n'ai pas de solution qui me satisfasse vraiment... Les propositions sont les bienvenues.

À propos, les pages de discussion des modèles sont généralement un endroit peu judicieux pour initier des demandes, car ces pages sont vraiment peu suivies

Cordialement, od†n ^{[dead words]} 3 février 2011 à 22:29 (CET)

Dégrader le rendu ? Mais encore ? (Une fois choisi le séparateur, il suffit de créer l'image appropriée, de gérer ce séparateur en background CSS et d'écrire les styles CSS qui sont simples). Cordialement, --Lgd (d) 3 février 2011 à 22:30 (CET)

Je ne t'empêche pas de préparer une jolie maquette od†n ^{[dead words]} 3 février 2011 à 22:38 (CET)

C'est dans ma todo depuis un bout de temps. Le seul souci réel est de trouver comment adapter le modèle {{Liste éléments}} pour gérer le premier ou le dernier élément de la liste (selon que le séparateur est géré à droite ou à gauche d'un élément), avec une syntaxe de modèle simple pour les contributeurs. Cordialement, --Lgd (d) 5 février 2011 à 10:50 (CET)

Ça, c'est gérable, je l'avais déjà fait. Il est possible de ne pas compliquer la syntaxe pour le contributeur à ce niveau. C'est seulement le rendu qui me préoccupe od†n ^{[dead words]} 5 février 2011 à 11:40 (CET)

Eh bien, commence la technique, et on finira le rendu. ;-) Dodoïste ^{[ dring-dring ]} 7 février 2011 à 21:30 (CET)

Citation en langue originale en référence

Salut !

J'ai trouvé dans plusieurs articles des contributions comprenant des citations en français (avec, parfois des liens wiki) complétées, en référence, des citations dans la langue d'origine, ce qui donnerait avec les balises :
{{citation|[[exemple]]}}<ref>{{citation|{{lang|de|''[[Beispiel]]''}}}}</ref>,
soit, en enlevant les nowiki et en remplaçant les ref par des parenthèses :
« exemple » (« Beispiel ») (« Beispiel » étant dans la pratique un lien bleu).
L'affichage est cohérent avec MS IE 8 (que j'utilise) donc a priori également avec les autres navigateurs.

Questions : est-il souhaitable de mettre toutes ces balises ? Sont-elles comprises par les logiciels de lecture « accessiblilisés » ?
Dans la négative, quelles sont les balises à laisser en priorité ?

@ + ! Papatt (d) 7 février 2011 à 18:24 (CET)

Bonjour. Oui ces balises sont souhaitables. L'essentiel est expliqué sur Wikipédia:Atelier accessibilité/Bonnes pratiques#Changements de langue, si tu as des questions plus précises à poser c'est volontiers que j'y répondrai. Bien à toi, Dodoïste ^{[ dring-dring ]} 7 février 2011 à 21:27 (CET)

Merci pour ta réponse, ma question portant sur les imbrications de balises qui ne sont pas explicitées dans la page d'aide. Lgd m'a déjà précisé que c'était inutile dans les alt mais pour les ref et combinaisons, je n'en savais rien.

@ + ! Papatt (d) 7 février 2011 à 22:37 (CET)

Langue du titre à moitié française

Salut. Lorsque le titre est dans une langue différente, il faut utiliser le modèle {{langue du titre}}. Mais quand le titre est partiellement en français et partiellement dans une autre langue, il y a une solution ? --'toff ^[discut.] 11 février 2011 à 04:53 (CET)

Bonjour ! Oui, tu peux contourner le problème avec le modèle {{Titre mis en forme}}, par exemple {{Titre mis en forme|Titre {{lang|en|in english}}.}} Litlok (m'écrire) 11 février 2011 à 09:05 (CET)

Tiens, j'avais pas pensé à regarder celui-là... Merci. --'toff ^[discut.] 12 février 2011 à 04:11 (CET)

Titre d'oeuvres : aberrations

Bonsoir, il m'arrive souvent ce genre de problème avec des titres d'oeuvres : « X publie l' Histoire des moineaux ». Dans certains cas (que je n'arrive pas à comprendre d'ailleurs), le tout est en gras. Comment (d'un point de vue respectueux de l'accessibilité tant qu'on y est) faire en sorte que l'apostrophe ne soit pas confondu avec les italiques du titre? Merci. Prosopee (d) 12 février 2011 à 22:03 (CET)

La version en gras : X publie lHistoire des moineaux et Y publie lHistoire des fleurs (le programme trouve un deuxième groupe de ''' et met le texte entre en gras...). Mais en utilisant l'apostrophe des Caractères spéciaux (l'apostrophe typographique), j'obtiens : X publie l’Histoire des moineaux et Y publie l’Histoire des fleurs (en fait ces apostrophes, c'est une longue histoire, mais dans ce cas il me semble que ça se justifie). --Anneyh (d) 12 février 2011 à 23:15 (CET)

Oui, mais pas tout à fait.

Si on vise au plus simple, l'utilisation de l'apostrophe typo résoud le problème immédiat de mise en forme. Mais pas le problème plus important de balisage sémantique : le code wiki '' génère en effet un élément HTML i qui n'est pas approprié pour les titres d'oeuvres. Mediawiki implémente l'élément approprié, qui est cite. Pour bien faire les choses, il faudrait en réalité, et indépendamment des choix en matières d'apostrophe, écrire :

l'<cite>Histoire des moineaux</cite>

qui donne l'Histoire des moineaux. Ou bien créer un modèle {{titre d'oeuvre}} qui utilise ce balisage si on préfère éviter l'utilisation directe de syntaxes wiki ressemblant à du HTML (ou encore, dans ce cas, d'une balise au libellé souvent trompeur).

Il n'y a pas une extrême urgence à changer les habitudes sur ce point. Mais la question se posera de manière plus évidente lorsque les contenus Wikipédia basculeront en HTML5, avec une importante quantité de contenus à corriger. A ce propos, l'utilisation de ''' pour la mise en gras de la première instance du titre dans l'introduction d'un article n'est pas non plus sémantiquement appropriée (le balisage approprié serait généralement dfn, dont le support par mediawiki est en cours de déploiement en ce moment)... . Cordialement, --Lgd (d) 13 février 2011 à 04:33 (CET)

Je vous adore, les gars de l'atelier d'accessibilité . Vos réponses m'aident vraiment beaucoup. Cette page devrait donner lieu à une synthèse des bonnes pratiques (sorte de FAQ) car il y a vraiment plein d'astuces à connaître. Pour finir sur ce problème (qui n'en est plus un, j'utiliserai cite maintenant), la solution est accessible, nous sommes d'accord? Prosopee (d) 13 février 2011 à 09:59 (CET)

Les deux solutions sont accessibles. Celle avec l'apostrophe typo et le « '' » est améliorable à d'autres points de vue, mais tout à fait accessible. Celle avec le cite est presque optimale à tous points de vue : elle est embêtante parce que beaucoup de gens comprennent que le terme cite signifie « citation » alors que c'est un faux-ami dans ce cas, et parce qu'elle introduit un bout de balisage HTML dans les articles, ce qui coince un peu avec les usages actuels qui tendent à tout remplacer systématiquement par de la syntaxe wiki (faux problème, AMHA, mais qu'on rencontre tout de même souvent). Cordialement, --Lgd (d) 13 février 2011 à 10:20 (CET)

Modèle {{lang}} dans abbr title

Encore moi . Proche d'une question ci-dessus, je remarque que la combinaison abbr title + modèle {{lang}} ne fonctionne aps : <abbr title=''{{lang|en|Test/Opération/Test/Exit}}''>TOTE</abbr> donne :

• <abbr title=Test/Opération/Test/Exit>TOTE

(Promis je dérange plus pour les deux semaines qui arrivent ;) Prosopee (d) 13 février 2011 à 09:59 (CET)

Une abréviation et son explicitation doivent obligatoirement être considérés comme étant dans la même langue. Pour passer aux gros mots techniques : le contenu d'un élément HTML (« TOTE ») et celui de ses attributs (« Test/Opération/Test/Exit ») sont techniquement un seul bloc de contenu pour ce qui est de la mention de la langue de traitement. C'est une vieille limite du HTML, bien connue et embêtante.

Concrètement : on devrait donc dire que le tout est en anglais, et donc pouvoir faire dans ce cas:

{{lang|en|<abbr title="Test/Opération/Test/Exit">TOTE</abbr>}}

Sauf que mediawiki a un bug pour le moment sur le résultat, qui ne donne rien, comme en témoigne le test suivant : .

Partant de là, on pourrait :

• soit recommander d'écrire <abbr title="Test/Opération/Test/Exit" lang="en">TOTE</abbr> qui donne le résultat attendu : TOTE
• soit créer un modèle {{abréviation étrangère}} pour produire le même résultat en essayant de rendre les choses plus faciles pour les contributeurs ? (un modèle de plus, un poil de complexité de plus dans les contributions aux articles).
• soit attendre que ce bug soit corrigé. Mais il faut regarder s'il a été signalé, déjà : n'hésites surtout pas à revenir nous signaler autant de choses que tu voudras, si tu nous détectes des bugs de mediawiki (et même sans cela).

Cordialement, --Lgd (d) 13 février 2011 à 10:39 (CET)

Quelqu'un peut me confirmer le bug ? Il est tellement énorme que j'ai l'impression désagréable d'avoir fait une bête erreur de syntaxe dans {{lang|en|<abbr title="Test/Opération/Test/Exit">TOTE</abbr>}}. Cordialement, --Lgd (d) 13 février 2011 à 10:52 (CET)

Perso je confirme le bug. Merci de ton aide et de tes réponses Lgd. Ta première solution, certes provisoire, est celle que j'utiliserai. Longue vie à l'atelier. Prosopee (d) 13 février 2011 à 11:50 (CET)

C'est à cause du « = » dans le 2^e paramètre. Il faudrait faire :

• {{lang|en|2=<abbr title="Test/Opération/Test/Exit">TOTE</abbr>}}
• ou {{lang|en|<abbr title{{=}}"Test/Opération/Test/Exit">TOTE</abbr>}}

od†n ↗^blah 13 février 2011 à 13:29 (CET)

Je me disais bien, aussi. Merci, Odin.

Bon, ça reste pas terrible pour le contributeur : L'une des grandes forces du modèle {{lang}} est justement l'absence de paramètre nommé.

Plus on a de retours, et plus je trouve pertinent de revoir l'usage du nom de modèle {{abréviation}} qui est actuellement limité (très limité) à la production de l'abréviation sans manifestation visuelle, d'usage spécifique : ce modèle devrait traiter abbr title tout court, et on pourrait lui adjoindre un paramètre de langue : faire {{abréviation|TOTE|Test/Opération/Test/Exit|en}} pour obtenir le résultat actuel des codes indiqués par Odin. Des avis ? Cordialement, --Lgd (d) 13 février 2011 à 13:36 (CET)

Je n'ai pas regardé dans le détail, mais cela me semble effectivement être la meilleure solution. Pour ce nouveau paramètre, tu auras compris qu'il faut éviter à tout prix les mélanges de paramètres nommés et non nommés . od†n ↗^blah 13 février 2011 à 14:01 (CET)

Vade retro, satanas. Cordialement, --Lgd (d) 13 février 2011 à 14:50 (CET)

Plus sérieusement, pour les modèles (exclusivement) à paramètres non nommés, j'ai le sentiment que jusqu'à trois (chiffre magique bien connu), ça va. Surtout quand le 3e paramètre sera d'un usage moins fréquent, comme ici celui indiquant la langue. On est en terrain assez solide.

Par contre, pour bouger le machin, maintenant que l'actuel {{abréviation}} a fait son chemin, ça va être un peu moins amusant. On a un {{abbr}} sur lequel on peut replier les usages de l'actuel {{abréviation}}, via une requête de bot. A moins qu'il ne faille carrément remplacer par {{abréviation discrète}} pour parer dès maintenant à toute éventualité ? J'ai assez envie de faire plutôt ça... Cordialement, --Lgd (d) 13 février 2011 à 14:57 (CET)

PS: j'aime bien {{abréviation discrète}} parce qu'à (long) terme, il faudra par exemple des {{dfn discret}} et des {{strong discret}} qui produisent le balisage HTML concerné mais sans sa mise en forme par défaut (gras, italique, etc.). Cordialement, --Lgd (d) 13 février 2011 à 15:00 (CET)

<retour à la ligne> Passage à l'acte :

• {{Abréviation}} a été renommé en {{Abréviation discrète}}
• la redirection {{abbr}} a été modifiée pour viser directement {{Abréviation discrète}}
• une requête de bot a été faite pour le remplacement des actuels appels à {{Abréviation}} et {{abbr}} par des appels à {{Abréviation discrète}}
• le futur modèle {{Abréviation}} est disponible au brouillon dans Utilisateur:Lgd/Test

Note : il faudra aussi penser à mettre à jour la documentation de {{info}} une fois ces changements effectués (et tant qu'à faire, à revérifier ses usages actuels).

Cordialement, --Lgd (d) 14 février 2011 à 09:19 (CET)

J'aurais une question : envisages-tu d'implémenter le paramètre de langue dans {{Abréviation discrète}} ? Par exemple, cela pourrait servir dans l'article National Socialist Movement (États-Unis) (NSM, SPLC et ADL). Cordialement, od†n ↗^blah 15 février 2011 à 17:15 (CET)

Oui, tout à fait. Je voulais regarder de plus près l'usage des paramètres (il y a du nommé), mais les deux modèles devraient fonctionner de manière identique. Cordialement, --Lgd (d) 15 février 2011 à 18:48 (CET)

Avez vous bien mesuré toutes les conséquences de ce renommage ? le modèle abréviation est utilisé dans d'autres modèles. Le changement de nom a généré un bug sur le modèle ouvrage le code {{ouvrage|prénom=Albrecht|nom=Dürer|titre=Géométrie|titre vo=Underweysung der Messung|trad=Jeanne Peiffer|éditeur=[[éditions du Seuil]]|année=1995|isbn=2-02012-427-0}} a pour l'instant le rendu suivant

1. REDIRECTION Modèle:Article/Auteur,

2. REDIRECTION Modèle:Article/Auteur,

3. REDIRECTION Modèle:Article/Auteur,

4. REDIRECTION Modèle:Article/Auteur,

5. REDIRECTION Modèle:Article/Auteur,

6. REDIRECTION Modèle:Article/Auteur,

7. REDIRECTION Modèle:Article/Auteur,

8. REDIRECTION Modèle:Article/Auteur,

9. REDIRECTION Modèle:Article/Auteur et

10. REDIRECTION Modèle:Article/Auteur (trad. Jeanne Peiffer), Géométrie [« Underweysung der Messung »], éditions du Seuil, 1995 (ISBN 2-02012-427-0)

Pourriez vous réparer cela. merci. HB (d) 16 février 2011 à 08:01 (CET)

Il n'y a aucun problème au niveau du modèle, c'est un bug lié aux redirections dans MediaWiki 1.17 (vers lequel la migration est en cours) et qui vient tout juste d'être détecté od†n ↗^blah 16 février 2011 à 08:33 (CET)

Ah Ok, coïncidence donc entre le changement de modèle et la migration dans mediawiki. Pardon pour l'amalgame. Mais cela semble réparéHB (d) 16 février 2011 à 09:29 (CET)

Gadget Accessibilité temporairement cassé

Bonjour,
La récente mise à jour de mediawiki va nécessiter une correction dans le Gadget Accessibilité. N'ayant pas la possibilité de m'en occuper aujourd'hui, je vous conseille de désactiver temporairement le gadget dans vos préférences en attendant que ce soit fait (le souci rencontré avec le gadget peut entraîner d'autres soucis par ricochet). Cordialement, --Lgd (d) 16 février 2011 à 14:49 (CET)

Ah! ça explique pourquoi j'avais n'importe quoi du côté des préférences ! J'ai eu peur d'avoir un virus anti wiki...Amicalement, Salix ( converser) 16 février 2011 à 19:25 (CET)

Oups, j'avais pas vu ce mot, je vois ta réponse (Lgd) sur le bistro. Tout remarche. Heureusement que t'était pas en vacances, dis ! Totodu74 (devesar…) 16 février 2011 à 20:53 (CET)

Nouvelles du front, pour résumer : sgmrbl de chez sbrmbl.

Le script du gadget fonctionne parfaitement (et sans causer aucun soucis ailleurs) quand il est chargé en tant que script personnel dans un vector.js. Il provoque une erreur jquery étonnante quand il est chargé en tant que gadget et de toutes façons, sa feuille de style est alors aux abonnés absents... Bref, je n'aime pas dire du mal des nouvelles versions de mediawiki, mais pour le coup, le fameux ResourceLoader nouvellement ajouté me semble être une... Enfin, on verra comment ça va évoluer et si une solution se profile. Pour le moment, tout le monde fait une cure de sevrage gadget accessibilité. Cordialement, --Lgd (d) 16 février 2011 à 20:58 (CET)

Chef ! oui Chef ! Ça va sûrement être corrigé dans la version suivante... Bon je vais devoir rester sur wp:en car les Caractères spéciaux ne marchent plus. Euh en fait wp:en a l'air de marcher mieux... un autre gadget en cause ou ils n'ont pas mis à jour ? Suite au prochain numéro.OK, mon vector.js n'était pas au top. --Anneyh (d) 16 février 2011 à 21:23 (CET)

Nouvelles du front suite et je l'espère fin : je suis passé 10 fois devant le problème sans le voir, mais bon, c'est corrigé à présent.

Les courageux peuvent tenter de réactiver le gadget en veillant à purger obstinément le cache de leur navigateur. Cordialement, --Lgd (d) 16 février 2011 à 22:20 (CET)

Je n'ai identifié aucun problème après qq test. Cela m'a l'air ok. Merci Lgd. Udufruduhu (d) 16 février 2011 à 22:25 (CET)

Merci pour la correction. Il reste un souci avec la flèche d'ouverture/fermeture du menu accessibilité dans le menu de gauche, la signalétique des flèches est inversée. Dodoïste ^{[ dring-dring ]} 17 février 2011 à 22:33 (CET)

Arf. Oui (curieux, ça). Merci ! je vais corriger ça. (sinon, tu as vu l"intéressant jQuery.makeCollapsible des projets en cours, pas encore déployé, à ce propos ?) Cordialement, --Lgd (d) 17 février 2011 à 22:37 (CET)

Un nouveau balisage sémantique: dfn

Bonjour,
Avec la récente mise à jour de mediawiki, quelques nouveaux éléments sémantiques ont fait leur apparition dans la syntaxe wiki, et en particulier l'élément dfn.

En HTML, il permet de baliser ce que l'on appelle « l'instantance définissante d'un terme ». Dans Wikipédia, pour aller au plus simple, son premier usage évident concerne l'habituel rappel du titre de l'article qui est systématiquement présent dans son introduction. Exemple avec l'article Accessibilité du Web :

L'accessibilité du Web est la problématique de l'accès aux services et contenus en ligne pour les handicapés et les seniors. Définie par des normes techniques établies par la Web Accessibility Initiative (WAI) du World Wide Web Consortium (W3C), elle nécessite un traitement tout au long du cycle de vie d'un site Web, par l'ensemble de ses acteurs, via des méthodes d'applications, des référentiels métiers et une démarche de suivi. Bien qu'elle soit une composante et un levier d'amélioration de leur qualité globale, le degré d'accessibilité effectif des sites Web reste actuellement très faible.

L'expression « accessibilité du web » mise en gras correspond exactement à l'usage de dfn : identifier un terme qui est défini au fil du texte dans lequel il se trouve, pour rendre indexable ce terme et sa définition. Ceci va notamment permettre d'améliorer et de généraliser le travail d'outils internes ou externes du type google define. On peut en particulier imaginer diverses utilisations dans le cadre des projets et portails thématiques.

Autrement-dit, nous devrions faire désormais :

L'<dfn>accessibilité du Web</dfn> est la problématique de... 

Ce qui donne :

L'accessibilité du Web est la problématique de...

Le style par défaut de dfn est l'italique sans graisse, ce que je viens de corriger dans Common.css pour supprimer l'italique et mettre en gras (purger le cache de votre navigateur si vous voyez de l'italique ci-dessus).

Il s'agit donc de bouger... environ 1 million d'articles pour effectuer le remplacement dans les introductions (recours aux bots, évidemment) et surtout de faire passer l'idée auprès des contributeurs (l'ajout d'une nouvelle syntaxe ayant en plus un air de HTML peut ne pas plaire).

Gros chantier, mais sans aucune difficulté technique et sans difficultés éditoriales majeures. La difficulté sera sûrement plutôt du côté de la pédagogie (mettre à jour l'aide, les pages de règles ou de recommandations sur les introductions d'articles, expliquer, expliquer, expliquer...)

Des amateurs ? Cordialement, --Lgd (d) 17 février 2011 à 08:56 (CET)

Attention : si vous voulez vous y mettre attendez quelques jours que la modification du rendu par défaut de dfn soit acquise dans tous les caches de navigateurs, sinon, des gens seront surpris de voir arriver une mise en forme contraire aux habitudes .

balise ou modèle ?

Ne serait-il pas préférable de créer un modèle idoine plutôt que d'ajouter des balises ? od†n ↗^blah 17 février 2011 à 18:47 (CET)

Je me pose la question depuis 15 jours (sans rire). Et pour le moment, je butte toujours sur le même problème : quel nommage ?

Sont exclus évidemment les noms de modèles type {{définition}}. On va charitablement épargner aux contributeurs un modèle {{Instance définissante}}, je pense... idem pour des tentatives comme {{entrée de définition}} et même {{terme défini}} : tout cela est verbeux sans réels avantages.

Dans la mesure où l'usage est bien spécifique, dans la mesure également où il y a forcément un surcroît de complexité immédiate avec l'ajout d'un nouveau modèle tout comme avec l'ajout d'un nouveau terme wiki, et enfin dans la mesure où il n'y a pas de nom de modèle à forte valeur ajoutée côté intutif, concis etc. ... <dfn>, ce n'est pas si mal. Mais toute idée géniale sera la bienvenue ! Cordialement, --Lgd (d) 17 février 2011 à 19:30 (CET)

« Reprise », « Reprise titre »... désolé pas mieux pour l'instant. Mais bon c'est tout récent, attendons déjà de voir ce que ça donne à l'usage avec cette balise. De toute façon on pourra toujours créer et déployer le modèle dans un temps ultérieur. od†n ↗^blah 17 février 2011 à 20:54 (CET)

« Reprise » etc. ne le fera pas pour le cas des pages d'homonymies mis en évidence dans la section ci-dessous. Pour tout te dire : je pense pour ma part que c'est une excellente occasion de confirmer qu'il y a certes du bon, mais aussi beaucoup de confusions et de discours hâtifs sur les choses qui s'écrivent entre deux chevrons dans WP . Cordialement, --Lgd (d) 17 février 2011 à 21:11 (CET)

Chevrons ou accolades ? Je voudrais être sûr od†n ↗^blah 17 février 2011 à 21:17 (CET)

J'ai bien dit chevrons. « Le HTML, c'est insupportable dans la source wiki », disent des wikipédiens qui utilisent quotidiennement <ref> et même <ref name="foo">, ainsi que <br /> et <gallery> ou encore <small> et <center>, voire même l'imbittable <math>... Les mêmes n'ont en revanche aucune réaction de fuite devant quelques modèles entre accolades parmi les plus pittoresques de WP : les inénarrables {{Lien Web}}, {{ouvrage}} et autres {{harvsp}}, sans compter les infobox etc. L'homo wikipedus est un être curieux, instinctif et irréfléchi, très souvent prisonnier de ses habitudes hasardeuses. --Lgd (d) 17 février 2011 à 21:20 (CET)

Désolé pour la question un peu bateau mais « [l'élément dfn] permet de baliser ce que l'on appelle « l'[instance] définissante d'un terme » : beuh, et alors ? Bon je vois ce que ça peut apporter, en donnant une logique à l'expression dfnisée, mais concrètement c'est si important ? Ça sert à quelque chose ? (il y a un peu de « c'est plus facile de taper ''' et j'ai pas envie d'ajouter encore un bouton d'édition » derrière ces questions, je l'avoue) Totodu74 (devesar…) 17 février 2011 à 21:52 (CET)

J'ai donné l'exemple ci-dessus de ce que fait google define en s'appuyant sur des techniques beaucoup plus lourdes d'indexation des définitions, faute de pouvoir mieux et de pouvoir justement s'appuyer plus sur ce balisage sémantique.

Pour donner un autre exemple : est-ce qu'un dictionnaire encyclopédique automatiquement généré à partir d'une extraction de contenus WP (dfn et dl dt dd) ne serait pas une idée stimulante ?

Ou bien un bot parsant régulièrement les articles liés à un portail et tenant à jour une page de glossaire sur le thème du projet ?

Ou encore la possibilité pour un utilisateur, via une extension Firefox par exemple, de consulter spécifiquement les définitions des termes clés liés à sa navigation dans le contenu, de les archiver, de les réutiliser ?

Ou encore, la possibilité de réaliser des imports ciblés d'un type de projet à l'autre (de WP vers wikibook, par exemple) ?

Les bénéfices sont importants et je pense assurés. Mais les saint Thomas seront déçus dans l'immédiat, certes : il s'agit de faire avancer les choses, avant de pouvoir en récolter les bénéfices .

Sinon, tu noteras que je me suis nettement moins excité sur kbd et pas du tout sur le troisème ajout sémantique de cette mise à jour, qui s'appelle samp : ce n'est pas tout à fait innocent . Cordialement, --Lgd (d) 17 février 2011 à 22:11 (CET)

Ayé, j'ai compris. En zoologie avec la sale manie^{[non neutre]} des titres en latin, Wikipédia ne figure parfois même pas sur la première page de résultats google. S'il n'y avait pas les autres usages, j'aurais presque demandé si on ne pouvait pas créer une zone en bas de page avec les sujets de l'article, dfnisés. Un genre de regroupement de tags. Ça aurait pu servir au référencement (ou indexage ? je ne suis pas très coutumier des termes), mais pas aux autres exemples que tu donnes.

Pour ce qui est du petit nom, franchement <dfn> est plus court à écrire que {{groupe nominal qui est le sujet de l'article}}... Peut-être un {{dfn}} pour simplifier ? Une fois que la répansion est faite je ne pense pas que les lecteurs newbies seront perdus, dfn n'est pas moins intuitif que ''', juste plus long à taper.

Sinon, j'imagine que tu t'attends à quelques réticences si tu demande un peu son avis à la communauté ? Totodu74 (devesar…) 17 février 2011 à 22:23 (CET)

Ouàlà... Dès que le contributeur s'y met avec un peu de bonne volonté, il découvre des usages et des utilités .

Pour le reste : disons que je n'envisage pas de faire bouger la quasi-totalité des articles de WP pour y ajouter un « bidule » sans quelques grincements de dents, oui, certes. Mais en fait, je passe par ici pour commencer parce que c'est un endroit accueillant, ouvert, sympathique, habitué à faire face à la nouveauté, plein de gens pédagogues et toujours source de bonnes idées. Un bon endroit pour réfléchir ensemble et commencer à ficeler le paquet pour le proposer à tout le monde si cela s'avère pertinent . Cordialement, --Lgd (d) 17 février 2011 à 22:31 (CET)

L'élément crucial qui fait pencher en faveur du choix d'un modèle, c'est la page de documentation. Une syntaxe wiki n'a pas de documentation facilement disponible, car les pages d'aides sont tout sauf organisées et utilisables. Reste donc uniquement la page de documentation du modèle, qui est présente en contexte (gros plus) et qui est bien entrée dans les usages. Je sais pas pour les autres, mais je ne lis plus de pages d'aides depuis quelques années. Par contre, je lis très régulièrement les pages de documentation de modèle que je ne connais pas ou que je ne comprends pas.

Donc, entre <dfn> qui est imbittable, et un nom de modèle un peu obscur mais tout de même plus explicite ({{terme défini}}, par exemple ?), je propose de miser sur le modèle.

On me permettra un boutade impossible à manquer : nos développeurs sont quand même de gros boulets, à ajouter du pseudo HTML dans le parseur. « Ah bon, Wikipédia c'est trop compliqué à éditer ? Ben c'est pas de ma faute hein, non. » Lamentable... Dodoïste ^{[ dring-dring ]} 17 février 2011 à 22:09 (CET)

Bon, si on va par là, on va droit vers un doublon de modèle {{terme défini}} et {{dfn}} à côté d'usages directs de dfn, tout comme nous avons déjà ou allons avoir dans leur version finale {{abbr}}, {{abréviation}} et abbr. L'incertitude me noie littéralement face à la supposition que cela améliore les choses, mais de toutes façons, l'opinion publique va l'emporter et on (je) fera avec. Sinon, pour ce qui est de la doc, c'est l'aide de WP qu'il faut améliorer, pas le code qu'il faut compliquer pour compenser une aide déficiente .

Pour la boutade, quand même, elle est mal venue : très concrètement, tu aurais développé quoi ? Cordialement, --Lgd (d) 17 février 2011 à 22:20 (CET)

OK, faisons une mise en situation. Un contributeur voit une syntaxe obscure de plus comme abbr, que fait-il ? Si il va chercher dans l'aide, la seule page connue à ce sujet est Aide:Syntaxe, et elle ne mentionne pas ce genre de syntaxe (pas plus que center, span, div, table, blockquote, et j'en passe et des meilleurs). Beaucoup ne vont même pas espérer trouver une réponse dans ces pages. Pas de documentation, pas de compréhension. Donc, le modèle est utilisé pour l'effet visuel qu'il produit, étant le seul élément facilement compréhensible.

Pour le doublon, il n'y en aura pas. Il s'agit de ne pas utiliser dfn, en faveur du modèle. C'est une pratique commun sur Wikipédia, en général la syntaxe wiki est préférée au pseudo HTML. Italiques, tableaux, listes... Et puis, pour les citations, nous avons déjà le cas des modèles de citation qui remplacent la syntaxe HTML. Et probablement d'autres que j'oublie. Rien de nouveau sous le soleil. Et nous aurons probablement des définitions de termes étrangers, donc un modèle {{terme défini étranger}}, comme pour les citations ?

Améliorer les pages d'aides, tu sais bien que c'est totalement irréaliste, j'ai même pas le temps de mener à terme mon essai sur Wikisource.

Pour ma boutade : à la place des développeurs, je me serais fixé d'autres priorités. On attend toujours le déploiement de la fonctionnalité reference folding, soit la possibilité d'afficher/masquer le contenu des références lors de l'édition. Parmi les travaux de l'ergonome employée, c'est le seul changement qui avait un impact significatif (selon ses propres propos), et il n'a pas été implémenté faute de main-d’œuvre. Simplifier l'édition, au lieu de persévérer dans un démarche qu'on sait problématique. Dodoïste ^{[ dring-dring ]} 17 février 2011 à 22:55 (CET)

Tu oublies beaucoup de choses. Sans entrer dans le détail (il est tard, j'avoue), tu oublies par exemple et en particulier le rôle clé du copié-collé. Tu ne dis rien du fait que les contributeurs utilisent quotidiennement certaines syntaxes ala-HTML (personne n'a proposé de créer un modèle {{center}} que je sache ? Et j'avais oublié <big> qui est carrément assez spontané dans les bacs à sable). Rien non plus sur un aspect essentiel : une syntaxe est adoptée, quelle qu'elle soit, quand son usage est précis, facilement mémorisable, étroitement ciblé, et son détail minimal (c'est le cas ici, il n'y aura aucun besoin supplémentaire pour gérer la langue, {{lang}} le fera très bien). Enfin, tu conclues en considérant qu'améliorer les pages d'aides est irréalisable, ce qui est curieux. Cela fait beaucoup de considérations un peu lointaines pour ce qui nous occupe .

Attention : je ne dis pas que l'usage d'un tag ala-HTML de plus sera aisé ni qu'il est la voie obligée. Encore une fois, si la vox pupuli est finalement de créer des modèles {{terme défini}} parce que c'est explicite) et {{dfn}} (parce que c'est plus rapide à saisir), on fera évidemment comme ça. Mais je n'y vois absolument aucun gain et plutôt l'incitation à ne pas bouger les bonnes choses à bouger, comme l'aide . L'idée de commencer par le tag et d'aboutir au modèle si la demande se manifeste est assez pertinente, je pense. Cordialement, --Lgd (d) 17 février 2011 à 23:31 (CET)

Je ne dis rien au sujet de center par exemple, parce que tu en as parlé avant, et qu'il n'y avait rien à ajouter.

Le copier-collé d'une syntaxe, ça marche très bien oui. Mais là, si on veut parler d'un usage pertinent de la syntaxe, et pas d'un usage tout court, le copier-coller n'est pas la question. La question est « que fait de « dfn » » ? Le copier-coller des listes de définitions pour en faire des faux titres de section marche très bien, que je sache. Ben là, c'est fichtrement pareil.

Pour l'aide, tu devrais savoir qu'une aide contextuelle, comme la page de documentation, sera toujours meilleure qu'une page d'aide située très très loin du contexte.

Je n'ai pas d'avis entre {{terme défini}} et {{dfn}}, l'important étant surtout la page de documentation.

Quand tu parles de <big> « spontanés », soit tout le monde est devenu codeur dans mon dos (et il faut que je me retourne), soit c'est du grand n'importe quoi. On a pas mal d'éditeurs qui en font, oui, mais en proportion ils représentent une part négligeable des éditeurs. Là, on parle d'utiliser une nouvelle syntaxe sur tous les articles, rien que cela rend la comparaison entre <big> et <dfn> impossible.

Donc, rien à voir avec des oublis de ma part, ni la vox populi, je sais très bien ce que je dis. Ta dernière tentative de ce genre, soit proposer aux éditeurs d'utiliser directement <abbr>, a été un échec assez flagrant à mon avis. Hormis quelques utilisations dans des modèles, et quelques arrachés de l'atelier qui l'ont ajoutés dans des articles, il ne s'est rien passé. Et c'était prévisible. Pour tout dire - et j'espère que tu y verras plus de la franchise qu'une critique personnelle - je ne pense pas que tu aies la bonne sensibilité en matière d'ergonomie. Mes excuses. Je supprime cette idiotie puérile de ma part, plus à mettre sur le compte d'une fatigue et d'une lassitude à minuit qu'autre chose. Dodoïste ^{[ dring-dring ]} 18 février 2011 à 00:10 (CET)

J'adore quand on parle de bonne sensibilité en matière d'ergonomie dans WP. C'est bien beau de parler entre spécialistes qui Vous pratiquez toutes sortes de codes comme vous pratiquez la langue française, mais n'oubliez pas les pauvres péquins qui n'ont que leur bonne volonté. Il est pour moi évident d'écrire <small>XIX</small>^e après J.-C. (je sais que <smal> va mettre les chiffres romains à la bonne taille que <sup> va mettre l'abréviation en exposant et même que <nowiki></nowiki> va éviter que MediaWiki applique le code pour les besoins de l'exemple) alors que je n'ai toujours pas compris la logique de {{je-ne-sais-quels-modèles-pour-les-siècles}} donc que je ne risque pas de les mémoriser et encore moins de les utiliser. Alors pour moi ce sera toujours plus clair d'utiliser <dfn> que n'importe quel modèle. Chacun sa logique et la mienne vaut bien la votre. Cordialement -- • Hamelin ^{[ de Guettelet ]} • 18 février 2011 à 04:15 (CET) Ah, au fait ! Puisque l'on parle modèle ; l'utilisation de modèle rend invisible le mot modélisé quand on utilise la fonction popup, j'ai ainsi laissé passer pendant plusieurs mois une erreur de date dans une modif jusqu'au moment où je me suis effectivement rendu sur l'article.

Questions sur les usages de dfn

--CQui bla : 17 février 2011 à 16:59 (CET) Si un meme article traite de plusieurs termes, comme le celebre chicon/endive, est-ce que tous les termes doivent etre dfnisés ? Je ne sait pas si je pose mon commentaire au bon endroit. N'hesitez pas a le deplacer

Question bienvenue, au contraire, puisqu'il faudra préciser les usages (j'ai volontairement choisi le plus évident et le plus fortement prioritaire pour amorcer l'idée)

Dans l'absolu, oui : dfn peut être utilisé pour différents termes dans un article. Mais les conditions de pertinences sont assez délicates :

• Il faut impérativement que le terme soit employé et défini dans un paragraphe spécifique. Donc, notamment pas dans un item de liste à puce ou numéroté, cas pour lesquels on serait en fait plutôt en présence d'un besoin d'une liste de définition « ; » et « : ».
• Il faut se dire que ce paragraphe doit pouvoir être extrait de l'article et présenté comme une définition du terme, à lui seul et sans qu'il ne contienne d'informations parasites.
• Souvent, un terme va être explicité dans le corps d'un article, mais il a déjà lui-même son propre article et donc en quelques-sortes « son dfn privilégié » dans l'introduction de celui-ci.

Sans exclure ces utilisations, il me semble prudent au moins dans un premier temps de s'en tenir à l'usage le plus simple. Cordialement, --Lgd (d) 17 février 2011 à 18:35 (CET)

Bonjour, comment ça se comporte dans le cas des termes homonymes ? --Amicalement, Salix ( converser) 17 février 2011 à 19:07 (CET)

Ah, très bien vu (Modèle:Respect).

Là, en effet, on a des termes (ceux qui ne sont pas liés et qui n'ont pas d'articles, pour rester sur l'idée du « dfn privilégié ») dont c'est une forme de définition qui relèverait du dfn. On a aussi un usage massif et une règle pas trop compliquée à proposer : si l'entrée n'a pas d'article, dfn. Si l'entrée a un article, c'est un lien et donc pas de chocolat dfn. Qu'en dites-vous ? Cordialement, --Lgd (d) 17 février 2011 à 19:21 (CET)

Rectification : dans les pages d'homonymie, les entrées ne sont pas dans des paragraphes (mais dans des items de liste). Il faudrait ajouter des <p>...</p> pour que l'usage de dfn réponde aux exigences actuelles en HTML5, ce qui entraînerait une complication excessive. Donc, finalement, pas de dfn dans les pages d'homonymie au moins dans un premier temps. Cordialement, --Lgd (d) 22 février 2011 à 08:47 (CET)

Tiens, ça faisait longtemps que j'avais posé une question : au hockey, on privilégie les termes francophones et on a donc souvent le terme français et le terme anglais dans l'intro. Faut dfniser les deux ? (Un exemple : Les Bruins de Boston (en anglais Boston Bruins) sont une franchise professionnelle de hockey sur glace basée à Boston dans le Massachusetts aux États-Unis). --'toff ^[discut.] 17 février 2011 à 23:48 (CET)

Je sentais venir le coup, mais je voyais ça sur le flanc « occitan ou arpitan » plutôt que sur un exemple sérieux .

dfn est un élément NPOV, il n'a aucun souci à ce que l'on fasse dans une introduction quelque-chose comme:

L'<dfn>endive</dfn> ou <dfn>chicon</dfn> (<dfn>{{lang|la|''Cichorium intybus convar. foliosum''}}</dfn>) est...

C'est au contraire très bien. Seul souci : il va falloir que tout le monde accepte que tout le monde soit en gras . Cordialement, --Lgd (d) 18 février 2011 à 00:07 (CET)

Un contributeur malpoli passé sous IP tient beaucoup à rectifier mon erreur, que j'aimerai bien pouvoir assumer . Il faut donc écrire:

L'<dfn>endive</dfn> ou <dfn>chicon</dfn> (<dfn>{{lang|la|''Cichorium intybus'' convar. ''foliosum''}}</dfn>)

--Lgd (d) 18 février 2011 à 00:56 (CET)

Ca tombe bien, on avait déjà opté pour l'option « les deux en gras » avant l'arrivée de dfn (j'avais oublié de le mettre dans mon exemple) --'toff ^[discut.] 18 février 2011 à 16:45 (CET)

Petite question pour un article possédant une section qui détaille les noms possibles. Ca arrive lorsque par exemple une dizaine de noms sont utilisés couramment pour un concept (désolé je n'ai pas d'exemple sous la main), et où seuls les deux ou trois plus courants sont cités en intro, les autres étant relégués plus loin pour éviter d'alourdir l'intro. Ces termes moins courants devront-ils être marqués comme définissant le sujet ? Si oui, ce qui me semblerait logique, ils seraient tous en gras, ce qui serait inhabituel hors de l'intro. Cordialement, Freewol (d) 21 février 2011 à 17:13 (CET)

C'est le cas délicat. Ce serait parfois pertinent, mais seulement si les règles sémantiques d'usage de dfn sont effectivement respectée : le paragraphe où se trouvent ces termes contient effectivement la définition. Autrement-dit, celle-ci serait en double dans l'article (premier paragraphe d'intro + section ou autre paragraphe indiquant les synonymes). Cela me semble donc à éviter. Cordialement, --Lgd (d) 22 février 2011 à 19:18 (CET)

Avançons : eine kleine sondache

Apparemment, la question clé pour l'instant serait :

• proposer aux contributeurs d'utiliser la syntaxe HTML : <dfn>Lorem ipsum</dfn>
• proposer aux contributeurs d'utiliser un modèle : {{terme défini|Lorem ipsum}}

Vos avis ? Cordialement, --Lgd (d) 20 février 2011 à 14:58 (CET)

Syntaxe HTML

1. Vu la complexité de la syntaxe html, je ne vois vraiment pas quelle est la plus-valu d'un modèle. Un simple bouton supplémentaire dans la barre d'outil de la fenêtre d'édition me semble suffisant. Udufruduhu (d) 20 février 2011 à 15:08 (CET)
2. comme Udufruduhu, en plus il me semble que ca peut être rajouter rapidement dans les raccourcis sous la fenêtre d'édition--Chandres (✉) 20 février 2011 à 15:52 (CET)
3. Faire un modèle pour faire un modèle, quel intérêt ? --'toff ^[discut.] 20 février 2011 à 22:20 (CET)
4. --TaraO (d) 22 février 2011 à 20:14 (CET)

Modèle

1. --CQui bla : 22 février 2011 à 16:46 (CET) Si il n'y a pas de probleme technique, ma preference :

   L'{{dfn|endive}} ou {{dfn|chicon}} ({{dfn|''Cichorium intybus'' convar. ''foliosum''|la}}) est...

   <CQui bla> Oublié de preciser, il serait peut-etre interessant d'ajouter la langue dans le modele, vu que les variantes d'un titre sont souvent dans une autre langue, un meilleur exemple

   {{dfn|La Haye}} ({{dfn|nl|Den Haag}} ou {{dfn|nl|'s-Gravenhage}} en [[néerlandais]]...

   Personnellement je prefere les modeles au code, je trouve plus propre et plus facile, par exemple, je ne connaissait pas <pre>, si cela avait été {{pre}} j'aurrai eu un lien vers la documentation du modele en dessous de ma fenetre d'edition pour aller voir d'un clic millieux a quoi cela sert reelement, si il y a des parametes possible, etc. </CQui bla> le 23 février 2011 à 14:57 (CET) ajouté le modele abreviation pour verifier...

   Juste une remarque à cette occasion (je ne m'acharne pas en faveur des syntaxes HTML, ce n'est pas la question) : il serait facile et certainement utile de donner accès pour la syntaxe HTML à des pages similaires à celles des modèles côté documentation, notamment dans la fenêtre d'édition. Cela aiderait tout le monde, je pense et ce serait assez facile (un zest de messages systèmes, un doigt de javascript, quelques nouvelles pages d'aides très ciblées permettant de faire des {{article détaillé}} dans l'aide globale sur la syntaxe). Je rêve aussi d'une bête page d'index alphabétique des pages dédiées à chaque syntaxe... Je me le note, toute cette discussion nous aura au moins apporté cela indépendamment de l'avenir de dfn . --Lgd (d) 23 février 2011 à 15:05 (CET)

Bilan

Personne n'a hurlé, c'est déjà un premier pas . J'ai commencé à travailler sur une amorce de PDD sur le sujet (si, si, il faudra en passer par là) : Utilisateur:Lgd/brouillon dfn, sans vraiment encore être tout à fait décidé à la lancer par suite. N'hésitez pas à donner vos avis, on va ratisser consulter très large avant un éventuel passage à l'acte (rappel : il faut bouger tout le million et des bananes moins quelques pommes d'articles de wikipédia si ça se fait). Cordialement, --Lgd (d) 6 mars 2011 à 11:40 (CET)

Pour le moment, la question à propos de Utilisateur:Lgd/brouillon dfn est : « Si on pose la question, le contenu de cette page est-il très grosso-modo la bonne manière de le faire pour que les gens comprennent de quoi il s'agit ? ». Cordialement, --Lgd (d) 6 mars 2011 à 11:46 (CET)

C'est déjà bien pour expliquer les cas les plus simples et (IMHPO) mesurer la crainte ou la frilosité face au changement parmi la communauté. Pour ce qui est du modèle {{dfn}} tu propose une syntaxe Le {{dfn}}machin{{dfn}} est... : ce n'est pas plutôt Le {{dfn|machin}} est... ? Totodu74 (devesar…) 6 mars 2011 à 12:06 (CET)

Sorry, j'étais en train de bouger Utilisateur:Lgd/brouillon dfn. C'est plutôt cet état, avec le {{Terme défini|...}}, bien-sûr. Cordialement, --Lgd (d) 6 mars 2011 à 12:17 (CET)

Ah, zut, c'était pas {{Terme défini|...}}, c'était {{dfn|...}} qui était dans l'avis plus haut. Sgmbl. --Lgd (d) 6 mars 2011 à 12:20 (CET)

Le contenu me semble très clair, même si à ta place j'irais plutôt chercher des avis en dehors de l'atelier accessibilité pour que ce soit plus représentatif .

Une remarque tout de même sur les choix que tu proposes à la fin : je vois d'ici le débat se focaliser sur le choix entre <dfn> et {{dfn}} ; ne vaudrait-il pas mieux en faire deux questions (« pour ou contre l'utilisation de la nouvelle fonctionnalité ? », puis « balise ou le modèle ? »)… ou un Condorcet  ?

Amicalement — Arkanosis ^✉ 6 mars 2011 à 19:10 (CET)

Bonjour, en tant que naïf de service je crois que j'ai globalement tout compris. ça ne me gènerait pas d'utiliser la syntaxe html s'il y avait ça dans les caractères spéciaux à cliquer. Pour le mommage du modèle, je pense en renvanche qu'un {{terme défini|Lorem ipsum}} serait un meilleur substitut, plus compréhensible pour le contributeur occasionnel qui verra ça dans le code en mode modification. Maintenant je m'interroge encore sur ce qu'il convient de faire quand 1/ il ne s'agit pas d'un mot mais d'une expression (ou un titre) 2/ quand il y a plusieurs mots clé (ex. Colobus polykomos). --Amicalement, Salix ( converser) 6 mars 2011 à 20:12 (CET)

Merci pour vos retours, n'hésitez pas.

Ce n'est qu'un brouillon : pour un passage en PDD, il y aura obligatoirement une période de discussion préalable, qui permettre justement d'élargir le champ des avis. Cordialement, --Lgd (d) 7 mars 2011 à 04:11 (CET)

Juste pour signaler l'état d'avancement : après vos avis sur un premier jet de contenu PDD et quelques demandes d'avis sur le fond, je viens de déposer une demande d'avis aux dresseurs de bots (qui seront très concernés). Sauf imprévu, la phase de discussion de la PDD devrait s'ouvrir d'ici une petit semaine. Cordialement, --Lgd (d) 20 mars 2011 à 09:11 (CET)

Et du coup, pour l'alternative tu restes sur {{Terme défini|...}} plutôt que {{dfn|...}} ? Perso je m'en fous, je ne suis pas pour l'option modèle, mais si {{Terme défini}} peut paraître plus intuitif, certains votants pourraient aussi voir à l'économie de caractères. À toi de voir si tu rajoutes une possibilité de vote prédéfinie en plus, ou si la subdivision de l'option modèle n'est pas forcément souhaitable. Au fait tu n'as donc pas trouvé plus sexy que WCAG Comme dit précédemment, j'avais déjà trouvé des cas de mauvais référencement pour des articles de bio pourtant importants, je peux essayer de t'en retrouver un si tu veux. Totodu74 (devesar…) 20 mars 2011 à 11:55 (CET)

Je ne reste nulle part sur cette question du modèle (sauf pour mettre quelque-chose dans le brouillon de PDD à ce stade). A vrai dire, plus le temps passe, et moins je suis quelque-part sur cette question, avec le souci qu'elle peut à elle seule plomber le tout auprès des contributeurs. L'idée de disperser et de rendre confuse la PDD avec des modèles alternatifs ne me semble pas très attirante. Mais finalement, c'est peut-être la discussion préliminaire dans le cadre de la PDD qui permettra d'aboutir de ce côté ? (je crains aussi un peu ces discussions préliminaires formellement obligées, qui sont une excellente occasion de noyer le bébé, mais bon, on verra ce qui en sortira).

Tu auras droit à ma reconnaissance éternelle si tu me trouve des exemples « sexys »  !

(N'hésitez pas à refaire un tour sur Utilisateur:Lgd/brouillon dfn pour améliore : ça n'est surtout pas « ma » PDD ).

Cordialement, --Lgd (d) 20 mars 2011 à 12:04 (CET)

D'ac pour le terme défini/dfn, attendons les discussions préliminaires. J'ai regardé pour les exemples (ce cas m'as fait rire mais bref), je vois que dans ton brouillon tu conclues par un « [F]ournir [à Google define] un balisage pertinent permettrait d'éviter ce genre d'erreurs. » : C'est peut-être maladroit d'expliquer qu'on va modifier un million d'articles pour aider Google non ? Je pensais plutôt axer sur les problèmes de référencement. Par exemple tu recherches « éponge » et Porifera ne figure même pas dans les résultats Google. Un <dfn> sur éponge dans cet article solutionnerait je crois le problème. (rapidement, je dois m'absenter pour le reste de la journée) Totodu74 (devesar…) 20 mars 2011 à 12:23 (CET)

Zut, Google a bougé et pas en plus clair pour ses utilisateurs. Entre Définir boeuf, Définir:Boeuf et define:boeuf, ce n'est pas la même fonctionnalité aujourd'hui, il va falloir corriger le brouillon.

Sinon, oui, il faut moins parler de Google tout en retenant son exemple, c'est un des soucis.

J'aime le coup de l'éponge . Il faudra peut-être un peut plus de temps que la semaine pour peaufiner tout ça (je ne serait pas beaucoup là pendant les 3 semaines à venir).

Cordialement, --Lgd (d) 20 mars 2011 à 12:33 (CET)

C'est parti, une PDD saignante pour le 12, une !

Bonjour,
Profitant d'un bref répit entre deux crises de procrastination, j'ai lancé la discussion préalable de Wikipédia:Prise de décision/Adoption du balisage dfn dans les introductions d'articles à partir du brouillon amélioré grâces aux retours apportés ici et là. Ce n'est pas encore tip-top côté contenu de la PDD, mais après tout, la phase de discussion est là aussi pour ça . Cordialement, --Lgd (d) 3 avril 2011 à 12:06 (CEST)

Mise à jour des modèles d'abréviation

Bonjour,
Avec l'aide précieuse d'Odin, les modèles d'abréviations ont pu être améliorés :

• {{abréviation}} permet de faire une abréviation soulignée (donc au cas par cas dans des articles ou certains modèles) et si besoin d'en indiquer la langue : {{abréviation|WAI|Web Accessibility Initiative|en}} donne WAI. On peut aussi utiliser le raccourci {{abbr}}.
• {{abréviation discrète}} permet de faire une abréviation non soulignée (donc dans les modèles très fréquemment répétés comme les abréviations liées aux références bibliographiques) et si besoin d'en indiquer la langue : {{abréviation discrète|WAI|Web Accessibility Initiative|en}} donne WAI.

Cordialement, --Lgd (d) 20 février 2011 à 14:53 (CET)

bonjour

donc on remplace les « ! scope="col" style="background: #e0e0e0;" | <abbr title="Parties jouées"> PJ</abbr> » par « ! scope="col" style="background: #e0e0e0;" | {{abréviation|PJ|Parties jouées}}  » dans les stats (par exemple hein) ? --TaraO (d) 21 février 2011 à 09:29 (CET)

Ma relève "access." au hockey est assurée --'toff ^[discut.] 21 février 2011 à 19:17 (CET)

taille maximale pour une page ?

Bonjour. Petite question : l'accessibilité n'impose-t-elle pas une taille maximale, en octets, pour une page ? Non seulement les pages très lourdes sont difficiles à modifier (voire impossibles), ce qui est un problème propre à Wikipédia, mais même en lecture elles mettent à mal les navigateurs sur les PC les moins puissants. Le navigateur peut prendre 100 % du processeur pendant de nombreuses secondes, ce qui rend difficilement utilisable le PC pendant ce temps. Je me demande donc s'il existe des recommandations à ce sujet sur le Web. Cordialement, Freewol (d) 20 février 2011 à 23:00 (CET)

Cela ne relève pas des problèmes d'accessibilité, mais la question est traitée à d'autres points de vue (performances, ergonomie, adaptabilité au media mobile). Aujourd'hui, elle se traduit rarement par une limite arbitraire et globale en octets qui n'est guère pertinente car le poids brut des données à télécharger n'est pas le seul facteur décisif.

Les chartes qualité comportent plutôt différentes recommandations que l'on retrouve en partie sur WP : affiner l'architecture de l'information (ici, articles principaux et détaillés), veiller à une utilisation pertinente des images (WP:IMG ici), optimiser la gestion du cache navigateur et le traitement des scripts (ce qu'est censé faire la récente mise à jour de mediawiki)... Cela dit, il est vrai que le respect de certaines de ces bonnes pratiques n'est pas toujours assuré ici dans certains articles « monstres ». Il faut aussi tenir compte le cas échéant de la multiplication de scripts en option pas toujours d'une utilité flagrante (monobook, vector, gadgets). Cordialement, --Lgd (d) 20 février 2011 à 23:10 (CET)

D'accord, merci pour la réponse. Au sujet de la taille en octet, je remarque quand même que les articles cités en tête de la liste Spécial:Pages longues ont tous à peu près le même effet sur un PC peu puissant lorsqu'on essaie de les charger, et ce même sans être identifié, c'est à dire avec un javascript minimal (j'imagine) : le PC est inutilisable pendant de nombreuses secondes, il semble "planté". Je n'ai jamais rencontré ce comportement sur un autre site que Wikipédia, d'où ma question. Je me demande si pour le coup une astuce permettant d'afficher une page plus légère en premier abord, puis la page complète si on clique quelque part, ne serait pas pertinent (par contre est-ce possible techniquement, aucune idée). Cordialement, Freewol (d) 21 février 2011 à 11:13 (CET)

Certes, une page de plus d'un Mo de contenu textuel, comme certaines qui sont en tête de Spécial:Pages longues vont inévitablement faire ramer une connexion ou un navigateur moins performants de par le seul poids du HTML à télécharger. Mais à part ces cas extrêmes, il y a plutôt un lien indirect entre la quantité de source wiki (ce que mesure Spécial:Pages longues, qui ne mesure pas exactement les pages effectivement « lourdes » finalement pour le visiteur) et la charge potentielle que cela entraîne en nombres d'images et de scripts à traiter par le navigateur. Par exemple, plus il y a de contenu textuel, plus il y a en général de titres de section, et donc plus il y a d'appels à la fonction javascript (exécutée aussi pour les IP) qui déplace le lien « [Modifier] » de manière à ce qu'il s'affiche immédiatement à droite du libellé des titres plutôt qu'aligné sur la marge droite des pages (Fonction d'une utilité essentielle, n'est-ce pas ? ).

Pour ce qui est d'une version « allégée », ce serait aisément faisable via les « habillages » (skins) de WP et la possibilité d'appeler un habillage directement via l'url du lien (sans modification des préférences du compte qui resterait donc sur vector ou monobook etc.) On pourrait imaginer un « vector allégé » : ce serait une idée très intéressante à creuser. Cordialement, --Lgd (d) 21 février 2011 à 12:13 (CET)

Ah je comprends, le poids en octet d'une page fait qu'elle prendra du temps à charger, en fonction du débit de la connexion, mais ce n'est pas ça qui prend 100 % du processeur. Ça, c'est l'habillage (javascript commun et personnalisé, redimensionnement des images peut-être, feuille de style css ... ?). Du coup effectivement, les pages longues en octets ne sont pas forcément celles qui posent le plus problème, même si en pratique j'ai remarqué qu'elles en posaient quand même. L'idée de pouvoir charger un habillage plus léger par l'url me semble plutôt bonne, même si elle ne résoudra pas le soucis du lecteur qui arrive sans se douter de rien sur une grosse page qui lui bloque son PC pendant un moment. Tout au plus pourra-t-il pour une prochaine fois enregistrer un favori avec l'habillage plus léger.

L'idéal serait de pouvoir dans les paramètres du logiciel Wiki "si une page va poser problème au chargement, forcer un habillage léger pour tous", mais je suis à peu près persuadé que c'est infaisable (comment savoir quelle page va poser problème ? a la limite, si c'était possible de les mettre dans une catégorie manuellement, mais bon ça me semble tiré par les cheveux). Merci pour les indications en tout cas. Cordialement, Freewol (d) 21 février 2011 à 17:05 (CET)

--CQui bla : 22 février 2011 à 17:12 (CET) Il faudrait eventuellement l'option Texte brut seulement...

Je vais peut-être dire une bêtise, mais, quand ma liaison rame, Google mail, par exemple, bascule automatiquement sur un affichage simplifié et me propose en option une mise en forme plus complète. Wikipédia ne peut pas faire ça ? --Amicalement, Salix ( converser) 22 février 2011 à 18:53 (CET)

Wikipédia le fait déjà mais uniquement pour une fonction javascript très précise : l'ajout à la liste de suivi par le lien sur l'onglet étoile. Si ta connexion est trop lente pour la requête particulière faite par cette fonction (une requête AJAX, ie sans rechargement complet de la page), le système se rabat sur un mode moins exigeant qui te fait passer par l'affichage d'une page intermédiaire à partir de laquelle tu retournes ensuite à la main à ton article initial. Mais ce ne serait pratiquement pas généralisable à d'autres fonctions javascript de l'interface (contrairement à Gmail, il y a peu d'AJAX dans WP par défaut en fait), et ce ne sera pas applicable aux images. Cordialement, --Lgd (d) 22 février 2011 à 19:12 (CET)

{{Langue}}

Bonjour. Sur le Projet:The Beatles, on utilise souvent le modèle {{langue}}, et un questionnement est survenu en ce qui concerne les crochets de wikification. Y a-t-il un problème à écrire:

{{langue|en|[[article]]}}

ou faut-il s'en tenir à ceci:

[[article|{{langue|article}}]]

Le premier choix sauve sur les octets lorsqu'il est utilisé en grand nombre, et ne nécessite pas de doublier le lien. Mais cela empêcherait-il un programme qui lit un article de bien fonctionner? Merci d'avance. — Mr. Frank | | Boîte aux lettres | le 4 mars 2011 à 18:36 (CET)

{{langue|en|[[article]]}} peut être utilisé sans problème. Cordialement, --Lgd (d) 4 mars 2011 à 21:53 (CET)

Merci beaucoup! — Mr. Frank | | Boîte aux lettres | le 5 mars 2011 à 01:49 (CET)

Merci Lgd, mais peux-tu m'expliquer pourquoi cette solution bien plus légère n'est pas mentionnée dans la doc, qui préfère orienter les utilisateurs vers une lourdeur apparemment inutile ? Et aussi, pourquoi les apostrophes doivent être à l'extérieur ? Zakke (d) 5 mars 2011 à 11:13 (CET)

La question est plus compliquée dans le détail. Notamment :

• Parce que Mediawiki a évolué techniquement depuis la rédaction initiale de la BP (la récente mise à jour a un impact potentiel sur cette question en modifiant la gestion des attributs title des liens et ceux-ci sont un des éléments du problème) ;
• Parce qu'il faut parvenir à trouver une recommandation simple pour les contributeurs qui couvre en fait des cas de figures plus variés et assez complexes (trop pour détailler utilement dans les bonnes pratiques) ;
• Parce que Mediawiki ne permet de toute façon pas de produire le code qui serait vraiment pertinent (en gros : lang devrait pouvoir s'appliquer comme paramètre direct du lien) ;
• <Bref moment de solitude amusé /> Parce que je n'ai que deux bras et malgré tout un temps limité à consacrer à améliorer et mettre à jour assez solitairement les bonnes pratiques d'accessibilité . Plus sérieusement, peu de gens se rendent compte (et c'est tout à fait compréhensible) que ces BP constituent beaucoup plus qu'une simple reproduction à la lettre de règles immédiatement applicables. C'est une méthode d'application d'une norme complexe, chose qu'on élabore d'habitude à plusieurs experts et en consacrant énormément de travail sur les multiples implications de chaque règle.

Je vais voir si je peux faire le point et mettre à jour les BP ce WE ou la semaine prochaine là dessus (j'aurais peut-être l'occasion de poser la question à quelques collègues, mais ils sont un peu frileux à s'occuper de ces questions de syntaxe WP, assez déroutantes). Pour la question des apostrophes, je tâche de regarder ça aussi. Cordialement, --Lgd (d) 5 mars 2011 à 12:21 (CET)

Merci pour ces explications, et bonne continuation dans ta tâche. Zakke (d) 5 mars 2011 à 12:37 (CET)

Graphiques : alternatives aux timelines

Bonjour. J'avais déjà parlé ici d'une alternative aux timelines par un tableau. Pour certains graphiques simples en forme de barres, une solution est en train d'être peaufinée sur l'atelier accessibilité anglophone. Le résultat est sur le modèle Template:Georgia, Largest cities, 2009 Census -- Bar Graph - me tapez pas pour le nom imbittable, j'ai pas choisi. Je crois avoir déjà vu ce genre de solutions quelques fois, donc c'est possible qu'on n'invente pas la roue.

Personnellement, j'ai transformé le premier jet en un tableau de données standard et accessible. Les commentaires sur cette technique sont bienvenus. Si cela convient, on pourrait répandre cette méthode en remplacement d'un bon nombre de timelines. Bien à vous, Dodoïste ^{[ dring-dring ]} 13 mars 2011 à 17:17 (CET)

<En coup de vent /> Deux exemples de solutions possibles explorées ici :

• Modèle:Pyramide des âges pour un graphique fait avec un tableau de données mis en forme via CSS ;
• Mauldre pour un accès dans le contexte de la timeline au tableau des données chiffrées qui en est l'alternative.

Cordialement, --Lgd (d) 13 mars 2011 à 18:50 (CET)

J'aime bien le modèle de pyramide des âges, il va sûrement m'être utile par la suite. Merci. :-) Dodoïste ^{[ dring-dring ]} 14 mars 2011 à 00:10 (CET)

Pour compléter : cette technique du tableau maquillé en graphique est séduisante et peut effectivement être parfois préférable aux timeline actuelles, mais en étant bien conscient qu'on est à la limite de l'information générée via CSS, avec certains des défauts habituels que cela suppose. En particulier, le graphique ne peut pas être enregistré ou copié collé (du moins, pas sans manipulations complexes) et la réutilisabilité du contenu en prend un méchant coup. D'autre part, la représentation de l'information est perdue en cas de désactivation de la couleur (impression papier ou conversion PDF). C'est donc à manier avec précaution et pas forcément à systématiser, comme pour tous les « exploits CSS » d'une manière générale (remplacements de contenu par des images CSS de manière supposée accessible, recourt massif à du CSS3 en cours d'implémentation, etc.) Cordialement, --Lgd (d) 14 mars 2011 à 05:55 (CET)

Oui, la partie graphique est fragile. Par contre ça reste un tableau, et toutes les informations y sont, donc le problème est limité. L'ennui, c'est qu'on ne dispose d'aucune vraie bonne méthode. Donc soit on ne fait rien pour l'instant, soit on répand une méthode imparfaite. Tu choisis quoi ? Dodoïste ^{[ dring-dring ]} 14 mars 2011 à 22:43 (CET)

Ma tendance naturelle privilégie les solutions robustes mêmes si elles ne sont pas encore développées : donc pour l'instant, plutôt laisser les timeline en l'état, ce qui fait ressortir le besoin de les revoir côté dev. En sachant en outre que cette extension va doucement mais sûrement vers sa fin : les solutions robustes sont du côté de HTML5, des formats SVG/WMF et/ou de frameworks/API de génération d'image type Google Chart. L'accessibilité des timeline n'en est pas à un ou deux ans près . Cordialement, --Lgd (d) 15 mars 2011 à 10:19 (CET)

OK, merci. :-) Dodoïste ^{[ dring-dring ]} 15 mars 2011 à 23:33 (CET)

Bouton image

Bonjour, au lieu du Bouton "Fichier inséré" ([[Fichier:Exemple.jpg]]) qui n'apporte pas grand chose (barre des modifs monobook) serait-il possible d'avoir un bouton "image insérée" qui insèrerait un truc plus utile du genre : [[Image:Exemple.jpg|thumb|upright=ici éventuel multiplicateur de taille|alt=ici courte phrase descriptive si pas d'image|ici la légende]]). Est-ce faisable ? D'autant plus que le symbole du bouton est déjà une image. --Amicalement, Salix ( converser) 13 mars 2011 à 20:01 (CET)

Il existe un script simple d'usage pour s'ajouter des boutons personnalisés dans la barre d'outil monobook. Sinon, les boutons de celle-ci peuvent être aisément modifiés. Pour la barre vector, j'ai le souvenir que c'était moins évident, mais Utilisateur:Dr Brains sera sans doute plus à même de répondre rapidement.

Sur le principe de remplacer le bouton actuel par un bouton thumb avec les paramètres clés (upright, alt, légende) : oui, mais peut-être non. Initialement, il me semble que la barre d'outil vector (en version de test) déclenchait un dialogue lors de l'utilisation du bouton image, avec une boîte de saisie pour le nom de fichier. C'est plutôt dans cette direction qu'il faudrait aller : ce serait tout de même plus aisé à comprendre et à utiliser que l'insertion d'un code wiki brut avec tous ces paramètres . Et pour tout dire, c'est ce que fait n'importe quel CMS digne de ce nom...

Cordialement, --Lgd (d) 14 mars 2011 à 06:06 (CET)

Quand on est une IP, Vector ne fait pas mieux que de proposer [[Fichier:Exemple.jpg]] avec Exemple.jpg prêt à être modifié. Rien pour rendre les images plus accessibles accessibles. --Amicalement, Salix ( converser) 14 mars 2011 à 14:46 (CET)

Pour la version test de vector, et la fenêtre de dialogue d'insertion des images. La WMF n'a pas donné suite au gros morceau du travail de l'ergonome qui fut employée, les prototypes stagnent depuis longtemps. La WMF préfère ouvrir un bon nombre de postes de communication, en somme, ce qui semble être un choix mal équilibré. Actuellement, c'est Brion Vibber et peut-être quelques autres codeurs qui préparent un nouveau parser, et bossent sur un éditeur WYSIWYG. J'ai des doutes sur le succès d'une interface réalisée uniquement par des personnes qui ne connaissent que le code (aussi compétentes soient-elles), mais j'espère me tromper. Bref, pas de bouton d'ajout d'image avant longtemps, longtemps. Dodoïste ^{[ dring-dring ]} 14 mars 2011 à 22:56 (CET)

Dommage. Contrairement à Lgd je crois vraiment qu'on gagnerait à proposer un bouton plus complet, maintenant que les alt= et upright= entrent dans les moeurs, à la suite des améliorations apportées aux pages d'aide sur les images. On ne peut pas demander à tous de mémoriser ce code plutôt compliqué pour les non anglophones (en plus avec des h sournois qu'y s'y cachent). Il faut soit actualiser le bouton de Monobook soit, à défaut, mettre au point un modèle pré-rédigé du genre {{nouvelle image}} ou {{image accessible}} ({{image}} existe !). J'en ai assez de remplacer des pixels par des upright ou d'ajouter des alt=, en particulier aux cartes... --Amicalement, Salix ( converser) 15 mars 2011 à 10:01 (CET)

Regroupement des forces techniques

La question pourrait peut-être être posée, pour plus d'avis, sur Projet:Javascript (Plus le temps passe, et plus je me dis qu'un village pump technique serait plus profitable que ces projets, ateliers etc. dispersés, tiens). Cordialement, --Lgd (d) 18 mars 2011 à 09:29 (CET)

Tout fusionner avec Wikipédia:Questions techniques ? Il suffit que les contributeurs calés en informatiques suivent toutes ces pages non ? L'autre solution que j'avais proposée aux fanas de français-grammaire c'est de fédérer leurs différentes pages (peu fréquentées) mais ils n'ont pas mordu à l'hameçon. C'est une solution toute aussi valable pour la technique et l'accessibilité (qui touche tous les projets): Créer un regroupement transverse des pages éparpillées dans les projets ou ateliers spécialisés : sur le principe du Projet:Illustrations qui coordonne plusieurs ateliers, dont l'Atelier identification dont j'ai organisé les pages de façon à ce qu'elles soient communes avec les projets qui ont suffisamment de matière à traiter. On gagne ainsi en efficacité car plus on est de fous...--Amicalement, Salix ( converser) 18 mars 2011 à 11:05 (CET)

Bien vu, mais c'est une autre possibilité. J'aurais juste un souci éventuel : les « comment je fais ça ? » du contributeur sont bien différents des discussions plus pointues (le dfn ci-dessus, les discussions ailleurs sur la prise en compte de la dernière révision médiawiki dans le javascript où on est 3 pelés à y comprendre quelque-chose, les demandes de nouveaux modèles qui sont encore autre-chose, etc.). Je pensais plutôt à un « technique pointu » plus « rassemblé » et plus facile à suivre que nos actuels projets accumulés (javascript, modèles, infobox), ateliers, pages de requête de modification d'une page protégée, page de requête de modification d'un message système... qui sont très (trop) dispersés, sans compter ce qui n'y entre pas et où on ne sait pas vraiment où parler pour que ça ait un impact efficace. Cordialement, --Lgd (d) 18 mars 2011 à 12:03 (CET)

Cette page pour le tout venant existe et elle s'appelle... le bistro ! Non ? Pour les questions très spécialisées, le tout est de leur faire de la pub pour attirer les cervelles pleines. Mettre une palette de navigation commune à toutes les pages techniques, sur le modèle de {{Navigation identification}}, permet de faciliter l'aiguillage des requêtes... et leur suivi. --Amicalement, Salix ( converser) 18 mars 2011 à 17:41 (CET)

Teasing bonnes pratiques accessibilité et AdQ

Hello,
Juste pour vous faire saliver un peu : un benchmark accessibilité des AdQ promus depuis l'adoption récente des critères accessibilités AdQ est en cours, avec des outils externes spécialisés.

L'évaluation de ces contenus va sortir par tranches, la première étant celle des 14 AdQ promus en janvier. Les critères évalués sont ceux de Wikipédia:Articles de qualité/Accessibilité, avec un avis complémentaire sur les problèmes d'accessibilité non couverts par ces critères (et donc une évaluation de ce qu'il faudrait potentiellement ajouter comme nouveau critère. Les arbres généalogiques et les modèles dynastiques seraient par exemple des candidat potentiels).

Pour le moment, les résultats temporaires en cours d'évaluation son déjà assez intéressants. Par exemple, nos contributeurs ont un mal fou à ne pas utiliser à tort et à travers la syntaxe des listes de définitions, les tableaux sont un tout ou rien, les changements de langue sont globalement bien adoptés avec leurs incertitudes sur la pertinence au cas par cas, les citations sont un outil globalement assez mal compris...

Stay tuned

Cordialement, --Lgd (d) 14 mars 2011 à 07:04 (CET)

Alors ?

C'est qu'à force de saliver, je risque de glisser en sortant de mon bureau Litlok (m'écrire) 24 mars 2011 à 08:51 (CET)

Je m'en voudrais de provoquer un si bête accident . Dès que je peux me poser 2 jours entiers chez moi entre deux interventions ici ou là et dès que mes petits camarades ont fini de jouer à modifier l'outil concerné. Concrètement, une semaine ou deux (je visais plus court au départ, désolé). Cordialement, --Lgd (d) 24 mars 2011 à 20:59 (CET)

Alternative textuelle

Discussion déplacée depuis Discussion Wikipédia:Wikiconcours/mars 2011/Équipes/Équipe 29#Alternative textuelle

je vais voir lgd (d · c · b) a/s de l'alternative textuelle qui n'apparait pas pour l'image de la box Mandarine 3 mars 2011 à 20:13

C'est normal que les alternatives textuelles n'apparaissent pas : elles ne sont là que pour décrire les images pour les personnes qui ne peuvent pas les voir. Si tu actives le 'gadget' ou boîte à outils accessibilité, tu pourra la voir. TED 4 mars 2011 à 00:48 (CET)

euh non, c'était pas le problème, c'était juste qu'on avait oublié de prévoir le champ « alternative » dans l'infobox mais c'est réparé ! le gadget permet de vérifier l'accesibilité d'une page mais n'est heureusement pas nécessaire pour voir le texte alternatif, lisible par tout le monde en promenant la souris sur l'image ! pitibizou ! Mandarine 4 mars 2011 à 01:29 (CET)

Tu as dû activer je ne sais quelle option, car quand un utilisateur lambda (ou moi qui n'ai pas pris la même option que toi) passe la souris sur l'image, c'est le lien vers l'image qui apparaît, et pas du tout le texte de l'alternative. TED 4 mars 2011 à 03:05 (CET)

ouh là ! tu m'inquiètes : je n'ai pas activé non plus l'outil de vérification de l'accessibilité ! après, je ne sais pas quelle option donne cette possibilité ! je retourne voir lgd ! pitibizou ! Mandarine 4 mars 2011 à 04:27 (CET)

D'une part, les anciennes versions d'Internet Explorer affichent le contenu de l'alternative au survol de l'image. D'autre part, en fonction du code précis de l'image dans WP, l'alternative peut également être recopiée par mediawiki dans l'attribut HTML qui génère le texte affiché au survol de l'image, pour tous les navigateurs cette fois. Ne pas trop se soucier de ce genre de détails de rendu de l'alternative . Par ailleurs, j'ai mis à jour ces infobox de manière à ce qu'elles produisent automatiquement une alternative générique utile si le paramètre alternative n'est pas renseigné. Cordialement, --Lgd (d) 4 mars 2011 à 05:09 (CET)

hein ? « en fonction du code [...] l'alternative peut être recopiée »  ? ben si je me soucie : rin compris ! je voudrais, simplement, avoir l'assurance que tout le monde voit le texte alternatif ! moi je le vois en passant la souris sur l'image, il semble que ted ne le voie pas du tout, qui voit quoi ? je me suis donc un peu trop avancée en disant que le texte était lisible par tout le monde ? que doivent faire ceux qui ne le voient pas pour arriver à le voir et éventuellement participer à la mise en œuvre de l'alternative textuelle ? sans savoir qui peut quoi on ne peut pas aiguiller les gens qui voudraient aider ! pitibizou ! Mandarine 4 mars 2011 à 19:23 (CET)
ps : merci encore pour la mise à jour des boxes ! s'il te reste une minute je veux bien que tu fasses un tour sur l'ensemble de celles du projet mc qui se trouvent ici ! si tu n'as pas le temps je m'y collerai maintenant que j'ai vu comment faire mais il faudra que j'attende que voxhy soit là pour déprotéger ! en tout cas encore merci !
ps bis : pardon nono on s'éloigne un peu du concours là...

Le mieux est d'utiliser le gadget accessibilité (dans les préférences de ton compte), qui est fait pour aider à rédiger les alternatives. Cordialement, --Lgd (d) 4 mars 2011 à 21:13 (CET)

mais non c'est pas la question : moi no problem, j'écris les textes, je vois les textes ! je voudrais juste savoir si tous les lecteurs ont accès ou non au texte alternatif en passant la souris sur l'image ! Mandarine 4 mars 2011 à 21:17 (CET)

Non, cela ne se produit que pour certaines images et pour certains lecteurs. Cordialement, --Lgd (d) 5 mars 2011 à 06:44 (CET)

d'accord... aurais-tu la gentillesse de développer (en langage accessible à un non spécialiste) stp ? quels utilisateurs, lecteurs, rédacteurs ou autres auraient accès au texte alternatif de quelles images, comment et pourquoi ? pourquoi, comment et quels autres auraient accès au texte alternatif de certaines autres images et lesquelles ou pourquoi n'auraient-ils accès au texte d'aucune image ? merci ! pitibizou ! Mandarine 5 mars 2011 à 07:14 (CET)

Pour savoir à quoi sert l'accessibilité du Web, et à qui cela s'adresse, tu peux déjà lire : Accessibilité du Web. TED 16 mars 2011 à 00:24 (CET)

Humpf... Bon, essayons.

L'alternative textuelle d'une image n'est pas faite pour être restituée quand l'image est affichée « normalement » dans le navigateur. Elle n'est destinée qu'aux cas où l'image ne peut pas être restituée : si l'affichage des images est désactivé, si la page est lue par un synthèse vocale, si un souci côté serveur ou connexion empêche le téléchargement de l'image. Donc, « normalement », disons, on n'y a pas accès en affichant la page et c'est pourquoi on utilise des outils particuliers comme le gadget accessibilité quand on a besoin de consulter ces alternatives pour en vérifier facilement la présence ou le contenu.

Mais cela se complique à cause de deux choses :

• la première n'est pas propre à Wikipédia : les anciennes versions d'Internet Explorer dont certaines sont encore assez utilisées faisaient apparaître l'alternative textuelle d'une image quand on survole celle-ci avec la souris (tout comme la bulle d'aide qui apparait au survol d'un lien). C'était une particularité de ce navigateur, corrigée depuis.
• la seconde est plus liée à la syntaxe wiki : dans wikipédia, les images sont par défaut des liens vers leur propre page où on peut consulter l'image en grande taille, consulter sa licence etc. Selon la syntaxe wiki très précisément utilisée pour l'image, c'est ce lien qui peut se retrouver avec une bulle d'aide où le texte donnée comme alternative de l'image a été reproduit (en double, donc) par le logiciel mediawiki. Dans ce cas, quelque-soit le navigateur, le texte de l'alternative apparaitra au survol de l'image. Par exemple :
  • si j'écris [[Fichier:Exemple.jpg|16px|alternative textuelle]], tu peux voir le texte de l'alternative en survolant l'image :
  • si j'écris [[Fichier:Exemple.jpg|16px|alt=alternative textuelle]], tu ne peux pas voir le texte de l'alternative en survolant l'image :

Il y a encore d'autres variantes de syntaxe, je n'entre pas dans les détails. Cordialement, --Lgd (d) 16 mars 2011 à 06:35 (CET)

merci lgd ! je pensais que tu avais conservé la page de discu en suivi, y étant intervenu ! généralement ça marche mieux avec toi mais là effectivement difficile de se comprendre et de se faire comprendre ! je vais réessayer aussi :

je ne comprends pas lorsque tu écris : « si j'écris [[Fichier:Exemple.jpg|16px|alt=alternative textuelle]], tu ne peux pas voir le texte de l'alternative en survolant l'image :  » ! parce que, si, justement, je vois (et j'en suis ravie : surtout ne rien changer !) le texte alternatif en survolant l'image alors que je n'ai pas activé l'outil de vérif de l'accessibilité !

je dis que j'en suis ravie parce que dans la mesure où je rentre un texte alternatif, j'apprécie tout de même d'en voir le rendu pour me faire une idée de l'aide que je peux apporter (relire le texte, est-il compréhensible, adapté, trop long, trop court, etc.)

je déduis de ta réponse du 4 à 05:09 que j'ai donc sans doute une ancienne version d'IE (?) mais je n'ai pas compris la suite : « D'autre part, en fonction du code précis de l'image dans WP, l'alternative peut également être recopiée par mediawiki dans l'attribut HTML qui génère le texte affiché au survol de l'image, pour tous les navigateurs cette fois. » !

je veux bien ne pas me soucier de ce que ça peut bien vouloir dire puisque, moi, je vois le texte alternatif mais, et c'était l'objet de mon interrogation, je ne peux pas ne pas me soucier de ceux qui, comme TED, voudraient peut-être aider mais ne voient pas le texte (cf. sa réflexion du 4 à 03:05) ! s'ils ne voient pas le texte, comment peuvent-ils apprécier si le rendu en est convenable ? en résumé, quelle est la solution pour que TED (ou tous ceux dans son cas) voie le texte puisqu'il semble, au vu de sa réponse, qu'il existe pour lui un obstacle à l'utilisation de l'outil de vérif de l'accessibilité !

j'espère avoir été plus claire ! sinon je veux bien essayer de reformuler encore ! pitibizou ! Mandarine 16 mars 2011 à 20:58 (CET)

Je vois très bien les alternatives textuelles en activant l'option ad hoc dans la boîte à outils (ou « gadget ») accessibilité en colonne de gauche. TED 16 mars 2011 à 23:10 (CET)

Si l'alternative apparaît pour toi au survol de , ([[Fichier:Exemple.jpg|16px|alt=alternative textuelle]]), c'est en effet parce que tu utilises une ancienne version d'IE, ou bien IE8 mais dans ce qu'on appelle le mode affichage de compatibilité où il reproduit le comportement de sa version précédente. Pour le « D'autre part, en fonction du code précis de l'image dans WP, l'alternative peut également être recopiée par mediawiki dans l'attribut HTML qui génère le texte affiché au survol de l'image, pour tous les navigateurs cette fois. », c'est ce qui est expliqué ci-dessus avec les deux exemples de code wiki.

Enfin, si un retour fait apparaitre une difficulté empêchant d'utiliser le gadget accessibilité, cela conduira soit à des améliorations de celui-ci, soit à diriger le contributeur concerné vers d'autres outils spécialisés (plus complexes, mais bon). Cordialement, --Lgd (d) 17 mars 2011 à 06:33 (CET)

@ Mandarine. Je rappelle simplement que toute personne qui peut afficher l'image n'a pas besoin de lire l'alternative textuelle : en affichage normal, celle-ci ne doit pas servir à compenser les déficiences du texte ou de la légende. En l'absence de gadget ou de navigateur sympa, les rédacteurs peuvent aussi facilement vérifier la présence des "alt=" en recherchant par exemple toutes les occurrences de "thumb", généralement présent pas loin côté code des images. --Amicalement, Salix ( converser) 17 mars 2011 à 14:04 (CET)

hello tous les trois ! merci de vos réponses ! juste une précision : je sais bien que l'on n'a pas « besoin » de lire l'alternative textuelle lorsque l'image s'affiche ou est visible ! je rappelle que je ne suis là qu'en qualité de candide, c'est-à-dire en me positionnant, non pas en utilisatrice de l'alternative textuelle, encore moins en spécialiste de sa mise en œuvre mais en béotienne qui s'est trouvée confrontée au problème du code dans les infoboxes (merci encore à lgd) et qui voudrait bien comprendre comment ça marche dans les autres formats également pour aider au mieux ! c'est à ce titre que j'ai « besoin » de voir !

donc, ok, ted confirmant le fonctionnement correct pour lui (et donc pour un utilisateur lambda) du gadget, cette question est réglée !

pour le reste, je reformule ce que je pense avoir compris, vous me dites si j'ai bon et je poursuis avec (je pense ) une dernière question (ouf se disent-ils ) ! donc, sans le gadget :

• codé par [[Fichier:Exemple.jpg|16px]] : donne (pour tous ?), au survol de l'image dans ce format, le nom du fichier
• codé par [[Fichier:Exemple.jpg|16px|texte]] : permet à un utilisateur lambda d'accéder, au survol de l'image dans ce format, au texte saisi ; ce texte unique peut être une description alternative, un commentaire, une légende de l'image, etc.
• codé par [[Fichier:Exemple.jpg|16px|alt=texte]] : le texte alternatif (ou commentaire, ou légende) n'est accessible, au survol de l'image dans ce format, qu'à certains utilisateurs (IE ancien ou IE8 mode ancien) ! l'utilisation de « alt= » me paraît donc inutile dans ce format (qui ne permet pas de faire apparaître de légende : la nécessité de différencier alternative textuelle et légende ne se pose donc pas)
• « alt= » est en revanche indispensable pour différencier, dans une vignette, le texte alternatif de la légende en codant ainsi : [[Fichier:Exemple.jpg|thumb|alt=texte alternatif|légende]] :
• reste donc à résoudre la question pour les galeries, qui ne permettent pas d'alternative textuelle quel que soit le code (mais le nom du fichier apparaît bien pourtant, au survol de l'image, pour la 4 sans légende !) :

légende

• 
  légende
• 
  légende
• 
  légende
• 

valà ! si j'ai bon je n'aurai pas à vous embêter davantage sinon j'espère que vous aurez la patience de me dire encore où ça coince ! merci à tous les trois ! pitibizou ! Mandarine 18 mars 2011 à 02:30 (CET)

C'est presque ça. Je reprends tes exemples :

• codé par [[Fichier:Exemple.jpg|16px]] : cela ne donne rien non plus au survol de l'image, sauf cas particulier de navigateur (vieil IE ou IE en mode ancien) comme toi. Dans ce cas, comme le contributeur n'a pas indiqué d'alternative, mediawiki se charge tout seul de coller le nom du fichier image comme alternative, comme si tu avais écris [[Fichier:Exemple.jpg|16px|alt=Exemple.jpg]] ;
• codé par [[Fichier:Exemple.jpg|16px|texte]] ou codé par [[Fichier:Exemple.jpg|16px|alt=texte]] : que l'on utilise l'une ou l'autre syntaxe n'est pas un point majeur, mais en fait, c'est plutôt la syntaxe qui ne fait pas apparaître la légende au survol qui est la plus recommandable, car elle évite que les contributeurs n'aient envie de détourner l'alternative de sa fonction pour y mettre d'autres choses comme un commentaire, une sorte de légende, etc. Or l'alternative doit être un texte reproduisant l'information donnée par l'image : ce n'est pas un « commentaire » au sens où on s'en servirait pour apporter une information complémentaire qui suppose qu'on ait perçu l'image.
• En revanche, pour [[Fichier:Exemple.jpg|thumb|alt=texte alternatif|légende]] qui donne une vignette légendée (un thumb) : oui, tout à fait, il faut écrire alt= pour que mediawiki puisse différencier la légende et l'alternative.
• Le système actuel de galeries ne permet pas de renseigner une alternative textuelle, c'est un défaut à corriger côté développement (comme l'indique d'ailleurs le gadget dans le message affiché par ses soins sur les galeries ). Le même problème se pose avec les « timeline » (frises chronologiques) ;

Cordialement, --Lgd (d) 18 mars 2011 à 05:58 (CET)

ok ! dernier (a priori) feed back ! j'ai fini par comprendre pourquoi le texte de l'alternative textuelle n'avait pas à apparaître en mode normal et donc le pourquoi de l'outil de vérif et que c'est le fait que moi je voie ce texte qui m'empêchait de comprendre ! donc :

• coder ce format d'image ainsi : [[Fichier:Exemple.jpg|16px]] ne donnera rien au survol de l'image pour le lecteur lambda mais affichera le titre du fichier pour les utilisateurs des systèmes permettant l'affichage de l'alternative textuelle ou par l'intermédiaire de l'outil de vérif (et pour les utilisateurs d'IE mais on oublie parce que c'est source de confusion et ce ne devrait pas être significatif)
• coder ce format d'image ainsi : [[Fichier:Exemple.jpg|16px|alt=exclusivement un texte alternatif]] (et c'est la syntaxe à conseiller afin de canaliser la vilaine tentation (à laquelle j'avoue avoir succombé pour les fichiers musicaux : c'est grave docteur ?) de la saisie d'un commentaire autre que la description alternative de l'image) ne donnera rien au survol de l'image pour le lecteur lambda (sauf IE idem) mais affichera le texte décrivant l'image pour les utilisateurs de l'alternative textuelle
• on oublie ce codage : [[Fichier:Exemple.jpg|16px|commentaire]] parce que l'absence du « alt= » est source de confusion en semblant autoriser le détournement, fortement déconseillé, de la fonction de l'alternative textuelle ? juste : il est visible par tous celui-là ? comme je les vois tous je ne peux pas me rendre compte, c'est idiot !
• vi j'ai vu l'appel au vote pour la résolution du bug dans les galeries ! mais comme j'irai pas voter je te donne procuration  ! pas été confrontée à la question sur les timelines mais c'est noté ! réglé aussi pour les vignettes !

valà ! ayé non ? pitibizou ! Mandarine 18 mars 2011 à 22:49 (CET)

A une petite correction de ton exemple près, oui. Cordialement, --Lgd (d) 19 mars 2011 à 07:32 (CET)

euh... Merci  ! bon je vais essayer de faire un petit truc sans trop de bêtises pour le projet mc ! pitibizou ! Mandarine 19 mars 2011 à 11:21 (CET)

Quand tu auras rédigé un truc clair, il serait utile de le recopier là : Wikipédia:Atelier_accessibilité/Bonnes_pratiques#Images ou là : Wikipédia:Mise en forme des images pour que ton expérience profite à tous . --Amicalement, Salix ( converser) 19 mars 2011 à 11:35 (CET)

Je me souviens avoir mis il y a quelques mois dans une page meta/aide/??? une explication à ce sujet (version technique), que j'aimerais bien vérifier... Mais impossible de remettre la main dessus dans notre maquis . Cela évoque-t-il quelque-chose à quelqu'un ? Cordialement, --Lgd (d) 19 mars 2011 à 12:00 (CET)

Galeries d'images et alternatives textuelles, une bonne nouvelle

Bonjour,
Le niveau de priorité du bug mediawiki Can't provide alt text for files in <gallery> vient de passer de « Normal » à « Highest » (le plus élevé). Excellente nouvelle, donc. Cordialement, --Lgd (d) 19 mars 2011 à 12:31 (CET)

Grâce à ceux qui ont voté ? --Égoïté (d) 19 mars 2011 à 18:08 (CET)

Un soucis avec le gadget ?

Ca ne fonctionne plus très bien chez moi. Que ce soit sous monobook ou sous vector. Par exemple, quand j'active un des gadgets, il n'apparaît plus activé dans le cadre (pas de coche). Sans compter que certains ne semblent plus fonctionner du tout : tableaux, langue, etc. A bah, tiens, je ne peux plus le fixer non plus. Je suis le seul ? --'toff ^[discut.] 24 mars 2011 à 03:48 (CET)

En effet, le script fonctionne mais la feuille de style MediaWiki:Gadget-Accessibility.css n'est plus prise en compte. Je vais tâcher de regarder ça aujourd'hui (mais c'est lié aux changements en cours côté dev, avec les inévitables bugs temporaires, cf Bistro d'hier). Cordialement, --Lgd (d) 24 mars 2011 à 08:00 (CET)

corrigé, en principe (en court-circuitant le système d'appel de CSS prévu pour les gadgets). Actualisez le cache de votre navigateur et ça devrait revenir à la normale. Cordialement, --Lgd (d) 24 mars 2011 à 08:48 (CET)

Cent quioux. --'toff ^[discut.] 24 mars 2011 à 16:22 (CET)

Utilisation de «  »

Bonjour. Quelque spécialiste de l'accessibilité de wp peut-il me dire ce qu'il pense de ce diff ? Merci. Iorek (d) 25 mars 2011 à 20:01 (CET)

Sous cette forme, ce n'est pas pertinent. Ce n'est pas le recours à une icône ni à celle-ci en particulier qui pose un problème, mais le passage par le modèle {{fait}} très spécifiquement. En effet, le sens de ce modèle, inscrit dans l'alternative textuelle de l'image, n'est pas « oui », mais « fait ». Il est à réserver aux pages de discussions et aux pages meta, et n'a pratiquement pas sa place dans les articles. Un autre modèle avec un rendu similaire mais avec une alternative plus pertinente serait nécessaire (peut-être existe-t-il, je n'ai pas regardé plus avant).

Pour cette raison, la modification concernée a été annulée. Cordialement, --Lgd (d) 25 mars 2011 à 21:05 (CET)

Sans doute le modèle {{oui}} est plus adapté. Udufruduhu (d) 2 avril 2011 à 13:09 (CEST)

Depuis nos corrections, oui. :-) Ceci dit, Lgd, j'ai un doute sur un détail. Est-ce que la version la plus correcte est celle de Udufruduhu, ou ma tentative d'éviter un doublon de "oui" ? Dodoïste ^{[ dring-dring ]} 2 avril 2011 à 13:46 (CEST)

Je pense que la tienne est meilleure. Je n'avais pas fait gaffe à ce doublon. Udufruduhu (d) 2 avril 2011 à 14:20 (CEST)

En effet, il faut éviter le doublon : l'image n'apporte pas d'information. Cordialement, --Lgd (d) 2 avril 2011 à 18:41 (CEST)

À propos de doublon : là aussi : {{onglets libres}}, utilisé sur les portails. Si quelqu’un a le courage de s’y mettre, moi pas ?
Ltrl G, le 9 janvier 2012 à 23:01 (CET)

Notification technique sur hiddenstructure

Bonjour. Récemment, la classe hiddenstructure a été retirée des styles des skins chick, modern, monobook et vector. Voir bugzilla:17009. Vu que nous avons une classe locale, cela ne change pas grand-chose dans l'immédiat, mais dénote d'une volonté globale d'en finir avec cette classe. Dodoïste ^{[ dring-dring ]} 30 mars 2011 à 19:00 (CEST)

C'est encourageant, en effet. Merci pour l'info. Cordialement, --Lgd (d) 30 mars 2011 à 19:01 (CEST)

Indication de langue automatique dans Lien web

Pourquoi l'indication de langue automatique ne fonctionne pas avec le modèle {{Lien web}}? Prosopee (d) 1 avril 2011 à 19:49 (CEST)

Parce que le modèle n'a pas été prévu pour. Ce ne serait d'ailleurs pas nécessairement judicieux (contrairement à ce qu'on peut penser de prime abord, la langue du libellé ne sera pas forcément identique à la langue qu'on voudra signaler avant le lien sous la forme par exemple (en) : il faudrait donc deux paramètres de langue, avec d'inévitables erreurs d'usage). Cordialement, --Lgd (d) 1 avril 2011 à 19:58 (CEST)

arg, donc, rien à faire? C'est dommage car c'est une source d'erreur constante ai-je remarqué. Lequel des deux champs (en) ou langue=en est interprété par les logiciels d'accessibilité au fait? Prosopee (d) 1 avril 2011 à 20:04 (CEST)

(conflit) Nos petits camarades de wp:en ont deux titres (pour toutes les références) : le titre original et le titre traduit. C'est pas folichon à remplir, mais ça ne me semble pas inutile. Accessoirement, je ne vois pas trop pourquoi on considère que le tritre d'un page web n'est pas forcéement dans la langue de la page, alors qu'on ne se pose pas la question pour le titre d'un livre. --Anneyh (d) 1 avril 2011 à 20:09 (CEST)

Disons qu'avec {{ouvrage}}, le champ langue est opérant, sinon on a « titre original » donc je trouve qu'on a la possibilité de le respecter, chose que tout le monde (c'est vrai) ne fait pas. Prosopee (d) 1 avril 2011 à 20:17 (CEST)

Les indications du type (en) ne jouent aucun rôle en matière d'accessibilité. Ce qui compte de ce point de vue est de pouvoir signaler (dans le code HTML) la langue dans laquelle est rédigée le libellé du lien (à la manière du modèle {{lang}}).

Or, à la différence d'{{ouvrage}} où les contributeurs reproduisent le titre original, il est fréquent que le libellé qu'ils donnent à un lien Web ne soit pas le titre de la page cible. Pour un lien vers une page dans une autre langue, on peut très bien se retrouver avec un libellé improvisé en français, ou même avec un libellé multilingue. Et si on suppose une règle conduisant à utiliser le titre de la page cible, il arrive que celui-ci soit bilingue.

Un champ permettant de renseigner la langue pour donner l'indication type (en) ne devra donc en aucun cas être utilisé en plus pour signaler la langue du libellé. Pour celle-ci, il faut s'en tenir à utiliser le modèle {{lang}} dans le champ {{titre}}. L'ajout d'un paramètre de langue dans le modèle {{Lien web}} n'a donc pas d'utilité pour l'accessibilité.

Cela dit, certes, un paramètre de langue uniquement pour produire le (en), pourquoi pas. Mais il serait préférable de commencer à réfléchir au remplacement de ces énigmatiques modèles (en), (zh), (el) etc. par une meilleure gestion éditoriale des libellés de liens afin d'indiquer au lecteur la langue de la ressource, comme cela se fait partout ailleurs où on s'est posé la question...

Cordialement, --Lgd (d) 2 avril 2011 à 06:53 (CEST)

C'est déjà plus clair pour moi! Je te remercie de ces éclaircissements. L'importante est de signaler la langue du titre original ; pour la mention visuelle : (en), il faut continuer car les critères de rédaction les mentionnent mais en effet ils ne sont qu'un pis-aller. Bonne journée, Prosopee (d) 4 avril 2011 à 07:40 (CEST)

gadget accessibilité : validation de l'usage de dfn

Bonjour,
Comme demandé lors des discussions de la Prise de décision/Adoption du balisage dfn dans les introductions d'articles, un outil de détection des usages impropres de dfn a été mis en place pour les contributeurs intéressés. C'est un ajout au gadget accessibilité.

Il détecte (si tout va bien à ce stade de son débugage) les utilisations de dfn ou du modèle équivalent en dehors du premier paragraphe introductif de l'article. le cas échéant, il ajoute un message d'erreur dans la page et un lien vers Aide:dfn. Il fonctionne également lors de la prévisualisation d'un article.

Pensez à actualiser le cache de votre navigateur pour disposer de cette nouvelle fonctionnalité.

Cordialement, --Lgd (d) 9 avril 2011 à 07:27 (CEST)

Abus de <abbr> ?

Bonjour, Est-il recommandé, pour chaque abréviation du texte, d'utiliser <abbr> ? Discussion lancée sur cette page de vote au BA. Merci, Prosopee (d) 12 avril 2011 à 07:55 (CEST)

Copie de la réponse faite sur Discussion:Armée de terre canadienne/Bon article

Les normes d'accessibilité n'imposent l'utilisation de abbr que sur la première occurrence présente dans la page. Il n'y a donc aucune obligation à l'utiliser sur toutes les occurrences. Ce ne serait pas nécessairement une amélioration, chaque abréviation explicitée rendant la consultation plus verbeuse dans un lecteur d'écran.

Dans le même ordre d'idée, je vois à l'examen de cet article qu'il faut apporter une autre précision sur l'usage d'abbr : il est inutile d'y recourir lorsque l'abréviation est déjà explicitée au fil de la phrase, comme dans « Le Commandement de la Force terrestre des Forces canadiennes ou COMFT... ». Il est suffisant dans ce cas d'écrire plutôt : « Le Commandement de la Force terrestre des Forces canadiennes ou COMFT... »

Voir les bonnes pratiques accessibilité qui présentent les différents moyens d'expliciter une abréviation.

Cordialement, --Lgd (d) 12 avril 2011 à 08:11 (CEST)

Service rapide . Ah bon ok, je note les deux précisions. Merci de ton aide, Prosopee (d) 12 avril 2011 à 08:20 (CEST)

Intermède publicitaire, conférence où on parlera du gadget

Bonjour,
Désolé pour la minute de pub violemment assénée, mais bon, on m'a demandé d'en parler ici : une conférence de nature un peu technique sera consacrée le 16 avril prochain à Paris aux outils d'assistance à l'accessibilité éditoriale, et le gadget accessibilité sera en particulier pris comme exemple. Vous trouverez ici les détails, voilà, voilà... Cordialement, --Lgd (d) 12 avril 2011 à 11:04 (CEST)

Correction d'erreurs sur les codes de changement de langue

Bonjour,
Lorsque le modèle {{lang}} est utilisé, les contributeurs doivent saisir eux-mêmes les codes de langue. Il y a donc d'inévitables erreurs introduisant des codes invalides et des signalement de changements de langue erronés (je rappelle à ce propos l'existence de cet excellent outil de validation et de recherche de codes de langue, en anglais).

Je viens de modifier le modèle lang de manière à ce qu'il range dans la catégorie:Page avec code de langue invalide au moins un premier cas d'erreur qui semble relativement courant : le code pour grec n'est pas... gr, mais de façon plus inattendue el pour le grec moderne ou grc pour le grec ancien (jusqu'en 1453).

Si vous avez des suggestions d'autres erreurs fréquentes du même type, n'hésitez pas à les signaler.

Le gadget accessibilité va également être modifié pour donner une alerte précise dans ce cas.

Dans l'immédiat, il serait intéressant de ne pas se précipiter sur les corrections pour le grec, et d'attendre jusqu'à demain, le temps que la catégorie:Page avec code de langue invalide se remplisse (le cache de mediawiki va s'actualiser progressivement pour les 157 646 articles concernés par ce modèle) : nous aurons ainsi une information intéressante avec une estimation du nombre d'articles en erreur sur ce point . Cordialement, --Lgd (d) 14 avril 2011 à 16:37 (CEST)

Hélas ! le code pour grec n'est pas... gr, de façon plus inattendue el pour le grec moderne…

Pourquoi on ne pourrait pas corriger dès maintenant les premières erreurs qui apparaissent ? C'est seulement pour les statistiques ? TED 14 avril 2011 à 17:18 (CEST)

Oui. Désolé de vous proposer de réfréner vos instincts correcteurs, mais nous manquons dramatiquement d'indicateurs chiffrés sur les fréquences d'erreurs, qui sont pourtant un outils de base habituellement. Celui-ci sera très imparfait, mais déjà utile. Cordialement, --Lgd (d) 14 avril 2011 à 17:30 (CEST)

Si vous êtes très sages, vous aurez samedi dans la mise à jour du gadget, outre diverses améliorations, une toute nouvelle détection d'une erreur pas encore traitée, sur un autre souci --Lgd (d) 14 avril 2011 à 17:32 (CEST)

Y va plus tenir dans la colonne de gauche à force de grossir ce gagdet ! --'toff ^[discut.] 15 avril 2011 à 00:41 (CEST)

Finalement, juste une cinquantaine d'articles, on fait de l'accessibilité à la marge, là.

En vrai, je voulais surtout avoir l'occasion de mettre pour une fois un message collaboratif et utile sur le Bistro. La semaine prochaine, on le refait avec lu au lieu de lb pour le luxembourgeois, tiens. Cordialement, --Lgd (d) 17 avril 2011 à 16:07 (CEST)

Est-ce qu'il ne serait pas plus « collaboratif et utile » de mettre un mot sur Portail:Grèce/Kafeneion ? <remarque inutile>(parce que « utile » et « bistro » dans la même phrase, cela ressemble à une figure de style littéraire… et je doute que tu cherches à faire de la poésie avec les {{lang}})</remarque inutile> TED 17 avril 2011 à 16:40 (CEST)

Si, je le ferai demain en cas de plof bistrotier. Mais ne gâche pas mes juvéniles illusions que le niveau du Bistro peut être relevé, steu-plaît : elles sont bonnes pour mes artères. Cordialement, --Lgd (d) 17 avril 2011 à 16:45 (CEST)

Galeries d'images et alternatives textuelles, une bonne nouvelle (bis)

Bonjour,
Pour le plaisir d'une petite nouvelle encourageante : après le passage du bug concerné au niveau de priorité le plus élevé en mars dernier, le correctif technique a été écrit (voir bugzilla). Si tout va bien, on devrait bientôt voir arriver ici cette amélioration très attendue . Cordialement, --Lgd (d) 23 avril 2011 à 08:14 (CEST)

Amusant, j'allais justement le signaler ! od†n ↗^blah 23 avril 2011 à 18:58 (CEST)

Cela dit, aujourd'hui, ça fait un peu « oui ? Non. Encore, fais-moi mal ! » du côté des commits . Cordialement, --Lgd (d) 23 avril 2011 à 19:03 (CEST)

rebelote Le patch va-t-il tenir ? Suspens insoutenable. Cordialement, --Lgd (d) 26 avril 2011 à 20:59 (CEST)

Héhé, roulement de tambours... qui durera jusqu'à la prochaine mise à jour de MediaWiki probablement. Si la correction passe ça risque fort de me donner envie de reporter plus de bugs dans ce genre (c'est pas la matière qui manque). Je serai aussi pris d'une envie irrésistible de courir tout nu dans la rue en criant "On les a eus, les salauds !", mais... euh... je crois que je dérive. Dodoïste ^{[ dring-dring ]} 1 mai 2011 à 21:00 (CEST)

Prends ta tisane, Dodoïste. Prends ta tisane... --Lgd (d) 1 mai 2011 à 21:04 (CEST)

Sage suggestion, j'en aurai besoin pour me réchauffer ensuite. :-) Dodoïste ^{[ dring-dring ]} 2 mai 2011 à 09:04 (CEST)

Plus sérieusement, si vous cherchez d'autres bugs à « pousser », je suggère notamment :

• celui sur le manque d'implémentation de l'élément q pour les citations, qui nous permettrait d'avoir enfin un code HTML pertinente derrière le modèle {{Citation}} (pour les citations blocs, par contre, c'est bon).
• celui sur les liens d'accès rapides pour la navigation au clavier (mais je ne sais plus si la correction demandée était la bonne).

Je vais tâcher de remettre la main sur les url. C'est quelque-part là dedans... Cordialement, --Lgd (d) 2 mai 2011 à 09:16 (CEST)

Image : alt

Je travaille actuellement sur l'article consacré à Rudolf Höss, en visant à terme l'AdQ. Dans ce cadre, je souhaite insérer systématiquement une alternative textuelle aux images, comme je l'ai fait dans Loi allemande des pleins pouvoirs de 1933. Deux questions: En vérifiant ce dernier article, il semble que mes textes soient trop longs (Je n'ai paut-être pas tout compris). Quid d'une image reprise dans l'infobox en tête d'article? Couthon (d) 1 mai 2011 à 12:51 (CEST)

Bonjour,
C'était en effet le problème dans Loi allemande des pleins pouvoirs de 1933 : bien qu'il n'y ait pas de limite normalisée en nombre de caractères et que celle retenue par le gadget (120 caractères) ne soit qu' indicative, l'essentiel est qu'une alternative ALT doit être plus concise que cela : c'est une information qu'il faut pouvoir consulter rapidement, disons.

Cependant, il existe une possibilité de description étendue d'une image qui correspond tout à fait au travail (impressionnant) que tu as réalisé avec les actuelles ALT de Loi allemande des pleins pouvoirs de 1933 : c'est de déporter cette description dans le champ approprié de la page de l'image sur commons (via le modèle commons:Template:Information si je ne me trompe pas), et de faire un ALT du coup très simple et très concis, du type « Consulter la description détaillée de la dernière page du texte original de la loi des pleins pouvoirs » (je prends l'exemple de la première image de Loi allemande des pleins pouvoirs de 1933).

Si tu choisis de ne pas fournir cette description étendue dans la page Commons, le choix actuel est de rédiger une alternative ALT descriptive mais très concise (difficile) ou plus simplement d'y mettre un « Voir la page de l'image décrite ci-après » : le « ci-après » renvoie alors à la légende du thumb, qui est aussi potentiellement une brève alternative...

Quant à elles, les images placées dans les infobox posent divers problèmes d'alternatives qui ne peuvent être résolus aisément pour le moment. Celle de Rudolf Höss a déjà une alternative ALT peu pertinente, car le le modèle d'infobox y reproduit bêtement la légende. Mais c'est à laisser en l'état faute de mieux pour le moment : corriger ce genre de choses est une des raisons qui nécessite une refonte en profondeur du code de toutes les infobox le jour où ce sera enfin possible (il approche doucement).

Globalement, la gestion des alternatives d'images dans WP est un chantier aujourd'hui assez frustrant, mais totalement ouvert à la fois techniquement et du côté des pratiques rédactionnelles.

Cordialement, --Lgd (d) 1 mai 2011 à 13:28 (CEST)

Version courte, sans doute plus pratique  :

• Si tu te sens à faire des descriptions très complètes des images, tu les mets sur la page de l'image dans Commons via le modèle commons:Template:Information et tu mets dans l'article des ALT du type « Consulter la description détaillée de la dernière page du texte original de la loi des pleins pouvoirs ».
• Si tu préfère aller au plus simple, tu écris juste dans chaque alternative de thumb « Voir la page de l'image décrite ci-après ».

Cordialement, --Lgd (d) 1 mai 2011 à 13:34 (CEST)

Des modèles de tableaux non formatés ?

Salut !

À la recherche d'une aide (que j'ai trouvée, merci) parmi les nombreuses pages de notre Wiki bien-aimée, je suis tombé (de stupéfaction) sur la page Projet:Charte graphique/Apparence des tableaux où aucun des tableaux présentés n'était formaté comme il se doit.

Afin d'éviter la prolifération des tableaux du genre, il serait bon qu'ils soient rapidement « accessibilisés ».

Au passage : quelques modèle:tableau ne sont pas formatés non plus. C'est dommage aussi.

Je vous passe le bébé ? Merci et @ + ! Papatt (d) 1 mai 2011 à 21:36 (CEST)

La page étant obsolète (comme c'est écrit en haut), il serait peut être plus rapide de la blanchir et renvoyer vers Aide:Les tableaux pour les novices ? --'toff ^[discut.] 1 mai 2011 à 22:15 (CEST)

Ce serait sans doute la solution la plus simple (la page est très peu fréquentée, d'ailleurs). Cordialement, — Le message qui précède, non signé, a été déposé par Lgd (discuter)

--'toff ^[discut.] 3 mai 2011 à 05:53 (CEST)

Est-ce qu'on utilise l'élément cite ?

Bonjour. Suite à Template_talk:Citation/core#Separating_content_from_formatting. je (re?)découvre que cite est accepté par le parseur de MediaWiki. Est-ce que l'usage proposé sur en: est pertinent ? Est-ce que nous faisons usage de cite ? Bien à vous, Dodoïste ^{[ dring-dring ]} 6 mai 2011 à 10:25 (CEST)

Ah, apparemment on l'utilise dans Modèle:Ouvrage, et probablement quelques autres endroits. Dodoïste ^{[ dring-dring ]} 6 mai 2011 à 10:29 (CEST)

Du point de vue accessibilité : cite n'a pas, actuellement et formellement, de nécessité. Mais, comme pour tout autre élément sémantique explicitement requis par WCAG ou non, son utilisation ne doit pas être détournée ou erronée : si on ne s'en sert pas, tout va bien, mais si on s'en sert, il faut le faire correctement.

Partant de là, la difficulté est de définir son usage : la définition d'HTML4.01 reconduite en XHTML1.0 est à peu près inutilisable, d'où sa redéfinition en cours en HTML5, qui aboutit à : cite balise les titres d'oeuvres (imprimées ou non, qu'ils soient ou non mentionnés en association avec une citation).

Actuellement, sur WP :

• il est parfois bien employé, comme dans {{Chapitre}} ou {{Citation bloc}} (si personne n'y touché depuis mes corrections).
• Il est détourné de cet usage dans différents modèles où il balise l'ensemble des données de référence, par exemple {{Lien web}}. Ceux-si sont donc à corriger sur le modèle de cette correction.

Il y a un troisième point, mais qui ne relève pas de l'accessibilité : il est sous-employé en général et notamment pour tout ce qui concerne les œuvres non imprimées (films, jeux vidéos, œuvres musicales, etc.), ou encore dans la mise en forme des titres d'articles. Mais là, c'est plus compliqué (éditorialement et techniquement parlant) : par exemple, tout article portant sur une œuvre avec le titre d'article correspondant devrait avoir un {{Titre mis en forme}} balisant avec cite... (sur cet exemple, je n'en ferais pas une priorité sauf si l'idée d'utiliser {{Titre mis en forme}} pour mettre systématiquement en italique les titres d’œuvres aboutit à quelque-chose, voir cette discussion).

Une dernière réflexion : quelles que soient les actions entreprises, son usage ne devrait en aucun cas être demandé aux contributeurs et doit passer exclusivement par les modèles, de manière à être transparent pour eux : rien que le nom de cette syntaxe est à elle-seule une source d'erreurs éditoriales suffisantes pour qu'il soit vital de protéger les contributeurs de prises de têtes inutiles .

Cordialement, --Lgd (d) 6 mai 2011 à 11:03 (CEST)

Après, les questions d'italique et de quotes CSS de en.wp sont plutôt des bricoles ne devraient pas poser de soucis, mais j'avoue avoir un peu arrêté de lire après « B and I must never be used of course — they are meant to disappear —, but strong and em are OK » qui témoigne d'un certain souci. Cordialement, --Lgd (d) 6 mai 2011 à 13:18 (CEST)

D'ac, merci pour les précisions. Donc la démarche anglophone est correcte (du moins au départ). Si je comprends bien, le problème que tu évoques au sujet des B/I vs. EM/STRONG est le suivant. D'un point de vue d'accessibilité, on peut utiliser B/I uniquement pour la mise en forme, et EM/STRONG uniquement pour marquer des emphases de manière sémantique. Donc l'un et l'autre ne sont pas incompatibles, et surtout on ne peut pas remplacer tous les B/I fait au hasard par des EM/STRONG : c'est du cas par cas. J'ai juste ? Dodoïste ^{[ dring-dring ]} 6 mai 2011 à 14:34 (CEST)

Pas tout à fait. B et I ont eux aussi un rôle sémantique qui leur est propre. C'est compliqué. L'essentiel est qu'aborder les contenus de WP en considérant qu'il y aurait un recyclage simple des B et des I actuels serait juste une énorme perte de temps pour de mauvais motifs. Disons qu'une idée à retenir avec prudence pourrait être : quand un élément au rôle sémantique plus évident que B ou I est possible, il est a priori préférable. Selon les cas, cela peut être notamment : cite, em, strong, dfn, dt... Parfois aussi, ce serait à l’inverse un anonyme span. Plutôt que de se dire « B et I, c'est pas bien, faisons cela à la place », il vaut mieux prendre le problème par l'autre bout, comme en se disant par exemple « Où sont les titres d'oeuvres, je sais que ça se balise avec cite? ». Après, il restera tout un tas de B et de I à traiter, mais ce sera déjà plus simple. Cordialement, --Lgd (d) 6 mai 2011 à 14:47 (CEST)

Est-ce qu'on utilise l'élément samp ?

J'anticipe la prochaine question de Dodoïste .

Réponse : on peut. <samp>Foo</samp> donne Foo.

Cela sert à baliser l'« output » d'un programme informatique. Typiquement, dans les articles qui parlent d'« hello world », par exemple. Ou encore quand on écrit que « le code {{lang|en|foo}} donne foo », sous la forme

« le code <code>{{lang|en|foo}}</code> donne <samp style="font-family:sans-serif;">{{lang|en|foo}}</samp> »

. Mais bon, moi, je cacherais ça sous le tapis... Cordialement, --Lgd (d) 6 mai 2011 à 11:23 (CEST)

On peut aussi utiliser var et kbd, tant qu'on y est, mais le tapis commence à être un peu encombré (quoique kbd pourrait être utile dans certains articles) Litlok (m'écrire) 6 mai 2011 à 13:33 (CEST)

Ah non, je m'insurge, kbd est déjà utilement déployé dans Modèle:Touche Modèle:Gniark gniark. Cordialement, --Lgd (d) 6 mai 2011 à 13:45 (CEST)

Moui, l'intérêt est plutôt limité. Comme pour cite, c'est pour moi évident que si on s'en sert c'est dans les tréfonds d'un modèle, sans que l'utilisateur moyen le sache. Dodoïste ^{[ dring-dring ]} 6 mai 2011 à 14:39 (CEST)

Exactement. Cordialement, --Lgd (d) 6 mai 2011 à 14:40 (CEST)

{{lang}}

Bonjour. Suite à une discussion avec Lgd (d · c · b), d'abord au sujet de l'article overclocking, puis plus générale, je me tourne vers vous pour obtenir plus d'informations sur l'usage du modèle {{lang}}. Si j'ai bien compris (sinon il se fera un plaisir de rectifier ), pour Lgd ce modèle est principalement utile pour améliorer la prononciation du mot lorsque l'article est lu par un mécanisme automatique. J'ai une objection à cela : pour moi le mot « overclocking » (qui est pour moi évidemment un mot du français, même s'il a été emprunté à l'anglais) se prononce en français très différemment d'en anglais, tout comme d'ailleurs n'importe quel mot, puisque la plupart des français ne maitrisent pas l'accent anglais (ou plutôt un des accents). D'autre part, l'utilisation de ce modèle alourdissant, je trouve, significativement les articles, j'ai le sentiment qu'il ne devrait être utilisé que pour une très bonne raison. À vous . Freewol (d) 6 mai 2011 à 21:15 (CEST)

Pardonnes moi Lgd, et n'hésites pas à me dire si je me mêle de ce qui ne me regarde pas. Je rejoins Lgd dans ses propos : pour exemple voici la prononciation de overclocking par le TTS de google en français et en anglais. Notez que la partie over se prononce en synthèse vocale française [ovɛʀ] et non [ovœʀ] comme c'est le cas en anglais, ce qui est sa prononciation en français aussi. L'exemple de Paella n'est par contre pas valable : le TTS francophone le prononce correctement : [paɛla], tandis que l'hispanophone le prononce [pɑja]. Bonne journée. Cordialement, Micthev ^{(discuter ⇐ /!\)}, le 9 mai 2011 à 19:53 (CEST)

Je m'immisce à mon tour. Micthev, j'imagine que tu voulais dire « Je rejoins Lgd Freewol dans ses propos » puisque ton exemple démontre qu'overclocking est reconnu comme un mot français par le TTS de google, et prononcé correctement. Je viens de faire l'essai avec espeak, c'est également le cas. Je pense donc comme Freewol que l'utilisation du modèle {{lang}} dans ce cas particulier n'est pas opportun. Skippy le Grand Gourou (d) 12 mai 2011 à 11:03 (CEST)

Non du tout bien au contraire, over doit se prononcer [ovœʀ] (oveur) et non [ovɛʀ] (ovaire) contrairement à ce que fait actuellement la version francophone. Micthev ^(discuter), le 12 mai 2011 à 11:44 (CEST)

Oui, je m'en suis rendu compte après coup. Ceci étant, je ne sais pas ce qui est le plus dommageable : le fait que la première moitié du mot soit prononcé [ovɛʀ] au lieu de [ovœʀ] (ce qui peut par ailleurs différer d'un TTS à l'autre et/ou faire l'objet d'améliorations futures des TTS) ou bien le fait que la prononciation à l'anglaise ajoute des intonations non utilisées en français. Par ailleurs je ne lis pas l'API, mais le wiktionnaire indique /ɔ.vœʁ.klɔ.kiɲ/ quand un dictionnaire anglophone indique /ˌəʊvəˈklɒkɪŋ/ Skippy le Grand Gourou (d) 12 mai 2011 à 12:00 (CEST)

Plus j'y pense, plus je suis contre cet usage du modèle. En effet, et toujours si j'ai bien compris l'argumentaire, on devrait remplir l'article overclocking d'appels au modèle {{lang}}, juste parce que certains logiciels de synthèse vocale ne sauraient pas comment on prononce « overcloking » en français ? Il me semble que le travail est à faire en amont, chez les développeurs de ces logiciels, pas dans les articles de Wikipédia. Pour moi, le seul usage correct de ce modèle serait de ce type :

• « l'ingénieur a déclaré {{Citation|{{lang|en|''This overclocking allows ...''}}}} ».

Cordialement, Freewol (d) 12 mai 2011 à 12:49 (CEST)

Le travail en amont a déjà été fait autant que possible. L'intérêt du logiciel d'une synthèse vocale est justement qu'elle es programmée pour prononcer l'immense majorité des mots d'une ou plusieurs langues correctement. Certaines exceptions notables sont ajoutées. Mais tu comprendrais bien que la liste d'exceptions deviendrait vite très longue si tous les mots étrangers qui ont une prononciation à la française devaient être pris en compte. Il semble bien plus correct sémantiquement parlant d'indiquer dans le texte quel est la prononciation attendue.

Surtout, nous ne faisons pas cela pour les sythèse vocales, qui ne sont qu'un outil. Nous faisons cela pour les 61'000 aveugles et les 146'000 malvoyants profonds de France. Je cite la France car une étude précise a évalué le nombre d'aveugles, ce qui n'a pas été fait dans d'autres pays comme la Suisse par exemple. Dodoïste ^{[ dring-dring ]} 12 mai 2011 à 23:21 (CEST)

Mais les malvoyants utilisent la synthèse vocale, non ? Et non, je ne comprends pas que les outils ne soient pas capables de s'adapter à l'évolution d'une langue (surtout que le mot « overclocking » est maintenant utilisé en français depuis au moins 10 ans, ce n'est pas vraiment un mot intégré récemment), et cela ne me semble toujours pas une raison suffisante pour remplir un article avec le modèle en question, désolé. Cordialement, Freewol (d) 13 mai 2011 à 09:50 (CEST)

PS : « overclocking » est un mot français, même s'il existe un mot anglais s'écrivant pareil et ayant le même sens. Attention à ne pas confondre les deux. Preuve : « Côté fréquence, le modèle annoncé par VIA atteint 1.2 GHz et dispose d’un overclocking automatique permettant de monter à 1.46 GHz en fonction du TDP. »

Bon, finalement je ne ferai pas de réponse sur le fond. j'ai arrêté de lire après « « overclocking » est un mot français, même s'il existe un mot anglais s'écrivant pareil et ayant le même sens ». Je suis désolé, mais je n'ai pas trop de temps à perdre avec les marronniers autour des querelles sur la francisation, qui me semblent le coeur de l'intervention de Freewol. Se battre pour des questions de point de vue idéologiques ou polémiques à la surface du contenu quand il s'agit d'un simple balisage technique serait dérisoire.

Je ferai juste une remarque pour compléter les explications avisées de Dodoïste : comme sur d'autres points des normes d'accessibilité, les métadonnées de langue sont loin d'avoir pour cible uniquement les handicapés. En réalité, on ne roule pas spécialement pour les handicapés : ce sont des métadonnées utiles à différents outils, tels que ceux d'indexation, de référencement, de réutilisation ou de traduction du contenu. L'accessibilité, dans ce domaine, n'est qu'un levier.

Pour conclure, je suggère plutôt à Freewol d'envisager une PDD sur l'usage de ce modèle s'il y tient absolument, tout en lui disant clairement que ce serait une idée très peu constructive : c'est en effet un cas assez remarquable et un peu inattendu de nécessité de balisage sémantique que les contributeurs ont « intégré » à leurs pratiques sans souci ni difficultés. Il est inutile, une fois encore, de vouloir réparer ce qui n'est pas cassé. Cordialement, --Lgd (d) 13 mai 2011 à 10:37 (CEST)

@ {{lang|en|Freewol}} : tu trouves « ce modèle alourdissant significativement les articles ». 1/l'alourdissement n'est visible que côté code et invisible pour le lecteur. 2/dans une ville, les rampes d'accès, rambardes de protection et autres escaliers de secours alourdissent peut-être l'architecture mais ces ajouts sont nécessaires à l'accessibilité de tous et doivent passer avant toute considération esthétique. En attendant que overclocking soit intégré officiellement au Dictionnaire de l'académie française, placer des balises {{lang}} est une bien petite concession que nous pouvons faire pour assurer un confort de lecture à ceux qui peuvent se retrouver confrontés à des trucs du genre « deuzingue » ou « smalletalque ». --Amicalement, Salix ( converser) 13 mai 2011 à 11:35 (CEST)

Je vais continuer à être un peu direct : la question de « l'alourdissement » est pour le moins légèrement posée. On parle ici d'une métadonnée sémantique, pas d'un gadget dispensable. L'alourdissement est une question à poser d'abord à propos des multiples modèles cosmétiques (modèles « nobr »), typographiques (modèles d'espaces insécables, entre autres), de navigation à pertinence incertaine (dates) ou en partie décoratifs (drapeaux), sur lesquels l'économie devrait porter en premier lieu si on souhaite ce genre d'économie. --Lgd (d) 13 mai 2011 à 13:34 (CEST)

Réf dans titre de tableau : bonne ou fausse bonne idée ?

Salut. Est-ce qu'une réf (<ref></ref>) dans un titre de tableau (|+) nuit à l'accessibilité ? Voir ici : Pat Rupp#Statistiques en carrière. --'toff ^[discut.] 7 mai 2011 à 04:09 (CEST)

Cela ne pose pas de problème. Cordialement, --Lgd (d) 7 mai 2011 à 08:27 (CEST)

Question subsidiaire : et pourquoi j'y ai pas pensé avant ? je suis sûr que t'a pas de réponse !!! --'toff ^[discut.] 7 mai 2011 à 10:31 (CEST)

<dfn> ou pas?

Bonjour, sur cet article j'ai constaté l'usage de ce modèle pour mettre en gras le nom du sujet dans le résumé introductif. Est-ce une pratique encouragée? Prosopee (d) 7 mai 2011 à 09:40 (CEST)

La question est en cours d'examen dans Wikipédia:Prise de décision/Adoption du balisage dfn dans les introductions d'articles. Pour le moment, il faut remplacer par le modèle {{terme défini}} (voir Aide:dfn), afin qu'on puisse au moins détecter ces usages anticipés (et les corriger le cas échéant par la suite). Cordialement, --Lgd (d) 7 mai 2011 à 09:52 (CEST)

Ok, je pense que le décision finale sera reprise ici même, que je puisse l'ajouter au guide de relecture? Cordialement, Prosopee (d) 7 mai 2011 à 11:57 (CEST)

Je m’étais noté de te prévenir le moment venu, si nécessaire. Cordialement, --Lgd (d) 7 mai 2011 à 12:10 (CEST)

Nouvelles détections de codes de langue erronés

Bonjour,
Quelques nouvelles détections d'erreurs lors de l'utilisation du modèle {{lang}} ont été ajoutées. Les pages à corriger sont listées dans Catégorie:Page avec code de langue invalide.

Le gadget accessibilité a également été mis à jour pour aider à repérer ces erreurs dans les pages quand vous activez le test « Langue » (un message d'erreur rappelant la correction à apporter s'affiche juste avant l'expression qui a un code de langue erroné). Pensez à actualiser le cache de votre navigateur pour disposer de cette nouvelle fonctionnalité.

Je reproduis ici le tableau des erreurs et corrections, en cas de questions à ce propos :

erreurs détectées

Code erroné	langue	Correction
paramètre vide		Renseigner le code de langue ou supprimer le modèle Peut être dû également à l'écriture de {{lang}} au lieu de {{m|lang}}
gr	grec	el pour le grec moderne (après 1453) grc pour le grec ancien (avant 1453)
lu	luxembourgeois	lb
mul	langues multiples	Supprimer le modèle
oci	occitan	oc
und	langue indéterminée	Supprimer le modèle

Cordialement, --Lgd (d) 7 mai 2011 à 10:08 (CEST)

J'ai corrigé ce qui n'était pas dans l'espace MAIN (sauf un cas un peu tordu), mais comme manier le fouet satisfait un de mes vieux fantasmes personnels, je vous laisse les corrections restantes . Cordialement, --Lgd (d) 7 mai 2011 à 12:25 (CEST)

J'ai corrigé les articles dans MAIN, certains modèles comme {{youtube}} ou {{ouvrage}} sont également détecté car ils utilisent {{lang}}. Il reste Sephiroth (Final Fantasy) pour lequel je ne trouve pas l'erreur restante (ou les erreurs), Ithkuîl une langue construite pour laquelle il n’existe probablement pas de code ISO, et Écosse et gaélique écossais pour lesquels je ne suis pas compétent pour corriger. A2 (d) 7 mai 2011 à 16:11 (CEST)

J’ai mis « art » (langue artificielle) comme code iso2 pour Ithkuîl, d’après enwiki. A2 (d) 7 mai 2011 à 16:14 (CEST)

Il est préférable d'éviter les codes génériques en l'absence d'un code pour cette « langue ». Cordialement, --Lgd (d) 7 mai 2011 à 16:44 (CEST)

Catégorie:Page avec code de langue invalide, on ne s'en lasse pas.

Bonjour,
La désormais bien connue catégorie:Page avec code de langue invalide vient de faire une grosse poussée de croissance avec l'ajout de la détection des emplois du modèle {{Citation étrangère}}... sans indication de la langue de la citation (c'est ballot, évidemment, mais apparemment très répandu). La détection a également été ajoutée au gadget accessibilité.

Bon courage aux courageux. Cordialement, --Lgd (d) 13 mai 2011 à 14:32 (CEST)

Bug sur wikiversité

Bonjour,

Juste pour vous dire que quand j'active la fonction « Accessibilité : affiche une palette d'outils facilitant la vérification de l'accessibilité d'une page (aide du gadget). » sur wikiversité le menu d'édition ne s'affiche plus quand je lance une modification de page. Je suis sur Firefox et Ubuntu 11.04. Si le gadget ne fonctionne toujours pas sur Firefox peut-être faut-il alors l'indiqué dans le menu préférence utilisateur. Bien à vous, Lionel Scheepmans (✉) , le 16 mai 2011 à 19:09 (CEST)

Bonjour,
J'ignorais que le gadget accessibilité avait été importé sur wikiversité, à vrai dire . IL ne présente pas de bug de ce type ici à ma connaissance. A priori, il s'agit d'une question de compatibilité avec des scripts ou un balisage propres à Wikiversité. Je tâcherais de regarder cela. Cordialement, --Lgd (d) 16 mai 2011 à 21:00 (CEST)

Je n'ai pas ce bug sur la Wikiversité avec Firefox 4.0.1 et Windows 7. JackPotte ($♠) 16 mai 2011 à 21:26 (CEST)

Il y effectivement plusieurs soucis. La première chose à faire : mettre à jour les fichiers js et css du gadget à partir de ceux de Wikipédia. Un bug se produit à cause du ressource loader de mediawiki qui ne gère pas correctement la présence de chevrons dans la CSS actuellement en place sur wikiversity. Cordialement, --Lgd (d) 17 mai 2011 à 07:03 (CEST)

Écriture différente de la prononciation

Bonjour à tous, je travaille actuellement sur le fait de rendre au possible accessibles les articles sur les saisons 1 et 2 de X Factor, et ce n'est pas une mince affaire . J'ai une question bête et méchante : comment faire pour qu'un lecteur d'écran (ou autre) lise l'expression F@n Factor en tant que Fan Factor, le modèle {{Abréviation discrète}} me semblant dans ce cas inapproprié. Merci par avance. Micthev ^(discuter), le 18 mai 2011 à 15:25 (CEST)

Du point de vue accessibilité, c'est une syntaxe cryptique (comme le SMS, le leetspeak, etc.) auquel il faut fournir une alternative (qui ne concerne pas les lecteurs d'écran spécifiquement). Le balisage abbr est en effet exclu. La graphie « correcte » est simplement à préciser entre parenthèses au fil du texte dans l'introduction.

Là où c'est plus embêtant, c'est quand il s'agit aussi du titre de l'article (exemple) : là, malheureusement, c'est mort pour rectifier celui-ci compte-tenu de l'attachement des wikipédiens à ce genre de fantaisies (n'en demandons pas trop pour en consolider un peu . Cordialement, --Lgd (d) 18 mai 2011 à 21:32 (CEST)

Merci, si je suis donc ta logique, confirme moi si je ne me trompes pas, la correction à apporter est donc tout simplement celle-ci ? Micthev ^(discuter), le 18 mai 2011 à 22:40 (CEST)

Catégorie:Page avec code de langue invalide, saison 4, the return

Bonjour,
Devinez... L'incontournable catégorie:Page avec code de langue invalide revient pour un nouvel épisode avec deux nouvelles erreurs détectées :

• le code du japonais n'est pas « jp » mais « ja » ;
• celui du danois n'est pas « dk » mais « da ».

Merci à Utilisateur:Visite fortuitement prolongée qui a eu l'idée initiale de ces deux détections.

Cordialement, --Lgd (d) 13 mai 2011 à 14:32 (CEST)

Quelques questions d'accessibilité à propos de Lois constitutionnelles de 1875 (d · h · j · ↵ · AdQ · Ls)

Bonjour à tous,

J'ai rédigé il y a longtemps un article devenu AdQ en 2006 (lois constitutionnelles de 1875), que j'ai refondu quelques temps plus tard entièrement, l'augmentant, et, je l'avoue, le complexifiant, au passage. J'aimerais essayer maintenant de l'améliorer au niveau de son accessibilité. Certaines choses sont évidentes (alt sur les images, transformation de ;L'interpellation, par exemple, en un vrai titre, etc.), mais quelques points me posent problème.

1. D'abord, le plus évident : j'avais trouvé utile, à l'époque, de compléter l'article, à différents moments, par des textes extraits d'ouvrage de l'époque (à cet endroit par exemple). Cette pratique répond-t-elle aux normes d'accessibilité ? Si non, quelles améliorations réaliser pour la rendre plus accessible ?
2. Ensuite, relativement évident aussi : lorsque j'avais réécrit l'article au départ, en 2006, les règles d'accessibilité n'étaient pas connues (ni même fixées ?), et j'avais trouvé "malin" de remplir le vide laissé par une table des matières longue avec deux textes de l'époque (ceux de Victor Hugo et Léon Gambetta à droite du sommaire). Je songe sérieusement à utiliser un sommaire compact ({{sommaire}}), et donc, à bazarder lesdits textes, qui restent intéressants toutefois, dans une boîte déroulante. Alors, simplement : une boîte déroulante est-elle accessible ? Cela vaut pour deux ou trois autres boîtes déroulantes dans l'article d'ailleurs.
3. Dernière question qui me vienne à l'esprit pour l'instant : une image comme celle-ci, qui n'est pas la seule de son type dans l'article, va demander une alternative relativement longue. Que faire dans ce genre de cas — nous serions bien au-delà des quelques 120 caractères préconisés...

Merci pour votre aide  !

Mandrak (Discuter), 31 mai 2011 à 20:34 (CEST)

Bonsoir,

Je dirais (hop !) :

1. Pour le moment, remplacer les <div align="right" class="thumb tright"><div class="thumbinner" style="width:300px;"><div class="thumbcaption"><p align=justify>... par le modèle {{Encadré}} : ce n'est pas encore accessible, mais au moins ça le deviendra facilement et automatiquement quand on (je, sans doute) aura le courage de s'attaquer à ce modèle pour corriger son code (et quelques-uns de ses usages). Le souci n'est pas la présence de ces encadrés, c'est qu'il s'agit de citations qui ne sont pas balisées comme tel dans le code HTML, ce qu'on fera proprement via le modèle en temps voulu.
2. Avant tout, enlever froidement la citation du Nouveau Larousse Illustré placée en exergue, non pas pour des questions d'accessibilité, mais pour respecter simplement l'usage qui exclue les exergues des articles de WP. Ensuite, Gambetta et Hugo ne sont pas un souci majeur, même si cet article gagnerait sans doute à être allégé en « encarts » d'une manière générale, toujours pour des raisons éditoriales (et non d'accessibilité) : les citations au fil du texte, contextualisées, sont souvent préférables à des citations « illustratives ».
   Sinon, les boîtes déroulantes ne posent pas de problème d'accessibilité majeur et peuvent être utilisées sans état d'âme de ce point de vue. Par contre, là encore, éditorialement... Bof dans ce cas de Gambetta et Hugo.
3. Les alternatives d'images sont actuellement une sacrée épine. Solutions possibles :
   1. Rédiger une alternative synthétique, qui résume non pas l'image mais l'information majeure qu'elle apporte dans son contexte, en étant concis sans se fixer absolument à 20 caractères près sur la limite des 120 ;
   2. Ou bien veiller à ce que le contexte de l'image (les paragraphes du corps de l'article en regard desquels elle se trouve) apporte toute l'information équivalente, et faire une alternative du type alt="Schéma des relations théoriques des pouvoirs sous la Troisième République expliquées ci-après" (en général, l'image en thumb précède le texte dans l'ordre du code).
   3. Ou encore rédiger dans la page de l'image une alternative complète reproduisant toute l'information (Il y a un modèle approprié que je ne retrouve pas dans l'immédiat, et peu importe alors la longueur de la description), synthétiser dans la légende du thumb et enfin mettre un alt="Consulter la description de cet image résumée ci-dessous".

Pour le dernier point, la seconde solution me semble la plus appropriée ici. La troisième a l'avantage théorique de fournir quelque-chose qui serait réutilisable immédiatement et aisément dans d'autres articles.

Cordialement, --Lgd (d) 31 mai 2011 à 21:00 (CEST)

1. Noté pour {{encadré}}.
2. Autre temps, autres mœurs... c'est vrai qu'à l'époque l'exergue n'avait pas choqué. Elle apporte quelque chose, je vais voir si je peux l'utiliser ailleurs dans le texte, mais, évidemment, elle doit disparaître de là, à mon grand regret (snif). Pour les encarts de Hugo et Gambetta, je réévaluerai leur "potentiel éditorial" (il me semble que, en 2006, la citation de Hugo, à l'époque la seule, était carrément une image... autre temps, autres mœurs !).
3. Je sentais bien que cette histoire d'alternative à des schémas logiques allait m'empoisonner la vie. La solution 2 me semble également la meilleure, tout simplement parce que la 3 demande de rédiger une synthèse en légende, ce qui me semble être une véritable gageure. Mais la 1, vue sous l'angle de rédiger un résumé de l'information importante qu'elle apporte, est intéressante également. Je vais méditer ça.

Autre question, qui vaut d'ailleurs pour Crise du 16 mai 1877 (d · h · j · ↵ · BA · Ls) que je viens de retravailler un peu question accessibilité (pas parfait encore, cela ne fait aucun doute) : les images comme cette belle photo de Clemenceau, quelle alternative leur donner ? J'ai hésité, dans crise du 16 mai 1877, entre décrire carrément à quoi ressemble un personnage photographié / peint, ou simplement mettre, comme je l'ai fait pour Gambetta, "Peinture représentant Léon Gambetta, debout, les mains dans les poches de son pantalon, le corps, visage compris, tourné vers la gauche."

Mandrak (Discuter), 31 mai 2011 à 21:21 (CEST)

C'est toute la difficulté de la rédaction d'une alternative textuelle. C'est un exercice éditorial beaucoup plus que technique, qui amène à une question toujours intéressante : pourquoi cette image est-elle là, dans ce contexte et qu'est-elle censée dire ? C'est l'une des raisons pour lesquelles je ne crois définitivement pas à la solution consistant à demander systématiquement aux contributeurs de rédiger une alternative pour chacun des quelques millions de thumbs présents dans les articles...

Plus prosaïquement : les alternatives actuelles dans Crise_du_16_mai_1877 me semblent remarquablement appropriées. Peut-être peut-on y introduire un quart de poil de « perception » de l'image, quitte à prendre le risque d'un peu de point de vue personnel. Par exemple, Gambetta frappe par une certaine désinvolture apparente, tandis que dans ton exemple de Clemenceau, il me semble difficile d'éviter un qualificatif comme « hautain » ou « impérieux » (subjectif, ai-je dis ). L'exercice est difficile... Mais encore une fois, les alternatives actuelles sont déjà suffisantes, ce serait juste une amélioration à risquer.

En fait, les schémas sont encore un des cas les plus simples : polysémie réduite, disons .

Cordialement, --Lgd (d) 31 mai 2011 à 21:38 (CEST)

Pour détailler un peu ce qui me semble approprié, du point de vue de quelqu'un qui n'aurait accès qu'à ces alternatives (je précise que j'ai commencé par jouer le jeu et par consulter cet article dans un lecteur d'écran ; sans avoir vu les images, donc) :

• le type d'illustration (gravure, peinture, photographie) est précisé. C'est une donnée pertinente du point de vue chronologique ;
• un détail comme la présence des décorations de Mac Mahon différencie cette représentation des autres ;
• la position assise ou debout est également un trait remarquable ;
• l'austérité différencie également le portrait de Grévy ;
• les mains dans les poches de Gambetta sont encore un trait remarquable.

Les traits saillants me semblent donc bien retranscrits. Cela dit, il faudrait un article sur la représentation officielle des hommes politiques, ses usages, ses manières, ses modes et ses significations . Cordialement, --Lgd (d) 31 mai 2011 à 21:46 (CEST)

Merci pour toutes ces suggestions et précisions utiles ! Je vois mieux comment faire mes alternatives textuelles — même si le mieux serait encore, pour les lecteurs qui n'ont jamais vu de photographies de Jules Dufaure ou Albert de Broglie, de décrire entièrement le personnage, à la manière d'un romancier, mais là évidemment ça devient compliqué...

Une dernière question (sans rapport immédiat avec l'article lui-même) : tu as écrit "C'est l'une des raisons pour lesquelles je ne crois définitivement pas à la solution consistant à demander systématiquement aux contributeurs de rédiger une alternative pour chacun des quelques millions de thumbs présents dans les articles". Est-ce à dire simplement que certaines images n'ont pas leur place dans l'article, ou est-ce à dire que certaines images, intrinsèquement, sont insusceptibles de description alternative ?

Mandrak (Discuter), 31 mai 2011 à 21:56 (CEST)

Ce n'est pas tout à fait cela. L'idée serait la suivante (elle tourne résolument le dos à la rédaction au cas par cas d'une alternative propre à chaque thumb ajouté à un article) :

1. automatiser la génération d'une alternative textuelle par défaut mais modifiable au cas par cas du type « Consulter la description de cette image brièvement décrite ci-après » : automatisation raisonnée.
2. parier sur ce qui est déjà dans les usages éditoriaux, ce que les contributeurs font déjà, c'est à dire donner une légende à chaque image (après, on peut avoir une bonne pratique incitant à résumer l'information majeur dans la légende) : s'appuyer sur l'existant.
3. faire rédiger des descriptions d'images dans les pages de celles-ci, et non dans les alternatives, ce qui a trois avantages immédiats :
   • la description en question est affichée, visible : c'est gratifiant de la rédiger ou de l'améliorer. Cela a un sens éditorial immédiatement perceptible pour les gens qui s'intéressent aux images. Bref, c'est au moins un peu motivant. Alors que se casser les noyaux à rédiger des attributs dont le contenu est invisible juste pour respecter des bonnes pratiques d'accessibilité... : sortir l'accessibilité du ghetto en en faisant un ressort d'amélioration plus large.
   • la description générique est réutilisable et de fait réutilisée pour chaque emploi de l'image dans des contextes différents : mutualiser, industrialiser.
   • C'est bon et même nécessaire pour une bonne indexation des images : l'accessibilité est là encore un levier de la qualité globale, et on mutualise les bénéfices.

L'accessibilité y trouvera pleinement son compte, mais les contributeurs et WP aussi. Bien-sûr, cela laisse la place à beaucoup d'imperfections ponctuelles, mais la qualité et l'accessibilité sont de toutes façons des questions d'amélioration progressive et continue.

Après, oui : il y a de nombreux cas où une image n'apporte en fait à peu près rien en terme d'information dans un article. Wikipédia fonctionne souvent sur un principe « accumulatif », ce qui donne beaucoup de bruit pour peu de signal dans des cas comme celui des images (cf les galeries souvent en surcharge pondérale avec des images en doublon côté information). Mais ce n'est pas le souci majeur, même si c'est assez évident quand on aborde la question en terme d'alternative et de sens des images.

Cordialement, --Lgd (d) 31 mai 2011 à 22:18 (CEST)

C'est effectivement une évolution assez profonde proposée là. La solution de rédiger des descriptions complètes et réutilisables dans les pages des images me semble véritablement excellente, et de nature à faire gagner un temps considérable — surtout dans un contexte où l'utilisation de alt sera de plus en plus répandu pour l'accessibilité de Wikipédia. D'une manière générale, il est impressionnant de voir que, tout en cherchant à améliorer l'accès d'une minorité d'utilisateurs à l'encyclopédie, on améliore la présentation, le contenu, la façon dont Wikipédia apparaît dans les moteurs de recherche, etc. Tout le monde y gagne vraiment. Mais j'imagine que l'évolution que tu proposes est un projet de grande ampleur, qui promet quelques discussions "intéressantes" dans la communauté .

Mandrak (Discuter), 31 mai 2011 à 22:38 (CEST)

« D'une manière générale, il est impressionnant de voir que, tout en cherchant à améliorer l'accès d'une minorité d'utilisateurs à l'encyclopédie, on améliore la présentation, le contenu, la façon dont Wikipédia apparaît dans les moteurs de recherche, etc. » : à vrai dire, c'est exactement le coeur de mon métier IRL .

Disons qu'il faut déjà parvenir à formuler correctement la chose, et que notre échange m'a donné un coup de pouce utile au bon moment, ce dont je te remercie. Pour le déploiement, il y avait une option passant d'abord par le développement (bugzilla toujours laborieux, accessibility initiative hélas apparemment en panne) car il y aurait des choses à faire de ce côté avant de présenter la ligne de conduite à suivre aux contributeurs (« les développeurs ont fait que... Maintenant, n'hésitez pas ! »). C'est la voie que j'envisageais jusqu'ici.

Il y a une seconde voie, dont je me dis qu'après tout elle a toujours eu ma préférence : la politique des petits pas et du levier à la base : mettre en oeuvre ici, et là ; amender en ce sens quelques pages de recommandations et de bonnes pratiques ; pousser à droite ou à gauche pour que cela commence à se faire. C'est tentant. Cordialement, --Lgd (d) 31 mai 2011 à 22:52 (CEST)

D'autant que, dans l'immédiat, il y a déjà dans au moins dans quelques AdQ de consistantes alternatives (beaucoup, beaucoup trop longues) qui ne demandent qu'à être déportées dans les pages des images correspondantes... Heu... tu ne m'avais pas proposé, dans ma pdd, un concours fort précieux d'une petite main  ? Cordialement, --Lgd (d) 31 mai 2011 à 23:02 (CEST)

Si j'ai pu avoir une utilité quelconque .

Quelque chose me dit que la "politique des petits pas" est bien souvent la meilleure : plutôt que de tout chambouler en une seule fois, on avance lentement. Wikipédia fonctionne d'ailleurs beaucoup comme ça, les choses se font peu à peu, à l'image de l'accessibilité.

Pour les petites mains, j'ai proposé en effet ! Passe sur ma PDD si tu le souhaites, là on dévie quand même du but de cette page...

Mandrak (Discuter), 31 mai 2011 à 23:06 (CEST)

On ne dévie pas (et encore merci pour tes contributions), on est au coeur de cet atelier. Mais j'avoue que là, je suis peu canné. Je vais revenir là-dessus ici dans la semaine pour expliquer le truc, fournir les liens vers les articles en questions, le modèle, etc. Ce sera bien d'avoir d'autres avis, aussi. Cordialement, --Lgd (d) 31 mai 2011 à 23:34 (CEST)

Couleurs criades - Palette

Bonjour !Bonjour

Vous m'avez été recommandés par un utilisateur à propos des couleur de la Modèle:Palette Créatures lacustres. La première fois, elle était verte. et jugée criarde et inaccessible. Une deuxième, même problème. J'aimerai bien qu'elle soit verte (différentes nuances, tons).

Alors, je vous demande si vous pouviez faire quelque chose contre les contrastes et tout ce qui s'y rapporte. Merci ! -- Mit freundlichen Grüßen, Morphypnos ^{[Dieu mortellement ennuyeux...]}. 2 juin 2011 à 13:49 (CEST)

Avant tout, quel serait la raison du vert ? Y a-t-il une signalétique de couleur réunissant plusieurs palettes, sujets ou articles qui serait nécessaire au lecteur ? A priori, tout ce ce que je trouve dans ce domaine, c'est le choix (déjà discutable mais bon) fait par le Projet:sport : du vert #99CC99 pour une partie de ses infobox et modèles. Mais je vois évidemment mal le rapport entre les créatures lacustres et le sport, je l'avoue.

Cela dit, si tu cherches absolument un autre vert qui ne pose pas de problème majeur de contrastes avec le noir du texte et le bleu des liens, celui du projet sport est valide. Sinon, tu trouveras les liens vers l'outil nécessaire à la mesure d'un contraste de couleur dans Wikipédia:Atelier accessibilité/Bonnes pratiques#Choix_de_couleurs_et_contrastes. Il est relativement facile à utiliser.

Mais sinon, cette palette est très bien avec ses couleurs par défaut, une couleur spécifique n'ayant ici aucun bénéfice pour le lecteur. Cordialement, --Lgd (d) 2 juin 2011 à 14:15 (CEST)

Merci beaucoup ! Pour le vert, la raison est tordue : l'eau, le lac, les algues, monstres (amalgame : reptile qui donné écailles qui donnent le vert [j'avais bien dit que c'était tordu]). — Le message qui précède, non signé, a été déposé par Morphypnos (discuter)

Ce n'est pas tordu, c'est simplement inutile pour le lecteur en terme d'ergonomie, de design et de navigabilité, et c'est risqué en termes d'accessibilité. Donc, à éviter. Si quelqu'un souhaite s'essayer au design, ce n'est pas ici qu'il faut le faire, mais par exemple dans un site personnel... --Lgd (d) 2 juin 2011 à 14:47 (CEST)

Modèle:Infobox Tournoi de golf

Bonjour, en regardant le modèle Modèle:Infobox Tournoi de golf pour régler un problème d'accessibilité ( ligne de titre apparaissent en rouge avec le gadget ), je suis tombé sur le Modèle:Infobox/Sous-titre qui est protégé et selon moi, semble être la cause du problème d'accessibilité. Je remplacerais : <th colspan par <th scope="row" colspan . Est-il possible de valider cette correction et de la faire si possible. Cordialement. Philippep (d) 2 juin 2011 à 14:41 (CEST)

Non, ce ne serait pas une correction valide ni utile. L'attribut scope (et ce serait scope=col, pas row, ici) n'est utilisable que pour un entête qui s'applique à la totalité de la ligne ou de la colonne concernée. Ici, ces « sous-titres » sont des entêtes de colonnes qui ne s'appliquent qu'à une partie de celle-ci (le bloc de lignes qui les suit). Mettre un scope sur ces entêtes conduirait, dans cette infobox, à faire dire par un lecteur d'écran que la ligne « Longueur » relève des informations sur le « Record de pointage du Tournoi », ce qui serait dénué de sens.

La résolution de ce problème (et de plusieurs autres du même type) nécessite une refonte complète des infobox actuelles, qui font un usage erroné des tableaux de données. Cordialement, --Lgd (d) 2 juin 2011 à 14:45 (CEST)

Pour mon info personnelle

Salut. Une petite question pour mon info personnelle, comment un lecteur d'écran lit-il ce genre de tableau (comment est interprété le rowspan ?) :

x	y
a	b
	c

• ab - c

ou

• ab - ac

--'toff ^[discut.] 5 juin 2011 à 20:40 (CEST)

A vrai dire, on ne consulte que rarement un tableau de donnée « linéairement » dans un lecteur d'écran : on se déplace de case en case à sa guise, en consultant donc une cellule à la fois. Mais en lecture linéaire, en y allant ligne à ligne, le rendu sera « ab - c ». En y allant en lecture intégrale, le rendu sera « a - b - c ».

En lecture non linéaire (mode tableau de Jaws par exemple), le contenu de « a » sera rappelé (à la demande) quand on consulte « b » ou « c » si « a » est en même temps un ! scope=row" (ce qui n'est pas le cas dans ton exemple, et qui n'est pas forcément nécessaire). Cordialement, --Lgd (d) 5 juin 2011 à 20:57 (CEST)

Bien compris. Merci. --'toff ^[discut.] 5 juin 2011 à 21:09 (CEST)

{{Infobox/Ligne donnée}}

Re moi. En tombant par hasard là-dessus avec le gadget activé, j'ai vu (du) rouge. Devra pas y avoir un TH au lieu du TD ? --'toff ^[discut.] 5 juin 2011 à 22:03 (CEST)

Si. De même que {{Infobox/Ligne donnée optionnelle}} et sans doute d'autres (en ajoutant les styles nécessaires pour ne pas déclencher un drame planétaire en modifiant le rendu...) Cordialement, --Lgd (d) 5 juin 2011 à 22:10 (CEST)

Bon, j'ai mis les TH sur les deux. D'ailleurs, ils y étaient à l'origine mais Wikialine (d · c · b) les a modifiés je ne sais pour quelle raison ? --'toff ^[discut.] 5 juin 2011 à 22:23 (CEST)

Pour que ce ne soit pas en gras, je suppose. Vu que maintenant, c'est en gras, je suppose aussi que tu aimes vivre dangereusement . Dans une infobox comme celle d'Anvers, il faut avouer que ça se voit beaucoup. Tu es sûr qu'un p'tit style="font-weight: normal;"... Hum ? Cordialement, --Lgd (d) 5 juin 2011 à 22:28 (CEST)

J'avais cru voir que c'était déjà en gras (et ça m'a pas choqué plus que ça sur un autre article). Bon, j'ai annulé mes modifs (je sais pas trop ou caser ton code)A voir plus tard. --'toff ^[discut.] 5 juin 2011 à 22:50 (CEST)

Pffff... ca m'avait pas choqué parce que l'article que j'avais pris comme modèle mettais en gras les titre a posteriori... Du coup, me basant sur lui, j'ai eu du mal à trouver la place du code... (quel con) Enfin, j'ai fais les modifs qui me semblent maintenant adéquates : [3] et [4]. J'espère ne pas avoir fait de bêtise. --'toff ^[discut.] 5 juin 2011 à 23:20 (CEST)

Une discussion sur les infobox de personne...

Bonjour, je vous signale l’existence de cette discussion sur les infobox de personne qui concerne de près l’atelier d’accessibilité. Tpt (d) 6 juin 2011 à 08:53 (CEST)

Métadonnées de livres

Je me permet de poser ici une question qui n’a pas directement attrait à Wikipédia mais à son projet-frère Wikisource. En effet il y a là une grande base de données de livres au format djvu associés à des métadonnées comme, par exemple, w:Livre:Say - Traité d’économie politique.djvu et je me demande s’il n’était pas possible utiliser un format comme Dubin Core pour insérer des métadonnées dans les pages html et ainsi permettre une meilleur accessibilité des données. Pour le Dubin Core qui fonctionne avec la balise <meta> il faudrait obligatoirement passer par javacript à part si l’on modifie l’extension ProofereadPages pour cela. Mes questions sont donc :

1. peut-on passer par javascript pour insérer des métadonnées ? Cela pose-t-il un quelconque problème ?
2. existe-t-il un autre format de métadonnées plus adapté à ce contexte et facilement déployable ?

Merci d’avance pour vos réponses, Tpt (d) 6 juin 2011 à 10:15 (CEST)

bonjour,

1. Les outils exploitant les éléments meta exploitent parfois le contenu généré via javascript, mais ce n'est pas suffisamment le cas pour être utile. Il faudra donc modifier l'extension.
2. Le Dublin Core est tout à fait pertinent ici.

Cordialement, --Lgd (d) 7 juin 2011 à 08:11 (CEST)

Merci, tu confirme ce que je pensait. Tpt (d) 7 juin 2011 à 11:05 (CEST)

Tableaux de versions logiciel

Bonjour, j'arrive de Discussion:LibreOffice en passant par Discussion Wikipédia:Atelier accessibilité/Bonnes pratiques ou on m'a indiqué cette page pour savoir où on pourrait centraliser le travail sur la bonne façon de faire (pour les tableau coloré en général j'imagine). La dernière réponse m'a fait remarqué que les modèles hyper courants que qui se retrouvent plus où moins repris dans toutes les langues ne respectent pas du tout les principe d'accessibilité, ce qui confirme a mon avis que ça serrais vraiment pas inutile. Sans trop connaître je vise une section dans le Projet:Charte graphique, et peut être un cahier des charges venant de cet atelier. Deux critère m'ont déjà été donné sur la page de discussion "bonnes pratique". :-) 14 juin 2011 à 09:42 (CEST)

Ca laisse froid, j'ai fait la page en question : Projet:Charte graphique/Tableau versions logiciels. :-) 17 juin 2011 à 20:17 (CEST)

???

Bonjour, quelqu'un pourrait m'expliquer sur ma PDD comment utiliser le gadjet Accessibilité, je ne comprends vraiment pas… Merci bien, Monday ^{[si vous voulez me parler, cliquer ici]} 16 juin 2011 à 19:22 (CEST)

Réaction bizarre du gadget à dfn

Salut. Je ne m'étais pas rendu compte de ça avant mais quand je vérifie dfn (<dfn> ou {{terme défini}}) avec le gadget il se produit une chose étrange : le premier clic produit l'effet désiré : mise en vert (supposition du deutéranope) du terme défini, deuxième clic : rien..., troisième clic : retour à la normale, quatrième clic : rien. En gros, dfn est sujet au double-clic ? --'toff ^[discut.] 21 juin 2011 à 06:21 (CEST)

Oui en effet, j'ai constaté le même bug. Sinon pour le vert tu supposes bien. Udufruduhu (d) 21 juin 2011 à 08:55 (CEST)

Il y a un souci, en effet. Il faut aussi revoir la détection d'erreur pour dfn (je ne devais pas être bien réveillé ce jour là). C'est sur ma todo, dès que possible cette semaine. Cordialement, --Lgd (d) 21 juin 2011 à 09:04 (CEST)

La semaine en question s'est un peu étirée. Mais disons que je vais profiter des congés d'été pour régler ça . Cordialement, --Lgd (d) 11 juillet 2011 à 09:57 (CEST)

Des infobox accessibles ? C'est en route

Bonjour,
Grâce à la collaboration précieuse du projet:Hockey sur glace et de quelques-uns de ses précieux piliers, un jeu de modèles permettant d'obtenir enfin des infobox accessibles est en cours de mise en place.

Pour le moment, on en est à l'ajout des styles nécessaires à Common.css et à des modèles dans mon espace personnel (Utilisateur:Lgd/Infobox V3 accessibles), qui vont bientôt être déplacés dans l'espace modèle puis mis en œuvre dans ce projet.

Pour tester la chose, pensez à actualiser le cache de votre navigateur. Tous vos retours et suggestions seront évidemment très bienvenus.

Si des gens ont des idées d'autres projets où rebondir, ce sera encore plus bienvenu.

Disons-le froidement: nous sommes à l'aube d'une nouvelle ère. Même que. Na.

Cordialement, --Lgd (d) 12 juillet 2011 à 12:54 (CEST)

On n'a pas tant collaboré que ça, on l'a surtout "poussé au cul" --'toff ^[discut.] 14 juillet 2011 à 07:48 (CEST)

Bravo ! Je vais suivre ça de près. Le projet:rugby à XV sera très intéressé également une fois la phase test hockey passée, mais cela ne sera pas très différent. Faudrait aller voir vers d'autres domaines (zoologie, politique, musique, cinéma, communes ?) pour plus de diversité. Udufruduhu (d) 14 juillet 2011 à 11:42 (CEST)

Merci pour votre intérêt ! N'hésitez pas à jouer les entremetteurs  : je peux pendant juillet-août (côté disponibilité) mettre des infobox en démo ou test dans Utilisateur:Lgd/Infobox V3 accessibles dès que vous tentez de vendre le morceau. après, j'espère bien passer le relais.

Sinon, un autre très gros morceau assez aisément jouable politiquement serait les taxobox du projet Biologie, mais j'avoue que là, j'ai jusqu'ici renoncé devant la complexité du modèle, ayant la flemme d'y passer une journée... Il faudrait en parler à leur auteur principal.

Cordialement, --Lgd (d) 14 juillet 2011 à 11:58 (CEST)

Le transfert dans l'espace Modèle est fait, voir Modèle:Infobox V3. C'est à partir de là que cela se passe, désormais. Cordialement, --Lgd (d) 22 juillet 2011 à 13:43 (CEST)

{{Terme défini}}

Salut à tous, je voudrais si possible faire le point sur ce modèle ; je préviens que je ne suis pas les décisions du moment donc j'ai peut-être zappé des infos utiles. Ce modèle est-il :

1. recommandé pour remplacer les italiques du nom de l'article concerné dans le résumé introductif?
2. accessible à 100%?
3. diffusable?

Merci de vos réponses. Prosopee (d) 14 juillet 2011 à 11:49 (CEST)

Bonjour,

1. Recommandé non, puisque la PDD est en panne faute d'intérêt des contributeurs (je ne tiens pas à porter à bout de bras quelque-chose qui laisse plus ou moins indifférent). La PDD n'était finalement pas le meilleur moyen (ce qui me conforte personnellement dans l'idée que, d'une manière générale les PDD d'ordre technique ne sont pas plus une bonne idée que celles d'ordre éditorial genre nommage de quelque-chose : les PDD sont des outils à usage organisationnel uniquement).
2. accessible à 100%, oui, tout à fait
3. diffusable : c'est la question délicate. Je ne pense pas prolonger la PDD vu le peu d'intérêt, mais plutôt laisser le bien connu phénomène d'imitation jouer son rôle avec quelques autres (dont le ressort AdQ par exemple). Il faut que je refasse le tour des derniers rares retours et que j'actualise le modèle ainsi que sa doc, mais a priori : oui, c'est diffusable sous la forme du modèle {{terme défini}}. Cordialement, --Lgd (d) 14 juillet 2011 à 11:58 (CEST)

Salut Lgd et merci de ta rapidité. Je demande cela car je pose systématiquement à la place des italiques ce modèle, lors de mes relectures. Je m'attends à des reverts et des explications donc je viens me renseigner auparavant. Je ne suis pas le mieux placé pour donner des leçons car je ne vais jamais sur les pages de votes pour les évolutions techniques tout simplement car je ne suis pas compétent. Je laisse cela aux spécialistes, comme toi, et leur prodigue toute ma confiance. Mais bon, comme tu le signales, oublions la recommandation et axons-nous sur la diffusion par "mimétisme". J'ajoute ce modèle au guide de relecture, pour info et le considère comme officiel. Cordialement, Prosopee (d) 14 juillet 2011 à 12:08 (CEST)

@Lgd, pour ce qui est de la PDD, il me semble que si elle n'obtient plus de remarques c'est qu'elle doit être mure pour passer au vote, non ? Si ce n'est la partie développement avec l'utilisation des bots (je n'ai pas bien suivi cette partie), le reste me semble bien finalisé et tous les remarques/questions ont été posées. Je ne suis pas convaincu que l'abandon soit la bonne solution. Udufruduhu (d) 14 juillet 2011 à 12:23 (CEST)

Bon, comme on m'a fait la même observation dans la pdd de la PDD, je me plie à ces avis. Les conditions de vote et le texte de la PDD, ainsi que la page d'aide sur le modèle, me semblent prêtes. Je suppose qu'on peut lancer la semaine prochaine... Cordialement, --Lgd (d) 16 juillet 2011 à 07:41 (CEST)

Le vote est ouvert. Udufruduhu (d) 20 juillet 2011 à 02:37 (CEST)

Modèle lang

Il y a apparemment un bug sur le modèle lang de Wikisource. Explications ici : Discussion modèle:Lang. Cdlt, Vigneron * ^discut. 19 juillet 2011 à 16:29 (CEST)

Couleur de texte

Bonjour, j'ai à deux reprises supprimé la couleur rouge du titre de la palette Dexter, mais ai été défait les deux fois par Skarock (d · c). Sauriez-vous expliquer, mieux que moi, pourquoi il est important d'éviter le texte rouge, qui porte à confusion avec un lien rouge ? Cela permettrait par la même occasion de montrer que je ne suis pas le seul à être préoccupé par la question.

À propos, je n'ai pas trouvé d'éléments sur ce point dans les Bonnes Pratiques ni dans la recommandation sur les couleurs. Peut-être y aurait-il un paragraphe à ajouter quelque part ?

Merci pour votre aide, od†n ↗^blah 20 juillet 2011 à 16:51 (CEST)

A vrai dire, ce n'est pas un problème d'accessibilité, d'où le pourquoi du comment de l'absence de BP. Par contre, c'est une erreur ergonomique criante, en effet. J'ai modifié, mais sans grands espoirs : pour ma part, j'avoue attendre de pouvoir refondre le modèle de base des palettes une fois les js propres et prévu enfin déployés dans mediawiki, et supprimer au passage les options de couleur... Froidement. Cordialement, --Lgd (d) 20 juillet 2011 à 17:00 (CEST)

je ne trouve pas ce que je publie

pourquoi?

Rien à voir avec l'accessibilité et la réponse est sur votre page de discussion (vos ajouts on été supprimés par des administrateurs). Cordialement. --'toff ^[discut.] 21 juillet 2011 à 05:45 (CEST)

HiddenStructure, la fin du tunnel ?

Bonjour,
La prochaine version de mediawiki (1.18) euthanasie proprement et simplement la class HiddenStructure :

« (bug 17009) the hiddenStructure CSS class, a highly hackish way of at least *appearing* to hide article elements, has been removed. Use the ParserFunctions extension to actually remove unwanted elements from the output. »

tenez bon, vous n'êtes plus seuls  ! Cordialement, --Lgd (d) 21 juillet 2011 à 16:15 (CEST)

Not watching... Not watching... Not yet... Not Big brother... isn't watching me...

Nous savons, puisque nous avons participé au bug 17009. Mais il reste deux paramètres inconnus :

1. la date de déploiement de 1.18 ?
2. C'est chouette d'avoir enfin ce soutien. Mais concrètement pour :fr, ça ne change presque rien. Personne n'a envie de corriger les 200 modèles restants, parce qu'ils ont l'air de fonctionner tout bien. Et j'avoue que je n'aurai jamais la patience de corriger plus d'une trentaine de modèles supplémentaires. Pour moi, il y a besoin de montrer qu'il y a un souci avec ces modèles, pour qu'ils soient corrigés. La question c'est donc : dans quelle mesure va-t'on aller dans l'esprit du bug 17009 ? Est-ce qu'on se mouille vraiment, en retirant la classe HiddenStructure de common.css ? Franchement : on le fait, on fait un appel à bénévoles avec la liste des modèles à corriger, et hop en une journée c'est fini. Je vois pas d'autre solution. Dodoïste ^{[ dring-dring ]} 21 juillet 2011 à 17:14 (CEST)

C'est évidemment le point à résoudre (je voulais déjà mettre un message d'encouragement, voyant que tu reprenais le domaine de la lutte ). Le mesure extrême serait évidemment un dernier et ultime recours uniquement. Mais sans envisager d'aller jusque-là, le passage à 1.18 (on ignore quand) sera l'occasion de rappeler ou de refaire connaître le problème, et d'attirer des bonnes volontés. Le passage à des V3 permettra peut-être d'en traiter quelques-unes d'ici là (cela fournit une excellente raison de passer directement à V3). Cordialement, --Lgd (d) 21 juillet 2011 à 17:33 (CEST)

Merci pour l'encouragement. :-)

Oui, j'espère aussi qu'on puisse en faire un maximum sans sortir l'artillerie lourde. Je ne pense pas qu'on puisse y échapper, mais on peut préparer le terrain en corrigeant les gros morceaux d'abord.

Oui, pour le passage direct à V3, quand c'est possible. Tu te souviens des infobox modulaires (modbox) ? Certaines utilisations de ce système risquent d'être galère à mettre à jour, car les modbox permettent un assemblage de structures au sein même de l'article. Je crains que certains articles doivent être corrigés un à un ? Mais j'ai pas encore trouvé d'usage que je décris (sans chercher vraiment non plus), donc je tire peut-être la sonnette trop tôt ? Dodoïste ^{[ dring-dring ]} 21 juillet 2011 à 17:58 (CEST)

Oui, je me souviens de ces modbox, une tentative irréfléchie. Mais elle n'avait cependant aboutie à rien dans les articles, il me semble ? Cordialement, --Lgd (d) 21 juillet 2011 à 18:11 (CEST)

À des fins d'archive, découvrant avec joie cet exploit de NeMoi, je note ici que HiddenStructure a été finalement achevé en date du 17 novembre 2011. Bravo à tous ceux qui y ont participé. Dodoïste ^{[ dring-dring ]} 8 décembre 2011 à 00:23 (CET)

<strong> ou <b>

Bonjour. En regardant les rendus HTML des pages de WP, je me suis aperçu qu'on trouvait aussi bien des balises <strong< que des <b>. Ma question pourquoi le code ''' génère-t-il des balises <strong> plutôt que des <b> et '' rend-il <em> et non <i> ? Merci --Pic-Sou (d) 25 juillet 2011 à 15:58 (CEST)

Bonjour,

Du côté de la syntaxe wiki :

• ''' génère b (cela n'a pas toujours été le cas, mais c'est acquis à présent)
• '' génère i (peu ou jamais de changements de ce côté si ma mémoire est bonne)

Mais si tu regardes le code source HTML, selon l'origine du balisage (syntaxe wiki, modèle, templates de pages mediawiki), c'est plus varié : on trouvera le plus souvent b mais aussi plus rarement strong, i mais aussi plus rarement em.

En principe, selon les standards Web (mais c'est assez confus selon les spécifications) :

• b est une mise en gras à des fins typographiques uniquement
• i est une mise en italique à des fins typographiques uniquement
• strong signale l'importance d'un contenu (mot-clé) et donne par défaut du gras, mais sans obligation de la faire.
• em signale l'emphase sur un contenu et donne par défaut de l'italique, mais sans obligation de la faire.

Le souci est donc qu'il ne serait pas très probant de chercher à demander aux wikipédiens d'être plus précis dans leurs utilisations de ces syntaxes : les différences sont assez cryptiques entre b et strong d'une part, em et i d'autre part, sans compter celle encore plus complexe entre strong (qui ne fait pas forcément du gras) et em (qui ne fait pas forcément de l'italique). Le parti actuel de s'en tenir à générer i et b dans tous les cas à partir de la syntaxe wiki, en sachant que ce n'est pas optimal, est assez sage. C'est au cas par cas, pour des choses plus spécifiques, qu'on peut tenter de préciser les usages, comme avec dfn.

Et à vrai dire, l'utilisation de ces différentes balises dans des sites comme Wikipédia contribue à aider à les définir dans le cadre des spécifications techniques du W3C, ce qui en retour est censé définir leur usage dans Wikipédia...

Cordialement, --Lgd (d) 25 juillet 2011 à 17:03 (CEST)

Cependant, il existe relativement peu de cas où les balises typo uniquement devraient être utilisées, mis à part dans les schémas {{BS}} qui ne sont, de tout façon, pas accessibles (faut pas rêver ). La généralisation de strong, sauf si l’utilisateur le demande clairement en mettant des b dans le code source de la page me paraîtrait intelligente. Est-ce que je me trompe ? --Pic-Sou (d) 25 juillet 2011 à 17:16 (CEST)

Heu, oui (si je peux oser ) : les mises en italique et en gras requises par Wikipédia:Conventions typographiques notamment ne relèvent le plus souvent pas de la sémantique de strong ni de em. Voir notamment les modèles bibliographiques (quoique... cite vient s'en mêler, ce qui ne simplifie pas, hélas ). Cordialement, --Lgd (d) 25 juillet 2011 à 17:23 (CEST)

Répète un peu

Ah, d'accord, je ne savais pas. Merci pour tes réponses --Pic-Sou (d) 25 juillet 2011 à 19:54 (CEST)

Erreur de code de langue à corriger

Bonjour,
La Catégorie:Page avec code de langue invalide se remplit doucement de pages comportant un code invalide lat au lieu de la quand le modèle {{lang}} est utilisé pour signaler un passage en latin. N'hésitez-pas à contribuer aux corrections .

Merci à Prosopee qui a signalé le besoin de détection de cette erreur.

Cordialement, --Lgd (d) 28 juillet 2011 à 08:28 (CEST)

Merci à A2 pour les corrections, la catégorie est revenue à son niveau habituel . Cordialement, --Lgd (d) 29 juillet 2011 à 07:35 (CEST)

Listes de définition et décalage du texte

Voilà : au cours de mes modifications sur WP, je rencontre souvent le « : » utilisé pour décaler du texte. Quelle est la syntaxe à utiliser pour remplacer cette mauvaise utilisation des listes de définition ?

Ltrl G (d · c) 19 août 2011 à 12:28 (CEST)

Il y a 4 cas de figure à l'usage, si j'en crois ce que j'ai vu :

1. « : » ne sert qu'à indenter : il faut simplement le supprimer (et expliquer...)
2. il remplace un balisage plus précis, essentiellement une citation : le modèle {{Citation bloc}} est tout indiqué.
3. C'est une indentation mais dans des listes : il faut rétablir une syntaxe de liste correcte, généralement à base de **
4. Parfois, c'est une vrai possibilité de liste de définition : ;foo et :bar

En cas de besoin, donne un ou des exemples plus précis ? Cordialement, --Lgd (d) 19 août 2011 à 12:37 (CEST)

Fiches Maladie Professionnelle

En utilisant l'outil Article au hasard, je suis tombé sur l'article Sulfure de carbone (maladie professionnelle), dont les Fiches Maladie Professionnelle ont tout de suite été rougies par le gadget Accessibilité.

Suite à une petite recherche, je me suis rendu compte que ce problème est étendu à un certain nombre d'articles.

Je vous demande donc ce qu'il convient de faire pour rendre accessible ce type de tableaux et si vous connaissez un modèle qui corresponde à cet usage (ou bien faut-il en créer un ?)

Cordialement,
Ltrl G (d · c), le 2 septembre 2011 à 20:10 (CEST)

Bonjour,

En fait, ce genre de tableau n'est pas un tableau au sens classique : il mêle en effet de la mise en forme de l’information, et sa structuration (on parle respectivement dans ce cas de tableau de mise en forme et de tableau de données). En fait, tout le haut du tableau, ainsi que son pied, devraient entrer dans son caption (|+), les trois colonnes constituant un tableau de données avec des cellules d’entête de colonnes. Le plus efficace à mon avis, puisque ce genre de fiche est présent sur de nombreux articles, est de créer un modèle pour appliquer la correction au paquet. Note que si on place tout dans le caption, on ne respecte plus la mise en forme avec la date de mise à jour séparée du reste ; mais à mon avis, cette mise en forme n'est qu’une tentative de reproduire celle des fiches techniques de référence professionnelles, et Wikipédia ne s’adresse pas à la même cible a priori. Je te suggère donc de créer un modèle et de le déployer avec un petit mot à Toxicotravail (d · c · b) pour expliquer les raisons de ton intervention. Il contribue peu, mais au moins il ne sera pas surpris s'il consulte sa liste de suivi. Litlok (m'écrire) 6 septembre 2011 à 09:11 (CEST)

Meri pour cette réponse. Malheureusement, je ne vais pas pouvoir contribuer très activement cette année, donc je le ferai plus tard si ça n'a pas déjà été fait par quelqu'un.
Ltrl G (d · c), le 9 septembre 2011 à 19:39 (CEST)

Infobox V3

Lgd ayant, pour le moment tout au moins, décidé de s'en aller de l'encyclopédie, je ne peux pas lui demander de vérifier ce projet de brique pour Infobox V3, quelqu'un pour le faire ? (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 5 septembre 2011 à 20:28 (CEST)

tu peux toujours tenter de lui envoyer un email pour lui demander un coup de patte. --TaraO (d) 5 septembre 2011 à 20:55 (CEST)

Il a cocher l'option pour ne pas recevoir de mail. Donc je ne peux pas .

Je ne pense pas avoir fait d'erreurs lors de la modification du code du modèle existant pour la version 2, d'ailleurs le gadget accessibilité "valide" mon travail, mais c'est juste histoire de vérifié si tout n'est pas pris en compte par ce gadget.

Autrement si quelqu'un a moyen de le contacter. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 6 septembre 2011 à 00:03 (CEST)

ah bah c'est con ; hier quand je t'ai proposé de lui envoyer un email, il avait pas encore coché l'option. Je dirais bien tente sur twitter mais bon, je pense qu'il veut couper les ponts pour le moment. Désolé de pas pouvoir t'aider plus. --TaraO (d) 6 septembre 2011 à 08:46 (CEST)

Rapidement comme ça, et malgré une petite nuit, je ne vois rien de choquant -mis à part la localisation, mais ça, cela dépasse largement le cadre de qui est actuellement envisageable. Litlok (m'écrire) 6 septembre 2011 à 09:01 (CEST)

Je ne souhaite en effet plus intervenir ni être sollicité pour des questions concernant Wikipédia. Ce n'est pas une excuse pour laisser tout en plan, même si j'ai été interrompu avant d'avoir pu finir de mettre en place ces modèles de manière à ce qu'il puissent vivre leur vie. Donc, quelques indications pour terminer :

• le gadget accessibilité n'est pas à jour et nécessite en particulier sur le test tableau plusieurs corrections. Les infobox devraient faire l'objet d'un traitement spécifique, en distinguant :
  • les anciennes infobox pour lesquels un message générique sur la nécessité de refondre l'aspect tableau est suffisant
  • les nouvelles pour lesquelles les tests tableaux s'appliquent, mais où les tableaux à double entrées ne sont pas correctement détectés et traités. Le test des titres caption est également à revoir dans ce cas.
• l'aide des modèles d'infobox V3 nécessite un complément (tutoriel ?) précisant en particulier:
  • les impératifs (gestion des titres de tableaux, combinaison des modèles respectueuse de la sémantique, absence de mise en forme problématique)
  • les limites (voir l'infobox Bataille de la Rome antique qui a nécessité un code sur mesure)
  • les règles d'usages : cela n'a pas vraiment de sens de convertir à ce format des infobox dont une partie du contenu, reproduite à l'identique, pose par ailleurs des problèmes d'accessibilité lourds sur d'autres points. Par exemple, les contenus générés en CSS type figure de maillots dans les infobox sport. Il en est de même quand se pose un problème éditorial et/ou d'ergonomie criant, comme pour les infobox avec boîte déroulante. Dans tous ces cas, il est préférable de ne pas convertir et d'attendre que les contenus évoluent.
• pour les questions plus techniques de finalisation de ces modèles, voir essentiellement cette discussion avec Od1n qui résume rapidement les principaux problèmes en suspens.

En espérant que ces quelques informations vous seront utiles et en vous souhaitant toutes sortes de bonnes choses dans une wikipédia peut être plus sereine, amicalement, --Lgd (d) 6 septembre 2011 à 12:31 (CEST)

A bientôt Lgd, comme les autres fois. --Wikialine (d) 6 septembre 2011 à 18:29 (CEST)

Reviens vite, frais et reposé. On t'aime nous ! --Amicalement, Salix ( converser) 6 septembre 2011 à 19:00 (CEST)

+1 Peter17 (d) 7 septembre 2011 à 00:32 (CEST)

On est pas toujours d'accord, mais j'espère aussi que ce départ n'est pas définitif (surtout que tu pars pil poil quand j'allais te demander de l'aide sur certains modèles). Oublie les facheuses inimitiés et reviens vite -Aemaeth 7 septembre 2011 à 12:57 (CEST)

Présentation générale des ateliers

Bonjour à tous. Je suis tombé au hasard sur cette page méconnue : Aide:Ateliers qui recense les ateliers de WP. Je propose de la refondre, collectivement, et avec tous les ateliers, afin d'en faire un « hub » vers les services spécialisés.J'ai ouvert une discussion à ce propos : ici. Tous les avis sont bienvenus et surtout tous les ateliers. Prosopee (d) 7 septembre 2011 à 09:53 (CEST)

Vous avez un message

Bonjour,

Dans le cadre de l’amélioration de l’accueil des nouveaux, Trizek propose de modifier l’apparence du bandeau de message. Actuellement, celui-ci ressemble à un bandeau d’ébauche ou un message d’avertissement quelconque. D’expérience, la majorité des nouveaux utilisateurs ne voient pas ce bandeau.

Il propose ce code :

.usermessage {height: 25px; width: 100%; position : fixed; top: 0px; left: 0px; z-index:1000; text-align:left; font-size:0.9em; margin: 0; padding: 0 0 0 20%;}
.usermessage small {display:none; font-weight: normal; font-size:0.7em;}
.usermessage:hover small{display:block;}
#p-personal {z-index:1200;}

Qu’en pensez-vous ? Voyez-vous quelque chose à redire/changer/améliorer ?

Cdlt, Vigneron * ^discut. 9 septembre 2011 à 11:51 (CEST)

Pourquoi pas. On peut avoir un aperçu ? ~Hlm Z. [@] 9 septembre 2011 à 15:08 (CEST)

Il suffit de mettre ce code dans son CSS personnel et d’avoir un message pour avoir un aperçu . Cdlt, Vigneron * ^discut. 9 septembre 2011 à 15:19 (CEST)

Bon , après essai, chez moi l'effet de cette modif est désastreux : bandeau relégué tout en haut, illisble, cachant les onglet, etc... J'ai vite purgé ! --Amicalement, Salix ( converser) 22 septembre 2011 à 00:24 (CEST)

Le tout en haut c’est fait exprès pour (afin d’éviter d’être confondu avec les bandeaux justement).

Par contre, en quoi est-ce illisible ? (là c’est l’effet contraire de ce qui est souhaité). Et chez moi, les onglets ne sont pas cachés (ni sur Opera, ni sur Firefox, ni sur Chromium), quel navigateur utilises-tu ?

Cdlt, Vigneron * ^discut. 22 septembre 2011 à 12:25 (CEST)

J'ai Firefox. C'est sans doute parce que j'ai une résolution 1024x768, ou bien à cause de la barre de navigation personnelle. Et je ne suis sans doute pas la seule... --Amicalement, Salix ( converser) 22 septembre 2011 à 14:15 (CEST)

Salut. Pour moi : Windows 7 (1600x900) + Firefox 6 + Monobook (pas vector) = onglets partiellement cachés. J'aime pas. --'toff ^[discut.] 22 septembre 2011 à 17:57 (CEST)

Euh j’ai un doute donc juste pour être sur : quand vous parlez des onglets, vous pensez aux onglets « Page ; Discussion ; Lire ; Modifier ; etc. » ou bien aux pseudo-onglets « Utilisateur ; Discussion utilisateur ; Préférences ; LdS ; etc. » ? Le second serait effectivement très gênant mais le premier plus inattendu mais juste inacceptable.

Indépendamment de la réponse à ma question précédente, vous auriez une idée pour résoudre le problème voire améliorer le bandeau ?

Cdlt, Vigneron * ^discut. 22 septembre 2011 à 20:01 (CEST)

J'ai rétabli le code. Un volontaire pour m'envoyer un message à cette heure tardive ? --Amicalement, Salix ( converser) 22 septembre 2011 à 23:11 (CEST)

Voilà voilà… Litlok (m'écrire)

Ben pour moi, c'est comme 'toff, les onglets sont cachés et je suis pas fan. Ma config c'est mac OS X 10.8, firefox 6 et monobook. Udufruduhu (d) 22 septembre 2011 à 23:43 (CEST)

@ Vigneron, voici la réponse à tes questions (merci Litlok ): ce bandeau est au-dessus des onglets de modification (ouf!) mais laisse à peine visibles, sur fond orange, les liens vers utilisateur et préférences. Il vient se positionner comme une 6e barre de navigation en dessous de ma barre personnelle de navigation Mozilla. Celle-ci est assez colorée avec des tas de petites iones et, du coup, le message passe inaperçu. Même quand on scroll car il ne semble pas faire partie de Wikipédia mais du navigateur, ou de la barre des modification, en fonction de l'emplacement de la fenêtre. Comme j'ai volontairement conservé l'encadré orange « Ne copiez pas de texte, ni d'une page web... » (au dessus du résumé) pour voir la même chose que les débutants, ça ne fait qu'une ligne de cadre orange de plus... Quand à la bulle "pensez à vérifier dans l'historique...", ce sont des pattes de mouches, totalement illisibles quand elles sont sur fond de texte.--Amicalement, Salix ( converser) 22 septembre 2011 à 23:50 (CEST)

P.S. De même pour l'enveloppe flottante sur ma pdd que je viens tout juste de remarquer, invisible quand superposée avec une discussion, et dont le texte est bien trop petit (même avec ma résolution pour myope !).

PS2. Pire ! tant que l'enveloppe flottante est là on ne peut plus cliquer sur les titres de section situés à sa gauche ! Argl ! --Amicalement, Salix ( converser) 24 septembre 2011 à 00:49 (CEST)

PS3. Et en plus ce @***!"! de bandeau orange persiste sur ma pdd, cachant les liens d'utilisateur et onglets, même après être passées à autre chose. --Amicalement, Salix ( converser) 24 septembre 2011 à 03:12 (CEST)

PS4. Grosse confusion aussi avec les utilisateurs qui utilisent la même présentation pour encourager à leur laisser un mot (cf. Discussion utilisateur:Arkanosis). --Amicalement, Salix ( converser) 25 septembre 2011 à 19:01 (CEST)

MediaWiki 1.18

D'après en:Wikipedia:Wikipedia Signpost/2011-09-19/Technology report#MediaWiki_1.18_deployment_begins, MediaWiki version 1.18 arrivera dans http://fr.wikipedia.org/ le 2011-10-04 (4 octobre 2011). Visite fortuitement prolongée (d) 20 septembre 2011 à 22:29 (CEST)

Histogramme

Bonjour,

Je suis en train de travailler sur un modèle permettant de générer des histogrammes. J'ai trouvé deux modèles qui pourraient se rapprocher de ce que je veux faire : {{Relevé hydrologique}} qui utilise "timeline", et {{Pyramide des âges}} (pas tout à fait un histogramme, je sais) qui utilise un tableau avec des div partout. Lequel est le meilleur (ou le pire) du point de vue accessibilité ? Existe-t-il une troisième possibilité ? A priori, j'imagine qu'il vaut mieux une balise img identifiée comme timeline qu'un faux tableau, mais j'aimerai une confirmation de cela. Cordialement.--Juju2004 (d) 2 octobre 2011 à 09:51 (CEST)

Je ne sais pas si la question est toujours d'actualité, mais timeline, malgré ses défauts, est préférable à des mises en forme de tableaux dès qu'il ne s'agit plus de cas simples. La pyramide des âges est un cas limite un peu particulier où on parvient encore à obtenir un résultat réellement accessible avec un tableau mis en forme. --Lgd (d) 6 décembre 2011 à 10:05 (CET)

Liste des pronoms en latin

Voir les tableaux de Liste des pronoms en latin. Visite fortuitement prolongée (d) 8 octobre 2011 à 22:46 (CEST)

Création de catégories de maintenance

Bonjour, à ma connaissance ce projet n'a pas encore de catégories cachées de maintenance pour signaler les pages à corriger comme ci-dessus au lieu d'avoir à poster un message. Il serait utile de créer des sous-catégories quand seuls les tableaux, les alt ou les lang sont à revoir. Cela faciliterait le travail de ceux qui sont capables de corriger l'accessibilité. On aurait ainsi {{Accessibilité à améliorer}} qui alimenterait la Catégorie:Accessibilité à améliorer et par exemple {{à accessibiliser|tableau}} qui alimenterait la Catégorie:À accessibiliser-tableau et {{à accessibiliser|lang}} qui alimenterait la Catégorie:À accessibiliser-lang, etc.--Amicalement, Salix ( converser) 9 octobre 2011 à 09:58 (CEST)

La masse d'articles potentiellement catégorisés ne rendrait-elle pas ces catégorisations peu utiles ? Des catégories plus ciblées alimentées automatiquement par exemple via certains modèles (Catégorie:Page avec code de langue invalide par exemple) ou le recours ciblé à AbuseFilter seraient peut-être plus profitables. --Lgd (d) 6 décembre 2011 à 10:02 (CET)

Infobox V3 - variante de modèle

Hello,
en faisant des essais avec les infobox V3, j'ai eu le besoin d'avoir la même chose que {{Infobox V3/Tableau Ligne données}} mais avec une ligne de séparation, car dans une longue liste énumérative (partie classification des taxobox) je trouve qu'on s'y perd un peu. J'ai fait une variante ici : Utilisateur:Hexasoft/Infobox V3 Ligne données simple.
Pensez-vous que :

• cette modification est sémantiquement et accessiblement correcte ?
• il serait possible de l'intégrer aux V3, soit en tant que modèle distinct, soit en tant qu'option du modèle (avec ou sans ligne de séparation) ?

Note : dans le cas présent j'ai en fait enlevé aussi le gras sur la colonne de gauche.

Cordialement, Hexasoft (discuter) 1 décembre 2011 à 22:03 (CET)

Une autre question, tant que j'y suis  : pourquoi l'infobox V3 est plus large que ses copines ? (Voir Utilisateur:Hexasoft/Taxobox où se trouvent des exemples de taxobox, de V2 et de V3 (à la fin)). Hexasoft (discuter) 1 décembre 2011 à 22:48 (CET)

1. Est-ce que l'utilisation du paramètre border dans le modèle {{Infobox V3/Début}} ne répond pas déjà au besoin ? Sinon, il vaudra mieux ajouter un paramètre au modèle {{Infobox V3/Tableau début}} existant (en faisant jouer une classe CSS) plutôt que de créer un modèle supplémentaire et des styles inline juste pour cela.
2. Les largeurs d'infobox sont variables selon les modèles V1, V2 etc. La largeur des V3 est ajustable, voir également {{Infobox V3/Début}}.

--Lgd (d) 6 décembre 2011 à 09:52 (CET)

Hello Lgd, merci pour ta réponse. Pour répondre à ta question, l'idée est de mettre des séparations uniquement dans les longues énumérations (typiquement les parties classification) car nous trouvons que ça améliore la lisibilité, mais pas que ça s'applique à toute la box. Je vais regarder Tableau début, mais il me semble − à vérifier − que quand on demande les bordures ça inclue le titre du tableau, rendant le rendu différent du reste. Je vais faire des tests.

Cordialement, Hexasoft (discuter) 6 décembre 2011 à 10:33 (CET)

Oui, cela s'applique à tous les tableaux contenu dans la box. Le parti-pris initial d'imposer des bordures de séparations systématiques répond bien aux besoins des infobox, mais il a peut-être sa limite dans ce cas particulier. C'est à voir avec les tests : l'idée serait en tous cas de privilégier l'ajout d'un paramètre à un modèle existant plutôt que la création d'un modèle supplémentaire, pour garder un jeu de modèles réduit et lisible, et pour bien tirer parti des styles CSS centralisés dans common.css. --Lgd (d) 6 décembre 2011 à 12:55 (CET)

Accessibilité

Salut à toutes et tous. L'université de Nice vient d'ouvrir son portail sur l'accessibilité web. Elle propose des tutoriels vidéo et des formations pour webmaster. Peut-être intéressant pour Wikipédia ? Prosopee (d) 3 décembre 2011 à 10:41 (CET)

Ce portail (qui n'est pas nouveau) est indiqué depuis assez longtemps dans Wikipédia:Atelier accessibilité/Ressources et références, mais il est vrai que cette page est peu visible. --Lgd (d) 6 décembre 2011 à 09:56 (CET)

Galeries d'images : mises à jour

Les galeries d'images supportent à présent un paramètre alt pour chaque image, permettant de leur donner une alternative textuelle (voir bug #18682). J'ai rapidement mis à jour les bonnes pratiques accessibilité, mais il faudra également actualiser notamment :

• Aide:Insérer une image/avancée ;
• MediaWiki:Gadget-Accessibility.js pour supprimer l'alerte en cas de galerie et afficher les alt comme pour les autre types d'images.

--Lgd (d) 6 décembre 2011 à 20:18 (CET)

Mise en forme des résumés de bonnes pratiques

Dans Wikipédia:Atelier accessibilité/Bonnes pratiques, la récente et nouvelle mise en forme des libellés ne me semble pas une réussite : ils ressortent nettement moins, sont écrasés par les bordures noires, bref, ils n'ont pas gagné en lisibilité. Pourrait-on au moins revenir à un rendu plus proche de celui d'origine ?

Le rendu actuel :

Utiliser systématiquement les titres de section (== etc.) et ne pas créer de pseudos-titres à l'aide d'une mise en gras ('''), d'une liste de définition (;), d'un élément div mis en forme (<div style="font-weight: bold">), etc.

--Lgd (d) 6 décembre 2011 à 20:27 (CET)

Réponse du comte Ɲemoi – L’apparence précédente combine à mon avis trop de marquages (italique + traits en tous sens + icone), de sorte que l’œil est plus attiré par le texte « normal » qui suit que par la bonne pratique ; elle a qui plus est le (petit) défaut de ne pas être normalisée. Des deux, la solution actuelle me semble plus efficace, mais elle fonctionne en « forçant » l’œil à regarder (deux gros traits noirs), ce qui est beaucoup moins agréable. La solution « {{encart}} seul » est peut-être encore préférable… Ce 6 décembre 2011 à 22:12 (CET).

Comme tu le constates, c'est une mise en forme désagréable à l'oeil (filets noirs trop tranchés, absence de bordures verticales et texte qui fuit, écrasement du contenu faute d'un padding suffisant, type de modèle prévu pour des mentions beaucoup plus brèves et de nature différente). Mettre en évidence un texte-clé ne « fonctionne » pas sur une telle base. Pour le moment, j'ai corrigé au plus simple avec ce qu'il y avait sous la main. --Lgd (d) 6 décembre 2011 à 22:48 (CET)

Réponse du comte Ɲemoi – Attire autant l’œil que la solution précédente, le repousse moins que la solution initiale, ça progresse, c’est certain. Les deux solutions précédentes utilisaient des icones Bonne pratique, je n’ai pas d’avis sur l’intérêt de les conserver, mais leur couleur se fondant avec celle des bandeaux, ça ne me choquerait pas. Ce 6 décembre 2011 à 23:14 (CET).

Ma modification initiale visait à simplifier le code en utilisant {{encart}} que Nemoi venait justement de lifter. Je me suis arrêtée au premier essai en constatant que le rendu n'était plus assez visible et... j'ai oublié d'en parler ici. C'est pas mal à présent mais je regrette la disparition de la petite icône dans la version actuelle. --Amicalement, Salix ( converser) 7 décembre 2011 à 01:22 (CET)

Réponse du comte Ɲemoi – Le modèle : Encart n’a pas changé, mais il était placé auparavant dans un cadre qui générait trop de bruit. Je remets l’icone. Ce 7 décembre 2011 à 10:56 (CET).

Listes horizontales pour les navbox

Bonjour. Les listes dans les palettes de navigation anglophones, formatées avec le modèle en:Template:Flatlist, sont maintenant correctement formatées et accessibles. Ce sont des vraies listes <li>. En plus des classes CSS correspondantes il existe un petit script JS qui corrige le rendu sous IE. Ainsi le rendu est identique sur tous les navigateurs. Ce changement a reçu pas mal d'attention, et a été mentionné dans le Wikipedia Signpost: Horizontal lists have got class.

Concernant nos propres modèles de pseudo listes horizontales, le Modèle:Liste éléments a été conçu pour être facilement modifiable en liste propre. Le changement est assez simple à faire, il suffit de modifier ce modèle et d'ajouter les codes correspondants dans nos pages common.css et common.js.

classes et script "hlist"

/* Helper script for .hlist class in common.css
 * Maintainer: [[User:Edokter]]
 */
 
if ( $.browser.msie ) {
  /* remove interpunct from last list items in IE 8 */
  if ( $.browser.version == '8.0' ) {
    $( '.hlist' ).find( 'dd:last-child, dt:last-child, li:last-child' )
      .addClass( 'nopunct' );
  }
  /* Generate interpuncts and parens for IE < 8 */
  if ( $.browser.version < '8.0' ) {
    $( '.hlist' ).find( 'dd + dd, dd + dt, dt + dd, dt + dt, li + li' ).prev()
      .append( '<b>·</b> ' );
    $( '.hlist dl dl, .hlist ol ol, .hlist ul ul' )
      .prepend( '( ' ).append( ') ' );
  }
}

/* Style for horizontal lists (separator following item) */
.skin-monobook .hlist dl,
.skin-modern .hlist dl,
.skin-vector .hlist dl {
    line-height: 1.5em;
}
.hlist dl,
.hlist ol,
.hlist ul {
    margin: 0;
}
.hlist dd,
.hlist dt,
.hlist li { 
    display: inline;
    margin: 0;
}
/* Display nested lists inline */
.hlist dl dl,
.hlist ol ol,
.hlist ul ul {
    display: inline;
}
/* Generate interpuncts */
.hlist dd:after,
.hlist dt:after,
.hlist li:after {
    content: " ·";
    font-weight: bold;
}
.hlist dd:last-child:after,
.hlist dt:last-child:after,
.hlist li:last-child:after {
    content: none;
}
/* for IE 8 */
.hlist dd.nopunct:after,
.hlist dt.nopunct:after,
.hlist li.nopunct:after {
    content: none;
}
/* Add parens around nested lists */
.hlist dl dl:before,
.hlist ol ol:before,
.hlist ul ul:before {
    content: "(";
}
.hlist dl dl:after,
.hlist ol ol:after,
.hlist ul ul:after {
    content: ")";
}
/* Put numbers in ordered lists */
.hlist.hnum ol li {
    counter-increment: level1;
}
.hlist.hnum ol li:before {
    content: counter(level1) " ";
}
.hlist.hnum ol ol li {
    counter-increment: level2;
}
.hlist.hnum ol ol li:before {
    content: counter(level2) " ";
}

 

J'ai déjà commencé cette discussion sur Discussion modèle:Liste éléments, je ne sais pas si il vaut mieux continuer là-bas ou ici ? Dodoïste ^{[ dring-dring ]} 7 décembre 2011 à 03:06 (CET)

J'ai fait un brouillon du nouveau modèle sur Utilisateur:Dodoïste/liste horizontale. Tout fonctionne bien, y'a plus qu'à. ;-) Dodoïste ^{[ dring-dring ]} 7 décembre 2011 à 04:26 (CET)

Avant de partir dans la mise en place d'un modèle, une question : quelles en sont les usages ?

• Listes UL horizontales : usage massif et évident, essentiellement pour une refonte des palettes de navigation. Mais dans ce cas, le code entier de celles-ci étant à reprendre, le modèle n'est pas nécessaire en lui-même : c'est la classe .hlist qui devrait être appliquée directement dans le modèle de palette (la saisie se faisant à la manière classique d'une liste dans la syntaxe wiki).
• Listes OL horizontales : je n'en vois pas d'usages existants pour le moment. Des idées ou des exemples ?
• Listes DL horizontales : là, outre l'absence d'usages apparents actuellement, l'utilisation me semble curieuse. Des exemples ?

Il me semble donc que la priorité n'est pas la création du modèle, qui n'est pas nécessaire pour la principale et la plus évidente utilisation de ces listes. En outre, son fonctionnement est celui d'une liste arbitrairement limitée, donc un modèle généralement lourd pour des listes qui seront le plus souvent très en deçà de cette limite et potentiellement gênant pour de rares listes qui seraient au-delà de la limite. Si un modèle s'avérait effectivement nécessaire, il serait préférable qu'il soit de la forme {{Liste horizontale début}}… {{Liste horizontale fin}} permettant la saisie du contenu avec la syntaxe de liste habituelle (Keep it simple) dont le maniement est plus aisé pour de longue liste (meilleure lisibilité).

Je propose donc :

• de s'en tenir au seul cas des listes UL (sauf usages que je n'aurais pas détecté pour les listes OL)
• d'alléger la CSS et le script en conséquences. Leur rendu est en effet correct dans les navigateurs, pas de souci majeur de ce côté.
• de s'orienter essentiellement, au moins dans un premier temps, vers la refonte des palettes :
  • corrigeant le problème majeur des listes simulées dans celles-ci
  • tirant parti de jQuery.makeCollapsible, comme indiqué dans Discussion Projet:Modèle
  • et passant à un code de listes/div et non de tableaux (les palettes de navigation ne sont pas de véritables tableaux de données en dépit de leur code actuel).

Cela me semble nettement préférable à la mise en place générique de styles et d'un modèle « tous usages » dont les besoins ne sont pas identifiés, et qui, selon une pratique fréquente dans Wikipédia, conduirait en fait à susciter des usages « parce que la technique est disponible », sans qu'ils soient vraiment réfléchis éditorialement et ergonomiquement. --Lgd (d) 7 décembre 2011 à 08:48 (CET)

Hum, je n'ai peut-être pas été très clair ?

• Je propose d'améliorer l'existant, pas de créer un énième modèle lourdingue. Il s'agit de modifier Modèle:Liste éléments, pour le transformer à la manière du brouillon de modèle que j'ai fait. J'ai largement simplifié le modèle liste éléments, il est 4x plus léger que l'original.
• Pour la question de listes UL, OL ou DL, il me semblait évident qu'on parlait d'un usage de liste UL. Si tu regardes le modèle Liste éléments, il affiche un point entre les items. Si tu regardes le résultat de mon modèle (et que tu testes le CSS et tout), tu verras un point entre les items. N'as-tu pas regardé un peu rapidement ?
• Pour avoir un modèle simplifié, et plus proche du modèle original en:Template:Flatlist qui est très simple, je suis tout pour évidemment. Nous avons toujours été d'accord sur ce genre de points.

Je suis tout pour une refonte des palettes et tout. Mais je propose une petite amélioration simple, et tu me réponds « escaladons l'Himalaya ! » Faisons le plus facile d'abord : la modification technique et l'amélioration d'accessibilité. Contrairement à ce que tu as écrit, cela ne change rien d'un point de vue éditorial, on ne va pas générer d'usages ou quoique ce soit.

Une des idées derrière ce CSS et JS identique entre FR et EN, c'est d'améliorer la portabilité des contenus entre wikis, et de pouvoir déplacer ce code dans le Core (styles généraux du site maintenus par les développeurs, dans bits.wikimedia.org). C'est la raison pour laquelle on m'a sollicité sur EN pour que je propose cette uniformisation ici. D'ailleurs, oui pour alléger le code, mais justement ce serait le boulot des développeurs. Et puis il faudrait ensuite répercuter le changement sur EN. Ouf ! Enfin, pour terminer sur un note plus joyeuse, je suis content de te revoir par ici. :-) Dodoïste ^{[ dring-dring ]} 7 décembre 2011 à 19:01 (CET)

Pour aller au plus simple : oui, nous sommes tout à fait d'accord sur le fond. La question est juste celle de la démarche. Une mise en place de la CSS et du JS pour le modèle {{Liste éléments}} tel que tu le proposes est évidemment un premier pas, même si le modèle n'est pas nécessaire dans la perspective ultérieure de palettes accessibilisés. Mais sous la forme où tu le proposes, on va faire de ce modèle une source de nouveaux usages (listes DL) pifométriques, ce qu'il me semble préférable d'éviter dans la mesure où ce n'est pas nécessaire pour ce premier pas. J'ai trop souvent vu les gens tomber sur un modèle un peu hasardeux, voir qu'il y avait une possibilité technique et s'en servir sans se rendre compte des conséquences. Limitons le modèle à sa seule valeur ajoutée, c'est à dire les listes UL, cela va tout à fait dans le sens de ta démarche.

Harmoniser entre wikis est une excellente approche, mais elle doit aussi permettre de tirer profit des améliorations faites à partir du code initial. Revenir vers EN pour les amener à mieux cibler ce modèle sera un gain pour tout le monde.

Mais sinon, à défaut, on peut y aller directement comme tu le proposes. --Lgd (d) 8 décembre 2011 à 11:02 (CET)

OK, on fait comme ça. Alors si j'ai bien compris, tu proposes de mettre un garde-fou qui assure que ce modèle sera bien utilisé pour des listes UL. Fait. Excuses, j'avais pas compris cela tout de suite.

Ensuite, pour optimiser le script et le CSS, je suis toute ouïe. Je vois bien que le CSS est chargé inutilement, et je pourrais grossièrement élaguer, mais ça risque d'être imparfait. Ce que je me demande, c'est si toutes ces classes viennent d'une réel besoin sur EN, ce qui me paraîtrait surprenant mais peut-être pas impossible ?

Je suis tout prêt à faire remonter des améliorations sur EN, bien sûr.

Pour moi, cette modification et la refonte des palettes sont des démarches complémentaires. Je suppose que les palettes devront être modifiées manuellement, ce qui va prendre du temps. En attendant, on aura déjà des listes sémantiquement correctes. Ça ne mange pas de pain. Dodoïste ^{[ dring-dring ]} 8 décembre 2011 à 14:14 (CET)

Réponse du comte Ɲemoi – Pour les ol, l’usage me semble se limiter à quelques listes ordonnées dans des palettes de navigation (classements) ; très négligeable, voire à éviter. Pour les dl, hormis à améliorer les Regards sur l’actualité, je ne vois pas. Il y aurait par contre à se débrouiller pour que le premier dd soit sur la même ligne que le dt.

Comme je le disais hier, les copiés-collés donnent :

copiés-collés

sous Opera :

Ma liste · commence, · continue, · vit, · respire l'air frais · d'une navbox · surpeuplée · et étouffante · en fin d'article.

sous Webkit :

Ma liste commence, continue, vit, respire l'air frais d'une navbox surpeuplée et étouffante en fin d'article.

sous Gecko :

    Ma liste
    commence,
    continue,
    vit,
    respire l'air frais
    d'une navbox
    surpeuplée
    et étouffante
    en fin d'article.

 

ce qui serait peut-être améliorable au niveau du script ; les rendus sont bons, par contre.

Concernant la reprise des palettes de navigation, je plussoie le jQuery.makeCollapsible. J’ai dans mon espace de brouillons quelques tests divers intéressants à ce sujet, notamment le test7. Ce 7 décembre 2011 à 11:20 (CET).

Que veux-tu dire exactement pas « copiés-collés » ? Le copié-collé du contenu affiché avec cette CSS et ce JS ? Si c'est le cas, quel est la question ? Chaque navigateur a son propre mode de gestion de la mise en forme dans le copié-collé, selon les OS et même les versions de navigateurs. C'est un domaine où rien n'est normalisé, où les soucis sont nombreux, mais qui n'a guère de rapport immédiat avec ce qui nous occupe. --Lgd (d) 7 décembre 2011 à 11:47 (CET)

Réponse du comte Ɲemoi – C’est un domaine où en l’absence de norme, il convient de vérifier manuellement que les résultats ne sont pas aberrants, et s’ils ne sont pas améliorables — puisqu’on en est à passer par un script. Je note que contrairement à une certaine solution à l’arrache, on dispose d’espacements corrects ; reste le rendu non-inline de Firefox qui, si quelqu’un y voit une solution pas trop gourmande, reste à gérer. Ce 7 décembre 2011 à 12:09 (CET).

Concernant test7 et la structure de palettes refondues : pas plus de dl dt dd que de tableaux. Ce sont de simples menus de navigation à base de listes UL éventuellement imbriquées. Ce qui prépare la voie à l'utilisation future du landmark nav et de l'élément menu. --Lgd (d) 7 décembre 2011 à 11:59 (CET)

Réponse du comte Ɲemoi – Le test7 était parti d’une expérimentation à base de listes simples, et sa syntaxe reste assez rigide pour pouvoir être modifiée ainsi à la volée sans erreur. Pas convaincu qu’il y ait de manière de mieux préparer l’avenir pour le moment, mais je ne demande qu’à être contredit sur ce point. Ce 7 décembre 2011 à 12:09 (CET).

Infobox V3, ça part en sucette

Trois modèles de briques supplémentaires d'infobox V3 ont été créés sans concertation ces derniers temps :

• Modèle:Infobox V3/Carte dont le code ne répond pas aux objectifs d'accessibilité de ce jeu de modèle (heureusement non utilisé pour le moment)
• Modèle:Infobox V3/Géolocalisation qui ne pose pas ce type de problème, mais qui est inutile sous cette forme (le coeur du modèle n'est pas d'être une ligne de tableau, mais simplement un contenu spécifique pour lequel les modèles existants suffisent) (idem, pas encore utilisé heureusement)
• Modèle:Infobox V3/Tableau Ligne avancement Même problème que la précédente. Il est utilisé dans une seule infobox.

Deux points clés à bien garder en mémoire :

1. Multiplier les sous-modèles V3 à l'image des confuses briques qui se sont accumulées dans les V2 est à éviter. Un modèle ne devrait être créé qu'en cas de nécessité confirmée.
2. Convertir en V3 des infobox dont le contenu ne peut actuellement pas être géré de manière accessible est inutile, voire dommageable : tout ce qui recourt à des cartes de géolocalisation est à ce titre à exclure des refontes en V3.

Il va falloir rattraper le tir pour supprimer ces trois modèles, donc. --Lgd (d) 7 décembre 2011 à 09:54 (CET)

Réponse du comte Ɲemoi – Hoplà, avant qeu je n’oublie, pense à faire des liens de type [//fr.wikipedia.org/ bla] à présent qu’on en a la possibilité (je corrige ceux de ton message).

Les V3 présentent plusieurs problèmes de conception, dont notamment la rigidité (Ligne mixte…). Il y a le choix entre diversifier le nombre de modèles et permettre la spécification d’un type de donnée ; cela permettra de conserver une certaine connaissance du contenu des cases de tableaux — et notamment d’éviter l’imbrication de tables à laquelle on ne va pas couper autrement. De manière générale, éviter l’imbrication de modèles d’affichage (modèle : Avancement / modèle : Infobox Parti politique/Sièges, modèle : Coord, etc.) est une bonne chose. Ce 7 décembre 2011 à 10:49 (CET).

Cette rigidité toute relative (qui reste à mesurer) est nécessaire. Après, ce sont des questions de contenus pertinents ou non, plutôt que des questions techniques. Par ailleurs, si l'imbrication de tableaux est exclue, le pullulement de modèles sans évaluation et qualification de qualité l'est tout autant. Sinon, autant supprimer le tout, c'est aussi une option. Dans tous les cas, je ne compte pas contribuer sur ce terrain autrement que de manière rigoureuse. Ce n'est pas un souci, on peut aussi supprimer l'aspect accessibilité et sémantique de ces infobox et en faire simplement une couche supplémentaire de modèles sans valeur ajoutée. --Lgd (d) 7 décembre 2011 à 11:23 (CET)

Réponse du comte Ɲemoi – Tes différents cauchemars ne me regardent pas ; il est plus rigoureux d’offrir des moyens de formater des données qui doivent être présentes que d’espérer que les contributeurs penseront à l’accessibilité lorsqu’ils en auront le besoin. Ce 7 décembre 2011 à 11:52 (CET).

A moins d'interventions d'autres contributeurs à même de faire avancer les choses, je vais laisser le chantier Infobox V3 mais après en avoir retiré toute mention d'amélioration de l'exploitabilité des données, de sémantique et d’accessibilité. Ce sera donc juste au final un bis du chantier V2, hélas. Ce n'est pas si dramatique au milieu des multiples chantiers de Wikipédia dont tant de bouts sont améliorables, mais au prix de certains sacrifices et notamment d'un mode de décision davantage fondé sur l'obstination que sur la compétence. En tous cas, il est exclu de continuer sur ce mode où un intervenant fait de l'obstruction sous prétexte qu'il déclare (je ne sais plus où hier) s'occuper de mise en forme et non de sémantique. --Lgd (d) 7 décembre 2011 à 12:35 (CET)

J'ai fait la mise à jour sur la page Modèle:Infobox V3 pour refléter l'état des choses actuel. Me recontacter si la situation se débloque. --Lgd (d) 7 décembre 2011 à 12:56 (CET)

C'est vraiment dommage . Des infobox-taxobox-modbox bancales on en a déjà suffisamment sur Wikipédia. A quoi bon multiplier les versions et augmenter la confusion générale si l'accessibilité ne s'en trouve pas améliorée ! C'est parfois à la limite du ridicule de vouloir tout mettre en fiche (cf. Elio Di Rupo qui en devient incompréhensible ou Berkélium qui a vidé l'article de son contenu) mais, si on va dans ce sens, le minimum serait que le contenu en soit accessible à tous ! --Amicalement, Salix ( converser) 7 décembre 2011 à 13:11 (CET)

Il ne faut pas se cacher que ce genre de problème, sur Wikipédia, peut rapidement et totalement ruiner un effort, d'où mon abord assez direct des choses. On peut cependant aussi espérer que cela se remette dans le bon chemin une fois que les limites d'interventions de bonne foi de contributeurs comme Nemoi seront gérées, notamment en mettant en évidence où, comment il faut mieux documenter ces infobox V3 pour éviter ce genre de soucis. Je souligne encore une fois après l'avoir fait dans sa page de discussion la pertinence de bcp de ses interventions dans les modèles ces derniers temps. C'est juste que là, la question est un peu plus difficile et que la documentation ainsi que le processus de validation devraient être le premier souci, avant de développer d'autres modèles ou de se mettre à bouger des choses dans les fichiers systèmes. Pour le moment, la démarche d'infobox V3 est en arrêt, disons. Mais l'urgence était dans tous les cas plus de mieux l'expliquer que de créer de nouvelles infobox. --Lgd (d) 7 décembre 2011 à 13:42 (CET)

Réponse du comte Ɲemoi – Laisse le bébé infoboîtes V3 grandir un peu sans son papa, il en a bien besoin. L’accessibilité ne se fait pas au compte-gouttes tant qu’il n’y a pas un gigantesque ménage de fait dans les codes affreux qui pullulent (les V1 et les V2 modulaires, pour ce qui me panique le plus actuellement, à présent que les classes hiddenStructure ont été virées). Développer un méta modèle rigide en croyant qu’il ne sera jamais hacké est utopique ; il vaut mieux prévoir les différents cas tant qu’ils peuvent être sous contrôle. M’est avis que ta compétence et ta prévenance en technologies à venir seraient plus utiles pour dégrossir le travail des palettes de navigation. Ce 7 décembre 2011 à 13:54 (CET).

Et voilà, on retourne à la v2 grâce à la non concertation. Encore un bel exemple du travail collaboratif... Merci à tous. --'toff ^[discut.] 7 décembre 2011 à 15:06 (CET)

Soyons clair, je n'essayerai pas d'entreprendre quoi que ce soit sur d'autres sujets, à commencer par les palettes de navigation, dans ces conditions. Je n'en ai pas le temps ni la capacité s'il s'agit de s'empêtrer encore une fois dans les particularités wikipédiennes, et ce serait peu profitable pour ce projet vu mon manque assumé de patience à cet égard. --Lgd (d) 7 décembre 2011 à 15:26 (CET)

Il ne faut pas baisser les bras Lgd ! Souviens-toi de tes doutes lors de la création de cet atelier. Je crois que l'accessibilité, même de façon chaotique, fait petit à petit son chemin dans la tête des wikipédiens au fils des reverts et des explications. Exactement comme cela a été le cas pour le sourçage, domaine dans lequel la Wp.fr est devenue un exemple grâce aux efforts du Projet:Sources et de sa Manon. J'ai un peu retouché ton message d'intro pour essayer de recadrer les contributions dans le bon sens : Cela vous convient ? --Amicalement, Salix ( converser) 7 décembre 2011 à 18:36 (CET)

@NeMoi : si je comprends bien, toi et Ju Gatsu Mikka avez créé des modèles afin de pouvoir convertir toutes les infobox en V3 (dans l'idéal). Cela part d'une bonne intention, V3 existe donc il faut l'utiliser. Mais si on fait les choses ainsi, il n'y a aucune différence entre V2 et V3 hormis le nom.

La démarche, c'est de passer à la V3 au cas par cas, par étapes, en préparant bien chaque étape. Quitte à ce que ce projet avance lentement. Il n'y a pas d'urgence à passer en V3.

Si on suit ta démarche NeMoi, on va se ruer sur V3 pour corriger des défauts de la V1 et V2. Mais on va tellement se précipiter qu'on va mal faire le choses, et que V3 contiendra tout autant de défauts que V2. Donc on fera quoi, une V4, et on va la rater de nouveau ?

Mieux vaut s'assurer qu'on fasse bien les choses. Dodoïste ^{[ dring-dring ]} 8 décembre 2011 à 14:45 (CET)

Réponse du comte Ɲemoi – Je ne connais pas le cas Ju (à première vue, /Carte est mal pensé : puisqu’il génère le code :

code

<div class="img_toggle" id="img_toggle_0">
<div class="geobox image2" title="Carte topographique" id="geobox_0_0" style="border-top-width: 0px; border-top-style: initial; border-top-color: initial; display: none; ">
<table class="DebutCarte" border="0" cellspacing="0" cellpadding="0" style="margin:0;border:none;padding:0">
<tbody><tr>
<td style="border:none;padding:0">
<div style="position:relative;">
<div class="thumb tright">
<div class="thumbinner" style="width:222px;"><a href="/wiki/Fichier:France_relief_location_map.jpg" class="image"><img alt="Carte topographique" src="//upload.wikimedia.org/wikipedia/commons/thumb/f/f7/France_relief_location_map.jpg/220px-France_relief_location_map.jpg" width="220" height="211" class="thumbimage"></a>
<div class="thumbcaption">
<div class="magnify"><a href="/wiki/Fichier:France_relief_location_map.jpg" class="internal" title="Agrandir"><img src="//bits.wikimedia.org/skins-1.18/common/images/magnify-clip.png" width="15" height="11" alt=""></a></div>
Voir la carte topographique</div>
</div>
</div>
<div style="position:absolute;top:25.175447619049%;left:51.593848101261%;width:0px;height:0px;margin:0;padding:0;line-height:0px;background-color:transparent;">
<div style="position:relative;top:-8px;left:-8px;width:16px;height:16px;background-color:transparent;"><img alt="Localisation de la ville" src="//upload.wikimedia.org/wikipedia/commons/thumb/5/5d/City_locator_14.svg/16px-City_locator_14.svg.png" width="16" height="16"></div>
<div style="position:relative;top:-16px;">
<div style="font-size:90%;position:relative;top:-1.65em;left: 0.5em;text-align:left;width:12em;line-height:1.2em;"><b><a href="/wiki/..." title="..." class="mw-redirect">...</a></b></div>
</div>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
<div class="geobox image2" title="Carte administrative" id="geobox_0_1" style="border-top-width: 0px; border-top-style: initial; border-top-color: initial; ">
<table class="DebutCarte" border="0" cellspacing="0" cellpadding="0" style="margin:0;border:none;padding:0">
<tbody><tr>
<td style="border:none;padding:0">
<div style="position:relative;">
<div class="thumb tright">
<div class="thumbinner" style="width:222px;"><a href="/wiki/Fichier:France_location_map-Regions_and_departements.svg" class="image"><img alt="Carte administrative" src="//upload.wikimedia.org/wikipedia/commons/thumb/3/3b/France_location_map-Regions_and_departements.svg/220px-France_location_map-Regions_and_departements.svg.png" width="220" height="211" class="thumbimage"></a>
<div class="thumbcaption">
<div class="magnify"><a href="/wiki/Fichier:France_location_map-Regions_and_departements.svg" class="internal" title="Agrandir"><img src="//bits.wikimedia.org/skins-1.18/common/images/magnify-clip.png" width="15" height="11" alt=""></a></div>
Voir la carte administrative</div>
</div>
</div>
<div style="position:absolute;top:25.175447619049%;left:51.593848101261%;width:0px;height:0px;margin:0;padding:0;line-height:0px;background-color:transparent;">
<div style="position:relative;top:-8px;left:-8px;width:16px;height:16px;background-color:transparent;"><img alt="Localisation de la ville" src="//upload.wikimedia.org/wikipedia/commons/thumb/5/5d/City_locator_14.svg/16px-City_locator_14.svg.png" width="16" height="16"></div>
<div style="position:relative;top:-16px;">
<div style="font-size:90%;position:relative;top:-1.65em;left: 0.5em;text-align:left;width:12em;line-height:1.2em;"><b><a href="/wiki/..." title="..." class="mw-redirect">...</a></b></div>
</div>
</div>
</div>
</td>
</tr>
</tbody></table>
</div>
<ul id="geoboxToggleLinks_0"><li><a id="geoboxToggle_0_0" href="javascript:;">Carte topographique</a></li><li style="display: none; "><a id="geoboxToggle_0_1" href="javascript:;">Carte administrative</a></li></ul></div>

 

là où il n’y a que quatre données intéressantes : la latitude, la longitude, et le type de carte ×2), et je ne me suis pas encore assez penché sur le cas V3 pour pouvoir dire à quelle pourcentage on gère l’ensemble des cas (on ne les gère pas tous, c’est tout ce que je sais). La différence principale entre les V2 et les V3 est qu’au lieu d’avoir un tableau foutoir dans lequel rentre un peu tout ce qu’on veut, on a des données proprement classées par type, dans le code wiki comme dans le code html ; c’est en soi un net gain pour la maintenance et l’accessibilité, qui se passe très bien d’un « contrôle qualité » que certains souhaiteraient. Il y a beaucoup plus urgence à nettoyer tous les codes foireux qui existent — j’y case les codes V1, les V2 modulaires, et les V2 pas en briques — et à offrir des moyens aux créateurs d’infoboîtes de fournir des données structurées, qu’à faire passer au compte-goutte les infoboîtes à un label qualité. Si ce dernier point semble si important à certains, c’est au-dessus de la couche V3 qu’il faut le faire ; faites les versions Pi, qu’on s’amuse un peu. Ce 8 décembre 2011 à 15:12 (CET).

Nemoi, comme cela t’a été expliqué, il n’y a pas d’urgence à passer aux V3 si c'est pour devoir refaire les mêmes erreurs de conception que les V2. Histoire d’en remettre une couche après Salix, Supertoff, Dodoïste et Lgd, si ton objectif de nettoyer les codes foireux qui existent est louable, celui de maintenir un minimum de qualité dans la conception des V3 l’est tout autant. Et tu es apparemment le seul ici à ne pas le penser. C'est regrettable, mais à un moment tu devrais peut-être te demander si tu n’aurais pas tort, d’ainsi vouloir défendre ton point de vue (qui, de notre point de vue, entraîne des problèmes de conception) contre ceux de la majorité… Au lieu de demander à tout le monde sauf toi de passer à des versions Vπ, tu pourrais peut-être, toi, passer à une version Ve, en guise de préalable à une 3-isation. Litlok (m'écrire) 8 décembre 2011 à 15:33 (CET)

Réponse du comte Ɲemoi – Il y a urgence à rendre les infoboîtes accessibles ; toutes celles que j’ai créé le sont, même si toutes n’ont pas le label « créé au compte-goutte ». Si tel est le souhait de l’atelier accessibilité, je peux forker le code, ça ne me dérange pas, ça me semble juste idiot. Avec sympathie, ce 8 décembre 2011 à 15:46 (CET).

Nemoi, sur la forme : peut-on éviter la glissade vers les artifices polémiques du type "certains" ? Ici, c'est Lgd, Nemoi, Dodoïste, Salix, Litlok qui discutent d'un problème précis et technique. Se voir qualifié de "certains" est très désagréable et n'apporte rien d'utile.

Cela étant dit, pour en venir au fond : j'y vois un peu plus clair dans ce qui semble être ta démarche après ton message. Il y a en effet une question à poser ou à préciser dans l'usage de ces infobox V3 :

• s'agit-il de s'en tenir à améliorer l'améliorable au cas par cas en produisant des infobox V3 dans tous les cas, avec un résultat parfois effectivement accessible, parfois non en raison de contenus spécifiques et malgré une structure globale améliorée ?
• s'agit-il de s'en tenir pour l'usage des V3 seulement au cas d'infobox où le résultat sera effectivement accessible (sémantique, exploitable etc.) sans qu'il y ait besoin d'y revenir ensuite ?

La première option élargit quantitativement le bénéfice apparent, mais elle le réduit du même coup qualitativement, de manière considérable. En quelque-sorte, cela consiste à faire du chiffre. Il n'y a en effet qu'un bénéfice très réduit à produire des infobox V3 dont le contenu sera en grande partie techniquement correct, mais avec un gros pavé reconduisant les erreurs du passé en plein milieu. Surtout si on qualifie le tout d'accessible et d'amélioré, ce qui va donner à penser aux contributeurs que la question est réglée alors que tout restera à faire pour une bonne partie de ces infobox.

La seconde approche, plus restrictive, a le mérite de la lisibilité (ce qui est V3 est accessible etc., le reste est à travailler). Elle ne repose pas sur une intention de labelisation ou d'excellence. Elle se fonde simplement sur le fait de recourir à un outil donné avec le niveau d'exigence approprié : le bon outil au bon moment au bon endroit, avec discernement, avec un résultat robuste.

Le même type de question se pose sur la gestion des modèles et leur maintenance, en dehors du problème d'accessibilité du contenu :

• refaire un jeu de modèles étendu sans contrôle au cas par cas, comme les V2, ce qui aboutit à un fouillis de briques difficiles à maintenir, à évaluer, avec à l'avenir des doublons, des modèles inutiles, etc. ?
• s'en tenir à l'idée initiale des V3, c'est à dire un jeu de modèle minimal structurant le cadre global du contenu d'une infobox, permettant de répondre aux besoins courants en matière de données en tableaux, et laissant la possibilité de contenus variés par le biais d'appels à d'autres modèles ?

Après l'expérience des V2 et après en avoir tiré les enseignements, j'en reste à la seconde possibilité qui, là aussi, est plus restrictive dans l'idée de disposer de meilleurs outils.

Par ailleurs, si tu estimes qu'il y a urgence à nettoyer certains types d'infobox, ce n'est pas le souci : passer du V1 en V2, ou du V2 pas modulaire à du V2 modulaire peut par exemple être le moyen le plus approprié à cet effet, sans nécessité de faire du V3. C'est un moyen tout à fait cohérent avec l'idée d'améliorations progressives.--Lgd (d) 8 décembre 2011 à 15:55 (CET)

Je rappelle par ailleurs que les infobox v3 avaient pour qualité première, et c'est pour ça qu'elles ont été créées, l'accessibilité. Elles étaient d'ailleurs catégorisées comme modèle accessible. Avec ces nouveaux modules ajoutés, cette catégorisation a été perdue et les v3 ne servent plus à grand chose. Mon avis est que ces nouveaux module n'ont pas le label v3 (qui reste un label d'accessibilité lié à l'atelier) : on les supprime ou on les renomme, quitte à les réintégrer si un jour elles sont utiles et accessibles. C'est peut-être radical, mais je ne vois pas pourquoi les efforts consentis depuis des mois pour l'accessibilité seraient réduit à néant maintenant. Si certains veulent faire des tests, ils peuvent utiliser une sous-page de brouillon. --'toff ^[discut.] 8 décembre 2011 à 16:35 (CET)

Réponse du comte Ɲemoi – On dirait que tu n’as pas bien compris quelque chose : l’accessibilité n’est pas remise en cause par l’existence ou non du modèle : Infobox V3/Tableau Ligne avancement (je ne me prononce pas pour les autres… il ne vaut mieux pas pour eux) ; seul le label « créé au compte-goutte » (pardon : « catégorisé comme modèle accessible ») l’est. Et ce n’est pas en essayant de crier plus fort que tu changeras cet état de fait. Ce 8 décembre 2011 à 16:49 (CET).

(édith) Idem 'toff, Lgd, Salix, Dodoiste, Litlok : les éléments des infobox V3 doivent être élaborés en concertation étroite avec l'atelier accessibilité, en prenant le temps qu'il faut pour bien faire les choses. Pour ce qui est des deux tests non utilisés de Ju gatsu, je les ai renvoyés à leur emplacement origine en sous page utilisateur de leur créateur. Pour ce qui est de la création de Némoi, je serai tenté d'en faire autant, mais le modèle est utilisé... Udufruduhu (d) 8 décembre 2011 à 17:05 (CET)

Remarque du naïf de service : + 1 avec Udufruduhu et les autres. Je n'y connais rien en code mais, de façon logique, soit tous les éléments associés au projet V3 sont parfaitement accessibles, soit ils n'en méritent pas le nom, sinon cela discrédite toute cette démarche. Justement parce que bon nombre de Wikipédiens comme moi - qui veulent bien faire mais qui sont incapables de s'assurer par eux-mêmes qu'aucune partie du code ne déroge aux conditions d'accessibilité - ont pour seule certitude qu'un titre de la forme « machin V3 » = « parfaitement accessible ». C'est le seul moyen pour que chacun soit sûr de préserver l'accessibilité de l'article sur lequel il travaille, même, et surtout, s'il fait bêtement du « copier/coller ». --Amicalement, Salix ( converser) 8 décembre 2011 à 17:30 (CET)

Réponse du comte Ɲemoi – Pour ce qui concerne la brique que j’ai réalisé, elle est accessible. Je gère les choses à ma manière, la page modèle : Infobox V3/Tableau Ligne avancement est demandé en passage en SI. Ce 8 décembre 2011 à 17:34 (CET).

NeMoi, pourrais-tu prendre le temps de savoir ce qui ne vas pas avec ton modèle ? Je vois que tu l'utilises pour indiquer un nombre d'élus sur un total (sénat, etc.), ce qui est très courant sur les infobox politique. Vu que c'est répandu, c'est un contenu que nous devrons faire passer en V3 un jour ou l'autre. Donc nous nous pencherons sur la question.

En gros, on te dit « ce modèle n'est pas acceptable en l'état ». Tu as simplement à demander pourquoi, et si on peut l'améliorer, et on se penche sur la question. Ensuite, soit ce modèle est amélioré, soit la question sera mise en attente jusqu'à ce qu'on trouve un moyen acceptable de produire ce contenu. Commence déjà par tenter d'en savoir plus sur le problème que pose ton modèle. Moi-même je ne suis pas sûr d'avoir compris. En effet, ce n'est pas un problème d'accessibilité, apparemment. Je fais confiance à Lgd pour avoir une bonne raison, donc j'aimerais bien savoir quel est le problème.

On te demande simplement plus d'écoute, c'est essentiel sur un projet collaboratif. Dodoïste ^{[ dring-dring ]} 8 décembre 2011 à 17:44 (CET)

Réponse du comte Ɲemoi – Pour la troisième fois : le modèle est acceptable en l’état ; il déroge juste au principe de n’utiliser qu’un nombre très (trop, selon moi) limité de boîtes. Ce 8 décembre 2011 à 18:01 (CET).

modèle: Infobox V3/Tableau Ligne avancement

Je fais un retour à la ligne et une section, les choses ayant avancé et le problème qui subsiste étant très spécifique.

Merci à Udufruduhu pour le déplacement des deux premiers modèles, j'avais invité Ju gatsu à le faire mais il n'a pas contribué depuis mon message ; je pense qu'il ne verra pas ombrage à ce déplacement nécessaire.

Concernant modèle: Infobox V3/Tableau Ligne avancement : je pense avoir bien distingué tout au long de cette section deux problèmes différents. Celui des briques non accessibles et celui des briques redondantes et non nécessaires. On est essentiellement dans le deuxième cas, que je reprécise :

• en tant que ligne de tableau, ce modèle produit une ligne déjà couverte par les modèles existants
• sa seule spécificité est le contenu de la cellule de donnée. Il suffit, dans le modèle d'infobox, d'appeler un modèle produisant une barre d'avancement, tout comme il arrive qu'on ait des infobox avec des appels à des modèles d'abréviation, etc.

La solution a été indiquée dans la page de discussion de Nemoi : utiliser un des modèles de ligne de tableau existant plutôt que d'en créer un de plus. Et appeler dans celui-ci un modèle spécifique produisant cette barre d'avancement. Pour ce modèle spécifique, soit il faut le créer, soit il existe déjà. Il me semble que Modèle:Avancement pourrait être utilisé, après une éventuelle modification pour en améliorer les fonctionnalités (ne pas forcer l'usage d'un pourcentage).

Pour le moment, où en est-on ? Nemoi a renommé modèle : Infobox V3/Tableau Ligne avancement en Modèle:Infobox Pi/Tableau Ligne avancement, qui est utilisé dans Modèle:Infobox Conseil général, modèle d'infobox qui mêle du coup des briques V3 et un nouvel appendice dans le monde folklorique des infobox, les infobox Pi... Voilà qui va simplifier les choses.

Je suis désolé de devoir insister, Nemoi, mais ça ne le fait toujours pas. Pourrais-tu, pour ce cas précis, tirer parti de la solution indiquée ci-dessus ? Et plus généralement, soit utiliser les V3 « avec nous », quitte à les faire évoluer mais de manière réfléchie, soit faire du V2 modulaire là où V3 n'est pas adapté, sans aller créer une inutile et surréaliste chapelle « Pi » qui reconduit ce qu'on a vu de pire par le passé en matière d'échec collaboratif sur les infobox ? --Lgd (d) 8 décembre 2011 à 17:46 (CET)

Réponse du comte Ɲemoi – Je suis les conseils de Litlok : ces infoboîtes ne sont pas des V3, et n’ont pas le « label qualité » de l’Atelier d’accessibilité. Elles serviront d’expérimentation pour évolutions des V3, et me serviront accessoirement à nous débarrasser des V1 pour en faire des modèles globalement accessibles. Ce 8 décembre 2011 à 17:59 (CET).

Faut-il ajouter et souligner que tu as, par ailleurs, non seulement fait avancer ces derniers temps d'excellentes choses en matière de styles common.css (hiddenstructure et d'autres nettoyages) ce qui a été souligné dans ta page de discussion notamment, mais aussi produit d'autres infobox V3 sans aucun problème, tout à fait bienvenues ? C'est un peu dommage, tout de même, ce psychodrame inattendu que tu prolonges ;-) --Lgd (d) 8 décembre 2011 à 18:01 (CET)

Réponse du comte Ɲemoi – Il n’y a de psychodrame que dans ta tête, les infoboîtes V3 se portaient très bien avec cette brique. Ce 8 décembre 2011 à 18:05 (CET).

Pour ceux moins techniques qui cherchent à suivre (), le choix en discussion est entre, schématiquement (je simplifie les choses, le modèle {{Avancement}} ne le fait encore tout à fait comme il faudrait) :

• un nouveau modèle de brique d'infobox V3 supplémentaire qui refait ce que fait {{Infobox V3/Tableau Ligne mixte}} mêlé à ce que fait {{Avancement}}
• ou bien le recours au modèle de brique V3 {{Infobox V3/Tableau Ligne mixte}} déjà existant, en y appelant le modèle {{Avancement}}

Nemoi ne voit pas de souci à l'ajout d'une brique. Ma position plus restrictive vise à limiter la multiplication des briques. --Lgd (d) 8 décembre 2011 à 18:21 (CET)

Réponse du comte Ɲemoi – Pour préciser ma position : on ne peut pas mettre un surveillant derrière toutes les créations d’infoboîtes. Or, il est nécessaire dans certaines infoboîtes qu’il y ait une barre d’avancement. À partir de là, soit on espère que les concepteurs d’infoboîtes penseront à utiliser le modèle : Avancement ; soit, on admet qu’il y en aura qui recoderont de zéro une solution si on ne leur donne pas la ligne qu’il faut — et ils useront vraisemblablement d’un tableau ou d’une timeline, ce qui est absolument à éviter. De manière générale, il faut un modèle V3 par type de donnée (un « avancement » étant un type de donnée composite). Ce 8 décembre 2011 à 18:32 (CET).

Je pense que c'est le point sur lequel nous ne sommes fondamentalement pas d'accord, d'un côté au moins toi Lgd et de l'autre au moins Nemoi et moi-même : l'usage de briques pré-construites aux usages spécifiques.

Personnellement, j'ai toujours considéré depuis son apparition que ce projet annexe au infoboite (et qui, rappelons le, n'a rien à voir avec le stade V2, qui est simplement une amélioration visuelle des infoboites, mais qui c'est basé sur ce standard parce que c'était celui en usage) était une amélioration d'un autre genre d'accessibilité, certes non pas pour le lecteur, mais plutôt pour le rédacteur puisqu'il s'agit pour ainsi dire du manuel de « l'infobox pour les nuls », facilitant ainsi à la fois la conception et la maintenant de modèles, y comprit par des personnes peu expérimentées. Par ailleurs, comme le dit Nemoi, ça a aussi le mérite d'uniformiser dans l'absolue tous les codes des modèles, ce qui les rend un peu plus facile d'accès.

Par ailleurs, parfois la simple intégration directe de modèles préexistants a parfois des limites comme le montre l'exemple ci-dessous :

exemple

Atelier accessibilité/Archives accessibilité 2011

Localisation sur la carte de Russie Moscou.

---

---

Localisation sur la carte de Russie Moscou.

---

 

C'était, d'ailleurs ce défaut de placement de la carte qui avait motivé la création d'une nouvelle brique, mais un problème auquel je ne m'attendais pas (le placement du point qui garde la zone de définition initiale) et que je n'ai pas pu résoudre (y compris par l'ajout de css perso en test) en raison de la limitation de mes connaissances techniques, a eu raison de ma bonne volonté et j'avais laissé le modèle inachevé. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 8 décembre 2011 à 19:12 (CET)

Réponse du comte Ɲemoi – Je ne me suis pas complètement exprimé sur ce modèle. Les infoboîtes V3 se sont données pour but d’être accessibles — en dehors du projet de leur donner un label « fait au compte-goutte » — et ce module me semble donc bien mal pensé, car il ne fait guère mieux que les actuels. Pourtant, je ne vois pas d’impossibilité à concevoir une solution accessible, soit qui ne génère qu’un code « discret » (uniquement les coordonnées) pour les lecteurs d’écran, soit qui intègre à la volée le code lors de l’appui sur un bouton « fabriquer une carte ». Si tu veux, je bosserai cela à la page du modèle : Infobox Pi/Tableau Ligne géolocalisation. Avec sympathie, ce 8 décembre 2011 à 19:31 (CET).

Concernant le dialogue de sourds, j'ai cessé de m'y intéresser lorsque j'ai compris que tout ce remue-ménage portait sur un dilemme épique. Utiliser un modèle existant (avancement) dans un autre modèle existant (ligne d'infobox), ou alors créer un modèle ? C'est aussi productif que les élus du parti socialiste français qui se tapent dessus entre eux en temps de campagne.

Alors oui, il faut limiter le nombre de modèles parmi la masse qui pullulent, donc je suis plutôt du côté de Lgd. Et l'attitude de NeMoi ne donne pas du tout envie de céder à ses caprices - qui sait ce qu'il va nous demander ensuite ? Mais bon, si c'est pour arriver à ce stade de point mort, franchement, ça vaut pas la peine, autant créer ce fichu modèle.

Par contre, c'est essentiel de pouvoir dire les choses franchement, NeMoi. En l'état actuel, on ne peut pas travailler avec toi. Parce que tu es beaucoup trop insistant, et que tu donnes l'impression d'être persuadé d'avoir raison envers et contre tout. La base d'une collaboration, c'est le compromis, c'est comprendre les points de vues, les différences dans une équipe, et de jongler avec. Savoir faire preuve d'humilité, et savoir faire profil bas même quand on a raison, si la situation le nécessite. Et ce, quelque soit ton niveau de compétence. Si tu ne l'apprends pas ici, tu l'apprendras dans la vraie vie, par exemple dans le milieu du travail. Pour ma part, j'ai appris à gérer mes propres difficultés en équipe dans le milieu professionnel et personnel, dans la douleur et tout. C'était pas beau à voir, mais il faut parfois des situations extrêmes pour des cas comme moi.

Donc, NeMoi, ton point de vue a été lu et compris. Ta suggestion n'a pas été retenue pour le moment. Mais plutôt que faire bande à part, voyons comment on peut travailler ensemble. Ça ne mènera nulle part de faire deux projets doublons. Par contre, il y a de nombreux projets sur lesquels on avancera plus vite avec ton aide, et réciproquement tu peux bénéficier de notre aide. Donc tentons un peu plus d'écoute, si tu le veux bien. Dodoïste ^{[ dring-dring ]} 19 décembre 2011 à 14:34 (CET)

Réponse du comte Ɲemoi – Continue de me prendre pour un gamin, c’est bon pour l’ambiance. Ce 19 décembre 2011 à 23:01 (CET).

Je te considère pas plus gamin que moi qui suis adulte, si c'est la question. Ce que je te dis, c'est des conseils sur la forme de ton attitude, et cela n'a rien à voir avec l'âge. Si je ressens le besoin de le dire, je le dis pareil à un gamin qu'à un mec de 50 ballets. Le problème, ce n'est pas l'âge, ici, c'est l'attitude. Dodoïste ^{[ dring-dring ]} 20 décembre 2011 à 01:13 (CET)

« Si vous pensez avoir été agressé lors d'une discussion, la meilleure solution est peut-être de laisser passer un peu de temps avant de répondre. Ce laps de temps peut vous permettre de vous apaiser, de réfléchir posément au message qu'a voulu vous transmettre (maladroitement) votre « agresseur » et enfin de trouver les mots justes pour exprimer votre point de vue sur la question. Une réponse non réfléchie de votre part risque en effet d'envenimer la discussion. » (source). --Amicalement, Salix ( converser) 20 décembre 2011 à 11:29 (CET)

Améliorer l'alternative textuelle ou l'utilisation du modèle {{fait}}

Pour parler de choses moins diplomatiques, si quelqu'un se sent à une petite intervention/réflexion : le modèle {{fait}} qui produit l'icône est surtout utilisé en dehors des articles, où son alternative textuelle actuelle, qui est « fait », est généralement pertinente. Mais il est aussi utilisé dans quelques dizaines d'articles, dans des tableaux comme ceux de Liste des lignes de bus de Toulouse, où l'alternative « fait » ne convient pas du tout : l'icône veut alors dire « oui », et le « fait » est assez déroutant en pratique.

Sans avoir regardé plus avant, peut-être faut-il avoir deux alternatives automatiquement gérées dans le modèle en fonction du namespace, peut-être un autre modèle doit-il être recommandé dans les articles ? Peut-être autre-chose ? Quelqu'un pour s'en saisir ? --Lgd (d) 8 décembre 2011 à 18:34 (CET)

Pardonnez-moi si je dis une sottise, mais on ne pourrait pas pas utiliser le {{oui}} existant (rendu :  Oui) en ajoutant un paramètre pour n'afficher que l'icône ? --Amicalement, Salix ( converser) 8 décembre 2011 à 19:04 (CET)

Pour ne pas afficher le texte : un paramètre non dans le modèle {{oui}} ? Ca détend.--'toff ^[discut.] 8 décembre 2011 à 19:15 (CET)

Améliorations du gadget accessibilité

Le gadget accessibilité a besoin d'un bon coup de neuf, notamment après le passage à la dernière version de mediawiki. Avant de m'y attaquer, je note ici au fil de l'eau les points qui me viennent, n'hésitez pas à compléter et même à en demander plus, si besoin . --Lgd (d) 8 décembre 2011 à 20:07 (CET)

A faire :

• alternatives :
  • supprimer l'avertissement obsolète pour les alternatives des gallery, et afficher les alternatives des images concernées.
• langues :
  • ne pas signaler que le div class="mw-content-ltr" a un attribut lang fr.
• titres :
  • alléger le rendu, montrer les cas de détournement de « ; » comme titre de section
• tableaux :
  • ...
• Listes :
  • ...
• Citations :
  • ...

Autre souhaits :

• possibilité de l'utiliser sous forme d'extension Firefox plutôt que comme un gadget (ne nécessite pas d'être connecté, etc.)
• pour les cas automatisables : signalement immédiat dans la boîte accessibilité en cas de détection d'au moins une erreur, pour ne pas avoir à parcourir la page intégralement.
• bouton « Tout activer/désactiver »

Trop rien à dire sur le passage au nouveau mediawiki, auquel je ne pane à peu près rien (même si je devine que ce div class="mw-content-ltr" est la raison pour laquelle tout l'article était inclus dans un grand cadre ces derniers temps, et que les galeries vont enfin pouvoir être accessibles !), mais j'avais une remarque plus générale : pourrais-tu coupler une option tout activer comme pendant de tout désactiver steuplé ? Merci d'avance, Totodu74 (devesar…) 8 décembre 2011 à 20:26 (CET)

Hop, noté. --Lgd (d) 8 décembre 2011 à 20:31 (CET)

La détection du type de côte des images ? Bloquée par une valeur en pixel ou adaptée aux paramètres de l'utilisateur par des multiplicateurs de la valeur par défaut (style upright). (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 8 décembre 2011 à 21:20 (CET)

Ce ne sera pas possible. La différence entre les deux manière de dimensionner les thumb n'apparaît de manière exploitable que dans la source wiki, mais le gadget n'y accède pas (il traite uniquement le code HTML produit à partir de cette source). Cela relèverait plutôt du Projet:Correction syntaxique. --Lgd (d) 9 décembre 2011 à 08:53 (CET)

Modèles de sommaires limités, ça intéresse quelqu'un ?

Une proposition de suppression des modèles {{Sommaire limité au niveau 1}}, {{Sommaire limité au niveau 2}} et {{Sommaire limité au niveau 3}} a été émise: Discussion modèle:Sommaire limité au niveau 1/Suppression. Elle va sans doute s'orienter vers la conservation, mais le souci, c'est de traiter en bloc les 3 modèles. Voir mes explications dans la PàS : le premier modèles est très certainement inutile, le second à voir, mais le troisième est un compromis actuellement nécessaire pour éviter que les gens ne fasse de faux titres de section pour éviter un sommaire trop long (voir Bonnes pratiques, structure des articles, titres de section).

Il faudrait donc regarder de plus près les usages effectifs de ces trois modèles, et avoir des éléments précis pour prévoir une éventuelle suppression du ou des deux premiers, et la conservation du troisième. Ou réfléchir à des solutions plus intelligentes. S'il y a quelqu'un d'intéressé par le sujet ?

--Lgd (d) 10 décembre 2011 à 13:29 (CET)

Peut être déjà faire comme pour l'équivalent de WPen : un modèle unique (chez eux limité au niveau 2 par défaut) avec la possibilité de changer au cas par cas la limite. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 10 décembre 2011 à 13:34 (CET)

Lien interne Atelier accessibilité, Bonnes pratiques, structure des articles, titres de section Visite fortuitement prolongée (d) 10 décembre 2011 à 23:33 (CET)

Il me semble que la solution soit {{sommaire}}. Udufruduhu (d) 11 décembre 2011 à 03:28 (CET)

Bien vu, merci.

Il faudra mettre à jour common.css si la limitation au niveau 1 ne doit pas être conservée (suppression de .toc_niveau_1) et aviser pour le niveau 2.

A noter : le code de {{Sommaire}} pourrait aussi être allégé pour la fonctionnalité de sommaire flottant ou centré : utilisation des classes .floatright, .floatleft et .center plutôt que de styles inline et d'attributs de présentation. Il y a également un paramètre width qui n'est pas documenté.

--Lgd (d) 11 décembre 2011 à 08:48 (CET)

Amha, le niveau 1 peut être utile dans des discussions ou dans des pages comme celle-ci. il faudrait effectivement en limité l'usage, mais pas nécessairement le supprimer.

Par ailleurs, puisque les modèles concernés par la PàS semblent être en doublon avec un plus général, je pense qu'on peut clôturer la PàS, faire passer un robot pour finir le travail initié par Udufruduhu et les passer en SI après. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 11 décembre 2011 à 10:23 (CET)

Je suis entièrement d'accord. La limitation au niveau 1 peut-être utile dans de très rares cas comme celui mentionné par Ju ou comme dans Liste de bandes dessinées en ligne et Liste des députés européens de la deuxième législature. À première vue, il semble que cela concerne exclusivement les listes.

Sinon, j'ai effectivement commencé à remplacer partout les modèles par {{sommaire}} sans changer le niveau de limitation. Les modèles {{Sommaire limité au niveau 1}} et {{Sommaire limité au niveau 3}} ne sont maintenant plus utilisés. Par contre {{Sommaire limité au niveau 2}} a trop de pages liées pour pouvoir le faire à la main. L'aide d'un bot serait la bienvenue une fois la PàS clôturée.

@Lgd : pour ce qui est du nettoyage du code {{sommaire}} je te fais confiance, je ne suis pas assez qualifié pour en juger. Udufruduhu (d) 11 décembre 2011 à 11:02 (CET)

Pas de souci pour appuyer si besoin est une demande de bot le moment venu. Pour le niveau 1, je ne sais pas trop quoi penser de cet exemple pour le moment, sauf que ce n'est pas une page de l'espace article (avec TOC) mais une page d'un espace navigation (éventuellement sans TOC mais avec des contenus à plier/déplier: c'est un simple plan de site à son échelle). Pour le code, désolé, pas le temps, si quelqu'un est intéressé, c'est bien. Sinon, ce n'est pas grave. --Lgd (d) 11 décembre 2011 à 12:54 (CET)

Nettoyages d’hiver

Message du comte Ɲemoi – J’ai fait ce jour un tour dans la catégorie : Modèle accessible. On y trouve :

• le modèle : DemogFranceAR et le modèle : Démographie France (problématiques de mise en forme, heureusement inutilisés) ;
• le modèle : DemogNS (accessible ? ça l’était indiscutablement jusqu’en octobre 2009) ;
• le modèle : Lien sur icône, obsolète ;
• le modèle : ÉlectionDébut, qui peut facilement mener à ce rendu et dont le titre est formé par un colspan (j’avais en tête d’ajouter un
  table li { list-style-type: none; list-style-image: none; }
  à la Common.css, avec ou sans classe particulière, à faire ?) ;
• et le modèle : ÉluDébut, qui, n’offrant pas de solution pour les très longues listes, conduit logiquement à ce genre de choses.

C’était mon rapport de bug de la journée, je retourne nettoyer les usages du modèle : (. Avec sympathie, ce 15 décembre 2011 à 17:19 (CET).

Oui, c'est la notion de qualification de modèles, mais il semble que ce soit plus compliqué entre contributeurs quand il s'agit des infobox, c'est à dire plus compliqué de manière très prosaïque quand il s'agit de ce que tu souhaites faire en matière d'infobox V3. Il y a toutes sortes de solutions aisées et utiles, mais il reste à savoir si les mettre en place répond à un besoin et surtout à des possibilités réelles : pour le moment, et notamment à la suite des divergences sur les modèles d'infobox, je serais pour la suppression temporaires de ces catégories d'évaluation d'accessibilité. --Lgd (d) 18 décembre 2011 à 11:38 (CET)

Je rappelle juste, pour que ce soit plus compréhensible, le problème en suspens dans l'indifférence générale :

Pour le moment, où en est-on ? Nemoi a renommé modèle : Infobox V3/Tableau Ligne avancement en Modèle:Infobox Pi/Tableau Ligne avancement, qui est utilisé dans Modèle:Infobox Conseil général, modèle d'infobox qui mêle du coup des briques V3 et un nouvel appendice dans le monde folklorique des infobox, les infobox Pi... Voilà qui va simplifier les choses.

Cela signifie qu'on va voir se multiplier des modèles « Infobox Pi » mêlant des bouts d'accessibilité V3 et ce qui viendra à l'esprit des contributeurs indifférents à ce genre de chose. Je ne vois pas l'intérêt de conserver une qualification « modèle accessible » via les catégories dans ce contexte. C'est pourquoi j'ai retiré cette catégorie des modèles V3 pour le moment, mais l'utilité de cette catégorie reste du coup incertaine s'il y a désaccords sur son utilisation.

Ce n'est certes pas un souci majeur, mais il faut quand même le gérer. --Lgd (d) 18 décembre 2011 à 11:50 (CET)

Réponse du comte Ɲemoi – Tes inquiétudes autour des infoboîtes te regardent. J’ai parlé du contenu de la catégorie : Modèle accessible telle qu’elle est actuellement, car c’est en l’état une vaste plaisanterie. Ce 18 décembre 2011 à 12:03 (CET).

Oui, la gestion de cette catégorie est évidemment à revoir de toutes façons, tu en as donné des exemples tout à fait pertinents, ce n'est pas la question. Si ce n'était que cela, il y a juste du travail à faire et une réflexion à mener. Ce que j'en disais ci-dessus, c'est qu'elle est en fait à supprimer AMHA étant donné qu'en plus, en y regardant plus complètement, elle est actuellement rendue inutile par d'autres problèmes plus conjoncturels auxquels tu es lié, car c'est aussi un problème déjà souligné de « le contributeur truc est un trublion». Ce n'est pas un souci majeur, la solution de la suppression a le mérite d'évacuer des controverses peu profitables.

Pour résumer :

• En pour, il y a l'évacuation de discussions improductives ainsi que le constat qu'elle exige un suivi actuellement non assuré ;
• En contre, il peut y avoir une perte du côté aide aux contributeurs intéressés par l'accessibilité, auxquels cette catégorie donnait une indication immédiate mais à condition d'être rigoureusement gérée.

Elle n'est pas rigoureusement gérée et sa gestion semble compliquée pour des raisons annexes mais incontournables. Le pour l'emporte, il me semble, pour le moment.

Donc : des objections à tout simplement supprimer catégorie : Modèle accessible qui est un outil potentiellement utile mais actuellement inopérant pour toutes sortes de raisons ? Passons à autre chose, svp --Lgd (d) 18 décembre 2011 à 12:21 (CET)

Réponse du comte Ɲemoi – Ce n’est pas car les infoboîtes V3 ne sont pas accessibles qu’il faut supprimer la catégorie : Modèle accessible ! Il serait bien plus efficace d’en faire une catégorie listant effectivement les modèles accessibles. Ce 18 décembre 2011 à 12:28 (CET).

Nemoi : outre que ces catégories sont restées un essai en friche (catégorie : Modèle accessible n'est pas la seule en fait), tu ne peux pas à la fois jouer l'obstruction sur la question des infobox V3 dont tu ne veux apparemment pas faire un modèle effectivement accessible, et dire qu'il y aurait des moyens « bien plus efficace d’en faire une catégorie listant effectivement les modèles accessibles ».

Au-delà de ces questions momentanées, il y a d'autres questions d'utilité de ces catégories que ton relevé de modèles où cela n'a pas été suivi met bien en évidence.

Bref, bon, on ne va pas y passer une semaine : on supprime et on passe à plus utile. On reparlera de tout cela plus tard, quand ce sera profitable.

Sauf interventions percutantes d'autres gens, je regarde ce WE pour faire les retraits nécessaires de catégories et demander les suppressions. De toute façon, à part le dialogue de sourds Lgd/Nemoi, personne n'est intéressé : simplifions, enlevons le superflu . --Lgd (d) 18 décembre 2011 à 13:44 (CET)

Pour répondre sur le sujet, oui, supprimons cette catégorie. Il suffit qu'on soit occupé ailleurs un moment (nos wikibreaks respectifs) pour que des modifications peu adéquates soient faites. Cela fait partie du jeu, quand on veut faire de la qualité sur un Wiki. Dons laissons de côté cette approche qui a peu d'intérêt à terme. Pour l'autre sujet, je réponds dans la section qui va bien. Dodoïste ^{[ dring-dring ]} 19 décembre 2011 à 14:17 (CET)

+1. Y a que ça d'accessible ? Car ça sous-entend que tout le reste ne l'est pas. Et puis, qu'est-ce qui certifie qu'un modèle classé là l'est vraiment, accessible ? Il vaudrait mieux utiliser {{encart}} dans la documentation des modèles pour indiquer qu'ils ont été vérifiés à un date donnée par l'atelier. Dans une encyclopédie participative, comme le souligne Dodoïste, tout peut arriver... --Amicalement, Salix ( converser) 20 décembre 2011 à 11:20 (CET)

PS. Pourquoi "encart" n'a pas droit à des lignes horizontales pour délimiter le texte comme c'est le cas pour la plupart des modèles in line ?

Modèle {{Langue du titre}} mal utilisé

Si quelqu'un s'ennuie pendant une longue soirée d'hiver, le modèle {{Langue du titre}} est malheureusement utilisé dans des articles dont seule une partie du titre n'est pas en français. Les modèles {{Titre mis en forme}} et {{lang}} devraient alors être utilisés. Voir la liste ci-dessous. --Lgd (d) 29 décembre 2011 à 20:02 (CET)

Articles à corriger

• On Green Dolphin Street (album de Bill Evans)
• California, Here I Come (album de Bill Evans)
• Brother (album de Boyzone)
• Prince of Darkness (album d'Ozzy Osbourne)
• Live at Budokan (album d'Ozzy Osbourne)
• A Saucerful of Secrets (album)
• Please Please Me (album)
• Some Girls (album)
• Big Fun (album)
• Wish You Were Here (album)
• The Trip (album)
• Happily Ever After (album)
• Animal (album)
• Since We Met (album)
• Hot (album)
• Cheese (album)
• Streets of Gold (album)
• Roses (album)
• Garfield (jeu vidéo)
• Clipping (audio)
• The Breakfast Club (bande originale)
• Grease 2 (bande originale)
• Inland Empire (Californie)
• Queens' College (Cambridge)
• Perfect Day (chanson de Lou Reed)
• State of the Nation (chanson de New Order)
• Never Enough (chanson de The Cure)
• The End of the World (chanson de The Cure)
• The End (chanson des Beatles)
• Teddy Bear (chanson)
• Crush (chanson)
• Money (chanson)
• Boys Don't Cry (chanson)
• Freakshow (chanson)
• Just Like Heaven (chanson)
• Out of This World (chanson)
• Taking Off (chanson)
• Original Sin (chanson)
• Piotta (chanteur)
• Big Five (cinéma)
• Turn Out The Stars (coffret)
• Ejército popular de liberación (Colombie)
• Bootstrap (compilateur)
• National Socialist Movement (États-Unis)
• This is Tomorrow (exposition)
• Fortress (film)
• A History of Violence (film)
• That Was Then... This Is Now (film)
• House of the Dead (film)
• Black Rain (film)
• Tequila Sunrise (film)
• Shine a Light (film)
• Highway (film)
• Tiefland (film)
• Hardball (film)
• Escort Girl (film)
• That's Life! (film)
• Mrs. Dalloway (film)
• The Fatal Hour (film, 1908)
• The Devil (film, 1908)
• Money Mad (film, 1908)
• The Reckoning (film, 1908)
• One Touch of Nature (film, 1909)
• Love Finds a Way (film, 1909)
• The Sacrifice (film, 1909)
• His Wife's Mother (film, 1909)
• The Deception (film, 1909)
• The Fatal Wedding (film, 1914)
• A Study in Scarlet (film, 1914, Pearson)
• Enoch Arden (film, 1915)
• The Arab (film, 1924)
• Son of India (film, 1931)
• Go West, Young Man (film, 1936)
• Hollywood Boulevard (film, 1936)
• Captain Kidd (film, 1945)
• Thunderbirds (film, 1952)
• Hollywood Boulevard (film, 1976)
• A Christmas Story (film, 1983)
• September (film, 1987)
• Dark Angel (film, 1990)
• Hollywood Boulevard (film, 1996)
• Time and Tide (film, 2000)
• Fade to Black (film, 2004)
• The Dark (film, 2005)
• A Perfect Day (film, 2005)
• Annapolis (film, 2006)
• Control (film, 2007)
• Stardust (film, 2007)
• Black (film, 2009)
• Hollywood Boulevard (film, 2009)
• Rampage (film, 2009)
• Twelve (film, 2010)
• Fair Game (film, 2010)
• Óglaigh na hÉireann (groupe armé)
• Saor Éire (groupe armé)
• Bad Manners (groupe)
• Wire (groupe)
• Chain Reaction (groupe)
• Penetration (groupe)
• The Fall (groupe)
• Chelsea (groupe)
• A Taste of Honey (groupe)
• Book of Love (groupe)
• Public Enemy (homonymie)
• Never Again (homonymie)
• Clipping (infographie)
• Offset (informatique)
• Sprite (jeu vidéo)
• Uplink (jeu vidéo)
• Prey (jeu vidéo, 2006)
• The Addams Family (jeu vidéo)
• Killing Floor (jeu vidéo)
• Bootleg (jeu vidéo)
• The Italian Job (jeu vidéo, 2001)
• Resident Evil (jeu vidéo, 2002)
• Carbon (journal)
• Heterocycles (journal)
• Molecules (journal)
• Tetrahedron (journal)
• Langmuir (journal)
• Analyst (journal)
• Entropy (journal)
• Environmental Chemistry (journal)
• Macromolecules (journal)
• Nanotoxicology (journal)
• Silicon (journal)
• Sensors (journal)
• Polymer (journal)
• Contraception (journal)
• Bootleg (musique)
• Inland Empire (Nord-Ouest Pacifique)
• Washing machine (plongée)
• Autumn (roman)
• Paranoid Park (roman)
• Field Marshal (Royaume-Uni)
• Resistance (série)
• Space Invaders (série)
• Mass Effect (série de jeux vidéo)
• Arena (téléfilm)
• James Webb (télescope spatial)
• Amazing Grace (film, 2006)
• Blow-Up (Herbie Hancock)
• Bootleg (jeu vidéo)
• Down to Earth (Ozzy Osbourne)
• Elements (journal)
• Hush (film, 2008)
• Intermission (film)
• Live at the Budokan (Blur)
• Live in Europe (Rory Gallagher)
• Long Tall Sally (EP)
• Macromolecules (journal)
• National Postal Museum (Washington)
• Overkill (Men at Work)
• Project Reality
• The Damned United (film)
• The Last Winter (film, 2006)
• The Prisoner (Herbie Hancock)

 

Ici, c'est l'été et le matin, alors je n'ai fait que les deux premiers . J'ai pas touché à la langue dans le titre de l'infobox, ça crée un apostrophe supplémentaire ? --'toff ^[discut.] 29 décembre 2011 à 20:30 (CET)

hop qquns de traités. Udufruduhu (d)

hop², sur les JV. Jean-Fred (d) 29 décembre 2011 à 22:58 (CET)

Vous tenez le bon bout, ne lâchez pas le morceau . --Lgd (d) 31 décembre 2011 à 12:12 (CET)

Et voilà... Merci à Udufruduhu, Jean-Frédéric, Supertoff, A2, Od1n et TaraO . La liste est épuisée, il reste à surveiller ça pour les inévitables erreurs qui vont se poursuivre (j'hésite à proposer un filtre). --Lgd (d) 10 janvier 2012 à 08:20 (CET)

Juste au passage une petite remarque qui fait suite à certaines modifs de TaraO (voir sa pdd), attention, ce n'est pas parce que le titre d'un article est en langue étrangère qu'il faut mettre en forme le titre en italique. Dans bien des cas (exemple : groupes de musique) il ne s'agit pas d'une œuvre ou d'une citation en langue étrangère et il n'y a pas lieu d'utiliser l'italique (comme le font d'ailleurs généralement les articles eux-mêmes). Bonne fin d'année. Xic_{[667 ]} 31 décembre 2011 à 17:08 (CET)

Une solution intelligente pour consulter les <ref> ?

Exemple de ce que cela donne

Ce n'est pas du domaine de l'accessibilité, mais je le mets ici car j'ai besoin d'avis.

Je suppose que vous êtes comme moi : quand vous consultez un article, vous rêvez d'un système permettant d'accéder immédiatement au contenu d'une référence ou d'une note, sans avoir à se balader à coup de liens internes du haut en bas de la page. Peut-être même, dans vos rêves les plus fous, aimeriez-vous pouvoir enfin lire immédiatement quel ce sgn%$$! d'ouvrage qui est mentionné en raccourci dans une ref sous la forme « JohnDoe, pp. 666 », ce qui vous oblige à recliquer pour arriver dans la section bibliographique... pour constater que vous n'avez alors aucun lien de retour vers l'endroit du texte d'où vous étiez parti.

Bref, la lecture de Wikipédia est une horreur primitive et primaire, et les <ref> et autres {{harvsp}} y sont pour beaucoup.

Peut-être y a-t-il quelque-part un gadget qui s'attaque à ce souci, je n'ai pas trouvé ?

Bref, j'ai bricolé quelque-chose pour mon usage personnel, et je me demande si cela vaut le coup de le travailler pour en faire un vrai gadget pour tout le monde, voire une fonctionnalité par défaut ?

Donc, je viens vous embêter : y a-t-il des gens pour tester Utilisateur:Lgd/TooltipRef, sachant que c'est amusant à souhait mais encore plein de trous ?

Sinon, je suis preneur d'articles avec des systèmes de ref inattendus, pour voir si ça peut se gérer...

Cordialement, --Lgd (d) 31 décembre 2011 à 12:12 (CET)

Hello, le rendu est sacrément différent chez moi (je n'ai pas e cadre). Je pensais que ça venait du fait que j'étais sous monobook mais sous Vector idem : saisie d'écran. L'idée me paraît géniale cependant, je pense que si le gadget voyait le jour je serait de ceux qui l'adopteraient illico. Totodu74 (devesar…) 31 décembre 2011 à 13:33 (CET)

J'ai oublié de préciser que pour le moment, c'était développé à l'arrache sous Firefox. Je ne réponds d'aucun rendu ailleurs, mais ça fait évidemment parti des choses à faire sérieusement si c'est intéressant d'aller plus loin. Pensez à indiquer vos navigateurs et leurs version ;-) --Lgd (d) 31 décembre 2011 à 13:46 (CET)

j'ai le même affichage que Totodu74 avec Firefox 9.0.1. Mais je pense que ce serait très intéressant d'aller un peu plus loin ! Binabik (d) 31 décembre 2011 à 13:53 (CET)

Shame on me! Quand on ne se trompe pas bêtement dans les consignes, c'est tout de suite mieux. Retournez voir Utilisateur:Lgd/TooltipRef et corrigez vos common.css personnel avec la bonne URL, désolé je suis confus, confus --Lgd (d) 31 décembre 2011 à 14:01 (CET)

Ça fonctionne bien pour moi (Mac, firefox 8.0.1, monobook). Un petit bug de fonctionnement tout de même . Après avoir cliqué une première fois sur une ref, si je clique à nouveau dessus, j'ai une seconde croix de fermeture de la fenêtre popup qui apparaît. L'idéal serait de pouvoir fermer la fenêtre en cliquant sur la croix ou en cliquant à nouveau sur la ref. Est-ce possible ? Udufruduhu (d) 31 décembre 2011 à 14:14 (CET)

Excellente idée, et à laquelle j'avais déjà pensé Faudra que je me penche sur le sujet, disons après les festivités hydratées du réveillon. od†n ↗^blah 31 décembre 2011 à 14:18 (CET)

Je suis déjà fan, je crois. Totodu74 (devesar…) 31 décembre 2011 à 14:23 (CET)

@Udufruduhu : oui, c'est criant et c'est dans la todo, entrée « neutraliser les liens d'appels une fois la note ou la subnote ouverte ».

@Od1n: si pour une fois quelqu'un de moins bille que moi en js pouvait prendre la main, ce serait, mais ce serait... . Ça te dit ? --Lgd (d) 31 décembre 2011 à 14:27 (CET)

C'est génial ! Par contre sur Chrome (version 16.0.912.63 m) ya pas le cadre (comme Toto) et pas le "aller à la biblio". de plus il crée un retour à la ligne (et donc le point vient à la ligne) mais le point ne se remet pas à sa place quand on faire disparaitre la ref.

Ce qui serait encore plus sympa : que ça marche quand tu édites une section ... --TaraO (d) 31 décembre 2011 à 15:05 (CET)

Ça fonctionne très bien chez moi sous Chrome... peut-être un problème de cache ? Binabik (d) 31 décembre 2011 à 15:06 (CET)

@TaraO : pour les refs en mode édition, il y a un super script développé par Arkanosis (d · c), voir Utilisateur:Arkanosis/iRef.js. Udufruduhu (d) 31 décembre 2011 à 15:16 (CET)

(je suis un boulet) : tu installes ça comment ? (sinon je sais pas pour vous mais perso je trouve que cet article est quand même bien écrit) -->[] --TaraO (d) 31 décembre 2011 à 15:18 (CET)

Udufruduhu (d) 31 décembre 2011 à 15:26 (CET)

Il est beau comme tout, cet article Surtout depuis la correction de la fameuse note 17 qui cassait le truc . -->[[]] --Lgd (d) 31 décembre 2011 à 15:52 (CET)

J'ai remarqué deux cas un peu particulier à gérer : d'abord quand il y a des op. cit. et autres ibid (parfois, on ne se souvient pas de tout) ; et secundo, essayez les notes T 7, T 8 et T 9 ici (pas très informatif...). Dans les deux cas, peut-être qu'un petit lien menant à la référence en bas permettrait d'améliorer la chose. Binabik (d) 31 décembre 2011 à 15:06 (CET)

Oui, bien vu. Il faut dans tous les cas un petit lien permettant d'aller quand-même à la note en fin de page si besoin. C'est une sécurité pour les cas imprévisibles ou non gérables. --Lgd (d) 31 décembre 2011 à 15:56 (CET)

Bon, c'est à voir côté libellé et mise en forme, mais un lien « Aller à cette référence en fin de page » est maintenant présent (actualisez le cache de votre navigateur). --Lgd (d) 31 décembre 2011 à 16:15 (CET)

C'est génial .

Deux petites remarques :

• J'ai retiré le « http: » dans la doc, afin de permettre l'utilisation du gadget à la fois en HTTP et en HTTPS.
• Tu as très bien fait d'utiliser un système avec clic pour l'ouverture et clic pour la fermeture (la navigation par mouseover, saypabien), mais le flemmard à l'aise avec la souris que je suis apprécierait une option non activée par défaut pour fonctionner en mouseover.

En tout cas bravo, c'est quelque chose qui plaira sans aucun doute à beaucoup ! — Arkanosis ^✉ 31 décembre 2011 à 16:29 (CET)

Chez moi les popups ne veulent plus se fermer maintenant que ce soit en cliquant sur la croix ou sur le numéro de la ref. Udufruduhu (d) 31 décembre 2011 à 16:35 (CET) (mode boulet) en fait ça fonctionne, j'ai oublié d'actualiser le cache. Udufruduhu (d) 31 décembre 2011 à 16:47 (CET)

Mise à jour : le bidule sait à présent :

• n'ouvrir qu'une ref à la fois
• fermer la ref ouverte si on reclique sur le lien d'appel
• fermer la ref si on choisit d'aller à la section références ou à la bibliographie

--Lgd (d) 1 janvier 2012 à 10:19 (CET)

je viens de forcer mon cache à se purge (de tout l'alcool qu'il a bu hier soir). Je n'ai toujours pas le cadre en popup et j'ai toujours le problème du point qui ne revient pas à sa place. En texte j'ai "Aller". --TaraO (d) 1 janvier 2012 à 10:54 (CET)

Dans Utilisateur:TaraO/common.css, les règles @import doivent être au tout début, avant toute autre règle de style. --Lgd (d) 1 janvier 2012 à 10:58 (CET)

merci beaucoup, cela fonctionne désormais. --TaraO (d) 1 janvier 2012 à 11:06 (CET)

Ça a l’air de fonctionner très bien chez moi aussi, merci pour ce script très utile.
Ltrl G, le 1 janvier 2012 à 11:42 (CET)

Quel beau cadeau de Noël pour bien commencer l'année ! C'est tout simplement génial Lgd ! Merci et bonne année 2012 à tous ! --Amicalement, Salix ( converser) 1 janvier 2012 à 13:47 (CET)

Bon. J'ai un peu perdu la main ces derniers temps, mais disons que dès que j'ai retrouvé comment faire un gadget et que j'en ai le temps, je pousse tout ça dans un gadget activable dans les préférences. L'étape suivante (où j'espère des bonnes volontés compétentes) sera d'optimiser le script et sa CSS. Après, le proposer via une PDD comme mode de consultation par défaut des notes & références ne serait pas idiot... --Lgd (d) 2 janvier 2012 à 11:58 (CET)

Hum, je reviens du réveillon et constate que le script a bien évolué entretemps Deux petites observations :

1. Je pense que tu le sais déjà, mais le popup est dans un <li> (vu que c'est l'élément cloné), ce qui n'est guère correct sémantiquement
2. La petite flèche avant le « Aller » me fait irrésistiblement penser qu'il s'agit d'un élément déroulable, il faudrait une image moins connotée

Aussi, pour une bille en JS selon tes dires, on peut dire que tu te débrouilles vraiment bien ! od†n ↗^blah 2 janvier 2012 à 15:38 (CET)

1. Oui, j'assume totalement le crime sémantique, sans le moindre remords, et avec diverses raisons.
2. Là, par-compte, non, argh : dans quel navigateur quel OS etc. As-tu une petite flèche devant le lien « Aller », ce qui n'est pas normal du tout ? J'ai dû louper un truc évident qq-part, ou bien ?

Pour le js, c'est à optimiser, c'est lourd, là (les variables, une éventuelle fonction de création de liens, sortir les libellés en paramètres, éventuellement voir du côté de widget jquery, tout ça). --Lgd (d) 2 janvier 2012 à 15:45 (CET)

Une petite remarque, au passage : ça pourrait être intéressant de pouvoir fermer avec [Échap], je pense.
Ltrl G, le 2 janvier 2012 à 15:53 (CET)

Bien vu, noté. Merci . --Lgd (d) 2 janvier 2012 à 16:19 (CET)

En prenant l'exemple de la fameuse référence 17 de Dubbie Bowie, j'ai une petite flèche de déroulage pour le lien de l'entrée bibliographique, qui fonctionne sans problème (et même : à merveille). Le truc qui me gêne, c'est qu'il y a une flèche de même style (l'image de l'entrée .note a[href^="#"] du CSS), devant le lien « Aller », qui est un lien classique et non un élément déroulant. Tu ne rencontres pas cela ? J'ai testé ton code sous Firefox avec une console JS, et en important le CSS avec un importStylesheet(). od†n ↗^blah 2 janvier 2012 à 16:02 (CET)

Hum... Quelqu'un qui utilise le script comme indiqué dans Utilisateur:Lgd/TooltipRef a ça aussi, dans la salle ? Comparez avec la capture d'écran ci-dessus où on voit le lien « Aller » sans flèche, ce qui est le rendu attendu ?

Il manque peut-être un !important dans la CSS, l'histoire des liens avec et sans flèches est un peu trop habilement gérée... --Lgd (d) 2 janvier 2012 à 16:17 (CET)

C'est parfait chez moi. Et même un plaisir à utiliser ! --Amicalement, Salix ( converser) 2 janvier 2012 à 16:21 (CET)

J'avais oublié cette capture d'écran en haut de la discussion. Je précise donc aussi que quand je teste ton script de la façon que j'ai indiquée, le lien « Aller » se trouve en haut à gauche, c'est-à-dire aligné avec le contenu de la référence et à gauche de celle-ci, comme un float. Probablement une histoire de priorité CSS. J'essaierai de voir s'il y a des choses à améliorer (ie. fiabiliser) sur ce point. C'est ma faute aussi, je n'avais qu'à utiliser le script comme indiqué sur la notice od†n ↗^blah 2 janvier 2012 à 16:34 (CET)

RTFM et épargne-moi des émotions --Lgd (d) 2 janvier 2012 à 16:40 (CET)

Bon, trouvé, c'était juste qu'il me chargeait une version ancienne du CSS… Comme quoi, faut faire attention avec le importStylesheet() od†n ↗^blah 2 janvier 2012 à 16:49 (CET)

Après avoir testé toutes les configurations que tu as mises dans ta sous-page, il y en a deux qui ne fonctionnent pas bien chez moi ((Mac, firefox 9.0.1, monobook) : la note dans le titre de section et celle dans l'image de la galerie. La popup est comme contrainte de ne pas dépasser la ligne de soulignement de la section ou la limite du cadre de l'image. Du coup une grande partie du cadre de la popup est invisible. M'est avis qu'il faudrait également tester une note dans une image en thumb. Udufruduhu (d) 2 janvier 2012 à 17:21 (CET)

Correction faite pour les titres de sections, les images de galerie et les thumbs, en espérant qu'elle n'aura pas d'effets de bords sur l'affichage de ces éléments dans certains cas. Merci, --Lgd (d) 3 janvier 2012 à 04:53 (CET)

J'ai également bougé le script pour qu'il fasse automatiquement appel à Utilisateur:Arkanosis/iRef.js afin de fonctionner aussi lors de la prévisualisation (dans une certaine mesure au moins). Merci à Arkanosis . --Lgd (d) 3 janvier 2012 à 07:33 (CET)

En m'inspirant de la « Note 2 » de Grand cachalot#Populations et conservation (une ref imbriquée dans une note), j'ai réussi à bricoler une situation un peu moins bien gérée que la normale : une ref avec renvoi (de type harv) imbriquée dans une note. En effet que se passe-t-il

Bibliographie

• Legrosvicieux, Un titre, 2011

Notes

Références

Petits décalages de fonctions par rapport aux entités qu'elles concernent : Si je clique sur Legrosvicieux qui s'affiche dans la subnote, il me renvoie à la biblio alors que, théoriquement, il devrait y avoir une flèche et il devrait m'afficher l'entrée de la biblio (« Legrosvicieux, Un titre, 2011 ») dans la subnote ; en revanche si je clique sur « Aller à la bibliographie », il me renvoie à la référence (ça le fait aussi pour la ref 'in situ sur grand cachalot). Je pense que cette situation ne doit pas être extrêmement répandue () et que la gestion est quand même grandement satisfaisante, déjà comme ça. C'était juste pour dire de... ? Totodu74 (devesar…) 3 janvier 2012 à 09:34 (CET)

Les notes dans les notes sont un truc à ne pas encourager dans les articles (d'ailleurs, il me semble que le Projet:Correction syntaxique détecte l'usage de {{#tag:ref|...}} dans un article comme une erreur à corriger). On pourrait facilement modifier le gadget pour qu'il donne le résultat attendu dans ce cas là, mais j'hésite. Des avis ? --Lgd (d) 3 janvier 2012 à 09:46 (CET)

Personnellement ce type de jeu de piste m'agace plutôt. Beaucoup de complications pour économiser quelques lignes de texte... Après tout, s'il y a des doutes, autant les exposer clairement. --Amicalement, Salix ( converser) 3 janvier 2012 à 09:57 (CET)

Dans ma réécriture de iRef, iRefMark n'est plus en variable globale, tu devrais donc plutôt tester si la function iRef est définie. Autre point à regarder : et si iRef est chargé après ton script ? od†n ↗^blah 3 janvier 2012 à 17:36 (CET)

Modification faite pour tester la fonction plutôt que la variable. --Lgd (d) 3 janvier 2012 à 18:30 (CET)

Sinon, je viens de retester en cas de chargement après le script, et je n'ai pas d'erreur, tout comme ce matin. Bon, ça n'est pas tout à fait rassurant, certes. Une idée ? --Lgd (d) 3 janvier 2012 à 18:56 (CET)

Attention, je n'ai pas dit qu'il y avait forcément un problème, juste qu'il faudra regarder, car cela me semble possible Je pense évidemment à une double exécution de iRef. Tu devrais déjà englober ton script dans une function, qui éventuellement permettra à d'autres scripts de simplement tester son existence, et aussi de ne pas polluer l'espace JS global od†n ↗^blah 3 janvier 2012 à 19:03 (CET)

Depuis entre une heure ou deux, mon js ne se charge pas (j'ai le navigateur qui mouline en boucle et la page semble constamment en train de se charger). Le problème disparaît, ou du moins je crois en avoir l'impression, quand je supprime le gadget de mon js, quelqu'un aurait-y touché queuqu'chose ? Totodu74 (devesar…) 3 janvier 2012 à 21:26 (CET)

ok, ok, le chargement d'iRef ne se passait donc pas si bien que ça. J'ai supprimé l'appel à Utilisateur:Arkanosis/iRef.js pour le moment. actualiser le cache de votre navigateur et dites-moi si ça le fait. Merci , --Lgd (d) 3 janvier 2012 à 21:32 (CET)

Humpf, en fait même problème sur Commons et idem sans le gadget sur fr:, j'ai du crier au loup trop vite, c'est les serveurs qui doivent pédaler dans la semoule ? Totodu74 (devesar…) 3 janvier 2012 à 21:48 (CET)

J'étais pas passé à Utilisateur:Lgd/TooltipRef/TooltipRefMini.js... Totodu74 (devesar…) 4 janvier 2012 à 18:05 (CET)

À mon avis, il vaudrait mieux éviter ce couplage fort entre les deux gadgets, que j'imagine bien source de moult complications et problèmes. Il serait préférable de les présenter distinctement à l'utilisateur et d'inviter celui-ci à installer les deux s'il souhaite bénéficier de l'« expérience complète ».

one more thing : ma version expérimentale gère les réfs groupées, des retours sur le code seraient très appréciables (notamment les 2 regexes dans getGroups() pour détecter les groupes)

od†n ↗^blah 5 janvier 2012 à 19:33 (CET)

Oui, j'avais mis en place entre-temps les deux version (avec et sans iRef) dans Utilisateur:Lgd/TooltipRef. J'attends d'autres avis externes, mais je te rejoins de plus en plus dans l'idée d'éviter le couplage.

Je n'ai pas eu le temps de tester aujourd'hui le nouveau Utilisateur:Od1n/iRef.js mais je te fais ça ce WE . Là, je fais joujou avec un autre camarade de jeu et un truc beaucoup plus diabolique --Lgd (d) 5 janvier 2012 à 21:03 (CET)

Contre le couplage des gadgets : ne sachant pas comment fonctionne iRef j’ai eu quelques problèmes (j’ai dû contribuer sous IP pour supprimer une section iRef resté sans raison sur une page) et j’ai peut-être oublié d’en corriger certains.

[édit] Je ne suis pas le seul à avoir un problème d’utilisation

Une fois, il m’en a rajouté trois, comme ça
Ltrl G, le 5 janvier 2012 à 21:08 (CET)

Le problème est que le couplage est défectueux en son état actuel. Mais comme il est probable qu'il ne soit pas maintenu…

Concernant Salsero35 (d · c · b), il importe les mêmes scripts dans son common.js et son vector.js, donc forcément ça provoque des bugs.

od†n ↗^blah 5 janvier 2012 à 21:48 (CET)

J'avais vu ton edit avec les 3 references : désolé. Il a bcp compté dans ma bascule vers le non-couplage. Mais bon, vous avez signé plus haut pour tester quelque-chose qui était en développement, n'est-ce pas  ?

Je sais bien que c’est en développement, c’est juste une observation : cela ne doit pas arriver plus tard à quelqu’un qui n’a pas « signé » !
Ltrl G, le 5 janvier 2012 à 23:29 (CET)

Au fait, puisqu'on en parle : personne ne l'a dit jusqu'ici, ni moi le premier, mais : Ltrl mérite un grand bravo pour le boulot d'accessibilité discret mais redoutable qu'il accomplit depuis quelques mois dans un nombre considérable d'articles. Merci  ! Juste un truc : c'était pas une idée d'avoir un pseudo que je n'arrête pas de confondre avec le mien, mais bon, c'est pas grave --Lgd (d) 5 janvier 2012 à 21:53 (CET)

Merci, c’est gentil. Désolé pour le pseudo… je ne te connaissais pas à l’époque et il fallait bien que je choisisse quelque chose. Mais rassure toi, moi aussi il m’arrive de confondre.
Ltrl G, le 5 janvier 2012 à 23:29 (CET)