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

Catégorie:Modèle Cladogramme

Bonsoir, j'ai la sensation que les modèles contenus dans cette catégorie ne doivent pas être très accessibles. Voir un exemple d'utilisation sur la page Hippotragini. Est-ce une simple illusion? Si oui que dire à leur auteur? --amicalement, Salix ( converser) 16 décembre 2008 à 22:49 (CET)

Ce modèle cumule deux problèmes:

• un tableau HTML utilisé pour un effet de mise en forme et non pour structurer des données
• une information portée par des styles CSS (qui font apparaître les bordures des cellules du tableau)

L'information est donc perdue dans divers cas : pas de support des tableaux et/ou pas de support des CSS.

Le tableau n'est pas la structure appropriée ici pour refléter l'organisation des données. Pour conserver un rendu similaire (en arbre), mais avec une structure pertinente et accessible, le modèle {{Clade}} devrait utiliser des listes imbriquées, avec une mise en forme CSS adaptée : la structure de listes permet de reproduire une arborescence et garantit que l'information est toujours présente, au moins de manière brute, quelque-soit le contexte de rendu.

Si besoin, faire signe, je devrais pouvoir proposer un modèle. Cordialement, --Lgd (d) 17 décembre 2008 à 05:33 (CET)

Merci à toi . Je te tiens au courant si les biologistes approuvent la généralisation de ce type de modèle. --amicalement, Salix ( converser) 17 décembre 2008 à 10:45 (CET)

Voir par exemple http://www.amaryllidaceae.org/web-jardin/bota-web/arbre.htm. Enfin pour moi en tout cas c'est utile. =) — Delhovlyn • [discuter] – 20 décembre 2008 à 13:05 (CET)

Un peu lourd (normal, vu la date : cela faisait longtemps que j'avais pas vu un « Voice family hack », souvenirs, souvenirs...), mais très bienvenu en effet. Merci --Lgd (d) 20 décembre 2008 à 15:32 (CET)

Waaaa, c'est beau. bayo 17 février 2009 à 11:45 (CET)

Mais qu'est-ce que ça prend comme place! Le biologistes trouvent déjà celui-la bien trop encombrant! Alors là... --amicalement, Salix ( converser) 17 février 2009 à 12:02 (CET)

{{Boîte déroulante}}... Ok, je sors. Nan, je ne sors pas, c'est typiquement le cas où un contenu par ailleurs bien codé et n'alourdissant pas trop le poids réel de l'article peut trouver sa place ergonomique via une boîte déroulante. Dans la mesure essentielle où il est d'abord jugé pertinent en tant que contenu, évidemment (mais ça, c'est pas mon rayon dans ce cas précis).

Par contre, pitié, n'importez pas tel quel le code de l'exemple donné par Delhovlyn, il a besoin d'une bonne révision. --Lgd (d) 17 février 2009 à 12:09 (CET)

Vidéos

Bonjour, je ne trouve rien dans les recommendations sur l'insertion de vidéos : quelles sont les précautions à prendre en matière d'accessibilité, de formats ou de tailles de fichiers? Peut-on encourager l'emploi de vidéos comme sur Aciculata à la place d'images fixes? Personnellement il me faut 30 secondes avant de la voir bouger. --amicalement, Salix ( converser) 16 février 2009 à 18:30 (CET)

Ce n'est pas vraiment une vidéo, c'est un gif animé. Je sais pas si ça pose un problème. Chez moi par contre ça s'est mis en route rapidement. — Delhovlyn » (discuter) 17 février 2009 à 01:54 (CET)

Rapidement, en me limitant aux Gifs animés:

• L'animation gif de Aciculata est effectivement très lourde et longue à charger, puisqu'il s'agit en fait d'une image de grande taille (800 x 535 pixels animé en 7 images, pesant 1.9 Mo) redimensionnée par le navigateur au moment de l'affichage (250 x 167 pixels affichés, mais après téléchargement des 1.9 Mo évidemment). C'est à vérifier, mais soit mediawiki ne génère pas la vignette côté serveur dans le cas des gifs animés, contrairement aux images statiques, soit c'est un problème lié au code des taxobox... En tous cas, la petite ébauche Aciculata figure en bonne place parmi les articles les plus lourds de Wikipédia.
• Pour leur accessibilité, les animations doivent pouvoir être contrôlées par l'utilisateur (pause, stop, play) avec, pour simplifier, un ou deux objectifs selon le contexte :
  1. Pour qu'il ne soit pas gêné par un contenu clignotant, provoquant des effets de flash, etc. qu'il s'agisse d'une image décorative ou d'une image porteuse d'information. Cela ne concerne que les gifs animés en boucle ou dont la durée avant arrêt automatique excède 5 secondes.
  2. Pour qu'il ait le temps de consulter chaque partie de l'animation à son propre rythme, selon ses contraintes personnelles, lorsque celle-ci véhicule une information à travers son déroulement.
• Dans le cas d'un gif animé, seul le critère 1 est satisfait, sans qu'il y ait en fait de mesure particulière à prendre : la touche échap du clavier permet en effet de stopper tous les gifs animés d'une page dans la plupart des navigateurs. En revanche, cela ne permet pas de consulter un gif animé étape par étape afin de satisfaire le critère 2.

Tout dépend évidemment du rôle de l'image : décorative comme celle d'Aciculata, ou véhiculant une information essentielle comme d'autres animations (je n'ai pas d'exemple sous la main). En conclusion pour l'instant:

1. Il faudra savoir pourquoi Aciculata se retrouve avec l'image "grand format" et non avec une version légère.
2. Les gif qui gigotent pour faire joli mais sans porter d'information, ou dont l'information est donnée par ailleurs dans l'article sous forme textuelle ne posent pas de problèmes majeurs (dans la mesure où les gens sont supposés savoir qu'ils peuvent les arrêter avec échap).
3. Les gif animés qui présentent une information à travers leur déroulement, sans que celle-ci soit donnée par ailleurs sous forme textuelle posent un problème dont la solution est cependant simple : il faut, comme d'habitude, privilégier la rédaction du contenu et utiliser ces images comme illustration de ce qui est écrit, et non comme véhicule unique de l'information. Ce qui est justifié par toutes sortes d'autres raisons que l'accessibilité...

PS: je complèterai prochainement les bonnes pratiques d'accessibilité sur ce sujet notamment, à l'occasion de leur mise à jour rendue nécessaire par la publication de la version 2.0 des recommandations WCAG. --Lgd (d) 17 février 2009 à 06:01 (CET)

Merci Lgd pour ces éclaircissements. J'avoue découvrir avec toi le coup du "échap" à propos des gif animés. Effectivement ça marche, sauf que si ce n'est pas écrit juste en dessous de l'image les gens comme moi ne le devineront pas... A propos de notre Aciculata le problème vient aussi du fait qu'on ignore a priori qu'il s'agit d'une image mobile tant qu'elle n'a pas fini d'être chargée : au premier essai je n'ai donc pas compris pourquoi le téléchargement de la page était si long et pourquoi on me signalait cet article, au deuxième essai il a fallu que j'attende 30 secondes pour voir des "papattes" bouger, c'est à dire beaucoup d'efforts àmha pour une valeur ajoutée faible. Je préfère donc nettement quand il y a un bouton pour lancer une image mobile : on est averti et on sait ce qu'on risque en cliquant. A propos de gif voir par exemple celui-ci(8,63 Mio) qui a mis la pagaille sur le café des biologistes où il était proposé à commentaires. Il faudrait tout de même indiquer une valeur maxi pour éviter que ne se généralise ce problème. Et j'ai en théorie l'ADSL ! En revanche il permet sur sa page de description de voir toutes les étapes de l'animation. Voici, pour te donner des idées afin de rédiger les "bonnes pratiques". --amicalement, Salix ( converser) 17 février 2009 à 09:18 (CET)

+1 sur le principe pour préciser notamment des limites de poids et aider à les respecter, si un projet animation s'active à court terme. Mais surtout, d'après les développements en cours, il devrait être possible d'utiliser d'ici quelques mois d'autres techniques moins obstructives (Je pense en particulier à la conversion automatisée en ogg). En fait, idéalement, il faudrait attendre encore un petit peu que ça mûrisse en suivant ce qui se prépare (ce que je vais tâcher de faire). --Lgd (d) 17 février 2009 à 12:18 (CET)

Peut-être peux-tu te mettre en rapport avec le Projet:SVA pour leur expliquer quelques trucs avant que leur enthousiasme ne déborde dans de mauvaises directions? --amicalement, Salix ( converser) 17 février 2009 à 12:40 (CET)

Hum... Disons que j'ai déjà laissé un assez mauvais souvenir à l'initiateur de ce projet, à mon grand regret. Je verrais si ce projet se bouge ou pas finalement (je crois plus à un plouf dans l'eau, pour tout dire). --Lgd (d) 17 février 2009 à 12:43 (CET)

Nous enterre pas de sitôt ! Normalement on ne fait pas de gif à partir de plusieurs photos, justement parce qu'ils sont habituellement de dimensions assez petites. Je vais aller voir si je peux pas vous l'alléger et je vais ajouter un truc à ce sujet dans le projet. Azariel (d) 17 février 2009 à 16:00 (CET)

Voilà, elle fait 165 Ko maintenant, et la qualité sur l'article ne sera pas perdue, par contre comment je fait pour l'importer et la mettre à la place de l'autre ? Azariel (d) 17 février 2009 à 16:32 (CET)

C'est intéressant et c'est a priori une bonne démarche potentielle sur le côté technique, mais avant de t'occuper du comment, je suggère que tu sois un peu plus sensible au pourquoi, c'est à dire à la question de la pertinence de cette animation. C'est tellement mieux dit par Salix ci-dessus que je la répète: « ...pour voir des "papattes" bouger, c'est à dire beaucoup d'efforts àmha pour une valeur ajoutée faible.  ». Le projet que tu souhaites animer n'a aucun intérêt tant qu'il ne commence pas par se poser la question du contenu. Animer plus, oui, mais à condition qu'il y ait d'abord quelque-chose de pertinent à animer. C'est la première question par laquelle devrait commencer ce projet. IL sera d'autant plus crédible, utile et efficace qu'il ciblera précisément son champ de contenu. C'est là où je crains avec regret que ce ne soit pour l'instant qu'un plouf dans l'eau, ce que me confirme hélas ta réponse ici. Mais si ça change, ça peut devenir très intéressant.

Maintenant, après cette brève digression, je suggère de poursuivre éventuellement sur la page de digression du projet concerné. Pas ici où c'est hors sujet (je sais, c'est moi qui ai commencé, mais bon). --Lgd (d) 17 février 2009 à 17:15 (CET)

Pour clore le sujet je dirais que les animations, comme les sons, peuvent être un vrai plus sur un article à condition de répondre à un besoin réel, en soutien au texte. L'animation des pattes de notre bestiole est intéressantes dans une section sur la locomotion et si on peut en maîtriser l'avancement des images et l'assortir d'une description de ce qui se passe pour ceux qui n'y ont pas accès (bas débit, lecteur d'écran, texte brut, version imprimée...). L'animation dans l'image d'en-tête d'une Taxobox qui doit pouvoir être vue, interprétée ou imprimée immédiatement par tous, c'est du superflu qui peut se révéler encombrant, pire que le Modèle:Images qui pose pourtant déjà des problèmes. Le projet SVA devrait pouvoir en prendre conscience.--amicalement, Salix ( converser) 17 février 2009 à 22:39 (CET)

Chantier taxobox / infobox

Plop,
Suite à certaines discussions, je lance une page de méthode sur ces contenus: Wikipédia:Atelier accessibilité/Taxobox et infobox. Premier jet en cours. Commentez, questionnez, proposez... --Lgd (d) 20 février 2009 à 10:29 (CET)

Hello. C'est quoi cette histoire de « les images ne bénéficient pas du mécanisme des thumb ». Je ne comprend pas bien pourquoi ? Certaines boites qui importe des images avec du JavaScript (et du coup qui pourrait être réglé) ? bayo 20 février 2009 à 12:05 (CET)

En passant http://fr.m.wikipedia.org peut peut-être aider à faire prendre conscience de certains problèmes. J'ai par exemple vu des cartes de géolocalisation avec des descriptions incomplètes (je ne retrouve malheureusement ni la page, ni le modèle). bayo 20 février 2009 à 12:17 (CET)

Super idée Bayo! ça donne déjà une idée des problèmes, de géolocalisation Paris ou d'images composées Crawley Town Football Club. --amicalement, Salix ( converser) 20 février 2009 à 12:22 (CET)

Pourquoi ne pas mettre un exemple de ce que tu appelles la version simple avec le div ? Amicalement — Steƒ ^{๏̯͡๏﴿} 20 février 2009 à 12:51 (CET)

Woow, magnifique « Crawley Town Football » Club :D bayo 21 février 2009 à 11:49 (CET)

Pour les thumbs: c'est amusant que l'image dans une infobox soit la seule à être dimensionnée arbitrairement, à ne pas avoir la structure de légende que doit avoir n'importe quelle autre image placée dans un article, etc. Surtout que c'est facile à régler, le recours aux thumbs pour l'illustration placée en tête d'une infobox.

Oui, http://fr.m.wikipedia.org est un bon révélateur des difficultés de réutilisation de contenus mal codés, notamment coté javascript.

pour l'exemple, il arrive, il arrive... --Lgd (d) 20 février 2009 à 13:07 (CET)

— Steƒ ^{๏̯͡๏﴿} 20 février 2009 à 13:16 (CET)

Ah oui, c'est vrai en effet, on fixe généralement une taille ; car il n'existe pas de moyen technique pour avoir une taille « préférence utilisateur » sans utiliser le thumb. On n'utilise pas le thumb à cause des cadres stylisés qu'il ajoute, mais c'est vrai qu'on pourrait le faire sauter par un contre style du genre nothumb dans une balise parente. Perso plus on utilise la syntaxe classique de wiki, mieux je me porte. Un exemple est le bienvenu :D bayo 21 février 2009 à 11:49 (CET) (qui n'en remet pas une couche)

Tant que j'y pense, peux-tu, Lgd, regarder les séparateurs horizontaux. J'aimerais un avis sur http://fr.m.wikipedia.org/wiki/Vroom, et les balises hr. Il me semble que tu avais déjà regardé ce cas, mais je ne sais plus ou. Ca doit revenir assez souvent dans différents infoboxs. J'ai essayer d'utiliser des tbody sans y parvenir (MediaWiki les filtre) car se serait amha le plus pratique. C'est juste pour savoir si ça pose un problème, c'est en tout cas un peu le cas dans la version mobile. bayo 21 février 2009 à 12:04 (CET)

Proposition d'un comité de lecture

Bonjour à tous ! Je souhaiterai vous soumettre une idée : sur la page des règles et procédures pour soumettre un article au label AdQ, il est proposé un lien vers le comité de lecture et un vers l'atelier typographique. Quand j'ai lancé ma première procédure en AdQ, je suis effectivement allé déposer un avis sur ces deux ateliers qui m'ont permis quelques corrections et conseils pertinents. Je n'ai pas eu l'idée à l'époque de venir voir ici. Je pense qu'il serait bien que l'accessibilité aie son propre comité de lecture qui pourrait se charger d'aider les proposants aux AdQ qui le souhaitent. Qu'on le déplore ou non, les AdQ sont de formidables vitrines, et il serait intéressant, en s'infiltrant dans les débats (çà fait un peu lobby ce que je dis là, non ? ), de faire prendre conscience à un plus grand nombre de gens cette problématique. Les AdQ étant souvent pris en exemple sur la forme pour créer de nouveaux articles, cela aurait peut-être un effet boule de neige ! Que pensez-vous de créer une sous-page dédiée à des volontaires prêts à relever le challenge et d'insérer un nouveau lien vers cette sous page dans la section règles et procédures des AdQ ? — Droop ^[blabla] 21 février 2009 à 14:22 (CET)

Tout à fait dispo pour ma part. Pour tout dire, c'est une chose que j'avais déjà proposé il y a quelques mois sans susciter un grand intérêt (J'en profite pour m'incline respectueusement une fois de plus devant Salix et son heureuse initiative sur Discuter:Royan/Article de qualité). Je serais en revanche très prudent sur le caractère éventuellement « contraignant » pour l'obtention d'un label AdQ : tout ce qui est théoriquement à faire en matière d'accessibilité n'est pas forcément aisé, il faut y aller doucement. La démarche du comité de lecture me semble tout à fait appropriée. --Lgd (d) 21 février 2009 à 14:36 (CET)

Oui je pense aussi qu'il ne faut rien imposer, mais seulement proposer une aide et informer.— Droop ^[blabla] 21 février 2009 à 16:22 (CET)

Proposition d'un nouveau message prédéfini

J'ai plein d'idées, j'en profite ! Ne pensez-vous pas que l'on pourrait demander l'ajout d'un message prédéfini intitulé accessibilité du même type que orthographe, typographie, catégorisation, etc. qui existent au-dessus de la boîte de résumé de publication ? — Droop ^[blabla] 21 février 2009 à 16:25 (CET)

Eventuellement. Mais la liste des message prédéfinis me semble déjà bien encombrée (si besoin, pour la demande, c'est MediaWiki:Gadget-ResumeDeluxe.js qui devra être modifié. Si la demande est faite et qu'elle ne rencontre pas d'hostilité, je me chargerai de l'intendance). --Lgd (d) 21 février 2009 à 17:41 (CET)

Tiens, je rebondis. Une extension FF de test d'accessibilité pour wikipédia serait sans doute pertinente (d'autant qu'elle pourrait aisément aller bien au-delà de l'accessibilité). D'habitude, on utilise plutôt des outils génériques, mais ici, un outil métier me semble profitable. Hum... (pour la petite histoire, il y a un Gadget accessibilité, ou plutôt une amorce de gadget restée un peu en friche, aussi)--Lgd (d) 21 février 2009 à 22:03 (CET)

Pour compléter Lgd sur son dernier point : MediaWiki:Gadget-Accessibility.css et MediaWiki:Gadget-Accessibility.js. bayo 23 février 2009 à 16:04 (CET)

Concours pour sauver un modèle

ça se passe dans Discussion Modèle:Localisation ville. --Lgd (d) 21 février 2009 à 22:25 (CET)

infobox hyper proteinée

Bonjour, une nouvelle infobox (encore!) est en préparation : Utilisateur:Wikialine/essais6 est-elle sufisemment accessible ? --amicalement, Salix ( converser) 2 mars 2009 à 14:52 (CET)

Même problème que pour toutes les infobox V2 ou non actuelles: confusion d'un tableau de données / de présentation là où il faudrait un début sans tableau HTML pour la partie titre et image, et des tableaux de données successifs ensuite. L'absence potentielle de cartes de géolocalisation, de diptyques de navigation, de blasons, de sous-tableaux à 3 ou 4 colonnes etc. est encourageante, tout de même. Oups, oubli : les efforts pour faire passer la syntaxe des tableaux de données ont tout de même partiellement porté leurs fruits, par les vertus du copié collé à partir d'infobox et de tableaux corrigés un peu partout: le modèle comporte des scope --Lgd (d) 2 mars 2009 à 17:40 (CET)

Et tu as sans doute vu une version ultérieure à celle-ci. --amicalement, Salix ( converser) 2 mars 2009 à 20:27 (CET)

Argh. --Lgd (d) 2 mars 2009 à 20:29 (CET)

Pour info, mise à jour des bonnes pratique en vue

Les bonnes pratiques seront dès que possible (d'ici un ou deux mois maximum, disons) mises à jour pour tenir compte de l'évolution des normes d'accessibilité WCAG, de leur version 1.0 à la version 2.0 (publiée en décembre dernier). Les ajustements à prévoir sont peu nombreux, et vont plutôt dans le sens de la simplification, la version actuelle des bonnes pratiques a déjà en partie anticipé ce changement des normes. --Lgd (d) 6 mars 2009 à 06:54 (CET)

La prise de conscience est en marche !

Bonjour, des modifications comme celle-ci (ajout du modèle {{lang}}) ou celle-là (substitution par une carte accessible et texte alt) me font penser que nos efforts ne sont pas vains et que la prise de conscience des exigences d'accessibilité est en bonne voie  ! --amicalement, Salix ( converser) 11 mars 2009 à 14:36 (CET)

À l'occasion je m'inscrirai au projet. Au départ j'étais complètement à coté de la plaque, mais je commence à comprendre l'accessibilité. Dites, vous auriez pas un lecteur d'écran gratuit à me conseiller, pour que je fasse des tests ? J'ai bien trouvé "Narrator" livré avec Windows, mais il est horrible, et j'ai même pas réussi à le configurer en français, il est en anglais par défaut. :(

Sinon, je vous invite à prendre part à cette réflexion du Bistro sur les homonymies : Homonymie, aide pas intuitive. Comment est lu le point d'interrogation qui lie vers la page d'aide, dans la présentation suivante ?

Pour l’article homonyme^?, voir Mercure.  

Merci de votre aide. Amicalement, Dodoïste ^{[ dring-dring ]} 11 mars 2009 à 15:08 (CET)

Très bonne remarque en effet. --amicalement, Salix ( converser) 11 mars 2009 à 16:07 (CET)

re- Le projet Charente-Maritime a d'ailleurs décidé de généraliser petit à petit ce genre de carte accessible sur l'ensemble des 472 communes en remplacement de l'ancien modèle de géoloc. C'est quand même un peu, beaucoup, grâce à toi Salix ! — Droop ^[blabla] 11 mars 2009 à 17:31 (CET)

Oh, sur tout de Lgd qui nous a mis le pied à l'étrier. --amicalement, Salix ( converser) 11 mars 2009 à 17:41 (CET)

Les modifications sur ces modèles d'homonymie vont dans le bon sens en matière d'ergonomie : le point d'interrogation n'est en effet pas des plus heureux à cet égard, même s'il ne pose en fait aucun problème d'accessibilité, le title du lien automatiquement généré par mediawiki sur ? étant explicite (« Aide:Homonymie »). Voir les bonnes pratiques sur les liens.

J'ai vu passer ton excellente initiative sur cette carte de géolocalisation, bravo !

Plus généralement, il y a diverses raisons de se réjouir à propos d'accessibilité : je vois par exemple des contributeurs utiliser spontanément, souvent par la simple vertu du copier-coller, des syntaxes de tableaux de données accessibles. De même, l'utilisation systématique du modèle {{lang}} entre dans les moeurs. Egalement, une grande partie de ce qui était corrigeable en matière d'accessibilité clavier ou d'alternative javascript l'a été dans MediaWiki:Common.js (D'ailleurs, la discussion sur le Bistro d'hier à propos de la géolocalisation dans le titre me remet en mémoire qu'il reste une fonction moveCoord() à corriger comme l'avait été IconesDeTitre(), pour que les coordonnées et l'icône de l'Atlas ne soient pas injectées dans l'élément de titre qui devient alors incompréhensible sans support CSS, dans un lecteur d'écran, etc. Zou, réglé, ça) ...

en revanche, il faut revoir l'organisation de cet atelier, dont les sous-pages sont beaucoup trop peu pédagogiques (je plaide coupable). Une page d'accueil plus proche de celles des projets serait sans doute habile, pour donner une vue d'ensemble plus claire, un accès immédiat à une section « Comment contribuer (facilement) ? », etc. --Lgd (d) 12 mars 2009 à 05:26 (CET)

Accessibilité d'un tableau de communes

Bonjour, j'ai créé en grande partie le tableau des communes de la Charente-Maritime et comme une multitude de syntaxes existent et que je n'y connais pas -encore- grand chose en matière d'accessibilité, j'aurai voulu connaître votre avis de spécialiste quant à l'accessibilité de la version actuelle de ce tableau (sachant qu'il y a eu par exemple un changement de syntaxe dans l'historique). Merci d'avance pour vos conseils. — Droop ^[blabla] 11 mars 2009 à 17:38 (CET)

• Bien: les en-têtes des colonnes sont correctement balisées avec le ! scope=col qui permet de les identifier comme telles. Le tableau en tant que tel ne pose donc pas de problème.
• Pas bien: l'utilisation du modèle {{smn}} est pour l'instant difficilement évitable, mais problématique. En effet, le contenu réel généré par {{smn|5.36|4|100}} n'est pas « 5,36 » mais « 0536 !5,36 », ce qui sera peu ou pas compréhensible pour les utilisateurs qui y auront accès sans que le « 0536 ! » soit masqué (styles CSS désactivés, non supportés ou non pris en compte). La solution sur ce point passe par une refonte complète des fonctions de tri dans wikibits.js, de manière à déplacer le contenu nécessaire au tri dans un attribut HTML non affiché, du type id ou class et à modifier le tri en conséquence. Cela relève de bugzilla et du développement de mediawiki, et non de ce que nous pouvons faire localement. Et, dans l'immédiat, un tel tableau perdrait une grande partie de son intérêt s'il n'était pas triable... --Lgd (d) 12 mars 2009 à 05:15 (CET)

{{Article détaillé}}, {{Article connexe}}, etc.

Une grande partie des modèles de la Catégorie:Modèle renvoi d'article génèrent actuellement une icône cliquable qui est hélas un lien vers la page de l'image, sans intérêt pour le lecteur et problématique pour l'accessibilité :

Article détaillé : Foo.

Contrairement aux icônes des bandeaux d'homonymie, il n'est pas possible de les transformer en lien vers une page d'aide. Ces icônes uniquement décoratives devraient en fait être traitée en tant qu'images d'arrière-plan CSS (non cliquable, pas d'alternative textuelle à gérer). J'ai préparé à cet effet les styles CSS pour MediaWiki:Common.css et les modèles corrigés dans Utilisateur:Lgd_test#Voir_aussi_etc (Attention, vous ne pouvez pas voir le résultat des modèles corrigés sans récupérer les styles nécessaires qui sont dans le monobouc personnel de ce compte).

Mais cette modification est délicate à gérer:

• je suppose que quelques contributeurs mettront sur le tapis le (faux AMHA) problème de l'accès à la page des images qui serait nécessaire pour consulter la liste de leurs auteurs, leur licence, etc.
• concrètement, le changement à effectuer d'abord dans les modèles, puis dans MediaWiki:Common.css, provoquera une légère perturbation de l'affichage dans les articles, le temps qu'il se propage dans le cache de mediawiki (pendant quelques heures, les icônes disparaîtront). Cela peut être évité en changeant le nom des classes CSS utilisées, mais les noms actuels sont pertinents et je préfèrerais donc l'éviter.

Avis, initiatives diplomatiques, participation à cette éventuelle modification etc. sont donc les bienvenus, d'autant que je n'aurais que peu de temps à y consacrer, et que je ne pourrais donc mener cela à bien seul --Lgd (d) 12 mars 2009 à 05:41 (CET)

Le mieux n'est-il pas d'en parler sur le bistrot peut-être ? Plus casse-gueule : un sondage ? Tu as mon entier soutien en tout cas.— Droop ^[blabla] 12 mars 2009 à 07:30 (CET)

Juste un détail : vers quelle page d'aide voudrais-tu que cela renvoie? Personne n'a l'idée de cliquer sur l'icône... --amicalement, Salix ( converser) 12 mars 2009 à 09:21 (CET)

Je disais justement qu'on ne pouvait pas les transformer en lien vers des pages d'aide --Lgd (d) 12 mars 2009 à 09:36 (CET)

Et je sous-entendais que cela n'a àmha pas d'importance en l'occurence . --amicalement, Salix ( converser) 12 mars 2009 à 18:06 (CET)

Bwa... Pourquoi on perd du temps, alors ? --Lgd (d) 12 mars 2009 à 19:39 (CET)

Je suis pour.

Toutefois, avant de faire cela, il serait bon de se demander si l'image est nécessaire. Est-ce que l'information portée est vraiment indispensable ? Sur la wiki anglaise, le rendu est bien plus simple :
Article détaillé : Foo

En gros, ne pourrais-t'on pas faire d'une pierre deux coups ? Rendre le modèle accessible et le simplifier en même temps ? Amicalement, Dodoïste ^{[ dring-dring ]} 12 mars 2009 à 19:10 (CET)

c'est exclu, à condition de refaire un vote . --amicalement, Salix ( converser) 12 mars 2009 à 19:16 (CET)

Mouif... (ça veut dire non, quand je dis mouif, mais en version pas abrupte):

1. ça va hurler pour un gain potentiel maigre pour ne pas dire nul par rapport au passage en icône CSS.
2. l'icône est pour le coup (c'est rare que je dise ce genre de chose ici) pertinente : elle signale bien un lien d'une nature très spécifique, lien de type asez récurrent à travers les articles pour que sa signalétique soit utile, et suffisamment spécifique pour que cela soit justifié en termes ergonomiques : elle aide à comprendre la structure de l'article et d'une série d'articles. Pour une fois, cette icône, c'est ce qu'on ferait n'importe où ailleurs.

en fait, ce qui vous brouille peut-être l'utilité de cette icône, ce sont les autres, les mauvaises qui polluent et diluent le sens (les p'tits drapeaux, tout ça . Mais celle-là correspond réellement à quelque-chose d'important en terme de navigation et de perception de l'architecture des contenus (article principal / article détaillé, c'est assez « essentiel » pour nécessiter une icône). --Lgd (d) 12 mars 2009 à 19:17 (CET)

Je suis convaincu par ton argumentation, et j'ai appris quelque chose de bien utile. Merci. ^_^ Dodoïste ^{[ dring-dring ]} 12 mars 2009 à 20:27 (CET)

Bon on irait vers un sondage comme tu en as le secret sur le Bistro, alors ? --Lgd (d) 12 mars 2009 à 20:32 (CET)

^_^ Me voilà flatté. Volontiers, mais avant cela, il y a un problème avec la classe choisie (class="detail plainlinks section navigation-only", qui est aussi utilisée par le modèle:... : l'image définie dans le css remplace l'originale. Amicalement, Dodoïste ^{[ dring-dring ]} 12 mars 2009 à 21:40 (CET)

Bien vu, en effet. J'ai complété les styles afin de prendre en charge ce modèle {{...}} qui pourra être corrigé dans le même lot. Pas d'autres cas à votre connaissance ?

En cas de doute, il est en effet possible d'utiliser une autre classe, afin d'éviter tout risque (je trouvais .detail très pertinent, mais ce n'est pas si gênant, après tout). --Lgd (d) 13 mars 2009 à 07:05 (CET)

Ok. Euh je veux bien participer au débat (ou sondage) sur le bistro, mais je n'ai pas compris en quoi ça pose problème pour l'accessibilité, l'image cliquable. Donc je serais bien en peine de l'expliquer sur le Bistro. Amicalement, Dodoïste ^{[ dring-dring ]} 14 mars 2009 à 14:50 (CET)

J'interviens un peu tard dans cette discussion, mais ce lien vers la page de l'image loupe peut être désagréable pour tous les contributeurs, ceux qui sont atteint d'un trouble convulsif de cliquage sur l'image plutôt que sur le texte comme moi, doiventla consulter régulièrement ! d'ailleurs je viens de vérifier, la page est consultée presque mille fois par jour http://stats.grok.se/fr/200903/Fichier:Searchtool.svg !--Chandres (d) 27 mars 2009 à 14:10 (CET)

Une bonne et une mauvaise nouvelle

Micthev avait laissé un message à Lgd à ce sujet, mais il a dû passer à l'as. User:Micbot est capable — dans une certaine mesure — de détecter la langue anglaise et d'ajouter le modèle {{lang}}, ainsi que de détecter les siècles et chiffres romains pour leur ajouter les modèles qui vont bien. J'ai dit dans une certaine mesure, car il fait trop de ratés pour qu'on le laisse tourner sans vérification, environ 1 erreur sur 10 justes. Et la détection de la langue anglaise est souvent partielle (par exemple, j'ai du compléter l'exemple ci-dessus), car elle est repérée par certains mots très courants (and, the, ...). Il est donc très utile, mais à utiliser en semi-automatique, en demandant confirmation avant de publier. Voici pour la bonne nouvelle.

La pas bonne, c'est que son dresseur est parti. Toutefois, je suis sûr qu'il serait intéressé de refiler son script, donc ce qu'il faut c'est quelqu'un de motivé, voir plusieurs personnes (je suis un grand idéaliste ). J'ai plusieurs projets d'importance qui passent avant dans mon emploi de temps (genre la refonte de la page d'acceuil), mais à l'occasion je serai tenté, si vous me confirmez que cela en vaut la peine. Verdict ? :D Amicalement, Dodoïste ^{[ dring-dring ]} 12 mars 2009 à 21:25 (CET)

Sur ce type d'article c'est peut-être bien hélas en biologie les expressions anglaises ne comportent jamais de the ou and... exemple Ada (oiseau) pourtant un contributeur nous en a fait pas mal du même style et c'est pénible à compléter à la main. Je me disais par contre qu'un bouton ou un bout de script près à l'emploi ne serait pas du luxe : ''{{lang|en|}}'' --amicalement, Salix ( converser) 12 mars 2009 à 21:50 (CET)

Oui, c'est bien en tant que "bout de script" que je compte l'utiliser. Il est très utile pour repérer les articles avec des textes en anglais, et commencer le boulot. Il simplifie le travail en somme, mais est très loin de le faire tout seul. Amicalement, Dodoïste ^{[ dring-dring ]} 12 mars 2009 à 22:08 (CET)

Bonne idée sur le fond même si moi aussi j'ai d'autres projets sur le feu ! Question annexe : est ce qu'il y a des restrictions à l'usage de ce modèle ? Par exemple pour les noms propres (The Beatles) ou alors dans le cas où seulement quelques mots (une partie de phrase) sont en anglais, doit-on ou peut-on quand même l'utiliser ? — Droop ^[blabla] 12 mars 2009 à 22:10 (CET):

@ Dodoïste, je voulais dire ajouter « ''{{lang|en|}}'' » en dessous de la boîte de résumé, avec les autres bouts de syntaxe prêts à l'emploi [[Catégorie:]] [[Fichier:]] [[Media:]] #REDIRECTION[[]] · [[Commons:|]] , etc. --amicalement, Salix ( converser) 12 mars 2009 à 22:38 (CET)

@ Droop, je pense que ça doit suivre en gros les mêmes principes que les conventions typographiques, en particulier sur les italiques et les mots étrangers. --amicalement, Salix ( converser) 12 mars 2009 à 22:47 (CET)

Excuse-moi mais je ne vois pas trop le rapport avec la typographie ! — Droop ^[blabla] 12 mars 2009 à 22:51 (CET)

Pour préciser l'usage du modèle {{lang}} : la question est délicate, et je n'ai pas encore complété les bonnes pratiques sur ce point. Voici ce qu'en dit la norme d'accessibilité WCAG:

Individual words or phrases in one language can become part of another language. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this Success Criterion. Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended. If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually not translated to all languages. The universal nature of technical terms also facilitate communication between professionals.

Some common examples of technical terms include: Homo sapien, Alpha Centauri, hertz, and habeas corpus.

Voici ce qui a été retenu par la méthode d'évaluation Accessiweb:

• nom commun de langue étrangère, présent dans le dictionnaire officiel de la langue par défaut de la page Web (exemple : parking) : ne pas mettre l'attribut lang (Note : le dictionnaire officiel est celui recommandé par l'académie en charge de la langue en question. Par exemple pour la France, le lien vers le dictionnaire officiel se trouve sur le site de l'Académie Française à l'adresse suivante : http://www.academie-francaise.fr/dictionnaire/index.html. Pour toute demande auprès du service du dictionnaire de l'Académie Française, utiliser le formulaire en ligne),
• nom commun de langue étrangère, non présent dans le dictionnaire officiel de la langue par défaut de la page Web et qui est passé dans le langage commun de la langue par défaut de la page Web (exemple : newsletter) : mettre ou pas l'attribut lang pour une bonne prononciation par les synthèses vocales,
• nom propre : aucune obligation de mettre l'attribut lang.

Et voici ce qui devrait être retenu par la méthode d'application RGAA: pas d'attribut lang « si le segment de texte n'est pas un nom propre, un mot/groupe de mots pouvant être identifiés s'il est prononcé dans la langue du contexte ou un mot/groupe de mots passé dans le langage courant de la langue du contexte »

Le tout est de parvenir à une recommandation aussi simple que possible pour les contributeurs...

Maintenant, le robot: il me semble pouvoir être une aide appréciable, au moins sur certains types de pages fréquents, et devrait pouvoir être adapté à d'autres langues par la suite. Je regrette d'avoir en effet loupé le message à son propos. Récupérer son code serait une bonne idée.

Enfin, le bouton dans le formulaire de saisie: on peut déjà passer par un gadget et proposer ensuite son application par défaut pour tous les utilisateurs. Je vais tâcher de mettre en place le gadget rapidement. --Lgd (d) 13 mars 2009 à 07:34 (CET)

Super, merci d'avance . Donc si je résume la règle : on met {{lang}} aux noms communs qu'un français n'arrive pas prononcer correctement s'il ne connait pas l'anglais, ce qui est logique. C'est moins logique d'en exclure les noms propres : The Beatles ou Dream Theater lus avec l'accent français ce n'est pas triste... mais bon --amicalement, Salix ( converser) 13 mars 2009 à 10:22 (CET)

Teu-Bée-à-t'-lss et Dreux-âme-thé-à-terre ? TED 13 mars 2009 à 17:46 (CET)

Exactelie taide --amicalement, Salix ( converser) 13 mars 2009 à 19:14 (CET)

De Royan et des balises alt.

Bonjour ! L'article Royan, récemment promu (félicitations à ceux et celles qui ont travaillé fort dessus), m'amène à me poser la question suivante : la balise alt est destinée à décrire le contenu de l'image à l'intention de ceux qui ne la voient pas, quelle qu'en soit la raison (physique, matérielle, logicielle...). Dans l'article en question, cette balise a été utilisée pour intégrer une analyse architecturale des bâtiments présentés sur les photos. Donc, si je configure mon navigateur pour voir les photos, je vois le bâtiment, mais pas l'analyse... Oui, vous pouvez me dire que je pinaille. --Maurilbert (discuter) 18 mars 2009 à 16:08 (CET)

Oui, tu pinailles, d'abord sur la distinction entre « analyse architecturale » et « description », mais ce n'est pas le point clé. en fait, le principe peut-être le plus important de l'accessibilité Web est juste « ne pas léser des utilisateurs en raison de leur situation de handicap ». La clé, c'est de bien le différencier de « donner la même information à tout le monde » ou « donner une information pertinente à tout le monde », ou encore de « donner toute l'information à tout le monde », ou encore de « donner la meilleure information possible ». Si, au hasard d'un dispositif d'accessibilité bien géré éditiorialement, ces utilisateurs handicapés se retrouvent finalement avec un contenu plus pertinent que celui par défaut, ce n'est pas un souci.

A vrai dire, c'est amusant, parce que je discutais justement aujourd'hui IRL d'un site d'information public qui est justement beaucoup plus compréhensible et intuitif via une aide technique que pour les internautes « lambdas » .

Mais bref : si une description de ces bâtiments ou davantage (analyse archi) est jugée nécessaire pour tous les utilisateurs, ce ne sont pas les alternatives qui sont à revoir, c'est le contenu textuel de l'article et son propos. Et dans ce cas, les alternatives seront à leur tour à revoir, car elles seraient alors dans un autre contexte. Tu vois l'idée ? --Lgd (d) 18 mars 2009 à 16:26 (CET)

En l'occurence il n'est fait aucune analyse architectirale, ce sont des description de photos. Rien n'est dit sur ce qui n'est pas visible à l'écran. Un "bien voyant" qui sait regarder a la même information . --amicalement, Salix ( converser) 18 mars 2009 à 16:56 (CET)

Tu tends le bâton pour te faire battre, Salix . Il est tout de même vrai que tes descriptions publient plus d'information que l'image ne le fait didactiquement, tout bêtement parce qu'elles sont verbalisées, et qu'elles reflètent un choix éditorial là où chaque lecteur ne saura pas forcément « lire une image », pour raccourcir très rapidement. C'est là où l'accessibilité est intéressante dans la gestion de la qualité: si ce degré d'information est finalement très utile à tous, pourquoi diable n'est-il pas dans le contenu textuel par défaut, que l'image vient alors réellement accompagner pour donner un autre accès à la même information ? Au fond, pourquoi est-ce l'image à laquelle on cherche une alternative, quand elle devrait plutôt être elle-même l'alternative au texte ? Autrement-dit, est-ce que nous savons vraiment nous servir des images sur Wikipédia ?

Zut, voilà-t-y pas que JY Rehby ne pinaille plus tant que ça, en fait, ou que je vends la mèche au lieu de le laisser exploiter ma réponse ci-dessus --Lgd (d) 18 mars 2009 à 17:16 (CET)

Bon doit-on envisager, pour ne pas frustrer les bien voyants, de réduire toutes les descriptions alternatives architecturales à « alt=Bâtiment avec murs, toiture, ouvertures », de campagne à « alt=Paysage avec ciel », de ville à « alt=Bâtiments et rues » ou de personnages à « alt=Tête sur un corps » ? Et encore, c'est peut-être encore trop, je propose donc de mettre « alt=image » partout, ça suffira bien pour l'accessibilité non ? . --amicalement, Salix ( converser) 21 mars 2009 à 20:45 (CET)

Bwa, j'invitais juste à rédiger des articles plus complets. Patapé --Lgd (d) 21 mars 2009 à 20:47 (CET)

C'est déjà long et épuisant d'écrire un AdQ avec les exigences actuelles alors laissons un peu de travail aux piranhas --amicalement, Salix ( converser) 21 mars 2009 à 21:07 (CET)

modèles de lignes de transports du Loiret

Salut, on se pose quelques petites questions sur l'accessibilité de liens tels que ceux-ci, aussi bien au niveau des contrastes de couleur qu'en ce qui concerne la possibilité d'une lecture du nombre par un logiciel de lecture :

• 4
• Modèle:Ligne Semtao/couleur ligne
• 10

Pouvez-vous donner votre avis sur la page de discussion suivante? Insertion des modèles de lignes de transports dans les pages, page de discussion de l'Utilisateur Aquatikelfik Merci d'avance! --Mélanie Huguet (d) 21 mars 2009 à 14:31 (CET)

Je préfère ne pas donner mon avis sinon je vais être extrémiste : passage du modèle en PàS, passage de l'article consacrés à la liste des lignes en PàS aussi ! Sérieusement : çà apporte quoi ce bariolage de couleurs ? Où est l'intéret encyclopédique là-dedans ? Pour ce qui est de l'accessibilité, je laisse le soin aux spécialistes de répondre ! — Droop ^[blabla] 21 mars 2009 à 15:05 (CET)

Droop: tais-toi.C'est moi qui fait groumpf, ici.

Chic ! des contributeurs qui s'intéressent à la question . Le souci, c'est que la réponse va effectivement porter sur le problème immédiat d'accessibilité, mais que je sens qu'elle va rapidement aller sur les questions de pertinence encyclopédique.

Bon, trêve de plaisanterie:

• Immédiatement, de nombreux liens de ce type ne seront évidemment pas accessibles, et je ne parle même pas de la gêne pour tous les publics en dehors des questions d'accessibilité :
  • 4: blanc sur fond jaune, personne ne fait ça ailleurs sur le Web à part peut-être un ou deux sites personnels bricolés, ratio de contaste de 1.4 pour un minimum de 4 retenu ici, et il n'est même pas besoin de faire le test pour constater que c'est illisible.
  • Modèle:Ligne Semtao/couleur ligne: 1.8. Pas mieux, même commentaire.
  • 10: 1.5, vous avez compris.

Donc, ça n'est absolument pas accessible pour des utilisateurs ayant le moindre handicap visuel qui tombe mal, et c'est tout simplement imbittable pour le pékin moyen. Mais la question n'est en fait pas là.

La question, c'est: pourquoi ces couleurs ?

Sont-elles indifférentes au media (le Web ? le papier ? Les panneaux aux arrêts de bus ?) Je vous rappelle qu'ici vous écrivez d'abord pour le Web, avec dans l'idée que ce sera réutilisable ailleurs. Tiens, au fait, comment communique l'entité concernée, sur son propre site ? Comment les utilise-t-elle ? De manière aussi primaire et maladroite ? ce serait bien de s'en insspirer, s'il faut vraiment en passer par là.

Mais au fait: est-il NPOV de les utiliser pour communiquer ici sur ces lignes de transport juste parce que l'acteur privé ou public à l'origine de celle-ci en a fait un de ses outils de communication ? Ne sentez-vous pas un léger souci de neutralité de point de vue, quand on réplique sans plus de contexte une charte graphique issue tout droit du marketing ?

surtout: ces couleurs véhiculent-elles une information qu'on ne puisse véhiculer autrement ? A ce point qu'il faille les reproduire ici parce qu'un article sur ces lignes de transports ne serait plus pertinent sinon ?

Dire que la ligne X est associée dans la signalétique à la couleur Z, oui. De préférence parce qu'on aura trouvé une publication sur le sujet, analysant la signalétique de ce réseau. Mais rendre Wikipédia à la fois un peu ridicule à force de naïveté (tout de même) et concrètement illisible sans contextualiser la moindre information, parce qu'on prend certaines choses au pied de la lettre, non. s'il vous plaît, non :parlez-en, si vous avez les sources, mais ne le faites pas. --Lgd (d) 21 mars 2009 à 15:12 (CET)

--Lgd (d) 21 mars 2009 à 15:12 (CET)

Voilà, c'est exactement ce que je voulais dire ! Et avec le recul : toutes mes excuses pour ma rudesse primaire, c'est effectivement très bien de venir s'intéresser à cette question !— Droop ^[blabla] 21 mars 2009 à 15:25 (CET)

Merci pour ces remarques rapides! Pour ce qui est des contrastes je m'en doutais déjà sans les valeurs scientifiques. Et pour ce qui est de l'intérêt encyclopédique, il vaut mieux clarifier tout cela avant que trop de travail ne soit réalisé! En fait le travail de colorisation des lignes a sans doute commencé avec l'article Lignes_de_bus_de_Toulouse. Effectivement ça fait un peu « smarties »... Il y a ensuite eu pour le Loiret les pages Réseau_SEMTAO et Réseau_Ulys inspirées de la page toulousaine. On peut voir ici que les couleurs correspondent bien aux couleurs des lignes : Lien vers les lignes de la Semtao. Et certaines couleurs ont une signification, comme la couleur rose pour les lignes 31 à 36, qui sont des lignes de transport à la demande (il faut appeler pour que le bus passe). Effectivement, sur le site officiel du réseau, les nombres sont plus gros et ombrés. Personnellement, ayant été utilisatrice du réseau durant de nombreuses années, je pense que ces couleurs ont une signification pour les usagers mais que leur présence sur l'encyclopédie n'est pas indispensable. Pour autant, je ne la trouve pas choquante. Mais je suis encore relativement novice concernant ce qui rentre ou non dans les critères de l'encyclopédie... A la lecture de vos réponses, j'ai l'impression que la question centrale est : peut-on garder ces liens à titre illustratif ou s'agit-il d'un manque de neutralité? Sinon, pouvez-vous juste préciser les initiales « PàS » et « NPOV » que j'ai déjà croisé sur Wikipédia mais dont je n'ai pas encore retenu la signification? (Et oui, ce langage ne m'est pas accessible! Mais c'est juste un clin d'œil. )

Je confirme l'inutilité d'un tel article dans Wikipedia, au même titre que les articles décrivant les différentes sorties d'une autoroute ou les communes traversées par une route (mais un frein a été mis de ce côté-là). Pour ce qui est du réseau de transports interurbains du Loiret, tout est dit dans le site officiel : http://www.ulys-loiret.com/. Il serait illusoire et inutile de vouloir recopier ce site. L'usager y a toutes les infos nécessaires. En outre, il ne faut pas oublier que d'une part le réseau est susceptible d'évoluer dans le temps et d'autre part les entreprises également, puisqu'il s'agit de délégations de services publiques attribuées sur marchés publics relancés périodiquement. La preuve en est ici. Ainsi les seules infos d'intérêt qui viennent d'être mises dans l'article risquent d'être périmées très prochainement!Roland45 (d) 21 mars 2009 à 16:30 (CET)

Heu.

J'ai un souci, là, mais c'est de ma faute : cet atelier n'a rien à dire sur le fond, juste sur les questions très précises d'accessibilité, où je pense que tout a été dit et entendu. Mais je suis le premier coupable d'avoir débordé dans ma réponse ci-dessus sur les questions de pertinence. Il faut décidément que je me surveille, désolé. Je tâcherais de vous rejoindre un peu plus tard sur la page où c'est en discussion sur le fond, donc. Mais cette fois, à titre personnel. --Lgd (d) 21 mars 2009 à 16:37 (CET)

Désolé, hors-sujet également, mais je répond à l'affirmation de ci-dessus avec laquelle je ne suis pas tout à fait d'accord, ce qui est normal vu que j'ai créé la page. D'une part, une telle page donne un aperçu général du réseau, ce qui n'est pas le cas du site officiel (y compris de la carte donnée en pdf) et puis je rappelle qu'il s'agit d'une ébauche de page et qu'elle est appelée à être améliorée et enrichie. D'autre part, ce réseau est certes amené à évoluer, mais ne sera pas non plus changé radicalement chaque année. Quelle page n'est pas amené à être mis à jour régulièrement ? wikineptune (d) 21 mars 2009 à 16:42 (CET)

Autant pour moi également. Sur la notion d'admissibilité, j'ai ajouté une section dans la Pdd de l'article.Roland45 (d) 21 mars 2009 à 16:45 (CET)

Gadgets

Bonjour,
Est-ce qu'il y a une page qui explique le fonctionnement du gadget sur l'accessibilité (Inspection des tableaux et Inspection des headers). Merci! — Riba ^(discuter) 21 mars 2009 à 18:53 (CET)

Histoire de la pensée économique des arts et de la culture (d · h · j · ↵ · BA · Ls)

Afin de me familiariser avec le problème, j'aimerais qu'un d'entre vous, si votre temps le permet, me fasse un commentaire de cette page en termes d'accessibilité. Cela me donnera une idée de comment procéder à l'avenir. Merci ! -- Bokken | 木刀 27 mars 2009 à 12:18 (CET)

Le contenu est essentiellement textuel, sans tableaux de données, ni timeline (histogrammes etc.) ce qui facilite les choses. Côté positif, les libellés de liens interne et externe sont pour l'essentiel suffisamment explicites pour être compréhensibles hors contexte (Voir Libellés des liens). La structure de titrage des sections est bien évidemment cohérente et le libellé des titres est pertinent, ce qui découle tout droit des critères généraux de qualité de Wikipédia, mais qui correspond également à un critère d'accessibilité majeur.

Les améliorations nécessaires seraient:

• les alternatives textuelles des images (thumb) qui sont actuellement toutes absentes. La première image sera par exemple lue « 180px-Repin_tretyakov.jpg » par un lecteur d'écran. Voir Images et le travail mené par Salix sur Royan.
• les expressions (titres d'ouvrages, liens, etc.) en anglais, qui ne sont pas signalés. La prononciation peut être incompréhensible dans une synthèse vocale. Voir Changements de langue.

Note: je laisse de côté certains autres problèmes, qui ne sont pas liés au contenu de l'article, mais à des modèles tels que ceux utilisés dans les notes ou la bibliographie, ou encore au fonctionnement global du système de référence.

--Lgd (d) 27 mars 2009 à 12:38 (CET)

Merci de ce retour rapide. À vrai dire, je me doutais en posant la question que le système des notes et références n'était pas optimal. Il ne l'est déjà pas dans un cadre d'utilisation habituel, d'ailleurs, mais je ne sais pas comment mieux faire. Je vais lire les liens que tu donnes et tâcher d'améliorer ce qui peut l'être. -- Bokken | 木刀 27 mars 2009 à 13:40 (CET)

Pour les références, cela ne dépend pas vraiment de la manière d'utiliser <ref> mais surtout du système lui-même. L'extension, peu satisfaisante, est sauf erreur de ma part en cours de refonte, ce qui me fait penser qu'il urge plutôt d'attendre. Cela dit, on peut cependant améliorer son paramètrage ici, via les messages systèmes. Il faudrait que je revois ça en détail.

Sinon, n'hésite pas à faire signe en cas de besoin (d'autant que l'aide en accessibilité a certainement besoin d'être améliorée). --Lgd (d) 27 mars 2009 à 13:43 (CET)

Sondage du jour

Salut Lgd et Vigneron, je me demandais quoi conclure de ce sondage? Je me suis rappelé que les labels n'était pas destiné à améliorer les articles, mais juste des récompenses que ce donne entre eux des wikipediens qui n'ont que faire de la transmission du savoir! Donc ce sondage était mal formulé, surtout mal ciblé. Mais je n'en reviens tout de même pas comme certains ont pu perdre de vue ce que peut être le but de cette encyclopédie. Lgd m'avais prévenu pour un autre sujet, que le bistro n'était pas forcément la meilleure place pour avoir des avis pertinent! Bon je tire tout de même un peu de positif de cela, j'espère que cela aura contribué à sensibiliser quelques contributeurs que 2-3 petits détails dans la manière de rédiger des articles peuvent énormément changer la manière de les lire pour d'autres contributeurs. Sinon une analyse rapide de ce vote montre une tendance favorable majoritaire, suivit par la tendance désabusé! . Les avis contre me semble particulièrement non pertinent, principalement tourné vers l'aspect "obtention" du label, et non pas ce qu'il représente. Je proposerais 2 choses:

1. Dans la page Wikipédia:Articles_de_qualité/Règles#Critères, ajouter l'atelier accessibilité dans la phrase « Vous pouvez proposer les articles au Comité de lecture et à l'Atelier typographique afin d'avoir des avis sur leurs défauts et d'améliorer ainsi leurs chances de promotion (non obligatoire). »
2. Dans la page Projet:Label/Liste_de_vérification rajouter le paramètre texte alternatif des images, et le modèle {{lang}}, je crois que ce n'est vraiment pas difficile à mettre en place, et que c'est un bon début pour sensibiliser les contributeurs.

Voila avant de faire quoique ce soit je voulais avoir votre avis. merci--Chandres (d) 27 mars 2009 à 22:18 (CET)

Bien, bien, bien... Allons-y:

En effet, la première chose à faire aurait été de ne pas se précipiter pour lancer sur le Bistro, beaucoup trop tôt, un sondage mal ficelé, dénué des explications nécessaires, et irréaliste. S'il y a un Atelier accessibilité et des gens qui y interviennent depuis longtemps, il aurait fallu penser à leur demander si c'était une bonne idée. Même si cela partait, je n'en doute pas un instant, d'une excellente intention.

Résultat : un sondage (pas sur le Bistro, un vrai) que pour ma part j'envisageais de faire dans quelques mois sous une forme bien construite et argumentée, appuyée sur des exemples simples, avec une question réaliste (proposer le comité de lecture et non attaquer bille en tête avec des critères), et surtout après plusieurs collaborations informelles avec des AdQ ou BA préparant le terrain, sera fortement handicapé le jour venu par le principal résultat de celui-ci qui est: « l'accessibilité ? ah non ! Pas de critères supplémentaires ! Font chier ceux-là. »

Quand je vois certaines personnes voter contre alors qu'ils sont très loin d'être opposés sur le principe, et quand je vois explicités sur le Bistro des motifs d'opposition qui sont loin d'être non pertinents, mais qui auraient pu être esquivés, j'avoue que je suis un peu déprimé par cette gaffe monumentale. Mais bon, le vin étant tiré, il va falloir le boire. Et au moins, maintenant, tu penses à demander l'avis de deux autres personnes, avant de faire quelque-chose, c'est déjà ça.

Alors :

• on ne rajoute surtout rien à Projet:Label/Liste de vérification. D'abord parce que cela provoquera des conflits, et ensuite parce que je ne veux pas, si ça passe, que ce soit un prétexte ensuite pour bloquer la prise en compte de l'accessibilité en la limitant à un ou deux critères arbitraires, qui peuvent se trouver sans rapport avec les soucis rencontrés dans les articles.
• on ne modifie pas non plus Wikipédia:Articles de qualité/Règles, même une mention d'un comité de relecture qui risque d'être vue comme un passage par la bande pour imposer de nouvelles obligations : on se fait discrets et on prend le temps de rattraper le coup, avant de reparler d'ajouter quoi que ce soit aux AdQ ou BA.

Voilà, voilà...--Lgd (d) 28 mars 2009 à 02:41 (CET)

Sinon, pour affiner un peu les résultats, et pour la petite histoire, je relève:

• 7 pour en connaissance de cause
• 8 pour farfelus ou en tout cas et de toute évidence sans savoir de quoi il retourne
• 6 pour indéterminés sur ce point
• 6 contre avec l'argument marquant « pas de critères ou de surcroît de difficulté pour les AdQ »
• 5 contre de gens qui ne savent pas de quoi il retourne mais que ça a hérissé
• 8 neutres à tendance négative de gens qui ne savent pas de quoi il retourne

Bref:

• 21 votes à côté de la plaque, soit 52%, dont une part des votes positifs. On est dans la fourchette supérieure des votes Wikipédiens qui recueillent toujours au moins un tiers d'avis de passants qui ne savent pas de quoi qu'on cause, mais qui font l'opinion et les usages. C'est le prix du déficit d'explications.
• 47% d'opposition ou de réticence, on ne bouge donc pas --Lgd (d) 28 mars 2009 à 03:25 (CET)

Je m'immisce... Je pense que la plupart des réponses indéterminées, négatives ou à tendances négatives vient du fait que leurs "émetteurs" n'ont pas eu de problèmes personnels ou de contacts directs avec des personnes « handicapées » ; sinon ils réagiraient positivement. De plus écrire en wiki n'est pas simple et l'idée d'ajouter des alt=, etc. doit leur paraître un fardeau... Mais je ne vois pas pourquoi vous ne corrigeriez pas les propositions de BA et AdQ (sauf le problème du temps, évidemment...). Bon courage ! --Égoïté (d) 28 mars 2009 à 09:03 (CET)

J'avoue que j'étais vraiment mal hier soir quand j'ai vu la tournure que prenait ce sondage, quand j'ai réalisé que cela pouvait avoir plus d'aspect négatif que positif. Le truc c'est que je n'ai même pas fait ca par "bon sentiment" mais juste parce que ca me semblait tellement évident que des paramètres comme alt ou le modèle lang doivent être utilisé ! je réalise que j'avais sous-estimé la proportion de personne qui contribue à wikipedia pour elle même, et qui n'ont pas grand chose à faire des lecteurs d'article en fait! Bon cela ne m'empechera pas d'essayer d'améliorer l'accessibilité des articles sur lesquels j'interviens, et aussi de suivre cet atelier. Je vous présente donc toute mes excuses, et me dis que je devrais vraiment me limiter à éditer des articles et prendre des jus de carottes au café des biologistes! en attendant je vais prendre un wikibreak de quelques jours pendant lequel je me répéterais "réfléchis avant de faire quelquechose, et surtout cherche si quelqu'un n'y a pas déjà réfléchis".--Chandres (d) 28 mars 2009 à 12:07 (CET)

Cantine

Bonjour. Auriez-vous l'obligeance de vérifier l'accessibilité de Cantine ? Plus généralement, quel modèle faut-il utiliser pour les textes en langue régionale comme le normand (voir note 53), le wallon, etc. ? Serait-il possible de recevoir la réponse sur ma PdD ? Merci de votre aide. --Égoïté (d) 28 mars 2009 à 08:53 (CET) P.S. toute critique de l'article est la bienvenue (j'aimerais le reproposer en BA)

argh, les langues régionales, l'un des recoins les plus abominables de BCP 47, RFC 4646 et autres IANA Language Subtag Registry. Ok, noté, chouette week-end en perspective .

Plus sérieusement, bravo pour les alternatives textuelles. Pour la chanson de Perret, deux possibilités:

• un <blockquote> ou un {{Début citation}}...{{Fin citation}}, indifféremment selon que tu es plutôt modèles ou non (le plus évident AMHA)
• un <pre>.
• éviter par contre :: qui ne fait qu'indenter la présentation sans permettre de délimiter structurellement le début et la fin de l'oeuvre ou <poem> que tu rencontreras sans doute aussi dans les pages d'aide, mais qui, en dépit de son libellé, n'est pas approprié pour la même raison.

Il y a d'autres détails sur des libellés de liens dans les notes, mais je passerai tout en revue ce week-end.

Cordialement, --Lgd (d) 28 mars 2009 à 10:08 (CET)

Attention, il y a langue régionale et langue régionale ! C’est au cas-par-cas : pour le normand, c’est effectivement le bordel (on se pose d’ailleurs la question en ce moment sur la Wikidémie, je suis en train d’établir une liste des langues du monde, ça prend du temps !) ; par contre, pour le wallon, il existe des codes ISO, donc on peut mettre Tos lès-omes vinèt-st-å monde lîbes. Pour retrouver ces codes, regarde l’infobox de la langue. Rien à voir avec la question initiale mais dans Cantine tu devrais séparer les notes des références pour plus de lisibilités (cf. Aide:Notes#Notes groupées). Cdlt, VIGNERON * ^discut. 2 avril 2009 à 09:54 (CEST)

Non, surtout pas les infobox de langue, c'est fiable ou pas, selon le crédit qu'on accorde à Wikipédia.

• Une référence de base sur les codes de langue: Language tags in HTML and XML, W3C
• Un outil très précieux, mais quand on connaît déjà le sujet: IANA Language Subtag Registry Search, idem

--Lgd (d) 2 avril 2009 à 09:59 (CEST)

Les codes de langue IETF dans les infobox de langue sont fiables, je les ais vérifiées personnellement et individuellement (pour la plupart). Visite fortuitement prolongée (d) 26 septembre 2011 à 23:13 (CEST)

PDF

Bonjour,

J'ai vu sur les bonnes pratiques qu'il était recommandé d'ajouter la mention (PDF) dans l'intitulé des liens de format pdf. Ma question est peut être bète ou impossible techniquement, mais ne serait-il pas possible de demander à un bot de repérer, dès qu'il y a des balises <ref> l'extension .pdf et d'y ajouter, si elle n'y est pas déjà, automatiquement la mention (PDF) séparé d'une espace en fin d'intitulé de lien ? Trop compliqué ? — Droop ^[blabla] 30 mars 2009 à 23:42 (CEST)

Techniquement oui. Mais c'est une modification de grande ampleur (en raison du nombre de pages visées) sur laquelle il serait nécessaire de recueillir d'abord un certain consensus (elle relève de l'évidence, certes, mais les moeurs wikipédiens sont ce qu'ils sont... ). --Lgd (d) 31 mars 2009 à 06:20 (CEST)

Tu proposes quoi ? On attend ? On tâte le terrain ? Veux-tu que j'ouvre une discussion sur le bistrot ? — Droop ^[blabla] 31 mars 2009 à 07:14 (CEST)

Attends un peu, pour laisser passer le débat sur les AdQ etc. Mais sinon, oui, le Bistro devrait permettre de sonder rapidement les avis. --Lgd (d) 31 mars 2009 à 07:20 (CEST)

Gadget accessibilité

Bonjour,

En trainant sur Aide:Les tableaux pour les experts, j’ai découvert le gadget accessibilité que j’ai aussitôt activé. J’ai bien une boîte qui apparaît en dessous de la boîte à outils mais j’ai beau cliquer sur les deux liens : Inspection des tableaux et Inspection des headers, il ne se passe rien (que ce soit en mode lecture ou en mode édition, que je sélectionne le tableau ou pas, etc.). Donc pour en revenir à la question ci-dessus de Riba, je pense que ce serait pas mal de créer une page d’aide (et si elle existe de la faire connaître !). Cdlt, VIGNERON * ^discut. 2 avril 2009 à 09:49 (CEST)

todo todo todo... J'avais noté, mais un grand coup de flemme m'a pris en revers, désolé. --Lgd (d) 2 avril 2009 à 09:52 (CEST)

Ok merci, parfait (je note déjà que les liens externes sont redevenus normaux, merci). Cdlt, VIGNERON * ^discut. 2 avril 2009 à 10:00 (CEST)

Tout d'abord merci,

Encore une question, quand le lien amène à Wikipédia free encyclopedia, il ne fonctionne pas. Est-ce à dire que les encyclopédies française et anglaise sont totalement distinctes et qu'il faut mettre un lien externe de l'une à l'autre? Exemple sur ma page : Cleo Higgins, Sleepover Club etc

Alice Ley

Projet de refonte du modèle {{Bienvenue nouveau}}

Bonjour, j'ai proposé de rendre ce modèle plus agréable à la lecture. Le segmenter en cadres pourrait être une idée. J'ai repris le modèle indonésien, je voulais savoir si c'était acceptable au niveau de l'accessibilité ou s'il peut l'être. J'en profite pour demander s'il faut mieux un color background transparent ou blanc ? Le modèle est ici. La discussion s'est entamée sur Discussion modèle:Bienvenue nouveau#Donner un coup de jeune?. Merci --Sisyph 6 avril 2009 à 00:35 (CEST)

Il y a, en l'état, plusieurs corrections nécessaires à faire dans le code (sans conséquences sur le rendu). Mais autant attendre que le modèle ait pris son contenu définitif et sa forme finale. refais signe à ce moment. Cordialement, --Lgd (d) 13 avril 2009 à 10:02 (CEST)

Typographie des titres

Bonjour,
Je ne sais pas si je suis à la bonne place pour amener cette discussion. Je suis tombé aujourd'hui sur ce modèle {{Isomérie}}. Je me demande si l'insertion de wikilien dans les titres d'articles en vraiment une bonne pratique. J'en doute, mais j'aimerais avoir un autre avis. Merci. — Riba ^(discuter) 11 avril 2009 à 17:27 (CEST)

aucun impact en termes d'accessibilité. En revanche, c'est souvent peu apprécié par des contributeurs, essentiellement car cela rallonge l'url des liens internes vers la section concernée. --Lgd (d) 11 avril 2009 à 17:39 (CEST)

Prise de décision sur les infobox

Bonjour, au cas où vous ne seriez pas au courant : Wikipédia:Prise de décision/Apparence générale des infobox est en phase de discussion. --amicalement, Salix ( converser) 21 avril 2009 à 13:37 (CEST)

La mise en forme d'un contenu, telle qu'elle envisagée dans cette PDD, n'est pas un problème d'accessibilité : Une fois déterminé un contenu, on se pose la question de l'accessibilité lors de la définition de sa structure la plus pertinente, puis lors de celle de son rendu. Là, on commence par le rendu...

Cela dit, une décision abruptement « graphisme V1 » ou « graphisme V2 » laisserait entières les questions importantes qui pendent comme des jours sans fin à propos des infobox, dont l'accessibilité n'est d'ailleurs pas la plus importante (sans compter que si cela se réduisait à V1 ou V2 qu'il s'agisse de graphisme ou d'autre chose, ce serait simple). Ce que l'on peut dire ici est: tant qu'on en reste aux considérations telles qu'indiquées au lancement de la discussion, c'est sans impact notable côté accessibilité : c'est un choix entre le pas bon et l'un peu moins bon.

Sinon, ces questions (incomplètes) peut éventuellement servir, mais bon courage face au mur en caoutchouc. --Lgd (d) 21 avril 2009 à 13:48 (CEST)

Salut, on a refondu la problématique, ce n'est plus V1 contre V2, mais décider des critères d'harmonisation de la feuille de style des infobox.

Autre chose : est-ce que le modèle {{Tnavbar}} pose problème dans les infobox? Est-il préférable d'y mettre {{Infodoc}} à la place? Si oui, pourquoi? Guérin Nicolas ^(messages) 21 avril 2009 à 17:16 (CEST)

Hum... On peut les renvoyer dos à dos, sauf si on cherche lequel est le plus améliorable :

• {{Tnavbar}} : le problème est que « v », « d », « m » ne sont pas des libellés de liens suffisants pour que ce soit compréhensible dans tous les contextes utilisateurs. Le modèle compense au mieux des possibilités offertes par mediawiki, en ajoutant les infobulles « Voir ce modèle » , « Discussion sur ce modèle » et « Modifier ce modèle. Merci de prévisualiser avant de sauvegarder », mais dans le détail technique, ce n'est pas fait ni faisable comme il faudrait pouvoir le faire pour répondre aux normes d'accessibilité : ces infobulles ne seront pas restituées dans tous les cas, laissant des utilisateurs avec les seuls libellés incompréhensibles.
• {{Infodoc}} : le lien sur l'icône a une alternative textuelle tout à fait pertinente et efficace « Consultez la documentation du modèle », rien à redire. En revanche, le lien textuel « modifier » a une infobulle générée automatiquement par mediawiki qui est désastreuse (C'est carrément l'url du lien qui y est reproduit, ce qui donne par exemple « http://fr.wikipedia.org/w/index.php?title=Advanced_Micro_Devices&action=edit&section=0 »). Remplacer le lien textuel « modifier » par une icône avec son alternative textuelle permettrait, compte-tenu des limites actuelles de mediawiki, d'obtenir un lien parfaitement accessible.

Donc, s'il faut en choisir un, disons que {{Infodoc}} est plus prometteur en l'état des limites de mediawiki.

--Lgd (d) 23 avril 2009 à 11:11 (CEST)

C'est plutôt le lien "modifier" en lui-même qui me gêne : je comprends le lien vers la page du modèle pour voir la doc, et aussi le lien vers la page de discussion pour voir les débats autour, quand à modifier c'est d'un intérêt minime. Ceux qui modifient les infobox sont en général ceux qui ont un minimum d'intérêt ou de connaissances là-dessus. Beaucoup d'infobox sont de plus protégées en écriture. Ne peut-on remplacer dans {{Infodoc}} ce lien "modifier" par le lien "discussion"? Ou alors tout simplement l'enlever? Guérin Nicolas ^(messages) 23 avril 2009 à 16:15 (CEST)

ça, c'est un tout autre problème qu'une question d'accessibilité. La pertinence du lien « modifier » dépend du type de modèle, et ici on en a deux bien différents :

• les « véritables » modèles, comme les infobox, que le contributeur a de moins en moins de raisons fréquentes de modifier, et où son utilité est discutable, en effet.
• les « modèles-contenu », comme les palettes de navigation, que les contributeurs ont plus souvent à modifier, et où le lien présent dans {{Tnavbar}} leur est souvent plus utile.

Donc pour les infobox, ergonomiquement, le « modifier » est plus un truc de geek qu'autre-chose, mais pas pour d'autres modèles. --Lgd (d) 23 avril 2009 à 17:06 (CEST)

Modèle lang et translittération

Bonsoir à tous,

Je fais suite à un message posté par VIGNERON (d · c · b) dans le bistro du 21 avril. Il y est dit qu'il faut mettre le modèle {{lang}} non seulement pour le ou les mots en langue étrangère mais aussi pour leur translittération quand on repasse d'un autre alphabet à l'alphabet latin.

J'utilise personnellement toujours le modèle {{lang}}, et ses variantes {{grec ancien}} et {{grec moderne}}. Mais j'ai toujours omis d'utiliser {{lang}} pour les translittérations des mots grecs en alphabet latin. L'utiliser ne me gêne pas particulièrement, mais je voudrais être bien sûr que ça soit efficace. En effet, les translittérations utilisent parfois des caractères quelque peu… exotiques disons (j'en ai dressé la liste sur une page perso), qui proviennent notamment des variantes vietnamiennes de l'alphabet latin — au début de Wikipédia, et d'ailleurs aujourd'hui encore, c'est ce qui, visuellement, est le plus efficace pour rendre certaines lettres grecques quand elles ont trop de diacritiques.

Question alors : l'utilisation de ces caractères exotiques ne gêne-t-elle pas l'utilisation du modèle {{lang}} ? Question secondaire : le modèle {{lang}} peut amener chez certains utilisateurs un basculement vers une autre police : maintenir ce basculement en appliquant le modèle {{lang}} à ces mots en alphabet latin ne risque-t-il pas de conduire à des problèmes d'affichage ?

Mandrak (Discuter), 21 avril 2009 à 21:24 (CEST)

1.  surtout parce que ça transforme le rendu du grec chez moi et qu'il est plus joli mais chut je l'ai pas dit .

Du point de vue des normes Web (ici XHTML1.0 et norme d'accessibilité WCAG), le modèle {{lang}} permet d'associer deux informations au contenu: sa langue et si nécessaire sa direction (pour les écritures de droite à gauche). La première est totalement indépendante de la graphie (elle est donc nécessaire pour les translittérations). La seconde dépend du sens de lecture réel de la graphie (il ne faut donc surtout pas oublier de préciser par exemple dir=ltr pour une transcription de l'arabe marquée lang=ar). De ce point de vue, les réponses sont donc simples.

Cela étant dit, les questions qui se posent du côté « résultat actuel pour les lecteurs de Wikipédia » :

• L'utilisation de ces caractères exotiques ne gêne-t-elle pas l'utilisation du modèle {{lang}} ? A laquelle je rajoute: est-ce que les translittérations (une fois accompagnée des indications de langue et de direction appropriées) sont correctement restituées par les aides techniques d'accessibilité (ici, les lecteurs d'écran) ? Par expérience, le résultat est plus ou moins pertinent en fonction du lecteur d'écran, de sa version, de sa capacité à exploiter telle ou telle partie d'Unicode. Il ne faut donc pas tenir compte des limites éventuelles des logiciels, et s'en tenir à ce que demande les normes (les logiciels évoluant en permanence pour améliorer leurs implémentations en fonction de ces normes). Donc: oui, mentionner les translittérations quand elles sont nécessaires pour aider à la compréhension du contenu. Oui: utiliser les caractères jugés les plus pertinents. Oui, utiliser systématiquement {{lang}} en renseignant correctement ses paramètres.
• Est-ce que {{lang}} peut amener chez certains utilisateurs un basculement vers une autre police ? Ou plus généralement modifier le rendu affiché ? Je vois a priori pas comment cela pourrait être le cas. Ce modèle et les modèles similaires sont au contraire conçus pour ne servir qu'à indiquer des métadonnées, en étant volontairement sans effet sur ce qui s'affiche. Mais il peut y avoir des défauts de conception quelque-part (par exemple, dans des modèles particuliers autre que {{lang}} lui-même, ou dans une série de styles dans Mediawiki:Common.css). Il faut que je regarde plus avant. Peux-tu me donner des exemples de pages, pour me faciliter les tests ? Notamment celles où ça transforme le rendu du grec chez toi ?

Cordialement, --Lgd (d) 23 avril 2009 à 10:55 (CEST)

Merci de ta réponse Lgd.

Une remarque préliminaire : les Anglais disposent, dans leur modèle {{lang}}, d'un paramètre supplémentaire, auquel Vigneron faisait référence d'ailleurs dans son intervention bistrotière, qui permet de spécifier l'alphabet utilisé : {{lang|grc|grc-Latn|texte...}}. Il ne me semble pas, à le lecture de la documentation du modèle, que nous ayons ça. Un tel paramètre est-il utile réellement ? J'ai l'impression qu'il serait plus précis que {{lang}} tout seul.

• Noté pour ta première réponse. Je précise que la translittération est toujours utile, car il y a moins de lecteurs de Wikipédia qui lise le grec ancien que de lecteurs qui ne le lisent pas (et si on parle de l'akkadien c'est encore plus vrai...). Je trouve toujours très drôle de mentionner le nom original de quelque chose, alors que 99 % des gens sont incapables de le déchiffrer ! La translittération est une nécessité pour que tout le monde comprenne.

Je pense que le mieux serait de demander à un bot d'effectuer l'ajout de {{grec ancien}} autour de la transcription des mots. Je m'en chargerai sur la page adéquate.

• Je sais que le modèle {{lang}} n'influe pas directement sur l'affichage. Il se contente de baliser le texte. Mais certains utilisateurs ont pu modifier leur monobook.css pour changer le rendu des mots de certaines langues. Dans ce cas-là, inclure la translittération dans {{lang}} pourrait modifier le rendu de celle-ci, et induire des problèmes d'affichage (polices qui ne supportent pas les caractères avancés utilisés pour la transcription par exemple). Ce problème n'a rien de grave sans doute, je le mentionne par acquis de conscience.

Pour la différence de rendu, tu pourras (peut-être) t'en rendre compte ici : Discussion utilisateur:Mandrak/Laboratoire/Test2. En haut le début de l'Iliade avec {{grec ancien}}, en bas, le même sans rien. Si tu ne vois aucune différence, un petit screen t'y aidera : Fichier:Temp Mandrak.png. La police du bas est du Arial, mais celle du haut, je n'en sais rien. J'ai fouillé mon PC rapidement, je n'ai pas trouvé ce que ça pouvait être. Firefox est réglé chez moi pour que le grec s'affiche en Arial Unicode MS, mais je ne crois pas que ce soit cette police.

Cordialement,

Mandrak (Discuter), 23 avril 2009 à 18:50 (CEST)

Pour la différence de rendu: elle est due à des indications de polices de caractères particulières dans la feuille de style MediaWiki:Common.css, elles-mêmes issues d'un transfert de styles plus anciens depuis MediaWiki:Monobook.css :

/* Taille et famille des polices pour les écritures non-latines ; voir aussi [[modèle:Lang]]. */
 
/* Écriture grecque, pour les langues : grec moderne (monotonique), grec ancien (polytonique) */
:lang(grc), :lang(el) {
 font-family:"DejaVu Sans", Athena, Gentium, "Palatino Linotype", "Arial Unicode MS", "Lucida Sans Unicode", "Lucida Grande", Code2000, sans-serif;
}

A l'origine, cela répondait à une demande du projet Hellenopedia. Ces styles de polices sont pris en compte aussi bien quand le modèle est {{grec ancien}} que {{lang|grc}}. S'ils te posent un problème, je te suggère de voir avec le projet concerné.--Lgd (d) 24 avril 2009 à 12:37 (CEST)

Merci pour ces réponses. Tu as juste oublié l'une de mes questions :

Une remarque préliminaire : les Anglais disposent, dans leur modèle {{lang}}, d'un paramètre supplémentaire, auquel Vigneron faisait référence d'ailleurs dans son intervention bistrotière, qui permet de spécifier l'alphabet utilisé : {{lang|grc|grc-Latn|texte...}}. Il ne me semble pas, à le lecture de la documentation du modèle, que nous ayons ça. Un tel paramètre est-il utile réellement ? J'ai l'impression qu'il serait plus précis que {{lang}} tout seul.

Encore une fois, merci de ton aide.

Mandrak (Discuter), 29 avril 2009 à 18:58 (CEST)

Ce n'est pas un paramètre supplémentaire, c'est le paramètre de langue qui peut être renseigné en ajoutant la mention de l'écriture à celle de la langue: {{lang|grc-Latn|...}}.

Normativement, la règle de base est de garder ce paramètre aussi simple que possible, en évitant les mentions d'écriture ou de variantes régionales qui n'apportent pas d'information nécessaire (On ne doit pas écrire par exemple {{lang|en-Latn|...}}). Mais avec les translitérations du grec, il me semble que l'on est bien dans les cas où l'information est pertinente. De même que l'on utilise {{lang|zh-Hans|...}} ou {{lang|zh-Hant}} selon la graphie pour le chinois, ou encore {{lang|az-Latn|...}} pour de l'azéri en alphabet latin (il peut également être écrit en caractères arabes), on peut différencier :

• le grec ancien écrit normalement {{lang|grc|Ἰλιάς}} ou {{grec ancien|Ἰλιάς}}
• le grec ancien translittéré {{lang|grc-Latn|Iliás}}.

--Lgd (d) 30 avril 2009 à 06:34 (CEST)

Amélioration du modèle IUCN

Bonjour, on a besoin de quelqu'un qui puisse vérifier le code intégrant « alt= » pour améliorer Modèle:Taxobox IUCN. Voir cette discussion du café des biologistes. --amicalement, Salix ( converser) 28 avril 2009 à 10:51 (CEST)

Pour {{Taxobox IUCN}}: si on veut respecter les normes d'accessibilité, il faudrait virer le paramètre alt et passer par l'ajout d'un link= (link vide) dans le modèle, ce qui produit une image non liée à sa page d'image, mais avec l'alternative vide nécessaire à son cas dans ce contexte (elle ne véhicule aucune information et il n'y a en fait rien à en dire). Si l'absence de lien vers la page de l'image pose des problèmes philosophiques parce qu'il n'y a pas d'accès immédiat à l'auteur et à la licence, le texte actuellement proposé pour le alt n'est pas pire qu'un autre (par contre, il faut l'implémenter dans tous les modèles concernés). Je suppose donc que vous allez devoir rester sur la solution actuellement proposée, qui est passable.

Pour l'image générique de la taxobox: même problème, si ce n'est que la proposition d'utiliser la légende est à oublier : une légende affichée sous une image n'est pas une alternative textuelle de celle-ci. Si vous voulez gérer une alternative textuelle, il faut ajouter un paramètre idoine au modèle et espérer qu'il soit renseigné. Je chercherais plutôt du côté d'une alternative générique imposée par le modèle (alt=Image illustrative de l'article), tant que les images des taxo-info-box ne sont pas enfin gérées comme des images normales, c'est à dire des thumb avec légende et alt, ce qui arrivera peut-être un jour. --Lgd (d) 28 avril 2009 à 13:29 (CEST)

Merci je recopie ta réponse sur le café. --amicalement, Salix ( converser) 28 avril 2009 à 19:31 (CEST)

Hum. Je pense que l'image véhicule bel et bien une information : elle donne l'échelle IUCN, et permet de situer le statut de conservation sur cette échelle. Faut-il tout de même mettre un |link= vide ? Amicalement, Dodoïste ^{[ dring-dring ]} 29 avril 2009 à 12:34 (CEST)

Oui, il semblerait logique de mettre un texte alternatif du style « EX : espèce éteinte » (pour l'exemple que je regardais) qui serait choisi en fonction du paramètre du modèle. Où est le problème ? — Delhovlyn » (discuter) 9 mai 2009 à 21:32 (CEST)

Ah ok, en fait le modèle donne déjà, après l'image (ou avant, c'est justement la question), le code sélectionné et la signification, donc le texte alternatif serait une information redondante (comme l'est déjà l'image, en fait, mais elle est jolie). — Delhovlyn » (discuter) 9 mai 2009 à 21:36 (CEST)

(Relativement) urgent

Bonjour ! Comment faire pour insérer alt=description d'une illustration dans une galerie de photos ? J'ai le problème dans Cantine. Merci pour vos réponses très attendues ! --Égoïté (d) 4 mai 2009 à 11:06 (CEST)

Bonjour, ce n'est pas encore possible d'ajouter ce paramètre aux galeries et c'est bien dommage! --amicalement, Salix ( converser) 4 mai 2009 à 11:51 (CEST)

OK merci. Tu peux me prévenir quand ce sera possible ? Bien à toi, --Égoïté (d) 4 mai 2009 à 14:43 (CEST)

Merci pour ton important travail sur Cantine. L'idéal serait de demander aux développeurs de rendre cela possible. J'ai ouvert le bug bugzilla:18682. J'espère que mon anglais est compréhensible. Dodoïste ^{[ dring-dring ]} 4 mai 2009 à 22:51 (CEST)

Mise à jour WCAG2.0 des bonnes pratiques

J'ai fait une rapide mise à jour des bonnes pratiques pour tenir compte des nouvelles références WCAG2.0, en privilégiant le document des techniques WCAG2, plus pédagogique que la norme elle-même. Quelques nouvelles BP découleront de WCAG2, je tâcherai de les rédiger demain.

L'amusant, c'est de constater que l'impact des contributeurs est en fait beaucoup plus fort qu'on ne le voyait via WCAG1.0: la plupart des points sur lesquels leur travail conditionne l'accessibilité sont de niveau A, c'est à dire les exigences vitales... --Lgd (d) 9 mai 2009 à 17:09 (CEST)

{{Méta palette de navigation avec colonnes}}

<énorme soupir>

L'exemple parfait de ce qu'il ne faut pas faire (Vu l'auteur, ça me surprend pas): un tableau de mise en forme dénué de sens quand il est linéarisé.

Pour donner une illustration simple, le modèle « Fédération internationale de ski » donné dans la documentation a pour contenu linéarisé, l'équivalent de :

• Fédération internationale de ski
  • Ski alpin
  • Ski de fond
  • Saut à ski
  • Ski acrobatique
  • Snowboard
  • Combiné nordique
  • Ski de vitesse
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
    • etc.

Alors qu'il devrait donner, s'il était correctement fait:

• Fédération internationale de ski
  • Ski alpin
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
  • Ski de fond
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
  • Saut à ski
    • Coupe du Monde
    • Championnat du Monde
    • Jeux olympiques
  • etc.

Si quelqu'un a le courage de reprendre ce modèle pour réunir dans la même cellule le titre de colonne et son contenu  ? --Lgd (d) 16 mai 2009 à 10:15 (CEST)

Accessibilité des mobiles et homonymies

Bonjour, en testant une page d'homonymie avec la version de Wikipédia pour mobiles je m'aperçois que dans les listes d'homonymes, le modèle {{page h}}, pourtant très pratique, n'apparait pas et escamote le terme. Par exemple dans Martin les lignes restent vides [1]. Y a-t-il une solution pour résoudre ce problème, tout en gardant l'indication de sous-homonymie ? --amicalement, Salix ( converser) 28 mai 2009 à 23:56 (CEST)

Tous les modèles ne sont pas pris en charge. Cela ne relève pas de fr.wikipédia, cette version pour mobile est bien inférieure à une dizaine d'autres facilement trouvables via un moteur de recherche. Voir par exmeple http://wikipedia.7val.com/wiki/Martin http://wikipedia.7val.com/wiki/OMS_(homonymie) et http://wikipedia.7val.com/wiki/OMS_(homonymie) qui affichent très bien les homonymies. Dodoïste ^{[ dring-dring ]} 29 mai 2009 à 00:49 (CEST)

Tant mieux! Merci. --amicalement, Salix ( converser) 29 mai 2009 à 10:22 (CEST)

Pour compléter Dodoïste: http://fr.mobile.wikipedia.org/ utilise une technologie (WAP1.0) aujourd'hui périmée parce qu'elle était une impasse technologique , à la différence de diverses autres versions pour mobiles. C'est plus une curiosité historique qu'autre chose. en supprimer la mention sur la page d'accueil ne serait pas un mal. --Lgd (d) 30 mai 2009 à 10:52 (CEST)

Je plussoie. --amicalement, Salix ( converser) 30 mai 2009 à 10:58 (CEST)

Tu fais la demande argumentée sur Discussion:Accueil, je fais l'admin de passage qui applique, et on explique après face à la levée de boucliers ? Ou bien, on laisse en l'état ? --Lgd (d) 30 mai 2009 à 12:13 (CEST)

Solution plus ciblée : t'adresser à celui qui est l'auteur de ce premier ajout sur {{Accueil/titre}} et voir avec lui s'il insiste encore pour le trouver génial, idem avec l'initiateur du projet, c'est à dire Antaya d'après cette discussion --amicalement, Salix ( converser) 30 mai 2009 à 14:55 (CEST)

On supprime la version actuelle parce que nulle dans tous les sens du terme. Cependant, n'y a-t-il pas une autre version plus accessible pour la remplacer ? — Steƒ ^{๏̯͡๏﴿} 30 mai 2009 à 15:02 (CEST)

Il y a le lien proposé par Dodoïste ci-dessus et (si tu y comprends qq chose) la page Wikipédia:Mobile, page à actualiser ? Au fait qui sait ce qu'est devenu le site fr.m.wikipedia.org qui est cité sur la page Wikipédia:Atelier accessibilité/Taxobox et infobox ?--amicalement, Salix ( converser) 30 mai 2009 à 15:17 (CEST)

Pourquoi pas en mettre un autre, en effet. Toutefois :

• Ce n'est pas un priorité absolue car les utilisateurs de versions pour mobiles ne passent pas par la page d'accueil pour accéder à une version mobile.
• Quelle version choisir ? Choisir celle proposée par la fondation est le plus simple, mais si on choisit un autre, la communauté risque d'avoir du mal à se mettre d'accord.

Le choix le plus simple serait peut-être de remplacer par Wikipédia:Mobile, qui contient la liste des accès mobiles (ou au moins des principaux). J'ajoute qu'il serait à mon avis plus judicieux de remplacer par Wikipédia:Publications, liste plus générale des autres publications de WP (dont les versions pour mobiles, et bien d'autres). de:Wikipedia:Hauptseite a retenu cette solution. Dodoïste ^{[ dring-dring ]} 30 mai 2009 à 15:40 (CEST)

Le lien de Dodoïste ne doit pas appartenir à la fondation, à la différence de fr.mobile.wikipedia.org, raison pour laquelle, sans doute, le lien avait été retenu pour l'accueil.

Mais je suis d'accord pour un lien général vers Wikipédia:Publications. Cependant, il va falloir l'avis d'autres contributeurs! — Steƒ ^{๏̯͡๏﴿} 30 mai 2009 à 15:42 (CEST)

Pfiou (pour être poli).

Ni la fondation ni les WP nationales ne sont à même de gérer actuelement une déclinaison pour mobile. Sachant que c'est un excercice déjà très difficile pour des projets disons plus construits, il faudrait juste arrêter de rêver: wikipédia n'a pas de version mobile, point.

Quoi s'il en soit, ce n'est pas un problème d'accessibilité. C'est une discussion intéressante, mais à poursuivre ailleurs. --Lgd (d) 30 mai 2009 à 15:51 (CEST)

As-tu lu le premier mot de Wikipédia:Publications ? Mettre ce lien n'est pas une mauvaise idée. --amicalement, Salix ( converser) 30 mai 2009 à 18:46 (CEST)

C'est justement parce que je l'ai lu que je suggère de mettre fin à une mascarade. Wikipédia:Publications confond deux problématiques qui sont celles de l'interopérabilité et celle de l'accessibilité, et la fondation se ridiculise en prétendant que la version WAP1.0 est un accès pour mobile. --Lgd (d) 30 mai 2009 à 18:55 (CEST)

Pourrais-tu commencer par clarifier l'article Accessibilité qui est franchement confus ? A commencer par l'intro. --amicalement, Salix ( converser) 30 mai 2009 à 19:07 (CEST)

À ce que j'ai compris, il y a une grande différence entre accessibilité et accessibilité du Web. Wikipédia:Publications parle d'accessibilité au sens large, tout comme la majeure partie de Wikipédia:Accessibilité. Donc cela ne concerne toujours pas cet atelier. Amicalement, Dodoïste ^{[ dring-dring ]} 30 mai 2009 à 19:14 (CEST)

Problème d'infobox

Bonjour,

Uune contributrice semble avoir, pour toutes les infobox V2, l'affichage des deux cartes physique et administrative en simultané; elle utilise IE et tourne sur Vista. Y a t'il une explication? Davantage d'information là: Discussion_Projet:Italie#Une_infobox_V2,_une_!. Message posté également sur Discussion Projet:Modèle#Problème d'infobox Merci de votre attention Otourly (d) 31 mai 2009 à 12:40 (CEST)

A mon avis, ça n'est pas un problème d'accessibilité, mais un problème de syntaxe, pour ça le projet modèle ou Wikipédia:Questions techniques. Amicalement — Steƒ ^{๏̯͡๏﴿} 31 mai 2009 à 13:18 (CEST)

A ton avis je rajoute le message sur la guilde des guildes? Ou c'est suffisant Buzz Stef48  ? Otourly (d) 31 mai 2009 à 13:37 (CEST)

On ne se moque pas !

Plus sérieusement. Je n'en sais rien ! J'ai essayé sous FF et IE, je n'ai aucun bogue, j'attends donc la réponse de Mandarine, pour voir. Peut-être y a-t-il un conflit avec les gadgets … Bref, si je ne trouve pas, je poserai la question sur la Guilde, je te tiens au courant. Amicalement — Steƒ ^{๏̯͡๏﴿} 31 mai 2009 à 13:49 (CEST)

hé hé ! ça me rappelle certaine lointaine bataille sur la GdG  ! bon va falloir se pencher sur la question des « préférences » puisque le pb venait de là et qu'elles n'en posent d'ailleurs pas que pour ça (hotcat aussi) ! merci à tous les deux ! pitibizou ! Mandarine ^{1 pépin ?} 31 mai 2009 à 23:51 (CEST)

Ah ui, malheureusement, les contributeurs de la Guilde changent, les anciens n'y sont plus, beaucoup de nouveaux, moins d'humour qu'auparavant.

Beh j'ai pris en main sur la page de discussion de Mandarine. C'est encore un gadget en conflit avec un autre ! — Steƒ ^{๏̯͡๏﴿} 1 juin 2009 à 00:57 (CEST)

Si l'exemple vous revient en mémoire: une timeline repoussée dans un modèle, c'était où déjà ?

hello,

Dans le cadre d'une série d'articles (ailleurs) sur l'accessibilité de Wikipédia, un truc m'agace: je n'arrive pas à remettre la main sur les quelques exemples de modèles utilisés pour retirer d'un article le code imbittable d'une timeline et l'épargner aux contributeurs non spécialisés dans cette extension. Dans mes obscurs souvenirs, ça devait se passer du côté du beau Danube Bleu. Ça vous dit quelque-chose ? Milles mercis si vous avez le lien sous la main . Il y a aussi une discussion sur le Bistro à ce propos que je ne retrouve pas... --Lgd (d) 31 mai 2009 à 15:18 (CEST)

Modèle:Parcours du Danube et pays riverains ? 19 janvier 2009 : Simplicité, modèles et références ? Amicalement, Dodoïste ^{[ dring-dring ]} 31 mai 2009 à 15:31 (CEST) Ah j'oubliais : vive les moteurs de recherche externes et site:fr.wikipedia.org

génial, merci (Là, je cherche les liens idoines dans le bugzilla, et c'est beaucoup beaucoup plus ch...) --Lgd (d) 31 mai 2009 à 17:33 (CEST)

Bon puisque j'abuse, je continue

Toujours dans l'optique d'une série d'articles qui paraîtra dans le courant du mois à propos de l'accessibilité de Wikipédia, je soumets à votre sagacité cette question: à quoi servent les modèles dans l'espace principal ? Auriez-vous quelques idées pour formuler une synthèse de leurs usages ? (Les usages fonctionnels: on s'adresse à des chefs de projets, par exemple, qui n'ont évidemment jamais mis les pieds ici) --Lgd (d) 31 mai 2009 à 17:46 (CEST)

Tu veux dire ceux qui simplifient la vie à ceux qui ne connaissent pas la syntaxe ? — Steƒ ^{๏̯͡๏﴿} 31 mai 2009 à 19:48 (CEST)

Oui, mais les autres ? Ou sinon ?

Je crois qu'il te faudra alors l'avis d'autres contributeurs. Parce que pour moi, les modèles ont pour principal but d'aider les contributeurs n'étant pas familiers avec la WikiSyntaxe ou avec le HTML simple. Ils facilitent ainsi la modification d'article : à la place de se taper un tableau à refaire, ils n'ont qu'à insérer {{Infobox Cinéma (personnalité)}} (c'est un exemple). Ceci a par la suite la conséquence d'uniformiser tous les articles d'un même thème. Il sera plus aisé de modifier un modèle que de modifier des milliers d'articles, qui auront la même apparence. Ils aident le respect des conventions, en quelques sortes.

Enfin, peut-être que j'oublie quelques buts des modèles, mais selon moi, ça reste ça un modèle. Amicalement — Steƒ ^{๏̯͡๏﴿} 31 mai 2009 à 20:21 (CEST)

Il y a aussi tous ces petits modèles qui permettent d'avoir des caractères ou des typos absentes ou difficiles à fomer à partir du clavier standard et ceux qui mettent en forme des ensembles plus complèxes respectant des conventions d'écriture comme le modèle {{ouvrage}}. --amicalement, Salix ( converser) 4 juin 2009 à 23:02 (CEST)

Image

Bonjour,

Je compte refaire et compléter les images pour illustrer les articles sur le jeu de la vie (création de SVG XML). Comment optimiser l’accessibilité ? Quelle couleurs choisir, comment mesurer le contraste, etc. ? Je pense faire plutôt que  ? Et pour les alternatives textuelles, comment décrire ces images ? Pour les animations (GIF puisque l’on a pas le choix apparemment), quel temps choisir ? Etc. Cdlt, VIGNERON * ^discut. 5 juin 2009 à 12:15 (CEST)

Quelques recommandations après une rapide lecture de l'article :

1. Ne pas utiliser d'expression désignant une image par sa position à l'affichage, comme « C'est le cas de la cellule verte dans la configuration de gauche ». Remplacer par :
   « C'est le cas de la cellule verte dans cette configuration:  »
2. Compléter la mention de la couleur par un biais indépendant de celle-ci quand elle véhicule une information nécessaire à la compréhension : « C'est le cas de la cellule verte (au centre) ». (Remarque: cet exemple n'est pas contradictoire avec la recommandation précédente, qui ne porte que sur les éléments placés via CSS, non sur le contenu de ceux-ci). Une autre solution sera d'utiliser des formes différentes en complément des couleurs (le carré vert, le triangle rouge, le rond jaune).
3. Rédiger des alternatives descriptives pour les images insérées dans les phrases, de manière à ce qu'elles s'insèrent au mieux dans le sens de celle-ci:
   « Ainsi, la configuration [[Image:Gol-blinker1.png|alt=3 cellules alignées horizontalement]] donne au tour suivant la configuration [[Image:Gol-blinker2.png|alt=3 cellules alignées verticalement]] qui redonne ensuite la première.. »
4. Les animations: s'assurer que l'alternative décrit de manière suffisante le déroulement de l'animation. Par exemple, pour le planeur :
   [[Image:Gol-glider.gif|thumb|[[Planeur (jeu de la vie)|Planeur]].|alt=Le Planeur est une figure de 5 cellules qui retrouve sa position initiale en x étapes"]].
5. Les contrastes: s'assurer que le ratio de contraste est suffisant (idéalement 4.5:1) pour le quadrillage et pour les cellules. Dans tes deux exemples comme dans l'article, il est suffisant pour les cellules, mais très insuffisant pour le quadrillage (1.8:1). Utiliser au moins un gris #808080 (3.9:1) ou mieux #707070 (ratio de 5:1). Cela dit, pour les couleurs des cellules, je ne vois pas l'intérêt de changer les couleurs actuelles de l'article.
6. Signaler les changements de langue manquants (Dans les notes et références, les liens externes, la bibliographie)

Enfin, concernant le rythme des animations: indépendamment des questions d'accessibilité, le rythme actuel est à l'évidence trop rapide pour que n'importe quel lecteur perçoive suffisamment les étapes (voir l'exemple du planeur). --Lgd (d) 6 juin 2009 à 10:55 (CEST)

Question sur le modèle lang

Dans Discussion Projet:Musique classique#Usage de Modèle:lang, Vol de nuit (d · c · b) prétend que {{lang}} pose des problèmes d'accessibilité. Quelqu'un pourrait-il lui répondre ? TED 5 juin 2009 à 15:17 (CEST)

Je demande confirmation que ce modèle n'en pose pas, plutôt. Merci d'avance. Vol de nuit ^✈ 5 juin 2009 à 15:29 (CEST)

Quels seraient les problèmes posés ? Je n’en vois aucun, au pire la balise lang est ignoré mais cela ne pose pas de problèmes (il existe des problèmes d’utilisations éventuellement mais c’est autre chose). Cdlt, VIGNERON * ^discut. 5 juin 2009 à 15:32 (CEST)

Je me demande si Vol de nuit (d · c · b) ne confondrais pas {{lang}} et {{Titre incorrect}} dont il a été question aussi dans la discussion à laquelle il se réfère. TED 5 juin 2009 à 15:40 (CEST)

Ah oui, titre incorrect a posé de gros problèmes d’accessibilité (à cause du JavaScript) mais depuis le mot magique DISPLAYTITLE, je crois que c’est réglé (au moins partiellement). Pour Lang, je ne vois définitivement pas quel pourrait être le problème d’accessibilité (mais je suis pas hyper spécialiste non plus). Cdlt, VIGNERON * ^discut. 5 juin 2009 à 16:07 (CEST)

Finalement, il semble que cela soit un bug des popups qui est en cause, et pas l'accessibilité du modèle lang !

Vigneron, tu en sais plus sur {{Titre}} et DISPLAYTITLE ? (ou quelqu'un d'autre) ? TED 5 juin 2009 à 18:47 (CEST)

{{Article détaillé}}, {{Article connexe}} le retour

Pour reprendre avec cette précédente section : Le problème avec ces modèles est que le nom de l'image est lue par les lecteurs d'écrans, c'est ça ? Genre "Image:Searchtool.svg" ? Et que l'image soit cliquable pose plus de problèmes qu'autre chose, et est inutile ?

Si j'ai à peu près juste, je veux bien demander l'approbation de la communauté pour la modification de Lgd, sur le bistro. Amicalement, Dodoïste ^{[ dring-dring ]} 5 juin 2009 à 16:00 (CEST)

• Pour certains de ces modèles, l'alternative textuelle de ces icônes n'ayant pas été renseignée, mediawiki produit une alternative nulle. Comme il s'agit d'images-liens, les aides techniques ne peuvent pas « taire » ces images, et sont contraintes à restituer ce qu'elles peuvent : un lecteur d'écran, par exemple, lira en effet fréquemment le nom du fichier image, ce qui est incompréhensible.
• Pour d'autres, l'alternative a fait l'objet d'une tentative de contenu (« Icône de détail »). Mais ces icônes ne renvoient à aucune page utile (elles ne renvoient qu'à leur propre page d'image), renseigner ainsi les alternatives ne présente aucun intérêt et ne fait que rendre plus confus le contenu.

Il y a donc deux solutions possibles :

• soit passer ces icônes en background CSS, ce qui est la démarche la plus logique
• soit leur ajouter un paramètre link= vide (pas d'URL après le signe =), ce qui en fait des images statiques (au lieu d'images-liens). Par exemple: . Dans ce cas, l'alternative vide fonctionnera normalement. Cette solution est cependant beaucoup moins robuste, car rien ne garantit que mediawiki continuera à l'avenir à produire une image simple (sans lien) en présence d'un paramètre link= vide.

Dans les deux cas, le lien disparaît. --Lgd (d) 6 juin 2009 à 11:22 (CEST)

Merci Lgd. C'est sur le Bistro de demain. N'hésite pas à modifier le message. ;-) Dodoïste ^{[ dring-dring ]} 6 juin 2009 à 15:34 (CEST)

J'ajoute : je me demande si il ne serait pas judicieux de faire pareil pour les modèles d'homonymies. « Aide:Homonymie » est consultée plus de 4'000 fois par jour, je pense que c'est parceque le lecteur voir un lien, et clique simplement pour voir où il mène. Ou alors il clique par erreur. Mais je doute que ce soit par intérêt, car sinon l'article « homonymie » serait bien plus consulté que ses 180 consultation journalières. Dodoïste ^{[ dring-dring ]} 6 juin 2009 à 15:46 (CEST)

Merci pour ton message sur le Bistro.

Il vaut mieux aborder la question des modèles d'homonymie dans un second temps : l'icône faisant lien vers Aide:Homonymie est en effet une fausse bonne idée car elle égare le lecteur, mais la proposition de suppression du lien va donner lieu aux débats habituels opposant ceux qui privilégient le lecteur et ceux qui privilégient le rédacteur. Sans compter le retour de la question du lien sur un point d'interrogation. --Lgd (d) 6 juin 2009 à 16:07 (CEST)

En effet, mieux vaut garder cela pour plus tard. Il y a encore beaucoup de modèles qui contiennent un point d'interrogation liant à une page d'aide, comme {{Japonais}}. Il y a également plusieurs message systèmes, comme ceux qui s'affichent sur les titres des pages d'historique : « Historique des versions de « Discussion Wikipédia:Atelier accessibilité » ^(?) » Dodoïste ^{[ dring-dring ]} 6 juin 2009 à 16:23 (CEST)

Lorsque sera venu le moment de faire la modif, je suggère d'en profiter pour uniformiser la taille des icônes à 20px, comme les images d'homonymies. Je trouve que 15px est trop peu pour {{Article détaillé}}, je distingue mal la loupe pour ma part. Dodoïste ^{[ dring-dring ]} 7 juin 2009 à 02:38 (CEST)

Jérôme signale sur le Bistro l'existence de Wikipédia:Prise de décision/Unification des modèles : article détaillé et Loupe. La proposition retenue est la n°5, qui ne pose pas de problèmes d'accessibilité. L'image contient un |=link vers l'articel détaillé. Mais je ne suis pas favorable à cette idée, car le lien est du coup redondant, et on ne s'attend pas à avoir un tel lien sur cette image. Dodoïste ^{[ dring-dring ]} 7 juin 2009 à 11:10 (CEST)

On met un lien sur une icône quand cela permet d'économiser de la place et du temps pour le lecteur. On met des liens redondants sur des successions d'éléments quand on prend le lecteur pour un abruti (les sites des grands quotidiens sont un bon exemple, avec leurs liens sur le titre de l'actu, sur le paragraphe de l'actu, sur l'image de l'actu). Groumpf... --Lgd (d) 7 juin 2009 à 11:28 (CEST)

Fil d'Ariane

Avertissement: je sais que l'ergonomie des pages de l'Atelier et pour certaines leur contenu sont entièrement à revoir. Disons que ceci est, sans illusion, simplement un test de portée plus générale.

Wikipédia a une petite particularité intéressante: c'est un site sans Fil d'Ariane.

Cette absence est totalement justifiée à l'heure actuelle dans les articles, l'architecture étant plate (tous les fils d'Ariane des articles se réduiraient à « Vous êtes ici: Accueil > Titre de l'article », ce qui n'a aucun intérêt). A l'avenir, si les catégories étaient enfin maîtrisées, il y aurait peut-être quelque-chose à faire en la matière, mais ce n'est pas le sujet de mon message.

En effet, autant le fil d'Ariane serait actuellement inutile dans les articles, autant il pourrait être pertinent dans les projets, l'aide, les ateliers, les pages de procédures, etc.

Je vois d'ici votre première objection: il fait doublon avec la ligne caractéristique des sous-pages. Oui, mais non. Disons que c'est une piste pour améliorer celle-ci, ou simplement la structurer sous une forme plus évidente pour le lecteur.

Je fais donc un test sauvage de fil d'ariane dans l'Atelier, histoire de susciter et de recueillir (j'espère) des avis, des suggestions, des critiques, etc.

(le fil d'Ariane, c'est le truc tout en haut de cette page qui commence par « Vous êtes ici »)

A vous lire,--Lgd (d) 6 juin 2009 à 19:12 (CEST)

Je trouve ça très bien. Çe serait surtout bien dans les pages d'aide à mon avis.

Mais je comprends pas comment on accède à cet atelier depuis Aide:Sommaire ? Que vient faire ce lien dans le fil d'Ariane ? Dodoïste ^{[ dring-dring ]} 7 juin 2009 à 00:17 (CEST)

Oui, pourquoi ne passe-t-on pas par la case Aide:Ateliers qui serait plus logique? Personnellemetn j'aime bien les liens logiques, comme par exemple celui généré par {{Catégorie botanique}}. Sinon l'idée de base est bonne. (En passant pourquoi sur la page Projet:Accueil y a-t-il un lien accessibilité qui pointe vers l'article et un Projet:Articles audio qui travaille dans son coin ?) --amicalement, Salix ( converser) 7 juin 2009 à 01:10 (CEST)

Ce n'était pas un loupé, mais un lapsus révélateur:

• la case Aide:Ateliers n'a qu'un intérêt anecdotique pour le visiteur. Les ateliers ne sont pas mentionnés dans Aide:Sommaire pour des raisons historiques essentiellement.
• Il y a des choses à repenser, mais c'est connu de longue date, dans le fouilli des pages d'aides, des ateliers, des projets, etc. Pour les mettre au service des contributeurs, en leur dessinant des chemins faciles. C'est à dire une architecture des contenus maîtrisée au lieu du bordel ambiant. Par exemple en supprimant la distinction ateliers/projets. Ou en la redéfinissant de manière cohérente.

Merci pour vos premiers retours. Il y a matière à creuser. --Lgd (d) 7 juin 2009 à 11:23 (CEST)

Très bonne idée ce fil. Je me demandais si il n'était pas possible de faire apparaitre, je ne sais pas sous quelle forme, le fil aval et pas seulement le fil amont (c'est à dire toutes les sous-pages accessibles à partir de la page courante) ? — Droop ^[blabla] 7 juin 2009 à 12:15 (CEST)

Il y a MediaWiki:Gadget-SousPages et Utilisateur:Lgd_test#sous_pages pour les sous-pages. C'est à creuser aussi, vu la tournure que prend l'utilisation des sous-pages, en effet. On pourrait envisager quelque-chose de générique, plutôt qu'un modèle spécifique comme celui des sous-pages de discussion. Une chose à la fois. --Lgd (d) 7 juin 2009 à 12:24 (CEST)

Question de novice : comment on installe MediaWiki:Gadget-SousPages ? — Droop ^[blabla] 7 juin 2009 à 14:12 (CEST)

En cochant la case qui va bien dans l'onglet « gadgets » de tes préférences, oeuf course. --Lgd (d) 7 juin 2009 à 15:16 (CEST)

Ah.. euh... ben oui ! Merci ! — Droop ^[blabla] 7 juin 2009 à 16:23 (CEST)

ça me démange fortement de proposer le même test de fil d'Ariane au projet aide. Salix ? Tu expliqueux ? Ou tu verrais ça comment ? Ce qui est intéressant lors de la mise en place d'un fil d'ariane, c'est ce que ça révèle sur les défauts de structure qu'on peut corriger : cela pourrait à la fois réveiller ce projet un peu léthargique ces derniers temps et mettre le doigt sur quelques soucis. --Lgd (d) 7 juin 2009 à 12:39 (CEST)

sinon, j'ai replacé Aide:Sommaire par Aide:Ateliers dans le fil d'Ariane, pour qu'on voit. Comme ça, ça a l'air très séduisant, mais je sais qu'il y a un souci derrière, dans l'articulation entre Aide:Sommaire et les ateliers et projets spécifiques. --Lgd (d) 7 juin 2009 à 12:46 (CEST)

Je n'ai pas le temps maintenant de réfléchir à ça mais il y a une chose que j'ai remarquée depuis longtemps c'est qu'on n'offre pas suffisemment tôt, et clairement, aux nouveaux contributeurs de rejoindre les projets ou ateliers et donc qu'il ne faut pas dans ces conditions s'étonner de voir certains contribuer en électrons libres et se heurter ensuite à la réprobation des groupes de travail. Je sais aussi qu'il me faut toujours un temps fou pour retrouver la liste des ateliers. --amicalement, Salix ( converser) 7 juin 2009 à 13:05 (CEST)

On a le temps, pas de souci. Mais ce que tu dis renvoit clairement à des problèmes d'architecture des contenus (côté organisation des pages en Wikipédia, projets, ateliers, aide etc.), et à des critères d'accessibilité de la récente norme WCAG2.0 (le fil d'Ariane en résulte) que j'aime beaucoup: « l'utilisateur dispose d'informations pour se situer dans un ensemble de pages Web », «  une page Web peut être située par plus d'un moyen dans un ensemble de pages Web sauf si cette page est le résultat ou une étape d'un processus » et « une aide contextuelle est disponible ». Mariez le tout avec le savoir-faire nécessaire, et vous arriver à des choses simples et immédiatement applicables pour organiser le cheminement dans les pages hors articles. L'utilisateur qui ne rencontre pas le bon atelier ou projet est face à un problème d'accessibilité, pour lequel il existe des solutions techniques et des méthodes d'évaluations. --Lgd (d) 7 juin 2009 à 13:21 (CEST)

Tiens, dans la série tests, ce serait assez parlant sur le Bistro avec par exemple:

Vous êtes ici: [[Wikipédia:Accueil principal|Accueil]] > [[Wikipédia:Accueil|Contribuer à Wikipédia]] > [[Wikipédia:Avenue des Cafés et Bistros|Cafés et Bistros]] > [[Wikipédia:Avenue des Cafés et Bistros|Le Bistro]] > {{SUBPAGENAME}}

(L'exemple est pour une page de journée du Bistro, évidemment)--Lgd (d) 8 juin 2009 à 10:28 (CEST)

Projet audio

J'ouvre un nouveau sujet pour répondre à la question incidente de Salix dans la section précédente:

En passant pourquoi sur la page Projet:Accueil y a-t-il un lien accessibilité qui pointe vers l'article et un Projet:Articles audio qui travaille dans son coin ?

... Parce qu'historiquement, ce projet était sans rapport avec l'accessibilité (Et aussi plus bêtement à cause de la séparation formelle entre projets et ateliers, l'atelier accessibilité n'était donc pas mentionnée dans cette page, ce que je viens de corriger). Les versions audios ont longtemps été considérées comme des gadgets du point de vue accessibilité. WCAG2.0 change en partie la donne en les prenant en compte au niveau AAA, c'est à dire au niveau d'optimisation qui n'est pas un objectif prioritaire pour Wikipédia mais qui ne peut pas faire de mal. Il faudrait donc rapprocher les deux projets, en effet. --Lgd (d) 8 juin 2009 à 10:46 (CEST)

Justement. Il y a en haut des articles audio une icône donnant accès à la version audio de l'article. Cette présentation est-elle convaincante ? Le Modèle:Article audio donne une alternative textuelle sur l'icône (à l'aide du modèle:Icône de titre). Donc à priori c'est déjà pas mal. Mais ce modèle est une vraie usine à gaz, autant dire que je n'ai pas réussi à comprendre son fonctionnement en entier, et des modèles comme ça me donnent vraiment envie de m'intéresser à autre chose... Dodoïste ^{[ dring-dring ]} 8 juin 2009 à 11:33 (CEST)

Premier jet rapide :

• Pour l'icône: virer le « Cliquez pour... » au profit d'un plus utile « Ecouter en ligne la version audio de cet article au format Ogg Vorbis » (« écouter en ligne » parce que ce n'est pas un lien de téléchargement du fichier audio, mais si vous avez mieux ?). Sinon, le lien est en effet assez bien placé.
• Virer le modèle de bas de page quand l'icône est affichée (modification du JS, je suppose à vue de nez), et s'assurer que toutes les informations (version, aide, date) sont bien présente sur la page cible du lien icône, ça désemcombrera les bas d'articles.
• Revoir le code du modèle en bas de page qui comporte des <small><small><small> qui ne peuvent qu'éveiller l'instinct dubitatif du premier intégrateur venu, et sans doute aussi des liens peu explicites ainsi que des icônes manquant de link habiles.
• Peut-être changer l'icône de titre qui fait plus pâté d'encre qu'autre chose, au moins pour moi avec ma vue très basse

Sinon, dans ma mémoire, il y avait eu deux initiatives successives: le projet audio proprement dit (des gens enregistraient une lecture humaine de l'article) et un projet plus récent bricolé par je ne sais plus qui, qui recourait à une synthèse vocale au résultat dramatique. Il faudrait sans doute aussi s'intéresser à ce dernier, pour évacuer les derniers indices encore présents sur les diverses scènes du crime (des AdQ uniquement, je crois).

--Lgd (d) 8 juin 2009 à 11:46 (CEST)

Second jet:

• définir une guideline pour lecteur et/ou un cahier des charges pour système de synthèse vocale explicitant ce qui doit être lu et comment (quid des tableaux, etc.).
• se rapprocher des gens qui font des livres audios, l'un d'entre eux faisait de l'entrisme de bon aloi il y a quelques mois dans les liens externes.

--Lgd (d) 8 juin 2009 à 11:55 (CEST)

Deux questions

Bonjour, deux petites question :

• Est-il déconseillé de mettre des modèles dans les titres de section ? (en l'occurrence, sur ce diff). Je pense que oui, mais il n'y en a pas mention dans Aide:Syntaxe#Créer une section ou Aide:Comment rédiger un bon article#Titres de section (question sous-jacente : serait-il possible de rajouter une ligne à ce sujet dans ces pages, histoire d'avoir une référence).
• Quelles sont les limites d'utilisation de {{Nombre}} ? J'ai vu passer des modifs avec des {{nombre|40|personnes}}, {{nombre|20000|exemplaires}} ou {{nombre|4|joueurs}} qui m'ont semblé un peu exagérées, non ?

Merci d'avance, Jean-Fred (d) 7 juin 2009 à 00:04 (CEST)

1. la présence de modèles dans les titres de section n'est pas un problème d'accessibilité. Cela dit, le bon sens conduit à dire que l'usage des modèles ou de liens dans ces titres doit être limité au strict nécessaire :
   • l'url de la section (lien interne vers celle-ci) devient rapidement imbittable
   • l'usage de modèle typographiques pour des raisons souvent personnelles, et les désaccords qui s'ensuivent, créent des conflits à très faible valeur ajoutée (si tu préfères: il est inutile de chercher les soucis pour des broutilles).
   • surtout, il y a très rarement des raisons indiscutables d'utiliser un modèle dans le libellé d'un titre.
2. {{nombre}} ne concerne pas plus l'accessibilité. Cela dit, son usage peut dériver et fait partie de ceux qui posent une question difficile: certains contributeurs sont plus soucieux de précision typographique (à la limite de la préciosité parfois) et d'autres sont plus attentifs à conserver des articles facilement éditables par tout un chacun, sans connaissance particulière des modèles typographiques. L'édition d'articles peut devenir très dissuasive quand il est truffé de modèles, et que le souci d'un certain formalisme typographique favorise la multiplication de modèles qu'on peut considérer comme superflus. La question de fond à se poser au cas par cas est, AMHA: est-ce que cette contrainte typographique issue de l'imprimée est pertinente sur le media Web ? C'est à dire: est-ce qu'elle véhicule une information nécessaire à la juste compréhension du contenu ? Quand ce n'est pas le cas, on peut s'interroger à juste titre sur la pertinence d'une démarche qui plaque aveuglément les règles historiques et typographiques de l'imprimé sur un média où cela reste à inventer. J'avoue ne pas être certain que la séparation des chiffres ou du nombre et sa pseudo-unité par des espaces insécables véhicule dans tous les cas une information tellement fascinante qu'elle nécessite tant de bruit. Sans doute pourrait-on écrire quelque-part, dans une page d'aide ou de recommandation, que « joueurs » n'est pas une unité, et que, non, on ne fait pas chier le monde avec {{nombre|4|joueurs}}, même si dans un autre cadre, sur un site que j'édite, j'écrirai en effet 4 joueurs si j'en ai le temps. --Lgd (d) 7 juin 2009 à 11:16 (CEST)

Ok, j'étais donc doublement à côté de la plaque en pensant être au bon endroit . Mais ça répond très bien à mes questions. (En gros, je vais pas réverter en masse ; mais je vais pas verser dans ce fanatisme typographique.) Merci pour les réponses, Jean-Fred (d) 7 juin 2009 à 14:14 (CEST)

Article détaillé, Article connexe, fin

Bon, on a un consensus parfait parmi 24 personnes. \o/ On met l'idée en application ? Dodoïste ^{[ dring-dring ]} 12 juin 2009 à 01:13 (CEST)

Idem pour (pdf) ? — Droop ^[blabla] 12 juin 2009 à 07:24 (CEST)

Pour (pdf) il faut plutôt demander sur WP:RBOT, non ? Dodoïste ^{[ dring-dring ]} 12 juin 2009 à 13:04 (CEST)

J'oubliais : il faut qu'on crée une page où mentionner les icônes, leur licence et leur auteur. Dans quelle espace de nom la créer ? Wikipédia ? Et quelle doit être la visibilité de cette page ? Je n'ai pas vu ce genre de pratique jusque-là, je n'ai donc pas de point de repère. Mais l'idée est excellente. Dodoïste ^{[ dring-dring ]} 12 juin 2009 à 13:04 (CEST)

Pour en revenir aux pdf, je souhaiterai que cela soit quelqu'un d'un peu plus calé que moi qui fasse cette demande auprès de WP:RBOT. Il faut déterminer précisément le texte que l'on souhaite ajouter (pdf) ou (PDF) ? Et peut être d'autres choses auxquelles je ne pense pas... Sinon je souscris pleinement à l'idée d'une page de crédits des icônes, qui devrait être accessible depuis l'accueil ou même depuis n'importe quelle page via le menu de gauche ou du bas (la ligne sur laquelle est écrit "politique de confidentialité / A propos de Wikipédia / Avertissements" me paraitrait l'endroit idéal où ajouter "crédits des icônes" ou un truc du genre).— Droop ^[blabla] 12 juin 2009 à 19:22 (CEST)

• Article détaillé etc. : j'ai mis à jour les modèles et Common.css. Le temps que les navigateurs mettent à jour leur cache, il y aura des effets de bords (icônes en double ou absence d'image). Je mets un message sur le Bistro et je repasserais ce soir pour calmer les foules en colère.
• la page de crédits des icônes : oui, un lien Wikipédia:Crédits graphiques en pied de page ferait l'affaire.
• PDF : le seul ajout à faire est « (PDF) » dans le libellé du lien (le poids du document étant inconnu, il ne peut pas être indiqué).

--Lgd (d) 14 juin 2009 à 11:06 (CEST)

Je viens de faire une premier jet sur Wikipédia:Crédits graphiques. Tu pensais à quelque chose dans ce goût ? Dodoïste ^{[ dring-dring ]} 15 juin 2009 à 07:05 (CEST)

Ça me semble très bien. --Lgd (d) 15 juin 2009 à 07:32 (CEST)

Malvoyant

Bonjour. Utilisateur:Serge Lacotte a des problèmes de navigation sur WP et cherche un parrain. ouvez-vous l'aider ? Merci pour lui, --Égoïté (d) 12 juin 2009 à 15:59 (CEST)

Bonjour, Utilisateur:Serge Lacotte est déjà parrainé par Utilisateur:Cobber17 et aidé également un peu par moi au sein du projet Charente-Maritime. Il se débrouille d'ailleurs très bien pour un débutant. Il me parait néanmoins opportun d'être attentif à ses demandes particulières en matière d'accessibilité. Je vais lui signaler l'existance de cet atelier sur sa pdd. Cordialement, — Droop ^[blabla] 12 juin 2009 à 19:26 (CEST)

Icônes de bandeaux, le retour

Détrompez-vous, nous n'en avons pas fini avec les icônes de bandeaux .

Le candidat suivant sur la liste : {{Méta bandeau d'avertissement}}. D'autant que je viens de tomber sur cette demande de sapin de Noël aux effets potentiellement dévastateurs.

Sur le coup, je pense qu'un simple avertissement sur le Bistro au préalable suffira, non ? (Par contre, il faut que je prépare les styles) --Lgd (d) 14 juin 2009 à 11:43 (CEST)

Tu penses tout mettre en CSS ? ou corriger les liens vers les images ? Je peux eventuellement aider pour ce qui est de rajouter une description. bayo 14 juin 2009 à 12:42 (CEST)

A priori, ce que j'envisage :

Conserver la structure en tableau, inoffensive

Passer en CSS les icônes par défaut

Laisser en place le mécanisme permettant de spécifier une icône spécifique en image HTML, pour permettre aux contributeurs de continuer à créer des bandeaux librement. Ajouter une alternative textuelle ou corriger celles existantes si besoin.

Ne passer en CSS que celles des icônes spécifiques qui sont massivement utilisées

--Lgd (d) 15 juin 2009 à 07:35 (CEST)

Ca semble honnête :-) bayo 16 juin 2009 à 11:44 (CEST)

HiddenStructure

Cette classe CSS est utilisée actuellement dans 72 modèles (des infobox) et pose de sérieux problèmes : l'idée générale est qu'elle masque à l'affichage les lignes non utilisées de tableau générées par le modèle, alors que celui-ci ne devrait simplement pas les générer. Le résultat est un tableau dénué de sens dont de nombreuses lignes sont remplies par des codes de variables {{{foo}}}.

Petite astuce pour mettre en évidence le souci dans un article : encadrez l'appel du modèle avec

<div class="nohiddenStructure">...</div>

(exemple).

Le programme serait donc :

1. de corriger partout où cela est possible pour remplacer l'emploi de HiddenStructure par un meilleur usage de {{#if:}}
2. de tenter de faire évoluer les quelques usines à gaz du type {{Infobox Premier Ministre}} vers des modèles plus légers et plus pertinents. Ou, à défaut, de leur appliquer le traitement 1
3. et finalement de retirer cette classe de classe CSS (et de veiller à éviter son retour).

Des volontaires ? --Lgd (d) 15 juin 2009 à 07:48 (CEST)

Le gros problème c'est que cette classe simplifie énormément le code. J'entends par là que la retirer va donner un code complexe sur un code qui doit déjà l'être, c'est une tache ardue :-) bon courage. bayo 16 juin 2009 à 12:08 (CEST)

Hum... La complexité supplémentaire de {{#if:}} utilisé pour n'inclure les lignes que si les paramètres ont été remplis ne va tout de même pas très loin. Surtout quand la syntaxe du tableau utilise la syntaxe HTML et non la syntaxe wiki, ce qui rend le tout beaucoup plus lisible (Mais bon, ça c'est un autre combat ) --Lgd (d) 16 juin 2009 à 18:45 (CEST)

A propos de l'accessibilité de Wikipédia

Comme je l'ai commis, je le signale ici à vos esprits critiques : Wikipédia, un terrain d'expérience précieux pour l'accessibilité (1) : le CMS et son contexte est le premier d'une série de brefs articles analysant la question de l'accessibilité Wikipédia du point de vue « expert ». N'hésitez pas à signaler les bourdes --Lgd (d) 23 juin 2009 à 10:17 (CEST)

Bonjour, je ne prétendrais pas avoir tout compris mais ça a le mérite d'exposer les problèmes et de mettre Wikipédia en lumière de façon constructive --amicalement, Salix ( converser) 23 juin 2009 à 14:27 (CEST)

Très intéressant. :-) Le but est-il d'attirer quelques-uns de tes collègues ? Amicalement, Dodoïste ^{[ dring-dring ]} 25 juin 2009 à 01:06 (CEST)

Disons que cela fait un certain temps que je me sers d'exemples wikipédiens lors des formations en accessibilité, pour les aspects rédationnels ou à propos de l'impact du CMS. Le but du jeu est surtout de signaler WP comme « boîte de Pietri » intéressante à observer dans le petit monde des experts de ce domaine, car elle permet de faire avancer pas mal de réflexions méthodologiques. Mais si cela peut amener des collègues à intervenir concrètement ici, ce serait en effet très profitable. --Lgd (d) 26 juin 2009 à 10:37 (CEST)

Une excellente nouvelle et un nouveau modèle pour les titres d'articles

Bonjour,
Une modificationt très attendue de mediawiki permet à présent d'étendre l'utilisation du mot magique {{DISPLAYTITLE}} et en particulier de l'utiliser pour baliser le changement de langue d'un titre d'article.

Pour en faciliter l'usage, j'ai créé le modèle {{Langue du titre}}. N'hésitez pas à indiquer toutes les améliorations qui seraient nécessaires, ou à y procéder. Il y a aussi une version de travail dans Utilisateur:Lgd test/Langue du titre.

Remarques:

• Une petite pub sur le Bistro serait sans doute bénéfique, mais je préfère attendre vos retours sur le modèle et da documentation.
• Les questions sur les règles d'usage (noms propres, termes entrés dans la langue courante, termes techniques) sont susceptibles de titiller des amateurs de coupage de cheveux en quatre... Toutes les idées pour préciser ces règles sont donc les bienvenues
• Le recours à un bot sera à envisager pour traiter certaines catégories comme Catégorie:Expression latine utilisée en droit, sans compter les séries d'articles du Projet:Biologie et de ses petits (et grands) frères divers.

Cordialement, --Lgd (d) 26 juin 2009 à 07:17 (CEST)

Ceci est très intéressant, merci.

Tu évoquais sur le café des biologistes (je poursuis ici à ton invitation) la possibilité de mise en italiques. Même si j'y suis personnellement favorable ce n'est pas forcément un cheval de bataille pour moi, mais je pense que derrière cela se pose la question plus générale du respect des conventions typographiques de wikipédia dans les titres : est-ce qu'un titre est soumis à tout ou partie des conventions typographiques en application sur les articles (sans a priori sur la faisabilité technique) ? C'est une discussion qui va plus loin que l'accessibilité ou les taxons en latin, mais si la réponse est positive cela voudrait dire que pour les codes lang qui l'imposent (tous ?) les italiques pourraient être automatiques.

Cordialement, Hexasoft (discuter) 26 juin 2009 à 11:21 (CEST)

C'est justement là où je mentionnais mes doutes. Côté technique, c'est simple (pour des titres entiers, les titres composites mêlant plusieurs langues sont un souci plus délicat). Pour simple rappel :

• La mention de la langue, par définition sans impact sur le rendu, ne pose pas de soucis
• La mise en italique au cas par cas via des modèles adaptés à des conventions de titrage par projet non plus
• dans l'absolu, faire un modèle permettant de mettre de l'italique ou non au gré du rédacteur en cas de changement de langue n'est encore pas un souci.

Mais côté éditorial, la mise en italique est loin d'être évidente:

• Le fait qu'il s'agisse d'un titre dans la page ne le soustrait en rien à l'italique du point de vue des règles typographiques historiques. Pas d'échappatoire de ce côté si on prend en compte celles-ci.
• Les règles de mise en italique dont il s'agit, ou du moins celles qui servent de référence, sont celles de l'imprimé, dont les modes de lecture sont différents de celles à l'écran. Une bonne partie de ces règles typographiques sont par ailleurs liées à des contingences de l'histoire des techniques ou des champs de publication.
• Mais la transposition immédiate des règles de l'imprimé sur le Web, media différent, n'a pas une pertinence évidente : on s'en tient en effet en général sur le Web à des mises en formes qui soutiennent une information de manière utile pour le lecteur. L'interface Web étant beaucoup plus complexe que celui de l'imprimé, une certaine économie de moyens dans la signalétique s'impose si on ne veut pas noyer l'utilisateur dans la surcharge cognitive (vite dit, mal dit). Cela peut conduire à évacuer certaiens règles historiques de la typographie imprimée.
• Or, l'italique d'une partie du titre peut être pertinente : elle facilite la lecture d'un titre composite en aidant à y repérer visuellement ce qui est une anomalie de contenu constituant une rupture dans la lecture du segment de texte, c'est à dire un terme latin dans le titre. Mais l'italique de la totalité du titre l'est déjà moins : le titre tout entier en italique fait beaucoup moins ressortir une différence, parce que c'est tout le bloc de texte qui est concerné, et que l'oeil ne s'accroche qu'à une zone réduite quand il s'agit de percevoir une différence de type texte normal/texte italique (Il en est autrement quand les couleurs ou la police de caractère changent elles aussi, par exemple, ce qu'on fait souvent en design Web pour des blocs de citation, mais qui n'est pas applicable ici).
• Dans la catégorie des arguments qui ne sont pas de fond, mais à ne pas négliger: comme je l'ai expliqué sur le Café des Biologistes, l'association systématique du changement de langue et de l'italique me pose un souci de priorité: amener les contributeurs à indiquer les changement de langue a un bénéfice certain pour des lecteurs et un potentiel trollesque très faible. en revanche, associer cela à l'italique a un bénéfice nettement moins évident pour le lecteur et s'avère plutôt en l'état une source de conflits entre contributeurs qui risque de nuire à l'objectif précédent.

Autrement dit :

• autant la nécessité de la mention de langue est aisée à montrer, autant l'italique relève de choix beaucoup plus difficiles
• ne pas mêler les deux serait sage, AMHA.

--Lgd (d) 26 juin 2009 à 12:26 (CEST)

Tu as raison , priorité déjà à l'accessibilité aux lecteurs d'écran. Il faudrait préciser en intro, dans la documentation de ce modèle (je n'arrive pas à mettre la main dessus, même avec l'outil de recherche!), que son utilisation ne change pas l'aspect visiel du titre. --amicalement, Salix ( converser) 26 juin 2009 à 13:13 (CEST)

@Salix: bien vu, et deaune. Désolé pour l'accès compliqué à la page de doc du modèle, j'étais bousculé ce matin, j'avais fait ça comme un cochon en me trompant de modèle de doc en sous-page. --Lgd (d) 26 juin 2009 à 13:48 (CEST)

Tout à fait d'accord avec toi, Lgd. En fait mon propos est plutôt d'attirer l'attention sur le fait que le "statut" du titre est assez flou, en particulier sur wikipédia. Sans compter que personnellement je trouve qu'utiliser le titre d'un article (au sens d'un texte), élément excessivement rédactionnel, comme identifiant d'un article (au sens d'une entité unique) est un choix que je trouve regrétable à de très nombreux points de vue. Mais c'est une autre histoire Hexasoft (discuter) 26 juin 2009 à 13:27 (CEST)

Je te suis tout à fait. D'autant que c'est un problème que j'ai souvent rencontré ailleurs dans l'utilisation de mediawiki dans d'autres contextes: réunir en une seule donnée l'identifiant back-office de la page (le bout title=dans l'url, disons), le titre de page (l'élément HTML title) et le titre h1 de la section principale du contenu (le titre au sens courant wikipédien), c'est très gênant. Mais c'est une autre histoire, en effet (C'est aussi une des grandes qualités de simplicité à première vue de Wikipédia). --Lgd (d) 26 juin 2009 à 13:45 (CEST)

Juste un truc, pour les titres à la fois en langue étrangère et en français, on fait comment ?

Je me suis posé la question pour les titres du type Nom de la société étrangère (société) (on retrouve ce cas à plusieurs reprises avec les homonymies). Amicalement — Steƒ ^{๏̯͡๏﴿} 26 juin 2009 à 13:33 (CEST)

Ce premier modèle ({{Langue du titre}}) dit justement qu'on ne fait pas (ou peut-être ne le dit-il pas assez clairement ? Améliorez, svp).

Pour faire, il faut le faire évoluer ou créer un autre modèle. Pour faire ça habilement pour le rédacteur et proprement, il faut une prochaine version de mediawiki qui permette de gérer le traitement des chaînes de caractères dans les modèles (une extension en cours d'implémentation par défaut). Donc, a priori, on attend pour régler le moment venu cette question (Il y aurait des solutions temporaires pour des cas de titres au format connu, mais si on peut éviter, c'est bien). --Lgd (d) 26 juin 2009 à 13:37 (CEST)

Ce type de cas existe aussi pour le latin en biologie, chaque fois qu'un nom latin est homonyme (soit avec un mot/nom français, soit avec un autre règne). On a alors aussi des choses comme trucmuchae (genre) ou bidulae (reptile). Point d'urgence, le nombre de titres purement latins est largement plus grand et ce sera déjà une amélioration d'accessibilité sur pas mal de d'articles (travail qui reste à faire dans les taxobox, il me semble). Hexasoft (discuter) 26 juin 2009 à 14:13 (CEST)

J'avais tenté autrefois de faire un modèle à 3 paramètre : 1er paramètre = code langue à deux lettres, 2e paramètre = ce qui est dans cette langue (ex : Trucmuchae ou bidulae) et 3e paramètre = ce qui reste en français (exemple : (genre) ou (reptile)). Cela ne peut pas marcher un truc de ce genre ? TED 26 juin 2009 à 14:49 (CEST)

Vu la structure du modèle langue du titre je pense que si, mais ça serait limité aux cas "titre homogène dans une langue" + précision en () pour cause d'homonymie (principalement). Mais je pense que ça représente 90% (refnec !) des cas de mélange de langue. Hexasoft (discuter) 26 juin 2009 à 15:02 (CEST)

J'ai travaillé dessus ce matin, justement. C'est ce qui m'a amené à conclure qu'il fallait attendre de pouvoir manipuler les chaînes de caractères dans les modèles, via la prochaine mise à jour de mediawiki concernée. Pour l'instant, ce serait en effet faisable à court terme et proprement pour des types de libellés bien connus (et encore, le proprement est très relatif), mais pas très utile. Patience vaut mieux que bricolage... --Lgd (d) 26 juin 2009 à 15:15 (CEST)

(conflit d'edit) On peut toujours imaginer un truc du genre :

paramètre 1 = langue 1

paramètre 2 = ce qui est dans la langue 1

paramètre 3 = langue 2

paramètre 4 = ce qui est dans la langue 2

paramètre 5 = langue 3

paramètre 6 = ce qui est dans la langue 3

etc.

Mais y a-t-il des titres avec plus de deux langues ? TED 26 juin 2009 à 15:16 (CEST)

Oui, On peut comme ça (Il y a d'autres biais aussi). Mais gère le problème des espaces, par exemple, en pensant au rédacteur... C'est pour cela qu'il faut des fonctions de manipulation de chaînes de caractères ({{DISPLAYTITLE}} exige une stricte identité des deux titres à la casse et au balisage près. La présence d'espace entre les mot, voir de signes de ponctuation combinés ou non avec des espaces est une prodigieuse source d'emmerdements). --Lgd (d) 26 juin 2009 à 15:39 (CEST)

Comme personne n'avait l'air de râler excessivement, je suis passé sur le Bistro (C'est un poil tard dans la journée, mais bon). --Lgd (d) 26 juin 2009 à 15:36 (CEST)

Merci à vous tous. À propos de l’italique, je pense que pour le moment c’est mieux sans, en tout cas il faut absolument éviter de le mettre par défaut. On peut soit imaginer un paramètre supplémentaires (italique : oui/non), soit une détection automatique (ce qui éviterait des erreurs mais je ne sais pas si c’est simple ou non à mettre en œuvre, je suppose que non puisque cela dépend de l’écriture et non de la langue). Enfin, il y a des cas, où l’utilisation de l’italique ou non n’est pas claire (typiquement l’Arménien où il ne devrait pas y avoir d’italique mais où il y en a parfois quand même, Sardur (d · c · b) notamment met l’arménien en italique sans vraie raison). En passant, il « parait » que mettre un texte entre deux paires d’apostrophes, ne crée pas un vrai italique mais juste du romain penché (moi je m’en contente mais pas certains typographes puristes…). Cdlt, VIGNERON * ^discut. 26 juin 2009 à 16:09 (CEST)

Le coup des deux apostrophes et du romain penché est en partie exact. Je ne sois pas sûr qu'il s'agisse de romain (j'avoue que ce n'est pas ma tasse de thé quotidienne dans un monde bêtement industriel), mais en tout cas c'est bien juste du « penché » et non de l'italique. Cependant, cela dépend aussi de la manière dont le navigateur « mappe » les polices et les styles de caractères, c'est assez compliqué dans le détail. En tous cas, c'est un troll d'espèce très savant et très velu qu'on croise rarement, tu as eu beaucoup de chance de pouvoir l'observer. --Lgd (d) 26 juin 2009 à 16:25 (CEST)

J'ai été éminement démagogique avec les deux expression en gras du message sur le Bistro du jour. Désolé, j'ai honte, moi aussi. Cela-dit, il est probable que je vais recommencer. --Lgd (d) 26 juin 2009 à 21:57 (CEST)

{{Titre mis en forme}}

Voici le grand frère de {{Langue du titre}}, qui fait beaucoup plus de choses, et qui devrait intéresser Hexasoft et TED:

• dans l'immédiat, il va remplacer (mais sans détour javascript) {{Titre incorrect}} quand il s'agit de mettre en exposant ou en indice une partie du titre d'un article.
• Mais il peut tout aussi bien indiquer un changement de langue pour une partie du titre seulement, voire mettre en italique.
• En gros, tant qu'on ne veut pas modifier le texte lui-même du titre, mais uniquement sa mise en forme ou ses métadonnées de langue, il le fait.

Au passage, comme indiqué sur le Bistro d'aujourd'hui, un autre petit frère a repris du service pour mettre en minuscule l'initiale d'un titre: {{Minuscule}}. --Lgd (d) 28 juin 2009 à 20:08 (CEST)

Au passage, les conventions veulent que les titres de films soient indiqués en italique, alors, doit-on mettre en italique chaque titre d'article sur un film ? Amitiés — Steƒ ^{๏̯͡๏﴿} 28 juin 2009 à 20:32 (CEST)

Voir dans la section précédente la question de l'italique. Pour ma part, je pense que ce n'est pas pertinent quand il s'agit de l'ensemble du titre, mais que ça peut l'être éventuellement dans quelques cas particuliers comme Maître du Registrum Gregorii ou Basiliscus (animal). J'ignore si le Projet Cinéma en rencontre de semblables.

Je copie également ici une question de TED (depuis ma Pdd) et ma réponse:

Est-ce que {{titre mis en forme}} est fonctionnel maintenant ? As-tu prévu de le remettre partout où tu as supprimé {{Titre}} ou {{Titre incorrect}} (partout où tu disais en commentaire de diff que tu enlevais provisoirement, pour faciliter la mise à jour de ces modèles). TED 30 juin 2009 à 03:22 (CEST)

Le modèle {{Titre mis en forme}} sait mettre proprement le titre en italique, mais ce n'est pas le moment :

A court terme, le bot n'a pas encore fini son passage. Cela facilitera le suivi de ses edits si le modèle n'est pas utilisé actuellement aussi pour l'italique, notamment parce que les mises en indices ou en exposant sont de loin l'utilisation la plus massive, et qu'elles recourent parfois à des modèles problématiques pour {{DISPLAYTITLE}}. Pour l'instant, je me concentre là-dessus en espérant qu'on ne me complique pas les choses.

L'étape suivante concernera la langue, sa mention n'ayant le caractère discuté de l'italique. Le traitement devra concerner tous les articles, soit via un bot, soit via l'ajout du modèle adapté via la taxobox, ce qui nécessite des tests préalables. Dans l'hypothèse où l'italique serait ensuite adoptée, le même moyen technique permettra de l'appliquer aisément et systématiquement.

L'italique viendra donc en troisème lieu, si la question éditoriale à son propos est enfin tranchée. La priorité pour l'instant à son propos est de se concentrer sur la seule question de la pertinence : j'espère que la communauté parviendra à une décision, quelle qu'elle soit, qui soit largement acceptée (la question ne concerne pas seulement les articles du Projet Biologie).

Pour le moment, il est donc préférable de s'abstenir de replacer de l'italique à la main ici ou là. Sachant qu'une solution technique « propre » existe à présent, mon rôle se bornera à son application une fois la décision prise. Cordialement, --Lgd (d) 30 juin 2009 à 07:09 (CEST)

Attribut de langue automatisé par une liste

Bonjour,

Le modèle {{Lang}} se fait de plus en plus entendre ces derniers temps, et cela m'a incité à l'utiliser plus souvent que d'habitude. Toutefois, je me rends compte qu'il est fastidieux de placer ce modèle à chaque occurrence d'un mot en langue étrangère, lorsqu'on travaille sur un article contenant beaucoup d'expressions étrangères. Prenez l'exemple de cet article sur un navire américain : diff. L'utilisation du modèle est très lourde et rend la lecture du texte en mode brut malaisé, d'autant plus qu'ici ce sont toujours les mêmes termes qui reviennent.

Pourrait-on créer un modèle qu'on placerait en tête d'article, à l'intérieur duquel nous pourrions lister les termes étrangers, afin que le modèle ajoute automatiquement dans le texte l'attribut de langue aux termes listés ? Gain de temps à l'édition, lecture en mode brut plus facile, et on est sûr de n'oublier aucune occurrence du mot. Est-ce techniquement réalisable ?

Aussi, lorsqu'on traite d'un article avec des noms de villes étrangères (es:Guipûzcoa, en:New Jersey, de:Karlsruhe, etc.) et des noms propres (en:Arthur Conan Doyle, yougoslave:Milovan Đilas, etc.), est-ce qu'il faut mettre le modèle Lang ?

Merci d'avance, Tachymètre ✉ 5 juillet 2009 à 10:48 (CEST)

Pour être de n'oublier aucune occurrence d'un ou de mot(s) précis, il y a sinon user:Stef48/regexp.js que tu peux charger dans ton monobook.js via loadJs('Utilisateur:Stef48/regexp.js'); et qui ajoute à ta barre d'outil d'édition ce bouton : .

Lorsque tu cliques dessus, une fenêtre s'ouvre et te permet de remplacer l'occurrence de X par Y dans tout l'article (en mode modification évidemment).

Par exemple ici : M. Night Shyamalan ([2]). Ceci dit, je crois qu'il ne fallait pas ajouter le modèle {{lang}} pour les noms propres ... C'est fait ...

Amicalement — Steƒ ^{๏̯͡๏﴿} 5 juillet 2009 à 11:17 (CEST)

La mention de changements de langue est un grand classique parmi les choses délicates à gérer.

Deux choses pour vous aider:

• La mention du changement de langue sur un nom propre (de persone, de lieux, etc.) n'est pas exigée par les normes d'accessibilité (voir les bonnes pratiques d'accessibilité). Si elle est tout de même présente, cela dit, cela ne fait pas de mal pour le lecteur. Mais il est vrai que cela contribue à alourdir l'édition pour le contributeur. Concentrez-vous plutôt sur les expressions en dehors des noms propres.
• Votre idée de modèle est hélas impraticable : actuellement, en effet, un modèle ne peut pas dire à MediaWiki de chercher des termes dans la suite du contenu pour modifier leur balisage.

--Lgd (d) 5 juillet 2009 à 11:29 (CEST)

Dommage. Je vais jeter un œil aux scripts comme le tiens, Stef48, pour m'aider à insérer plus facilement le modèle Lang. Merci pour vos réponses. Tachymètre ✉ 5 juillet 2009 à 12:21 (CEST)

Ça y est, je me suis ajouté un bouton pour insérer le modèle Lang, ainsi que ta fonction Remplacer. L'édition ira sensiblement plus vite, grâce à cela ! Je voulais juste savoir, c'est quoi les flags de ta fonction ? g, c'est pour tout remplacer, mais à quoi servent m et i ?

J'ai également remarqué que le bouton « Insérer une image » ajoutait le code [[Fichier:Exemple.jpg]], au lieu de [[Image:Exemple.jpg]], et j'ai récemment croisé un bot en train de remplacer Image par Fichier dans les balises d'image. Pourtant, dans la page d'aide consacré à l'insertion des images, tout est écrit en Image, et non en Fichier. C'est une question d'accessibilité, ou bien la différence n'a pas d'importance ? Tachymètre ✉ 5 juillet 2009 à 13:45 (CEST)

Il n'y a pas de différence. Peux-tu dénoncer le bot (), afin que je puisse lui dire que ce genre de modification ne sert à rien ? Amicalement, Dodoïste ^{[ dring-dring ]} 5 juillet 2009 à 13:54 (CEST)

C'est Xqbot (d · c · b), il sévit en ajoutant des liens interlangue et couvre ses méfaits sous l'appellation « changement de type cosmétique ». Preuve : diff. Mais chuuuut, hein, nous ne nous sommes jamais parlés. D'accord ? Tachymètre ✉ 5 juillet 2009 à 14:10 (CEST)

M = Multi-line

I = Ignore (ignorer la casse)

G = Global

Note que le G est le seul dont je me serve.

Amicalement — Steƒ ^{๏̯͡๏﴿} 5 juillet 2009 à 19:41 (CEST)

merci :) Tachymètre ✉ 5 juillet 2009 à 19:52 (CEST)

Précisions sur les alternatives textuelles des images

Bonsoir. J'aimerais quelques précisions concernant la complémentarité du caption et de l'alternative textuelle. Dans quelle mesure l'un peut faire doublon sur l'autre ? Par exemple [[Image:P Eiffel.png|48x24px|Icône du Portail de la tour Eiffel]] est cité dans les bonnes pratiques. Mais le caption ne fait-il pas doublon avec le texte alternatif produit par mediawiki ? Voir le code produit :

• <a href="/wiki/Fichier:P_Eiffel.png" class="image" title="Icône du Portail de la tour Eiffel"><img alt="Icône du Portail de la tour Eiffel" src="http://upload.wikimedia.org/wikipedia/commons/thumb/4/4e/P_Eiffel.png/26px-P_Eiffel.png" width="26" height="24" /></a>

J'ai corrigé une grossière erreur dans la recommandation sur les alternatives textuelles des images de en.wiki. Mais mon anglais est imparfait, alors une relecture ne serait pas de trop. Les pages d'aide sur l'accessibilité en général sont très incomplètes. Je vais tenter d'y remédier petit à petit, en traduisant les bonnes pratiques de Lgd. Amicalement, Dodoïste ^{[ dring-dring ]} 6 juillet 2009 à 01:56 (CEST)

Ah, et lorsqu'on décrit une image, est-il pertinent de signaler le type d'image dont il s'agit (icône, dessin au crayon, peinture à l'huile, photographie, portrait, etc.) ? Dodoïste ^{[ dring-dring ]} 6 juillet 2009 à 19:07 (CEST)

Imagine que tu sois aveugle ou que tu ne puisse pas afficher les images : àmha selon le contexte cela peut-être utile en effet. --amicalement, Salix ( converser) 7 juillet 2009 à 15:00 (CEST)

Bandeau d’ébauche

Bonjour,

J’ai corrigé le modèle {{ébauche}} (liens sur les icônes non pertinents) ; la version modifiée se trouve ici: Utilisateur:Cépey/temp. J’attends vos éventuels commentaires avant de remplacer le modèle actuel {{ébauche}} par la nouvelle version. Voici ce que ça donne:

{{Utilisateur:Cépey/temp|mathématiques|Suisse}}

Description des changements: (1) Les liens sur les icônes pointent maintenant sur la catégorie d’ébauche correspondante et ont une alternative textuelle en conséquence. On pourrait tout aussi bien supprimer ce lien et mettre une alternative textuelle vide, si vous pensez que ce serait mieux. — (2) Le lien sous le mot « (Comment ?) » pointe maintenant sur Aide:Comment rédiger un bon article plutôt que Aide:Comment modifier une page (selon une remarque sur Discussion:ébauche).

En fait, ce qui résoudrait tous les problèmes serait de rediriger Modèle:ébauche vers Modèle:Modèle vide, mais je doute que ça plaise à tout le monde.

—C.P. 8 juillet 2009 à 14:21 (CEST)

C'est une bonne idée (et décidément on a tous des bonnes idées en même temps ces derniers jours). La difficulté consiste à pouvoir créditer les auteurs de toutes les icônes d'ébauches (et donc respecter notre propre licence) sur Wikipédia:Crédits graphiques, qui s'affiche en bas de page avec les informations de copyright. Même si c'est fastidieux, on peut faire la liste de toutes ces images.

On peut aussi se demander si il ne vaudrait pas mieux avoir une icône unique pour les bandeaux d'ébauches. Parce qu'actuellement, les icônes ne signalent pas qu'on a affaire à une ébauche, mais font doublon avec les texte en paramètre qui suivent. Et l'image varie tellement qu'elle ne joue plus tellement son rôle de signalétique. Sans dire encore que dès qu'on a deux paramètres, on a deux icônes, et qu'on peut en avoir six à la suite. Trop d'icône tue l'icône. Dodoïste ^{[ dring-dring ]} 8 juillet 2009 à 15:45 (CEST)

Zut, j’avais pas remarqué la discussion que tu viens de pointer. — Pour accéder à la licence des icônes, cela est effectivement problématique, même s’il est possible d’écrire une marche à suivre (un peu compliquée) sur la manière de récupérer les infos. —C.P. 8 juillet 2009 à 16:22 (CEST)

— Sinon, le mieux serait en effet de zapper toutes ces icônes personnalisées par sujet d’ébauche, qui n’apportent rien (peut-être après s’être assuré de l’accord des wikipédiens par un petit sondage en bonne et due forme, afin d’éviter les critiques de ceux qui aiment ces icônes), et de les remplacer par une unique icône, qu’on pourrait alors créditer sur Wikipédia:Crédits graphiques. (Au passage, cela simplifierait le code du modèle {{ébauche}}. —C.P. 8 juillet 2009 à 16:41 (CEST)

J'ai trouvé ! La meilleure manière de créditer les auteurs me semble être de fournir un lien vers l'index des sous-pages du modèle ébauche sur Wikipédia:Crédits graphiques. Chaque modèle de paramètre possède une page de documentation unique, qui contient un lien vers l'image non affecté par le modèle ébauche. Ainsi on peut modifier le modèle sans autres soucis. Est-ce que cela te convient ? Dodoïste ^{[ dring-dring ]} 9 juillet 2009 à 04:28 (CEST)

Cela me convient, et même aucun crédit me conviendrait, mais le problème n’est pas là. Pour la question du crédit de ces icônes, je suggère d’en parler à un endroit plus approprié, comme par exemple Discussion Wikipédia:Crédits graphiques, pour avoir un retour de wikipédiens plus sensibles que moi sur cette question. (Ceci dit, je trouve que ta méthode rend quand même assez malaisée la récupération de la license de l’image, car l’utilisateur doit d’abord déterminer le thème de l’ébauche pour retrouver la bonne page de paramètres, et enfin le crédit de l’image qu’il recherche ; mais comme j’ai dit, ici n’est pas ici la page la plus appropriée pour en parler : À l’origine, j’avais posté ici pour avoir un retour sur l’accessibilité.) —C.P. 9 juillet 2009 à 09:18 (CEST)

Ok. Concernant l'accessibilité, il me semble que tout va bien. L'alternative textuelle est "catégorie d'ébauche : mathématique", et je vois pas ce qu'on pourrait faire de mieux. Mais tu peux préférer attendre le retour de Lgd la semaine prochaine pour qu'il te donne un avis plus compétent. Amicalement, Dodoïste ^{[ dring-dring ]} 9 juillet 2009 à 13:27 (CEST)

Ce fut une belle tentative pour alléger le sapin de Noël, respect.

Comme cela continue à bouger, wait and see... --Lgd (d) 11 juillet 2009 à 06:19 (CEST)

Portails, projets et onglets

La généralisation des onglets sur les pages de portail et de travail des projets pose-t-elle un problème d'accessiblité? Bref il vaut mieux s'en tenir à ça ou bien peut-on généraliser sans problème de mises en page avec onglets comme ça? --amicalement, Salix ( converser) 9 juillet 2009 à 09:58 (CEST)

Remarque somme toute non constructive, je n'aime pas les icônes, je préfère faire un truc plus Portail:Réalisation audiovisuelle. Voire même Portail:Cinéma (brouillon) — Steƒ ^{๏̯͡๏﴿} 9 juillet 2009 à 13:09 (CEST)

Donc certains wikipédiens, même jeunes, préfèrent sans onglets ni icônes, c'est noté. Mais en effet cela ne répond pas encore à ma question d'accessibilité. --amicalement, Salix ( converser) 9 juillet 2009 à 17:48 (CEST)

Les onglets proprement dits ({{Début des onglets}}) ne posent pas de problèmes d'accessibilité. Seul le gabarit à la base de choses du type Portail:Ornithologie/Section nécessiteraient des corrections sans conséquences sur les rendu et le code wiki/HTML global de ces portails est une insulte à l'intelligence, mais ça, c'est moins grave . Bref, pas d'objections à la généralisation. --Lgd (d) 11 juillet 2009 à 06:15 (CEST)

Merci, donc on laisse faire. Je préférais m'en assurer. --amicalement, Salix ( converser) 11 juillet 2009 à 11:20 (CEST)

quelle hiérarchie pour les modèles ?

Bonjour ! Il m'arrive régulièrement dans les articles d'avoir des liens vers des titres d'oeuvres en anglais. Est-ce qu'il y a une hiérarchie à privilégier entre l'italique, le modèle {{lang}} et les crochets du lien ? Merci ! Léna (d) 12 juillet 2009 à 13:41 (CEST)

Je pense que tu trouveras la réponse là : Discussion_Wikipédia:Atelier_accessibilité/Bonnes_pratiques#lang. J'ai rajouté une explication dans la documentation du modèle, est-ce clair? --amicalement, Salix ( converser) 12 juillet 2009 à 16:18 (CEST)

Bandeau pour demander l'amélioration de l'accessibilité

Bonjour, je sais bien qu'il faudrait l'apposer un peu partout à ce stade mais on pourrait déjà réfléchir à un bandeau demandant d'améliorer l'accessibilité d'un article particulièrement obscure pour un lecteur d'écran. Cela éveillerait sans doute les conciences, comme ça a été le cas quand on a créé le bandeau déplorant le manque de sources. On pourrait mettre celui-ci plus discrètement en page de discussion, puisque cela ne remet pas en cause la validité de l'article. Que diriez-vous d'un texte dans le genre de :

«  Cet article ne tient pas assez compte de l'accessibilité. Pour rendre cet article accessible, quel que soit le handicap du lecteur, améliorez sa rédaction en vous aidant des bonnes pratiques conseillées par l'Atelier accessibilité. »

--amicalement, Salix ( converser) 16 juillet 2009 à 11:10 (CEST)

Hum...

Moui...

Hum...

Non, finalement, pour ce qui est de mon avis personnel, avec notamment pour raison :

• Ajouter un bandeau est fréquement polémique (réaction courante, qu'elle soit pertinente ou non sur le fond : « au lieu d'ajouter un bandeau, corrigez plutôt directement ce qui ne va pas »)
• Autre réaction prévisible dans un domaine plus limité : « qu'est-ce que c'est que cette nouvelle contrainte ? Il y a en a déjà bien assez comme ça pour les AdQ et des BA ».
• Méthodologiquement, dire globalement « Cette page n'est pas accessible » est ce que l'on évite de faire. Une page a des points positifs à conforter et des points améliorables qu'il faut précisément indiquer aux gens concernés. A la rigueur, peut-être, des bandeaux spécifiques sur tel ou tel problème (« les choix de couleurs de cette palette posent un problème de contraste de couleurs », « Les libellés de liens de cette section ne sont pas explicites », « Les tableaux présents dans cette page n'utilisent pas les métadonnées nécessaires à son accessibilité », « Pensez à signaler les changements de langue du texte », etc. avec les liens qui vont bien, mais sous réserve des deux points précédents)
• les principaux articles où ce bandeau serait pertinent renvoient à des problèmes majeurs où des intérêts contradictoires s'opposent sur fond de limites technologiques : par exemple, tous les articles utilisant du contenu généré CSS, ou encore les articles recourant à des tableaux non linéalisables pour faire des arbres généalogiques ou des organigrammes, ou encore ceux utilisant timeline, etc. le bandeau ne ferait que mettre les contributeurs face à une quasi-impossibilité, à leur niveau, de corriger ce qui relève de fonctionnalités défectueuses ou manquantes dans mediaWiki. Mauvaise communication sur l'accessibilité, ça.
• l'aide (Aide:Sommaire) est encore largement insuffisante pour que diverses bonnes pratiques puissent devenir des usages exigibles. Il faut déjà beaucoup améliorer de ce côté.
• Plus généralement, toute mon expérience en la matière me murmure très fort que l'accessibilité a tout à gagner en se « glissant » aussi subrepticement que possible dans les règles rédactionnelles, plutôt qu'à être donnée aux rédacteurs comme objectif en soi, sauf cas spécifiques.

En revanche, le système de suivi et d'évaluation des modèles et des usages que j'avais tenté de mettre en place avec Wikipédia:Atelier accessibilité/Suivi des points améliorables est à revoir. L'idée n'était pas idiote, mais elle est maladroite et insuffisante. J'avais prévu de cogiter là-dessus à la rentrée, à vrai dire, notamment après la mise en place d'outils similaires au toolserver pour repérer les usages, modèles, etc. qui seraient prioritairement à corriger. Bref, plutôt que de prendre le contributeur de front, je pense qu'il vaut mieux :

• continuer à privilégier le travail sur les sources automatisables d'accessibilité (modèles, etc.)
• continuer à promouvoir, mais de manière soft, les bonnes pratiques d'accessibilité uniquement rédactionnelles quand elles sont consensuelles (la promotion du modèle {{lang}} est un bon exemple).
• ne pas oublier ce qui avait été commencé avec un ou deux AdQ et qui s'était très bien passé (je suis allé d'ailleurs corriger comme cela en cours de labellisation deux autres AdQ sans aucun souci).

Mais pas de bandal qui fera plus de polémique que de bien. Cordialement, --Lgd (d) 16 juillet 2009 à 11:31 (CEST)

Ok, c'est peut-être encore trop tôt en effet... pourtant je me lasse de répéter toujours la même chose... ton idée de messages spécifiques est donc une solution à creuser. N'hésite pas! --amicalement, Salix ( converser) 16 juillet 2009 à 16:21 (CEST)

{{Horloge}}

Bonjour.

Je voudrais vous présenter le cas du modèle {{Horloge}}. Il contient une petite icône décorative en forme d'horloge, Modèle:Horloge, placée dans les articles sur les films, juste devant les durées.

J'ai cru comprendre que les icônes sans autre fonction que décoratives, bien qu'elles soient assez souvent à éviter, n'étaient néanmoins pas toujours le mal absolu, et qu'elles pouvaient se justifier dans certains cas où elles apportent quelque chose pour la navigation (par exemple {{article détaillé}} et modèles proches, cf. message plus haut).

Pour le cas qui nous occupe, il y a donc deux possibilités :

1. soit on considère que cette icône fait partie des cas où une image purement décorative se justifie :

   dans ce cas, si j'ai bien compris, il faudrait utiliser link=, pour éviter d'avoir un lien inutile et « confusant » vers la page de description (ou utiliser l'astuce CSS, car j'ai bien compris que la pérennité du link= n'était pas assurée, mais comme l'utilisation d'{{horloge}} est tout de même moins universelle que {{article détaillé}} par exemple, je ne sais pas si ça vaut le coup d'alourdir Common.css pour ça) ;

2. soit on considère que cette icône n'est pas utile à la navigation :

   dans ce cas il faudrait blanchir le modèle (je ne dis pas supprimer, car ça ferait un lien rouge moche dans les vieilles versions des articles) ; cela dit j'imagine que ça nécessiterait une procédure de suppression, mais je ne voulais pas en lancer une inutilement (au cas où l'on serait dans la possibilité numéro 1) avant d'avoir votre avis.

Comme je ne suis pas capable de juger si cette image fait partie des icônes pertinentes ou pas, je vous soumets la question. Voilà, j'espère que je n'ai pas dit trop de bêtises ! Merci d'avance de votre aide. — Hr. Satz 22 juillet 2009 à 18:19 (CEST)

En quoi un lien vers une page de description de l'image est à éviter ?

Par ailleurs, le modèle est utilisé par le projet cinéma, pour les fiches film apparemment, mais aussi par le projet musique, pour les albums. Peut-être faudrait-il également contacter ces projets pour voir ce qu'il en est, savoir ce qu'ils pensent du modèle, de son utilisation, etc. Amitiés — Steƒ ^{๏̯͡๏﴿} 22 juillet 2009 à 18:37 (CEST)

« En quoi un lien vers une page de description de l'image est à éviter ? » : Ben pour les mêmes raisons que sur {{article détaillé}}, {{...}}, etc. Voir plus haut sur cette page le sujet « {{Article détaillé}}, {{Article connexe}} le retour » ainsi que le bistro du 7 juin, et plus généralement la bonne pratique sur l'absence de lien vers les pages de description, pour les images purement décoratives : « Actuellement, l'ajout d'un paramètre link= sans valeur après le signe égal produit une image qui n'est pas une image-lien et qui a une alternative vide. C'est-à-dire la solution optimale pour une image décorative qu'on ne gère pas en CSS. » puis (c'est ce que je disais sur l'absence de pérennité du link=) : « Cependant, ce comportement de mediawiki est susceptible de changer à l'avenir, car il n'obéit qu'à un choix arbitraire des développeurs. Il est donc risqué de s'y fier. ».

L'idée est de rendre l'image non cliquable pour d'éviter d'avoir un lien vers la page de description, car l'image est purement décorative, et donc n'apporte rien à un utilisateur qui liste les liens hors contexte avec un lecteur d'écran par exemple (du moins d'après ce que j'ai compris).

De plus, je peux me tromper, mais j'ai l'impression que tu trouves ma démarche cavalière, or je ne vois pas pourquoi, ma question concerne l'accessibilité de la chose. Je ne crois pas que le projet cinéma soit spécialisé dans l'accessibilité. J'ai bien dit que je ne proposais pas la suppression, je pose simplement une question pour savoir comment l'améliorer ; et que si suppression il devait y avoir, j'engagerais une procédure en bonne et due forme avec, bien entendu, alerte au projet concerné. Donc pas de raison de râler (si c'est le cas). — Hr. Satz 22 juillet 2009 à 20:14 (CEST)

Je viens de mettre la main sur d'autres modèles du même type, qui suscitent donc la même question chez moi : {{disque d'argent}}, {{disque d'or}}, {{disque de platine}}, {{double disque de platine}}, {{disque de diamant}}, {{monde}}. — Hr. Satz 22 juillet 2009 à 20:14 (CEST)

Effectivement, {{Horloge}} ne véhicule aucune information mais constitue un lien parasite. C'est probablement le cas des autres modèles que tu cites (je n'ai le temps de regarder tout de suite), mais aussi de très nombreux autres dans Wikipédia. Le link vide est une solution. Pour des modèles « stables » et très employés, l'image CSS reste cependant préférable, comme cela a été fait pour les modèles {{Article détaillé}} etc. (Tiens, BTW, un petit avantage de l'image CSS: un changement d'icône se fait uniquement dans la feuille de style et non dans le modèle, ce qui évite toute surcharge côté serveur (jobqueue)).--Lgd (d) 30 juillet 2009 à 07:13 (CEST)

Merci pour ta réponse ! Je me suis permis de mettre le link= vide dans les modèles de disque car ils sont assez confidentiels (inclusion dans 39, 186, 197, 72 et 50 articles) et l'éventail d'articles pouvant les accueillir assez restreint.

Pour {{monde}}, l'usage est potentiellement plus large (et de fait utilisé dans 229 articles), de même qu'{{horloge}} (670 articles), donc je n'y touche pas vu que le CSS est préférable. De plus, il n'y a pas d'explication sous forme de texte après l'image, comme avec les modèles de disque, et il n'est pas certain qu'une telle indication soit faite dans les articles en plus du modèle (je ne sais pas si je m'exprime bien ; par exemple si quelqu'un a juste marqué «  : 20,52 millions d'entrées » dans un article, et que l'on retire du modèle le lien vers la page de description de l'image, il n'y a plus de légende / alternative textuelle, donc ça n'a plus de sens pour quelqu'un qui n'a pas les images, et là je ne sais pas comment faire — je n'avais pas fait attention à ce problème quand j'ai posé la question). — Hr. Satz 1 août 2009 à 23:04 (CEST) barré bêtise le 2 août 2009 à 19:14 (CEST) : je viens de m'apercevoir que le alt reste, même avec un link= vide j'ai pas encore tout compris moi...

Alternative des timeline (graphiques complexes type histogrammes)

Plop,
Juste un mot rapide pour vous signaler, à la suite d'une fructueuse discussion/collaboration avec Utilisateur:Xfigpower, la mise en place dans un modèle d'histogramme ({{Relevé hydrologique}}) d'un système (à l'essai, améliorable) pour fournir une alternative à ces graphiques (étant donné que l'extension timeline qui les génère ne le permet pas).

Voir la page de documentation du modèle et l'exemple de l'article Mauldre, ainsi que la catégorie de maintenance et de suivi Catégorie:Accessibilité : Graphique timeline sans alternative. Je reviendrais sur le sujet, mais avis et améliorations sont les bienvenus. Mieux encore: crééez les alternatives ! --Lgd (d) 30 juillet 2009 à 07:06 (CEST)

Précisions sur les alternatives textuelles des images

Bonjour. J'aimerais quelques précisions concernant la complémentarité du caption et de l'alternative textuelle. Dans quelle mesure l'un peut faire doublon sur l'autre ? Par exemple [[Image:P Eiffel.png|48x24px|Icône du Portail de la tour Eiffel]] est cité dans les bonnes pratiques. Mais le caption ne fait-il pas doublon avec le texte alternatif produit par Mediawiki ? Seront-ils tous les deux lus par un lecteur d'écran, ou seul l'alternative textuelle sera lue ? Voir le code produit :

• <a href="/wiki/Fichier:P_Eiffel.png" class="image" title="Icône du Portail de la tour Eiffel"><img alt="Icône du Portail de la tour Eiffel" src="http://upload.wikimedia.org/wikipedia/commons/thumb/4/4e/P_Eiffel.png/26px-P_Eiffel.png" width="26" height="24" /></a>

J'ai corrigé une grossière erreur dans la recommandation sur les alternatives textuelles des images de en.wiki. Mais mon anglais est imparfait, alors une relecture ne serait pas de trop (fait par un contributeur anglais depuis le temps). Les pages d'aide sur l'accessibilité en général sont très incomplètes. Je vais tenter d'y remédier petit à petit, en traduisant les bonnes pratiques de Lgd. Amicalement, Dodoïste ^{[ dring-dring ]} 6 juillet 2009 à 01:56 (CEST)

Ah, et lorsqu'on décrit une image, est-il pertinent de signaler le type d'image dont il s'agit (icône, dessin au crayon, peinture à l'huile, photographie, portrait, etc.) ? Dodoïste ^{[ dring-dring ]} 6 juillet 2009 à 19:07 (CEST)

Oups, pardon pour l'oubli.

• Le « caption de l'image » (le tooltip, disons plutôt) génère l'attribut title du lien
• L'alternative génère le alt de l'image

Concrètement, cela a un impact essentiellement pour les lecteurs d'écran: selon leur paramètrage et le contenu qu'ils rencontrent, ils vont en effet restituer à l'utilisateur soit le alt, soit le title, soit le plus long des deux (parce qu'il est a priori susceptible d'apporter plus d'information). La bronne pratique consiste donc à avoir tout simplement une information identique dans les deux attributs.

Indiquer le type de l'image peut être pertinent dans certains contextes, mais ce n'est pas la règle générale. Tout dépend s'il sagit d'une information effectivement nécessaire à la compréhension de ce que véhicule l'image dans la page où elle se trouve. Ici, c'est rendu plus compliqué par les images-liens (Indiquer le type de l'image donne au moins un sens minimal au lien vers sa page) --Lgd (d) 30 juillet 2009 à 07:31 (CEST)

L'idée m'est venue en lisant en:Wikipedia:Alternative text for images : « The alt text description should not duplicate information already present in the caption. L'alternative textuelle de doit pas dupliquer les informations déjà fournies dans le caption. » Vu ta précédente réponse, je pense que cette affirmation est à nuancer, alors si tu m'expliques tout ça en détail, j'irai corriger la recommandation sur en. Dodoïste ^{[ dring-dring ]} 31 juillet 2009 à 13:55 (CEST)

Ah, fichu vocabulaire imprécis (« caption » ne veut rigoureusement rien dire en HTML pour une image et on ne sait jamais ici si les gens utilisent les termes propres à mediawiki ou les termes réels du HTML).

Le passage que tu signales dans :en concerne les images en thumb où le « caption » est ce que nous appelons la « légende », affichée sous l'image (Donc pas du tout ce que j'avais compris ci-dessus, qui s'applique aux images sans thumb). Il n'y a rien à changer au texte de :en sur ce point: le alt d'une l'image et sa légende affichée en dessous n'ont en effet aucune raison de pouvoir être identiques, et la recommandation va dans le bon sens. --Lgd (d) 31 juillet 2009 à 16:36 (CEST)

Pour aider: d'abord (à gauche) une image sans thumb où le alt et le title devraient être identiques (contrairement à l'exemple), et ensuite (à droite) une image en thumb où le alt et la légende sont sans problèmes différents... sauf que mediaWiki en profite pour générér sournoisement un title identique à la légende et différent du alt... Zut, Sgn & Sgrmbl !

Il est jaune

Conclusion: ne rien toucher, le CMS a des implémentations trop farfelues pour l'instant. C'est pourquoi j'ai préféré éviter les recommandations sur ce sujet dans les bonnes pratiques, à vrai dire. --Lgd (d) 31 juillet 2009 à 16:44 (CEST)

Salix en Wikibreak

Bonjour, je passe deux secondes pour vous dire que je dois me mettre en wikibreak quelques temps. La vie réelle me réclame à plein temps encore au moins un mois au deux... Bon courage à vous pour poursuivre nos efforts! --amicalement, Salix ( converser) 24 août 2009 à 21:24 (CEST)

Bon wikibreak et des tas de souhaits de bonnes choses. --Lgd (d) 25 août 2009 à 10:09 (CEST)

Chiffres romains

Bonjour, suite à une discussion sur {{Langue du titre}}, je voudrais savoir comment l'on signale des chiffres romains dans un titre. En ce qui concerne l'intérieur de l'article, je suis tombé sur ça plus haut, mais pour ce qui est du titre... Zandr4^[Moa ?] 25 août 2009 à 13:48 (CEST)

Conflit Langue du titre - Infobox Jeu vidéo

Bonjour,

Nous avons un souci sur le Projet:Jeu vidéo, avec le modèle {{Langue du titre}}. Lorsqu'il est placé juste au-dessus de notre {{Infobox Jeu vidéo}}, le code <p><br /></p> est ajouté dans la source HTML, entre les deux modèles, ce qui fait apparaître une ligne blanche et décale le texte vers le bas. Pour pallier à ce conflit, soit nous plaçons le modèle Langue du titre ailleurs dans le corps de l'article (peu intuitif ; il faudrait le maintenir en première ligne), soit nous plaçons les deux modèles sur la même ligne (comme ici : diff).

Je ne sais pas lequel des deux modèles est fautif (remarque : aucun problème avec les infobox des autres projets). Est-ce que l'un d'entre vous pourrait jeter un œil là-dessus ? Moi et les modèles, ça fait deux Tachymètre ^(me parler) 25 août 2009 à 14:15 (CEST)

Je rebondis avec une question corolaire : il y a un endroit privilégié pour placer ce modèle ? Personnellement je le place juste après le bandeau de portail (avant les catégories donc), ça me paraissait naturel ; mais peut-être pas ou peut-être qu'on s'en fout ^^. Jean-Fred (d) 25 août 2009 à 14:39 (CEST)

En fait, j'ai toujours vu les modèles de titres (Langue / Mise en forme / Titre incorrect) placés en première ligne. Ça me paraît plus intuitif puisque le titre se trouve en haut. De plus, quand on veut vérifier si une page contient le modèle ou pas, ça évite de sonder toute la page à sa recherche. Mais c'est un autre débat. ^^ Tachymètre ^(me parler) 25 août 2009 à 14:56 (CEST)

Le script associé au modèle est minimal. Il peut être éventuellement étendu pour supprimer le <p><br /></p> si celui-ci est bien un reliquat du modèle après suppression via javascript. Mais ce sont des bricoles de rendu sans grand intérêt dans un wiki, pour tout dire (un wiki ne sert pas à faire de jolies choses. Il sert à faire du contenu).

Sinon, programmatiquement, sa place est indifférente, mais il est effectivement intelligent de placer ce modèle en début de code de l'article, pour les contributeurs (intuitivement, ce qui concerne le titre est au début de la fenêtre d'édition, et cela évite les doublons, etc). --Lgd (d) 25 août 2009 à 14:59 (CEST)

Je ne voudrais pas dire de bêtise, mais je crois que cette ligne blanche est due au fait que dans le code de l'infobox, il y a un retour à la ligne entre le <includeonly> et le <table> juste après. Après test en sous-page perso, il faudrait qu'ils se suivent immédiatement : <includeonly><table>. — Hr. Satz 25 août 2009 à 15:16 (CEST)

{{Langue du titre}}, {{Lang}}

Bonjour, j'ai de nouvelles question sur ces modèles.

• Déjà demandé plus haut, mais je la repose au passage : Que doit-on faire lorsqu'il y a des chiffres romains dans un titre ?
• Dans un titre comme PlayStation 2, un français prononce "Pleystéchun deux", et non pas "Pleystéchun two". Comment gérer ce 2 ?
• Lorsqu'on link vers un article ayant la balise Langue du titre sur en, doit on rajouter au lien que l'on vient de créer un attribut Lang en ? Je pense notamment aux liens vers l'article Playstation. Cela ferait énormément de lien à corriger.
• Enfin, lorsque l'on rajoute un attribut Lang sur un titre de section, et que l'on modifie ensuite la section, c'est tout moche dans l'historique. Le résumé automatique affiche en effet la balise Lang, comme lorsque l'on place des références sur un titre de section. Y-a-t-il quelque chose à faire de ce côté ?

Merci, Zandr4^[Moa ?] 31 août 2009 à 12:35 (CEST)

1. chiffres romains dans un titre qui n'est pas en français : auriez-vous un exemple précis ? Selon la fréquence de ces cas éventuels, une adaptation des modèles existants est peut-être appropriée.
2. PlayStation 2 : les modèles actuels et les limitations de mediaWiki ne permettent pas de différencier de façon satisfaisante des parties du titre dans des langues différentes. Il vaut mieux, au choix :
   • considérer que « Playstation » est un nom propre ou un terme entré dans la langue courante et qui ne nécessite pas d'indication du changement de langue. Dans ce cas, pas de modèle de changement de langue du titre.
   • considérer que la prononciation du titre entier en anglais est pertinente. Dans ce cas, appliquer simplement {{Langue du titre}}.
3. Un lien vers un article dont le titre est balisé comme étant dans une autre langue doit donner la même indication si son libellé est le titre de l'article. Par exemple, un lien Standard Generalized Markup Language ou SGML doit être écrit {{lang|en|[[Standard Generalized Markup Language]]}} ou {{lang|en|[[Standard Generalized Markup Language|SGML]]}}. Cela pourrait d'ailleurs être traité par un bot.
4. Historique: laisser en l'état. Les modèles ne sont pas interprétés dans les commentaires de dif, ce qui lève de nombreuses difficultés potentielles de développement et aide à caractériser certaines autres éditions.

--Temesis2 (d) 1 septembre 2009 à 12:22 (CEST)

Pour le point 4, l'effet peut être même bénéfique car incitatif. Une telle ligne d'historique attire l'attention, et qui sait ? peut-être que les contributeurd ayant cet article dans leur liste de suivi auront la curiosité de jeter un œil sur le modèle lang... Litlok →m'écrire 1 septembre 2009 à 12:32 (CEST)

Merci pour votre réponse

1. Nombreux exemples dans le domaine des jeux vidéos : Project Zero II, Final Fantasy VIII ou autre (de II à XIII), Battlezone_II:_Combat_Commander Breath_of_Fire_III (II,III,IV), Dragon_Quest_III (II,III,IV,V), Grand_Theft_Auto_III, Red Faction II Suikoden_V (II,III,IV)ainsi que toutes les pages liées comme Musique de Final Fantasy VIII ou Personnages_de_Final_Fantasy_X_et_X-2 qui mêle titre anglais, français, chiffres classiques et chiffre romains. J'ai cité ceux qui me passaient par la tête, j'en oublie probablement beaucoup d'autres.
2. On laisse donc les projets correspondants au sujet décider de la conduite à adopter ? Si oui, il faudra trouver un moyen d'avertir l'ensemble des projets de ce choix.
3.  OK
4.  OK

Zandr4^[Moa ?] 1 septembre 2009 à 12:52 (CEST)

S'il ne s'agit que de chiffres romains (sans mise en exposant comme dans un III^e), aucun modèle de mise en forme spécifique n'est nécessaire :

• Les modèles comme III ({{III}}) n'affectent pas la mise en forme typographique.
• Ils apportent un commentaire via un attribut title (« nombre ... écrit en chiffres romains ») qui n'a pas d'effet sur l'accessibilité, et qui, étant en français, ne peut pas être pertinent dans le contenu d'un modèle {{Langue du titre}}
• l'information véhiculée par ce commentaire (pour expliciter le chiffre romain) sera disponible normalement dès l'introduction de l'article si le modèle {{III}} y est utilisé.

Donc: soit utiliser uniquement {{Langue du titre}}, soit n'utiliser aucun modèle de titre (même situation que pour la question 2 ci-dessus).

--Temesis2 (d) 1 septembre 2009 à 14:19 (CEST)

3. Quand j'avais demandé à Lgd, il m'avait expliqué que la syntaxe correcte est [[Standard Generalized Markup Language|{{lang|en|Standard Generalized Markup Language}}]] (meme si c'est long)

4. Une partie de la solution, c'est d'éviter les termes anglais comme gameplay dans les titres (j'ai vu certains de tes travaux, les cas où c'est un titre d'oeuvre on peut pas, forcément). Jean-Fred (d) 1 septembre 2009 à 13:18 (CEST)

3. Fichtre ! Il faudra rajouter un bouton dans la barre des icônes pour transformer une expression en un tel lien ! Avait-t-il donné un motif à une telle syntaxe ?

4. Oui, mes sujets principaux ne me laissent pas vraiment le choix. Après, je ne suis pas fan de la francisation à outrance, dans le projet sécurité informatique notamment, il me faut parfois un certain temps avant de comprendre de quoi parle un article, alors même que je connais bien le sujet... Mais effectivement, les mots comme Gameplay possèdent des équivalents. Zandr4^[Moa ?] 1 septembre 2009 à 13:59 (CEST)

3. Il y a du pour et du contre avec les deux syntaxes possibles, selon les contextes:

• [[Standard Generalized Markup Language|{{lang|en|Standard Generalized Markup Language}}]] et {{lang|en|[[Standard Generalized Markup Language]]}} sont tous deux exacts et grosso modo équivalents quant à l'accessibilité du code HTML final.
• [[Standard Generalized Markup Language|{{lang|en|SGML}}]] est impropre : l'attribut title du lien, qui a un libellé en anglais « Standard Generalized Markup Language », n'est pas inclus dans le segment balisé comme étant en anglais
• {{lang|en|[[Standard Generalized Markup Language|SGML]]}} est pertinent : le title « Standard Generalized Markup Language » est dans le segment balisé comme étant en anglais

Chacune des deux syntaxe, une fois recommandée aux contributeurs, aura ses effets indésirables mais finalement marginaux dans le bénéfice global qu'il y à utiliser les modèles de langue. Ce n'est sans doute pas un point essentiel. --Temesis2 (d) 1 septembre 2009 à 14:19 (CEST)

D'ailleurs, j'ai un cas « amusant », à savoir le passage suivant : "se rapprochant ainsi de la série [[Silent Hill (série)|Silent Hill]]." Que fais-je ? Zandr4^[Moa ?] 1 septembre 2009 à 14:13 (CEST)

Ce cas de titre et de lien bilingues n'est pas (pour l'instant) balisable de manière simple pour les contributeurs via des modèles. Sans doute vaut-il mieux ne rien faire. --Temesis2 (d) 1 septembre 2009 à 14:19 (CEST)

D'ac. Autre problème non moins amusant : {{Voir homonymes|{{lang|en|Alone in the Dark}}}} a pour rendu

Pour les articles homonymes, voir Alone in the Dark. L'imbrication des accolades semble problématique. Zandr4^[Moa ?] 1 septembre 2009 à 14:21 (CEST)

Ce n'est pas l'imbrication des accolades, c'est le fait de passer à mediawiki un libellé de lien qui comporte des caractères interdits (les accolades), c'est à dire de tenter d'écrire [[{{lang|en|Alone in the Dark}}]], lequel donne [[Alone in the Dark]].

Il faudrait que les modèles comme {{Voir homonymes}} ne formattent pas le lien eux-mêmes, mais prennent un lien comme valeur de paramètre. On pourrait alors écrire {{Voir homonymes|{{lang|en|[[Alone in the Dark]]}}}}. --Temesis2 (d) 1 septembre 2009 à 14:37 (CEST)

D'accord. Un jour peut-être alors. Zandr4^[Moa ?] 1 septembre 2009 à 14:48 (CEST)

Le modèle {{Voir homonymes}} accepte un paramètre, mef, qui permet de mettre en forme le lien. Le test de ce paramètre a l'air de donner le résultat escompté. Litlok →m'écrire 1 septembre 2009 à 15:22 (CEST)

En effet. Bien vu. --Temesis2 (d) 1 septembre 2009 à 15:35 (CEST)

Suite à votre réponse plus haut sur les chiffres romains, et puisque vous avez l'air de détenir plein d'informations intéressantes :) : {{III}} a pour substitution dans le code source <span class="romain" title="Nombre 3 écrit en chiffres romains" style="text-transform:uppercase">III</span>

1. Pourquoi ce modèle inclut-il le style text-transform:uppercase alors que le contenu du span est déjà en majuscule ? Et quand bien même, cette propriété est probablement incluse dans la classe romain non ?
2. Les softs de "lecture de page" prononcent les attributs des paramètres titles des <span> ? Même si c'est le cas, ils ont dire aussi iii non ?
3. Ou sont prises toutes les décisions relatives à l'accessibilité, la mise en place des solutions... ?
4. Pourquoi est-il permis aux utilisateurs l'utilisation de balise Xhtml et de propriétés CSS directement ? (Je viens de m'en rendre compte. ) Si l'utilisation était restreinte à l'usage des différents modèles, n'obtiendrait-on pas un code plus propre ? (pages utilisateurs mises à part bien sûr)
5. Enfin, pourquoi Xhtml 1.0 Transitional et non Strict ? Ne serait-ce pas meilleur du point de vue accessibilité ? (Je précise que mon opinion sur le sujet n'est pas celle-ci...)

Zandr4^[Moa ?] 1 septembre 2009 à 14:48 (CEST)

6. Petit oubli : Dans l'introduction, on écrirait alors, en considérant le terme playstation comme du "vocabulaire courant pour le titre" : La ''{{lang|en|Playstation}} 2'' est une console de jeu[...] ou l'on resterait cohérent avec le titre et laisserait alors le terme playstation tel quel ?

7.Et un autre : On laisse les pages d'homonymie sans balise {{Langue du titre}} afin de conserver les liens vers les pages d'homonymie cohérents ? Zandr4^[Moa ?] 1 septembre 2009 à 14:55 (CEST)

1. La question avait été évoqué apparemment ici: Wikipédia:Atelier_typographique/juin_2009#Mod.C3.A8les_de_chiffres_romains. Il y a une accumulation de propriétés CSS (issue de l'historique touffue de ces modèles) qui se contredisent et qui annulent l'effet initial de petites capitales. Les modèles pourraient être corrigés dans un sens ou dans un autre.
2. L'attribut title n'est pris en compte par les aides techniques que sur un très nombre réduit d'éléments HTML (principalement les liens A dont ils permettent d'expliciter le libellé, les champs de formulaire dont ils permettent d'expliciter le rôle, les zones réactives AREA d'images cliquables, les éléments iframe). Sur un élément span ou div, le title sera dans la quasi totalité des configurations ignoré par les aides techniques. Il n'y est d'autre part pas accessible au clavier. Les modèles actuels de wikipédia utilisant le title de cette manière ne sont donc d'aucun bénéfice en matière d'accessibilité, et peuvent au contraire lui nuire, s'ils servent à véhiculer une information indispensable à la compréhension du contenu (par exemple, faire figurer une mention « XxX » dans le contenu le rend non accessible).
3. comme partout ailleurs dans WP ou dans les autres projets wikimedia : par les contributeurs, éventuellement au sein des projets concernés. Et en matière de développement de mediawiki ou de ses extensions, par les canaux habituels type bugzilla. Il n'y a pas de prise en compte spécifique de l'accessibilité à l'heure actuelle (bien que des idées en ce sens commencent à voir le jour: Proposal:Create an accessibility committee).
4. ce ne sont pas des balises XHTML directement autorisées, mais une syntaxe wiki avec un format de type HTML, qui est interprété par le parseur de mediawiki au même titre que la syntaxe dite « wiki ». Cette syntaxe de type HTML permet de dépasser les limites inhérentes de la syntaxe wiki, dont le vocabulaire et les possibilité d'expression sont nécessairement très réduites (sauf à vouloir la rendre à peu près incompréhensible). Concernant les styles CSS, le comportement de mediawiki est en revanche beaucoup plus proche d'une véritable syntaxe CSS autorisée : seules certaines propriétés spécifiques y sont interdites et filtrées par le parseur (en particulier les images de background, pour ne pas autoriser l'insertion d'images externes ou d'images posant des problèmes d'accès à sa licence). Il serait possible au parseur de n'autoriser le HTML et l'attribut style que dans les modèles, mais ce serait sans doute inutilement contraignant et complexe à mettre en oeuvre.
5. le choix XHTML ou HTML Strict ou transitionnel n'a pas d'impact direct sur l'accessibilité du contenu. Indirectement, les déclinaisons strictes invalident l'usage d'attributs et d'éléments de mise en forme qui sont eux-mêmes découragés par les normes d'accessibilité : on peut donc dire que le strict facilite de loin le suivi de l'accessibilité sur un point de détail. Mais il est tout à fait possible de produire le même niveau d'accessibilité en transitionnel. Pour mediawiki, et compte-tenu de l'époque à laquelle ce CMS a été lancé, le transitionnel était pertinent pour autoriser l'usage d'éléments de mise en forme simples pour les contributeurs (center par exemple). Pas indispensable, mais simple et pertinent.
6. utiliser le modèle dans l'introduction en cas de doute (la règle finale des normes d'accessibilité est de préciser la langue en cas de doute sur sa prononciation correcte dans la langue du contexte).
7. laisser des pages d'homonymies avec un titre bilingue sans modèle {{Langue du titre}}. Pour des pages d'homonymie sans mention en français entre parenthèses après un contenu dans une autre langue (y en a-t-il ?), il n'y a pas d'objection à utiliser le modèle. --Temesis2 (d) 1 septembre 2009 à 15:32 (CEST)

Merci beaucoup pour tout ceci.

7.Oui il y en a : Alone in the dark. De plus, Litlok a apporté une information supplémentaire plus haut sur les lien vers pages d'homonymie qui permettrait de résoudre le problème.

Bon, c'est clairement un travail pour bot. La seule chose que nous pouvons raisonnablement faire, c'est d'utiliser langue du titre, et lang sur une expression quand l'article de même nom n'existe pas (et ne peut donc pas servir de point de repère aux bots) Zandr4^[Moa ?] 1 septembre 2009 à 15:40 (CEST)

Améliorer la gestion des images par le CMS

Barack Obama, Sénateur de l'Illinois

En bossant sur l'accessibilité des images de la Wikipédia en anglais, quelques idées sont commencé à bourgeonner dans ma tête (comment ça je suis incapable de rester tranquille ?!). Voici une liste de défauts, concernant les images dotées d'un paramètre "thumb" (cas le plus courant dans les articles) :

1. étant le seul contenu dans le lien vers la page du fichier, et étant dotée d'une alternative textuelle vide par défaut (alt=""), les images ne sont par défaut pas accessibles ;
2. le lien vers la page de description de l'image ne contient aucune indication de destination, rien ne dit où l'on va atterrir avant d'avoir essayé ;
3. la légende est reprise dans l'attribut title du lien vers le fichier, ce qui peut être lu par les lecteurs d'écrans et dont peut faire doublon ;
4. lorsque l'image est décorative et n'apporte aucune information importante, ou que cette information est déjà donnée dans la légende, il faudrait laisser l'alternative textuelle vide mais ce n'est pas possible (voir point n°1)
5. Lorsque l'image est très longue, il faut donner accès à une description longue dans une page annexe, rôle de l'attribut longdesc. Mais un lecteur d'écran n'arrivera pas à discerner un lien longdesc lorsqu'il est présent dans un autre lien (ici le lien vers le fichier) ;
6. en-dessous du lien vers l'image figure une seconde image-lien non accessible, qui mène à la page de l'image.

Ça fait beaucoup de défauts... D'où mon envie de refondre la manière dont MediaWiki gère les images. Si on enlevait le lien sur image, et qu'on mettait en valeur le lien d'en-dessous (avec un intitulé explicite) ? Ça réglerait beaucoup de problèmes d'un coup. Prenons un exemple :

[[Fichier:BarackObamaportrait.jpg|180px|right|thumb|Barack Obama, Sénateur de l'Illinois]]

Actuellement, ce code wiki génère le code HTML suivant :

<div class="thumb tright">
<div class="thumbinner" style="width:182px;"><a href="/wiki/Fichier:BarackObamaportrait.jpg" class="image" title="Barack Obama, Sénateur de l'Illinois">
<img alt="" src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/BarackObamaportrait.jpg/180px-BarackObamaportrait.jpg" width="180" height="225" class="thumbimage" /></a>
<div class="thumbcaption">
<div class="magnify"><a href="/wiki/Fichier:BarackObamaportrait.jpg" class="internal" title="Agrandir">
<img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" /></a></div>
Barack Obama, Sénateur de l'Illinois</div>
</div>
</div>

Je propose qu'à la place MediaWIki génère :

<div class="thumb tright">
<div class="thumbinner" style="width:182px;">
<img alt="" src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/BarackObamaportrait.jpg/180px-BarackObamaportrait.jpg" width="180" height="225" class="thumbimage" />
<div class="thumbcaption">
<div class="magnify"><a href="/wiki/Fichier:BarackObamaportrait.jpg" class="internal" title="Agrandir">Accéder à la page de l'image
<img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" /></a></div>
Barack Obama, Sénateur de l'Illinois</div>
</div>
</div>

Je sais que l'impact sur le lecteur serait grand, et donc que cette modification est difficile à réaliser. Toutefois, cela rendrait immédiatement la plupart des images accessibles, et permettrait d'implémenter l'attribut longdesc. Les contributeurs se retrouveraient donc avec un nombre limité d'images requérant une alternative textuelle, et le travail serait à leur portée.

Mais tout n'est probablement pas aussi simple que ce que j'ai imaginé, alors j'aimerais vos avis et conseils. :-) Dodoïste ^{[ dring-dring ]} 3 septembre 2009 à 17:43 (CEST)

Ce n'est en effet pas si simple :

• Que les images proprement dites soient cliquables pour accéder à leur page et à leur version agrandie est un atout ergonomique important. Supprimer le lien sur les images comme dans votre proposition ci-dessus serait une régression. Il est préférable d'éviter autant que possible de revenir à l'époque où l'accessibilité était perçue comme un appauvrissement des sites.
• Pour améliorer l'accessibilité des thumb, il n'est pas nécessaire que les images cessent d'être des images liens. Il leur faut en revanche une alternative textuelle par défaut, non vide et fonctionnelle (« Agrandir l'image ») et qui sera rendue explicite en contexte (niveau AA d'accessibilité) grâce à la légende qui suit (Sous réserve de la pertinence de celle-ci, qui renvoit à l'amélioration des règles éditoriales avec un bénéfice plus large que l'accessibilité). Pour cela, le code HTML des thumb devrait inclure l'image et la légende dans le même élément de type bloc, idéalement un paragraphe (avec les span nécessaires pour une mise en forme identique, et non des div). Il serait en revanche vain de viser dans wikipédia le niveau d'accessibilité AAA avec des images-liens explicites hors contexte.
• le fait que le title du lien reprenne un contenu textuel présent à la suite de l'image (la légende) ne pose pas de problème d'accessibilité. En revanche, alternative textuelle de l'image et title du lien gagnent à avoir le même libellé, pour garantir le plus directement possible qu'ils fournissent la même information : le title serait donc, à la suite du point précédent, simplement « Agrandir l'image », lui aussi.
• Même analyse et même solution pour l'icône de loupe.
• « Mais un lecteur d'écran n'arrivera pas à discerner un lien longdesc lorsqu'il est présent dans un autre lien (ici le lien vers le fichier) ; » : non, il n'y a pas de difficulté de cette nature. Le longdesc d'une image lien ne pose pas de problème d'implémentation pour les lecteurs d'écrans actuels.
• L'implémentation de longdesc (ou sa réimplémentation) serait enfin inutile pour répondre aux exigences WCAG : la description étendue des images complexes est naturellement gérée éditorialement dans le contenu textuel dans lequel se trouve l'image, lorsque l'article est correctement rédigé. Il serait donc inutile d'ajouter de la complexité à la syntaxe et à l'édition. Il est préférable de favoriser des règles éditoriales au bénéfice plus évident aux yeux de tous les contributeurs : expliciter dans la légende ou dans le texte l'information apportée par une image complexe, fournir le tableau des données d'un diagramme, etc.)

--Temesis2 (d) 3 septembre 2009 à 18:18 (CEST)

Merci bien Temesis2. :-)

Ce que vous préconisez est une solution à laquelle j'ai également songée, mais que j'ai écartée car j'ai plusieurs incertitudes à son sujet. Quoique, je suis déjà certain que je me rangerai à votre avis après quelques éclaircissements.

• Bien noté, c'est en effet un point important à ne pas oublier. :-)
• Que fait-on dans le cas d'une image-lien qui possède une alternative textuelle à juste titre, comme Image:Fréquentation tour Eiffel.svg ? Doit-on écrire « Agrandir l'image ; Graphique de fréquentation : moins d'un million d'entrées annuelles jusqu'en 1945, puis une croissance presque continue jusqu'à 6 millions d'entrées annuelles après 2000 » ? En gros, doit-on toujours indiquer la destination du lien, et l'ajouter à l'alternative textuelle ? Si on le fait pour une image-lien décorative, pourquoi pas sur une image-lien importante ? Et alors, comment faire pour que le résultat soit intelligible ?
• Avoir la même alternative textuelle pour l'image-lien et l'icône-lien (« Agrandir l'image ») est un moindre mal, mais ce doublon n'est pas optimal, si ? Remarquez, je ne sais ce qu'on peut faire de mieux...
• Il me semble que les dernières versions de JAWS permettent de lire l'attribut title des liens, après configuration dans ses préférences. Toutefois, un contributeur anglais utilisant JAWS 8.0 (et ayant accès à cette fonctionnalité) a choisi de pas activer cette fonction, peut-être donc que ce n'est pas très utile.
• Concernant l'attribut longdesc, j'ai mal interprété les explications du W3C au sujet du longdesc : « Since an IMG element may be within the content of an A element, the user agent's mechanism in the user interface for accessing the "longdesc" resource of the former must be different than the mechanism for accessing the href resource of the latter. » Mais je n'ai pas compris quelle différence il faut faire entre le premier lien et le second du longdesc.

Merci d'avance pour les explications. Je reporterai probablement ces explications et la conclusion du débat sur la Wikipédia anglophone, dans le but d'obtenir un consensus nécessaire pour faire une demande aux développeurs sur bugzilla. :-) Dodoïste ^{[ dring-dring ]} 5 septembre 2009 à 21:22 (CEST)

Avant tout, il serait préférable de ne pas lancer une éventuelle modification supplémentaire du CMS pour les alternatives d'images en l'absence d'une véritable évaluation rigoureuse, menée sur un lot de projets de natures différentes. Or, pour être franc, les contributeurs, quelque-soit leur bonne volonté, n'ont pas les moyens méthodologiques et techniques de mener cette évaluation. Je vous invite donc à la prudence dans ce domaine.

Pour les autres points :

• la piste proposée ci-dessus part de l'observation des comportements des rédacteurs : les légendes sont aisément renseignées, les alternatives textuelle ne le sont pour ainsi dire jamais (sauf quand une automatisation par des modèles est possible) : leur rédaction place les quelques contributeurs éventuellement motivés face à un niveau de complexité rédactionnelle qui rend la chose impraticable à grande échelle. Les débats sur en:Wikipedia talk:Alternative text for images et le contenu touffu de en:Wikipedia:Alternative text for images montrent très bien les limites de l'exercice.
  Dans cette optique, il s'agit de fournir une alternative par défaut (mais modifiable par le rédacteur en cas de nécessité, cf norme ATAG) qui se « marie » avec la légende. Cela peut conduire à revoir des recommandations d'accessibilité comme celle à laquelle vous faites référence (qui provient des bonnes pratiques de cet atelier) et à renforcer celles qui concernent la rédaction des légendes. Autrement dit, il ne serait pratiquement plus demandé aux contributeurs de modifier l'alternative par défaut, mais ils seraient davantage guidés dans la rédaction des légendes.
  Mais ce n'est qu'une piste de réflexion, qui demande une évaluation approfondie pour être confirmée.
• « Avoir la même alternative textuelle pour l'image-lien et l'icône-lien » n'est pas un moindre mal, c'est une solution optimale en l'état de l'art, pour concilier les besoins d'ergonomie et d'accessibilité. Elle ne pose aucun problème ni aux utilisateurs, ni aux producteurs du site, bien au contraire.
• title et paramètres de Jaws : une démarche accessibilité ne peut pas et ne doit pas tenir compte des hypothétiques pratiques personnelles de paramètrage de leur aide technique par les utilisateurs. En effet, cela irait à rebours de la démarche d'abstraction nécessaire des innombrables contextes utilisateurs, sur des bases de suppositions fragiles. Il s'agit au contraire de rester au coeur de la démarche d'accessibilité, qui vise à fournir aux aides techniques un document exploitable, c'est à dire dit « accessible », à partir duquel c'est à l'aide technique et à l'utilisateur de faire chacun sa part de chemin. Nous avons coutume de dire, pour notre part, que la démarche d'accessibilité WCAG ne vise pas les utilisateurs, mais les outils.
  Pour vous donner un exemple simple des contradictions auxquelles conduirait une démarche reposant sur une évaluation des habitudes des utilisateurs: les implémentations propres à Jaws peuvent conduire à désactiver la prise en compte du title sur WP, essentiellement en raison des title de liens externes générés par mediawiki, qui n'ont pas d'intérêt (url du lien). En revanche, un utilisateur de Windows Eyes qui a le choix de consulter ces title non pas systématiquement en fonction d'un paramétrage, mais au cas par cas et à la volée, serait immédiatement pénalisé par un retrait d'information dans ceux-ci.

--Temesis2 (d) 6 septembre 2009 à 13:12 (CEST)

Merci pour ces explications. J'ai bien compris la nécessité de prudence, mais cela signifie-t-il qu'il vaut mieux que je ne fasse rien ? Comme vous l'avez rapidement compris, les recommandations sur les alternatives textuelles sont aussi délicates à écrire qu'à appliquer, et le consensus est très loin d'être atteint. Il serait certainement bénéfique de simplifier la tâche au petit monde qui s'arrache les cheveux pendant que j'écris ces lignes. :-)

Peut-on tout de même suivre votre suggestion, à savoir l'ajout de « Agrandir l'image » dans le title, les alternatives textuelles de l'image-lien ainsi que l'icône-lien ? L'ajout de cette alternative textuelle par défaut, sur toutes les images hormis celles dotées d'un attribut link (vide ou non), ne saurait poser un quelconque problème au sein des projets Wikimedia (du moins, j'ai beau me creuser la tête je n'en vois pas).

Renforcer les recommandations sur les légendes est également une bonne idée. Je m'occuperai de relayer vos explications pour poursuivre une discussion plus large sur la version anglaise, et nous tenterons d'y travailler. Bien à vous, Dodoïste ^{[ dring-dring ]} 8 septembre 2009 à 18:23 (CEST)

Il serait préférable de ne pas se précipiter sur une piste de solution où tout est à évaluer. Vu la difficulté des questions d'alternatives d'images et le nombre considérable d'autres améliorations possibles de bas niveau d'accessibilité, l'énergie des bonnes volontés peut trouver facilement à se dépenser pour résoudre d'autres problèmes dont les solutions sont plus évidentes (structures de tableaux, changements de langue, libellés de liens externes, accessibilité des contenus générés en javascript, utilisation de la couleur, structure de titrage de section incomplète...) --Temesis2 (d) 9 septembre 2009 à 08:09 (CEST)

Formulaire de recherche, une régression à corriger

Bonjour,
Si un contributeur a l'occasion d'intervenir sur Mediawiki:Common.js, une récente régression d'accessibilité pourrait être corrigée.

Après une évolution de Spécial:Recherche, la fonction javascript qui ajoute au formulaire les options de recherche avec des moteurs externes a été à son tour mis à jour.

Malheureusement, lors de cette modification de Mediawiki:Common.js, il n'a pas été prêté attention au balisage nécessaire à l'accessibilité des champs input radio et de leurs étiquettes : les éléments label for des étiquettes ne sont plus présents dans le code généré.

Le script antérieur montre comment générer le code correct. Les liens a peuvent rester présents dans les éléments label. Ainsi, le code généré actuel :

<span>
   <input type="radio" id="searchengineRadio-mediawiki" onfocus="changeSearchEngine(this.value)" value="mediawiki" name="searchengineselect" />
</span>
<label>Recherche interne</label>

<span>
   <input type="radio" id="searchengineRadio-exalead" onfocus="changeSearchEngine(this.value)" value="exalead" name="searchengineselect"/>
</span>
<a href="http://www.exalead.com/search/wikipedia/results/?q=foo&language=fr">Exalead</a>

Devrait être:

<span>
   <input type="radio" id="searchengineRadio-mediawiki" onfocus="changeSearchEngine(this.value)" value="mediawiki" name="searchengineselect" />
</span>
<label for="searchengineRadio-mediawiki">Recherche interne</label>

<span>
   <input type="radio" id="searchengineRadio-exalead" onfocus="changeSearchEngine(this.value)" value="exalead" name="searchengineselect"/>
</span>
<label for="searchengineRadio-exalead"><a href="http://www.exalead.com/search/wikipedia/results/?q=foo&language=fr">Exalead</a></label>

--Temesis2 (d) 8 septembre 2009 à 07:02 (CEST)

Je crois que c'est bon avec cette modif. Litlok →m'écrire 8 septembre 2009 à 09:27 (CEST)

Parfait. Merci ;-) --Temesis2 (d) 9 septembre 2009 à 07:35 (CEST)

Quel usage éventuel pour l'attribut alt de math ?

La syntaxe <math> qui permet de générer des contenus mathématiques à partir d'un saisie TeX génère par défaut une image (à moins que le contenu ne soit assez simple pour être restitué en texte HTML).

Cette image a, par défaut, la saisie TeX comme contenu de son alternative textuelle. Cependant, il est possible d'indiquer l'alternative de son choix à l'aide d'un attribut alt:

• <math>\sum_{k=1}^n k^2</math> produit par défaut l'image $\sum _{k=1}^{n}k^{2}$ dotée de l'alternative alt="\sum_{k=1}^n k^2". Celle-ci peut être pertinente pour un public suffisamment spécialisé, ayant au moins une connaissance minimale de TeX. On pourrait supposer que ce public est justement celui qui s'intéresse aux articles où les développements mathématiques sont conséquents.
• <math alt="Somme de 1 à n de etc.">\sum_{k=1}^n k^2</math> produit la même image $\sum _{k=1}^{n}k^{2}$, mais dotée cette fois de l'alternative alt="Somme de 1 à n de etc.". La saisie de cette alternative est évidemment contraignante, le résultat peut être moins clair pour un contenu complexe et un public habitué à TeX. Mais elle serait sans doute pertinente pour des emploi plus isolé de <math>, dans des articles moins spécialisés.

Il est donc difficile d'évaluer l'utilité de cette éventuelle alternative, les cas qui pourraient être éventuellement concernés, ou encore l'intérêt que sa saisie pourrait avoir aux yeux des contributeurs. Des avis seraient donc les bienvenus.

--Temesis2 (d) 9 septembre 2009 à 13:56 (CEST)

Je ne connaissais pas l'attribut alt pour <math>. C'est une bonne chose. Pour avoir pas mal joué avec LaTeX dans ma jeunesse, je pense pourvoir dire que quand l'expression est complexe, la syntaxe LaTeX peut être très difficile à suivre, même pour un spécialiste : que celui qui n'a jamais oublié une accolade ou tapé par erreur _ au lieu de \ me jette la première pierre (zut, pour une fois que je pouvais utiliser kbd, mediawiki ne le supporte pas...). Dans le cas des fractions imbriquées par exemple (somme de fractions aux numérateur et dénominateur), il peut être délicat de se forger une image mentale de l'équation. Pour mémoire, un autre outil de traduction, TeX4ht, place par défaut dans le alt une représentation visuelle (en art ASCII, avec des /, | et \ pour indiquer une intégrale ou le symbole ∑ par exemple) de l'équation. C'est encore pire dans un lecteur d'écran, mais cela relève d'une bonne intention : quand les images sont indisponibles, les équations restent consultables dans un navigateur grapĥique. Je crois donc que dans les cas simples, renseigner le alt pour le non-spécialiste est utile, et dans les cas complexes, cela est aussi utile pour les spécialistes. Enfin, premièrement qui dit spécialiste des maths ne veut pas dire spécialiste en LaTeX (c'est probable a priori, c'est tout...). Et deuxièmement, plus généralement, on ne devrait pas d'hypothèse sur le profil des personnes qui consulteraient un article spécialisé. Par conséquent, j'aurais tendance à recommander l'utilisation systématique du alt. Litlok →m'écrire 10 septembre 2009 à 10:15 (CEST)

Du bon usage de Lang

Bonjour. Travaillant souvent sur les articles consacrés à la musique anglo-saxonne, je voudrais savoir si le modèle Lang doit être apposé sur les noms de chansons, d'albums, bref, les noms propres (cette question concerne aussi les jeux vidéo, par exemple). Un exemple : Abbey Road (album) : clairement constitué de deux mots anglais (abbaye et rue), mais il s'agit d'un nom propre. Autre exemple : The Beatles: Rock Band. Doit-on utiliser Lang dans ces cas-là ? Merci. Zakke (d) 9 septembre 2009 à 21:14 (CEST)

Tu devrais trouver des débuts de réponse dans cette section et celle-là. Ensuite, quelqu'un sera probablement en mesure de te donner une réponse plus fine pour les détails. Amicalement, Dodoïste ^{[ dring-dring ]} 9 septembre 2009 à 22:32 (CEST)

En général, on n'indique pas le changement de langue pour les noms propres. Je crois (avis personnel) que c'est pour faire écho à la manière dont les média oraux locaux ou l'usage en français énoncent ces noms propres, qui les rendraient incompréhensibles dans leur langue d'origine (je pense par expérience personnelle et par exemple à Huygens ou Khatchatourian...). On n'indique pas non plus ce changement dans les mots passés dans le langage courant. Il n'est donc pas nécessaire, je pense, d'indiquer un changement de langue pour les Beatles. Mais Abbey Road n'est pas entré dans le langage courant : il faut donc indiquer le changement de langue. Le cas est plus subtil avec Rock band. Rock est dans le langage courant, band aussi (dans l'expression jazz band). Mais prononcés à la française, je ne sais pas si cela reflète vraiment le titre original: rroque bande... Dans ce cas précis, je crois que l'on est dans la zone grise, où tout dépend du contexte. Je dirais que si ce titre figure dans un paragraphe, isolé, alors il ne faudrait pas le baliser. Mais s'il figure dans une liste de titres comme abbey road, alors il risque de faire « tache » si jamais c'est le seul prononcé à la française : par conséquent, dans ce contexte-là, il faudrait indiquer le changement de langue. Mais je le répète, nous sommes avec ce titre précis dans la zone grise, et les interprétations peuvent varier. Litlok →m'écrire 10 septembre 2009 à 09:59 (CEST)

Merci pour cette réponse, mais ce que tu m'expliques me semble contradictoire et très confus. Tu commences par dire qu'on peut négliger les noms propres (confirmé dans une discussion indiquée par Dodoïste : « nom propre : aucune obligation de mettre l'attribut lang », dixit Lgd). Puis, tu t'attaques au cas des mots passés dans le langage courant, en prenant comme contre-exemple Abbey Road, pour conclure que Lang doit être apposé à ce dernier. Or, Abbey Road peut très bien être considéré comme un nom propre ! En fait, c'en est un : dans le contexte, Abbey Road n'est pas une rue, c'est un disque de musique. Idem pour Rock Band, en fait. Le laxisme sur les noms propres n'est donc plus d'application ? Je suis perdu. En tout cas, je sais maintenant qu'il n'y a pas de solution systématique à mettre en place et qu'il faut y aller au cas par cas, merci pour ça ! Zakke (d) 10 septembre 2009 à 14:14 (CEST)

On entend par nom propre les noms de personnes, de lieux célèbres (Boston...), ce genre de choses... Abbey Road n'est pas un nom propre, c'est un titre d'œuvre qui porte des majuscules Litlok →m'écrire 10 septembre 2009 à 14:32 (CEST)

Quand tu dis « on entend », tu veux dire les gens en général ou bien ceux qui s'intéressent à l'accessibilité ? Parce que ma définition de nom propre inclut les titres d'œuvres... Zakke (d) 10 septembre 2009 à 15:38 (CEST)

Personnellement j’ai pris le parti (et en l’absence de consigne précise sur le point précis des noms propres) de mettre le modèle selon la prononciation (parce que un des buts de ce modèle est d’aider la synthèse vocale). Donc oui pour FBI, non pour CIA par exemple (mais certains prononcent les deux à l’anglaise !). Ceci dit, je viens récemment de me faire remonter les bretelles sur de.wiki pour cela d’ailleurs. Donc je te conseille de faire comme tu veux et de ne pas te prendre la tête . PS : il y a le même problème en taxinomie. Cdlt, Vigneron * ^discut. 10 septembre 2009 à 19:32 (CEST)

Mais non Vigneron, tout le monde sait que FBI signifie Fausse Bonne Idée. Quel vieux jeu tu fais. Dodoïste ^{[ dring-dring ]} 11 septembre 2009 à 11:21 (CEST)

Le critère de succès sur les changement de langue, tel qu'il est défini par la norme internationale WCAG2, rend effectivement indispensable un travail de décision au cas par cas par le rédacteur. L'essentiel est cependant pour celui-ci de se souvenir :

• que l'objectif est de permettre la prononciation des contenus de manière compréhensible, et que l'objectif prime sur la lecture formelle de ses règles d'application : dans la « zone grise », la question n'est pas de savoir si « Abbey Road » ou « Rock band » sont des noms propres ou pas. Elle est de savoir quelle information donner pour que ces expressions soient accessibles.
• qu'en cas de doute sur la pertinence d'un changement de langue, il faut en effet s'interroger sur le rendu vocal dans la langue par défaut (ici, en français). A moins que le terme ne soit effectivement entré dans l'usage avec une prononciation francophone très différente de sa prononciation dans sa langue propre, l'indication du changement de langue ne causera pas de dommage, si elle n'apporte pas de bénéfice évident (la « zone grise »). On peut également se souvenir qu'une indication de changement de langue n'influe pas seulement sur le rendu vocal : elle bénéficie par exemple aux outils de traduction automatique. Or, ceux-ci sont sans doute plus demandeurs d'indications systématiques, indépendamment des questions de prononciation.

Sinon, le rendu de « Rock band » dans un moteur de synthèse vocal en français, sans changement de langue, est « roc ban ». Le rendu de « road » est « ro-a-d' ». Le modèle {{lang}} n'y est donc pas superflu. En fait, ce qui compte dans cette notion de terme passé dans la langue, c'est la probabilité:

• qu'il ait une prononciation francisée coutumière
• ou qu'il soit géré de manière spécifique par les synthèses vocales (cas classique: « smoking » au sens du vêtement ne nécessite pas de mention de changement de langue)

Enfin, pour compléter l'avis de Litlok ci-dessus : il peut être préférable, quelque-soit le choix adopté pour une expression donnée, de maintenir le même choix à travers les différents contextes où elle se trouvera utilisée avec le même sens. --Temesis2 (d) 11 septembre 2009 à 05:21 (CEST)

Très bien, je comprends mieux maintenant le pourquoi du comment (on devrait ajouter une synthèse de cette discussion sur la page d'aide du modèle...). Pour le fun : on doit apposer Lang à Mr. Moonlight mais pas forcément à Eleanor Rigby. J'ai bon ? Et « fun » n'en a pas besoin, bien sûr ! Zakke (d) 11 septembre 2009 à 22:24 (CEST)

Oooké, voilà, là c'est clair ! Ça me rassure, j'ai donc pas abondamment utilisé lang récemment pour rien. Merci pour les explications, Jean-Fred (d) 11 septembre 2009 à 23:43 (CEST)

Tentative de résumé :

• règle de base : tout les mots étrangers et prononcés « à l’étrangère » (donc pas smoking par exemple) doivent prioritairement utiliser ce modèle,
• pour les autres termes prononcés « à l’étrangère », le modèle est utile mais l’utilisation est moins prégnante (de plus, des variations locales peuvent créer des contestations),
• pour les mots étrangers prononcés à la française (CIA par exemple en France) le modèle est inutile et parfois même dommageable.

Cdlt, Vigneron * ^discut. 14 septembre 2009 à 17:05 (CEST)

Script pour améliorer l'ergonomie des boîtes déroulantes

Bonjour. Des témoignages et tests utilisateur montrent que les boîtes déroulantes sont très peu intuitives pour les nouveaux, qui ont de la peine à comprendre qu'on peut les dérouler et comment y parvenir. Suite au sondage bistrotier du mois précédent, j'ai tenté de poursuivre l'amélioration des boîtes déroulantes en tenant compte des avis formulés. Nous étions donc arrivés à un modèle comme suit :

Liste des capitales d'Europe afficher

Liste des capitales d'Europe masquer

Exemple de contenu : Berlin ...

Toutefois, Lgd étant devenu moins disponible il me manquait quelqu'un capable de réaliser le JavaScript. Donc je me suis tourné vers la Wikipédia anglophone, et j'y ai notamment demandé l'aide de Cacycle, auteur de WikEd. Cacycle a pondu un magnifique Javascript, disponible sur en:User:Cacycle/navbox demo. Son adoption est en cours de discussion sur la Wikipédia anglophone, mais la discussion traîne passablement, alors c'est pas pour tout de suite.

Il me faudrait quelqu'un capable d'adapter le script de Cacycle, pour qu'il soit fonctionnel sur la Wikipédia francophone. On pourrait ensuite discuter de son implémentation, ou à défaut le mettre à disposition en tant que Gadget. Lorsque j'ai essayé de le mettre dans mon monobook, bien que j'aie le bouton centré et avec le bon intitulé, il manque l'icône. De plus, lorsque la souris passe sur le lien, il ne prends pas l'apparence d'un bouton comme sur en.wiki. Merci de votre aide. :-) Dodoïste ^{[ dring-dring ]} 11 septembre 2009 à 11:51 (CEST)

Je viens de tester (Firefox 3.5) : les palettes de navigation ont l'air de fonctionner correctement (sans même effectuer les changements dans le modèle). Par contre, les boîtes déroulantes pas du tout. Sachant que dans MediaWiki:Common.js, ce sont deux scripts distincts, es-tu sûr que le script de Cacycle couvre bien les deux ? Dr Brains (d) 13 septembre 2009 à 03:48 (CEST)

Merci Dr Brains. :-) Le script de Cacycle couvre probablement uniquement les palettes de navigation. Le script fonctionne parfaitement bien avec la skin modern. Par contre, le bouton apparaît en double sur monobook, et l'icône manque sous vector. C'est du moins ce que j'ai obtenu en testant sous IE8 et Opera 9.63. Merci de ton aide. Dodoïste ^{[ dring-dring ]} 13 septembre 2009 à 04:07 (CEST)

Dans l'immédiat, un passage par l'atelier accessibilité serait une étape nécessaire du recettage de ce script (un recettage a-t-il été prévu ?) Tout en étant une amélioration ergonomique, c'est aussi une régression majeure d'accessibilité : prendre le temps de quelques itérations serait prudent.

Sur le fond : le cas de ce script n'est pas dramatique en soi, mais c'est un bon exemple de ce qui devrait être fait et qui fait défaut aujourd'hui. Les projets Modèle et Javascript actuel se résument à des pages de requêtes : ils n'ont ni objectifs qualité, ni guidelines (nommage, scriptage non intrusif, accessibilité, etc.), ni outils de recettage (un modèle majeur ou un script devrait satisfaire à une checklist qualité avant d'être basculé en front).

Parmi les conséquences, il y a:

• le fait que tout repose encore sur le hasard des participations personnelles, faute de projets structurés et d'outils permettant le « passage de relais » ou permettant à un intervenant d'être aidé sur les multiples aspects d'un modèle/script.
• l'absence de coordination entre quelques projets qui ont un impact majeur sur les fonctionnalités, l'ergonomie, l'accessibilité du contenu.
• la production inévitable de modèles ou de fonctionnalités problématiques quand les intervenants cherchent à améliorer la qualité globale.

Ce cas précis pourrait être un bon déclencheur pour améliorer la face obscure (« technique ») des contributions à WP. C'est un sujet essentiel sur lequel les contributeurs auront peut-être prochainement l'occasion de discuter de vive voix. --Temesis (d) 13 septembre 2009 à 08:17 (CEST)

Étant donné que vous aviez désiré reporter le travail que nous avions commencé à ce sujet, je ne savais si vous seriez intéressé à donner un coup de main. Content d'apprendre que c'est le cas. Je me suis dit que si vous vouliez donner un coup de papatte, vous n'auriez pas manque les diverses discussions et le sondage que j'ai prévu d'initier une fois le script adapté. Et j'aurais probablement laissé un mot sur l'atelier avant le déploiement.

• Cacycle m'a dit avoir conçu le script pour qu'il affiche une image (comme je leur ai suggéré, et avec l'appui d'un utilisateur de JAWS 8.0), image que selon lui un lecteur d'écran devrait ignorer. Je ne m'y connais pas assez pour savoir si c'est en effet le résultat produit. Concernant les autres problèmes que pourrait causer ce JavaScript, je manque d'outils pour évaluer quoique ce soit.
• Bien que j'aie parlé de WAI-ARIA à Cacycle, il ne m'a rien répondu à ce sujet. Je suppose donc qu'il n'a rien fait dans ce sens.
• Le mois précédent, vous avez exprimé le désir d'inclure une amélioration des tableaux de mise en forme utilisés dans les palettes de navigation. Toutefois, vous avec indiqué que cela serait un lourd travail, et impliquerait de remplacer manuellement chacun des tableaux. La modification du script étant plus rapide et simple, je propose d'agir en deux temps. D'abord se centrer sur la côté le plus important de cette modification, qui est l'utilisabilité, car la modif touche la plus grande partie des utilisateurs. Et ensuite, affiner le travail en améliorant les tableaux de mise en forme.

Voilà l'état de la situation. Merci d'avance de votre aide. Il va de soi que je me chargerai de répercuter les améliorations et discussions produites ici sur en.wiki, afin que ces améliorations d'ergonomie et d'accessibilité aient le plus d'impact possible. Amicalement, Dodoïste ^{[ dring-dring ]} 13 septembre 2009 à 19:00 (CEST)

Le test qui fait défaut ici (pourtant indiqué par les bonnes pratiques d'accessibilité) est simple, et il peut être facilement popularisé auprès des contributeurs auteurs de script: tester systématiquement la fonctionnalité au clavier.

Ici, le code généré :

<span title="Click to show hidden content" onclick="javascript:collapseTableTest(0)" class="collapseButtonTest" id="collapseButton0">
  <a class="collapseButtonContent">
   <span class="collapseButtonShow"> </span>
   show
  </a>
</span>

...interdit au lien show/hide de prendre le focus clavier et lui interdit d'être reconnu et annoncé comme un lien dans un lecteur d'écran.

Pour y remédier, en allant au plus simple :

• ne jamais utiliser de gestionnaire d'évènement onclick sur un span (ou sur tout autre élément div, img, etc.) Pour que onclick soit universel et ne nécessite pas de gestion de son équivalent clavier, l'utiliser systématiquement sur un élément a doté d'un attribut href="#".
• compléter la fonction par un return:false; pour éviter l'activation du href.

Voir SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons (Attention : cette ressource comporte une erreur par ailleurs dans l'exemple 4 où un attribut alt et non title doit être utilisé)

Dans le même ordre d'idée, ne pas utiliser l'attribut title d'un span pour expliciter le rôle d'un lien. N'utiliser title que sur des éléments a, input, textarea, area, iframe.

--Temesis (d) 14 septembre 2009 à 05:29 (CEST)

Merci bien, c'est noté. :-)

La question de l'attribut title sur un span me rapelle <span title="Voir toutes les sous-pages de discussion">+</span>, bricole temporaire que Lgd avait mis en place. Peut-être auriez-vous une meilleure solution pour ce cas précis ? Sachant qu'il est inclus sur toutes les pages de discussion, il me semble qu'une amélioration aurait un gros impact sur l'accessibilité. Et j'aime les modifications à gros impact. ^_^

Voilà, j'ai reporté l'information à Cacycle, et lui ai indiqué les recommandations du W3C que vous m'avez montré. J'espère qu'il les suivra, mais vu que ça a l'air d'être un détail facile à régler, je pense qu'il le fera.

J'avais oublié de configurer mon vector.css. Ok, en route vers le déploiement.

Le script qui sera déployé est Utilisateur:Dodoïste/Boîte déroulante.js. Je n'y connais pas grand-chose en JavaScript, alors il faudrait me dire concrètement quel bout de script il faut que je remplace par quoi. J'ai eu beau chercher à comprendre, c'est indigeste. :D Dodoïste ^{[ dring-dring ]} 15 septembre 2009 à 17:09 (CEST)

J'ai lancé le sondage : Wikipédia:Sondage/Utilisabilité et accessibilité des palettes de navigation. Nous peaufinerons le script comme expliqué ci-dessus avant de le déployer. :-) Dodoïste ^{[ dring-dring ]} 21 septembre 2009 à 17:47 (CEST)

J'ai eu beau faire des tests, remplacer tous les éléments span par a, et ajouter un href="#", ça ne marche pas. J'arrive à utiliser ce script avec le clavier sous Opera 10, mais pas sous IE8 ni Opera 9.64. Et mes modifications n'y changent rien. Help please ! Dodoïste ^{[ dring-dring ]} 26 septembre 2009 à 00:10 (CEST)

Lecteurs d'écran et UTF-8

Bonsoir !

Je n'ai pas de synthèse vocale sous la main ce soir, et ne suis pas sûr d'avoir le temps de tester demain. Je n'ai pas non plus de plage Braille... et de toute manière serais incapable de vérifier si la restitution est correcte ! Vu que sur Wikipédia nous avons la chance d'avoir des articles intitulés Tōkyō, Coşkun Kırca ou Tự Đức, je me demandais si les lecteurs d'écran pouvaient restituer ce genre de contenu et si oui, comment. Cela s'étend aussi aux textes publiés dans des alphabets non latins (voir les intros de bon nombre d'articles sur des sujets chinois, japonais ou russes). Pour une synthèse j'imagine que cela est envisageable (sous réserve au minimum d'avoir bien indiqué la langue), bien que j'aie des doutes sur le rendu avec les outils actuels. Mais comment une plage Braille « digère-t-elle » ce genre de contenu ? Que se passe-t-il ? Litlok →m'écrire 14 septembre 2009 à 23:21 (CEST)

... et je jure que n'avais pas fini ma lecture quand j'ai écrit le message ci-dessus (ne cherchez pas, c'est hors-Wikipédia...) ! Litlok →m'écrire 15 septembre 2009 à 00:02 (CEST)

Si l'utilisateur ne dispose pas d'extensions spécifiques adaptées au traitement élargi d'Unicode par le lecteur d'écran, le rendu peut être incompréhensible ou nul, quand il ne s'agit pas de diacritiques communes. Par exemple, pour une installation par défaut de Jaws 9 :

• Tự Đức est lu : « T symbole ? C »
• ( 嗣德帝 ) est lu « parenthèse gauche parenthèse droite ».
• Tōkyō (東京) (codé Tōkyō ({{lang|ja|東京}}) est lu « Tokyo parenthèse gauche japonais parenthèse droite » (grâce à la présence du modèle {{lang}} autour de 東京, la langue du contenu est annoncée, même si celui-ci n'est pas lu).

D'autres configurations de Windows ou de Jaws donneront des résultats variables, mais toujours avec des pertes d'informations en l'absence des extensions nécessaires (voir même en présence de celles-ci pour certains types de caractères).

Le problème est similaire sur une tablette, où les caractères ne seront pas restitués ou seront incorrectement transcrits.

Enfin, ce problème se pose également pour les symboles typographiques : le caractère ↑ utilisé pour les retours de notes, par exemple (mais il ne serait dans tous les cas pas explicite et nécessiterait donc un title). --Temesis (d) 15 septembre 2009 à 08:34 (CEST)

Pour donner un point de vue plus global :

• En dépit des apparences, l'utilisation étendue d'Unicode ne pose pas aux utilisateurs de lecteurs d'écran un problème réellement différent de celui posé à tous les visiteurs : la nécessité d'étendre des fichiers index de prononciation est identique à celle d'installer des polices de caractères Unicode. La présence de contenus comme Tự Đức ou 東京 (quand la langue est bien renseignée) ne désavantage pas les utilisateurs handicapés dotés des aides techniques appropriées. de ce fait, la question ne tombe sous le coup d'aucun critère WCAG, car elle est uniquement éditoriale : ce qui rendra ces contenus éventuellement plus aisés à restituer ou à comprendre pour tous les utilisateurs bénéficiera de la même manière aux utilisateurs en situation de handicap.
• En revanche, l'utilisation de symboles graphiques Unicode peut poser des problèmes d'accessibilité, leur interprétation étant essentiellement visuelle (faute de pouvoir les traiter comme des abréviations). Ce qui, pour le coup, tombe sous le coup de WCAG.

--Temesis (d) 15 septembre 2009 à 09:34 (CEST)

Ortho 1990

Bonjour. J'ai déjà évoqué, dans l'oracle et au bistro et même en PdD d'une catégorie qui a été supprimée, l'utilité qu'il y aurait à signaler aux usagers qu'un article est écrit de nouvelle orthographe afin qu'il n'y ait pas d'ambigüité et qu'on ne confonde pas une nouvelle forme avec une faute, au préjudice de WP. Je signale que le problème de la nouvelle ortho va s'accentuer petit à petit (voir, par exemple, [3]

Je signale aussi aux amateurs de la "nouvelle orthographe" l'existence du logiciel Recto développé depuis mars 2009 par le Cental, centre d'informatique pour l'étude du traitement des langues rattaché à la Faculté de philosophie et lettres de l'Université catholique de Louvain-la-Neuve. Ce logiciel est à la disposition des particuliers sur internet et donne, outre la rectification du texte encodé, la justification des modifications. Cela se passe ici.

Le Cental pourrait être intéressé par un débat sur les possibilités d'amélioration et de diffusion de son logiciel ; moi, je trouverai intéressant que WP puisse présenter ce genre de service. Donc je vous en parle... --Égoïté (d) 15 septembre 2009 à 13:43 (CEST)

Je ne vois pas le rapport avec l'accessibilité du web, à savoir par exemple l'aide aux handicapés visuels. Amicalement, Dodoïste ^{[ dring-dring ]} 15 septembre 2009 à 14:46 (CEST)

Si. Une implémentation sur Wikipédia d'un outil comme celui utilisé par http://www.lesoir.be (également illustré par la page de résultat de http://www.uclouvain.be/recto-verso/results.html ) aurait en effet un impact sur l'accessibilité (par exemple, l'accessibilité clavier de la fonctionnalité, les questions éventuelles liées à AJAX, aux icônes...). Les différentes implémentations signalées montrent des niveaux d'accessibilité déjà assez variables --Temesis (d) 18 septembre 2009 à 10:37 (CEST)

J'ai pris le terme accessibilité au premier sens du mot, et j'ai sans doute tort. Je pensais notamment aux seniors pour qui la nouvelle orthographe peut être... d'autant plus déroutante que le vocabulaire spécialisé est fortement présent dans WP (Tu peux m'expliquer "implémentation", STP, Temesis ?). Les gens de cet âge utilisent de plus en plus le web et, de lecteurs, ils pourraient davantage devenir des contributeurs précieux par leurs connaissances, leur expérience, le temps dont ils disposent. Améliorer l'accessibilité de la langue devrait les encourager, me semble-t-il. --Égoïté (d) 18 septembre 2009 à 12:12 (CEST)

Les sens multiples du terme « accessibilité » sont déjà très présents et particulièrement variables sur Wikipédia. Votre remarque en crée un nouveau : être dérouté par une orthographe. Ce sens est très loin des objectifs de ce projet, qui part d'une définition formelle donnée de l'accessibilité (utilisateurs en situation de handicap moteur etc.) et ne s'ouvre guère au-delà de la notion plus générale de handicap technique (bas-débit par exemple). En gros: il est indifférent au contenu et à la forme orthographique de celui-ci.

En fait, la gestion explicite de cette question de conventions orthographiques semble surtout une contrainte supplémentaire ajoutée à l'interface : elle nécessite de nouvelles fonctionnalités (le bouton pour accéder à l'une ou l'autre version orthographique) qui posent ici le même problème que n'importe quelle autre nouvelle fonctionnalité. C'est en ce sens qu'il faut lire la réponse: les « implémentations de Recto posent des problèmes d'accessibilité » : une implémentation est le recours à une fonctionnalité sur une site (les boutons, liens etc. pour basculer d'une version ortho à une autre, accéder aux explications associées à la nouvelle ortho).

Sauf hypothèse (improbable) d'implémentation de Recto sur WP, ce n'est donc pas un problème d'accessibilité sur le fond. En revanche, Recto a un besoin évident d'assistance à l'accessibilité de ses implémentations sur des projets Web. Je crois savoir personnellement que cette question est délicate et rejoint des préoccupations déjà signalées en de tout autres lieux que WP.

Enfin, une remarque : ici, l'utilisation de l'une ou l'autre des conventions orthographique n'a, semble-t-il, aucune conséquence sur le sens ? Il s'agit donc uniquement d'orthographe immédiate formelle, et non de problèmes de compréhension du contenu ? Il serait curieux qu'une réforme orthographique aboutisse à des ambigüités de compréhension du contenu. En ce sens, ces réformes orthographiques n'ont qu'un impact négligeable sur la gestion de l'accessibilité des contenus. Que des lecteurs se posent des questions face à l'emploi de l'une ou l'autre orthographe ne les empêche pas d'accéder à l'information. Que leurs doutes sur l'orthographe les amène à réduire leur confiance dans la fiabilité de cette information est un problème qui dépasse de très loin Wikipédia. --Temesis (d) 20 septembre 2009 à 13:14 (CEST)

Merci Temesis pour l'information, je comprends mieux. Effectivement, c'est un problème formel au départ, mais le... caractère {{clin}} de certains fait qu'ils abandonnent la lecture car rebutés par la forme (on me l'a déjà confessé). Bien à vous, --Égoïté (d) 20 septembre 2009 à 16:44 (CEST)

abbr enfin implémenté

Bonjour,

La récente mise à jour de mediaWiki apporte une nouvelle implémentation importante pour l'accessibilité du contenu : il est à présent possible de produire l'élément HTML abbr permettant d'expliciter la signification d'un sigle, d'une abréviation ou d'un acronyme.

Les Bonnes pratiques ont été mises à jour pour en indiquer l'usage et la syntaxe. --Temesis (d) 18 septembre 2009 à 04:57 (CEST)

Note: Un des usages potentiels de ce nouveau tag : les en-têtes de tableaux de données abrégés, comme c'est le cas notamment :

• dans de nombreux modèles concernant le sport (exemple)
• pour les noms des mois (exemple)
• dans des calendriers...

Autres cas d'école:

• les modèles d'icônes de langues et d'extension de fichier.
• les modèles de numération en chiffres romains (où les title devraient être réduits à l'information pertinente, c'est à dire le chiffre seul et non la mention inutilement verbeuse « Nombre XXX écrit en chiffres romains »).

--Temesis (d) 18 septembre 2009 à 05:12 (CEST)

Autre note : il serait possible et sans doute nécessaire de définir dans MediaWiki:Common.css une classe applicable à l'élément abbr, qui permette aux contributeurs ou à certains modèles de ne pas afficher le comportement actuel de celui-ci (soulignement en pointillé, curseur de souris spécifique : FOO), afin de désamorcer de prévisibles conflits de préférences personelles. --Temesis (d) 18 septembre 2009 à 05:44 (CEST)

Je viens de voir ça (j’ai un plugin sur Firefox qui entre un peu en conflit avec cette balise du coup je vois des explications un peu partout ).

Je plussoie Temesis, surtout que le pointillé me sert déjà pour signaler les redirections. Cdlt, Vigneron * ^discut. 18 septembre 2009 à 08:26 (CEST)

Il se pose enfin la question de l'usage « éditorial » de ce nouveau tag, hors modèles. Un exemple : le sigle WCAG dans cette page. Les questions de fond sont :

• le choix d'utiliser abbr ou non est complexe et susceptible de perdre les contributeurs. Mais dans le doute, à part le problème de verbosité inutile dans un lecteur d'écran ou des cas délicats de langue de l'abréviation et du title, il n'est pas très grave. C'est un cas similaire à celui des modèles de changement de langue qui risquent rarement de faire du mal quand ils ne font pas de bien évident.
• l'acceptation d'un surcroît de complexité de la syntaxe des articles est sans doute le problème le plus aigu.
• à nouveau, la question des conflits improductifs sur les goûts de chacun, les uns n'ayant pas d'objection au rendu avec pointillés et les autres étant susceptibles de trouver cela peu admissible.

L'exploitation via les modèles semble déjà prioritaire et plus évidente.

--Temesis (d) 20 septembre 2009 à 11:38 (CEST)

Je viens de l'essayer, il ne fonctionne pas de cette manière : {{lang|en|<abbr title="Manoj Night Shyamalan Foundation">MNS Foundation</abbr>}}. Cordialement — Steƒ ^{๏̯͡๏﴿} 20 septembre 2009 à 11:53 (CEST)

J'ai par ailleurs effectué ceci sur mediawiki:common.css : [4]. Cela convient-il ? — Steƒ ^{๏̯͡๏﴿} 20 septembre 2009 à 11:58 (CEST)

Supprimer totalement le rendu par défaut de abbr, à commencer par les pages de diff, n'est sans doute pas la voie à suivre. Il s'agissait plutôt :

• surtout, de ne pas se précipiter
• de réfléchir à une classe du genre abbr.transparent {border: 0;} qui permette d'utiliser au cas par cas class="transparent" dans des modèles.

--Temesis (d) 20 septembre 2009 à 12:14 (CEST)

Puisque cela influence toutes les listes de suivi et les pages de diff, je me suis reverté. Il faudra une plus grande discussion à ce sujet. Par ailleurs, avant de réfléchir à la class pour les cas en ayant besoin, il va donc d'abord falloir réfléchir à ces cas. En ce qui concerne les articles, je trouve ces pointillés peu esthétiques — Steƒ ^{๏̯͡๏﴿} 20 septembre 2009 à 14:21 (CEST)

Est-ce qu'il fonctionne dans un lien ? Par exemple, dans le sigle WCAG dans cette page, ça marche plus ou moins bien, mais le rendu graphique est brisé. Comment se débrouille un lecteur d'écran ? Dodoïste ^{[ dring-dring ]} 14 octobre 2009 à 02:04 (CEST)

Avancement des modifications des modèles

Je pense qu'il est bon de tenir un suivi des nos modifications ici. Dodoïste ^{[ dring-dring ]} 2 octobre 2009 à 01:57 (CEST)

1. Modèle:Info fait puis réverté suite à malentendu
2. Modèle:Indication de format fait puis réverté suite à malentendu
3. MediaWiki:Talkpageheader Je me demande si ce que j'ai fait est sémantiquement correct ? « + » n'est en aucun cas l'abréviation de « Voir toutes les sous-pages de discussion ». Alors oui, ça a l'avantage d'être accessible, mais je pense qu'on est encore loin du compte, et c'est peut-être pour cela que Temesis n'a rien fait à ce sujet.
4. Modèle:Indication de langue en cours sur WP:DIPP

J'ai utilisé <abbr> sur un article, hier, et c'est assez moche ce rendu. Que pensez-vous de créer cette classe dont parlait Temesis : abbr.transparent {border: 0;} sur Common.css, et enfin ce modèle {{abbr}} qui permettrait d'utiliser <abbr class="transparent">{{{1}}}</abbr> ? Ceci permettrait à tout un chacun d'utiliser <abbr> sur les articles.

Par ailleurs, quelqu'un peut-il jeter un œil à Philip G. Epstein, je ne suis pas sûr que l'usage de <abbr> soit correcte.

Cordialement — Steƒ ^๏̯͡๏ 14 octobre 2009 à 06:57 (CEST)

Image sans légende

Wikipédia fr comportant près de 77 200 images sans légendes, je vous propose d'attirer l'œil sur ce problème avec un bandeau en début d'article : Modèle:Image à légender

Je pense que cela peut-être utile d'essayer d'endiguer ce flot... Si une majorité donne son aval, il faudrait faire connaître ou promouvoir ce bandeau...

Le but de se bandeau est en l'apposant, forcer son retrait en obligeant les contributeur à légender les images... au même titre qu'un bandeau à wikifier ou ébauche...

Le nom du modèle peut évoluer... Modèle:À légender serait plus approprié ?

J'ai d'abord proposé cette discussion sur le bistro, sans réel engouement... -- Cordialement - Archimëa ✉⇔ 21 septembre 2009 à 18:13 (CEST)

Bonjour,

Je ne pense pas que multiplier les bandeaux soit une bonne chose. En l'occurrence, je crois que celui-ci serait avantageusement remplacé par une catégorie cachée de maintenance, par exemple. Mais cela nécessiterait le passage régulier d'un bot pour mettre à jour (sur plusieurs dizaines de milliers de pages, brrr...). Comment as-tu obtenu ce nombre ? La manière dont tu l'as eu pourrait donner une idée sur le moyen permettant de l'intégrer dans la maintenance... Litlok →m'écrire 22 septembre 2009 à 10:34 (CEST)

Je ne propose pas de multiplier des bandeaux mais d'apposer un bandeau... (encore cet argument sans fondement...)

Si c'est seulement dans le but de lister les articles, ca me semble inutile, puisque c'est déjà fait...

Si une catégorie cachée est mieux, eh bien au pire... Mais je nes suis pas sûre qu'ajouter une catégorie incite les utilisateurs à la supprimer... À moins que je me trompe ? -- Cordialement - Archimëa ✉⇔ 22 septembre 2009 à 13:38 (CEST)

Rejouter un bandeau revient effectivement à multiplier les bandeaux (par un facteur compris entre 1 et 2 ), et comme Litlok je ne suis pas convaincu. les bandeaux wikifier et ébauche incluent implicitement le fait de légender les images. Tant qu'à parler de bandeau je préférerais largement le modèle anglophone d'un bandeau à multiple paramètres indiquant les points à améliorer.  :::sinon Litlok a posé la question intéressante, comment as tu obtenu le nombre de 77200? :::le légendage des images ne me semble pas spécifiquement du ressort de l'atelier accessibilité, il me semble qu'ici le paramètre alt est plus important, non? --Chandres (d) 22 septembre 2009 à 14:31 (CEST)

En général, un article mal écrit l'est de plusieurs façons (absence de sources, orthographe) et est souvent une ébauche. Résultat : on peut très facilement se retrouver avec 3 ou 4 bandeaux en tête d'article.

À propos de alt et de la légende, le message concerne bien aussi l'atelier, puisqu'une image sans légende a a fortiori peu de chance d'avoir un alt Litlok →m'écrire 22 septembre 2009 à 14:38 (CEST)

L'alt et la légende sont importants, car ils sont complémentaires. Un lecteur d'écran lit la légende et l'alternative textuelle. L'alternative textuelle permet de donner accès aux informations graphiques auxquelles seule la personne qui ne voit pas l'image n'a pas accès. La légende donne des informations complémentaires à l'élément visuel, pour tous les utilisateurs.

Et le légendage est d'autant plus important que le paramètre alt est utilisé de manière quasiment confidentielle actuellement. Dans la plupart des cas, la légende est la seule information qu'un lecteur d'écran peut avoir. Donc s'assurer qu'il y ait au moins une légende serait déjà un grand pas pour l'accessibilité. :-) Merci de votre intérêt pour ces choses. ^_^ Dodoïste ^{[ dring-dring ]} 22 septembre 2009 à 14:51 (CEST)

_{niveau accessibilité, elle passe ta signature dodoiste? --Chandres (d) 22 septembre 2009 à 15:11 (CEST)}

C'est détecté par Projet:Correction syntaxique (voir Projet:Correction_syntaxique/Détections#Image sans description). Jean-Fred (d) 22 septembre 2009 à 15:39 (CEST)

On approche des 80000 images sans légende, donc il me semble que c'est un fait que le bandeau a wikifier ou ébauche ne servent, ne concernent ou ne font pas penser à s'occuper des images, c'est évident. Il ne remplis pas sont rôle, même si en théorie, il pourrait, je veux bien le concevoir...

En ce qui concerne l'abondance des bandeau, on va pas ouvrir le débat ici, vu la grosseur du sujet... seulement "un bandeau de plus" me semble peu constructif, je ne comprends pas... mais bon, passsons...

L'intérêt est bien réel d'autant plus que si l'image n'est pas en thumb ou en gallerie, la description principale est placée en alternative par MediaWiki.

Savoir comment mettre la catégorie sur la page, ou comment est établie la liste n'est pas le sujet primordial, n'importe quel bot peut le faire sans problème, c'est des questions accessoires facilement solubles. C'est plutôt savoir si apposer cette catégorie (à défaut du bandeau), conviendrait à tout le monde :

1. Ne pas gêner, si la description n'est pas mise
2. Permettre d'inciter les contributeurs à eradiquer cette catégorie des articles en placant les légendes -- Cordialement - Archimëa ✉⇔ 22 septembre 2009 à 16:43 (CEST)

@Chandres : ma signature est accessible à mon avis (j'ai testé avec l'extension libre Fire Vox pour Firefox), mais je n'en suis pas certain : tester avec lecteur d'écran n'est pas suffisant, il faut suivre les recommandations du W3C et pas les résultats des lecteurs. Le lien vers ma page de discussion est restitué correctement, c'est l'ombre qui n'est pas signalée. Ce genre de décoration n'est pas importante, et c'est bien qu'elle ne soit pas signalée. Donc à priori, je dirais que ma signature est accessible. :-) Dodoïste ^{[ dring-dring ]} 22 septembre 2009 à 16:55 (CEST)

Pour en rester à la question de l'utilité du bandeau, il faut différencier :

1. les images sans légendes (qu'il s'agisse de thumb ou d'images sans thumb).
2. les images en thumb légendées, mais sans alternative textuelle.

Dans le premier cas, rédiger une légende (et passer l'image en thumb si ce n'est pas déjà le cas) fait partie des usages biens établis. La tâche est coutumière à beaucoup de contributeurs. Son résultat est immédiatement perceptible par tous. La pertinence de la légende est aisée à évaluer. Peut-être un bandeau est-il utile, peut-être ne serait-ce qu'un bandeau de plus et une catégorie serait plus pertinente. Mais ce n'est pas le cas difficile à traiter.

Dans le second cas, celui des alternatives textuelles proprement dites, il en est tout autrement. Rédiger une alternative textuelle est une pratique rarrissime. C'est une tâche très peu valorisante et dont le résultat est difficilement évaluable, n'étant pas immédiatement apparent dans l'article. C'est une tâche particulièrement difficile, qui nécessite d'apprendre ce qu'est une alternative textuelle et comment elle doit être rédigée en fonction du contexte de l'image. Pour être clair: la rédaction par les contributeurs de plusieurs dizaines de milliers d'alternatives textuelles n'est pas un objectif réaliste ni pertinent, et la tentative ne serait pas profitable au bout du compte.

La question des alternatives textuelles ne passent donc pas par un bandeau appelant à s'y mettre, ni plus généralement par la prise en main du problème par les contributeurs. Elle relève d'abord d'une autre approche de la question par le CMS, avec la mise en place d'une solution d'alternative par défaut qui s'articule avec les légendes et avec une gestion de descriptions dans les pages d'images.

--Temesis (d) 22 septembre 2009 à 17:38 (CEST)

Oui, le problème des légendes alternatives est compliqué à gérer. Mais ce n'est en aucun cas le but de cette catégorie, ou du bandeau. Le but dans un premier temps est d'ajouter une description principale... qui pourra servir d'alternative pour les images simples tant qu'une décision/position claire ou consensus sur la gestion des images et de leurs descriptions n'est pas pris. Le but n'est pas forcément de pousser les gens à mettre une description principale + une alternative (bien que ce serait l'idéal), mais de mettre au moins une description. Le bon côté c'est qu'elle pourrait parfois la remplacer temporairement (bien qu'elle ne saurait le faire à long terme, les deux étant différent...) comme tu dis, il faudrait définir comment doit être une description alternative...).

De toute façon, il faut au moins une description simple...

Cette description passée en alternative serait toujours mieux que le nom du fichier, proposé actuellement en l'absence totale de texte descriptif. La description simple ne saurait à long terme remplacer l'alternative ou se suffir à elle-même, en espérant qu'un jour, ce problème de légende alternative soit réglé et toutes les images renseignées...

Et ca, mettre une description principale, c'est faisable...

Si en plus de mettre une description, cette catégorie pourrait pousser les gens à passer les images actuelles simples en thumb (quand c'est possible). Cela serait encore un plus.

Pour la différenciation entre les images, ce bandeau ou cette catégorie pourraient concerner toutes les images, avec ou sans description alternative ou principale, thumb ou pas... Il resterait à modifier le texte du bandeau ou de la catégorie pour mieux coller à la globalité.

Je pense que le bandeau serait pertinent si la liste d'image était beaucoup moins importante... (s'il n'y avait que 100, 200, 300 images à gérer et si la catégorie était maintenue régulièrement, on pourrait imaginer apposer ce bandeau...) -- Cordialement - Archimëa ✉⇔ 22 septembre 2009 à 20:49 (CEST)

Désolé si j'ai enduit d'erreur tout le monde en parlant du paramètre alt, qui n'est absolument pas en jeu ici, on est tous d'accord!

Sinon 80 000 images sans légende ca fait tout de même beaucoup, il faut à mon avis réfléchir à quelque chose de plus actif qu'un simple bandeau pour réduire cela. L'idée du bot pour catégoriser me plait assez, car par la suite avec AWB il serait assez facile de charger les articles par série pour ajouter la légende. Ce ne sera certe pas suffisant pour combler cette lacune rapidement, mais ce sera un bon début. --Chandres (d) 22 septembre 2009 à 22:22 (CEST)

Le mieux serait de cibler directement les nouveaux, et l'utilisateur moyen. Lorsqu'il veut insérer une image, il clique sur l'icône correspondante de la barre d'outils, et [[Fichier:Exemple.jpg]] est inséré. Mais là, il n'a aucune indication qui lui dit si c'est suffisant comme ça ou pas. thumb c'est quoi ? La légende, je la met où et comment ? alt, ça se mange ? Un des principaux problèmes que rencontre un nouveau lorsqu'il veut insérer son image, c'est qu'elle apparaît en résolution maximum par défaut. À partir de là, on peut s'orienter dans deux directions :

1. Améliorer le CMS : Lors de l'insertion d'une image, le CMS donne des informations sur la manière de paramétrer l'image selon sa fonction. Il produit notamment des infos sur le légendage. L'utilisateur est donc accompagné tout au long de l'insertion de l'image. Coût relativement élevé en termes de développement, mais devient de plus en plus indispensable. C'est typiquement un boulot pour l'Usability Initiative, et justement ces ergonomes préparent quelque chose de semblable pour les liens et les tableaux de Babaco.
2. Il est à mon avis possible d'agir localement : Ajouter le paramètre thumb à l'exemple généré par le bouton, évitant ainsi à l'utilisateur de le rajouter. Un exemple de légende peut également être ajouté. Petit coût pour un gain certain.

Dodoïste ^{[ dring-dring ]} 23 septembre 2009 à 02:10 (CEST)

+1 pour modifier les bouton pour mettre thumb.

Pour ton premier point : AddMediaWizard (qui n'est pas prévu dans les releases de la Usability ??) met en thumb et a un formulaire pour mettre une légende. Il choppe même par défaut la description sur Commons (bon il sélectionne pas la {{fr|}}, mais c'est déjà ça). Jean-Fred (d) 23 septembre 2009 à 02:36 (CEST)

Je ne sais pas qui développe AddMediaWizard, ni comment, etc. Plusieurs personnes se sont ajoutées bénévolement à l'Usability Initiative, et c'est possible que AddMediaWizard soit un projet annexe. Pour le reste, cette extension est vraiment en phase bêta (la fonction "crop this image" fonctionne mal et produit une quantité de code insensé), mais l'essentiel – avoir le panel d'images à la portée d'un clic et choisir l'image par un second – fonctionne bien et est efficient. Ce qui manque, c'est :

1. la possibilité de sélectionner les différents usages qu'on veut faire de l'image (thumb avec légende (par défaut), lien vers une autre page, icône, sans thumb) ;
2. de visualiser immédiatement le résultat (interface riche), pour ne pas avoir à publier son image 10 fois ou cliquer frénétiquement sur le bouton prévisualiser ;
3. d'avoir des conseils sur le légendage et l'alternative textuelle à renseigner, en fonction de l'utilisation qu'on a choisi afin de ne pas avoir 3 pages de doc pour insérer une image.

Je t'encourage à faire un retour aux développeurs de cette extension, et à stimuler son développement car son potentiel est vraiment très fort. :-) Dodoïste ^{[ dring-dring ]} 23 septembre 2009 à 03:33 (CEST)

Pourquoi pas rajouter thumb localement, en effet. Ce serait un moyen d'endiguer le problème. Mais il na faudrait pas que cela interfère avec l'ajout d'images dans les infobox (ainsi que les autres cas où thumb n'est pas nécessaire).

Que pensez-vous de l'ajout en commentaire en même temps que thumb : |<!--Légende à compléter--> (et |alt=<!--Légende à compléter--> si besoin)

Tout en sachant que le problème global des descriptions doit être réglé.

Pour en revenir à la question initiale, l'apposition de cette catégorie est-elle viable -- Cordialement - Archimëa ✉⇔ 23 septembre 2009 à 14:55 (CEST)

Je pense que le mieux est de rajouter « |thumb|Légende à compléter ». Lorsqu'on veut mettre l'image dans une infobox, il faut modifier de le code de l'image quoiqu'il en soit, en enlevant le lien sur image (car il est généré par le code de l'infobox). De toute façon, un nouveau devra lire la doc. d'une infobox pour pouvoir bosser dessus. Ce n'est donc pas un cas à prendre en compte ici. De plus, avoir « Légende à compléter » en texte visible permet au nouveau de voir où mettre sa légende pendant la prévisualisation, et de mieux saisir où elle sera placée. Sans parler du fait que le code <!-- --> est inconnu du contributeur moyen et ne sera pas intuitif du tout.

Le choix de l'apposition d'une catégorie ou non n'est à mon avis pas du ressort de cet atelier : cet impact serait étendu et très visible. Cela concerne donc la communauté dans son ensemble, et pas uniquement cet atelier. Nous avons éclairci ici l'importance du légendage pour l'accessibilité. Le choix d'une catégorie est à prendre par la communauté, à la lumière des explications fournies ici. Amicalement, Dodoïste ^{[ dring-dring ]} 23 septembre 2009 à 15:38 (CEST)

Ok pour la catégorie. Je pourrais donc ouvrir une discussion puis PDD par exemple sur le bistro, relayant cette discussion ? -> « en précisant : une catégorie cachée est plus conseillée que le bandeau... tout en, sachant que c'est pour inciter une action, en rappelant le problème des légendes alterantives... et que des modifs sont à venir sur le bouton... » ?

Ou alors il vaut mieux attendre que les modifs sur le bouton soient faites, si elles doivent être faites... bien-sur

Pour la modification sur frwiki, vous comptez faire une demande au titre du projet accessibilité, ou c'est seulement un accord de principe ? -- Cordialement - Archimëa ✉⇔ 23 septembre 2009 à 16:49 (CEST)

Tant qu'à rajouter « Légende à compléter », pourquoi ne pas en faire un lien vers la page d'aide concernant les images et le légendage, puisque que ce texte serait visible ? -- Cordialement - Archimëa ✉⇔ 23 septembre 2009 à 17:22 (CEST)

Peaufiner le nouveau script des boîtes déroulantes pour le déploiement

Hello. Le Wikipédia:Sondage/Utilisabilité et accessibilité des palettes de navigation, arrive à terme aujourd'hui, accepté à l'unanimité. Le script qui sera déployé est Utilisateur:Dodoïste/Boîte déroulante.js et Utilisateur:Dodoïste/Boîte déroulante.css.

Le script est fonctionnel au clavier, sous Opera 10. Mais, à ma connaissance, pas sous les autres navigateurs. Cacycle n'a pas corrigé ce problème, l'atelier JavaScript n'a pas répondu, et j'ai fait des test pour tenter de corriger moi-même le problème signalé par Temesis, en vain. Conclulsion : au secours ! Je copie ci-dessous l'explication de Temesis. Merci d'avance. Dodoïste ^{[ dring-dring ]} 28 septembre 2009 à 00:33 (CEST)

Le test qui fait défaut ici (pourtant indiqué par les bonnes pratiques d'accessibilité) est simple, et il peut être facilement popularisé auprès des contributeurs auteurs de script: tester systématiquement la fonctionnalité au clavier.

Ici, le code généré :

<span title="Click to show hidden content" onclick="javascript:collapseTableTest(0)" class="collapseButtonTest" id="collapseButton0">
  <a class="collapseButtonContent">
   <span class="collapseButtonShow"> </span>
   show
  </a>
</span>

...interdit au lien show/hide de prendre le focus clavier et lui interdit d'être reconnu et annoncé comme un lien dans un lecteur d'écran.

Pour y remédier, en allant au plus simple :

• ne jamais utiliser de gestionnaire d'évènement onclick sur un span (ou sur tout autre élément div, img, etc.) Pour que onclick soit universel et ne nécessite pas de gestion de son équivalent clavier, l'utiliser systématiquement sur un élément a doté d'un attribut href="#".
• compléter la fonction par un return:false; pour éviter l'activation du href.

Voir SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons (Attention : cette ressource comporte une erreur par ailleurs dans l'exemple 4 où un attribut alt et non title doit être utilisé)

Dans le même ordre d'idée, ne pas utiliser l'attribut title d'un span pour expliciter le rôle d'un lien. N'utiliser title que sur des éléments a, input, textarea, area, iframe.

--Temesis (d) 14 septembre 2009 à 05:29 (CEST)

C'est en cours. --Temesis (d) 28 septembre 2009 à 12:58 (CEST)

Il reste un problème de compatibilité IE5.x à régler. --Temesis (d) 29 septembre 2009 à 10:53 (CEST)

Merci Temesis. Pour IE5.x, n'y aurait-il pas moyen de faire quelque chose dans le goût de http://www.ie6nomore.com/code-samples.html ? Dodoïste ^{[ dring-dring ]} 29 septembre 2009 à 11:37 (CEST)

Non. Les commentaires conditionnels ne sont pas utilisables par les contributeurs/administrateurs dans le cadre des modèles de WP. Et si cela avait été possible, http://www.ie6nomore.com/code-samples.html est l'exemple de ce qu'il ne faut pas faire, c'est à dire adresser une source HTML différente selon les navigateurs : dans ce type de contenu, on ne modifie à l'aide des commentaires conditionnels que les surcouches CSS ou javascript, pour assurer la robustesse du contenu HTML indépendamment de l'agent utilisateur.

--Temesis (d) 29 septembre 2009 à 12:50 (CEST)

Côté technique : Je pensais justement à l'intégrer dans le JavaScript. Je sais bien que MediaWiki est extrêmement restrictif au niveau du code, j'avais d'ailleurs testé et vu que ce n'est possible que dans le JavaScript. En tant que puriste, je pensais bien que vous alliez me dire qu'il ne faut pas ajouter du contenu HTML par le JavaScript, et que ce dernier ne sert qu'à mettre en valeur le HTML.

Sur le fond : je trouve la démarche intéressante. Plutôt que de fournir des versions appauvries des interfaces pour des navigateurs obsolètes, il me semble que c'est rendre service à l'utilisateur que de lui signaler que son navigateur est obsolète et lui suggérer d'en télécharger un meilleur. Cela ne pourra que lui rendre service à terme.

Quoiqu'il en soit, selon Browser Version Market Share, août 2009, le pourcentage d'utilisateur de IE 5x est de 0.03%. Moi, à votre place, je ne me casserais pas la tête là-dessus. Autant IE 6 a encore 13% de part de marché et est à prendre en compte, autant IE5 est tellement rare qu'il est inexistant à l'heure actuelle. Bien à vous, Dodoïste ^{[ dring-dring ]} 29 septembre 2009 à 14:19 (CEST)

Autre souci: le script (non corrigé) présente des incompatibilités de rendu avec certaines palettes. Voir l'exemple des deux premières palettes dans l'article PSG. Il faut déterminer si c'est ponctuel ou si les modèles de ce type sont nombreux. --Temesis (d) 30 septembre 2009 à 12:44 (CEST)

C'est ponctuel. Il y a plusieurs manières de changer la couleur de fond du titre. La plus utilisée est celle fournie par le modèle. Ici, en plus de l'utilisation du paramètre du modèle qui va bien, il y avait un élément div qui était ajouté. Le problème n'est du côté du script, il faut corriger ce problème dans les palettes.

C'est réglé sur Modèle:Paris SG navigation et Modèle:Effectif actuel du PSG. Amicalement, Dodoïste ^{[ dring-dring ]} 30 septembre 2009 à 15:42 (CEST)

Par contre, il y a un rendu différent sur les palettes utilisant le paramètre sous-titre, comme Modèle:Partis politiques français au Parlement européen. Et là, modifier les palettes n'est pas forcément désirable. Mais le fait d'avoir le bouton en-dessous n'est pas forcément un problème non plus. Je n'ai en tout cas pas l'impression que cela gêne l'utilisation. Mais peut-être que cela gênera d'autres utilisateurs ?

Il y a plusieurs modèles qui utilisent le paramètre sous-titre, et dans certains cas c'est peu pertinent, comme Modèle:Sénat que j'ai modifié. Dodoïste ^{[ dring-dring ]} 5 octobre 2009 à 15:18 (CEST)

Please, do excuse my American English, en : American English.

• wikipédia_:_atelier_accessibilité
• wiktionary : handicapée
• wiktionary : handicapé
• handicapé
• Is atelier accessibilité workshop_ en : accessibility?

In 1985 & 1986 millions of us were en : warned, en : recommended, to quit referring to ourself as en : handicapped, handicap. I do concede that some had agreed, where others did not.

I have been contacted by one of your participants, which has led me to this page, where I found handicapée, which does not, in fact, wikilink, &, nor does en : wikilink, due to some mystery.

I do find handicapée to be en : emblematic of why I do find wikipédia, wikipedia, wikimedia, mediawiki, to be en : vile; it is not the software, it is the en : policy that is handicappist, handicappism. Okay, so, it does wikilink as handicapé. Neither one need be so en : prominently, en : exaltedly, en : promoted.

Of all the trillions of potential en : latin derivatives, I do very much suspect that there might be another en : synonym available, though, certainly, none is perfect, &, we must always, everyday, further refine en : lexicon_(disambiguation), en : vocabulary_, en : etymology_, en : linguistic_(disambiguation), en : language_(disambiguation).

hopiakuta DonFphrnqTaub Persina (d) 29 septembre 2009 à 01:00 (CEST)

The expression "personnes handicapées" is the translation of "people with disabilities", wich comes from the official definition of Web accessibility by the Web Accessibility Initiative. See Introduction to Web Accessibility. It's not a matter of Wikipedia policy.

If you wish to complain about it, I can only suggest that you contact the WAI : this is not a question for Wikipedia. --Temesis (d) 29 septembre 2009 à 09:51 (CEST)

Thank You for responding; however, prior to my involvement, in the 1970's, many people had quit w/ "handicap". I had quit in 1986.

The page, "handicap" does link to en : disability, which does include a en : redirect of en : disabled, as well as en : disable, whereas en : handicapped & en : handicap are en : disambiguation.

So, does French have anything like disablée, disablé, disabilitée, disabilité? There must be another synonym; I am certain that there is something other than "handicap" to work from.

hopiakuta DonFphrnqTaub Persina (d) 29 septembre 2009 à 13:05 (CEST)

No, "Handicapé" is simply the exact word, without any problematic connotation in french. Other words ("infirme"} or euphemism ("personnes en situation de handicap") are just confusing or worst (from your point of view) with no profit. But, once again, it's not a question regarding wikipedia : WP just uses "official" vocabulary, for NPOV --Temesis (d) 29 septembre 2009 à 13:22 (CEST)

So many of us have frequently found that our language is excessively en : stagnant regarding en : civil rights, that it is difficult to convince, to kick to en : evolve, American-English, en : American-English; en : language can either en : stagnate liberty in one circumstance, or, in another arena, it can en : enhance en : liberty_(disambiguation). We are, as yet, en : mired in a word that so many of us had dropped thirty years ago.

We do, however, refrer to en : oppression as handicappist, handicappism, racism, racist.

hopiakuta DonFphrnqTaub Persina (d) 29 septembre 2009 à 15:15 (CEST)

As said Temesis, the term in use in french is "Handicapé", it can't be substituted to another, even if we understand the use of this can be confusing for some. We, the french wikipédia community, can't change a word and decide to use any word instead of any other. Peharps you could write something to the Acamédie française, if never you will be listen, and they can or want do something about this problem. -- Archimëa ✉⇔ 29 septembre 2009 à 15:25 (CEST)

Atelier accessibilité (10 octobre)

Bonsoir,
je poste cette annonce ici, même si je pense que toutes les personnes actives de l'atelier sont au courant : le 10 octobre aura lieu, à Villejuif, un atelier sur l'accessibilité dans Wikipédia intitulé « Wikipédia accessible ? C'est possible » et animé par 2 professionnels du domaine, par ailleurs contributeurs sur Wikipédia.

L'association Wikimédia France a acheté 7 places et il en reste 2 disponibles. L'objectif est double :

• intéresser et sensibiliser des contributeurs aux problématiques de l'accessibilité (et leur permettre de relayer ces problématiques et les solutions aux différentes communautés wikimédiennes, i.e., se faire le porte-voix de l'atelier accessibilité) ;
• réunir un ensemble de gens intéressés pour discuter des actions à mener par la suite, une sorte de groupe de travail (avec l'aide de l'association).

Si vous être intéressés, contactez-moi. Pour plus d'infos regardez le site officiel. Cordialement, (:Julien:) ✒ 30 septembre 2009 à 01:04 (CEST)

Paramètre link et alt dans une image hors thumb : attention

La dernière mise à jour de mediaWiki a apparemment provoqué une régression notable dans la gestion des alternatives textuelles d'images (hors thumb). Pour résumer, ce qui favorisait automatiquement l'accessibilité dans divers cas nécessite à présent des paramètres beaucoup plus explicites. Dans le détail, sauf erreur :

• Paramètre link absent :
  • Mauvais : sans paramètre link ni alt, l'alternative par défaut est le nom du fichier : [[Fichier:Exemple.jpg|16px]] produit un <a ...><img ... alt="Exemple.jpg"/></a> :
  • Mauvais : sans paramètre link mais avec alt vide, l'alternative est vide : [[Fichier:Exemple.jpg|16px|alt=]] produit un <a ...><img ... alt=""/></a> :
• Paramètre link vide :
  • Mauvais : avec paramètre link vide, et sans alt, mediaWiki ne produit plus une alternative vide, mais utilise également le nom de fichier : [[Fichier:Exemple.jpg|16px|link=]] produit un <img ... alt="Exemple.jpg"/> :
  • Bon : avec paramètre link vide, et avec alt vide, l'alternative est vide : [[Fichier:Exemple.jpg|16px|link=|alt=]] produit un <img ... alt=""/> :
• Paramètre link renseigné :
  • Mauvais : avec paramètre link renseigné et sans alt, mediawiki utilise là encore le nom de fichier : [[Fichier:Exemple.jpg|16px|link=Wikipédia:Atelier accessibilité]] produit un <a ... title="Wikipédia:Atelier accessibilité" ><img ... alt="Exemple.jpg"/></a> :
  • Bon : avec link et alt renseigné, [[Fichier:Exemple.jpg|16px|link=Wikipédia:Atelier accessibilité|alt=Atelier accessibilité]] produit un <a ... title="Wikipédia:Atelier accessibilité"><img ... alt="Atelier accessibilité"/></a> :

Cela signifie :

• que la solution du link vide pour les icônes décoratives, qui produisait jusqu'ici une image sans liens avec alt vide, déjà signalée comme incertaine dans les bonnes pratiques, est à présent définitivement à proscrire (au profit du recours à des images CSS exclusivement) : l'implémentation vient de changer abruptement et peut à nouveau changer demain.
• qu'il n'est toujours pas possible d'inclure une image sans en faire un lien, sauf à recourir à la combinaison link et alt vides, qui est à éviter pour la raison précédente.
• qu'il est impératif de renseigner le paramètre alt d'une image hors thumb, y compris pour l'indiquer comme étant vide.

--Temesis (d) 1 octobre 2009 à 09:35 (CEST)

Ne nous précipitons pas non plus dans le sens inverse. On ne va pas courir dans un sens et dans l'autre au fil des revirements inconsidérés du CMS.

Une des raisons pour lesquelles je me suis mis à contribuer à l'accessibilité sur :en, et que j'ai amélioré quelques-une de ses recommandations, c'est parce que je pensais que les développeurs iraient lire les recommandations utilisées par la communauté avant de changer quoique ce soit. Je pensais aussi qu'il consulteraient la communauté, et qu'ils observeraient les usages de la communauté, avant de faire de tels changements. Cela ne s'est pas fait spontanément, il va donc falloir leur apprendre à agir ainsi.

J'ai une carte dans ma manche : les développeurs sont beaucoup plus proches de la communauté anglaise. Quelques explications bien placées peuvent avoir un fort impact. Je connais d'ailleurs un développeur actif qui se soucie de l'accessibilité.

Quoiqu'il en soit, on ne peut pas changer nos bonnes pratiques et recommencer tout notre travail au gré de revirements hasardeux. Il est donc nécessaire de tenter une autre approche. Amicalement, Dodoïste ^{[ dring-dring ]} 1 octobre 2009 à 11:04 (CEST)

Les bonnes pratiques n'ont jamais intégré la première implémentation du link vide qu'à titre indicatif, en raison de sa fragilité prévisible. Il ne s'agit justement pas de se précipiter, que ce soit dans un sens ou dans un autre, mais de continuer à être très prudent avec une implémentation aujourd"hui encore instable et incertaine. --Temesis (d) 1 octobre 2009 à 11:12 (CEST)

Modèle:Sous-titre

Intervention déposée simultanément dans Wikipédia:Le Bistro/10 octobre 2009, Discussion:Occitan, Discussion Projet:Langues et Discussion Wikipédia:Atelier accessibilité

Le recours au modèle {{sous-titre}} me paraît une fausse bonne idée :

• d'abord parce que l'on n'a apparemment pas sollicité l'avis des participants du Projet:Langues avant de recourir à ce modèle. Or la sous-page de documentation de ce modèle indique que « le recours à ce modèle ne devrait pas avoir lieu en dehors d'articles où un projet a décidé de la nécessité d'un sous-titrage. »
• j'ai un doute sur la pertinence de ce modèle et sur son interprétation par les navigateurs pour personnes ayant des déficiences visuelles. Consulter l'Atelier accessibilité me semblerait être une précaution indispensable, d'autant plus qu'il faut aussi prendre en compte le rendu bizarre pour les gens qui ne disposenty pas de javascipt ou qui l'ont désactivé ;
• la sous-page de documentation du modèle disait aussi que « Il ne peut en aucun cas être utilisé dans le contexte d'un désaccord sur le libellé du titre d'un article. »

Je n'ai pas de solution toute faite, mais je pense qu'il faudrait revoir sérieusement cette histoire de titre et de sous-titre, qui me semble être une solution bancale.

Hégésippe | ±Θ± 10 octobre 2009 à 17:56 (CEST)

Le modèle {{sous-titre}} ne pose aucun problème d'accessibilité. Il permet au contraire de gérer de manière accessible l'ajout d'un contenu au titre principal, la notion de sous-titre n'existant pas en HTML. Il permet surtout de préciser le changement de langue sur son contenu, tout en étant compatible avec {{Langue du titre}}).

Les discussions sur son éventuelle adoption se sont tenues :

• dans le projet Musique classique pour {{Sous-titre/Musique}}
• dans le projet Cinéma pour {{Sous-titre/Cinéma}}, cette dernière ayant d'ailleurs aboutit à son abandon.
• Une proposition d'utilisation a été également faite auprès du projet Biologie pour le remplacement de l'actuel modèle {{Sous-titre espèce}}.
• Il a été recommandé à chaque projet de recourir à un sondage plus général (hors du cadre étroit de chaque projet) sur le principe même d'un modèle de sous-titre dans les pages de WP.

En revanche, son utilisation actuelle sur un article comme Occitan par exemple est typiquement hors du cadre prévu, mais ces questions d'adoption par les projets ou d'utilisation « sauvage » ne relèvent pas de cet atelier, et l'accessibilité n'y est pas une donnée pertinente, que ce soit à l'appui d'un point de vue ou d'un autre.

--Temesis (d) 11 octobre 2009 à 07:27 (CEST)

Cher L., j'ai quand même du mal à comprendre comment un lecteur pour déficients visuels peut permettre à ceux-ci de déceler, de manière irréfutable, dans le code HTML, que le <span id="sous_titre_h1"> est « structurellement » lié à la balise <h1>, compte tenu de la séparation et de l'éloignement relatif entre les deux balises. Sans parler du fait qu'un article comportant cet artifice peut être consulté par un lecteur qui ne lit pas le français, et ne devinera donc pas ce que peut signifier l'identificateur « sous-titre_h1 », malgré le recours à « h1 », dans le nom de l'identificateur, pour tenter de faire ce lien. Hégésippe | ±Θ± 11 octobre 2009 à 14:08 (CEST)

Cela ne se passe pas comme vous le supposez, pour une aide technique :

• Un lecteur d'écran exploite le code produit par le navigateur dont il n'est qu'une surcouche (il s'interpose entre l'écran et la chaise, si vous voulez) : il n'interprète pas la source wiki ou le code final sans javascript, c'est à dire :

  <h1>Der Ring des Nibelungen</h1>

  suivi de

  <span id="sous_titre_h1">L'Anneau du Nibelung</span>

• Il interprète le code produit via javascript, c'est à dire le

  <h1>Der Ring des Nibelungen <span id="sous_titre_h1">L'Anneau du Nibelung</span></h1>

  qui ne lui pose aucun problème d'identification du contenu de titre. En revanche, il faudrait dans l'article pris en exemple un {{Langue du titre|de}} et du coup préciser également que le sous-titre est en français et non en allemand, mais c'est une toute autre question. Et pour regarder plus loin, dans un monde idéal, il n'y aurait pas de détour via javascript et mediawiki permettrait aux contributeurs de saisir spécifiquement un champ « sous-titre ». Rien de tout cela n'est bloquant dans l'immédiat.

Au delà encore, dans vos questions, il y a le sous-jacent: mais que se passe-t-il pour le lecteur chez qui javascript n'est pas supporté ou activé, et chez qui le titre h1 sera en effet suivi d'un bref paragraphe de texte contenant uniquement le sous-titre brut ? En premier lieu, ce n'est pas une question d'accessibilité. Ensuite, à d'autres points de vue (ergonomie, etc.), l'accès à l'information est assuré, de manière certes minimale et améliorable mais robuste.

Pour tout dire : ce modèle a été créé sans aller jusqu'aux dernières optimisations possibles, son adoption étant incertaine. Il y aurait donc, s'il est pérénnisé, des améliorations diverses au-delà de l'accessibilité. L'une d'entre elle serait d'avoir sans javascript une mention correctement présente dans l'introduction de l'article et non un bout de texte isolé. Ce n'est pas un souci technique majeur, juste une question à poser le moment venu à un contributeur amateur de javascript. Ce sont des bricoles techniques sans grand intérêt.

La seule question concernant ce ou ces modèles est celle de la pertinence éditoriale de l'outil "sous-titre", au regard d'autres problématiques. Elle est certes loin d'être innocente (ouverture d'une porte à des rebondissements de conflits de points de vue sur le nommage d'une page, par exemple, comme vous venez de le constater). Elle est en tous cas intéressante.

--Temesis (d) 11 octobre 2009 à 14:50 (CEST)

Boîte à outils

Je recopie ici la liste des logiciels donné à la conférence Paris-Web :

• Trempette
• Firebug
• Developper toolbar
• WEBAIM toolbar
• Accesibility toolbar
• CCA
• NVDA
• Headingsmap
• Favelets

Je me disais que ce serait peut-être une bonne idée de faire une sous page (du genre Wikipédia:Atelier accessibilité/boite à outils) en expliquant sommairement ces logiciels, leurs fonctions, leur utilité, etc. (moi-même je ne les connais pas tous). Cdlt, Vigneron * ^discut. 13 octobre 2009 à 15:03 (CEST)

Il existe Wikipédia:Atelier accessibilité/Ressources et références#Outils de tests et aides techniques, que l'on peut compléter. :-) Dodoïste ^{[ dring-dring ]} 13 octobre 2009 à 16:12 (CEST)

Ne pas se bousculer, tous ces outils ne sont pas à mettre entre toutes les mains (NVDA n'est pas un lecteur d'écran représentatif par exemple, et l'atelier s'intitulait « On rase gratis », ce qui exprimait de notre part certaines réserves sur la pertinence de ces outils immédiatement accessibles). Il y a un tri à faire, une page Wikipédia:Atelier accessibilité/Ressources et références#Outils de tests et aides techniques à améliorer en effet, et des gadgets à créer pour mettre à disposition des contributeurs non techniques des outils plus immédiats. Mais sinon, oui, il faut documenter tout cela. --Temesis (d) 13 octobre 2009 à 16:22 (CEST)

Oui évidemment mal utilisés ces outils pourraient faire plus de mal que de bien. C’est pourquoi je proposais de les décrire : ne serait-ce que pour savoir où les trouver, et ensuite comment et dans quel cas les utiliser. Je les ai aussi mis là pour ne pas les oublier . Niveau documentation, je ne suis pas le mieux placé pour faire cela (niveau lecteur d’écran je suis une bille par exemple, je sais juste que NVDA ou Jaws existent mais pas vraiment quoi en faire ni comment). Quant à faire des gadgets, c’est hors de ma portée.

Dans la liste des choses à documenter, il y a aussi le gadget Inspection des tableaux et Inspection des headers (cela a peut-être déjà été fait mais je ne sais pas où). Cdlt, Vigneron * ^discut. 13 octobre 2009 à 16:51 (CEST)

C'est un chantier noté, dans la mesure où il intéresse tous les projets. Il reste à trouver les mains pour le mener à bien : si quelque-chose se fait avec les compétences et les moyens du bord, il sera d'autant plus facile d'amener des experts à l'améliorer... --Temesis (d) 13 octobre 2009 à 18:07 (CEST)

Atelier Paris-Web 2009 : Wikipédia accessible ? C’est possible !

Je ne pouvais assister à cette conférence, bien que je l'aurai souhaité, mais Paris, c'est loin du sud. Aussi, te serait-il possible à toi, ou à quelqu'un d'autre, de résumer ce qui s'y est dit ? — Steƒ ^๏̯͡๏ 13 octobre 2009 à 15:31 (CEST)

Je ne saurais faire un résumé pour ma part (à l'aide !). Un pdf plus complet que celui qui a été présenté durant la conférence sera en ligne prochainement. Les ateliers du samedi 10 ont peut-être été filmés (par une caméra minuscule, et pas de prise de son), mais je n'en suis pas sûr.

Après la conférence, il y a eu une première réunion de contributeurs intéressés par l'accessibilité. Et donc une première concertation sur les objectifs à atteindre et les méthodes à employer. Il serait bon de faire des rencontres online régulièrement, pour poursuivre dans cet élan. Il a été proposé de faire des rencontres IRC par exemple. Que dites-vous d'une rencontre IRC par week-end ? Ou une rencontre IRC le premier week-end de chaque mois ? Dodoïste ^{[ dring-dring ]} 13 octobre 2009 à 15:54 (CEST)

De mon côté, intéressé par ce genre de rencontre, mais le week end ne sera peut-être pas le meilleur moment, sauf si ces rencontres ont lieu le vendredi … — Steƒ ^๏̯͡๏ 13 octobre 2009 à 16:09 (CEST)

La présentation devrait être en ligne d'ici la semaine prochaine en effet (souci de conversion en PDF en cours). Des publications détaillées reprenant les points abordés sont également prévues par les auteurs, mais cela prendra un petit peu plus de temps. Stay tuned. --Temesis (d) 13 octobre 2009 à 16:19 (CEST)

Pour l'instant : Atelier Paris-Web 2009 : Wikipédia accessible ? C’est possible ! (Powerpoint, 3.1Mo). --Temesis (d) 20 octobre 2009 à 11:06 (CEST)

Plugin de création de graphique

N'ayant pas eu de réponse sur la page Discussion_Wikipédia:Atelier_graphique/Recherche_et_développement, je me permets de faire un copier/coller de mon message ici.

J'ai constaté qu'il était assez difficile d'inclure un graphique dans wikipedia et qu'en dehors de l'utilisation d'un SVG/Image, de timeline ou graphique en bar, vous n'aviez aucune solution rapide pour des courbes simples ou en camembert. De mon côté, j'avais besoin d'inclure simplement des graphiques dans un mediawiki professionnel (pour des benchs avec temps de réponse et nombre de requête/s). Dans un premier temps, j'ai donc commencé à fouiller au niveau des plugins existants sous mediawiki pour pouvoir y inclure ce que je voulais. J'ai donc découvert les plugins timeline (présent sur wikipedia) ainsi que Gchart4mw [5]. J'ai rapidement découvert que le premier n'était pas du tout adapté à mon besoin (dessiner des courbes x,y) et que le second était limité en nombre de point/taille du graphique. J'ai également regardé du côté de l'extension gnuplot [6] mais je n'ai malheureusement pas pu m'en servir puisque je n'avais pas la possibilité de l'installer sur mon serveur.

C'est donc à ce moment que j'ai commencé à me tourner vers une solution de générateur de graphique natif PHP avec jpgraph [7] et j'ai donc créé un plugin pour mediawiki. J'ai reversé ce plugin à l'emplacement suivant : jpgraphmw [8]. Etant donné que ce plugin est encore très récent, j'aimerai savoir dans quel mesure il pourrait intéresser la communauté et dans quel sens il faudrait que je le fasse évoluer s'il devait pouvoir répondre à un besoin de la communauté.

En dehors du fait que ce plugin génére directement les graphiques pour mon article, je trouve qu'il apporte un avantage direct sur un graphique SVG ou PNG : il fait parti intégrante du texte d'un article, permettant d'accèder rapidement à l'information et au source d'un graphique. Il permet également de se garantir que les utilisateurs génèreront des graphiques qui seront tous identiques en terme de charte graphique. Enfin, je pense qu'il pourrait également permettre de générer plusieurs types de graphiques et ainsi améliorer l'accessibilité (notamment en générant des graphiques noirs et blancs ou tout autres suggestions qui pourraient vous venir à l'idée).

Il ne me reste plus qu'à vous souhaiter une bonne journée. Yannig (d) 15 octobre 2009 à 18:44 (CEST)

Manquant de disponibilité dans l'immédiat, je reviens vers vous d'ici quelques jours. Cette extension est évidemment intéressante. Plusieurs améliorations seraient cependant nécessaires pour en faire un outil de production de contenus accessibles. Cordialement, --Temesis (d) 20 octobre 2009 à 11:11 (CEST)

Pas de problème. De mon côté, je vais essayer de trouver un espace 'bac à sable' afin que ce plugin puisse être testé sans problème et ainsi que je puisse avoir des retours. Yannig (d) 20 octobre 2009 à 19:04 (CEST)

Regroupement des notes

Salut. L'article Strawberry Fields Forever contient un certain nombre de notes groupées ensemble (avec l'attribut name de la balise ref), et on m'a fait remarquer, à juste titre, que lorsqu'on consulte une note, on ne sait pas sur laquelle cliquer pour remonter à l'article. Est-ce qu'il est préférable de procéder comme sur l'article Histoire de la pensée économique des arts et de la culture, avec une multiplication de notes identiques (qui renvoient toutes à la même page du bouquin), quitte à augmenter la taille de la section "Notes et références" ? Ou bien faut-il attendre une modification miracle de Mediawiki... ? Je serais d'accord de procéder comme sur l'article d'économie, mais uniquement si ça vaut vraiment le coup... Merci. Zakke (d) 23 octobre 2009 à 13:02 (CEST)

Très, très (vraiment très) rapidement, mais cela mériterait une évaluation détaillée :

• point de vue ergonomique : une référence, c'est un lien interne dans la même page, dans le contenu duquel j'ai immédiatement toute l'information, plus un lien de retour immédiat vers ce que j'étais en train de lire. Rien que le fait qu'il faille un lien de retour est déjà un échec potentiel, à vrai dire (si la référence était affichée dans une fenêtre « modale » comme on appelle cela dans le jargon, j'aurai juste à cliquer sur son icône de fermeture pour avoir mon contenu initiale inchangé sous les yeux et ce serait un progrès considérable). Quoi qu'il en soit, si c'est plus compliqué que cela et qu'il faut clqiuer ici, puis là, puis je ne sais pas comment revenir à mon contenu, c'est un échec total (c'est la sutuation actuelle). Donc Strawberry Fields Forever est un exemple de ce qu'il ne faut pas faire.
• Point de vue accessibilité, les divers liens sont actuellement des échecs en raison de leurs libellés non explicites (typiquement des « 1 », « a » ou « ↑ ») mais cela peut se résoudre via une amélioration technique de l'extention cite et cela ne doit pas troubler pour le moment les contributeurs. C'est à évacuer du débat.

Bref, le souci actuel n'est pas l'accessibilité, mais l'ergonomie. Et il y a en effet un souci important dans ce qu'on préconise parfois. Ne pas faire comme dans Strawberry Fields Forever serait un bon début. Mais Histoire de la pensée économique des arts et de la culture fait autrement sans faire mieux.

Peut-être Accessibilité du Web peut-il donner des idées, sans prétendre aborder tous les cas présents dans d'autres articles. C'est un chantier à ouvrir dans lequel les outils et usages actuels sont à revoir. Il est très heureux que des contributeurs se manifestent sur le sujet, comme vous le faites.

--Temesis (d) 23 octobre 2009 à 15:10 (CEST)

Dans ses préférences utilisateurs/gadgets/outils avancés, on peut activer les popups pour avoir cette « fenêtre modale » simplifiant l'ergonomie pour la lecture des notes (évite les allers-retour vers le pied-de-page). Par contre j'imagine que la fenêtre de popups pose un pb. d'accessibilité… A2 (d) 23 octobre 2009 à 15:42 (CEST)

Merci de ce début de réponse Temesis, mais je ne suis guère avancé. Tu qualifies les deux méthodes de mauvaises, mais en existe-t-il, à l'heure actuelle, une troisième ? Accessibilité du Web est semblable au deuxième cas : voir par exemple les notes 19,20 et 21 qui sont identiques et renvoient à Rick Ells. Zakke (d) 23 octobre 2009 à 15:55 (CEST)

Demande

Salut, je voulais savoir, si un ou plusieurs participants au projet, voulez bien expliquer leurs démarche pour une accessibilité plus étendu du site, tout cela pour le Wikimag. Merci :) mik@ni 30 octobre 2009 à 18:03 (CET)

Hello, merci de ton intérêt. C'est une super idée que tu as là. :-) Rapidement, selon nos précédentes discussions, et notemment la réunion de Paris-Web, il y a :

1. Demander un audit de l'accessibilité de MediaWiki par des experts, solution coûteuse mais indispensable. Pour améliorer MediaWiki, il faudrait également que la Wikimedia Foundation manifeste un réel intérêt pour l'accessibilité.
2. Avoir un suivi de l'accessibilité dans les projets modèle et Javascript. Ces éléments sont clés, car une modification d'un modèle peu impacter (en bien ou en mal) des dizaines milliers de pages.
3. Populariser l'accessibilité par les labels de qualité, le Wikiconcours, etc. Il est également possible de créer un label accessibilité. Je pense pour ma part qu'il faut une liste de bonnes pratiques adaptée au rédacteur lambda, et plus pédagogique que nos bonnes pratique actuelles.

Il faudrait développer une de ces ces trois pistes, pour le Wikimag. Je ne peux pas parler du 1) et du 2) pour ma part (j'ai pas tout compris), et j'attends des retours de mes camarades pour développer quelque chose au niveau du 3). J'espère que d'ici quelques jours j'aurai une réponse à mes mails. Bien à toi, Dodoïste ^{[ dring-dring ]} 31 octobre 2009 à 00:54 (CET)

Rapidement : premier jet, et un peu arbitrairement quand aux questions (je pose les questions auxquelles je réponds, mais n'hésitez pas à en poser d'autres ou à les préciser). Les questions prises en compte sont essentiellement, et de manière répétitive, celles que l'on rencontre en vrai :

Vous vous occupez d'accessibilité, c'est quoi ?

L'accessibilité de WP est la possibilité pour des aveugles, daltoniens, sourds, handicapés moteurs ou cognitifs, etc. ainsi que pour les personnes âgées de pouvoir consulter Wikipédia, voire d'y participer.

Dans les discussions entre wikipédiens, le terme "accessibilité correspond plus souvent à toutes sortes d'autres questions très diverses. L'atelier accessibilité se concentre sur le sens premier et opérationnel de l'accessibilité. Il exclut donc beaucoup de questions que les wikipédiens mettent couramment sous le terme "accessibilité". C'est d'ailleurs une chose que nous devons souvent expliquer, quand on nous soumet une question hors sujet.

Donc, vous vous occupez uniquement d'un public très particulier ?

Non, pas du tout et au contraire. Disons que n'importe qui peut se retrouver "en situation de handicap", similaire à celle d'un aveugle ou d'un handicapé moteur. Ne me dites pas que vous n'avez jamais été victime d'une souris qui ne marchait plus dans un cybercafé, d'une connexion en bas débit où vous désactivez l'affichage des images, ou d'un éclairage qui rendait votre écran à peu près illisible sur votre portable ?

Au-delà, il s'avère que ce qu'on fait techniquement pour les outils des utilisateurs en situation de handicap bénéficie à beaucoup d'autres outils utilisés par tous les visiteurs de Wikipédia. Par exemple, Google est souvent réputé être un utilisateur aveugle. Ou encore, l'accessibilité au sens strict fait une partie de travail nécessaire pour que Wikipédia soit consultable sur un mobile.

L'accessibilité pour les lecteurs handicapés est-elle importante pour Wikipédia ?

Elle est essentielle. La vision revendiquée par la fondation Wikimedia est l'intention de mettre la connaissance à disposition de tous. Cela inclut notament les personnes en situation de handicap et les seniors, c'est à dire la cible spécifique de l'Initiative pour l'accessibilité du Web du W3C, dans laquelle se situe cet atelier. En fait, l'objectif de l'Initiative pour l'Accessibilité du Web et la vision de Wikimedia coïncident totalement : rendre le contenu de Wikipédia perceptible, compréhensible et utilisable par tous sans exception.

Vous vous occupez donc surtout des aveugles ?

Non. Les aveugles et leurs lecteurs d'écran ou tablettes brailles sont juste le cas les plus "marketing" de l'accessibilité (voir un aveugle surfer le Web, c'est très impressionnant, cela produit toujours son petit effet même sur les plus sceptiques), mais ce n'est qu'un exemple sexy. L'accessibilité d'un site Web est indépendante du type de handicap ou de la combinaison de divers handicaps. Le plus souvent, par exemple, le problème d'accessibilité de Wikipédia concerne un public beaucoup plus large, celui de tous les gens qui ne peuvent pas utiliser une souris. D'un certain point de vue, nous nous efforçons au contraire d'oublier les aveugles. Nous traitons des situations de handicap.

Il faut donc optimiser Wikipédia pour les utilisateurs handicapés ?

Non, pas du tout. Il ne faut surtout pas optimiser, ou prévoir des contenus spéciaux, c'est inutile. Il s'agit juste de veiller à respecter des normes de portée plus générale, qui visent principalement à ce que le contenu de Wikipédia soit exploitable par n'importe quel logiciel ou matériel. Ces normes ont été conçues pour s'insérer dans la qualité générale d'un site. Elles ne demandent pas de faire des contenus spéciaux pour les aveugles ou les handicapés moteurs, elles demandent de faire n'importe quel contenu de manière à ce qu'il vraiment utilisable par n'importe quelle machine.

Un aveugle ou un handicapé moteur ou plus généralement un utilisateur en situation de handicap peut-il consulter Wikipédia ?

Il n'y a pas de réponse globale. Les contenus de Wikipédia sont pour l'instant très simples et souvent assez aisés à traiter, mais la première page venue peut contenir une aberration : il suffit qu'un contributeur y ait mis son truc à lui qui lui semble bien. Il est très difficile d'évaluer précisément le niveau d'accessibilité réel des contenus de Wikipédia. Tant que les contributeurs font du contenu et ne commencent à pas à s'occuper de mise en page, de modèles, d'interaction... cela se passe plutôt bien.

Un aveugle ou un handicapé moteur ou plus généralement un utilisateur en situation de handicap peut-il contribuer à Wikipédia ?

Oui, mais peut-être de plus en plus nettement non si le développement de mediawiki ne réalise pas qu'il y a un champ entier de la qualité Web qui doit être pris en compte. L'utilisability Initiative actuelle, par exemple, ne tient pas compte des problèmes d'accessibilité, et va plutôt provoquer dans l'immédiat des régressions importantes. Par exemple, des menus inutilisables au clavier.

En conclusion, que recommanderiez-vous ?

Avant tout, recentrez-vous sur les contenus, arrêtez de jouer avec l'interface des articles.

Faites ce qui vous est recommandé, sans chercher à comprendre ni à innover. Votre rôle est de faire du contenu, pas de faire de l'accessibilité et encore moins d'inventer des fonctionnalités, de l'interaction, des modèles etc. Le rôle d'autres intervenants est de vous permettre de faire des contenus de qualité (du point de vue technique) sans que vous ayiez spécialement à vous préoccuper d'autre chose que d'utiliser les outils et de respecter les usages recommandés. S'ils font bien leur travail, ce sera simple pour vous, sauf cas particuliers.

Maintenant, la vrai question est savoir si les projets wikimedia parviennent à avoir de tels intervenants à même de faire ce genre de recommantions et d'aider à mettre en place les outils nécessaires. Pour l'instant, ce n'est pas gagné, mais la prise de conscience commence à germer.

--Temesis (d) 31 octobre 2009 à 12:08 (CET)

Est-ce que ces réponses correspondent à ce que tu recherches, Mikani ? Dodoïste ^{[ dring-dring ]} 1 novembre 2009 à 13:49 (CET)

Métapalettes déroulantes, le retour

Bonjour, je suis en train de réfléchir avec le projet biologie à la mise au point de palettes de bas de page permettant de naviguer parmi les articles et sous-articles traitant d'une même espèce biologique. Voir les exemples sur lesquels je réfléchis. Croyant me souvenir que ce modèle de métapalette n'est pas top du point de vue acessibilité à cause des groupes, quelqu'un saurait-il mettre au point un code propre et facile d'usage pour avoir à terme deux modèles du type {{Métapalette espèce zoologique}} {{Métapalette espèce botanique}}. Quelqu'un s'en sent-il capable ou bien nous continuons avec l'actuel {{Méta palette de navigation}} faute de mieux ? --amicalement, Salix ( converser) 3 décembre 2009 à 18:25 (CET)

Oui, c'est une bonne idée de créer ces deux modèles à partir de la méta palette de navigation, je le ferais avec plaisir. On aurait comme cela une bonne unification des modèles. Tpt (d) 4 décembre 2009 à 21:14 (CET)

J'avoue être nulle en modèles à part la méthode du copier/coller/bidouiller. C'est pour cela que je préfère laisser cela aux "pros". Si tu veux bien aider quelles informations te faut-il ? --amicalement, Salix ( converser) 4 décembre 2009 à 22:24 (CET)

Le modèle {{Méta palette de navigation}} n'est pas optimal du point de accessibilité, mais ses défauts ne sont pas « bloquants » pour l'utilisateur. En revanche, leur correction nécessiterait de revoir entièrement le javascript enrouler/dérouler (principalement: utilisation erronée d'un élément TH comme titre d'un tableau, à la place de CAPTION s'il est traité comme tableau de données ou de TD s'il est traité comme tableau de mise en forme). Ce serait un chantier d'assez grande ampleur, mais pas prioritaire.

Les seules précautions essentielles pour l'instant sont de ne pas utiliser l'option « image dans le corps » et surtout l'option « sous-groupe » (Modèle:Méta palette de navigation sous-groupe) qui créent des problèmes beaucoup plus grave (liés notamment à l'imbrication de tableaux).

--Temesis (d) 16 décembre 2009 à 06:55 (CET)

Donc selon toi on pourrait utiliser ces projets en l'état ? --amicalement, Salix ( converser) 16 décembre 2009 à 13:31 (CET)

Oui.

Une bricole mais importante : avec les indications de changement de langue qui vont bien sur le latin.

Côté optimisation, si et seulement si c'est envisageable : ne pas centrer les listes serait un plus, mais uniquement ergonomique. De même, si les catégories sont présentes en bas de page, s'abstenir des les répéter dans la boîte. Dans l'idéal et toujours ergonomique et non accessibilité, éviter les couleurs au rôle indiscernable pour le visiteur. Tant que ces 3 points ne bloquent pas l'idée générale auprès des contributeurs, bien-sûr.

--Temesis (d) 16 décembre 2009 à 13:39 (CET)

Ces catégories dans ce type de palette sont àmha très utiles pour éviter de la bourrer de 10nes d'articles en plus ( = économie de place et de maintenance) et aussi pour pointer directement vers les plus ciblées. N'oublions pas que de nombreux lecteurs n'en connaissent pas le fonctionnement ou bien ne les voient même pas en bas de page (déjà que pour les paettes c'est pas gagné !). Est-ce que cela pose un problème d'accessibilité ? A part ça j'ai supprimé des "center", il faut tous les enlever ? Pour la couleur je l'ai mise en fonction des codes couleur des projets, elles n'ont pas vraiment d'importance mais c'est en générale apprécié. Est-ce que l'écriture en blanc qur fond gris est un problème ? --amicalement, Salix ( converser) 16 décembre 2009 à 18:09 (CET)

Chez les voisins les Commons-iens

Bonjour,

Ce n'est peut-être pas complètement l’endroit, mais j’aurais aimé avoir un petit renseignement concernant l’accessibilité pour Commons. J'essaye, à l'occasion, d'exporter ce que cet atelier nous apprend là bas (par exemple, récemment un utilisateur a crisé parce-que des icônes sous Creative Commons utilisées sur le formulaire d'import étaient en link= vide ; je me suis permis de pointer vers les pages dédiées de cet atelier).

Commons regorge de bandeaux du type commons:Template:NASA-image. Puisque j'y interviens souvent et encore à l'avenir, j'aurais aimé savoir dans quelle mesure ils étaient accessibles, et si par hasard il y avait une façon de faire qui soit un tant soit peu meilleure (pour exemple, le link= non vide est encore largement répandu). Est-il important indiquer une alternative du style alt=Navette spatiale ? Car cela complique un peu la cuisine pour avoir des modèles auto-traduits (sachant que, à tord ou à raison, cette aspect primera toujours sur le reste). Le lien +/- est-il potable ? Autre ?

Je pose des questions un peu dans le vague, pas grave s'il n'y a pas de réponse . Cordialement, Jean-Fred (d) 4 décembre 2009 à 18:40 (CET)

Je suis loin d'être spécialiste mais la réponse à ta question ne serait-elle pas expliquée là ? --amicalement, Salix ( converser) 4 décembre 2009 à 20:31 (CET)

En partie, mais ma question se voulait plus générale : le bandeau lambda de Commons est-il potable en termes d'accessibilité, et le cas échéant peut-on y faire quelque-chose ? Jean-Fred (d) 15 décembre 2009 à 18:33 (CET)

Bonjour, après un examen rapide, les problèmes d'accessibilité immédiatement détectables sont :

• l'alternative textuelle de l'icône. Le link= vide évite de créer une image lien, mais mediawiki utilise alors par défaut le nom du fichier image comme alternative textuelle. Une solution immédiate serait de forcer l'alternative vide avec: [[File:Shuttle.svg|30px|link=|alt=]] (dans commons:Template:NASA-image/layout). Mais une solution plus robuste serait bien-sûr le remplacement par une image de background CSS.
• l'absence de signalements de changement de langue sur les liens « Deutch », « Français » etc. qui pourraient être ajoutés aisément (dans commons:Template:Lang links)
• le libellé non explicite du lien +/- (dans commons:Template:Edit). Faute de pouvoir générer un title sur le lien, ce libellé devrait être remplacé par un texte explicite (certes à internationnaliser).
• le modèle commons:Template:NASA-image/layout comporte un code invalide et ignoré par mediawiki : {| ... direction: {{Dir|{{{lang}}}}};". L'attribut HTML direction n'existe pas. L'auteur du modèle visait soit l'attribut HTML dir (pertinent), soit la propriété CSS direction (non pertinent: elle ne doit pas être utilisée de cette manière pour indiquer un changement de sens du texte, voir CSS vs. markup for bidi support). Par ailleurs, dans les deux cas, la mention de la langue comme valeur de substitution ne sera pas valide, les seules valeurs possibles étant ltr ou rtl.

--Temesis (d) 16 décembre 2009 à 06:42 (CET)

Merci pour ces réponses.

• Ok, dorénavant ce sera un alt vide. Mais (j'ai bien fait de demander), ce n'est pas trop ce que je comprends en lisant Wikipédia:Atelier_accessibilité/Bonnes_pratiques#Images_décoratives ?
  Vu le nombre de bandeaux sur Commons, tout passer en background CSS sera plutôt long ; mais prioritairement on pourrait commencer par les modèles les plus utilisés. Quelle serait la marche à suivre ?
• Ok, je vais (faire) corriger cela.
• Hmmm, ce sera sans doute plus délicat à faire avaler, mais on essaiera ;-). Un texte du style « Modifier » conviendrait ? Question d'un type qui n'y connaît goutte : il me semble avoir vu des cas semblables où abbr était utilisé ?
• Ho ho. Je plaide coupable pour le coup (ce devait être dans mes premiers modèles... ). Mais si j'ai bien compris, ce n'est pas si mal que ça : le code correct est celui de commons:Template:PD-Layout. Le modèle {Dir} prend en paramètre le code de langue et retourne bien ltr ou rtl. On se retrouve donc avec un style="... direction: ltr;" (propriété CSS bien formatée). Pour l'attribut HTML, il est généré par les modèles locaux tels {ar} ; ne pourrait-il pas de la même façon être pris en charge par {Lang} ?

Jean-Fred (d) 16 décembre 2009 à 18:39 (CET)

Paramètres de changement de couleurs dans les infobox

Bonjour, j'ai lancé le sondage suivant Wikipédia:Sondage/Paramètres de changement de couleurs dans les infobox. J'essai de limiter la multiplication des paramètres de modification de couleur dans les infobox. Il s'agit uniquement des paramètres où les rédacteurs peuvent modifier la couleur du fond et du texte des titres et sous titres directement depuis l'article, ce qui peut parfois provoquer l'usage de couleurs de texte au contraste faible par rapport au fond et inverssement. amicalement--Wikialine (d) 7 décembre 2009 à 22:12 (CET)

Voir Ce n'est pas l'accessibilité qui est en cause. le problème ne relève pas prioritairement de l'accessibilité, mais de choix éditoriaux, ergonomique et de design. A cet égard, l'idée selon laquelle un bloc de contenu devrait refléter la charte graphique propre à son sujet est défendable, mais très délicate à maîtriser dans WP. La solution d'une charte indépendante du design de chaque sujet est évidemment beaucoup plus économique. Mais, et c'est sans doute le point essentiel : dès que les avis spontanés des contributeurs interviennent, cette économie est à reconsidérer. Bref, ce n'est certainement pas un problème dont le traitement puisse être prioritaire, dans un tel contexte. En d'autres termes, plus simples: laisser courir pour l'instant est sans le plus sage, les gens sont assez buttés de part et d'autres et réfléchissent peu sur le fond, qui est difficile. --Temesis (d) 16 décembre 2009 à 15:41 (CET)

Effectivement ces paramètres ne posent pas de problème d'accessibilité. C'est son mauvaise usage qui peux provoquer un problème d'accessibilité. L'usage de 2 couleurs aux contrastes insuffisants. En lançant ce sondage, je tenais à voir ce que les wikipédiens pensaient de ces paramètres. Pour le moment il y a pas mal d'idées et de réflexion positives. Pour l'essntiel ces paramètres sont surtout utiliser sur les modèles sportifs. Dans les discussions plusieurs débuts de solutions sont avancées pour résoudre les roblèmes occasionnées par le mauvaise usage de ces paramètres. Enfin affaire à suivre, on verra bien ce qu'il en sortira in fine. amicalement--Wikialine (d) 18 décembre 2009 à 00:31 (CET)