Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2010 - second semestre

Une page de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Sommaire

Accessibilité du bandeau des nouveaux messages.[modifier | modifier le code]

Bonjour !

En deux jours, je découvre (par hasard) que certains utilisateurs ne savent pas à quoi sert le bandeau nouveaux messages : d'abord Harcourt, rapporté par Serein « Elle ne comprenait rien aux pages de discussion, messages, bandeaux oranges etc. » , puis l'Université de Bordeaux « Nous avons découvert l'espace page de discussion un peu tard ».

Est-ce un faux prétexte, ou y a-t-il un vrai problème ? Le message est-il assez pertinent ? Ne faut-il pas accentuer sa lisibilité (fond, forme ?) ?

Qu'en pensez-vous ? Trizek bla 24 juin 2010 à 17:10 (CEST)

Il me semble pourtant que ce bandeau d'un orange assez « flashi » qui me déclare « vous avez de nouveaux messages » (et qui apparaît sur chaque page que je visite) est relativement compréhensible ! Après, j’ai l'expérience wikipédienne, mais à mes débuts, je n’ai pas eu de soucis de ce côté-là — Steƒ ๏̯͡๏ 24 juin 2010 à 17:35 (CEST)
Si j'ai bon souvenir, au départ ça m'avait fait tout bizarre ce message. Mais j'avais pris le temps de comprendre.
Plus récemment, alors que je montrais WP et son fonctionnement à d'autres (ou simplement une page à l'occasion), il est arrivé que le bandeau de nouveaux messages soit présent. Et les personnes à côté de moi n'ont pas immédiatement compris ce message. Plutôt dérouté, car il apparaît à l'intérieur de l'article, sous le titre. Ce n'est pas vraiment à où on l'attendrait je pense. Et si le message était dans le menu de l'utilisateur (lien page de compte, page de discussion, etc.) en haut à droite ? Plus intuitif ? Ce serait à tester... Dodoïste [ dring-dring ] 24 juin 2010 à 17:53 (CEST)
+1 --Égoïté (d) 25 juin 2010 à 08:38 (CEST)
Le principe de lien n’est en soi, pas intuitif. Aussi bizarre que cela puisse paraître, les gens vont parfaitement comprendre qu'il peuvent cliquer sur des trucs écrits en bleu, mais pas sur des trucs écrits en bleu sur fond orange. Du coup, il vaut mieux prendre les gens en main.
Ne faudrait-il pas changer la phrase ? Trizek bla 25 juin 2010 à 09:26 (CEST)
Nuvola apps email.png
Vous avez de nouveaux messages ; cliquez ici pour les lire (diff ?).
Pensez également à vérifier dans l'historique de votre page de discussion la présence éventuelle d'autres messages en attente.
Et bien… Je trouve ton idée étrange, Dodoïste. En fait, je trouve que la ligne du haut est déjà pas mal pleine (pensez aux petits écrans), alors, la rallonger avec le bandeau (même modifié) des nouveaux messages…
Par contre, on peut très bien modifier le bandeau actuel en modifiant sa place et en le rendant plus explicite, comme le tente Trizek. Mais, à mon avis, il ne faut pas donner moult liens, on perd le nouveau contributeur, sans ça. Il clique sur le premier lien, tombe sur une page d'aide, et se dit donc que le bandeau orange ne lui est pas destiné par exemple. Je propose donc le bandeau suivant (notez qu'à mon avis, agrandir le bandeau actuel ne va pas forcément plaire aux anciens, il prend plus de place qu'auparavant). Et, on pourrait placer ce bandeau au-dessus du titre h1 des pages, par exemple — Steƒ ๏̯͡๏ 25 juin 2010 à 09:52 (CEST)
Nuvola apps email.png
Vous avez de nouveaux messages, cliquez ici pour les lire (diff ?).
Pensez également à vérifier dans l'historique de votre page de discussion la présence éventuelle d'autres messages en attente.

Par +1, je voulais dire que le bandeau ne devrait pas être sous le titre, comme le faisait remarquer Dodoïste. Par ailleurs une adresse plus directe ne pourrait-elle favoriser la compréhension ? et ajouter un lien vers l’historique ? Amclt, --Égoïté (d) 25 juin 2010 à 12:31 (CEST)

Nuvola apps email.png
On vous a envoyé un message. Cliquez ici pour le lire (diff ?).
Vérifiez aussi dans l'historique de votre page de discussion si d'autres courriers ne sont pas en attente.
Nette préférence pour le deuxième bandeau, avec le pluriel par défaut, dès fois que… Tant qu'à faire, je serai plus sur l'option suivante (le terme diff étant trop « jargonneux »). Trizek bla 25 juin 2010 à 12:38 (CEST)
Nuvola apps email.png
Vous avez de nouveaux messages, cliquez ici pour les lire.
Pensez également à vérifier dans l'historique de votre page de discussion la présence éventuelle d'autres messages en attente.
Plop, rapidement : lire Wikipédia:Demande d'intervention sur un message système pour commencer, qui traite une grande partie de ces questions. Ensuite, le message n'est pas déplaçable localement (pour le mettre éventuellement avant le titre, ce qui ne changerait absolument rien sur le fond pour l'utilisateur). Enfin, ce n'est pas un problème d'accessibilité (Par contre, créer un atelier qualité serait certainement avisé, on pourrait y noyer celui-ci en gérant plus efficacement ce genre de demandes). Cordialement, --Lgd (d) 25 juin 2010 à 12:42 (CEST)
Moins rapidement: le lien majeur de ce bandeau ne doit en aucun cas mener vers l'aide, mais vers le diff concerné, avec un libellé qui dit qu'il s'agit du dernier message en date. De même, le lien vers l'historique ne doit en aucun cas mener à l'aide, mais vers... deviner quoi ? Ce qu'il annonce, c'est à dire l'historique proprement dit. On en fait pas une interface Web à coup de page d'aides : on la fait à coup d'utilisations naturelles. --Lgd (d) 25 juin 2010 à 12:52 (CEST)
Allez, je termine: si vous voulez vraiment favoriser une interface qui ne laisse pas le nouveau venu se tromper, ce bandeau doit être remplacé par une fenêtre modale neutralisant tous les autres liens et formulaires de la page en cours de consultation, et donc ne laissant qu'un seul choix : aller consulter le diff de sa page de discussion. ça nécessite de revoir l'implémentation dans mediawiki, et surtout ça immédiatement faire hurler énormément de gens. Donc, ne pas chercher une illusoire solution qui garantisse que l'utilisateur suivra... Cordialement, --Lgd (d) 25 juin 2010 à 13:00 (CEST)
Je sais ça date un peu, mais forcer les visiteurs à visiter leur page de discussion immédiatement, posera problème dès qu'on est en train d'éditer une page : plus moyen de sauver son travail en cours, même pour une prévisualisation. C'est bien qu'on voit le message, mais empêcher de faire autre chose d'abord serait non productif et terriblement gênant. Laissons tout de même les visiteurs organiser leur temp, il n'y a pas à les forcer et leur faire tout abandonner immédiatement (d'ailleurs les admins très sollicités ne pourraient même plus répondre aux messages ou travailler sur une page s'ils devaient lire tout immédiatement dans l'ordre où les messages arrive et à la seconde. Une solution serait d'afficher le message en position absolue (pour être certain de le voir en haut de la fenêtre), comme le font certains messages généraux d'annonces importantes de MediaWiki. Mais le positionnement absolu n'est pas non plus très accessible et plutôt à éviter car il entraine des problèmes de superpositions et de compatibilité avec certains contenus (notamment des composants vidéos), et c'est aussi agaçant que les publicités Flash sur les sites d'hébergement gratuit, voire même maintenant les portails commerciaux ou d'actualité, où il faut attendre avant de pouvoir fermer la pub qui masque une partie de l'article (le pire que j'ai vu : le portail de SFR avec les logos SFR partout sur l'écran, mais Orange l'a fait avant lui...). Qu'on ne dise pas que ces boites superposées sont accessibles tant elles sont irritantes... Verdy p (d) 19 novembre 2010 à 12:52 (CET)
Allez en trois (comme à Pyramide) :
Cool, une nouvelle idée de projet avec ce projet de la qualité. Ça me donne follement envie de m'y mettre ! Argl Conflit ! Vit sociale, tout ça… Enfin, dans le cas présent, on est dans l’utilisation d'un outil (MediaWiki) et dans la manière d'aborder cet outil. AMHA, le fait de traîter seulement l'aspect handicap dans l’atelier d'accessibilité serait une erreur, mais là n’est pas la question. Quelques réponses intéressantes ayant été données, je vais aller voir du côté des messages système, une fois que ça aura bien décanté ici : autant faire un choix le plus approprié possible. Enfin, c’est mon avis.
Les liens présentés dans les exemples sont justement des exemples. Ces liens illustratifs en l'état sont effectivement prévus pour amener aux messages, et à l'historique. Je ne voyais pas quoi mettre d'autre pour illustrer. Sourire
Et pour finir, on ne va pas aller jusqu'à faire des fenêtres immenses (ça vire à la caricature, là), mais déjà un message universel, adapté, et lisible, ça sera déjà beaucoup. Par contre, le fait d'aller vers le diff directement, ou vers la page, voir d'amener directement vers la bonne section, ça c’est à réfléchir !
Trizek bla 28 juin 2010 à 11:36 (CEST)
Il suffit de relancer la demande actuellement en cours sur Wikipédia:Demande d'intervention sur un message système. Cordialement, --Lgd (d) 5 juillet 2010 à 07:46 (CEST)
Merci pour le tuyau. C’est parti. Trizek bla 6 juillet 2010 à 00:44 (CEST)
+1 avec Lgd : c’est soit le pop-up, soit les gens qui de toute façon ne regardent que ce qu’ils connaissent eh bien... ne verront pas ou tard ce message. Épiméthée (d) 15 juillet 2010 à 20:58 (CEST)

{{Titre section}}[modifier | modifier le code]

Désolé si le sujet a déjà été abordé mais ce modèle est plutôt ignoble non ? ce qui devrait être en background est posé avec <img>, on crée 3 divs pour poser un pauvre h2 et la « mise en page » à coups de position:absolute fout forcément le camp si on ose zoomer le texte. ceci répété 8 fois sur la page d'accueil (sur les portails aussi, mais c'est moins grave disons) avec les alt remplis en plus…

« HSutvald2.svg ! Dit le robot
_ Ha bah oui, merci Wikipédia ! »

Pour ma part j'ai un peu essayé de voir ce que je pouvais faire dans mon coin mais j'en suis incapable (visiblement mediawiki censure background:url). en créant la (les) classe(s) idoine(s) devrait y avoir moyen de faire quelque chose de plus propre - mirrorRᴑᴙᴚim  27 juin 2010 à 03:37 (CEST)

Oui, il est tout à fait possible de refaire un modèle de titre propre. Dans la mesure où la mise en forme de la page d'accueil semble maintenant à peu près stabilisée, et où ce modèle commence à être utilisé dans d'autres pages, ce serait le bon moment pour le faire (gérer les images en background CSS et corriger le code HTML en conséquence). --Lgd (d) 5 juillet 2010 à 07:45 (CEST)

Version audio des articles ?[modifier | modifier le code]

Hello,
sur la page Matamata j'ai vu qu'une version audio était disponible. Est-ce nécessaire / utile au projet, par exemple par rapport aux programmes qui permettent de lire les articles (qui ont l'avantage de lire l'article courant, et non une version éventuellement différente, plus ancienne) ?
Je peux faire ce genre d'enregistrements, mais uniquement si ça a un réel intérêt pour le lecteur (l'auditeur, en l'occurence), à savoir si il est en mesure de savoir facilement qu'une version audio existe, et si ce n'est pas redondant avec les programmes de lecture existant.

Cordialement, Hexasoft (discuter) 4 juillet 2010 à 23:00 (CEST)

Cf. Projet:Articles audio. TED 4 juillet 2010 à 23:10 (CEST)
Il faut bien comprendre que l'on raisonne systématiquement en termes de priorité. Il existe trois niveaux d'accessibilité, qui reposent les uns sur les autres : le plus souvent, mettre en place une technique d'accessibilité du niveau le plus élevé sans avoir au préalable répondu aux exigences des niveaux précédents revient à construire sur du sable. Les conditions propres à chaque projet Web sont également déterminantes (ici, la limitation à des enregistrements audio réalisé ponctuellement alors que le contenu évolue constamment). Le cas des versions audios des articles (technique du niveau d'accessibilité le plus élevé, c'est à dire AAA) en donne un bon exemple, pour trois raisons principales :
  • la première exigence est de rendre le contenu exploitable non seulement par les lecteurs d'écran, mais d'une manière générique par n'importe quelle aides techniques, afin de répondre le plus largement possible aux besoins des différents handicaps. Pour cela, la priorité va, non pas aux versions audio, mais à des mesures de niveaux d'accessibilité plus immédiats (A et AA).
    Dans le cas de WP, c'est en particulier :
    • l'utilisation appropriée et complète des titres de sections (pas de faux titres fait avec « ; » notamment)
    • le balisage des tableaux de données (scope, titre de tableau)
    • l'usage pertinent des tableaux de mise en forme (pas d'organigramme ou d'arbre généalogiques faits à l'aide de tableaux, par exemple)
    • les alternatives textuelles des images
    • les changements de langue (modèle {{lang}})
    • l'absence de pseudos-contenus CSS (ne pas utiliser les modèles de génération de cartes, de schémas, etc).

    En travaillant avant tout sur ces exigences, on rend le contenu accessible dans les lecteurs d'écran, qui offrent une véritable possibilité de consultation et d'interaction avec le contenu, à la différence du fichier audio qu'on ne peut qu'écouter statiquement et passivement. Mais on couvre également d'autres besoins : par exemple, le titrage de section permet la navigation au clavier dans le contenu dans le cas de handicap moteur empêchant l'usage de la souris. De même, l'absence de pseudos-contenus CSS permet l'adaptation du rendu en réponse à d'autres handicaps visuels. Enfin, le bénéfice s'étend au-delà des problèmes de handicap au sens classique : par exemple, les alternatives textuelles facilitent la consultation des contenus en cas de désactivation du téléchargement des images (bas-débit, connexion mobile). Les bénéfices d'une version audio sont beaucoup plus réduits.

  • Dans le cas de contenus qui sont fréquemment modifiés, une version audio statique (telle que réalisée actuellement par le projet audio) n'a guère de sens. Il est techniquement tout à fait possible de mettre en place une génération de fichier audio à la volée, qui correspond, elle, au contenu réellement publié. Or, les mesures prioritaires indiquées ci-dessus ont également un impact majeur sur la qualité de cette éventuelle version audio dynamique, générée par un système de synthèse vocal côté serveur. Ce système n'existe pas actuellement sur WP, mais une des conditions de son éventuelle mise en place à l'avenir sera que les articles soient exploitables... par un lecteur d'écran.
  • Enfin, en réalité, la mise en place de versions audio n'est pas en rapport avec les handicaps visuels, mais avec les handicaps cognitifs. Plus précisément, c'est un des moyens retenus pour améliorer l'accessibilité cognitive quand « un texte nécessite une capacité de lecture plus avancée que le premier cycle de l'enseignement secondaire ». Attention : un des moyens. Or, parmi les autres techniques concernées, dans le cadre de Wikipédia, c'est la rédaction du résumé introductif des articles et l'apport d'illustrations explicatives qui apparaissent en fait comme les plus pertinentes : elles sont beaucoup plus simples à mettre en oeuvre, et elles s'inscrivent surtout entièrement dans la démarche éditoriale existant par ailleurs.
En conclusion : les versions audios enregistrées par les contributeurs ne sont pas dénuées d'intérêt, mais celui-ci est extrêmement marginal dans le contexte de WP. Cordialement, --Lgd (d) 5 juillet 2010 à 07:32 (CEST)
Oui, j'avais bien conscience des limites des versions audio, et surtout du besoin plus important de rendre "propre" les articles pour les outils de traitement (comme les lecteurs d'écran). J'ai suffisamment à m'occuper avec le contenu (à quoi bon lire un article creux) ou avec la qualité du code et des sources, mais s'il avait existé une bonne raison (une raison utile) de faire ce genre de chose, j'aurai pu apporter ma contribution (et en plus j'ai une belle voix grave Clin d'œil). Cordialement, Hexasoft (discuter) 5 juillet 2010 à 21:46 (CEST)

Image non cliquable[modifier | modifier le code]

Bonjour

Je souhaitais améliorer l'accesibilité de Ligne d'Auray à Quiberon qui utilise plusieurs modèles dont l'accessibilité n'a pas été prise en compte (voir Wikipédia:Modèles/BS). Je bloque sur le fait de rendre une image non cliquable... tel que Fichier:BSicon .svg (aussi appelé Fichier:BSicon leer.svg). Faut-il utiliser <imagemap></imagemap> ou "tout simplement" [[File:example.jpg|link=|caption]] ('''link=''')? (trouvé dans Aide:Image cliquable) et dans http://www.mediawiki.org/wiki/Images .

Cordialement, --Manu1400 (d) 7 juillet 2010 à 17:38 (CEST)

Bonjour,
Il faut utiliser link=, et surtout renseigner les alternatives alt. En sachant cependant qu'à côté du problème des images, ce modèle en pose un tout aussi important du coté des tableaux : en fait, il faudrait commencer par « sortir » ce modèle de l'infobox, puis le traiter comme un tableaux de donnée classiques, c'est à dire le doter d'un titre caption et de cellules d'en-têtes de colonnes correctement renseignées. Cordialement, --Lgd (d) 11 juillet 2010 à 08:11 (CEST)

langue dans un modèle[modifier | modifier le code]

Bonjour

Le Modèle:Traduction/Référence est beaucoup utilisé. Il serai peut être utile d'essayer d'utiliser le Modèle:Lang (ou une autre solution permettant l'ajout de l'information au sujet langue du texte) sur le titre de l'article... J'ai essayé rapidement, voir éventuellement l'historique de Modèle:Bac à sable. --Manu1400 (d) 10 juillet 2010 à 18:04 (CEST)

Normalement ce devrait être bon (usage de span lang=""). Voir l'historique du modèle pour voir ma correction. Cela te convient ? Cordialement — Steƒ ๏̯͡๏ 10 juillet 2010 à 18:12 (CEST)
Il me semble que tu en as oublié un dans le modèle (si pas de paramètre type). Par ailleurs, dans l'absolu, le modèle est susceptible de renvoyer un code incorrect dans certains cas, puisque les préfixes des wikipédia ne correspondent pas toujours aux codes de langues à utiliser. Mais il est certainement rarement employé pour les langues concernées, c'est donc un moindre mal. Cordialement, --Lgd (d) 11 juillet 2010 à 08:16 (CEST)

Wikimania et accessibilité, retour d'expérience[modifier | modifier le code]

Coucou. La conférence et l'atelier sur l'accessibilité ont rempli une salle de développeurs, à notre grande surprise. J'ai eu des contacts avec de nombreuses personnes, qui ouvrent bien des possibilités.

Dans l'immédiat, Roan Kattouw de l'initiative d'utilisabilité a pris note des problèmes reportés au sujet de Vector. Chaque semaine, je lui enverrai un bug détaillé (afin de lui économiser son temps, éviter les malentendus et être fiable). Ils vont prendre soin de corriger ce qui concerne Vector, mais ne toucheront probablement pas au reste. C'est le premier travail sur lequel je vais me focaliser.

Pour le reste, bien des options sont envisagées. Une proposition bien faite sur Wikimedia Strategy est susceptible de convaincre la fondation, selon son responsable Eugene Eric Kim. C'est la priorité n°2. Dans le cas où cela ne marcherait pas, les chapitres français et allemands sont à priori d'accord de financer un expert en accessibilité. Un intérêt de la part de l'équipe de Wikia, dont celui d'un développeur front, a été remarqué. Enfin, il serait intéressant de regrouper les développeurs qui ont montré leur intérêt dans une initiative.

Je mettrai à disposition une version augmentée de ma présentation en anglais, afin de toucher la Fondation, les développeurs, et la communauté anglophone plus généralement. J'ai pas le temps de tout détailler. L'essentiel est là. À suivre. :-)

Plop,
Sur le premier point : à vrai dire, il faudrait déjà un audit complet de la chose au préalable, selon une méthode d'application WCAG, ce qui peut se faire cet été par exemple à la suite de ce que Gilles et moi-même avions déjà fait. Par la suite, selon ATAG, l'année prochaine, après sa sortie, car ce sera l'enjeu et l'outil essentiel. Mais des patchs au pif sans priorité sur des retours désordonnés, non. Plus généralement, on ne « corrige » pas de l'accessibilité, c'est une voie en impasse : on fait du développement accessible. Pour l'instant, on ne sait même pas dans quelle mesure et où il faudrait patcher Vector immédiatement ni dans quelle mesure il faudra distribuer les priorités sur la roadmap ultérieur de mediawiki. Il faut être clair : le souci est que les contributions libres n'apporteront rien de plus que des signalements de problèmes disparates, aucune priorisation ni aucune garantie de conformité WCAG.
La proposition n°2 est où, précisément ? Désolé, mais Wikimedia Strategy est une chose illisible où il est impossible de trouver quoi que ce soit.
Enfin, sur une hypothèse, faite d'avoir trouvé la fameuse hypothèse : « financer un expert en accessibilité » : oui, mais non, cela peut être une bonne voie pour de l'argent dépensé à court terme à peu près en pure perte à long terme. Être assisté pour acquérir une culture, des compétences et des outils en accessibilité et apprendre à s'en servir de levier de qualité, ça, ce serait autre chose, mais c'est un tout autre marché et une toute autre démarche.
Mais sinon, c'est super, bravo pour ton investissement et merci pour ces retours qui complètent très utilement d'autres canaux. Cordialement, --Lgd (d) 13 juillet 2010 à 20:58 (CEST)
Sgrmbl*... C'est l'inconvénient des post où il y a trop à dire, et le résumé ne peut être suffisamment complet... Maieuh, pas taper. Pleure
J'ai bien en tête une démarche telle que tu la décris. Mais c'est pas tout simple comme tu t'en doutes. Saches pour l'instant que j'ai bien observé ta démarche ici, et que je suis déjà conscient des remarques que tu as faites là. J'essaie de te faire un état de la situation complet rapidement.
Oh, et pour la n°2 : la proposition n'existe pas encore. Bien à toi, Dodoïste [ dring-dring ] 13 juillet 2010 à 22:04 (CEST) *Note : crédit de l'auteur : Lgd.
Ah non : Sgrmbl, c'est ma marque de fabrique à moi, ça Mort de rire. --Lgd (d) 13 juillet 2010 à 22:34 (CEST)
Aha, c'est que tu as placé « Sgrmbl » sous CC-by-sa... Sifflote OK ok, je viens de te créditer. Mort de rire
  1. Du côté de l'Usability Initiative : Naoko Komura (qui ne travaille plus à la WMF depuis le 17 juin 2010) a dit, il y a quelques mois, avoir considéré l'idée de demander un audit d'accessibilité de ce que l'Usability Initiative a produit. Mais avant de le faire, elle voulait voir corrigé les erreurs basiques. Ce qui me paraît étrange comme approche, puisque le but d'un audit est justement de montrer les erreurs... Cette piste ne semble pas avoir évolué avant le départ de N. Komura.
  2. Danese Cooper a déjà pensé plusieurs fois à employer un expert en accessibilité au sein de l'équipe, selon ce qu'elle m'a dit à Wikimania. Je n'ai pas bien compris pourquoi elle n'est pas allée au bout de cette idée. Apparemment, il y a plusieurs raisons évoquées en vrac : budget limité, d'autres priorités d'emploi dans l'immédiat, équipe actuelle qui est très jeune (beaucoup de nouveaux employés - enfin d'ailleurs, car ça manquait pour un site du top 6 !), et besoins mal définis en matière d'accessibilité.
  3. Roan Kattouw, employé à temps partiel et à durée limitée a été très intéressé par l'accessibilité. Nous avons eu plusieurs discussions, il m'a présenté à plusieurs personnes, etc. Il est enthousiasmé à l'idée d'améliorer l'accessibilité de Vector. Il me semble être un levier potentiel, dans une démarche de qualité de manière générale. Je regrette qu'il ne soit pas employé à long terme.
  4. Wikimedia Strategy a été évoqué comme un moyen de présenter un démarche d'accessibilité, et de l'intégrer aux objectifs de la Fondation. Mais cela nécessite d'être bien préparé. Quand à la démarche à présenter, voir aux paragraphes suivants. Un des avantages est qu'on peut facilement voir le soutien de la communauté pour une proposition. Or, selon mon expérience sur en.wiki, et récemment à Wikimania, on devrait pourvoir facilement récolter un bon nombre de signatures. À tenter, si ça marche c'est bien.
  5. Pour l'approche, tu as raison d'insister sur le développement à long terme. Entres différents blocages ici et là, j'en étais venu à considérer une approche à court terme, tout en connaissant ses inconvénients. Je reviens sur terre. XD
Donc, si je comprends bien, trois approches sont envisageables :
Approche n°1 : Intégrer un expert en accessibilité à long terme dans l'équipe de l'Usability Initiative. Puisque c'est eux qui font les le plus de développement front ces temps. Mais est-ce que c'est aussi une option qu'il ne soit pas directement en lien avec l'équipe UX, et plutôt avec d'autres devs de la WMF ?
Approche n°2 : Donner des formations complémentaires prioritairement aux développeurs front, comme WebAIM training. C'est hautement désirable, mais dans quelles mesures est-ce suffisant ? D'autres démarches de sensibilisation et/ou de formation sont-elles envisageables ?
Approche n°3 : Je verrais bien un partenariat avec le National Center on Disability and Access to Education, par exemple. Déjà que l'accessibilité me semble proche des buts de la WMF, le côté de l'accès aux ressources éducatives semble parfaitement concorder. Là aussi, dans quelles mesures un tel partenariat serait suffisant ? Et quels buts précis donner à ce partenariat ? La WMF fait de plus en plus de partenariats très intéressants, il me semble donc que cela collerait avec leur démarche.
J'ajoute que je conçois le rapport de bug concernant Vector comme une démarche de sensibilisation à l'accessibilité, faute de mieux. Plusieurs erreurs ont été identifiées, sans priorisation à l'heure actuelle. Certaines erreurs sont faciles à corriger. Les sources d'autres erreurs ne sont pas complètements identifiées. Et pour certains cas, la manière de les corriger de manière optimale n'est pas simple à décider. Conscient des manques dans notre évaluation (bien plus que mes deux camarades, à mon grand regret), je compte sur les détails de Gilles ou toi à ce sujet pour entreprendre cette démarche. Si je n'ai pas votre soutien, je mettrai cette approche en attente d'un audit par exemple.
Merci de tes lumières. :-) Dodoïste [ dring-dring ] 16 juillet 2010 à 05:29 (CEST)
J'ai eu quelques retours, notamment de la part de Seb35 sur ce qui s'était dit là-bas. Je ne suis pas sûr qu'un wiki soit l'outil idéal pour mettre en place une politique de mise en accessibilité ; de plus, la nature, disons éclatée de la répartition des responsabilités dans le contexte des projets de la Fondation (tant au niveau local des wikis, qu'à celui d'une gouvernance d'ensemble) implique qu'on ne peut pas imaginer de solution simple à appliquer, dans la précipitation et l'effervescence. Bref, il faudrait qu'on se prenne le temps d'une vraie réflexion IRL sur le sujet, une brainstorming en petit comité autour d'une table. Lgd et moi en avons déjà parlé. Il faudrait qu'on se relance sur le sujet, mais je ne le pourrai pas avant le milieu de l'automne... Litlok (m'écrire) 16 juillet 2010 à 08:40 (CEST)
Coucou. Euh, lorsque tu dis « pas sûr qu'un wiki soit l'outil idéal », tu parles de quoi exactement ? De Wikimedia Strategy ? C'est techniquement un wiki, mais les propositions ne sont pas faites pour être refondues par n'importe qui n'importe comment. Du moins, si j'y fais une proposition, je veillerai à que ce soit le cas.
J'aimerais bien de détails sur ce qu'a dit Lgd dans la première section sur Wikimania, à savoir « mettre en place une démarche et des outils de suivi de la qualité des développements, qui sont un peu la mort de la contribution technique à mediawiki première génération ».
C'est très volontiers que je me déplace sur Paris (ou où que vous soyez en France) pour discuter. Mais J'aimerais bien pouvoir battre le fer pendant qu'il est encore chaud. Notamment, le "Strategic planning" de la fondation sera clos en septembre, donc si on pouvait se bouger avant ce serait bien. Bien à vous, Dodoïste [ dring-dring ] 16 juillet 2010 à 15:07 (CEST)
Disons qu'un wiki, à mon sens, c'est très bien pour écrire ensemble sur des sujets qui font (plus ou moins Clin d'œil) consensus, mais que cela ne peut pas être un outil de planification et encore moins de gestion de projet. C'est normal, ce n'est pas conçu pour cela.
« Mettre en place une démarche et des outils de suivi de la qualité des développements, qui sont un peu la mort de la contribution technique à mediawiki première génération », cela signifie que pour parvenir à une gestion de l'accessibilité, il faudrait au préalable mettre en place une gestion de la qualité dans son ensemble. Cela implique d'identifier clairement des rôles, techniques ou de conseil, à chaque étape du processus de production sur Wikipédia (contenu et interface). Et pour éviter les initiatives pleins de bonne volonté, mais potentiellement nuisibles (je préfère le terme anglais de harmful...), il semble alors inévitable de restreindre les périmètres d'intervention de chacun, en fonction des compétences reconnues. Concrètement, il faudrait avoir des contributeurs spécialisés par exemple en JS, avec interdiction aux autres de bidouiller le JS. D'autres en CSS, avec les mêmes restrictions. D'autres sur la syntaxe des modèles wiki, etc. Il va alors de soi qu'une telle démarche prendrait totalement à contrepied l'« esprit wiki » (du moins en apparence : on recentrerait les contributions sur la réelle valeur ajoutée du contenu en les détournant de la gadgetisation de l'interface), et ce serait bien « la mort de la contribution technique à mediawiki première génération ». Pour en discuter, cela risque d'être difficile car théoriquement, je suis en vacances ce soir (wouéééé !), pour ne reprendre que la deuxième semaine de septembre. Et j'ai pas mal d'obligations familiales et professionnelles prévues déjà cet été Clin d'œil Litlok (m'écrire) 16 juillet 2010 à 15:37 (CEST)
Le wiki n'est que là à but de brainstorming, les idées retenues sont transférées ailleurs. Cela ne me semble pas pertinent d'écarter la piste de Wikimedia Strategy avant d'avoir essayé. Surtout qu'on a pas vraiment mieux...
Cette réponse est intéressante, mais je reste sur ma faim. Notamment parce que j'ai la nette impression que c'est une démarche classique sur un projet Web, mais pas du tout adaptée à Wikimedia. Surtout en l'état de l'équipe. Il n'y a pour l'instant qu'un domaine où cette approche est utilisée, c'est la sécurité. Avant d'être installée, chaque extension doit être revue par Tim Starling, et corrigée lorsque besoin est. Or, ce processus est actuellement très bloquant, notamment parce qu'une seule personne est responsable de cela et que c'est très très loin d'être suffisant. La WMF emploiera d'autres personnes pour ce job à l'horizon 2011-2012, mais en attendant cela frustre passablement les autres dévs...
Je n'arrive pas à imaginer que cette démarche puisse être étendue à d'autres domaines sans effectivement mettre à mort le bouzin. En toute franchise, j'ai l'impression que vous mettez la barre bien trop haut, alors que tout reste à faire. Puisque qu'on avance de toute façon en terrain inconnu, je préférerais de loin tester quelques approches, et voir ce qui marche ou ne marche pas. Nous n'avons rien à perdre, on peut difficilement faire pire que la situation actuelle de toute façon.
Bonnes vacances Gilles. :-) J'espère aussi avoir l'opinion de Lgd. Et peut-être qu'en attendant ton retour je pourrais rencontrer Lgd pour avoir une première discussion ? Dodoïste [ dring-dring ] 16 juillet 2010 à 18:40 (CEST)
Je reviens vers toi dans le WE, pour compléter à la suite de Gilles.
Dans l'immédiat : il est évident que Wikimedia a ses particularités et qu'il ne s'agit pas d'y appliquer une démarche de gestion de qualité totalement centralisée. Il y a par exemple des choses à faire en auto-contrôle (recette) pour le développement, à condition de mettre en place les outils nécessaires (référentiels de tests, plate-forme de suivi). Mais il ne sera pas possible de mettre en place une réelle stratégie d'accessibilité (et plus généralement de qualité) sans restreindre aussi divers périmètres d'intervention au niveau local au moins.
Sinon, il y a en ce moment des choses qui pourraient t'intéresser, à titre d'exemple de gestion d'amélioration ergonomie / accessibilité, avec le cas de Dotclear (les deux projets ne sont pas du tout à la même échelle et ce qui suffit à l'un n'est évidemment pas la réponse pour l'autre, mais il y aussi de nombreux points communs et divers incontournables dans la méthode ;-) ). Cordialement, --Lgd (d) 17 juillet 2010 à 09:00 (CEST)
Je crois comprendre que tu parles de check-list (référentiel) adaptée au contexte de Wikipédia en parlant « d'auto-contrôle (recette) » ? Oui, j'en avais discuté avec Roan Kattouw, ce serait une très bonne idée. Par contre, au niveau de la « plate-forme de suivi », pas sûr que je comprenne ce que tu veux dire exactement. Est-ce que ça pourrait avoir un lien avec Project:Selenium_deployment que je n'ai pas trop compris ? Voir aussi Extension:Selenium et SeleniumFramework.
Je crois que j'ai compris le plus important de cette comparaison : avoir Lgd dans l'équipe est suffisant pour rendre Dotclear accessible, mais ne suffit pas dans le cas de Wikipédia. Mort de rire
Plus sérieusement, voyons si je comprends ta comparaison, qui n'est pas très explicite (c'est pas accessible à mon handicap cognitif Mort de rire). Doctlear est semblable à WP en tant que CMS doté d'une équipe de développeurs bénévoles, pas très soudés jusqu'à récemment. Et qu'une grosse partie du travail a été de souder l'équipe. En gros. Donc il s'agirait aussi de souder l'équipe de dévs. de Wikipédia. Je ne peux guère tirer plus de conclusions au vu du peu d'informations données. Dodoïste [ dring-dring ] 20 juillet 2010 à 03:41 (CEST)

la représentation graphique de données brutes - avec un outil externe[modifier | modifier le code]

Est-ce que l'outil externe Visualizer est accessible ? Exemple : Visualize Wikipedias growth up to 2010 avec l'outil externe http://toolserver.org/~al/visualizer4wm.php --almaghi (d) 16 juillet 2010 à 23:41 (CEST)

Je précise, puisque j'y ai jeté un œil très intéressé : C'est un JavaScript qui récupère les données présentes dans un tableau, pour générer un graphique interactif en flash. Puisqu'il s'utilise de manière combinée avec un tableau (un minimum accessible sinon le contenu n'est pas utilisable), cela ne pose pas de problème d'accessibilité à priori.
Un détail par contre : le lien vers le graphique est pour l'instant dans la légende du tableau « |+ ». Au besoin, le parser, qui fonctionne actuellement avec le lien dans la légende, peut être modifié, selon almaghi. La question est de savoir si il est nécessaire que le lien vers le graphique soit hors de la légende, ou si c'est acceptable. Bien à vous, Dodoïste [ dring-dring ] 17 juillet 2010 à 01:24 (CEST)
Pour compléter :
  • la présence du lien « Visualize the following data » ne pose pas de problème spécifique d'accessibilité (sa présence dans le titre du tableau n'est pas optimale, mais n'est pas bloquant). En d'autres termes, la présence de l'outil ne compromet pas l'accessibilité de la page Visualize Wikipedias growth up to 2010.
  • en revanche, l'outil lui-même, c'est à dire la page cible sur le toolserver, n'est absolument pas accessible : ce n'est pas à cause de Flash en lui-même, mais de la manière dont celui-ci est codé. Parmi les blocages immédiats :
    • impossibilité d'utiliser les contrôles de l'interface flash au clavier
    • utilisation du paramètre wmode qui masque totalement l'objet flash aux lecteurs d'écran
Cordialement, --Lgd (d) 17 juillet 2010 à 10:01 (CEST)
Merci pour ces réponses. J'avais oublié la navigation au clavier. Une partie des informations se trouve dans Wikipédia:Atelier_accessibilité/Bonnes_pratiques#Javascript. Voir en particulier SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons J'ai vu plusieurs events sans alternatives spécifiques au clavier, mais j'ai absolument pas compris le script, donc je ne serais dire quels sont les passages précis qui nécessitent correction. SCR20: Using both keyboard and other device-specific functions sera utile à almaghi à mon avis.
Pour les lecteurs d'écrans, je ne comprends pas. Pourquoi n'est-on pas dans le cas G190: Providing a link adjacent to or associated with a non-conforming object that links to a conforming alternate version ? En quoi un lecteur d'écran va plus tirer profit du graphique animé que du tableaux ? Et comment un lecteur d'écran est-il censé lire un graphique aussi complexe, et informer l'utilisateur de l'évolution du contenu ? Même avec ARIA ça me semble compliqué. O.o Bien à toi, Dodoïste [ dring-dring ] 17 juillet 2010 à 22:10 (CEST)
G190 ne concerne que les cas de contenus ou de technologies non compatibles, c'est à dire ceux qu'il ne serait pas possible de rendre accessible. Ce n'est pas le cas de cette interface Flash. Quant au résultat dans un lecteur d'écran, c'est le malentendu classique sur le rôle de l'accessibilité : elle ne consiste pas à corriger les défauts des choses mal faites initialement. Ici, ce graphique interactif animé est proprement imbittable pour tous les utilisateurs; le rendre accessible ne consiste qu'à garantir qu'il n'y aura pas de discrimination et que les utilisateurs d'aides techniques pourront pleinement profiter... de ses défauts intrinsèques Clin d'œil. Évidemment, sur le fond, l'exercice a un intérêt assez limité. Disons que c'est un bon exemple de la différence entre accessibilité et qualité, ou encore du non-sens qu'il y aurait parfois à mener une démarche d'accessibilité isolée des autres aspects de la qualité Web. Cordialement, --Lgd (d) 18 juillet 2010 à 07:16 (CEST)
OK. En fait, les parties à corriger du code proviennent directement de google code. Le dev là-bas est réactif, dons si tu donnes des détails, notamment sur le problème avec flash (j'ai suffisamment compris l'interaction au clavier), je peux reporter, et ça peut être corrigé.
En ce qui concerne la remarque « imbittable pour tous les utilisateurs » : là, oui, le résultat produit n'est pas très intuitif. Mais suivant comme il est utilisé, il fait aussi de jolies choses. Et puis, le graphique animé n'est qu'une option de cet outil parmi un bon nombre, dont cet exemple pertinent.
Mais surtout, je te trouves assez rude avec cet outil, alors qu'il est une nette avancée par rapport aux outils existants. Entre les images complexes, difficiles à mettre à jour, et qu'on ne sait pas comment légender (l'alternative textuelle, on en parle pas !), et les désastreuses <timeline>... L'avantage de cet outil est qu'il part d'un tableau existant, et sémantiquement correct pour qu'il soit réutilisable par l'outil. Contrairement aux cas précédents, on est au moins sûr qu'il existe une alternative accessible. Et c'est super simple à mettre à jour, il suffit de modifier le tableau.
J'ajoute qu'avec almaghi nous avons fait attention à ce que la présence du titre du tableau soit encouragé par le modèle. Par exemple, pour qu'on ait un titre au graphique généré (très utile pour comprendre le graphique), il faut fournir un titre au tableau. Voir aussi cette amélioration collatérale d'un tableau (troisième modèle, ligne 92 dans le diff). Almaghi ne pensait pas à l'accessibilité, mais il avait besoin d'améliorer le tableau pour avoir un bon résultat. Je pense que cet outil est un levier indirect pour améliorer l'accessibilité des tableaux. Bien à toi, Dodoïste [ dring-dring ] 20 juillet 2010 à 02:37 (CEST)

gif animé ou ogv ?[modifier | modifier le code]

Bonjour à tous, je viens pour un conseil sur l'utilisation du gif animé et du ogv. Il existe, en mathématiques, des schémas animés qui illustrent de manière attractive des propriétés mathématiques.

Je suis pour ma part toujours frustrée par les gifs animés qui défilent en boucle sans jamais s'arrêter et nous laisser le temps de comprendre le phénomène. J'avais cru trouver la solution en les remplaçant par des fichier ogv qui permettent de faire pause à tout moment.

  • exemple File:Regular Pentagon Inscribed in a Circle 240px.ogv vs File:Regular Pentagon Inscribed in a Circle 240px.gif. J'étais très contente de moi jusqu'à ce que quelqu'un me signale que le film ogv n'est pas lisible car la personne n'a pas téléchargé le bon truc (VLC ?) . Du coup je suis perplexe : faut-il faire des animations gif ? Sont-elle lues par tous? Faut-il des animations ogv ? Mais dans ce cas quelle est la proportion des gens qui ne peuvent pas le lire? . Merci de me donner votre avis. HB (d) 23 juillet 2010 à 12:21 (CEST)
Bonjour,
Hum... En version courte, disons que l'un et l'autre sont très en dessous de ce que l'on peut faire pour l'instant dans d'autres contextes avec d'autres technologies (flash, pour ne pas le nommer), mais que les atouts immédiats et le potentiel de l'ogv l'avantagent de façon évidente face au gif animé, qui est une technologie immédiatement réduite, figée et au potentiel inexistant. Notamment la possibilité d'un véritable contrôle utilisateur, les modes d'implémentations de celui-ci (compatibilité clavier par exemple), la gestion d'alternatives et les déclinaisons possibles selon les capacités du navigateur (déjà utilisée avec la déclinaison d'un ogv en élément video, java, quicktime, etc. qui fait qu'il n'y a pas si souvent que cela à « télécharger un truc »)
La question n'est pas de savoir si les animations gifs seraient « lues par tous » et pas les ogv : la question est qu'elles sont et resteront inutilisables ou dénuées de sens pour une partie des utilisateurs (qui ne peuvent pas en contrôler le défilement, pour lesquels il n'y a pas d'alternative textuelle, etc). Le recours à ogv vise à répondre à ce souci, et parvient dès aujourd'hui à y répondre en (petite) partie.
Bref, les deux technologies sont pour l'instant insatisfaisante, mais l'une (gif) va le rester et pas l'autre. Le jeu en vaut donc très largement la chandelle. Cordialement, --Lgd (d) 23 juillet 2010 à 13:11 (CEST)
Petit ajout sur l'avenir du .ogv et de la vidéo sur Wikipédia en général. Wikimania a été dotée cette année de 3h de conférences à ce sujet. Ce qui retient surtout mon attention est le partenariat entre kaltura.org et Wikimedia, très riche en apports. Un résumé de la conférence est disponible sur Submissions/Collaborating on Collaborative Video for Wikipedia.
Les gens de Kaltura sont, à ce que j'ai pu voir de leur démarche, soucieux de la qualité et des standards. Il veulent notamment apporter un système de sous-titrages des vidéos plutôt prometteur, ce qui est crucial pour l'accessibilité. Et le support du format libre WebM sera probablement ajouté, ce qui augmentera l'interopérabilité. Bonne nouvelles donc, à suivre. Dodoïste [ dring-dring ] 23 juillet 2010 à 21:52 (CEST)
Merci pour vos réponses. J'en conclus que, malgré les défauts actuels (dont une lisibilité non universelle) le format ogv a plus d'avenir que le gif animé. Je vais donc continuer dans cette voie. Un étonnement cependant concernant flash : quelqu'un de mon entourage me dit que c'est un logiciel propriétaire qui n'est pas du tout dans la logique du libre.HB (d) 24 juillet 2010 à 07:40 (CEST)
@Dodoïste : merci pour ces infos récentes.
@HB : Le recours à Flash est évidemment exclu aujourd'hui dans des projets comme ceux de Wikimedia, et historiquement mal perçu dans le monde du Libre. Mais cela n'empêche pas cette technologie d'être pertinente dans d'autres cadres (un exemple récent et fameux) et de permettre par exemple de répondre à des besoins d'accessibilité, dans les limites des implémentations actuelles (un exemple). Pour conclure, cet article me semble bien résumer les choses à l'heure actuelle d'un point de vue... neutre Clin d'œil : Flash and Standards: The Cold War of the Web. Cordialement, --Lgd (d) 24 juillet 2010 à 09:33 (CEST)
Tout à fait d'accord, on ne va pas recommander Flash, quand les outils pour travailler dessus sont tous propriétaires et chers et les alternatives de qualité très médiocre. L'avenir est plutôt du côté de HTML5 (et de SVG qui est aussi animable et scriptable, y compris pour les images bitmap qu'il peut encapsuler) qui pourrait rendre Flash obsolète. L'alternative « standard » sinon c'est MPEG mais c'est bourré aussi de brevets et de restrictions pour les implémentations (et les licences sont chères).
On a aussi MNG (le format libre PNG mais étendu aux animations, capable aussi de supporter la vidéo et l'encapsulation de flux sonores et textuels pour les sous-titres, à mon avis le meilleur substitut pour l'instant à GIF qui ne respecte pas la colorimétrie ni les ratios de rendu, et ne gère pas non plus les couches alpha), ou encore Ogg (un conteneur libre pouvant remplacer totalement MPEG pour l'empaquetage des flux dans divers formats, plus connu pour sa déclinaison audio Ogg/Vorbis) : est-ce cela le ".ogv" (Ogg/Vidéo ?), car jusqu'à présent je n'ai jamais rencontré cette extension à 3 lettres dans aucun contenu. Verdy p (d) 19 novembre 2010 à 13:08 (CET)

Pending changes et accessibilité[modifier | modifier le code]

Bonjour. L'extension Pending changes a été déployée sur en.wiki. En l'état actuel, elle est partiellement accessible. Il y a des alternatives textuelle sur les images (bien qu'une soit améliorable), le JavaScript se dégrade gracieusement et est à priori facile à rendre accessible au clavier. Le développeur responsable est aussi très présent et soucieux.

J'ai besoin de deux choses : une confirmation quand aux améliorations à apporter, et un conseil pour discuter avec un développeur front dans la résolution d'un problème.

Corrections à apporter[modifier | modifier le code]

Comme on peut le voir sur l'article Flight feather, on a le comportement suivant. D'abord une icône avec l'alternative textuelle suivante : « Changes must be reviewed before being displayed on this page. ». Très longue, c'est en fait plus clair pour un utilisateur de lecteur d'écran que pour un voyant. Mieux vaudrait avoir une information directement textuelle ou un lien ici, pour que ce soit clair pour les deux. Puis :

<div id="contentSub"><div id="mw-fr-revisiontag" class="flaggedrevs_short plainlinks noprint" onMouseOut="FlaggedRevs.onBoxMouseOut(event)">
<div class="flaggedrevs_short_basic"><img class="flaggedrevs-icon" src="/w/extensions/FlaggedRevs/client/img/doc-magnify.png"
alt="Changes must be reviewed before being displayed on this page." title="Changes must be reviewed before being displayed on this page." />
<img id="mw-fr-revisiontoggle" class="fr-toggle-arrow" src="/w/extensions/FlaggedRevs/client/img/arrow-down.png"
style="display:none;" onMouseOver="FlaggedRevs.showBoxDetails()" title="show/hide details" alt="(+)" /></div>

C'est les classiques onmouseover et onmouseout qui sont utilisés. Pour être accessibles, ils devraient être couplés à onfocus et onblur, selon SCR20: Using both keyboard and other device-specific functions. Peut-être que ces événements ne devraient pas être sur une image, mais plutôt sur un lien par exemple ? L'alternative textuelle « (+) » sur la flèche gagnerait à devenir « more », par exemple.

J'aimerais la confirmation qu'il n'y ait rien d'autre à corriger dans la version courante. Quoique récemment, dans la deuxième image, ce qui était style="display: inline;" est devenu style="display:none;". Je viens de comprendre à quoi ça sert (voir la section suivante), je ne pense pas que ça ait un impact ici. Dodoïste [ dring-dring ] 31 juillet 2010 à 04:48 (CEST)

Corriger l'alternative textuelle est indispensable.
Ajouter les événements clavier rendra l'icône utilisable au clavier, mais son rôle de lien ne sera toujours pas restitué à une aide technique, puisque c'est une image. Pour corriger autant que possible avec des moyens simples, il faudra en effet un véritable lien A. Ensuite, en fonction de la manière dont ce sera fait, il faudra sans doute aviser pour d'autres ajustements.
Au passage, plutôt qu'un script « traditionnel », il vaudrait mieux exploiter jQuery (puisqu'il est là pour ça).
Enfin, pour les autres soucis de rendu, ce sera sans doute plus difficile à « replâtrer» à ce stade, c'est à dire après coup : il est toujours plus facile de concevoir dès l'origine de manière non intrusive. Si les choses peuvent être revues en profondeur :
  • commencer par mettre en place un rendu sans javascript parfaitement propre (pas d'icônes, les choses à la place la plus simple, etc). Le siteSub (actuellement, le « From Wikimedia ») serait certainement un bon emplacement pour le « This is the latest accepted revision, accepted on 24 June 2010. »
  • ensuite, le js modifie le DOM pour adapter le code statique (créer les icônes uniquement quand elles sont nécessaires, déplacer dans l'arbre du document si nécessaire, appliquer la nouvelle mise en forme, etc.)
Le résultat ne sera pas parfait, mais déjà nettement plus facile à gérer. Pour aller plus loin, il faudrait d'une part passer à ARIA, et d'autre part recenser les différentes utilisations locales des headers de page (notice, liens d'accès direct, titre H1, icônes AdQ, atlas, onglets, etc.) pour revoir le code de base du template vector/monobook et ménager de quoi faire tout cela proprement : pour l'instant, c'est un peu trop foutoir, si j'ose dire Clin d'œil.
Cordialement, --Lgd (d) 31 juillet 2010 à 10:43 (CEST)

L'orientation que prend les développements[modifier | modifier le code]

La communauté et assez active dans les changements, dont la plupart vont dans le bon sens. Elle voit plusieurs défauts, dont :

  • Lorsque JavaScript est désactivé, le menu est déroulé par défaut. Et il obstrue alors souvent un élément proche, comme sur Houptsyte.
  • Lorsque la page est en train de charger, la boîte s'affiche déroulée, puis se ferme, ce qui est perçu comme une nuisance.
  • Un problème d'ergonomie dans l'interaction, dont la perte fréquente de focus lorsqu'on déroule le menu et qu'on déplace la souris dedans (classique pour ce type de menu déroulant, il suffit souvent d'élargir la zone qui active le menu). Et quelques soucis niveau design.

En réponse à cela, plusieurs corrections proposées :

  1. Kaldari, un développeur front depuis de nombreuses années (à ce qu'il dit), me dit



bugzilla:24314

bugzilla:23796

Question peut-être hors-sujet, je ne suis pas sûr qu'on parle de la même chose : c'est censé bouger, le menu de gauche, dans un avenir prévisible ? Pour l'instant c'est, disons, entièrement à revoir en fait (utilisation erronée de tabindex pour rendre très partiellement et mal accessible au clavier un élément qui ne l'est pas, etc). Cordialement, --Lgd (d) 2 septembre 2010 à 11:52 (CEST)
Oui. J'ai un tantinet zappé de finir cette section. ^^' Buuuh ! Je reprends, mais c'est pas fini. Les changements en attentes étaient censés bouger, et puis là je sais pas trop. La période de test étant achevée, un vote est en cours sur en.wiki pour décider de l'avenir de l'outil. Il est certain qu'il continuera à être utilisé. Mais certains demandes seront peut-être faites, et la spécification risque de bouger. Á voir.
Pour le menu du gauche, hors-sujet en effet mais c'est pas grave : mes collègues ayant fait des reports de bug inutilisables, rien n'a changé. Je pourrais techniquement les compléter, mais j'ai 24h dans une journée comme beaucoup de monde (tu connais trop bien cette sensation je pense). Bien à toi, Dodoïste [ dring-dring ] 2 septembre 2010 à 12:26 (CEST)

Titre de catégorie et langue[modifier | modifier le code]

Bonjour.Que faut-il faire en matière d'accessibilité quand on a un nom de catégorie utilisant un mot étranger comme Catégorie:Slasher ou Catégorie:Giallo ? Faut-il utiliser un modèle ? Merci Mérôme Jardin (d) 23 août 2010 à 21:47 (CEST)

Si il n'existe pas de terme francophone plus utilisé, ou que le terme étranger est entré dans les usages du langage français, le problème ne se pose pas. Car dans ce cas le terme étranger fait partie du langage français. Dodoïste [ dring-dring ] 23 août 2010 à 22:01 (CEST)
Hum... Ce n'est pas si évident, même si on pourrait formellement se réfugier derrière ce principe. L'exclusion des noms propres et des termes entrés dans les usages ne signifie pas qu'il ne « faut pas » indiquer de changement de langue, mais simplement que celui-ci n'est pas obligatoire. In fine, c'est le rendu prononcé à la française qui compte (est-il intelligible ou non ?) Même s'il est apparemment rare, le changement de langue serait pertinent dans plusieurs cas, comme Catégorie:Slasher, Catégorie:Sturmabteilung ou encore Catégorie:Noise rock.
D'autre part, le même problème se pose en fait pour toutes les pages de discussion d'articles ayant eux-mêmes un {{Langue du titre}}, même s'il serait préférable que ce soit géré en amont par mediawiki à partir des métadonnées de la page d'article. On rencontre aussi, mais rarement, le même problème dans d'autres espaces de nom, comme Portail:Shania Twain, Portail:Bollywood et du coup Projet:Bollywood, ou encore Aide:WikiLook.
Pour indiquer les changements de langue ne portant que sur le titre propre de la page mais pas sur le nom d'espace, il faudra donc un modèle dédié contenant {{DISPLAYTITLE:{{NAMESPACE}}:<span lang="{{{langue|{{{1|}}}}}}">{{PAGENAME}}</span>}}. Son usage n'étant potentiellement pas limité aux pages de catégories, il resterait à lui trouver un nom intuitif...
Cordialement, --Lgd (d) 24 août 2010 à 05:20 (CEST)

Encouragements[modifier | modifier le code]

une médaille en forme de puzzle marquée W

Bonjour, je tenais à remercier tous les participants de cet atelier pour le travail réalisé depuis sa création, matérialisé par cette avancée notable : Wikipédia:Articles de qualité/Accessibilité ! Bravo à toute l'équipe et merci au nom de nos lecteurs handicapés. --amicalement, Salix ( converser) 24 août 2010 à 13:15 (CEST)

Rappel à propos du modèle lang[modifier | modifier le code]

Bonjour, comme je ne retrouve plus l'info, pouvez-vous me rappeler la conduite à tenir pour tous les noms scientifiques en latin. Par exemple que faire pour une page comme Muridae bourrée de noms scientifiques ? Faut-il :

  1. ajouter à tout prix des {{lang|la}} partout, même dans les titres et les listes à puces de taxons ? (mais quel boulot !)
  2. utiliser lang seulement au sein du texte ?
  3. ajouter lang seulement quand la prononciation change du français ?
  4. inutile car les noms scientifiques sont considérés comme des termes techniques ?
  5. autre...

Comme ça je pourrais le préciser clairement une bonne fois pour toutes dans les projets concernés et les bonnes pratiques. --amicalement, Salix ( converser) 1 septembre 2010 à 23:23 (CEST)

Le souci est qu'il n'y a pas de démarche systématique à retenir. Disons que :
  • n'utiliser {{lang}} que dans le corps de l'article ou dans le corps du texte et non ici ou là dans le reste de la page : non, il ne faut en aucun cas retenir ce genre de règle. Un changement de langue est pertinent où qu'il soit ; il n'y a pas de notion éventuelle de première occurrence ou de contexte.
  • {{lang}} inutile car ceci ou cela : non plus. Les indications données par WCAG visent juste à ne pas créer d'obligation dans des cas problématiques ; elles ne constituent pas une interdiction de mentionner un changement de langue ni une dispense en cas de doute lié à la prononciation.
  • {{lang}} est potentiellement pertinent dès lors qu'une question de prononciation se pose (du point de vue accessibilité). Mais il est aussi pertinent à d'autres points de vue d'une manière plus systématique dès lors qu'il s'agit par exemple d'ajouter une métadonnée permettant d'indexer des contenus (toutes les entrées en latin ou latinisantes par exemple).
Pas de réponse simple, donc, désolé. Mais on peut retenir que la présence de ce modèle ne sera sans doute que très exceptionnellement problématique du point de vue pertinence (hors questions de conflits entre wikipédiens).
Pour ma part, je ne chercherais pas à « préciser clairement une bonne fois pour toutes », justement. Voyons déjà ce que les gens vont continuer à en faire et à en dire. Il y a une importante composante « faisabilité, pertinence au cas par cas et usages » dans les questions plus expertes posées par les changements de langue, et l'utilisation de ce modèle sur WP est un terrain d'observation particulièrement utile Clin d'œil. Cordialement, --Lgd (d) 2 septembre 2010 à 10:30 (CEST)
Je vais donc poser ma question de façon plus précise : en gros, est-ce que ça vaut le coup pour le projet biologie de s'emm... à ajouter d'urgence des {{lang}} partout, sur des milliers d'articles si on peut estimer que, dans un article comme Muridae, un biologiste amateur handicapé utilisant un lecteur d'écran peut le plus souvent parfaitement comprendre le latin lu "à la française" ? (ou encore : est-il suffisant de l'ajouter progressivement, à la faveur des hasards de contributions, ce qui peut prendre peut-être une dizaine d'années compte tenu du nombre d'articles concernés) --amicalement, Salix ( converser) 2 septembre 2010 à 13:46 (CEST)
En faire une urgence à laquelle avoir répondu dès demain, non. Une petite dizaine d'années est un délai tout à fait raisonnable en matière d'amélioration de wikipédia en général Mort de rire. Bref, pour l'instant, laisser faire les gens comme ils le sentent : ce n'est pas le plus décisif pour l'accessibilité d'un article mais le grand intérêt est que c'est réellement utile et que ça contribue fortement à amorcer une prise en compte de celle-ci par les contributeurs. Cordialement, --Lgd (d) 3 septembre 2010 à 10:03 (CEST)

Lien entre pages de l'atelier[modifier | modifier le code]

Hors-sujet: on peut faire un lien {{article détaillé|Wikipédia:Atelier accessibilité/Bonnes pratiques}} sur Wikipédia:Articles de qualité/Accessibilité, mais pas l'inverse! Ou alors indiquer qu'un résumé pour les rédacteurs est disponible sur Wikipédia:Articles de qualité/Accessibilité. ;-) Bien à toi, Dodoïste [ dring-dring ] 2 septembre 2010 à 00:09 (CEST)

Vous arrangez ça comme vous voulez mais en principe les rédacteurs d'AdQ ont des exigences plus strictes que le rédacteur lambda d'un article quelconque. Or l'organisation actuelle laisse penser le contraire avec un lien "Bonnes pratiques pour les rédacteurs" (en fait un page pour les AdQ) et un lien "Bonnes pratiques détaillées" (alors les AdQ font moins bien que les autres articles ? Ou on obtient le statut de "rédacteur" seulement quand on vise l'AdQ ? C'est en tous cas ce qu'on se demande...). Au minimum, le lien dans l'encadré de droite devrait être plus explicite : j'ai cherché, en vain, un lien vers cette page de critères d'accessibilité pour les AdQ et c'est pour cela que je l'avais mis en article détaillé --amicalement, Salix ( converser) 2 septembre 2010 à 07:27 (CEST)
si je peux me permettre : ça ne rentre pas dans les catégories wikipédiennes type article détaillé, rédacteurs ou contributeurs, etc.
La page Wikipédia:Articles de qualité/Accessibilité est uniquement une page de critères et non de bonnes pratiques, destinée à l'évaluation des AdQ, issue des Wikipédia:Atelier accessibilité/Bonnes pratiques proposées à tous les contributeurs. Les articles ne sont par défaut pas évalués du point de vue de l'accessibilité ; le sens de l'expérience actuelle est que les AdQ sont évalués du point de vue de l'accessibilité. Cordialement, --Lgd (d) 2 septembre 2010 à 09:48 (CEST)
Intéressant feedback Salix. Wikipédia:Articles de qualité/Accessibilité est à mon avis plus destiné au rédacteur et aux articles de manières générale. Car le contenu des bonnes pratiques est très varié : autant certains points sont relativement simples et abordables, autant certains sont très pointus, et d'autres concernent plus les modèles, Javascript, MediaWiki... La page pour les AdQ est donc une synthèse pour les rédacteurs d'articles. Du moins c'est comme ça que je le vois.
Oh, et j'ai corrigé l'intitulé du lien dans le menu. :-) Dodoïste [ dring-dring ] 2 septembre 2010 à 11:08 (CEST)
heu, non, bien que cela se défende. Disons plutôt qu'il faudrait, comme cela a déjà été évoqué quelques fois, revoir la présentation de Wikipédia:Atelier accessibilité/Bonnes pratiques pour trier par priorité plutôt que par thématiques (en revoyant si besoin le contenu et les priorités, voire la notion de priorité telle qu'elle est définie actuellement). Mais en tous cas, Wikipédia:Atelier accessibilité/Bonnes pratiques liste ce que les rédacteurs devraient faire. Il n'est pas inutile que ce soit à la fois très encourageant sur certains points et un large constat d'échec sur d'autres. Sur beaucoup de points, le problème n'est pas « que faut-il dire au contributeur aujourd'hui » mais plutôt « que faut-il modifier dans le CMS pour limiter le champ d'action du contributeur ou consolider ce qu'il fait quand c'est possible ».
Sinon, pour le menu, l'intitulé devrait être « critères... » Clin d'œil, mais ce n'est pas essentiel étant donné l'indifférence générale dans laquelle se trouvent les-dits critères (en gros, il sont ignorés à chaque AdQ sauf si quelqu'un s'en mêle et même encore souvent dans ce cas, c'est un peu ce que je craignais). On peut les laisser comme ça, ils ne font aucun mal en étant ignorés, et peut-être feront-ils du bien plus tard. --Lgd (d) 2 septembre 2010 à 11:44 (CEST)
Ton fatalisme t'honore Lgd mais c'est rarement avec de pieux conseils facultatifs qu'on fait avancer les choses ici. La page sur les AdQ devrait petit à petit être utilisée comme argument oposable lors d'un vote contre, comme cela a été le cas pour la vérifiabilité et les références (et pourtant c'était pas gagné d'avance quand on a créé le Projet:Sources Clin d'œil ! ). Àmha, un peu comme pour les tableaux, il faudrait 3 niveaux graduels d'approche : 1/ L'accessibilité essentielle, 2/ Les critères pour mériter l'AdQ, 3/ L'accessibilité pour les experts. Hélas, organiser ces pages est hors de ma portée... --amicalement, Salix ( converser) 2 septembre 2010 à 14:04 (CEST)
Nous sommes en réalité largement d'accord Clin d'œil.
  • Concernant les AdQ, c'est pour cela que je concluais en disant que ces critères feront peut-être du bien plus tard Clin d'œil.
  • Pour ta progression en 3 niveaux : elle rejoint ma suggestion de réorganiser les bonnes pratiques par priorité. Avec une correction de taille cependant : actuellement, les critères retenus pour les AdQ, dont le respect est loin d'être gagné, sont en fait le minimum le plus simple à la portée de tous les contributeurs (ton stade « accessibilité essentielle »).
L'idée n'est donc pas actuellement que tous les articles auraient un objectif d'accessibilité X et que les AdQ en auraient un X+. L'idée que les AdQ sont l'occasion de faire mieux connaître et adopter quelques critères d'accessibilité minimaux, choisis pour leur facilité.
Si l'on veut réorganiser les bonnes pratiques en termes de priorités plus exploitables par les contributeurs, ce sera donc plutôt :
  • priorité élevée: « ce qui est le plus facile à faire pour les types de contenus les plus courants » et qui est requis pour les AdQ (enfin requis, au moins sur le papier)
  • priorité moyenne : « ce qui est plus difficile à faire pour aller au-delà ou dans des cas de contenus plus particuliers »
  • priorité basse : « ce qu'on ne sait pas vraiment faire actuellement »
Un détail, important : il faut éviter de parler en termes de « niveaux » pour ces trois stades : il ne doit y avoir aucune confusion possible avec les niveaux d'accessibilité (A, AA et AAA) auxquels ne correspond pas la progression.
Cordialement, --Lgd (d) 3 septembre 2010 à 06:17 (CEST)
D’accord pour une réorganisation par priorités élevée, moyenne et basse. Cela me semble utile. Par ailleurs : toujours rien pour les alt dans les galeries ? Amclt, --Égoïté (d) 3 septembre 2010 à 08:06 (CEST)
D'accord aussi pour ce découpage, avec une nuance : je pense qu'il faut laisser les critère AdQ sur une page à part (d'ailleurs celle-ci n'est pas estampillée atelier") car ces critères peuvent évoluer et dépasser un jour (qui sait) le cadre des "priorités élevées". --amicalement, Salix ( converser) 3 septembre 2010 à 09:05 (CEST)

Wikipédia:Articles de qualité/Accessibilité[modifier | modifier le code]

Hello,
Vos avis sont les bienvenus sur ce qu'il conviendrait éventuellement de faire selon vous, ou au moins sur ce que cela vous inspire, dans le cas de Discussion:Football Club de Nantes/Article de qualité Clin d'œil.

Pour vous donner un résumé des épisodes précédents, deux interventions ont eu lieu pour l'instant :

  • Celle d'Égoïté qui, fort logiquement, constate que l'article ne répond pas aux nouveaux critères et qui, intelligemment, renvoie à cet atelier pour avoir de l'aide à ce propos.
  • La mienne, en complément, qui propose en complément le code corrigé des tableaux concernés.

Les deux interventions suscitent pour l'instant un désintérêt poli. Sachant en outre que cet article est représentatif de tout un pan très actif de Wikipédia (une partie des articles sportifs) faisant un usage abondant de codes particulièrement problématiques, comment voyez-vous cela ? Histoire de vous inspirer, je liste dans un désordre volontaire quelques possibilités qui me viennent à l'esprit, y compris ce qu'il ne faut surtout pas faire :

  • Ce n'est pas un souci, voyons à plus long terme ce qui ressortira d'une plus longue série de démarches AdQ
  • Retournons-y et insistons avec diplomatie
  • Allons-y franco et corrigeons dans l'article (au moins ce qui ne relève pas de la modification plus lourde d'un modèle, voir le détail dans la page de discussion AdQ)
  • Demandons-nous si le critère sur les tableaux est si réaliste que cela ?
  • Allons faire de la pédagogie après du projet sport ou foot
  • Allons faire de la pédagogie auprès des principaux contributeurs de l'article
  • Allons faire de la pédagogie auprès des piliers du système AdQ
  • Faisons de l'obstruction frontale en multipliant les votes "Bon article parce que les critères accessibilité ne sont pas respectés"
  • Améliorons le contenu de cet article avant d'aller parler de détails techniques
  • Allons contribuer plus généralement au projet sport

L'objet de ma question est surtout de savoir où les gens qui s'intéressent à ces questions d'accessibilité, à commencer par ceux qui ont souhaité ces critères pour AdQ, veulent aller (l'article en lui-même n'est pas la question majeure).

Cordialement, --Lgd (d) 3 septembre 2010 à 09:32 (CEST)

Bonjour, j'ai essayé l'émulation positive sur le vote et sur la pdd de l'article Nantes . Nous verrons bien si cela éveille des consciences... Tire la langue--amicalement, Salix ( converser) 3 septembre 2010 à 12:00 (CEST)
J'ai jeté un œil à quelques articles sur les clubs de foot, et ils adoptent tous la même disposition en tableaux imbriqués. L'idée « Allons faire de la pédagogie après du projet sport ou foot » me semble la plus adéquate. Le problème doit être résolu à la source. Ta version de l'article est plus propre, mais je leur accorde que c'est moins joliment présenté. Inutile donc d'insister sur cet AdQ sans avoir un bon compromis à proposer (de toutes façons, ils finiront par te répondre que Racing Club de Strasbourg est AdQ, alors pourquoi pas Nantes ?).
Rmq : dans le cas particulier des tableaux formatés en trois colonnes, pourrait-on explorer le code du côté des div flottantes (ou de la propriété inline ?) pour générer un alignement horizontal ? Tachymètre (me parler) 3 septembre 2010 à 13:16 (CEST)
Un coup de main par ici pour aider à améliorer Nantes ? --amicalement, Salix ( converser) 3 septembre 2010 à 18:04 (CEST)
Àmha, se réinterroger sur le critère des tableaux peut toujours être utile, mais je préfèrerais surtout que quelque chose soit fait pour cet article plutôt que de « laisser courir ». À force de laisser courir, on gardera éternellement le même problème dans ce type d’article. Peut-être serait-il opportun d’améliorer l’article avec tes propositions et de clairement expliquer, de façon pédagogique et diplomatique, la raison des changements. La modification de l’article, je pense, devrait créer un intérêt… réel (poli ou non, ça je ne sais, mais nous sommes en principe entre gens de bonne compagnie Sourire). Et cela éviterait l’argument pourquoi ici et pas Strasbourg ou d’autres : il faut bien commencer un jour, n’est-ce pas ? Clin d'œil Cela permettrait peut-être plus facilement d’engager une pédagogie, ensuite, sur les projets ? Et les piliers du système AdQ verraient aussi que quelque chose de constructif peut se passer. Ceci dit, je ne suis certainement pas encore d’attaque pour faire le travail, désolée. C’est donc un simple avis. Amclt, --Égoïté (d) 3 septembre 2010 à 18:26 (CEST)
Bonjour, contrairement à ce qu'y est dit précédemment, la question de l'accessibilité ne s'est pas vu opposé un désintérêt poli. Ayant initié la demande d'AdQ je souhaitais auparavant m'occuper des sections à renforcer car cela introduisait de nouveaux tableaux. Or pour régler la question de l'accessibilité il valait mieux que tous les tableaux soit déjà en place. Concernant le projet football je ne pense pas qu'il soit réfractaire à la question l'accessibilité. En revanche beaucoup de tableaux sont copiés d'un article à l'autre puis adapté à l'article en question. La question de l'accessibilité est ainsi pour moi très difficile à résoudre n'ayant aucune connaissance technique pour les tableaux. A contrario l'option d'opposition frontale que vous soulevez précédemment ne me semble pas être une bonne option à part frustrer des contributeurs attaché à obtenir un AdQ qu'il n'obtiendront pas pour une raison mineur (non pas que l'accessibilité soit un problème mineur, mais la résolution du problème purement technique reste mineur par rapport aux efforts à faire pour porter un article au niveau AdQ). Je pense qu'il serait plus intéressant d'entamer une collaboration avec le projet football et plus généralement le projet sport en travaillant sur des modèles de tableaux permettant de réintégrer la question de l'accessibilité au niveau des tableaux. Ainsi on pourrait envisager de travailler sur des modèles qui permettraient de mettre à jour les articles déjà labellisé et de mettre en place une habitude vertueuse de prise en compte de l 'accessibilité à l'origine de la création et du développement d'article. pour en revenir au FC Nantes j'ai essayé d'intégrer les tableaux proposé par d, malheureusement d'une part des tableaux ont étés modifiés depuis, le travail ne peut donc être transposé et d'autre part nouveaux tableaux sont apparus. Koniggratz (d) 14 septembre 2010 à 13:55 (CEST)
Avis très bienvenu, merci Sourire. Il y a en effet beaucoup à faire du coté des tableaux et des articles sportifs, mais c'est à faire très tranquillement et sans pression, au cas par cas, modèle après modèle, article après article, avant de dégager éventuellement des règles pour ce thème. En fait, c'était le sens de ma question dans cette section, mais je voulais savoir où les autres personnes intéressées souhaitaient éventuellement aller. Cordialement, --Lgd (d) 14 septembre 2010 à 14:01 (CEST)

Traduction en anglais de l'introduction à l'accessibilité[modifier | modifier le code]

Bonjour. Avec l'aide de Aelfgar pour la première section, j'ai fini la traduction « What is accessibility? ». Une relecture est bienvenue pour s'assurer que je n'aie pas commis d'erreur au niveau du fond. J'ai en effet fait plusieurs simplifications afin de cibler le contributeur (une page sera faite pour les dévs), retouché quelques exemples et tenté de faire des phrases courtes, simples et directes. Merci d'avance. :-)

D'ailleurs, je suis preneur de toutes bonnes volontés pour les traductions restantes. Bien à vous, Dodoïste [ dring-dring ] 7 septembre 2010 à 02:32 (CEST)

Juste deux remarques :
  • Voir l'article accessibilité du Web sur l'erreur majeure de définition de l'accessibilité au sens de la WAI. Je comprends bien le souhait de simplification derrière le changement de citation par rapport à la version française de Wikipédia:Atelier accessibilité/Qu'est-ce que c'est ? mais c'est une mauvaise idée. Une des conséquences classiques de cette présentation « universelle » de l'accessibilité est d'encourager et de conforter des démarches avec lesquelles tu as déjà eu des soucis récents sur la WP anglophone (mettre tout et n'importe quoi dans l'accessibilité au nom des utilisateurs en bas débit, des utilisateurs de vieux navigateurs, etc.) Clin d'œil.
  • J'enlèverais les deux exemples entre parenthèses concernant l'accès clavier (« because of events like onmousedown... unless an alternative like onkeydown is provided ») qui ne sont pas très représentatifs de l'aspect technique réellement rencontré (il s'agira par exemple plus souvent d'un onclick sur une image ou sur un titre de section, donc non universel).
Cordialement, --Lgd (d) 7 septembre 2010 à 05:00 (CEST)
C'est corrigé, et merci. Pour le deuxième point, je voulais mettre un exemple car je trouve cet phrase un peu vague comme ça. Mais je ferai une page dédiée pour les dévs de toute façon, donc c'est OK.
Au fait, tu m'avais dit que tu me mettrais en lien avec certains personnes pour l'audit, est-ce que c'est en cours ? D'ailleurs, si tu ne peux pas m'aider pour l'audit, peut-être le Litlok pourrait relire mon futur premier jet lui ? Bien à toi, Dodoïste [ dring-dring ] 7 septembre 2010 à 11:08 (CEST)

WCC[modifier | modifier le code]

Bonjour. Juste pour dire que vous devez vous attendre à du boulot dans les mois qui viennent. Quatre des jurés qui ont déjà exprimé leurs sensibilités sur Wikipédia:Wikiconcours/septembre 2010/Jury ont inscrit l'accessibilité parmi elles. Sourire Amclt, --Égoïté (d) 9 septembre 2010 à 17:41 (CEST)

Voilà qui fait plaisir à voir. Merci qui ? Merci Égoïté ! :-) Dodoïste [ dring-dring ] 9 septembre 2010 à 17:51 (CEST)
Bonjour,
Excellente nouvelle en effet :-) Mais je ferais une proposition à propos des alternatives textuelles des thumbs, pour améliorer ce que l'on fait jusqu'ici.
En effet, ces alternatives posent un problème redoutable. Tu (Égoïté) a montré dans plusieurs articles à la fois la possibilité mais aussi la difficulté de rédiger des descriptions d'images. Le WCC serait une bonne occasion d'aller plus loin, et de profiter de cette expérience pour améliorer la manière de faire afin de gagner à la fois en pertinence et surtout en facilité, donc en faisabilité. L'intérêt final, outre l'amélioration bien réelle de l'accessibilité des articles concernés, serait aussi de montrer la voie du côté des évolutions techniques de mediawiki concernant les thumbs (mais je n'entre pas dans les détails de ce côté).
Pour cela, je propose la chose suivante :
  • L'accent est mis plutôt sur la rédaction des légendes, qui doivent reproduire l'information principale apportée par l'image. De cette manière, on s'appuie sur un usage déjà bien en place. Il s'agit de veiller à ce que la légende, sans aller jusqu'à une description immédiate et intégrale de l'image, reflète systématiquement l'information clé qu'elle illustre (par exemple, en quoi telle image est-elle exemplaire de ce qui est dit dans le texte voisin ? Ou encore, quelle est la donnée majeure d'un graphique, par exemple une tendance dans une courbe ?).
  • Du coup, du côté des alt, on s'appuie sur une autre possibilité offerte par les normes d'accessibilité WCAG (voir G74: Providing a long description in text near the non-text content, with a reference to the location of the long description in the short description : l'alternative indique que c'est un lien permettant d'accéder à la page de l'image, et que la description de l'image suit immédiatement dans le texte. Cela donne en fait une alternative identique pour chaque image en thumb, qui pourrait être : « Consulter les données associées à cette image, dont la description suit ci-après. » C'est une forme d'alternative qui peut paraître inhabituelle par rapport à ce qui est pour l'instant recommandé dans les bonnes pratiques, mais qui repose sur une approche nouvelle proposée par WCAG2, qu'il serait tout à fait pertinent AMHA d'adopter à présent qu'elle est officielle.
Enfin, il serait sans doute utile de fournir rapidement aux contributeurs du WCC et au jury une page dédiée expliquant les divers critères retenus, afin de donner des exemples concrets à propos de cette question des alternatives (je vais tâcher moyen de...)
Cordialement, --Lgd (d) 11 septembre 2010 à 06:50 (CEST)
Pour la page d'aide, un premier jet à améliorer considérablement (mais il faut rester très bref) : Wikipédia:Atelier accessibilité/Aide accessibilité pour le Wikiconcours. Cordialement, --Lgd (d) 11 septembre 2010 à 07:15 (CEST)
@Dodoïste, spécial training accessibilité : il y a une faille dans cette méthode, qui nécessite un changement du code HTML actuellement produit par mediawiki pour les thumb. Votre mission, si vous l'acceptez, sera de la trouver Clin d'œil Cordialement, --Lgd (d) 11 septembre 2010 à 07:34 (CEST)
Bonjour. J’ai ajouté deux liens dans ton exemple pour démontrer que la wikification est possible car il y a des « ayatollahs » de la wikification des légendes Clin d'œil. Perso, je préfère l’ancien système qui permet des descriptions plus longues et plus précises, mais ceci sera effectivement plus à la portée des rédacteurs. Dès que vous êtes prêts, faites-le savoir haut et fort sur les pages du WCC : cela renforcera l’impact de l’annonce des sensibilités. Moi, je serai quasiment absente pendant 2-3 jours pour cause de Journées du Patrimoine. Amitiés, --Égoïté (d) 11 septembre 2010 à 07:54 (CEST) P.S. Ce serait utile de créer Alternative textuelle et Légende d’image même en ébauche. Voir Légende (homonymie).
Bien vu pour la wikification.
Je suis un peu bousculé aussi, mais je comptais aborder aussi un autre point, spécialement avec toi. Les descriptions détaillées conservent tout leur intérêt, mais plutôt sur un autre support : la page de l'image, sur fr ou sur commons selon les cas. C'est une piste complémentaire très importante. Cordialement, --Lgd (d) 11 septembre 2010 à 08:01 (CEST)
Ouiiiii. \o/ Tu m'ôtes les mots de la bouche. Il serait plus pertinent de signaler « Consulter les données de cette image et sa description longue, la légende suit ci-après. »
Ne jamais sous-estimer l'envie des rédacteurs de Wikipédia à écrire du texte. Mort de rire Les descriptions textuelles d'images sont pour l'instant sous-utilisées sur Wikipédia, alors que cela représente un intérêt encyclopédique certain pour tous les utilisateurs. Comparons par exemple la légende sur Photographie#Invention, et la légende sur File:View from the Window at Le Gras, Joseph Nicéphore Niépce, uncompressed UMN source.png. Elles sont complémentaires. Des détails sont données sur le temps de pause et l'éclairement du soleil, par exemple, qui sont utiles à tout le monde. Cela alourdirait trop de faire une légende complète sur l'article, en revanche on peut détailler sur la page de description de l'image.
Lgd : J'adoore ce genre de petits défis. :-) Et puis c'est nécessaire si je veux faire la demande aux dévs. :-) Le problème est que la légende produite par MediaWiki, qui suit l'image, n'est pas dans un paragraphe p. J'ai gagné ? Hihi ! ^_^ Dodoïste [ dring-dring ] 11 septembre 2010 à 09:10 (CEST)
Arf, mon small c'était plus un gag qu'autre chose, le problème étant bien réel mais le détail passablement complexe. Mais c'est aussi bien si tu relèves le défi Clin d'œil. Donc, il y a éventuellement un p impliqué en effet, mais pourquoi précisément, avec quelle correction du code des thumb exactement, et en rapport avec quel(le) critère/technique WCAG Mort de rire ? --Lgd (d) 11 septembre 2010 à 10:19 (CEST)
Sinon, à propos de cette question de localisation des descriptions d'images : il faut revenir à l'idée clé qu'une image a d'une part une description « factuelle » potentielle, indépendante de ses usages (notamment à des fins d'indexation par les moteurs de recherche), et d'autre part un sens d'usage dans un contexte donné. L'une et l'autre peuvent être très ou totalement différent et ne peuvent en tous cas pas être exigés de la même manière des mêmes contributeurs. La légende est le meilleur moyen de gérer le sens dans le contexte de l'article, puisque sa rédaction est un besoin existant et admis par ailleurs. La page de l'image est le meilleur moyen de tirer en effet parti du goût des wikipédiens pour les tâches fastidieuses d'écriture Clin d'œil. Cordialement, --Lgd (d) 11 septembre 2010 à 10:40 (CEST)
Tu as évidemment raison, je pense, quant aux deux sens de l’image. Mais je me demande à quelle page de l’image tu penses : celle de WP et/ou celle de Commons ? Et je me demande aussi si sur Commons seraient bien vues les descriptions de l’image telles que je les ai rédigées, par exemple, dans mes derniers articles importants. Lorsqu’il y a légende dans l’image, la transcription est normale àmah et ne doit pas poser de problème ; idem lorsqu’il s’agit d’un texte manuscrit difficile à lire (exemple) mais pour les images « en général », les tableaux, etc. ? Comment serait admise la part de subjectivité inhérente à la description ? Amitiés, --Égoïté (d) 12 septembre 2010 à 09:13 (CEST)
Question due au fait que je ne peux tester sur un navigateur test : comment la personne handicapée aura-t-elle accès à la page de données de l’image quand elle lira (choix du texte à préciser) ? :
alt=Consulter les données associées à cette image, dont la description suit ci-après proposé par Ldg
alt=Consulter les données de cette image et sa description longue, la légende suit ci-après. proposé par Dodoïste
alt=Consulter les données et la description de cette image dont la légende suit ci-après. proposé par Égoïté
Amitiés, --Égoïté (d) 12 septembre 2010 à 09:27 (CEST)
Chaque image en thumb est un lien vers la page de données de l'image, ces formulations sont donc (grosso modo) restituées comme si on avait écrit :
(Il faut que je regarde à nouveau si une capture vidéo/audio de la consultation dans NVDA serait parlante. On ne peut hélas pas illustrer ce genre d'explications avec une capture de la consultation de la page dans Jaws, pour des questions de licence, alors que ce serait le plus pédagogique).
Sinon, je préfère la formulation que j'ai proposé, même si elle est améliorable : indiquer que la page cible contiendrait une description de l'image est à la fois faux (pour l'instant, elle n'y est quasiment jamais) et peu clair (dois-je suivre le lien ou simplement consulter la légende pour accéder à l'information ?)
Cordialement, --Lgd (d) 12 septembre 2010 à 11:02 (CEST)
Exemple d’illustration donnant une description factuelle.
Bien pigé. Dans un but pédagogique, j’ai légèrement complété la page d’aide WCC (j’espère que vous serez d’accord avec mon texte) et l’ai signalée sur Discussion Wikipédia:Wikiconcours/septembre 2010. Amclt, --Égoïté (d) 14 septembre 2010 à 16:26 (CEST)
Bon complément. Mais je n'ai pas compris le rôle de ton image reproduite ci-contre ([[Fichier:View from the Window at Le Gras, Joseph Nicéphore Niépce, uncompressed UMN source.png|thumb|Exemple d’illustration donnant une description factuelle.]]) ?
Sinon, mais on va rebondir sur un autre sujet, il faut mieux expliquer que les contributeurs peuvent renseigner un champ « Description » sur Commons.
On tâtonne, c'est normal, ce n'est pas évident du tout. Cordialement, --Lgd (d) 14 septembre 2010 à 17:28 (CEST)
Oui tu as raison, il fallait indiquer Commons ! (cela me paraissait tellement évident (Smiley Gêné)). Pour l’image placée, cela me semblait mieux expliciter la différence entre description factuelle et légende. Ceci dit, aurais-tu une idée du pourcentage de personnes qui utilisent un navigateur texte ? (question de mon fils) et y aurait-il un autre système que le alt ? (question perso car le site des musées en Wallonie propose une partie plus «accessible » mais… rien en alt pour la galerie d’images…) Amclt, --Égoïté (d) 14 septembre 2010 à 18:34 (CEST)
  1. Les stats : c'est une question classique de tout bon étudiant en qualité Web un peu réactif (ton fils envisage de s'inscrire un jour à une formation ? Je lui fais une recommandation de ce pas, ça me changera des ânes que je subis chaque année Mort de rire), mais... il n'y a aucun chiffre possible des gens qui utilisent des navigateurs textes ou plutôt des aides techniques (lecteurs d'écran, loupes, etc) : ces outils sont en effet totalement transparents pour les logiciels de stats Web qui scrutent la fréquentation des sites (un lecteur d'écran est par exemple « caché » derrière FF ou Internet Explorer). Tout ce que l'on peut indiquer, ce sont les chiffres de la population handicapée officiellement recensée, donc seulement un nombre minimal d'usagers potentiels, sachant que l'intérêt du Web est énorme en terme de gestion sociale du handicap et sachant que le handicap dépasse largement les recensements officiels concernés avec par exemple les seniors. Donc quelques millions de personnes en Europe, disons (je ne donne volontairement pas de chiffres, mais ils sont dans WP notamment).
  2. Il n'y a pas d'autres système que le alt pour les images. Attention: légers excès de langage parfois ci-après Ce que fait le site des musées en Wallonie est un vieil exemple d'une abomination qu'il ne faut jamais commettre et qu'on a beaucoup pratiqué autrefois par ignorance, c'est à dire : « une version texte que je fais pour les aveugles, qui est un ghetto pour les handicapés et qui me permet de me dédouaner de manière politiquement correcte mais stupide du point de vue d'un entrepreneur. Elle n'est pas à jour côté informations, elle me coûte des sous pour rien, elle est destinée en principe aux seuls aveugles sauf qu'ils ne sont pas le seul public handicapé et de loin, et à vrai dire si jamais le cadavre bouge encore : elle n'est même pas accessible aux sus-dits aveugles parce qu'elle est mal faite. Bref, j'ai tout faux tant en termes de communication que de gestion ou plus essentiellement de handicap ».
    C'est ce que l'on appelle une « version texte » qui généralement ne l'est pas (celle-ci a des images... sans alt, youpie !), qui n'est jamais mise à jour en temps acceptable par rapport à la version pour « les gens normaux », et qui, surtout, ne répond absolument pas aux besoins des personnes concernées : celles-ci sont des internautes comme les autres, qui s'assument comme des grands en sachant qu'ils doivent utiliser certains logiciels appropriés de leur côté, mais qui détestent qu'on les enferme dans un « sous-site ». J'ai déjà vu des réactions assez éruptives d'internautes handicapés lors de formations, sur ce point. Et surtout, j'en vois une autre, récurrente : « que tout ne nous soit pas accessible dans un site, OK, surtout si le site propose des services et des formes de contenu innovantes. Mais on demande juste que le minimum à la portée de n'importe quel site soit au moins fait et qu'on permette de nous débrouiller avec un site intelligemment fait ». Voilà voilà, comme tu le vois, c'est sensible mais très intéressant... Mort de rire
    Sinon, à vrai dire, je travaille en tant que prestataire avec les organismes belges responsables des questions d'accessibilité Web. Ils sortent d'une période de difficulté prolongée, mais ils avancent maintenant très sûrement et c'est un des terrains européens qui va être intéressants à suivre dans les prochaines années.
Cordialement, --Lgd (d) 14 septembre 2010 à 19:41 (CEST)
Je transmets à mon fils Clin d'œil. Pour le 2/ c’est ce que je pensais. Merci
Pour le conflit d’éd. ne t’inquiète pas : je disais juste à Stef que les critères AdQ n’incluaient pas les alt et qu’on y allait pas à pas. Amitiés, --Égoïté (d) 14 septembre 2010 à 23:36 (CEST)

Pourquoi Wikipédia:Atelier accessibilité/Aide accessibilité pour le Wikiconcours ne mentionne quasiment que les images ? Ne faudrait-il pas parler des tableaux, de {{lang}}, etc. ? — Steƒ ๏̯͡๏ 14 septembre 2010 à 18:35 (CEST)

Heu, je ne répondrai pas à tout le monde en même temps (surtout que c'est plutôt l'heure où je plie les gaules, désactive sagement toute connexion et donc je serais plus plutôt là demain matin, mais cette page pour le WCC est supposée :
  • renvoyer à la page des critères AdQ pour les tableaux, lang etc.
  • expliciter juste le critère supplémentaire, qui est celui des images
Il se peut tout à fait que cela ne soit pas clair pour les gens, et qu'une page donnant plutôt tout d'un coup soit plus avisée ? On change ? Avis bienvenus.
Cordialement, --Lgd (d) 14 septembre 2010 à 19:41 (CEST)

Avignon[modifier | modifier le code]

Bonjour à tous

Le message conjoint d'Égoïté et de Lgd sur la PDD du WCC m'a fait penser que la page Avignon qui doit être prochainement présentée à la labellisation aurait besoin d'un sérieux controle technique de la part de l'Atelier. Est-ce possible avant le déchaînement prévu de ces prochaines semaines ? Très amicalement --JPS68 (d) 14 septembre 2010 à 18:14 (CEST)

Vous semblez vivre dans un univers assez stressant, avec le WCC ou les AdQ, non Mort de rire ? Ici, on est très Zen, vu qu'on a des objectifs à très long terme. Mais bon, on y va de ce pas, à Avignon Clin d'œil. Cordialement, --Lgd (d) 14 septembre 2010 à 18:22 (CEST)
Heu... C'est bien un nombre de jours, le nombre de + et de - dans le tableau « Le mistral », seconde ligne ? --Lgd (d) 14 septembre 2010 à 18:41 (CEST)
C'est un peu moins stressant que la PDD Boite de conserve, quand même. Bienvenu au royaume du mistral. J'ai utilisé pour ce tableau les données du centre météo cité. Ce n'est pas un nombre de jours, c'est une quantification, àmha, ++++ signifiant 4 fois plus que la norme. JPS68 (d) 14 septembre 2010 à 18:59 (CEST)
Ok, j'ai un peu de retard dans l'intervention prévue (bcp de boulot IRL aujourd'hui), mais je vais passer corriger les tableaux, qui sont le principal point problématique. Cordialement, --Lgd (d) 15 septembre 2010 à 12:43 (CEST)
Merci Clin d'œil --JPS68 (d) 15 septembre 2010 à 15:18 (CEST)
Je suis passé corriger les tableaux. :-) Lgd, tu peux vérifier que ce soit bon ? En particulier pour Avignon#Climat, j'ai introduit des abréviations sur les en-têtes de lignes assez longs du tableau « Vitesse des vents du Mistral ». Je ne sais pas si c'est une bonne idée en fait, notamment parce que je doute que cela soit bien compris des rédacteurs. Dodoïste [ dring-dring ] 15 septembre 2010 à 21:31 (CEST)
Merci beaucoup, Dodoïste Sourire.
Pour les abbr d'en-têtes, il y a en effet le risque de grosses confusions dans les usages. Je suis incertain... Cordialement, --Lgd (d) 16 septembre 2010 à 06:52 (CEST)
 :-)
Pour l'en-tête de colonne vide, c'est une question que je me suis posée plusieurs fois. J'avais été induit en erreur par les insructions sur Aide:Tableaux que je viens de corriger.
Pour les abbr d'en-têtes, on fait quoi ? On observe ou on retire ? Note que la deuxième solution ne me pose pas de problème. Et surtout que ne sais pas quelle est le degré d'importance de ces abbr d'en-têtes pour les utilisateurs. Est-ce que c'est plutôt un bonus, ou est-ce que c'est vraiment utile pour les lecteurs d'écrans ? Bien à toi, Dodoïste [ dring-dring ] 16 septembre 2010 à 22:29 (CEST)

Le respect de la syntaxe wiki ne devrait-il pas être la base afin de permettre l'accessibilité dans wikipédia ? Si c'est le cas, il faut remplacer les balises HTML (essentiellement des H4) de cette page par leur équivalent wiki. D'après les ATAG, je pense que c'est nécessaire, cela permet de gérer la conformité au HTML au niveau du moteur de wikimedia et non au niveau des pages : http://www.w3.org/TR/ATAG10-TECHS/imp2#check-ensure-published-DTD Meszigues (d) 24 novembre 2010 à 01:27 (CET)

Bonjour,
En fait, il ne s'agit pas de HTML, mais de syntaxe wiki qui prend l'apparence de HTML : ces pseudos balises sont traitées par le parseur de mediawiki au même titre que les <ref>, <math>, <timeline> etc. tout comme la « syntaxe wiki classique », c'est à dire les == et autres (autrement dit, la conformité est gérée, pour autant que mediawiki ou plus exactement Tidy puissent le garantir).
Cela dit, un usage bien ancré dans Wikipédia est de proscrire les syntaxe wiki « HTML » quand une syntaxe wiki « classique » existe, pour ne pas dérouter les contributeurs. Cependant, le choix du HTML s'explique dans ce cas par le souhait d'une mise en forme identique à un simple texte mis en gras tout en conservant le niveau de titrage effectivement requis. Ce n'est pas dans les usages, mais cela n'a rien de dommageable en tous cas du point de vue de l'accessibilité.
Cordialement, --Lgd (d) 24 novembre 2010 à 05:19 (CET)
Bonsoir,
Il existe le projet Projet:Correction syntaxique qui repère les balises HTML (Voir erreur 49).
Ne serait-il pas préférable d'avoir pour règle que la syntaxe doit être préférée au "pseudo" balisage HTML ?
Dans le cas où la "pseudo" balise HTML serait nécessaire pour l'accessibilité, un attribut signalant cet usage serait le bienvenu (c'est possible puisse d'après ce que vous venez d'écrire ce n'est pas du HTML et wikimédia a une grande liberté sur les attributs, par exemple un attribut "commentaire" ou "accessibilité"). Cet attribut éviterait certaines corrections syntaxiques systématiques et les incompréhensions qui s'en suivraient (le travail sur la syntaxe ou l'accessibilité étant lourd, il est désagréable de le voir modifié sans précaution).
En espérant que cela puisse aider.
Meszigues (d) 24 novembre 2010 à 21:26 (CET)
Effectivement ce titre est détecté par le projet correction syntaxique pour l'erreur 49 depuis quelques temps (HTML pour un titre de section). Même si ça n'en est pas vraiment, je n'ai pas vraiment envie de marquer l’article comme faux-positif car cela va devenir rapidement ingérable si d'autres apparaissent par la suite. Il faudrait pouvoir modifier la détection, que ce ne soit pas détecté comme une erreur, mais Sk (l'auteur du projet, du script de détection sur le toolserver) ne répond plus aux demandes depuis un moment. Comme certains l'ont fait remarqué, il est vraiment recommandable de simplifier la vie des utilisateurs et pour cela l’utilisation de la syntaxe wiki semble admise de tous, pour ne pas dire acquise. Ici Avignon est le seul article à utiliser cette mise en forme et doit se justifier à chaque sous-titre d’un « <!--Voir [[Discussion Wikipédia:Atelier accessibilité]] à propos de cette syntaxe inhabituelle --> » pour la légitimer. Je ne vois pas vraiment ce qu’apporte le fait d'avoir le titre en gras à une taille 1.0em plutôt qu'« un poil plus grande » avec deux « ==== ». De fait je pense qu'on ne devrait pas garder cela sur l'article ni l’exemple de la page bonnes pratiques. Si l'intérêt est uniquement esthétique il est futile (les goûts et les couleurs…). A2 (d) 30 novembre 2010 à 14:51 (CET)
C'est à voir avec les principaux contributeurs de l'article. Cordialement, --Lgd (d) 4 décembre 2010 à 09:01 (CET)

Modèle:Infobox Chef d'État - correction[modifier | modifier le code]

Bonjour. J'ai récemment tenté d'enlever cette malédiction de "hiddenstructure" de Modèle:Infobox Chef d'État. Vu que l'infobox est très longue, et que tout devait être fait à la main, j'ai fait petites quelques erreurs qui m'ont valu cris et maux de têtes à dénicher. Mais c'est corrigé.

Contre toute attente, il reste un problème que je ne m'explique pas. Comme on le voit sur le brouillon de la nouvelle version, MediaWiki génère un énorme espace vide fait d'une quantité de « <p><br /></p> ».

Je viens de faire quelques tests, et c'est bien ce que je pensais : c'est les retours à la ligne entre les fins de balises #if et le début des balises #if suivantes.

}}
{{#if:

Et c'est très étrange car sur les autres infobox le problème ne se pose pas. Ce problème est facile à contourner (en utilisant des <!-- -->) et je suis en train de le corriger. Mais si quelqu'un trouve une méthode plus simple, ou peut m'expliquer pourquoi le problème ne se pose pas sur Modèle:Infobox Politicien qui a une syntaxe similaire, je suis preneur. Dodoïste [ dring-dring ] 17 septembre 2010 à 00:15 (CEST)

C'est corrigé, cette infobox est enfin un peu plus propre. Elle propose encore pléthore de paramètres inutiles et inutilisés, mais le principal est fait. J'ai gagné quelque chose ? Mort de rire Hormis la douce nuit de repos que je vais m'offrir ? Dodoïste [ dring-dring ] 17 septembre 2010 à 01:16 (CEST)
Appel à volontaires : il reste de nombreuses infobox à corriger, voir la liste de travail sur HiddenStructure. Dodoïste [ dring-dring ] 17 septembre 2010 à 01:29 (CEST)
Désolé, j'ai dû annuler pour l'instant : la version corrigée était bugguée (disparition d'en-têtes de ligne tel que « Parti politique » et « Président(s) du Conseil » par exemple). Tu n'as pas choisi la plus facile, très loin de là !
Personnellement, j'euthanasierais volontiers cette usine à gaz immaniable, mais bon... On va plutôt tâcher de venir à bout des bugs Mort de rire Cordialement, --Lgd (d) 17 septembre 2010 à 07:24 (CEST)
J'ai choisi cette infobox en connaissance de cause. Cet aprèm je ferai une sieste, rechargerai mes batteries et m'attaquerai à d'autres infobox plus simples. J'en ai ras la tartiflette des chefs d'états.
Dans le genre plus simple, je viens de corriger Modèle:Infobox Col‎. Dodoïste [ dring-dring ] 17 septembre 2010 à 17:11 (CEST)

Si je vous em...[modifier | modifier le code]

dites-le ! Comme je ne suis pas en état de le faire, pourriez-vous contacter Ambre suite au dernier commentaire de Wikipédia:Le Bistro/21 septembre 2010#Bonjour l'automne ? Cette contributrice parait pleine de bonne volonté mais pourrait être utilement aidée je pense. Si oui, merci ! Si non, tant pis… Amitiés, --Égoïté (d) 21 septembre 2010 à 23:19 (CEST)

Fait, en ce qui concerne la question d'accessibilité. Pour le reste, elle a besoin d'aide oui. Mais il faut savoir qu'elle est très gourmande en aide, à deux parrains on avait de la peine à suivre. ;-) Bien à toi, Dodoïste [ dring-dring ] 21 septembre 2010 à 23:39 (CEST)

Demande de relecture d'un tutoriel pour des tableaux accessibles[modifier | modifier le code]

Bonjour. Un de mes plus gros travaux sur la Wikipédia anglophone ces derniers temps porte sur l'accessibilité des tableaux. Suite à une discussion qui fut chaude par moments, un compromis a été trouvé. Il s'agit donc d'améliorer les bonnes pratiques actuelles Wikipedia:Manual of Style (accessibility)#Data tables, et surtout de retirer les erreurs et la recommandation innapliquable sur les cellules fusionnées.

Un résumé simple, destiné à la plupart des lecteurs, figure sur le Manual of Style draft. Il remplacera la recommandation susmentionnée.

Le gros étant le tutoriel détaillé sur Manual of Style draft/Data tables tutorial. Il est destiné aux curieux. Mais aussi aux membres de projets divers, intéressés par la question, qui veulent améliorer leurs guides de style internes. En.wiki est à ce niveau beaucoup plus développé et mieux organisé, on trouve par exemple des conventions de style détaillées pour le projet discographies.

Ce tutoriel long est surtout destiné aux membres du projet accessibilité. Au vu du nombre de membres et de la masse de boulot, il est impensable qu'une personne (moi par exemple) doive suivre toutes les discussions clés pour s'assurer que tout va bien. Il faut donc que les membres aient une référence fiable et complète en main, et puissent être autonomes. Je vais tester la démarche, avec pas mal de suivi au départ. On verra ce que ça donne. À priori je le sens bien.

Mais ce tutoriel est en bonne partie destiné à résoudre les manques de priorités du projet. Deux recommandations peu applicables (colspan/rowspan et abbr des en-têtes de tableaux) sont donc reléguées en bas de la page, et passent de "recommandations prioritaires à appliquer" à "recommandations bonus, pas trop applicables".

Je me suis basé sur les sources que j'ai trouvées à ce sujet. Mais pour certains points, ce sont de simples déductions, qui semblent logiques et découler de critères plus généraux. Ce qui implique qu'il est très possible que des erreurs soient présentes dans le fond.

Le relecture par un expert est la seule chose qu'il manque à ce tuto. Il a déjà le soutien des membres clés du projet accessibilité, donc il sera déployé juste après que les dernières corrections soient faites. Merci d'avance ! Dodoïste [ dring-dring ] 25 septembre 2010 à 08:41 (CEST)

Relecture d'une première moitié (je ne relève que le pas bon, mais c'est plein de bon aussi, hein Clin d'œil) :
  1. Section Overview of basics > "They can have the headers read first" : non. l'identification des en-têtes ne conduit pas, dans la lecture linéaire du tableau, à ce que les en-têtes soient lus en premier. Elle permet que les en-têtes soient lus quand la demande en est faite ou par défaut lors du parcours en mode tableau. A supprimer.
  2. Section Correct table captions > "A table caption is required unless it is directly preceded by a short paragraph or a section header playing the same role" : en fait non, et il va falloir actualiser les BP de fr.wp sur ce point. Le CAPTION est toujours requis.
  3. Section Meaningful tree structure of headers (toute la section) revient à dire qu'il faut scinder les tableaux du mauvais exemple en plusieurs tableaux comme dans le bon exemple. Pourquoi ne pas le dire plus directement ? Par ailleurs, le mauvais exemple peut être rendu accessible sans passer par là, via headers et id, mais la démarche est effectivement trop complexe pour être documentée et utilisée courament sur WP. Là, le choix du message à faire passer est délicat et la question reste ouverte.
  4. Section Avoiding column headers in the middle of the table est une répétition plus claire de Meaningful tree structure of headers. A fusionner.
  5. Section Making relevant row headers : non, le "bad example" répondra aux exigences WCAG avec un simple ajout de scope col sur les en-têtes de colonnes. Enculage de mouches typiquement anglo-saxon (si je peux me permettre) à éviter. Le but du jeu n'est pas de dire comment faire un bon tableau à la fois ergonomique et accessible. Le but du jeu est de leur dire comment rendre accessibles leurs tableaux, que ce soient des horreurs ou pas. Ou alors, changement complet de démarche et l'accessibilité se dilue dans des bonnes pratiques éditoriales au point de devenir transparente, ce qui est également pertinent. Mais dans ce cas, il faut prendre un parti et choisir une démarche : manuel d'accessibilité (comme actuellement) ou manuel du contributeur.
  6. Section Avoid merging cells not meant to duplicate the same information : idem.
  7. Section Avoiding visual order in data tables : l'ordre linéaire du "bad example" est correct et accessible. C'est un tableau de mise en forme dont il suffit de supprimer le TH. Il est inutile de le transformer en tableau de données.
<humour> Le pseudo-perfectionisme anglo-saxon qui coupe les cheveux en quatre au-delà de WCAG sans aucun sens des priorités est proprement terrifiant, mais il faut en effet faire avec Clin d'œil </humour>. Plus sérieusement, ces surcharges à tendance ergonomique au-delà de l'accessibilité expliquent assez bien certains déficits de prise en compte de l'accessibilité. Il faut vraiment commencer par faire passer les bases, ce qui veut dire faire admettre aux participants à ce projet qu'il font une chose frustrante : chercher le faisable et non l'idéal.
Cordialement, --Lgd (d) 25 septembre 2010 à 09:21 (CEST)
Merci pour cette relecture. :-)
  1. Fait Je savais cette partie imprécise, mais je ne sais pas trop comment l'améliorer. Il ne convient surtout pas de la supprimer : les rédacteurs ont aussi besoin de savoir à quoi servent les changements qu'ils fonts. J'ai reformulé ce passage, en le rendant plus proche de la source W3C.
  2. Fait Fait sur fr et en.
  3. Fait J'ai retiré cette section au profit de la suivante. Cette section n'est pas cohérente car je n'ai pas trouvé l'exemple auquel je pensais. Elle sera bien si je trouve le bon exemple au sein de WP, mais en attendant je la retire. Concernant les ID et headers, j'ai fait le choix de ne pas en parler car c'est trop complexe et qu'on peut faire sans. Dans le même ordre d'idée, j'ai parlé de l'attribut summary en fin de page parce qu'un membre du projet en avais fait mauvais usage et parce qu'il avait l'air d'y tenir. Mais sinon, j'aurais évité de parler de cette technique trop complexe.
  4. Fait Fait, au moins temporairement. Ne fera plus doublon lorsque j'aurai trouvé un bon exemple pour le n°3.
  5. Oui, il me semble que l'ergonomie des en-têtes est un point important à traiter. D'autant plus que c'est également abordé par WebAIM. Il faut en effet préciser que c'est de l'ergonomie, d'une manière ou d'une autre. Je suis preneur de suggestions.
  6. Là, je comprends pas. Il me semblait qu'il y avait bien une erreur sémantique, donc une erreur de fond, dans cet exemple. Ou tu veux dire que c'est un détail ? Si c'est cela je peux déplacer la section parmi les bonus ?
  7. J'y avais songé. Au besoin l'exemple pourrait être déplacé dans les bonnes pratiques pour les tableaux de mise en forme. Mais le fait d'en faire un tableau de donnée propre n'aiderait-il pas l'utilisateur à mettre en relation l'image et sa légende ? Oui, encore de l'ergonomie, mais c'est important aussi non ?
C'est intéressant ce que tu me dis à propos de la démarche anglo-saxonne. RexxS m'a justement dit, après qu'on ait trouvé un compromis : « While I appreciate the rigour WCAG brings to that area, my background is in systems analysis and web design, and my instinct is to emphasise the problems for users who only have older technology, limited bandwidth, etc. They don't have an organisation like WCAG to advocate for their interests, so I often need to present my own research, rather than being able to point to a source. »
Ce qui ne l'a pas empêché de comprendre finalement assez rapidement : « Nevertheless, I'm convinced by your arguments that "perfection is the enemy of good enough", and I'll happily go along with making improvements incrementally. It will be a long time before more than a small proportion of Wikipedians acquire anything more than a basic understanding of the issues here, and I accept that we need to "sell" these ideas slowly enough that we don't provoke rejection. »
Au besoin, je peux déplacer les considérations d'ergonomie dans les critères en bonus. Ou dans une recommandation du projet utilisabilité que je créerai pour l'occasion. Qu'en dis-tu ? Bien à toi, Dodoïste [ dring-dring ] 26 septembre 2010 à 02:37 (CEST)
  1. A déplacer dans une recommandation distincte, plutôt
  2. Non, il n'y a pas d'erreur « sémantique ». Les cellules vides sont intellectuellement plus satisfaisantes, mais ne font pas une différence notable.
  3. Remplacer un tableau de mise en forme transparent pour l'utilisateur par un tableau de données, même bien fait, qui ne l'est pas et qui invite à utiliser un mode de consultation particulier (non linéaire) : cela ne simplifie pas les choses pour l'utilisateur. Cordialement, --Lgd (d) 26 septembre 2010 à 15:27 (CEST)
Pas facile à faire, mais ça a de la geule en effet ta liste. :-)
Pour 5 et 6, c'est fait, j'ai déplacé dans une section dédiée, en attendant d'avoir une page dédiée ou une meilleure idée. Pour la 7, j'ai fait la correction et déplacé l'exemple dans un futur brouillon pour légèrement améliorer la section sur les tableaux de mise en forme (celle des bonnes pratiques générales).
Je suis prêt pour la suite de la relecture, si tu l'acceptes. :-) Dodoïste [ dring-dring ] 26 septembre 2010 à 22:43 (CEST)

MediaWiki et les légendes[modifier | modifier le code]

Reprenons la discussion plus haut, fort intéressante. Dodoïste [ dring-dring ] 26 septembre 2010 à 16:28 (CEST)

  • L'accent est mis plutôt sur la rédaction des légendes, qui doivent reproduire l'information principale apportée par l'image. De cette manière, on s'appuie sur un usage déjà bien en place. Il s'agit de veiller à ce que la légende, sans aller jusqu'à une description immédiate et intégrale de l'image, reflète systématiquement l'information clé qu'elle illustre (par exemple, en quoi telle image est-elle exemplaire de ce qui est dit dans le texte voisin ? Ou encore, quelle est la donnée majeure d'un graphique, par exemple une tendance dans une courbe ?).
  • Du coup, du côté des alt, on s'appuie sur une autre possibilité offerte par les normes d'accessibilité WCAG (voir G74: Providing a long description in text near the non-text content, with a reference to the location of the long description in the short description : l'alternative indique que c'est un lien permettant d'accéder à la page de l'image, et que la description de l'image suit immédiatement dans le texte. Cela donne en fait une alternative identique pour chaque image en thumb, qui pourrait être : « Consulter les données associées à cette image, dont la description suit ci-après. » C'est une forme d'alternative qui peut paraître inhabituelle par rapport à ce qui est pour l'instant recommandé dans les bonnes pratiques, mais qui repose sur une approche nouvelle proposée par WCAG2, qu'il serait tout à fait pertinent AMHA d'adopter à présent qu'elle est officielle.
Cordialement, --Lgd (d) 11 septembre 2010 à 06:50 (CEST)
@Dodoïste, spécial training accessibilité : il y a une faille dans cette méthode, qui nécessite un changement du code HTML actuellement produit par mediawiki pour les thumb. Votre mission, si vous l'acceptez, sera de la trouver Clin d'œil Cordialement, --Lgd (d) 11 septembre 2010 à 07:34 (CEST)
Lgd : J'adoore ce genre de petits défis. :-) Et puis c'est nécessaire si je veux faire la demande aux dévs. :-) Le problème est que la légende produite par MediaWiki, qui suit l'image, n'est pas dans un paragraphe p. J'ai gagné ? Hihi ! ^_^ Dodoïste [ dring-dring ] 11 septembre 2010 à 09:10 (CEST)
Arf, mon small c'était plus un gag qu'autre chose, le problème étant bien réel mais le détail passablement complexe. Mais c'est aussi bien si tu relèves le défi Clin d'œil. Donc, il y a éventuellement un p impliqué en effet, mais pourquoi précisément, avec quelle correction du code des thumb exactement, et en rapport avec quel(le) critère/technique WCAG Mort de rire ? --Lgd (d) 11 septembre 2010 à 10:19 (CEST)
Ah bah j'ai pas gagné. :D Je ne pense pas savoir. Ce que j'ai compris, c'est que l'image doit être immédiatement suivie d'un paragraphe contenant la légende. Il peut éventuellement y avoir un effet de redondance entre la petit icône agrandir de lien vers la page de l'image, et le lien sur image. Je donne donc ma langue au chat. Mais ce n'aura pas été faute d'avoir remué cette masse imbitable de critères WCAG 2.0. :-) Dodoïste [ dring-dring ] 26 septembre 2010 à 16:28 (CEST)
Elle n'était pas facile.
Le problème relève de Link Purpose (In Context). Pour qu'un lien libellé de manière générique et répétée dans la même page (via le alt du thumb, du type « Consulter etc. ») soit explicite en contexte, il doit être placé dans le même élément parent que le texte qui l'explicite (ici, la légende) et cet élément doit être d'un type précis. Donc, l'image doté d'une alternative générique et sa légende doivent appartenir au même paragraphe p (le seul type d'élément pertinent dans ce cas, le tableau de mise en forme ne le faisant pas). Cela s'applique également à la petite loupe actuellement. Cordialement, --Lgd (d) 26 septembre 2010 à 16:35 (CEST)
D'accord, merci. Je vais d'abord m'assurer que le travail sur les tableaux fonctionne bien avant de me lancer sur cet autre gros chantier. En tout cas merci, j'ai tous les éléments nécessaires en main maintenant. :-) Dodoïste [ dring-dring ] 26 septembre 2010 à 20:16 (CEST)
je te ferai un point plus construit sur cette proposition de gestion des thumb, si tu veux. En tous cas, merci de la soutenir. Cordialement, --Lgd (d) 27 septembre 2010 à 09:39 (CEST)

Juste un petit - gros - merci à tous les deux. Cela me semble important de vous le dire car c’est de votre travail que seront issus les « modes d’emploi » utiles aux contributeurs Lambda désireux de bien faire mais non compétents sur le plan technique. Avec reconnaissance, --Égoïté (d) 26 septembre 2010 à 22:54 (CEST)

Mélange de technique ET d'accessibilité[modifier | modifier le code]

Bonjour

Le Modèle:Méta bandeau d'avertissement (modèle utilisé dans le Modèle:À sourcer) donne une image non cliquable mais avec un alt non vide. Entre pouvoir modifier la valeur de ce alt tout en ayant une valeur par défaut qui serai une chaine vide et avoir une chaine vide, qu'es ce qui est le plus adapté ? --Manu1400 (d) 3 octobre 2010 à 00:10 (CEST)

L'alternative devrait être systématiquement vide, ces icônes ne véhiculent pas d'information déterminante pour la compréhension du contenu. Cordialement, --Lgd (d) 3 octobre 2010 à 07:25 (CEST)

Casse-tête chin latin[modifier | modifier le code]

Bonjour, dans la Liste des locutions latines faut-il ajouter {{lang}} partout, sachant que certaines expressions relèvent des exceptions mentionnées ici dans la bonnes pratiques. --Amicalement, Salix ( converser) 4 octobre 2010 à 11:16 (CEST)

La réponse est invariable : dans le doute, un {{lang|la}} éventuellement superflu ne causera pas de torts. C'est fait (quand le code wiki d'une page est homogène et propre, ce genre d'edit s'automatise très facilement Clin d'œil). Cordialement, --Lgd (d) 5 octobre 2010 à 08:47 (CEST)
Super, merci Lgd ! S'il y a une page qui avait bien besoin du modèle c'était bien celle-ci. --Amicalement, Salix ( converser) 5 octobre 2010 à 12:22 (CEST)

Test de l'extension LiquidThreads[modifier | modifier le code]

Bonjour. Je viens de dicuter sur IRC avec Werdna (Andrew Garrett) développeur de l'extension qui va améliorer les discussions : LiquidThreads. Voir la page de test et la page de feedback. Je propose de tester cette extension sur la page de discussion de cet atelier. Cela me semble pertinent en matière d'accessibilité, pour que nous puissions tester cette extension, et reporter les problèmes d'accessibilité que l'on trouve.

Notons que j'ai — il y a longtemps — reporté un bug majeur concernant l'accessibilité dans bugzilla:21920 : plusieurs boutons n'étaient pas accessibles au clavier. Ce bug avait été résolu rapidement. Et Werdna semble motivé pour peaufiner l'accessibilité du logiciel.

Tester cette extension ici implique techniquement d'installer LiquidThreads sur fr.wikipedia.org, en étant désactivé par défaut. Et ensuite de l'activer manuellement sur la page désirée - donc cet atelier. Il faut donc un court vote à ce sujet pour montrer aux dévs qu'ils peuvent faire la modif, et leur envoyer un bug. Merci donc d'exprimer votre avis, afin qu'on ait un nombre d'avis significatif. :-)

  1. Pour, en tant que proposant. Dodoïste [ dring-dring ] 4 octobre 2010 à 13:58 (CEST)
  2. Pour, --Égoïté (d) 4 octobre 2010 à 18:07 (CEST)
  3. Pour. TigHervé (d) 4 octobre 2010 à 20:55 (CEST)
  4. Pour mais il faudra pas se plaindre si j'essaye tout ce qu'il y a à essayer... ;) CQui bla 4 octobre 2010 à 21:37 (CEST)
    Exactement ! :-) C'est fou comme mon message est mal passé, car « essayer tout ce qu'il y a à essayer » est vraiment le but de ce test. J'ai du boulot pour rendre ma pensée claire moi ! Mais ça Salix tu sais que ça a pas changé depuis mes débuts ! Mort de rire Dodoïste [ dring-dring ] 4 octobre 2010 à 22:02 (CEST)
  5. Pour Idem Cqui. --Amicalement, Salix ( converser) 4 octobre 2010 à 21:40 (CEST)
  6. Pour Moez m'écrire 4 octobre 2010 à 22:44 (CEST)
  7. Pour Gz260 (d) 5 octobre 2010 à 00:02 (CEST)
  8. Pour la plupart des reproches que j'entends sur mediawiki sont à propos de la difficulté de suivre et participer aux pages de discussions (fonctionnement différent d'un forum, et là on est à deux doigt de la forme d'un forum donc gros +1) A2 (d) 5 octobre 2010 à 06:21 (CEST)
    Yes, A2, t'as tout compris ! :-) C'est exactement le but de cette extension. Dodoïste [ dring-dring ] 5 octobre 2010 à 12:42 (CEST)
  9. Neutre Pour Tester LiquidThreads sur fr est une bonne idée, mais cet atelier très peu fréquenté n'est pas le meilleur support de test qu'on puisse trouver. --Lgd (d) 5 octobre 2010 à 06:59 (CEST)
    C'est juste. Mais comme je le disais à TigH sur le bistro, l'atelier est un point de départ. Ensuite, on peut manuellement l'activer sur une autre page dès que la communauté se met d'accord. Mais on a déjà un quelques réticents sur fr, et si la page était plus visible ils seraient venus voter contre. Les dévs auraient donc refusé de faire le premier pas d'installation. Méthode petits pas. ^_^ Dodoïste [ dring-dring ] 5 octobre 2010 à 12:42 (CEST)
    Ok, ça se tient. --Lgd (d) 5 octobre 2010 à 12:51 (CEST)

Merci de vos avis, j'ai envoyé le bugzilla:25435. Dodoïste [ dring-dring ] 6 octobre 2010 à 05:41 (CEST)

Question pour m'aider a comprendre et donner mon avis[modifier | modifier le code]

Je serais pour un essai de cette fonctionnalité mais je ne suis pas sur que cette page soit la bonne, des personnes n'ayant rien a y dire vont avoir envie d'y trainer, des personnes ayant des problèmes d'accessibilité risquent de ne pouvoir y accéder si justement il y a des problèmes... CQui bla 4 octobre 2010 à 18:49 (CEST)

Bof, l'importance c'est que l'outil soit corrigé avant d'être déployé sur le site. Si il y a un problème temporaire sur cet atelier parce qu'on teste, cela n'a aucune gravité.
« Des personnes n'ayant rien a y dire vont avoir envie d'y trainer » : au vu de la foule venue voter, y'a pas de risque hein. Dodoïste [ dring-dring ] 4 octobre 2010 à 20:44 (CEST)
C'est que les truffes comme moi en informatique n'osent pas se prononcer... vu qu'on n'y pige que couic ! --Amicalement, Salix ( converser) 4 octobre 2010 à 20:47 (CEST)
Oui, c'est de ma faute si mon message est trop technique, désolé. Note qu'à mon arrivée j'avais certainement un profil moins technique que toi. Ça me fait tout bizarre de plus être compris maintenant, alors qu'avant c'est moi qui pigeais que dalle ! Mort de rire
Pour le coup, c'est un vote purement administratif pour les développeurs, y'a pas de raison de refuser. Donc vote juste "pour", c'est tout ce qui compte. Après on pourra tester, et si on aime pas on pourra désactiver facilement nous-même cet outil. :-) Bien à toi, Dodoïste [ dring-dring ] 4 octobre 2010 à 20:58 (CEST)
Chacun son truc. C'est vrai que tu as aquis des connaissances de façon fulgurante dans ce domaine et ne me demande pas de rivaliser ! Je ne suis pas contre des essais, on verra bien... Comme truffe je sais m'adapter à tout type de sol Clin d'œil. --Amicalement, Salix ( converser) 4 octobre 2010 à 21:15 (CEST)

J'ai bien envie de voter contre. Quel est le risque pour Wikipédia que cette extension activée sur une seule page puisse créer des problèmes sur l'ensemble des pages ? J'ai vu que beaucoup de rapports de bug ont été réalisés. (Deux votes c'est peu). Peut-on facilement activer PUIS désactiver cette extension sur toute (les pages de discussion) une Wikipédia ? Ce qui me gène beaucoup c'est le fait de ne pas avoir le choix une fois l'extension activée sur une page du système d'historique et compagnie. comprendre : Faire comme avec Vector : si Vector ne plait pas à untel, il peut revenir à Monobook. PS : Les bots peuvent ils modifier une page de discussion si l'extension est activée sur cette page ? --Manu1400 (d) 4 octobre 2010 à 22:03 (CEST)

Alors c'est bien que tu sois venu m'en parler avant d'avoir voté. :-)
Cette extension sera installée sur tout Wikipédia, mais inactive partout sauf sur le projet accessibilité. Il n'y a pas de risque donc que cela pose un problème sur les pages où l'extension n'est pas activée.
Une fois l'extension installée, si je comprends bien c'est les admins locaux qui peuvent activer et désactiver librement LiquidThreads des pages. C'est très flexible donc.
Je ne sais pas encore si les bots pourront modifier la page de discussion de l'atelier. C'est une bonne question, et c'est pour cela qu'on teste : si besoin on corrigera les bots pour qu'ils puissent faire leurs modifs. Et si c'est pas possible ou trop dur à cause de LiquidThreads, on dira aux développeurs qu'ils doivent repenser leur outil pour que ce soit faisable. :-)
Si tu le permets je déplace cette discussion sur l'atelier comme cela tout le monde profite des explications. Dodoïste [ dring-dring ] 4 octobre 2010 à 23:02 (CEST)

J'ai trouvé la liste des sites qui utilisent LiquidThreads :

Gif animé converti en ogg Theora[modifier | modifier le code]

Pose d'un câble sous-marin (animation)

Bonjour. J'ai vu que tu t'intéressais au sujet. On en est où, en terme de dernier savoir-faire, en état de l'art ? J'ai fait l'an passé des animations gif (dans Cable sous-marin, entre autres) que j'aimerais présenter d'une façon plus ergonomique. Merci d'avance. --Michel Barbetorte (d) 2 octobre 2010 à 14:59 (CEST)

Bonjour, content que tu t'intéresses au sujet. Rapidement, car je n'ai pas de temps tout de suite, mais la semaine prochaine je reviens vers toi. Il existe un brouillon de tutoriel en anglais : converting animated GIFs to Theora OGG. Pour l'instant cela reste un domaine qui a été peu creusé, donc le tutoriel est à traduire, mais aussi probablement à rendre plus clair et plus pas à pas. En attendant, vois quand même si tu arrives à en faire quelque chose, et si tu peux me dire précisément ce qu'il faut améliorer. Bien à toi, Dodoïste [ dring-dring ] 2 octobre 2010 à 17:44 (CEST)
Salut. Bon ben voila, j'ai transformé les deux animations gif en ogv Theora dans Câble sous-marin. Ne reste plus qu'à vérifier que ça passe sur les navigateurs. (J'ai utilisé SMPlayer et WTheora avec la dernière version 0.27 de ffmpeg2theora dans WTheora. Avec ces programmes interactifs par menu, ça devrait être à la portée de presque tous). --Michel Barbetorte (d) 5 octobre 2010 à 16:49 (CEST)
Bravo et merci. La vidéo est de qualité similaire, et est absolument magnifique dans le nouveau lecteur fait par Kaltura en partenariat avec la Fondation. Dans tes préférences > Gadgets > « mwEmbed : ajoute les sous-titres, dans la langue définie dans vos préférences, aux vidéos des extensions Firefogg uploading et Add-Media-Wizard. » Tu peux donc désormais même ajouter des sous-titres pour les vidéos. Ces sous-titres sont actuellement visibles par quelques contributeurs qui ont coché cette case, mais lorsque cette nouveauté sera prête elle sera activée par défaut sur les projets Wikimédia.
Concernant la compatibilité avec les navigateurs, la réponse sur le bistro mérite quelques éclaircissements. Il y a deux facettes distinctes : le support de la vidéo par les navigateurs eux-mêmes (nativement), et les solutions de secours mises en place au cas où le navigateur ne supporte pas justement (fallback).
  1. Le support actuel est indiqué sur HTML5 video#Browser support, on y voit que Ogg Theora a le vent en poupe. Concernant le support à venir, il est probable que le format WebM prenne le dessus. Le lecteur vidéo de Wikipédia prévoit justement d'intégrer WebM, et à priori ce sera le logiciel qui se chargera de convertir le format de la vidéo. Donc cela ne changera rien pour toi : ta vidéo au format Theora est pérenne et a de l'avenir.
  2. Au cas où le navigateur ne supporte pas Theora, il y a le lecteur Java Cortado qui peut prendre le relais. Ainsi que Quicktime, et plusieurs autres selon ce qu'on a installé sur son ordi. Des add-on pour navigateurs sont également disponibles pour améliorer la compatibilité des navigateurs qui pèchent à ce niveau.
En gros, c'est un domaine touffu et complexe. En tant qu'utilisateur tu as simplement à te soucier de mettre la vidéo Theora sur Commons, et c'est les développeurs qui sont responsables de faire au mieux avec. Bien à toi, Dodoïste [ dring-dring ] 5 octobre 2010 à 22:17 (CEST)
C'est bô. D'autant plus que des gens le font, là où la question ne se posait même pas il y a deux-trois ans. Merci Dodoïste et surtout Barbetorte Clin d'œil. Cordialement, --Lgd (d) 5 octobre 2010 à 21:55 (CEST)
En résumé, on voit qu'il est possible de convertir les GIFs en jolies vidéos. On peut donc sensibiliser d'autres éditeurs à cette démarche.
C'est aussi l'occasion de tester l'outil en bêta : préférences > Gadgets > mwEmbed. Le prochaine étape est l'utilisation des sous-titres : un début de documentation se trouve sur Commons:Timed Text.
Bien à vous, Dodoïste [ dring-dring ] 5 octobre 2010 à 22:17 (CEST)
Salut. Tu peux en parler au bistro, des progrès en accessibilité mis à la portée de tous Sourire par Utilisateur:Barbetorte/Conversion d'une animation gif en vidéo Ogg Theora ; j'ai corrigé les liens foireux et ajouté deux mots pour le téléversement sur Commons. Mais n'oublie pas de faire un speech similaire sur le bistro de Commons en français. Il s'agit aussi de savoir, en tâtant le terrain, s'il faut garder ce tutoriel sur ma page perso ou s'il est à mettre sur Commons. En ce qui me concerne, je ne crois pas que toutes les animations .gif soient forcément à convertir en .ogv, mais c'est à voir au cas par cas. Bonne campagne d'accessibilité. À ton service si besoin est pour d'autres sujets qui pourraient entrer dans mes compétences. (Le sous titrage, c'est facile maintenant, mais je ne suis pas sur que tout le monde en ait compris l'intérêt, chaque chose en son temps.)--Michel Barbetorte (d) 7 octobre 2010 à 15:10 (CEST)
Merci encore. Je pense que cela fait sens de le mettre en sous-page de l'atelier accessibilité. Et une copie sur commons sera bienvenue aussi. Peut-être même que quelqu'un le traduira en anglais ?
Je ferai ces messages demain. JackPotte (d · c · b) a bien compris l'intérêt des sous-titres. Mais vu qu'il ne sont visibles que si on a le gadget activé, ça ne prends pas encore. Cela viendra une fois que les vidéos seront vraiment déployées. Dodoïste [ dring-dring ] 8 octobre 2010 à 02:04 (CEST)
J'ai laissé un message sur le bistro du 8, idem sur commons, et placé ton tuto sur commons:Help:Conversion vidéo/Animation GIF en vidéo. :-) Dodoïste [ dring-dring ] 8 octobre 2010 à 19:12 (CEST)
Pas encore décidé où le mentionner (par lien) sur Commons. En revanche il est maintenant sur Wikipédia:Atelier graphique/Didacticiels graphiques/Conversion d'une animation gif en vidéo Ogg Theora. Et il ne faut pas le recopier ailleurs, pour des raisons évidentes de mises à jour. --Michel Barbetorte (d) 9 octobre 2010 à 16:35 (CEST)

Fil d'Ariane, soucis[modifier | modifier le code]

Bonjour,
Ce fil d'Ariane "graphique" n'est pas une bonne idée :

  • le design est trop daté, façon années 90 : mauvaise publicité pour une fonctionnalité essentielle qui sera, du coup, jugée simplement "moche"
  • l'adoption du fil d'Ariane dans les pratiques de design actuelles privilégie la sobriété
  • côté technique, ce n'est pas non plus très habile de mettre en avant une mise en forme via des images HTML
  • côté accessibilité, il perd en lisibilité avec le remplacement des chevrons gauches par des images HTML insuffisamment contrastées et dotées d'alternatives nulles. La suppression du "Vous êtes ici" au lieu de son éventuel masquage à l'affichage n'est pas non plus un gain en ce sens. Enfin, mais c'est sans doute accidentel, le alt de l'icône home est erroné.

Je ne peux que recommander le retour à l'essai initial, améliorable surtout sur le contenu et non sur la forme.

Avec plus de recul, il faut être conscient que mediawiki, dans son utilisation actuelle sur WP, impose une architecture du contenu où le fil d'Ariane est tout au plus une « verrue utile » : un essai plaqué sur une organisation de contenu qui n'y correspond pas, comme l'illustrent par exemple le cas des sous-page ou le rattachement des articles à des portails, ou celui de sous-pages à des projets, etc. Sa pertinence n'est donc pas si évidente : ce n'est pas parce que le fil d'Ariane est considéré aujourd'hui comme irremplaçable dans le cas de contenus bien organisés qu'il serait de facto un bon emplâtre sur la jambe de bois d'ici où les contenus ne le sont pas Clin d'œil.

Par ailleurs, je n'avais pas remarqué sur le moment mais : sur Wikipédia:Atelier accessibilité, l'ajout plus ancien à cet endroit du bandeau "avenue des café et Bistrot" pose également un problème, l'un des intérêts majeur du fil d'Ariane étant qu'il est toujours atteignable au même endroit relatif dans la page, c'est à dire immédiatement après le titre de contenu de celle-ci.

Cordialement, --Lgd (d) 11 octobre 2010 à 09:55 (CEST)

Dodoïste, reviens !!! de ParisWeb Cordialement, --Lgd (d) 15 octobre 2010 à 15:28 (CEST)
Promis je corrigerai ça à mon retour. Pour l'instant je fais du masochisme dans un cybercafé, à taper sur un clavier AZERTY (je suis habitué au QWERTZ) et le tout sous une télé diffusant des émissions people bruyantes me donnant un mal de crâne du tonnerre. Grrr ! Dodoïste [ dring-dring ] 15 octobre 2010 à 19:47 (CEST)
Réponse, enfin :
  • 1 & 2 : Je suis asssez surpris pour le design daté. Oui, le fil d'ariane sobre est le plus courant, mais pleins de sites utilisent une mise en page semblable sans faire "daté". :s
  • On en a discuté, OK. Je vais donc éviter.
  • Je comprends que le "Vous êtes ici" est particulièrement utile pour les internautes aveugles, qui ne disposent pas de la mise en page et de la signalétique graphique pour reconnaître le fil d'Ariane : c'est donc utile. Mais je ne vois pas l'intérêt pour les autres types d'internautes, qui doivent je pense trouver cette précision fort superflue.
J'ai corrigé le problème posé par le bandeau "avenue des café et Bistrot", dans l'immédiat. On peut faire mieux. Bien à toi, Dodoïste [ dring-dring ] 19 octobre 2010 à 23:29 (CEST)

J’ai trop bu…[modifier | modifier le code]

Sand doute ai-je trop bu ce soir à l’occasion du 19e anniversaire de mon fils… mais je n’avais pas envie de passer par mon habitude traditionnelle de contrôle de pages de suivi pour vous trouver et donner un lien à Wikipédia:Oracle/semaine 41 2010#textes en français facile et j’ai rapidement cherché dans Aide:sommaire cette page-ci car il me semblait que je la trouverais aisément. Que dalle ! Ai-je rêvé ou y étiez-vous jadis ? Ai-je vraiment trop bu ou mon ordi, par F3, est-il incapable de trouver « atelier » dans cette page-là ? Donc, sommairement, comment pouvez-vous être accessible sur WP pour ceux qui ne s’intéressent que peu à ce type de problème ? --Égoïté (d) 14 octobre 2010 à 00:13 (CEST) qui va cuver…

Mort de rire C'est mieux ainsi ? Il y avait aussi en bas de l'encadré « Voir aussi : Annuaire des projets ». --Amicalement, Salix ( converser) 14 octobre 2010 à 00:53 (CEST)
Mmmm, oui ! Et tu peux aller plus loin : mettre un lien dans Aide:Liens utiles Clin d'œil --Égoïté (d) 14 octobre 2010 à 08:12 (CEST) qui a dormi du sommeil de la juste Mort de rire
Fait yakadmander ! --Amicalement, Salix ( converser) 14 octobre 2010 à 08:26 (CEST)
Merci Salix. Dans le style yakadmander, une autre question car j’ai vraiment pas le temps de vérifier : les 2 modèles d’infobox dont on parle dans Wikipédia:Le Bistro/15 octobre 2010#Votre avis est sollicité sont-elles correctes quant à l’admissibilité ? Merci déjà, je file.--Égoïté (d) 15 octobre 2010 à 09:00 (CEST)
De ce point de vue, cela ne fait pas de différence :
  • l'un et l'autre nécessiteraient des corrections. Elles sont de natures évidemment inégales puisque les deux infobox correspondent à des types de contenus différents (des images et du js dans l'une, pas dans l'autre). Mais au bout du compte, cela reste des corrections triviales techniquement, beaucoup plus délicates à faire accepter politiquement car elles remettraient en cause plusieurs aspects immédiatement visuels.
  • quel que soit le modèle unique finalement adopté, le fait qu'il n'y en ait qu'un au bout du compte est le seul point clé à retenir pour faciliter ce genre de corrections.
Donc, peu importe le flacon, on atteindra l'ivresse un jour ou l'autre à la place de ces piquettes infâmes.
Quand quelqu'un écrit « admissibilité » en ayant manifestement pensé « accessibilité », je commence à m'intéresser à mon potentiel de gourou sectaire Mort de rire
Cordialement, --Lgd (d) 15 octobre 2010 à 14:41 (CEST)
Mort de rire Je précise, Ô Expert dont les avis sont largement reconnus et respectés (ça va comme ça ?) : admissibilité en matière d’accessibilité. D’accord avec toi à ce stade de la procédure, mais s’il n’y a plus qu’un choix/quand il n’y aura plus que le choix de la boite à faire, le fait qu’une des deux boites soit admissible en accessibilité pourrait bien faire pencher la balance… pour autant que ceux qui s’intéressent à l’accessibilité se manifestent, non ? Clin d'œil --Égoïté (d) 16 octobre 2010 à 07:37 (CEST) qui perso penche pour la boite avec S (V2), qui lui semble plus lisible, plus esthétique et plus dans le style Vector.
Les infobox ancienne manière sont en voie d'extinction « naturelle » (cette PDD était tout à fait dispensable, mais bon). Cordialement, --Lgd (d) 16 octobre 2010 à 10:46 (CEST)

Frises chronologiques[modifier | modifier le code]

Bonjour, la page Aide:Frise chronologique n'aurait-elle pas besoin de quelques conseils d'accessibilité ? --Amicalement, Salix ( converser) 14 octobre 2010 à 19:09 (CEST)

Si. Cordialement, --Lgd (d) 15 octobre 2010 à 14:01 (CEST)
Je me disais aussi... Alors à votre bon coeur Clin d'œil parce que moi et les codes.... --Amicalement, Salix ( converser) 15 octobre 2010 à 19:39 (CEST)
Mais à ce niveau c'est pas juste "quelques conseils", y'a tout à faire surtout du côté de MediaWiki. À moins qu'ont fasse déjà la base en demandant de rédiger une légende qui serve d'alternative ? Cela rendra le passage à une correction propre plus facile le moment venu, donc autant commencer tôt. Dodoïste [ dring-dring ] 15 octobre 2010 à 19:42 (CEST)
Hum... Bof. A l'usage, encourager un pis-aller ne permet pas de « transformer l'essai » par la suite. Il vaut mieux laisser en l'état et saisir la bonne occasion d'une refonte de cette extension. Par laisser en l'état, je veux dire qu'un certain flou sur la question (que j'ai pour ma part volontairement entretenu, je le reconnais) a l'immense mérite d'éviter la confrontation frontale à éviter à tous prix entre « vraiment pas accessible, ne pas utiliser timeline » et « éditorialement, interdire timeline serait immédiatement absurde ». Le management de l'accessibilité nécessite parfois l'existence de petits tas sagement glissés sous le tapis... Cordialement, --Lgd (d) 29 octobre 2010 à 18:48 (CEST)

Correction d'erreurs d'accessibilité avec WPC[modifier | modifier le code]

Bonjour. J'ai proposé à l'auteur de WikiCleaner l'intégration (détections/corrections) d'« erreurs d'accessibilité » à son outil et vous invite à appuyer ma demande (ou à m'expliquer pourquoi elle ne serait pas pertinente) sur la page de discussion du projet de correction syntaxique. J'ai hâte de vous lire car je n'ai pas vraiment d'exemples concrets à apporter pour le moment. L'idée générale est de corriger l'accessibilité en corrigeant la syntaxe et que cela permettrait de sensibiliser les contributeurs aux problèmes d'accessibilité dans les articles. Dodoïste m'a confirmé sur IRC la semaine passée que mon idée avait un potentiel donc voilà, la pierre est jettée. — A2 (d) 20 octobre 2010 à 09:14 (CEST)

Répondu sur la page du projet. Cordialement, --Lgd (d) 20 octobre 2010 à 09:52 (CEST)

Meta palette ?[modifier | modifier le code]

Bonjour. Suite à une proposition BA des Blackhawks de Chicago (non, non, je viens pas vous demander de voter), un intervenant a mentionné l'accessibilité comme critère d'AdQ. Bien que ce ne soit pas le label visé, j'ai fait des modifs dans les tableaux pour insérer de nombreux scope=col (entre autres). En vérifiant les tableaux (grâce à la fonction prévue), j'ai remarqué que les méta-palettes de bas de pages apparaissaient en rouge. D'où ma première question : est-ce normal et y a-t-il un moyen de remédier à ça ? Ma deuxième question porte sur l'accessibilité de l'article lui-même : si l'un d'entre vous a le temps de jeter un oeil sur l'article et me dire ce qui pourrait être encore améliorable au niveau accessibilité, je me ferai un plaisir de faire les modifs nécessaires. --'toff [discut.] 25 octobre 2010 à 00:26 (CEST)

Bonjour. Merci de ton enthousiasme pour ces corrections. :-)
Pour les méta-palettes : oui, c'est un problème connu. Qu'il faudrait vraiment résoudre un jour. Mais c'est un gros chantier car il faudrait complètement refondre les palettes. Pour l'instant, on s'est dit qu'on avait d'autres priorités plus faciles à faire. Mais à mesure que le reste s'améliore, on ne va bientôt plus pouvoir y échapper... Sourire diabolique
J'ai vu que plusieurs changements de langues étaient déjà indiqués. À vue de nez, il y a probablement encore des corrections à faire, notamment dans les références.
Tu as fait un bon boulot sur les tableaux, bravo. Par pure curiosité, je ne comprends pas comment tu as fait une séparation verticale dans le tableau Blackhawks de Chicago#Meilleurs pointeurs. J'ai cru d'abord à des cellules vides, ce qui n'aurait pas été idéal, mais apparemment ce n'est pas le cas ?
C'est tout, concernant cet article. Les modèles ne sont pas compris dans les critères AdQ, vu que c'est trop compliqué pour une bonne partie des rédacteurs. Mais vu que tu est à l'aise avec la technique, peut-être que tu pourrais améliorer Modèle:Infobox Équipe de hockey sur glace. Il s'agit d'associer sémantiquement le titre d'une ligne à sa donnée correspondante, avec ! scope="row" |. Un exemple sera plus parlant : Modèle:Infobox Faciès culturel que j'ai refondu récemment. Note que Modèle:Infobox/Ligne mixte optionnel fait ça très bien, et que ce serait une bonne idée (et plus simple) de refondre l'infobox avec ce lot de modèles - dit "infobox avec des briques".
Voilà, et merci encore. :-) Dodoïste [ dring-dring ] 25 octobre 2010 à 03:26 (CEST)
Merci de ton avis.
Pour les meta-palettes tant pis.
Oui, je connais le modèle lang depuis quelques temps déjà mais il est possible que certaines phrases m'aient échappé vu le nombre de références anglaises qui sont incluses dans l'article, je rejetterai un oeil.
Pour les colonnes, il s'agit en effet d'une cellule vide, mais longue (en fait la fusion de 12 cellule grâce à ! scope=col rowspan="XX" bgcolor="#ffffff" |, XX étant le nombre de cellules (nb de lignes totales du tableau) à fusionner dans cette colonne. C'est un truc que nous employons régulièrement au Projet:hockey sur glace pour les statistiques de joueurs par exemple.
Je note l'idée pour l'infobox Equipe de hockey. Je regarderai comment se présente Modèle:Infobox Faciès culturel pour avoir une idée. --'toff [discut.] 25 octobre 2010 à 05:04 (CEST)
Bon, du coup, j'ai fais des modifs sur Modèle:Infobox Équipe de hockey sur glace. Ca semble bon, a part les deux dernière ligne où j'ai un doute (saison précenete et en cours). Si tu peux jeter un oeil et me donner ton avis. --'toff [discut.] 25 octobre 2010 à 07:13 (CEST)
Dans l'ensemble c'est parfait. Et en effet, il ne fallait pas les mettre sur les saisons précédentes et en cours, c'est corrigé. C'est parce que ces cellules sont seules ; ce n'est pas un titre associé à une cellule. :-)
Pour la cellule vide du tableau, ce serait bon de trouver une autre solution. Déjà, est-ce que ces séparations sont bien nécessaires ? Si on peut s'en passer, ce sera le plus simple. Sinon, j'ai pas d'idée. Qu'en penses Lgd ? Dodoïste [ dring-dring ] 25 octobre 2010 à 14:16 (CEST)
Nécessaires : oui et non. Ça permet de séparer le tableau en deux au niveau des statistiques qui sont traitées différemment en Amérique du Nord en évitant de faire 2 tableaux séparés l'un sous l'autre. Est-il possible de mettre 2 tableaux l'un à côté de l'autre tout en gardant une certain accessibilité ? S'il y avait une méthode pour séparer en gardant l'accessibilité pourquoi pas. --'toff [discut.] 26 octobre 2010 à 06:36 (CEST)
Laisser en l'état : la colonne de séparation centrale ne pose pas de soucis réels (même si elle fera sourciller certains puristes anglo-saxons, il y a eu des débats à ce propos). Pour améliorer, ajouter un scope row sur le rang (première colonne du tableau), peut-être.
Sinon, en regardant très vite (entre deux trains) ce matin certains des articles corrigés, je crois bien avoir vu des scope sur des TD (code wiki |) au lieu de TH (code wiki !). Je regarderai pour corriger ce WE. Merci et bravo à 'toff en tous cas Clin d'œil. --Lgd (d) 29 octobre 2010 à 18:24 (CEST)
J'en ai pas vu pour ma part, mais j'ai pu passer à côté ? Dodoïste [ dring-dring ] 31 octobre 2010 à 17:16 (CET)

Le retour du boulet[modifier | modifier le code]

Salut, c'est encore moi. Je suis parti (en croisade) pour essayer "d'accessibiliser" tous les articles labellisés du projet hockey et d'entraîner avec moi mes camarades hockeyeurs (vous pouvez y intervenir). A part ça, je me pose une question, doit-on apposer le modèle lang pour les liens vers les articles à consonance anglophone comme The New York Times par exemple ? --'toff [discut.] 26 octobre 2010 à 07:15 (CEST)

Vu l'important travail que tu as lancé sur le projet hockey, tu es à des lieues d'être un boulet. Plutôt un aide très bienvenu, et un important levier dans les rouages de cet atelier. ;-)
Les changements de langue doivent être indiqués, « excepté pour un nom propre, pour un terme technique ou pour un mot ou expression faisant partie du français courant ». Donc, dans ce cas, il y en a besoin. À écrire de la manière « [[The New York Times|{{lang|en|The New York Times}}]] ». :-)
Sinon, les deux modifications que tu as indiquées ne sont pas les seules à prendre en compte pour l'accessibilité. C'était les deux principaux dans le cas de l'article Blackhawks de Chicago, mais pour d'autres articles il peut y avoir d'autre critères concernés. Par contre, ce sont probablement les plus facile à prendre en compte, et les plus courants. Et un bon point de départ. Donc on ne va pas ajouter d'autres critères pour l'instant. Mais ce serait bon de préciser que ces deux critères constituent un point de départ, et qu'il y en a d'autre qu'on pourra prendre en compte si ça marche déjà bien avec les deux premiers. ;-) Dodoïste [ dring-dring ] 27 octobre 2010 à 20:14 (CEST)
Les tableaux sont aujourd'hui le souci le plus criant à traiter dans les modèles et articles liés au sport en général, dans un premier temps. Mais comme il peut s'agit de tableaux parfois très complexes, il faut aussi doser sagement l'effort : corriger ce qui est évident et savoir passer sur ce qui ne l'est pas.
Sinon, le modèle lang pose souvent des difficultés aux wikipédiens qui préfèrent en général les règles binaires, mais l'essentiel à retenir est qu'il s'agit d'une affaire où chacun peut et doit faire preuve de son bon sens : apposer le modèle trop souvent ne posera pas de problèmes, mais si on veut être plus spécifique dans son utilisation, c'est le fait de savoir si ce sera compréhensible prononcé « à la française » qui est le critère déterminant pour l'appliquer ou non.
Bien évidemment, je plussoie l'idée de commencer avec peu de choses mais qui soient à la fois très utiles et aussi aisées que possible. L'essentiel est d'amorcer le processus. Cordialement, --Lgd (d) 29 octobre 2010 à 18:45 (CEST)
Dans l'exemple donné, on trouve donc :
! scope="col" rowspan="99" bgcolor="#ffffff" |
! scope="col" colspan="5" | Saison régulière
! scope="col" rowspan="99" bgcolor="#ffffff" |
Soit un « ! scope="col" » sur la pseudo-cellule de séparation. Ne vaudrait-il pas mieux avoir :
| rowspan="99" bgcolor="#ffffff" |
! scope="col" colspan="5" | Saison régulière
| rowspan="99" bgcolor="#ffffff" |
Mais peut-être que c'est un détail ? Bien à toi, Dodoïste [ dring-dring ] 29 octobre 2010 à 20:00 (CEST)
Oui, on peut replacer le TH par un TD, mais l'impact utilisateur est incertain. Disons qu'il s'agit surtout de savoir ce qui sera le plus simple pour les contributeurs. Ne rien faire peut être un choix Clin d'œil. Cordialement, --Lgd (d) 30 octobre 2010 à 13:33 (CEST)
C'était bien la réponse que j'attendais. Merci ! Donc on laisse comme ça, au moins pour le moment. :-) Dodoïste [ dring-dring ] 30 octobre 2010 à 14:18 (CEST)
Ça m'arrange un peu vu le nombre énorme d'article impactés. Clin d'œil --'toff [discut.] 31 octobre 2010 à 20:06 (CET)
Sinon, quelle est la différence entre « [[The New York Times|{{lang|en|The New York Times}}]] » et « {{lang|en|[[The New York Times]]}} » ? Visuellement, ça donne la même chose. Problème avec la gestion de liens internes dans le modèle ? --'toff [discut.] 31 octobre 2010 à 20:06 (CET)
"Visuellement, ça donne la même chose." : Le modèle {{lang}} n'est pas censé avoir un impact visuellement. C'est une information destinée aux aveugles qui écoutent la page avec un lecteur d'écran, et aux moteurs de recherche qui indexent et surtout traduisent le contenu comme Google Translate.
Pour le fond, je vais me contenter de recopier la réponse de Lgd d'il y a presque un an, à la même question.
« Bonne question, mais la réponse est assez simple, heureusement.
Sur le fond, les deux seront le plus souvent pertinents. Ce n'est pas essentiel, pas de souci majeur avec la syntaxe que tu utilises : le fait de signaler la langue est déjà beaucoup plus important que les détails qui suivent.
Dans le détail : le premier (mon exemple) incite les rédacteurs à être plus attentifs au libellé de leur lien, qui peut ne pas être dans une seule langue, ou qui peut être modifié par la suite sans qu'on prenne garde au modèle de langue, ou qui peut être dans une langue X pour une cible dont le titre Y est dans une autre (d'où un souci technique évité car le title du lien ne risquera pas d'être dans une autre langue que celle qui lui est attribué). Bref, il y a divers cas compliqués qu'on évite de poser avec la première syntaxe. Cordialement, --Lgd (d) 13 mars 2010 à 13:50 (CET) »
En résumé, adopter cette syntaxe permet de prévenir des erreurs que les Wikipédiens pourraient commettre au fil du temps. À terme donc, cela simplifie la tâche. Voilà voilà. :-) Dodoïste [ dring-dring ] 31 octobre 2010 à 21:49 (CET)
Visuellement n'était pas le bon terme choisi (puisque le modèle lang est "transparent" pour nous). Je voulais dire que dans les deux cas, le lien interne apparaissait et renvoyait vers le bon article. Ce qui me rassure, c'est que les deux sont valables et qu'il n'est pas nécessaire de modifier les existants mais je m'attacherai à utiliser la seconde forme à l'avenir. Merci. --'toff [discut.] 31 octobre 2010 à 22:25 (CET)
Tiens, à relire je réalise que, sortie de son contexte, il manque une précision dans la réponse de Lgd : La syntaxe à préférer est donc « [[The New York Times|{{lang|en|The New York Times}}]] ». Mais je crois que tu as compris. Merci à toi de d'intéresser à l'accessibilité. :-) Dodoïste [ dring-dring ] 31 octobre 2010 à 23:20 (CET)
salut, on se connait pas mais je suis le pote du boulet ...
par contre, sauf erreur de ma part on écrit : « ''[[The New York Times|{{lang|en|The New York Times}}]]'' » non ? --TaraO (d) 9 novembre 2010 à 09:14 (CET)

Gros doute sur les palettes versus box[modifier | modifier le code]

Bonjour, comme suite au conseil de Lgd, le projet élevage a commencé la rédaction de palettes de navigation (voir Catégorie:Palette de navigation intra-espèce) pour relier les sous articles entre eux plutôt que des box "sous-article" (voir un exemple en haut à droite de Colourpoint) . Mais à l'usage j'ai de gros doutes :

  1. Contrairement à une box du type biohomonymie, le contenu des palettes n'est plus lisible depuis l'article par un lecteur d'écran puisqu'il n'y a plus que le nom du modèle
  2. les palettes sont parfois regroupées comme ceci et sont donc beaucoup moins visibles

Est-ce alors un si bon choix ? --Amicalement, Salix ( converser) 29 octobre 2010 à 19:16 (CEST)

Tout va bien, c'est le bon choix. Cordialement, --Lgd (d) 29 octobre 2010 à 21:54 (CEST)

Bizarrerie[modifier | modifier le code]

Coucou. Sur Wikipédia:Accessibilité#Accessibilit.C3.A9_du_Web je viens de trouver : « Prendre en compte les spécificités des lecteurs d'écran afin de favoriser l'accessibilité du Web aux malvoyants. Cela implique en particulier de ne pas mettre de liens internes sur les titres des sections, et de ne pas abuser, en règle générale, de ces liens internes. » La deuxième phrase me surprend fortement, pour dire le moins.

À supprimer carrément, ou à réécrire en quelque chose de plus utile ? Dodoïste [ dring-dring ] 31 octobre 2010 à 23:58 (CET)

Question d'ordre technique[modifier | modifier le code]

Est-ce qu'il y a une différence au niveau de l'accessibilité entre

| scope="col" | '''truc machin'''

et

! scope="col" | truc machin

? En tout cas au rendu visuel, je n'en vois aucune. Udufruduhu (d)

Oui, clairement : la permière version génère un td (table data cell) donc une case de données, la seconde un th (table header cell) donc une case d'en-tête.
C'est étrange que tu aies le même rendu visuel ; pour ma part j'ai un texte aligné à gauche avec la première et un texte centré avec la seconde — ça dépend peut-être du style du tableau.
Amicalement — Arkanosis 1 novembre 2010 à 11:12 (CET)
Ah ok, merci pour la réponse. Effectivement cela dépend du style du tableau. Donc si je comprends bien la première syntaxe ne sert à rien, car le scope="col" ne doit être utilisé que dans les entêtes. J'ai bon ?
Et puis tant que j'y suis j'ai deux autres questions. J'ai testé le gadget accessibilité et je n'ai pas tout compris (si elle existe, j'ai pas trouvé la page d'aide). Ma première question concerne le code de couleurs lorsqu'on visualise les tableaux. Le vert signifie que c'est ok et le rouge que le tableau n'est pas accessible, mais que signifie la couleur jaune ?
Ma seconde question concerne le mode inspection des headers. Je l'ai testé sur plein d'articles mais je n'ai jamais rien remarqué et donc je ne comprends pas à quoi cela sert et comme s'en servir. Si vous pouviez m'éclairer à ce sujet vous seriez bien aimables Clin d'œil. Udufruduhu (d) 1 novembre 2010 à 17:53 (CET)
« Le scope="col" ne doit être utilisé que dans les entêtes [de lignes et de colonnes] » : en gros, pour éviter de compliquer la question avec des détails techniques inutiles, oui tu as bon.
Pour le gadget, j'ai compris en partie en regardant le code MediaWiki:Gadget-Accessibility.css. À mon avis, ce qui est en jaune est correct également. Mais le jaune est essentiellement utilisé pour entourer le titre du tableau (en haut de celui-ci), et signale donc que le code utilisé pour ce titre est bien « |+ ». Après, le gadget ne peut pas évaluer la pertinence du contenu du titre, ce qui est un autre sujet.
Il existe deux autres usages du jaune. L'un pour une autre méthode correcte de faire des titres de tableaux accessibles, mais plus complexe et donc à ne pas trop utiliser - d'ailleurs tu ne le verras pas souvent. L'autre pour je ne sais trop quoi, mais tu ne devrais pas rencontrer ce cas souvent non plus. Dodoïste [ dring-dring ] 1 novembre 2010 à 20:06 (CET)
Hum... Je n'avais pas rédigé de page d'explication à propos de ce gadget qui n'était alors pratiquement jamais utilisé, mais il est temps d'y remédier Mort de rire.
Je vais en profiter pour le mettre à jour, la détection des tableaux est largement améliorable. Cordialement, --Lgd (d) 2 novembre 2010 à 07:48 (CET)
Tiens, ce serait l'occasion de solliciter l'excellent Utilisateur:Dr Brains pour améliorer le script un peu vieillot de ce gadget. Cordialement, --Lgd (d) 2 novembre 2010 à 09:59 (CET)

Accessibilité des palettes, un essai à transformer[modifier | modifier le code]

Bonjour. Je signale que Od1n a récemment créé {{Liste éléments}}, censé à terme être utilisé dans les palettes. Parmi les avantages cités dans la discussion, il précise, je cite :

« Il y a un autre avantage, c'est que ça centralise les éléments : si un jour une personne, Lgd par exemple, fait un système d'accessibilité pour que les palettes contiennent des listes <ul> mises en forme par CSS, on aurait juste à modifier mon modèle. »

— Od1n

Le plus gros reste à faire, sachant que ce modèle est actuellement utilisé sur 3 palettes. Mais avec un peu de pub bien placée, à terme ça peut le faire.

Je propose surtout, dans le cadre de cet atelier, de s'occuper de corriger le modèle en utilisant une liste et la classe correspondante, comme en:template:Flatlist. Dodoïste [ dring-dring ] 1 novembre 2010 à 21:55 (CET)

Créer une liste horizontale est à première vue très simple, avec par exemple ce code :

<ul style="margin:0">
    <li style="display:inline; margin:0">Riri&nbsp;• </li>
    <li style="display:inline; margin:0">Fifi&nbsp;• </li>
    <li style="display:inline; margin:0">Loulou</li>
</ul>

Noter que comme MediaWiki force le formatage du code HTML généré en mettant chaque <li> sur une ligne, je suis obligé de placer les « &nbsp• » à la fin des <li>.

Mais il y a un problème que je n'arrive pas à résoudre : avec le CSS désactivé, on obtient une liste verticale, certes, mais qui contient des « • » moches à la fin.
On pourrait utiliser les pseudo-éléments :before / :after, mais ceux-ci sont mal supportés par certains navigateurs. Quelqu'un aurait une idée ?

od†n [dead words] 2 novembre 2010 à 00:22 (CET)
Bonjour,
Plus simplement, il suffit d'utiliser une image de background CSS à la place des caractères de boulets actuels, qu'il s'agit justement de faire disparaître (ainsi que le détail inutilement complexe des espaces insécables). Cordialement, --Lgd (d) 2 novembre 2010 à 07:46 (CET)

Titres de tableaux[modifier | modifier le code]

Bonjour. Quelques titres de tableaux commencent à être acceptés sur en:, et la pertinence de leur contenu est discutée. Surtout lorsqu'ils sont précédés d'un titre de section. Et certains sont bien trop longs, comme Fantasia Barrino discography.

Les arguments sur l'intérêt sémantique des titres de tableaux et leur importance pour l'accessibilité ne sont pas la question. L'utilité est reconnue pour l'accessibilité (du moins c'est ce qu'il me semble), c'est bien le contenu lui-même qui est débattu.

J'aimerais donc quelques conseils sur les titres de tableaux à utiliser sur :en:WP:DISCOGSTYLE (en bas) et le tutoriel de tableaux. En particulier concernant la redondance possible avec les titres de colonnes. Merci d'avance. :-) Dodoïste [ dring-dring ] 7 novembre 2010 à 22:51 (CET)

J'oubliais : l'essentiel de la contestation figure sur :en:Wikipedia talk:Featured list candidates#Bold (or otherwise) table captions. :-) Dodoïste [ dring-dring ] 8 novembre 2010 à 18:45 (CET)
Encore ? Moi qui croyait naïvement nos collègues anglo-saxons plus directs que nos ergotages gaulois...
Plus sérieusement et sans avoir regardé plus avant (volontairement) : il y a erreur de débat si vous en êtes à discuter du contenu et de la longueur du CAPTION. Titrer un tableau est tout aussi évident que titrer une section : c'est exactement la même chose, tellement simple que tous les wikipédiens y parviennent avec brio depuis des années. Il suffit de suivre le même instinct.
Maintenant, en fait, je soupçonne le débat d'être largement biaisé par les questions de redondance. Alors allons-y : rien, en aucun cas, ne justifie l'absence de cette information clé et irremplaçable pour les aides techniques qu'est le titre de tableau, quel que soit le titre de la section et le fait que son contenu soit réduit au tableau, ou quel que soit le contenu du paragraphe qui précède le tableau, ou autres choses du genre confusion avec le SUMMARY, etc. La clé est qu'un tableau, contrairement à un lien, n'est jamais « explicite en contexte » grâce à un autre contenu.
Rappel: la seule chose sur laquelle peuvent retomber les aides techniques en l'absence de CAPTION (on oublie l'attribut SUMMARY que personne n'a jamais pu savoir comment rédiger), c'est de restituer la première ligne du tableau comme manière de désigner son contenu. Laquelle est compréhensible une fois sur deux dans le meilleur des cas. Donc, on met des titres à chaque tableau et sans chercher plus loin (surtout), ces titres disent la même chose que s'il s'agissait d'écrire le titre Hn d'une section.
Il faut souvent, donc, un doublon nécessaire entre le CAPTION à comprendre comme une métadonnée et le contenu éditorial qui a été naturellement saisi. Pour le rendre supportable, une solution consiste à lui appliquer une classe de masquage (le .hidden de wp.fr). En attendant peut-être le labelledby ARIA et en fait sans doute même après cela (on pourra alors peut-être dire que le tableau est « labelled by » le titre de section ou la phrase qui le précède, mais encore faudra-t-il pouvoir faire faire cela par des contributeurs, ce qui n'est pas gagné sauf à les transformer en experts es code accessible...)
Je sais pourquoi je n'ai jamais voulu intervenir sur en.wp notamment Mort de rire. <Edith>Bon, je suis quand même allé voir : le drame est en fait une question de gras ou pas gras avec les inévitables infobox en seconde semaine... c'est irrécupérable. Les infobox sont des tableaux de données dont le rôle et le contenu sont entièrement à revoir, avant de pouvoir les coder sémantiquement (et donc de manière accessible). C'est le point Godwin de l'accessibilité wikipédienne, qu'on sort quand on n'a plus rien à dire. </edith> Cordialement, --Lgd (d) 8 novembre 2010 à 19:16 (CET)
Je suis confronté à un éditeur qui pose beaucoup de question en même temps, fait un boucan du diable, et change de priorité tout le temps. Maintenant, il est axé sur :en:Essjay controversy, le troll ultime lié aux "experts" sur en:. En gros, "mais c'est qui ce soi-disant expert qu'on suit là ? Qu'est-ce qui atteste qu'il est vraiment expert ?" Il est constructif sur le long terme, mais super lourd à gérer dans l'instant. Me souvenant que tu avais peu apprécié la dernière fois où j'avais parlé de ton identité IRL, je me suis abstenu. Mais ça veut dire que je suis pour l'instant bloqué sur ce point, et qu'à long terme il faudrait trouver une solution. La solution peut peut-être venir de l'interaction avec des experts supplémentaires, parmi ceux que je rencontrerai à la formation en décembre, ou WebAIM, ou qui voudra bien.
Sinon, oui, notre RexxS veut utiliser des SUMMARY à la place des CAPTION. Le problème du gras a pu être surmonté en grande partie. Le problème qui reste est bien le contenu du CAPTION, notamment parce que certains font des CAPTION bien trop longs.
Je ne suis pas trop fan de la solution du .hidden, je pense que cela se marie mal avec les pratiques éditoriales. La situation n'a pas trop bougé depuis le 8 novembre, donc. Bien à toi, Dodoïste [ dring-dring ] 16 novembre 2010 à 21:40 (CET)

Couleurs[modifier | modifier le code]

Ia Orana, devinez qui c'est ? Clin d'œil

Bon, suite à la mise en place (progressive) de l'accessibilité au sein du projet hockey (mais je suis content, ça suit derrière ! ) j'ai encore une petite question pour vous : au niveau des couleurs, on doit éviter de donner une indication uniquement par la couleur (pas de soucis) et on parle de contraste entre le fond et le texte. Mais je ne vois nulle part d'indication disant que si on indique une information par la couleur (en plus d'une autre indication) il est utile également parfois de faire attention à choisir des couleurs bien contrastées. Je m'explique : dans l'article Saison 1928-1929 des Bruins de Boston que nous développons avec TaraO (d · c · b), j'ai copié collé un tableau pour les résultats des matchs qui ne me satisfait pas (copie partielle) :

Date Adversaire Score Fiche
15 nov Symbol support vote.svg @ Pirates de Pittsburgh 1-0 1-0-0
17 nov Symbol neutral vote.svg @ Sénateurs d'Ottawa 2-2 1-0-1
20 nov Symbol oppose vote.svg Canadiens de Montréal 0-1 1-1-1

Le contraste entre les deux couleurs est infime. Je me dirigeais vers des couleurs différentes :

Date Adversaire Score Fiche
15 nov Symbol support vote.svg @ Pirates de Pittsburgh 1-0 1-0-0
17 nov Symbol neutral vote.svg @ Sénateurs d'Ottawa 2-2 1-0-1
20 nov Symbol oppose vote.svg Canadiens de Montréal 0-1 1-1-1

mais je me demande si c'est encore assez contrasté ?

D'où mes questions :

  • Ne doit-on pas également préciser quelque part que le contraste dans les couleurs utilisées à fin d'indication doit être aussi assez prononcé,
  • Dans ce cas particulier, le contraste préconisé (4.5) n'est-il pas trop fort ? Le premier exemple oscille entre 1.1 et 1.2 et le 2e entre 1.6 et 2.6. Je précise que le 1.6 concerne les deutéranopes dont je fais partie (donc l'accessibilité me concerne même si ce n'est pas pour ça que je m'y suis intéressé) et que ça me suffit largement, mais je ne peux pas parler pour d'autres. --'toff [discut.] 9 novembre 2010 à 06:00 (CET)
Bonjour,
Du côté des normes d'accessibilité :
  • WCAG2.0 ne prévoit pas de critère de contraste applicable dans ce cas, c'est à dire lorsque deux couleurs différencient une information (les exigences de contraste ne concernent que le contraste entre le texte et son arrière-plan, selon les critères 1.4.3 Contraste minimum et 1.4.6 Contraste amélioré).
  • Mais le critère clé est que l'information est véhiculée également par un autre moyen (Critères 1.3.1 Information et relations et 1.4.1 Utilisation de la couleur). La présence de la colonne d'icônes Symbol support vote.svg, Symbol neutral vote.svg et Symbol oppose vote.svg satisfait ce point. Il faudra cependant améliorer l'utilisation des icônes :
    • en renseignant l'en-tête de la colonne (quitte à le masquer à l'affichage, voir ci-dessous)
    • en renseignant les alternatives textuelles des images (qui gagneraient également à ne plus être cliquables, voir ci-dessous, mais en pensant aussi à les ajouter à la page Wikipédia:Crédits graphiques pour régler les questions d'accès à la mention des auteurs).
Par ailleurs, et pour d'autres raisons, ces tableaux doivent également avoir un titre caption (wiki : |+, éventuellement masqué à l'affichage.
Tableau et icônes corrigés, version avec l'en-tête de colonne visible (également corrigé côté styles pour alléger le code à l'aide de la classe wikitable) :
Résultats de la saison 1928-1929
Date Résultat Adversaire Score Fiche
15 nov victoire @ Pirates de Pittsburgh 1-0 1-0-0
17 nov match nul @ Sénateurs d'Ottawa 2-2 1-0-1
20 nov défaite Canadiens de Montréal 0-1 1-1-1
Tableau et icônes corrigés, version avec l'en-tête de colonne renseigné mais masqué avec ! scope="col" | <span class="hidden">Résultat</span> (le titre caption est également présent et masqué):
Date Adversaire Score Fiche
15 nov victoire @ Pirates de Pittsburgh 1-0 1-0-0
etc. Code identique au précédent
S'ils n'existent pas, il faudrait prévoir 3 modèles pour les icônes afin d'alléger le code des tableaux dans les articles et de garantir que l'alternative textuelle et le link= seront bien utilisés systématiquement.

Au-delà, si on veut aller plus loin que les normes d'accessibilité : on peut en effet s'intéresser aux contrastes entre les trois couleurs utilisées. Dans ce cas :
  • Comme tu le constates avec ton essai, il est en pratique impossible d'atteindre des ratio de contrastes significatifs entre ces couleurs d'arrière-plan : même sans aller jusqu'au minimum de 4.5:1 qui est exigeable en matière de texte, le seuil de 3:1 retenu dans certains autres cas sera déjà impraticable. Cela signifie que l'impact final sera faible dans les cas de handicap visuel ou technique hors daltonisme (parmi le public des handicaps visuels, les daltoniens ne sont en fait pas spécifiquement la cible de ces critères. Quant au handicap technique, il concerne toutes les situations où les contrastes perçus sont faibles indépendamment d'un handicap visuel, par exemple en cas de mauvais écran, d'éclairage défavorable etc.)
  • Cela permet cependant une amélioration dans le cas particulier du daltonisme et plus précisément ici des deutéranopes (ici, protanopes et tritanopes ne sont pas ou peu pénalisés par cette palette précise).
  • Mais cela impose un choix de couleurs très denses, qui sont peu adaptées à des arrière-plan de texte pour la plupart des utilisateurs. Au point qu'on peut considérer que cette amélioration pour un type spécifique (deutéranopie) sera une gêne pour un nombre plus importants d'autres personnes.
En conclusion : il n'est jamais facile de sortir des exigences WCAG pour tenter d'aller plus loin (sinon, ce genre de critère aurait été intégré à WCAG Clin d'œil). Étant donné que les tableaux comportent cette colonne d'icône, je conseillerais de s'en tenir aux couleurs initiales.
Cordialement, --Lgd (d) 9 novembre 2010 à 07:34 (CET)
Je retiens de tout ça :
les ! scope="col" | <span class="hidden">Truc à ne pas afficher mais qui est utile</span> à instaurer.
le fonctionnement que j'ai avec Tarao (d · c · b) depuis quelques années du binôme « vision des couleurs normales/deuteranope » est un plus car il permet d'améliorer ma perception des articles sans gêner celle des gens « normaux » : il me propose des couleurs et je lui dit si c'est « visible » pour moi. Merci. --'toff [discut.] 9 novembre 2010 à 08:18 (CET)
Une idée en passant : créer une catégorie "Wikipédien ayant une spécificité visuelle prêt à aider". Ce serait un plus et une aide précieuse dans le cadre de l'accessibilité, non ? --Amicalement, Salix ( converser) 9 novembre 2010 à 08:55 (CET)

Au sujet du modèle Prononciation[modifier | modifier le code]

Bonjour,

Le Modèle:Prononciation (qui est très employé) peut être utilisé de deux façons car l'un des paramètres est facultatif. Lorsqu'il est utilisé sans le paramètre facultatif il génère environ Prononciation du titre dans sa version originale. Je souhaite proposer d'ajouter un title sur la balise a, ce qui donnerai par exemple Prononciation du titre dans sa version originale. Qu'en pensez vous ? --Manu1400 (d) 11 novembre 2010 à 19:13 (CET)

Autant que possible, title du lien et alt de l'image devraient être identiques. Dans ce cas, il faudrait d'ailleurs profiter de l'occasion pour corriger le alt qui ne correspond pas forcément au contexte actuellement (ce n'est pas nécessairement le « titre ») : alt="Écouter|Écouter serait donc préférable. D'autre part, la suppression du sup sur le texte serait aussi préférable pour la lisibilité et par ailleurs pour le respect formel des critères WCAG (exemple Bruxelles). Cordialement, --Lgd (d) 12 novembre 2010 à 06:53 (CET)

Question bete (encore)[modifier | modifier le code]

C'est quoi la différence entre Inspection des tableaux et Inspection des header ? --'toff [discut.] 12 novembre 2010 à 07:12 (CET)

Je suis en train de refaire entièrement le gadget. Pour l'instant, « Inspection des header » est inutile. Cordialement, --Lgd (d) 12 novembre 2010 à 10:25 (CET)

Refonte du gadget accessibilité[modifier | modifier le code]

C'est noir, ça pique, ça se reproduit vite... les punaises sont une vraie malédiction !

Bonjour,
Depuis le temps que je devais m'y mettre, j'ai fini par me bouger : une nouvelle version du gadget accessibilité (destiné à faciliter la vérification de quelques bonnes pratiques) est en cours d'écriture.

Autrement-dit:

  • vous êtes invités à actualiser le cache de vos navigateurs pour mettre à jour les scripts et feuilles de style du gadget (Firefox, Safari : maintenez la touche Majuscule (Shift) en cliquant sur le bouton Actualiser (Reload) ou pressez Maj-Ctrl-R (Maj-Cmd-R sur Apple Mac) ; Internet Explorer, Opera : maintenez la touche Ctrl en cliquant sur le bouton Actualiser ou pressez Ctrl-F5).
  • vous êtes invités à le tester, que ce soit sous Monobook ou sous Vector. Il y a forcément toutes sortes de choses qui ne marchent pas encore.
  • la toute nouvelle page d'aide du gadget est en cours d'écriture. Elle manque évidemment d'illustrations mais celles-ci ne seront ajoutées que quand le rendu final du système de test sera fixé.
  • pour râler, proposer, discuter et en papoter, c'est ici.

Cordialement, --Lgd (d) 12 novembre 2010 à 13:52 (CET)

D'ailleurs, si quelqu'un a le courage de chercher une belle icône de punaise + la même barrée sur Commons, pour remplacer le lien « fixer », ce serait sympa... Désolé : chercher des icônes dans le fouillis de Commons est au-dessus de mes capacités Mort de rire. Cordialement, --Lgd (d) 12 novembre 2010 à 14:05 (CET)
Choisis une image dans :commons:Category:Pushpins qui corresponde à ce que tu cherches, et je te fais la version barrée. :-) J'aime bien la noire ci-dessus, mais je sais pas si ça s'intégrera bien à ton outil ? Dodoïste [ dring-dring ] 12 novembre 2010 à 15:04 (CET)
J'avais quand même regardé :commons:Category:Pushpins mais elles sont toutes très moches, trop fines, trop grosses etc. La bonne vieille punaise courante dans les interfaces, je voudrais (celle qu'on voit bien en 12px de haut)... Mort de rire. Mais sinon, celle-là pourrait le faire si elle était dans le bon sens (inversion horizontale). Sinon, tu en penses quoi du machin ? (je viens d'ajouter le test des citations). Cordialement, --Lgd (d) 12 novembre 2010 à 15:10 (CET)
Hum, j'ai tenté de te la retourner et de la réduire un peu, mais rien n'y fait, en petite taille elle rend mal. Pas le temps de t'en faire une en partant de rien, ma foi. :( Dodoïste [ dring-dring ] 13 novembre 2010 à 15:54 (CET)
Merci ! On fera sans, ce n'est pas urgent (l'articulation entre le plier/déplier par défaut du lenu de gauche et le fixer de cet item est de toute façon à revoir). Cordialement, --Lgd (d) 13 novembre 2010 à 15:56 (CET)
Un admin devrait ajouter un lien « (page d’aide) » sur la description du gadget. A2 (d) 12 novembre 2010 à 20:05 (CET)
Fait ça vient, ça vient Clin d'œil. Cordialement, --Lgd (d) 12 novembre 2010 à 20:15 (CET)

En passant, beau boulot, ca va (me) faciliter la tâche pour accessibiliser. Merci, merci, j'aime beaucoup ! --'toff [discut.] 12 novembre 2010 à 21:04 (CET)

Bravo ! Je ne sais pas encore très bien l'exploiter mais en tout cas ça marche bien ! --Amicalement, Salix ( converser) 13 novembre 2010 à 00:01 (CET)
applaudissement --Égoïté (d) 13 novembre 2010 à 09:37 (CET)
Moi pas comprendre : par exemple je teste Oie flamande où les tableaux ne m'ont pas l'air très accessibles en l'état, pourtant ils sont simplement entourés de orange. Qu'est-ce que ça veut dire ? --Amicalement, Salix ( converser) 13 novembre 2010 à 11:46 (CET)
Le gadget suppose que ce sont des tableaux de mise en forme, puisqu'il n'y a pas de titres, ni rien qui puisse laisser penser que c'est un tableau de données. Dans ce cas, c'est à toi de vérifier si le tableau en orange sert juste à la mise en page, ou si il c'est un tableau de donnée qui a besoin de titres, et tout. Dans ce cas, ton instinct avait juste, et la plupart sont des tableaux de données pas du tout accessibles en l'état.
Sauf un : tu peux voir que dans Oie flamande#Arts, tu as aussi un tableau entouré en orange. Et celui-ci, c'est un tableau de mise en page, voir les bonnes pratiques sur les tableaux de mise en page. Et en l'état, il est accessible. :-) Dodoïste [ dring-dring ] 13 novembre 2010 à 12:12 (CET)
Merci! Quelques explications supplémentaires dans la section idoine serait les bienvenues. Tire la langue. --Amicalement, Salix ( converser) 13 novembre 2010 à 12:25 (CET)
<Maudite Edith> Oui, la documentation est à compléter, mais vos questions sont très utiles pour cela Clin d'œil.
Le point clé, c'est que ce n'est qu'un outil d'assistance à la vérification. Il n'est pas possible de tout faire vérifier automatiquement, car une partie de ce qu'il faut évaluer nécessite une réflexion « humaine ». L'outil aide en validant ce qu'il peut et en mettant en évidence le reste :
  • du vert signifie que le code ne contient pas d'erreurs (qui soient automatiquement vérifiables)
  • du rouge signifie présence d'une erreur certaine (parmi celles qui sont automatiquement vérifiables)
  • du orange signifie : là, vous avez quelque-chose à regarder vous-même, l'outil ne peut pas trancher. C'est notamment le cas des tableaux des sections « morphologie » et « standard » de Oie flamande qui ne comportent aucun élément ou attribut d'accessibilité (pas d'en-têtes de colonne et de ligne, pas de titre, etc.) mais qui pourraient très bien être des tableaux de mise en forme inoffensifs (comme la TOC). Dans ce cas, seul l'évaluateur est à même de trancher et de décider s'il s'agit de tableaux de données qui doivent être corrigés (c'est le cas dans cet article).
Parmi les améliorations, il faut que j'ajoute un message en orange pour chaque tableau de ce type disant quelque-chose comme « Vérifier par vous-même s'il s'agit bien d'un tableau de mise en forme ou si le code doit être corrigé ».
Cordialement, --Lgd (d) 13 novembre 2010 à 12:44 (CET)

J'aime beaucoup ce gadget, un grand bravo. Deux pistes pour le fignoler :

  1. C'est très bien de pouvoir tout désactiver en un clic. Mais souvent, j'aimerais surtout pouvoir tout activer d'un clic, pour se faire une idée générale de l'article rapidement.
  2. Si j'évalue une série de pages, ce qui va se faire avec les projets intéressés (Hockey par exemple) et les labellisations, j'aimerais bien que les options cochées le restent d'une page à l'autre. Via un cookie, par exemple, comme pour le menu de gauche. Mais c'est peut-être pas tout simple à faire. Amicalement, Dodoïste [ dring-dring ] 13 novembre 2010 à 16:01 (CET)
  1. C'est justement ce qui me cassait les pieds en prévoyant la demande. Pas de chance pour moi, mais c'était prévisible Mort de rire. Plus sérieusement, mon souci est que ça va vite devenir illisible, le résultat d'une option "tout cocher". Ça peut se résoudre très facilement avec une CSS unique et des @import, puisque tout consiste à appliquer des CSS donc le souci n'est de développer, c'est plutôt l'utilité.
  2. Vi, là toutafé. Mais pour le coup, si tu coches une série de tests sur la première page et que ton choix est conservé sur les suivantes, ta demande précédente en prend un coup dans les dents de son indispensabilité, non ?
    Sinon, le coup des options cochées conservées via un cookie, ça me stimule aussi sur une autre idée que j'avais mais pas urgente : décliner en deux versions (basculables d'un petit clic une fois le gadget activé) : interface et fonctionnalités avancées v. machin simple pour tout le monde (via un autre cookie).
Bon, jusque-là, ça va : les rares gens sont contents et on n'en est pas encore trop à prévoir de le transformer en usine à gaz Mort de rire.Cordialement, --Lgd (d) 13 novembre 2010 à 16:20 (CET)
Oui, si la n°2 est choisie, la n°1 est moins nécessaire, et inversement. Désolé de pas l'avoir dit clairement. :p Dodoïste [ dring-dring ] 13 novembre 2010 à 17:56 (CET)
Fait Les tests cochés sont à présent conservés de page en page Reste à optimiser le code du gadget. --Lgd (d) 17 novembre 2010 à 11:55 (CET)
En outre, serait-il envisageable en modifiant le gadget et/ou son « Monobook » (ou toute autre page CSS/JS/autre méthode rattachée à son compte Wiki ou à la rigueur via un cookie stocké localementmais c’est moche comme façon de procéder, et assez peu pratique pour ceux qui n’utilisent pas systématiquement le même poste de travail) de faire en sorte que l’outil d’accessibilité soit, pour ceux qui le désirent, par défaut en mode « épinglé » plutôt que devoir cliquer sur le lien « Fixer » à chaque fois ? Merci d’avance. (note : je n’ai lu qu’en diagonale avant de poster, désolé si cela aurait déjà été évoqué…)MetalGearLiquid [m’écrire] 15 novembre 2010 à 14:17 (CET)
Je viens de bouger pas de choses sur un nouveau test à propos des alternatives textuelles, mais la prochaine étape sera (en principe) ces questions de tests choisis et de « fixé choisi » conservés quand on passe de page en page. Cordialement, --Lgd (d) 16 novembre 2010 à 13:46 (CET)
Fait pour le mode épinglé, à présent mémorisé par un cookie (rechargez le cache du navigateur). Cordialement, --Lgd (d) 17 novembre 2010 à 06:56 (CET)
Testé, très pratique. :-) Dodoïste [ dring-dring ] 17 novembre 2010 à 20:33 (CET)
Ce qui est bien, c'est qu'on repère vite les utilisateurs ce certains tests Mort de rire --Lgd (d) 17 novembre 2010 à 20:50 (CET)
Grillé ! :D Mais ça montre deux choses. Premièrement que les tests sont efficaces (très efficaces). Ensuite, depuis que tu as mis ce cookie, j'ai toutes les options cochées par défaut, tout le temps. Cela défigure la page, mais le nombre d'informations à la seconde est impressionnant, c'est bigrement utile. Un grand bravo donc, c'est une réussite. Dodoïste [ dring-dring ] 17 novembre 2010 à 21:01 (CET)
Merci Clin d'œil - certes ça « défigure » (l’ajout d’une ou plusieurs espaces après le cadre de langue est-il requis ?), mais dorénavant, puisqu’il mémorise le statut (fixé dans mon cas), il n’est guère difficile de passer d’un mode « lecture en tant qu’utilisateur lambda » au mode « éditeur/wikificateur », et ça marche aussi bien lors d’une simple consultation d’un article que lors de l’affichage de prévisualisation… Tester c’est l’adopter ! Clin d'œilMetalGearLiquid [m’écrire] 24 novembre 2010 à 10:51 (CET)

lang (encore)[modifier | modifier le code]

Je sais, je suis casse-bonbons, mais quitte à faire les choses, autant les faire bien. Mon ami TaraO (d · c · b) a pondu un paragraphe qui me pose soucis... Au niveau accessibilité les noms propres ne doivent pas avoir d'indication de changement de langue ? Donc, où doit-on mettre l'indication et où ne doit-on pas ? (si quelqu'un veut jeter un oeil au paragraphe en question). D'autre part, si les noms propres ne doivent pas être indiqués, le nom complet de la mascotte devrait-il s'écrire Blades ''{{lang|en|the Bruin}}'' voire même (j'abuse là...) Blades ''{{lang|en|the}}'' Bruin ou alors pas d'iincation du tout si on considère que « Blades the Bruin » est un nom propre ? --'toff [discut.] 12 novembre 2010 à 21:14 (CET)

Concernant les noms propres, ce n'est pas qu'on ne doit pas indiquer le changement de langue, c'est qu'on peut ne pas le faire. Le point déterminant est « est-ce qu'il sera compréhensible ou reconnaissable s'il est prononcé à la française » (hors cas particulier où il aurait une prononciation « française » originale et entrée dans les usages).
Pour « Blades the Bruin », je mettrai le changement de langue sur le nom complet, et aussi sur les occurrences suivantes de « Blades » afin de conserver une lecture cohérente. Cordialement, --Lgd (d) 12 novembre 2010 à 21:32 (CET)
Fait pour les occurrences suivantes. par contre, est ce que je dois en mettre sur certains des mots de « Les autres noms possibles sont : Bruno, Buster, Stanley Cub, Spokey, Bruiser, Checkers, Power Paws, Buddy et Hub Cub » ? (je dirais non mais je suis pas sûr) --TaraO (d) 12 novembre 2010 à 22:24 (CET)
Toujours la même chose : qu'est-ce que ça va donner une fois prononcé ? Dans le doute, un changement de langue de plus n'est pas dommageable. Cordialement, --Lgd (d) 13 novembre 2010 à 12:48 (CET)

Amorce de palette et de choses déroulantes[modifier | modifier le code]

Bonjour,
Étant un peu en forme, j'ai plié un bon début de refonte des palettes de navigation et autres menus déroulants, rendus accessibles et mieux faits côté code (d'irréprochables listes imbriquées sans aucun affreux tableau de mise en forme). Avant que je ne continue éventuellement, une question clé : y a-t-il des courageux prêts à envisager l'inévitable PDD du siècle proposant le remplacement une fois la chose finalisée ? C'est à dire :

  1. Des gens pour tester et faire remonter les retours avant le lancement de la PDD ?
  2. Des développeurs chevronnés du jQuery pour optimiser mon bricolage (d'habitude, je pilote des développements jQuery, mais je n'ai pas le droit d'y mettre la main, à vrai dire) ?
  3. Des praticiens de la discussion préparatoire d'avant PDD pour expliquer ?
  4. Des dresseurs de bots d'après adoption de la PDD pour bouger ce qui est botabougeable ?
  5. Des fourmis prêtes à remuer les articles, modèles etc. intraitables sauf à la main ?

Si un nombre raisonnable de ces conditions peut être remplies, je continue et je commence par vous mettre ça dans le common.js etc. pour que tout le monde puisse tester. Cordialement, --Lgd (d) 13 novembre 2010 à 17:39 (CET)

Je suis volontaire pour les N°1 et 3. :-) Dodoïste [ dring-dring ] 13 novembre 2010 à 17:52 (CET)
Modeste volontaire dans la mesure de mes faibles compétences informatiques. Il faudrait recruter des adeptes de l'accessibilité du côté du Projet:Informatique Clin d'œil. --Amicalement, Salix ( converser) 13 novembre 2010 à 19:13 (CET)
(Smiley) Hum... Mort de rire Si je peux servir à quoi que ce soit étant donné mon incompétence technique notoire mais ma bonne volonté… tu n’as qu’à appeler. Je te dois au moins ça ! Clin d'œil --Égoïté (d) 13 novembre 2010 à 23:42 (CET)
Je veux bien donner un coup de main, par exemple pour 1 et 5, mais il faudra me donner plus de détails sur ce qu'il y a à faire... Sourire Peter17 (d) 14 novembre 2010 à 00:01 (CET)
Je ne voudrais pas faire mon rabat-joie, mais il serait bien d'avoir au moins un aperçu de ce qui est proposé... od†n [dead words] 15 novembre 2010 à 15:22 (CET)
Il arrive très bientôt (sous la forme d'un gadget temporaire, ce sera mieux que de modifier le common.js directement et plus simple que des vector/monobook.js personnels à bidouiller). Je vais tâcher de faire ça d'ici demain, pour que vous puissiez commencer à tester et à faire des retours. Cordialement, --Lgd (d) 15 novembre 2010 à 15:56 (CET)
Fait Deaune.
Pour tester : allez dans vos préférences, onglet Gadgets, activez le gadget New collapsible box dans la section « Outils avancés  ». Eventuellement, rechargez le cache de votre navigateur (Firefox, Safari : maintenez la touche Majuscule (Shift) en cliquant sur le bouton Actualiser (Reload) ou pressez Maj-Ctrl-R (Maj-Cmd-R sur Apple Mac) ; Internet Explorer, Opera : maintenez la touche Ctrl en cliquant sur le bouton Actualiser ou pressez Ctrl-F5)
Pour un aperçu des modèles de boîtes déroulantes et de palette, voir Utilisateur:Lgd et les modèles :
Dans l'immédiat, je serai surtout preneur :
  • des jets divers de tomates, choux et patates, bien-sûr ;
  • de vos retours sur la boîte déroulante (et ses limites volontaires Clin d'œil : par exemple, elle n'est imbriquable dans elle-même, pour éviter des abominations ergonomiques).
Cordialement, --Lgd (d) 15 novembre 2010 à 17:06 (CET)
Ça m'a l'air intéressant... quelques premières observations en vrac :
  1. Comme je m'y attendais Mort de rire les puces sont trop grosses, il faudrait que le rendu soit plus proche que ce que nous avons actuellement.
  2. Il ne faudra pas qu'il y ait de puce après le dernier élément, cela va de soi.
  3. Pour les liens de type "v • d • m" à gauche, je me dis que finalement un seul lien serait suffisant, celui vers la page du modèle. Les liens directs "discussion" et "modifier" sont pas utiles, ils surchargent et ils sont même un peu déroutants.
  4. Ça serait bien de pouvoir empiler les palettes sans bordure, comme on a actuellement avec {{Palette}}
  5. Un truc que je trouve un peu gênant, c'est quand l'enroulage, quand le scroll de la page est tout en bas, fait se déplacer la page vers le haut, si vous voyez ce que je veux dire ? Ça serait génial si on pouvait améliorer ça, c'est-à-dire que ce qui est au-dessus des palettes ne bouge pas, quelle que soit la situation. Bon, le problème est déjà présent avec les palettes actuelles, serait un peu délicat techniquement à résoudre, et je ne pense pas que ça soit une priorité.
  6. Du point de vue de l'accessiblité, serait-il acceptable de mettre un "onfocus:blur()" sur le lien "dérouler" ?
  7. Donner des possibilités de configuration, pour ceux qui le veulent. Je pense au lien "dérouler", qui serait au choix juste à côté du titre comme tu le proposes (j'aime bien) ou alors tout à droite (comme c'est le cas avec les palettes actuelles). J'aimerais bien aussi la possibilité de pouvoir dérouler la palette en cliquant n'importe où sur l'entête (sauf bien sûr le titre si c'est un lien), éventuellement proposer ça sous forme d'un gadget optionnel.
On devrait déjà avoir de quoi faire avec ça Mort de rire  – Cordialement, od†n [dead words] 15 novembre 2010 à 17:46 (CET)
Peut-on rester concentré sur les boîtes déroulantes, dans un premier temps Clin d'œil ? Même si certains de ces retours s'y appliquent, laissons les palettes de côté pour l'instant sur les détails, comme expliqué plus haut.
Sinon, pour l'immédiat: le point 6 est exclu. La première phrase du 7 aussi (l'idée générale est justement de supprimer une très large partie de la personnalisation inutile et néfaste). La seconde est par contre très bien vue. Cordialement, --Lgd (d) 19 novembre 2010 à 21:40 (CET)
Le lien dans l'en-tête de la palette est effectivement très ennuyeux. Dans l'idéal, il ne devrait pas y en avoir, ce qui permettrait de mettre le bouton déroulant directement sur l'en-tête, accompagné de la jolie flèche. Du point de vue de l'accessibilité comme de l'ergonomie, ce serait le top. Mais peux-t'on seulement espérer arriver à ce résultat, en connaissant les réticences que peuvent montrer les rédacteurs ? Dodoïste [ dring-dring ] 20 novembre 2010 à 15:08 (CET)
J'étais parti initialement sur cette idée où l'en-tête n'est pas un lien WP et où elle remplace le « enrouler/dérouler » actuel. Puis, j'ai laissé de côté et je suis revenu au comportement actuel (le « enrouler/dérouler » à côté de l'en-tête) qu'il va falloir conserver de toutes façons : l'usage est non seulement fortement ancré mais surtout nécessaire dans beaucoup de cas (Il ne pose d'ailleurs plus de problème d'accessibilité dans ma version, les liens « enrouler/dérouler » étant à présent explicites hors contexte).
Bien-sûr, on pourrait réintroduire ce comportement (l'en-tête remplace le « enrouler/dérouler ») de manière transparente pour les cas où il n'y a pas de lien. Mais on aurait alors deux interfaces différentes pour une même fonctionnalité, ce qui n'est pas recommandable. D'un autre côté, en vrai, on a déjà ce double interface si on prend en compte le menu de gauche, alors un peu plus un peu moins...
Question ouverte, donc, et avis bienvenus Clin d'œil. Cordialement, --Lgd (d) 20 novembre 2010 à 15:53 (CET)
Nous avons fait la même réflexion, et sommes arrivés à la même conclusion.
Ensuite, une solution envisageable serait de déplacer le lien ailleurs dans le modèle, lorsqu'il est nécessaire. Ce qui permettrait d'éviter la confusion entre le lien « enrouler/dérouler » et le lien vers un article. Mais à mon avis, c'est loin d'être gagné d'avance, et ce n'est pas à prévoir tout de suite. Mieux vaut lancer l'amélioration la plus importante et consensuelle d'abord, et ensuite fignoler le risqué si on le sent bien. Dodoïste [ dring-dring ] 20 novembre 2010 à 16:52 (CET)

nouvelle infobox[modifier | modifier le code]

Bonjour. Pourriez-vous vérifier Modèle:Infobox Mets car certains contributeurs commencent à l'utiliser. D'autre part, peut-on distinguer les langues dans une infobox ? Merci déjà, --Égoïté (d) 14 novembre 2010 à 13:46 (CET)

  1. Elle a les défauts minimaux des infobox, sans rien d'urgent à y retoucher pour l'instant (c'est le code global des infobox qu'il faudra modifier plus tard pour aller plus loin).
  2. Pas sûr de bien capter la question, mais on peut faire au cas par cas dans chaque article | ingrédients = {{lang|de|Düsseldorfer Löwensenf}} par exemple. Cordialement, --Lgd (d) 14 novembre 2010 à 15:05 (CET)
Ok merci. --Égoïté (d) 14 novembre 2010 à 15:40 (CET)

Alt - gadget[modifier | modifier le code]

Bonsoir LgD. Tu ne pourrais pas ajouter à ton gadget la possibilité de visionner les alt comme on visionne les Lang ? (Suis paresseuse, moi, c’est connu Clin d'œil --Égoïté (d) 15 novembre 2010 à 18:58 (CET)

C'était LA question que j'espérais ne pas voir poser Mort de rire, mais on va le faire, inévitablement (Pour expliquer: le gadget recourt à une technique très légère et facile à faire évoluer - le full CSS -, mais qui a ses limites ici ou là. Elle ne permet pas de faire un truc apparemment aussi simple que de visionner les alt, alors qu'elle permet de visionner beaucoup d'autres choses. Pour aller plus loin, certaines fonctionnalités devront recourir à un peu plus de javascript. Ce n'est pas un souci, c'est juste que, de mon point de vue, ça n'est pas élégant). Bref, j'ajoute ça sur la todo à court terme du gadget en plus du « Fixer » qu'on peut conserver de pages en pages. Cordialement, --Lgd (d) 15 novembre 2010 à 19:06 (CET)
Merci déjà (air connu) ; tu confirmes ainsi l’opinion (aimable !) que certains ont de moi : la BdM (branleuse de mouche) ! Mort de rire Je me demande si Gilles n’a pas déjà trouvé un gadget pour ça, tout compte fait ? Je lui demanderai… tantôt — les jeunes, faut les laisser dormir. Pour l’élégance…, oui mais pardonne-moi : le temps passé à comparer les articles en mode édité et en mode source, pour être réellement efficace, il n’est pas négligeable… Bisous, --Égoïté (d) 16 novembre 2010 à 00:34 (CET)
Fait C'est fait. Rafraîchir le cache du navigateur (air connu) pour bénéficier du test affichant les alternatives textuelles des images. Du coup, je vais sans doute améliorer les autres tests en y mettant ici ou là un zest de javascript supplémentaire, tiens Clin d'œil. Cordialement, --Lgd (d) 16 novembre 2010 à 08:08 (CET)
Glub ! Merci Lgd ! Bisou, mais peux-tu m’expliquer pourquoi on lit « alt vide » alors qu’il y a un texte comme dans boite de conserve ? et pourquoi 2 alt vide dans Lancelot de Casteau Là, je le comprends pour l’une puisqu’il n’y a pas de texte alt, mais pour l’autre ? --Égoïté (d) 16 novembre 2010 à 10:43 (CET)
Hum... Ah : dans chaque image en thumb, outre l'image elle-même, il y a la petite icône de loupe (générée par Mediawiki, tu n'y peux rien) qui est mal faite et qui génère donc une alerte. Mais je vais l'enlever de la détection, il est inutile que ça confuse tout le monde puisque les contributeurs n'y peuvent rien. Bouge pas, le temps que je fasse deux ou trois erreurs de syntaxe javascript et c'est réglé Mort de rire ... Cordialement, --Lgd (d) 16 novembre 2010 à 10:52 (CET)
Fait Voilà, les alertes liées aux loupes ont disparu (recharger as usual). Au passage, il fait aussi « tilt » quand il rencontre une image pas en thumb qui devrait avoir un link vide, ce qui est bien (voir le bandeaux d'AdQ en bas de page, par exemple, ou les images dans les infobox). Cordialement, --Lgd (d) 16 novembre 2010 à 11:07 (CET)
Impec ! Merci i n f i n i m e n t. --Égoïté (d) 16 novembre 2010 à 11:25 (CET)
P.S. Je l’ai signalé sur la PdD du jury WCC. --Égoïté (d) 16 novembre 2010 à 11:34 (CET)
J'ai re-bougé pour que les alertes soient plus intuitives (enfin, je l'espère Mort de rire et pour détecter des soucis d'images supplémentaires (Là, c'est un peu une « tuerie », comme disent mes jeunes collègues). Donc, ne pas hésiter à actu... Au passage, j'ai ajouté des alertes en cas d'utilisation de galeries et de frises chronologiques (timeline). NB pour moi : regarder pour une éventuelle alerte sur {{Images}} et ce genre de choses. Cordialement, --Lgd (d) 16 novembre 2010 à 13:49 (CET)

Euh, c'est moi ou ça ne fonctionne plus ? --'toff [discut.] 17 novembre 2010 à 16:43 (CET)

Hum... Non, tout fonctionne. Peut-être un problème de mise à jour ? (recharger le cache du navigateur). Ah, en effet, il y a un problème uniquement sous monobook (tout va bien sous vector). Je vais réparer ça... --Lgd (d) 17 novembre 2010 à 17:00 (CET)
Fait rapidement patché (recharger le cache du navigateur). Cordialement, --Lgd (d) 17 novembre 2010 à 17:53 (CET)
Merci (effectivement, je ne suis pas sous vector). Ca refonctionne. --'toff [discut.] 17 novembre 2010 à 23:55 (CET)

Bonjour, et merci pour cet outil. Quelques questions :

  • « L'utilisation des timelines réduit l'accessibilité » ← C’est pas un exagéré/simpliste ? J'y connais rien, mais avais cru comprendre qu’un problème d'accessibilité c’est quand une part des visiteurs est désavantagée. Sur Star Wing (arf, faut que je lui fasse ses alt à lui), la timeline est un plus graphique, tout est dans le texte. J’ai un peu l’impression de me faire agresser par l’outil ! :-)
  • « Ce tableau devrait avoir un titre caption » sur n’importe quelle infobox : c’est pas inhérent aux infobox ? Que peut-on faire pour arranger ça ?
  • +/- idem pour les palettes héritant de {{Méta palette de navigation}}.
  • L’alerte pour les images pas thumb en infobox : quelle est la marche à suivre ?
    Et que fait-on des images comme les drapeaux (Drapeau de la France France et Flag of France.svg par exemple) ? Jean-Fred (d) 17 novembre 2010 à 21:12 (CET)
    Bonne question, car le gadget signale "link=" manquant et "alt=" manquant, alors que Mediawiki fournit déjà les deux informations de la bonne façon dans le HTML généré sans utiliser ces attributs nommés. Je pense que la suggestion est dangereuse, car elle va conduire plein de monde à mettre des "link=" partout sur toutes les images, et ensuite on va se plaindre qu'on n'a plus accès aux pages de description des images (et donc plus accès aux infos sur le droit d'auteur mentionnant les attributions obligatoires selon nombre de licences (dont la quasi-totalité des images libres, sauf celles du domaine public et celles où ce n'est pas nécessaire quand le copyright général su site suffit comme les logos des sites la Fondation Wikimedia) !
    J'étais plutôt opposé à l'attribut "link=" dur les projets MediaWiki (avant on avait "lien sur image", moins propre mais qui fournissait une catégorisation pour en limiter l'usage, mais la solution actuelle avec "link=" supprime cette catégorisation, et ne permet plus le suivi). On va donc avoir des problèmes avec le droit d'auteur, mais aussi un problème pour lier à une images plus grande et décrite plus complètement pour ceux qui ne supportent pas la taille par défaut insérée dans les pages du wiki. La question n'a pas été réglée, mais imposer "link=" sur toutes les images est à mon avis une erreur ! En tout cas ce n'est pas du tout une question d'accessibilité, puisque cette solution avec "|link=" et "|alt=" en fait 'réduit l'accessibilité des images. Pour moi, c'est carrément contre-productif (et en opposition avec la charte de Wikipédia qui impose de mentionner les sources et licences, et on n'aurait pas du en faire la publicité). Verdy p (d) 19 novembre 2010 à 12:04 (CET)
    Wikipédia:Crédits graphiques n'existe pas pour rien. Et le reste de ton message est plutôt H.S, mais on est pas à ça près si je comprends bien. Dodoïste [ dring-dring ] 19 novembre 2010 à 18:27 (CET)
  • Désactiver le gadget hors main ? Vu qu'il semble persister, c’est un peu lassant sur les pages de discussion :-)
  • Ai réglé son compte au link de {{Bon article}}, un sysop pour faire de même à {{Article de qualité}} ?
Tout à fait d'accord, il faudrait uniformiser {{Bon article}} et {{Article de qualité}}  – od†n [dead words] 17 novembre 2010 à 21:24 (CET)
Bonjour,
Tout d'abord, merci pour vos retours, qui permettront d'améliorer l'outil.
  1. Timeline : le message est en effet un peu brutal, mais le problème est lourd. Je vais voir si on peu améliorer la formulation de l'alerte (tout en restant concis) et surtout je vais documenter la bonne pratique sur les timeline encore en chantier.
  2. Alertes à propos des infobox et des palettes: les infobox et les palettes sont, de fait, entièrement à recoder. Certes, les contributeurs n'y peuvent pas grand-chose dans l'immédiat, mais le fait que l'outil mette en évidence le problème (là aussi, lourd) me semble nécessaire. Enfin, côté palette, une refonte est amorcée (voir plus haut). Après, on pourra passer aux infobox si cela ne déclenche pas une IIIe guerre mondiale...
  3. Images pas en thumb et drapeaux : je vais compléter la documentation du modèle, et fournir un petit lien dans les alertes pour qu'on puisse aller directement consulter l'aide appropriée.
  4. Désactiver le gadget hors main : il y a aussi des gens qui l'utilisent pour tester des pages hors main et les améliorer. Par ailleurs, les tests ne sont pas destinés à être activé en permanence. Cela dit, si c'est vraiment une demande massive, on peut exclure uniquement les pages de discussion.
Cordialement, --Lgd (d) 19 novembre 2010 à 07:33 (CET)
Personnellement je préfère que le gadget soit valable pour toutes les pages et ne pas l'activer tout le temps. Pourquoi les pages d'aide, les règles et les ateliers de Wikipédia se dispenseraient-ils d'accessibilité, même si c'est moins grave ? Et puis on peut aussi avoir besoin de tester un modèle en pdd avant de le mettre dans le main, non ? --Amicalement, Salix ( converser) 19 novembre 2010 à 20:00 (CET)
+1 avec Salix, --Égoïté (d) 21 novembre 2010 à 13:49 (CET)
Idem, et à la rigueur si certains aimeraient que le gadget soit systématiquement activé sur main et d’office désactivé ailleurs, il devrait bien y avoir moyen de leur indiquer la marche à suivre (éditer le cookie ? - pour ma part, cela serait sans doute pour l’espace « Spécial: » afin de ne plus affecter la liste de suivi par exemple, pour d’autres ce serait probablement les pages de discussion, etc.) pour leur donner satisfaction… (pour autant que ce ne soit pas trop chronophage de ton côté pour leur offrir cette souplesse) Au passage, serait-il envisageable d’ajouter à côté de « Tout désactiver » l’option inverse pour tout activer d’un seul clic ? Je suppose que ça pourrait intéresser certaines personnes… — MetalGearLiquid [m’écrire] 24 novembre 2010 à 11:02 (CET)
Je résiste, je résiste, mais je vais bien finir par devoir céder pour le bouton « tout activer » Mort de rire. Cordialement, --Lgd (d) 24 novembre 2010 à 12:34 (CET)

Bug gadget vérification alt[modifier | modifier le code]

Bonjour. J'ai considéré hier comme erreur grave le fait de donner une fausse localisation dans la carte de l'infobox des communes de France (version2) ; voulant montrant ça à un ami, je me suis retrouvée avec une localisation correcte ; j'étais pressée, je me suis dit qu'on avait corrigé. Ce matin, je prends mon temps, vérifie, vois qu'il n'y a pas eu de correction et me demande s'il y a une différence sous Ubuntu et sous Windows. Bref, vérificationS faiteS : c'est le gadget pour la vérification des alt qui "déplace" le point rouge de localisation. Exemples : Vitry-le-François et Sainte-Menehould (dans le WCC) ou Saint-Dizier (hors WCC). Sans activer le gadget, ces communes sont localisées en France. En l'activant, elles sont localisées en Belgique ! Bisous, --Égoïté (d) 21 novembre 2010 à 08:01 (CET)

Pour les curieux : la même chose se produit avec les outils classiques de test d'accessibilité (la Webdev toolbar par exemple). Cela vient du système utilisé pour « placer » ces points sur les cartes : le point n'est pas placé en référence à la carte, mais en référence au bloc qui contient le tout. Quand le message d'alerte est ajouté dans ce bloc, il fait « glisser » la carte vers le bas, mais le point ne bouge pas.
On peut peut-être corriger sans introduire une exception trop lourde dans le script. Je teste dans ma version et je l'incluerai dans la prochaine mise à jour si cela n'a pas d'autres effets de bords.
Merci pour le retour ! Cordialement, --Lgd (d) 21 novembre 2010 à 08:47 (CET)
Bon : mon correctif marche très bien... pour les cartes pas trop mal codées. C'est déjà ça.
Pour les éventuels courageux du code : certains modèles comme Modèle:Fragéoloc (dans Buzy par exemple) ne donne aucune classe au div conteneur de la carte et de son point de localisation, ce qui le rend impossible à atteindre via une CSS externe. Il faudrait dans l'absolu corriger tout ces modèles en y ajoutant la classe geobox sur le div conteneur de la carte, en s'assurant que cela n'a pas d'effets inattendu dans d'autres modèles de géolocalisation utilisant le premier de manière encore inattendue...
<mode screugneugneu radoteur>En vrai, il faudrait euthanasier tout ce fichu système bricolé de points sur des cartes et le remplacer par quelque-chose de propre, par exemple à base d'une API type GoogleChart Clin d'œil</screngneugneu>
--Lgd (d) 21 novembre 2010 à 10:39 (CET)

Alt galeries[modifier | modifier le code]

Grâce au gadget dont question à la section ci-dessus, je trouvé la page "votez" et j'ai laissé un mot. Ce serait bien que d'autres y laissent aussi un commentaire parce que c'est assez vide jusqu'à présent... Amclt, --Égoïté (d) 21 novembre 2010 à 08:07 (CET)

Merci.
Au passage, pour d'autres contributeurs : il suffit (après s'être connecté en ayant créé un compte le cas échéant) d'utiliser le lien « vote » en début de page, dans la ligne « Importance: Normal major with 3 votes (vote) ». Cela évite de multiplier les commentaires et cela peut aider si on ne pratique pas la langue shakespearo-bugzilienne Clin d'œil. Cordialement, --Lgd (d) 21 novembre 2010 à 09:30 (CET)
et pour voter, il faut cliquer sur le petit carré puis sur " change my vote" ce qui est bizarre puisqu'on n'a rien à changer au départ... Clin d'œil --Égoïté (d) 21 novembre 2010 à 13:48 (CET)

Gadget[modifier | modifier le code]

Salut. Question de fainéant. Il y a moyen de tout désactiver d'un seul coup mais pas de tout activer d'un seul clic. Ça serait possible ? --'toff [discut.] 21 novembre 2010 à 20:27 (CET) Bien sur ! Des que tu active beaucoup de choses , à gauche tu as tout desactiver du cous , sa supprime !--MiniRobot 3 décembre 2010 à 20:42 (CET)

Cela a déjà été proposé ci-dessus, et considéré non nécessaire depuis que les options activées restent en mémoire (cookie). Et apparemment, c'est moins simple à faire. Mais c'est quand même amusant de pouvoir tout désactiver quoiqu'il arrive, même quand... tout est déjà désactivé. :D Dodoïste [ dring-dring ] 21 novembre 2010 à 20:54 (CET)
Pfff... pu moyen d'être fainéant... Clin d'œil --'toff [discut.] 21 novembre 2010 à 21:32 (CET)

Une autre question : je suis toujours sous l'ancienne version de wikipédia (pas passé à Vector...). Du coup, quand je fixe le gadget, il se positionne en haut à gauche sur le logo de WP mais il cache le champ de recherche. Pour pouvoir rechercher un article, il faut que je "défixe" le gadget. Ne pourrait-il pas se fixer à l'endroit où il se trouve d'origine (plus bas quoi) ? --'toff [discut.] 22 novembre 2010 à 04:27 (CET)

Ok, c'est noté pour la prochaine mise à jour (fixé à l'endroit initial ou bien repliable comme sous vector). Cordialement, --Lgd (d) 22 novembre 2010 à 05:44 (CET)
Merci. --'toff [discut.] 22 novembre 2010 à 06:36 (CET)

Une politique pour les petits drapeaux[modifier | modifier le code]

Bonjour,
Planter un si beau marronnier de bon matin, voilà qui est rafraîchissant Clin d'œil.

Plus sérieusement : les icônes de drapeaux posent (cf les retours du gadget accessibilité) un évident et lourd problème :

  • une grande partie d'entre eux, (souvent directement saisis dans les articles, mais aussi parmi ceux générés via des modèles) sont dénués d'alternative textuelle.
  • quand il y a une alternative désignant uniquement le pays (« alt=France »), elle ne convient pas. Dans {{FRA-d}} Drapeau : France par exemple, le libellé est ambigu pour cette icône : rien n'indique immédiatement que le lien sur l'icône ne vise pas l'article France mais la page de l'image Fichier:Flag_of_France.svg. Avec le modèle {{FR}}, c'est encore plus amusant puisque cela donne Drapeau de la France France c'est à dire grosso modo France France
  • quand il y a une alternative désignant explicitement le drapeau (« alt=Drapeau de la France ») comme dans {{drapeau|France}} Drapeau de la France, c'est déjà mieux.
  • il ne semble finalement pas possible de désactiver les liens sur ces icônes, vu le problème d'accès à la mention des auteurs et à la licence (la page Wikipédia:Crédits graphiques serait dépassée ou ingérable, et quelque chose comme ceci ne sera certainement pas accepté).

Donc, proposition de politique :

  1. Systématiser la classe flagicon déjà présente dans le modèle {{Country flag2}} et à travers lui dans tous les modèles de la catégorie Catégorie:Modèle Country data : elle n'a aucun effet sur le rendu, mais elle permet d'identifier spécifiquement les drapeaux à des fins de traitement. Par exemple, le gadget accessibilité pourrait s'en servir pour décliner un test plus adapté pour les drapeaux, qui ne hurle plus à propos du link puisqu'il faut conserver celui-ci.
  2. Pour les alt, systématiser les alternatives de la forme « Drapeau de... ». Si la classe flagicon est présente, le gadget pourra faire une alerte sur ce point.

(Tout à fait volontairement, cette proposition s'abstient de prendre position pour ou contre les petits drapeaux ici où là, ce n'est pas notre problème Clin d'œil.)

Cordialement, --Lgd (d) 22 novembre 2010 à 07:46 (CET)

Bon, en imaginant que je suis un boulet (perso, je m'imagine très bien vue que ça correspond à la réalité ! Clin d'œil ), et que j'ai pas tout compris, je fais quoi avec ça :
[[Fichier:Municipal Flag of Chicago.svg|20px|drapeau chicago]] [[Chicago]],<br />{{Illinois}},<br />{{États-Unis}} --'toff [discut.] 22 novembre 2010 à 08:13 (CET)
  • Tout à fait d'accord pour la classe et le alt. En plus cela ne devrait rencontrer aucune doléance opposition, alors ne nous privons pas. Par contre pour les licences des images, il ne faudrait pas baisser les bras tout de suite, il y a peut-être des solutions ? Ça serait dommage ne pas essayer.
  • 'toff, je suis pas sûr d'avoir compris la question Mort de rire Mais je peux te dire que les modifications ne changeraient rien à l'utilisation pour les contributeurs. C'est ce que tu voulais savoir ?
od†n [dead words] 22 novembre 2010 à 08:23 (CET)
En gros, c'est ça : quand un contributeur intéressé par le gadget voit les alt et link manquant sur les drapeaux, que doit-il penser ? Si c'est : surtout, t'en fait pas, touche à rien, c'est pas intuitif mais je vais répercuter auprès de mes collègues du projet hockey. --'toff [discut.] 22 novembre 2010 à 08:34 (CET)
Si j'ai bien compris, et que l'idée suit son cours, le gadget reconnaîtra les drapeaux et sera capable de ne pas asséner d'avertissements s'il n'y a pas lieu de le faire Clin d'œil od†n [dead words] 22 novembre 2010 à 08:48 (CET)
@od†n : Voilà... (C'est implémenté dans ma version de dev, en fait). Cordialement, --Lgd (d) 22 novembre 2010 à 09:17 (CET)
@'toff : Évidemment, tu nous sors le cas casse-pied où le drapeau est directement dans l'article au lieu de passer par un beau modèle genre {{drapeau}} Mort de rire
Bon, dans ce cas, yapa : il faut créer le modèle {{drapeau|Chicago}} qui donne un beau Drapeau de Chicago (comme je viens de le faire) et ensuite l'utiliser dans les articles à la place du [[Fichier:Municipal Flag of Chicago.svg|20px|drapeau chicago]].
Pour la création des modèles, si besoin, demander ici ou sur le Projet:Modèle (Pour {{drapeau|Chicago}}, j'ai fais ça sans doute comme un cochon en créant Modèle:Country alias Chicago et Modèle:Country flag alias Chicago : le système des Country data a l'air plus perfectionné que ça, mais il est imbuvable, apparemment, il faut créer Modèle:Country data Chicago, puis à partir de là Modèle:Country alias Chicago et Modèle:Country flag alias Chicago C'est imbuvable, mais bon). Cordialement, --Lgd (d) 22 novembre 2010 à 09:17 (CET)
Pitié, Projet:Modèle/Demandes est déjà saturé Mort de rire Et sinon, pour la reconnaissance des drapeaux, le gadget pourrait faire des regex du genre « \[\[[fichier|file|image].*flag of.* etc. » Comment ça, ça serait barbare comme solution ? meu non voyons. od†n [dead words] 22 novembre 2010 à 09:25 (CET)
Pitié, pas de regex Mort de rire --Lgd (d) 22 novembre 2010 à 09:39 (CET)
Pour le point 2 de la politique des petits drapeaux, j'ai corrigé un gros paquet de modèles en erreur avec une solution simple qui évite le piège de la gestion des « Drapeau de Truc », « Drapeau de la Chose » et autres « Drapeau du Bidule » : alt=Drapeau : Truc
Ne pas hésiter à faire de même dans des cas similaires pour faire avancer le bouzin Clin d'œil Oui, j'ai bien mis l'espace avant et après le deux-points, la sacro-sainte typographie est sauve, mais non, on ne va pas y mettre une espace insécable, faut pas pousser. Cordialement, --Lgd (d) 22 novembre 2010 à 20:27 (CET)
Une espace insécable dans une alternative textuelle. :D Rien que pour me marrer un coup, j'aimerais bien voir ça un jour. Dodoïste [ dring-dring ] 22 novembre 2010 à 23:38 (CET)
Promis, juré : j'ai déjà vu un diff rien que pour cela (j'aurais dû le noter, mais ce n'est pas bien de montrer du doigt, non plus) Mort de rire. --Lgd (d) 24 novembre 2010 à 12:35 (CET)
Plop ?
Il va bientôt falloir mobiliser un bot, pour traiter les choses comme Catégorie:Modèle pays et drapeau historique. Au passage, si vous avez d'autres catégories de ce type dans vos tiroirs, lâchez vos com' Vos coms ? Vos com's, enfin bref, c'est comme cela qu'on dit, non ? Cordialement, --Lgd (d) 25 novembre 2010 à 19:53 (CET) Clin d'œil.
Au fait: c'est fait pour la requête. Cordialement, --Lgd (d) 26 novembre 2010 à 16:21 (CET)

Espaces insécables[modifier | modifier le code]

Au fait, excusez ces questions certainement très naïves mais servent-ils vraiment à quelque chose sur Wikipédia ? Je croyais que la syntaxe wiki gérait automatiquement les espaces insécables mais on voit passer des contributeurs qui en rajoutent partout et fleurir les modèles qui leurs sont dédiés. Est-ce que ça a un impact sur l'accessibilité ? Où tout cela est-il expliqué ? Je n'ai rien trouvé sur Aide:Syntaxe ni Aide:Caractères spéciaux et l'article Espace insécable ne parle pas de wiki. --Amicalement, Salix ( converser) 24 novembre 2010 à 11:51 (CET)

Pour autant que je sache, MediaWiki insère automatiquement des espaces insécables pour les % et les « », mais c'est tout. Les espaces insécables n'ont aucune influence sur l'accessibilité, ils servent uniquement à la mise en page. Cela permet de ne pas avoir de symboles bi-points en début de ligne, ou de césure entre « p. » (etc.) et ce qui suit immédiatement ; la lecture est ainsi plus fluide, moins déroutante.
On peut trouver d'autres usages, par exemple dans les palettes de navigation, cela permet de ne pas couper les éléments, et la palette est beaucoup plus facile à lire. L'inconvénient, c'est qu'il faut faire attention à ce que ça tienne en largeur sur les écrans de petite taille.
Cordialement, od†n [dead words] 24 novembre 2010 à 12:04 (CET)
En effet, ce n'est pas une question qui relève des critères d'accessibilité normatifs. Cependant, éviter les renvois à la ligne dans un nombre, entre une valeur et son unité etc. pourra être particulièrement apprécié par des lecteurs ayant certains handicaps visuels ou cognitif (dyslexie) qui rendent difficile le passage d'une ligne à la suivante lors de la lecture.
Les pratiques actuelles dans Wikipédia n'ont donc rien de dommageable quand il s'agit du rôle normal de ce caractère. C'est différent quand on utilise par exemple deux espaces insécables successifs pour simuler un padding, comme dans certaines palettes de navigation Clin d'œil, ou plus sérieusement, quand des espaces insécables sont détournés de leur rôle et répétés pour simuler une mise en colonne, une indentation, etc. Mais cela reste rare.
Donc, de ce côté, grosso-modo, tout va plutôt globalement bien. Cordialement, --Lgd (d) 24 novembre 2010 à 12:30 (CET)
Ne serait-ce pas une référence à peine dissimulée à un certain « 2• » ? Clin d'œil
(à propos, vu que ce n'est pas le sujet de cette discussion ; je trouve que les palettes deviennent vite pénibles à lire, surtout quand il y a beaucoup de texte en italique ; l'insécabilité et les doubles espaces sont des techniques pour essayer d'améliorer un tant soit peu la lisibilité... Aussi, on devrait s'inspirer des palette anglaises : je trouve les couleurs plus belles (quoique moins de contraste avec la couleur des liens) et je préfère leur taille de texte légèrement réduite : en fait je la trouve plus lisible, et en prime ça prend moins de place ; évidemment, c'est en rapport avec mon écran, ma vue, ma police de caractères, mon anti-aliasing cleartype, etc.)
Cordialement, od†n [dead words] 24 novembre 2010 à 12:49 (CET)
Nonon Mort de rire
Pour les palettes, je finis d'abord la V1.0 du gadget accessibilité, ensuite je poursuis sur la nouvelle version du script de déroulement, et donc des modèles de palettes (plutôt dans quelques semaines, je vais être bientôt quand même un peu obligé de bosser full time IRL). Donc : hors-jeu pour le moment. Mais merci pour le signalement des palettes .en, ça servira évidemment. Cordialement, --Lgd (d) 24 novembre 2010 à 12:56 (CET)

Merci pour ces éclaircissements. En pratique, où est-il écrit que MediaWiki insère automatiquement des espaces insécables pour les % et les « » et peut-être d'autres signes ?--Amicalement, Salix ( converser) 24 novembre 2010 à 16:11 (CET)

Heu... clic, clic, clic, clic encore... zut... clic... (je suis arrivé là comment, au fait ?) Finalement, c'est , mais bon, il faut chercher, en effet Mort de rire. je trouve parfois plus simple de regarder directement le code source du parseur dans mediawiki que de tenter les pages d'aide, en vrai. Il y a un chantier à relancer Clin d'œil Cordialement, --Lgd (d) 24 novembre 2010 à 16:17 (CET)
Tiens, une idée d'approche ludique: on vous donne une page d'aide ; vous avez 3 clics et 3 minutes pour y arriver à partir de Aide:Sommaire. Si vous perdez, vous devez corriger l'aide... Non ? Cordialement, --Lgd (d) 24 novembre 2010 à 16:23 (CET)
Pour ceux qui ont du mal, je vais compléter la liste (en espérant ne rien oublier) des cas pour lesquels wikimédia gère tout seul comme un grand la transformation de l’espace normale en une espace insécable (notez que le terme « espace » est féminin en typographie) : les % (à noter que pour ‰ wikimédia ne propose rien de tel à l’heure actuelle) et les « » déjà évoqués, mais également pour certaines marques de ponctuation : deux-points, point d’interrogation, point d’exclamation sans oublier le point-virgule… du moins sur WP:FR. Si vous connaissez d’autres cas, je vous serai gré de les signaler… Cordialement, — MetalGearLiquid [m’écrire] 24 novembre 2010 à 17:54 (CET)
Smiley Colère Ça m'énerve les pages d'aide qui vous disent comment on fait des trucs compliqués comme ceci ou cela, où il faut se concentrer pour tout saisir, et puis qui ajoutent ensuite (pour ceux qui sont arrivés jusque là) « ah! mais, au fait, faut pas l'faire dans Wikipédia ! »". Pas vous ? --Amicalement, Salix ( converser) 24 novembre 2010 à 18:57 (CET)
Mort de rire. --Lgd (d) 24 novembre 2010 à 18:59 (CET)
Encore une fois mon avis là-dessus : malgré l’automatisme (je confirme %«»:?!) rien n’empêche d’inclure les espaces insécables dans les sources des articles. Exemple : une traduction est faite d’un article depuis frwiki, le contributeur copie la source vers son wiki puis commence à traduire, il veut faire une citation de l’article français (allez savoir pourquoi !), vire les modèles de mise en forme qui n’existent pas sur son wiki (qui souvent ne nous servent qu’à gérer ces espaces…) et se retrouve avec une citation en français dont la typographie laisse à désirer (cf. plus haut les problèmes de retour à la ligne pour la lisibilité d’une unité par exemple). Un gadget pour faciliter la mise en valeur des espaces insécables et autres caractères invisibles fait toujours défaut (il existe pourtant, il n’y aurait qu’à l’adapter un peu à nos besoin sur frwiki). Edit : dans la foulée ça me fait penser à une question, serait-il possible d’envisager un gadget non pour l’édition mais pour la visualisation comme le fait le gadget accessibilité (le même genre de boite déroulante à droite) avec des options (CSS only si j’ai bien compris) pour surligner les espaces insécables ou afficher les apostrophes typographiques, etc. ? On va me dire qu’il suffit d’utiliser la fonction de recherche des navigateurs mais il faut disposer de ces caractères pour le faire et c’est là que ça cloche : l’espace insécable (u00a0) est rare sur les disposition de clavier, de même pour le guillemet-apostrophe (u2019). A2 (d) 26 novembre 2010 à 19:06 (CET)
Il ne faut tout de même pas oublier deux ou trois choses :
1) certains anciens navigateurs font sauter les espaces insécables présentes dans le code source durant une édition
2) même avec des navigateurs récents, ils sautent encore régulièrement (je soupçonne WikEd d’en être coupable, au moins en partie, sans pouvoir me porter partie civile contre lui avec certitude Clin d'œil)
3) il me semble aussi que certains anciens systèmes d’exploitation peuvent également les faire sauter lors d’un copier-coller.
Il faudrait donc voir s’il y a moyen de corriger les éventuels bugs de certains gadgets qui provoqueraient la substitution, et garder à l’esprit qu’il est impossible d’interdire aux utilisateurs de vieux ordinateurs munis d’OS+navigateurs datant du siècle passé d’éditer les articles de Wikipédia (donc en pratique, il ne sert à rien de coder des insécables directement au clavier, puisqu’ils pourront toujours sauter, il faudra toujours (ou du moins pendant encore très longtemps) passer par des modèles, des entités et/ou CSS).
Mes deux « em-cents »,
Cordialement, — MetalGearLiquid [m’écrire] 3 décembre 2010 à 06:07 (CET)
Je suis bien conscient de tout ça, connais-tu un OS qui ne les supprime pas au copier/coller. Quant aux navigateurs qui les font « sauter », as-tu supprimés volontairement les insécables de la page pour le prouver (cf. le diff. de ton message) ou en utilises-tu encore un de ces… « navigateurs du siècle dernier » ? A2 (d) 3 décembre 2010 à 16:09 (CET)
Au niveau du copier-coller qui préserve les espaces insécables, je puis t’assurer avec certitude que Windows 7 en fait partie[1], et je suis presque sûr que cela est également vrai pour les versions Win2K, 7 et Vista, en passant par les 2K3 et 2K8. Ceux qui pourraient ne pas le faire correctement sont les versions antérieurs de Windows[2] ; pour ce qui est des OS concurrents, tels *nix[3], MacOS et MacOSX par exemple, il faudrait également les tester pour répondre à cette question. À noter qu’il faut bien comprendre que je parle juste de la fonction copier-coller des OS, pas des limitations liées aux applications dans lesquelles on encode ou copie[4]. Mais le sujet ici n’est pas de lister les aptitudes de chaque OS et application à supporter intégralement Unicode.
Concernant ta seconde phrase, émets-tu l’hypothèse que je me serais rendu coupable d’un WP:POINT, si c’est la cas, merci de (re)lire WP:FOI… et penses-tu sérieusement que si j’utilisais un OS et/ou navigateur du siècle dernier j’aurai formulé la phrase de la sorte (plutôt que de dire par exemple : « j’utilise Win3.1 avec Netscape Navigator 1.0 qui fait sauter les espaces insécables »), et enfin pourquoi penses-tu que j’ai évoqué WikEd en soulevant cette problématique ? (enfin soit, passons…)
À noter qu’il me semble que l’outil de recherche de texte de Firefox ne fait aucune distinction entre les espaces insécables et les sécables, à moins que le site que je viens de tester présente également une déficience du support de l’insécable et la substitue[5], rendant ma supposition fausse ! En tout cas, la copie d’une espace insécable dans le champ de recherche trouve également les espaces sécables présentes dans un texte, preuve que le support parfait de Unicode n’est pas intégral[6]. — MetalGearLiquid [m’écrire] 4 décembre 2010 à 07:14 (CET)
Notes :
  1. En effectuant dans cet OS un copier-coller depuis Notepad vers Notepad++ car ce dernier a l’avantage de permettre la visualisation des espaces insécables, tabulations et passages à la ligne sans rien modifier, contrairement aux traitements de textes qui peuvent parfois décider de procéder à certaines substitutions qu’ils supposent avantageuses pour l’utilisateur.
  2. Win9x, voire certaines versions de WinNT.
  3. Unix, linux, etc.
  4. Imaginons la copie d’un texte avec espaces insécables dans un OS supportant correctement Unicode, vers une application non compatible avec Unicode : il se pourrait qu’elles soient remplacées par des espaces insécables, qu’elles soient substituées par une séries de caractères ASCII ou que sais-je encore, soit juste au moment du coller, soit au moment de la sauvegarde du texte/du fichier.
  5. ou est-ce dû à une question de définition de charset utilisé différent entre l’application source et cible lors d’un encodage/copier-coller ?
  6. ou peut-être que les développeurs pensent rendre un service à l’utilisateur lambda en effectuant une substitution dans le champ de recherche… pour ma part, j’aurai bien voulu une case à cocher dans la barre de recherche, pour avoir le choix entre une recherche stricte et une recherche lâche, permettant également de ne pas tenir compte des lettres accentuées, tabulations, etc. et pourquoi pas, soyons fous, même permettre des recherches avancées sur base d’expressions régulières simples… mais en évoquant ceci je sors totalement du cadre du sujet.
Merci pour la réponse détaillée sur les OS. Pour les navigateurs j'avais déjà fait moulte test sous Windows pour cela, j'étais un des premiers comme toi à en parler sur divers projets et je me suis aussi fait bannir pour une apostrophe typographique de trop (comme toi il me semble…). Aussi je confirme que Chrome et Firefox ne distinguent toujours pas espaces sécables et insécables. Ma remarque était assez ironique, je suis étonné que tu le prennes aussi mal, ton diff. montre bien une suppression de quelques espaces insécables dans les messages des autres (la question, bien qu'ironique, était réelle : était-ce volontaire ? aucune accusation de POINT, c'était par curiosité, peut-être utilises-tu un script qui transforme tout automatiquement ou que celui-ci fait des trucs dans ton dos). D'ailleurs de même sur le diff. suivant, Lgd plus cocasse pour sa « démonstration gadget », nous aura supprimé toutes les apostrophes typographiques (carrément !). Bizarre non ? Était-ce volontaire Lgd ? A2 (d) 4 décembre 2010 à 15:03 (CET)
C'était un simple effet de bord d'un gadget en cours de test développé à ta demande. Maintenant, si cela suscite de ta part ce genre de question déplaisante autant que déplacée et inutile, je te recommande fortement, disons, d'éviter de recommencer. --Lgd (d) 4 décembre 2010 à 15:07 (CET)
Je viens de restaurer la bonne version avec apostrophes (je le signale pour d’éventuels lecteurs ultérieurs qui n’y comprendraient plus rien et j’ai fait cette correction à dessein, sait-on jamais avec certains qui feraient feu de tout bois pour y voir un WP:POINT et le retourner contre l’un ou l’autre contributeur par la suite… ).
Note concernant l’ironie, les seconds degrés, et j’en passe : il est manifeste que cela entraîne souvent des quiproquos. J’essaie à la fois d’éviter d’en faire moi-même usage et de « détecter » ceux des autres intervenants sur les diverses PdD, mais ce n’est guère chose facile (un oubli de smiley combiné à un manque de connaissance du style, du contexte cognitif d’un autre intervenant, et « bardaf c’est l’embardée » comme le disais si bien Manu Thoreau en incarnant son personnage dans Faux contact, et cela vaut aussi bien pour les intervenants que pour les autres lecteurs a posteriori), ce qui précède et qui suit ce petit message en est la preuve incontestable. — MetalGearLiquid [m’écrire] 10 décembre 2010 à 11:58 (CET) « Édith » @A2, comme je l’indiquais précédemment, il me semble que c’est WikEd qui pourrait être la cause des remplacement « dans mon dos » des espaces insécables par des espaces normales… — MetalGearLiquid [m’écrire] 10 décembre 2010 à 13:09 (CET)
@A2 : « serait-il possible d'envisager un gadget non pour l'édition mais pour la visualisation comme le fait le gadget accessibilité (le même genre de boite déroulante à droite) avec des options (CSS only si j'ai bien compris) pour surligner les espaces insécables ou afficher les apostrophes typographiques, etc. ? » : C'est très facile (je viens de le faire dans mon vector.js). Est-ce d'un usage assez courant pour justifier un gagdet ? D'autant que c'est assez lourd côté performances du navigateur, au moins sous la forme où je l'ai rapidement écrit. Sinon, je peux installer le script dans ton vector js. Cordialement, --Lgd (d) 4 décembre 2010 à 08:28 (CET)
Merci. Je vais aller trouver ça sur ton vector.js (ou historique) et me l'adapter, mais s'il fonctionne aussi bien que sur le diff. au-dessus j'aurais surement quelques questions ! Si on peut l'activer/désactiver, le problème des ressources est moindre. Je ne sais pas si c'est d'usage courrant, à voir à l'utilisation. Je sais que la plupart des traitements de textes le propose en option, mediawiki non. A2 (d) 4 décembre 2010 à 15:03 (CET)
Très franchement, vu ta manière de réagir aux développements qui sont fait quand on prend du temps pour prêter attention tout spécialement à tes demandes sans rapport avec l'objet de cette page, tu peux aller te brosser. Faut pas déconner, quand même : un minimum de politesse et de respect seront les bienvenus Mort de rire. --Lgd (d) 4 décembre 2010 à 15:11 (CET)
Je ne comprends pas vos réactions, encore une fois c'était pour aider, si le gadget déconne, je ne saurais le corriger moi-même donc je te souligne cet effet de bord que tu n'as peut-être pas remarqué. Je t'ai remercié pour le script que je n'attendais plus vraiment vu les nombreuses fois où j'ai demandé un gadget du genre restées sans réponses. Je ne l'ai pas encore vu en action donc pour le moment je ne peux te remercier plus. S'il fonctionne comme décrit, je t'enverrais des mercis par panier. Tu as tout mon respect Lgd, contrairement à ce que tu peux croire et si mes remarques ou formulations parfois peut-être trop ironiques vous paraissent déplacées il faudra que je cesse de les formuler ainsi. Si ça peut paraitre hors-sujet (côté accessibilité), comme je viens de le faire remarquer, les réponses à mes demandes pour ce type de gadget sont restés bredouilles à droite à gauche, là où sur ce projet j'avais espoir d'avoir une réponse de quelqu'un de compétent, preuve en est. Je ne vois vraiment pas comment pourrais-je être irrespectueux et impoli envers quelqu'un qui vient de m'offrir ce que je demande depuis des mois (voir années). Aussi je vous prierais de m'excuser si cela a pu paraitre ainsi. A2 (d) 4 décembre 2010 à 15:28 (CET)
Ne t'en fais pas, c'était de l'ironie comme en a le secret Lgd. Ça surprend toujours un peu au début Mort de rire od†n [dead words] 4 décembre 2010 à 17:44 (CET)
Humpf. Non, c'était beaucoup plus bêtement un mouvement d'agacement intempestif de ma part à partir d'un message mal compris et à la fin d'une très mauvaise journée. Je te fais toutes mes excuses, A2 (J'ai mauvais caractère, c'est hélas connu et je me soigne, mais bon il faut décidément que je me surveille encore davantage). Le script a en effet un énorme bug lors de l'édition, ou plus exactement lors de la preview. J'ai pour l'instant réglé ça brutalement dans la version de test Utilisateur:Lgd/vector.js en le désactivant dans ce cas (chercher les if(!(wgAction=='view'))), mais ce n'est pas idéal : il faudrait garder la fonctionnalité lors de la prévisualisation sans qu'elle affecte le contenu de la boîte d'édition. Par ailleurs, ce qui est encore plus intéressant dans la demande d'A2, c'est que si on envisage d'autres gadgets de vérification lors de la consultation d'une page, il faudra modifier le système permettant de fixer le gadget accessibilité de manière à le rendre générique (permettre d'avoir X gadgets fixés de cette manière). Je me note ça sous le coude. Cordialement et désolé, --Lgd (d) 5 décembre 2010 à 11:40 (CET)

Bon, en attendant j'ai revu la mise en page de l'aide en espérant que ce soit plus clair et surtout que cela évitera à l'avenir des diff' inutiles : que je suis le naïf de service, merci de vérifier si j'ai bon Clin d'œil. --Amicalement, Salix ( converser) 4 décembre 2010 à 18:46 (CET)

Au fait, j'ajoute toujours les guillemets en cliquant dans la liste des caractères spéciaux (comme « ceci » par exemple) proposée sous la fenêtre des modifications et des contributeurs viennent ensuite modifier le code, pourquoi ? --Amicalement, Salix ( converser) 4 décembre 2010 à 18:54 (CET)
Les diffs sont trompeurs et cette modification n'est pas faite par les contributeurs. Les liens de la barre d'outil d'édition insèrent des espaces insécables sous une forme littérale que mediawiki convertit ensuite dans une autre forme, ce qui apparaît dans les diffs. Cordialement, --Lgd (d) 4 décembre 2010 à 19:45 (CET)

Images décoratives[modifier | modifier le code]

Bonjour,

J'ai découvert récemment le gadget accessibilité et j'ai testé la détection des textes alternatifs aux images. J'ai rapidement vu que l'avertissement concernant les copyright en-dessous de la fenêtre d'édition a un gros "ALT MANQUANT" en rouge. Je l'ai signalé à Kropotkine qui me répond qu'il a un doute à la lecture de Wikipédia:Atelier accessibilité/Bonnes pratiques#Images décoratives et effectivement, à la lecture de ce paragraphe, on ne sait pas si "alt vide" correspond à "alt manquant"(pas clair) et si c'est vraiment à jour (pas de mention du paramètre |link=)?

Je vous remercie d'avance de votre attention,--Y▬Spirine@causer 24 novembre 2010 à 16:59 (CET)

S'agit-il du rendu du modèle {{Bienvenue copyvio}} ou {{Copieur}} (même modèle par le jeu des redirections) ?
Si c'est le cas :
  • l'image n'apporte pas d'information qui ne soit dans le texte du bandeau, donc le ALT doit être vide
  • l'image n'a aucune nécessité d'être un lien vers sa propre page (elle est dans le domaine public, donc pas de problème de mention des auteurs), donc le LINK gagne à être vide pour qu'elle ne soit pas un lien au rôle et à la cible difficilement compréhensibles.
J'ai corrigé {{Copieur}} entre-temps en ce sens (voir la correction) (j'avoue que j'avais vu votre discussion par dessus vos épaules).
L'aide du gadget est en cours de rédaction et les messages d'alertes sont en cours d'amélioration : ce type de retour est extrêmement utile pour déterminer ce qui conviendra. Merci Clin d'œil N'hésitez pas à poser ici toutes les questions qui vous viennent.
Cordialement, --Lgd (d) 24 novembre 2010 à 17:09 (CET)
Nonnon, c'est le MediaWiki:Wikimedia-copyrightwarning--Y▬Spirine@causer 24 novembre 2010 à 17:20 (CET)
Même problématique pour le LINK déjà vide et pour le ALT à ajouter, même solution (fait). Cordialement, --Lgd (d) 24 novembre 2010 à 17:43 (CET)
Ok, compris. Kropotkine 113 (d) 24 novembre 2010 à 17:47 (CET)

Tableaux[modifier | modifier le code]

Ia Ora Na. Comme on ne doit pas insérer de tableau dans un tableau je me demandais s'il y avait un moyen "propre" de positionner 2 tableaux côte à côte (Notamment quand il n'ont pas les mêmes dimensions) ? --'toff [discut.] 25 novembre 2010 à 03:52 (CET)

En allant au plus simple, comme ceci (L'important est le left de {| class="wikitable left" et le {{Clr}} final) :
coucou
foo foo foo foo foo foo foo
foo foo foo foo foo foo foo
coucou
foo foo foo
foo foo foo
foo foo foo
foo foo foo
foo foo foo
Mais dans le cas, les tableaux ne sont pas centrés.
Pour obtenir deux tableaux côte à côte et le tout centré dans la page (avec un code simple pour les contributeurs), il va falloir créer des modèles {{Côte à côte début}} et {{Côte à côte fin}} et créer les styles nécessaires dans Mediawiki:Common.css (par exemple du display:inline-block pour les tableaux et du text-align:center pour le conteneur, même si les vieilles versions d'IE n'aimeront pas). Comme cela pourrait servir aussi pour d'autres cas que des tableaux, le jeu devrait en valoir la chandelle...
D'autres avis ? Cordialement, --Lgd (d) 25 novembre 2010 à 06:28 (CET)
Ah oui, chouette tiens. J'ai déjà vu pas mal de tableaux imbriqués, et je ne les ai pas corrigés car je pensais que les auteurs allaient tenir à leur mise en page... Ça serait utile. :-) Dodoïste [ dring-dring ] 25 novembre 2010 à 12:45 (CET)
En fait de tableaux imbriqués, la page d'accueil de fr.Wikipédia vire au rouge quand on utilise le gadget ! N'y a-t-il pas moyen d'y remédier ? J'ai aussi un problème avec les modèles de la Catégorie:Modèle Cladogramme : des idées pour faire plus accessible ? --Amicalement, Salix ( converser) 25 novembre 2010 à 13:02 (CET)
Cool, ça me satisfait pour le moment. (Dis, t'as pas un lien vers une page d'aide pour les "class" des tableau ? Parce qu'il semble y avoir pas mal de possibilité et ça éviterait que je passe mon temps à vous embêter...) --'toff [discut.] 25 novembre 2010 à 19:55 (CET)
Ça, ce serait une bonne idée, de reprendre les 3 pages d'aides sur les tableaux (novice, curieux, expert) pour y mentionner les choses vraiment utiles, comme les classes : wikitable, sortable, center, centre, left, right... et très bientôt alternance. Saliiiiix ? Mort de rire Cordialement, --Lgd (d) 25 novembre 2010 à 19:58 (CET)
@Salix : à propos de Catégorie:Modèle Cladogramme, c'est à peu près mort pour le moment. On avait vaguement parlé d'un Cladogramme à base de listes imbriqués, mais les gens veulent des choses plus graphiques. AMHA, c'est un petit tas à glisser sous le tapis pour le moment, en attendant HTML5 qui devrait permettre de faire proprement des choses comme cela plus facilement. Cordialement, --Lgd (d) 25 novembre 2010 à 20:01 (CET)

Références bibliographiques avec BibTeX[modifier | modifier le code]

Bonsoir, avant de donner mon avis est-ce accessible ? --Amicalement, Salix ( converser) 25 novembre 2010 à 22:18 (CET)

J'aimerais comprendre ce que tu entends par « accessibilité » ? Accessible à qui, pour qui, sur quoi ? Bibi Saint-Pol (sprechen) 26 novembre 2010 à 10:56 (CET)
Tout est là : Wikipédia:Atelier accessibilité/Qu'est-ce que c'est ? Clin d'œil. --Amicalement, Salix ( converser) 26 novembre 2010 à 10:58 (CET)
Bonjour,
En bref : avis  Neutre.
Du point de vue accessibilité (telle qu'elle est abordée ici), cela ne pose pas plus de problèmes que les différents autres systèmes de notes et références bibliographiques (liens non explicites).
Pour élargir le point de vue : du point de vue ergonomique, disons que ce n'est pas pire que d'autres (lecture cassée en 3 endroits dans la page là où on peut se limiter à deux). Par ailleurs, du point de vue technique, comme tous les systèmes reposant sur des identifiants ID qui ne sont pas vérifiés et corrigés par mediawiki, il s'expose à produire des ID non uniques sur une même page (problème courant).
Ces défauts sont plus ou moins communs à tous ces systèmes concurrents actuels sur fr.wp, mais ce n'est pas un chantier qui pourra être traité par le biais de modèles (les développements qui seraient nécessaires ne relèvent pas de ce qu'on peut faire localement). Autrement-dit, si celui-ci répond par ailleurs à des besoins avérés du point de vue éditorial, pourquoi pas... Cordialement, --Lgd (d) 26 novembre 2010 à 11:08 (CET)
Cf. aussi ma réponse à l'endroit de la discussion initiale. Bibi Saint-Pol (sprechen) 26 novembre 2010 à 11:42 (CET)

Modèle Clade[modifier | modifier le code]

Bonjour, l'utilisation du modèle {{Clade}} génère des tableaux imbriqués, ce qui n'est pas du tout bon pour l'accessibilité... mais je ne crois pas que cela puisse être résolu proprement parlant (esthétique notamment mais aussi compréhension) par une autre façon de faire. Peut-on envisager une alternative textuelle aux arbres phylogénétiques ? Merci d'avance pour vos idées et votre aide. Cordialement, Totodu74 (devesar…) 26 novembre 2010 à 14:43 (CET)

Regarde la réponse à la question sur le modèle Cladogramme deux sections plus haut. En gros, on corrigera ça plus tard. Par contre, ce serait utile de déjà commencer à lister les modèles de ce genre, ça facilitera la correction plus tard. On peut faire la liste quelque part en sous-page de l'atelier accessibilité. Dodoïste [ dring-dring ] 26 novembre 2010 à 14:48 (CET)
Rha pas vu ! Merci pour la réponse, zou sous le tapis… Totodu74 (devesar…) 26 novembre 2010 à 16:14 (CET)
Il va falloir donner du bromure aux utilisateurs du gagdet : on ne les tient plus, ils veulent tout corriger Mort de rire. --Lgd (d) 26 novembre 2010 à 16:17 (CET)
Ben oui, tu nous offres un nouveau jouet pour Noël, tu ne voudrais pas qu'on l'abandonne sous le sapin ? Ange --Amicalement, Salix ( converser) 26 novembre 2010 à 17:17 (CET)

Gadget accessibilité, c'est Noël, version 1.0 en vue ce WE[modifier | modifier le code]

Bonsoir,
Je vais mettre en ligne la version 1.0 du gadget accessibilité ce WE, c'est à dire actualiser le gadget actuel vers une première version à peu près solide (celle que vous utilisez une version de test, vous m'avez tous pris de court en vous précipitant dessus alors que c'était juste un essai... Mais bon, je ne vais pas râler Mort de rire).

Avant que je n'oublie quelque-chose qui serait vraiment prioritaire, voici la liste des changements apportés par cette version 1.0 : manifestez-vous si quelque-chose m'a échappé (je serais beaucoup moins disponible dans les 3 semaines à venir pour faire des corrections et il n'y a malheureusement pas grand-monde pour y suppléer).

Les choses faites dans cette nouvelle version :

  1. Test Alternatives et drapeaux, pavillons et smileys : cette version reconnaît ces icônes, en particulier les drapeaux bien traités selon la petite politique des drapeaux exposée quelques sections plus haut. Dans la plupart des cas, compte-tenu des corrections effectuées ces derniers jours sur les modèles de drapeaux, il ne signale plus que des choses vraiment à problème parce que pas encore traités, et il vous permet de vérifier rapidement que l'alternative textuelle ne dit pas n'importe-quoi (genre « cataclop » pour le drapeau français). Le nombre d'alertes sur les articles à risque que j'ai testé a diminué d'au moins 80%, c'est impressionnant.
  2. Test Alternatives et infobox : le gadget ne « casse » plus le rendu des cartes de géolocalisation, sauf pour les plus irrécupérables... Cela n'empêche pas ces cartes d'être un gros problème, mais on sait qu'il n'est pas traitable simplement tout de suite.
  3. Test Langue : le gadget met une bordure qui permet d'identifier le texte auquel a été appliqué le modèle {{lang}} ou similaire.
  4. Test Listes : le gadget utilise du orange mieux contrasté et émet de nouvelles alertes en cas de listes à puces comportant des sauts de lignes en trop.
  5. Test Tableaux, Test Alternatives et gallery, Test Alternatives et timeline : plusieurs messages d'alertes ont été corrigés pour être plus pertinents.
  6. Gadget sous monobook : le gadget peut être « fixé » sans masquer le moteur de recherche.
  7. Fixer : le gadget utilise une icône qui indique l'action, au lieu du bête « fixer »

Les choses à faire impérativement à la suite de cette version :

  1. Mettre à jour et compléter l'aide du gadget, pour diriger immédiatement vers des solutions applicables par le contributeur.

Les choses que j'ai froidement laissé de côté au moins pour l'instant :

  1. Le « Tout activer ». Pensez que les tests sont appelés à devenir plus nombreux. Pour ma part, bien que très habitué à l'examen de pages Web à des fins de tests d'accessibilité, je suis déjà saturé dans ma petite tête si j'active tous les tests actuels...
  2. Désactiver le gadget dans tel ou tel espace de nom, ou avoir la possibilité de le faire selon ses choix (pas urgent).
  3. D'autres signalements de listes mal faites, à base de <br /> en particulier (c'est déjà traité par le projet de correction syntaxique, pas d'urgence).
  4. Revoir le test sur les titres pour qu'il fasse des alertes bien visibles en cas de saut d'un niveau de titre (idem).
  5. Les alertes de tableaux et de thumb manquant dans les infobox : les contributeurs ne peuvent en corriger qu'une faible partie, mais il est temps que ce scandale soit évident, en quelque-sorte.
  6. heu... quoi d'autre ? (je passe sur l'internationalisation du gadget et d'autres choses plus techniques, ce sera la 1.5)

Les choses que vous auriez déjà rapportées et qui auraient été oubliées ci-dessus (ou alors vos toutes dernières inspirations : il ne vous reste que quelques heures) :

  1. C'est à vous... Cordialement, --Lgd (d) 26 novembre 2010 à 20:06 (CET)

<mode impatient>C'est pas déjà le WE ? Clin d'œil</mode impatient>
Juste un petit retour sur l'historie des drapeaux : en me penchant dessus ce matin, j'ai voulu corriger un autre article et créer un modèle pour Saint-Louis mais, en regardant ton exemple pour Chicago, je me suis demandé si c'était pertinent ? En effet, tu utilise un modèle destiné (d'après son nom), aux pays seulement et d'ailleurs, Catégorie:Modèle Country data ne contient, hormis Chicago, quasiment à priori, que des pays. Du coup, j'ai pas fait... --'toff [discut.] 26 novembre 2010 à 20:25 (CET)

Le fait que des noms de sous-modèles à usage purement technique disent « country » quand il s'agit d'une ville n'est pas un problème. Reconstruire le système très compliqué des modèles de drapeaux pour cela serait peu productif, je pense. Le contributeur va écrire {{drapeau|Chicago}} et le résultat sera celui attendu, c'est l'important. Maintenant, il va falloir certainement fournir un guide pour la correction de ces drapeaux (si je n'arrive pas à vous prendre de vitesse en corrigeant à tour de bras les cas individuels qui restent Mort de rire). Cordialement, --Lgd (d) 27 novembre 2010 à 11:23 (CET)
Ca roule. J'ai fait pour {{drapeau|Philadelphie}}, ça a l'air bon ? --'toff [discut.] 27 novembre 2010 à 19:28 (CET)

Mise à jour faite, actualisez...[modifier | modifier le code]

Voir Bistro du jour. J'ai l'abominable sentiment d'avoir commis un bug quelque-part, ça va me gâcher le WE, je sens...Cordialement, --Lgd (d) 27 novembre 2010 à 11:23 (CET)

Cet outil est génial, un tout grand bravo au(x ?) concepteur(s) ! Bisou Je le trouve notamment pratique pour voir où les modèles langues ont pu être oubliés. J'ai cependant une petite remarque : Je travaille beaucoup avec les articles à taxobox, et c'est effrayant de la voir tout en rouge... Ce serait possible de régler les problèmes d'accessibilité des différents modèles (p. ex. link manquant sur image... un thumb est pas pour autant envisageable) ou sinon de ne pas afficher une boîte toute rouge ? Bon week-end, Totodu74 (devesar…) 27 novembre 2010 à 14:49 (CET)
Disons que, avec les alertes actuelles, l'outil participe sournoisement à la cabale d'une refonte future des infobox Mort de rire --Lgd (d) 27 novembre 2010 à 16:12 (CET)
Mais... la taxobox n'est pas une infobox, mais une... taxobox ! Mort de rire Totodu74 (devesar…) 27 novembre 2010 à 19:28 (CET)

Du bon usage de alt et link[modifier | modifier le code]

Bonjour,

Je n'ai toujours pas vraiment compris quel est le bon usage des mot magiques alt et link pour l'accessibilité des images. Désolé de vous importuner avec des questions bêtes (Smiley Gêné) auxquelles vous avez sûrement déjà répondu mais après avoir lu les discussions au-dessus, je n'ai toujours pas compris…

  • Alt devrait systématiquement être présent pour fournir une alternative textuelle à l'image, mais je n'ai pas compris pourquoi dans certains cas, on se passe du mot magique alt. En gros quelle est la différence entre [[Fichier:truc bidule.png|alt=truc bidule]] et [[Fichier:truc bidule.png|truc bidule]] ?
  • Si j'ai bien compris, le logiciel mediawiki fournit par défaut un lien vers le fichier lui-même donc lorsque c'est bien le lien vers le fichier que l'on cherche à avoir, on ne met pas link (typiquement les images en thumb), dans les autres cas on a le choix entre la spécification d'un lien particulier ou de mettre laisser le link vide. Comment choisit-on ?
  • Si j'ai bon ci-dessus, cela justifie totalement ce révert mais je ne comprends pas pourquoi Lgd a rétabli ma version derrière Euh ? ?
  • dernière question (à propos du gadget), la nouvelle version semble ne plus montrer les link vides pour tout un tas d'utilisations de fichiers comme les drapeaux et les smiley, mais pourquoi l'avertissement est-il toujours présent pour les images à l'intérieur des infobox qui ne doivent renvoyer vers rien d'autre que l'image elle-même ? Par exemple pour {{infobox rugbyman}}, j'ai fait cette modification pour ne plus avoir l'avertissement avec le gadget, est-ce que c'est bon ?

Udufruduhu (d) 27 novembre 2010 à 12:22 (CET)

[[Fichier:truc bidule.png|alt=truc bidule]] donne une image avec un attribut alt valant "truc bidule" et [[Fichier:truc bidule.png|truc bidule]] donne une image avec un attribut alt valant "truc bidule.png" (car non précisé) et donc la balise "a" (pour créer le lien) avec un attribut title qui vaut "truc bidule". --Manu1400 (d) 27 novembre 2010 à 12:34 (CET)
Alors pourquoi je vois l'alternative Clin d'œil et pas Face-wink.svg pour {{Clin d'œil}} alors que l'attribut alt n'est pas spécifié ? Sinon, je n'ai pas compris la seconde partie de ta réponse. Qu'est ce que c'est que la balise "a" ? Udufruduhu (d) 27 novembre 2010 à 12:45 (CET)
Rapidement:
  1. les deux syntaxes ont des effets pratiquement identiques :
    • [[Fichier:Exemple.jpg|alt=truc bidule]] donne truc bidule
    • [[Fichier:Exemple.jpg|truc bidule]] donne truc bidule
  2. @Manu1400 : s'il-te-plaît, lève le pied un moment sur tes interventions dans ce domaine, tu sembles te débattre un peu avec tout cela. Cordialement, --Lgd (d) 27 novembre 2010 à 13:17 (CET)
Et donc y-a-t-il une syntaxe à privilégier ou on fait comme cela nous chante ? Et si vous pouviez répondre également à mes autres questions au-dessus, ça m'aiderait bien Clin d'œil, merci. Udufruduhu (d) 28 novembre 2010 à 15:35 (CET)
Désolé. J'essaie de faire au plus clair :
  1. alt : dans le doute, écrire [[Fichier:truc bidule.png|alt=truc bidule]] dans tous les cas (pour ce qui suit, on considère donc toujours suivi cette règle).
  2. link :
    • Si le paramètre link est absent ([[Fichier:truc bidule.png|alt=truc bidule]]), l'image est automatiquement un lien vers le fichier :
      [[Fichier:Exemple.jpg|alt=truc bidule|16px]] donne truc bidule qui est un lien automatique vers Fichier:Exemple.jpg.
      Dans ce cas, il faut un alt qui permette de savoir que c'est lien vers une page d'image. Par exemple, par le biais des modèles idoines, Drapeau de la France a pour alt « Drapeau de la France » et pas « France » tout court. C'est le cas qui, normalement, ne devrait pas se produire dans les articles sauf pour des choses comme les drapeaux, et qui fait que le gadget met souvent du rouge partout.
    • On ne met un paramètre link avec le nom d'un article, d'une page meta ou d'une page externe derrière ([[Fichier:truc bidule.png|alt=truc bidule|link=article truc]]) que si on veut que l'image devienne un lien vers une page particulière :
      [[Fichier:Gnome-preferences-desktop-accessibility.svg|alt=Atelier accessibilité|link=Wikipédia:Atelier accessibilité|16px]] donne Atelier accessibilité qui est un lien automatique vers Wikipédia:Atelier accessibilité.
      Dans ce cas, il faut un alt qui permette de savoir quel est sa cible, ici « alt=Atelier accessibilité ». C'est plutôt un cas qu'on rencontre en dehors des articles.
    • On ne met un paramètre link vide ([[Fichier:truc bidule.png|alt=truc bidule|link=]]) que si on veut que l'image ne soit pas un lien, ni vers le fichier ni vers autre chose. On ne doit le faire que si c'est une image du domaine public ou une image mentionnée dans Wikipédia:Crédits graphiques :
      [[Fichier:Commons-logo.svg|alt=|link=|16px]] donne qui n'est pas un lien.
      Dans ce cas, le alt sera vide ou pas selon que l'image apporte ou non une information qui n'est pas déjà dans le texte où elle se trouve. C'est un cas fréquent dans les bandeaux, a priori pas pour des images de contenu dans les articles.
Cordialement, --Lgd (d) 28 novembre 2010 à 16:25 (CET)
Un grand merci Lgd pour ces explications éclairantes. Udufruduhu (d) 28 novembre 2010 à 23:31 (CET)

Boujour, je n'ai pas résisté à la tentation de faire bénéficier tout le monde de cette belle démonstration, à peine retouchée sur la forme, sur la page des Recommandations sur la mise en forme des images Aide:Image cliquable (déplacé, voir ci-dessous). Merci de relire au cas où... mais je crois avoir (enfin) tout compris Clin d'œil. --Amicalement, Salix ( converser) 28 novembre 2010 à 19:35 (CET)

J’aimerais tout de même attirer l’attention sur une différence entre les deux codes (truc bidule précédé ou non du alt=) :
[[Fichier:Exemple.jpg|truc bidule]] donne <a href="/wiki/Fichier:Exemple.jpg" class="image" title="truc bidule"><img alt="truc bidule" src="http://upload.wikimedia.org/wikipedia/fr/a/aa/Exemple.jpg" height="60" width="60"></a>
[[Fichier:Exemple.jpg|alt=truc bidule]] donne <a href="/wiki/Fichier:Exemple.jpg" class="image"><img alt="truc bidule" src="http://upload.wikimedia.org/wikipedia/fr/a/aa/Exemple.jpg" height="60" width="60"></a>
Le code HTML généré diffère, sans le alt=, la balise a est agrémentée de titre="truc bidule", mention qui est absente en cas d’usage du alt= (du moins alt= seul sans « double définition » du genre [[Fichier:Exemple.jpg|truc bidule|alt=truc chose]])
Le problème est que cela changera tout en fonction du navigateur de l’utilisateur, en effet, sans le title= généré, Firefox n’affichera aucun phylactère lors du passage du pointeur de la souris sur l’image, alors que certaines versions d’Internet Explorer l’affiche tout de même (non ce n’est pas Firefox qui est en faute, c’est IE6/7 qui faisaient quelque chose qu’ils n’étaient pas supposés faire, et pour preuve, IE8 n’affiche plus le phylactère non plus, sauf lorsqu’on clic sur l’icône « page brisée » à l’extrême droite de la barre d’adresse, afin de passer en mode « compatibilité des anciennes versions de IE, connues pour être moins respectueuses des normes du W3C »). Bref, en ajoutant alt= devant la légende, on risque d’être moins accessible dans certains cas… Il faudrait bien entendu tester en combinaison avec link= et d’éventuels autres cas spécifiques. La prudence est donc de mise ! — MetalGearLiquid [m’écrire] 3 décembre 2010 à 05:56 (CET)
Les explications sur ce point figurent déjà dans Aide:Image cliquable. Cordialement, --Lgd (d) 4 décembre 2010 à 09:00 (CET)
Merci pour ce lien, je ne connaissais pas encore cette page, gageons que l’ajout du lien permettra à d’autres wikipédiens qui passent par ici d’en prendre connaissance. Cordialement, — MetalGearLiquid [m’écrire] 10 décembre 2010 à 10:44 (CET)

On peut... mais faut-il ?[modifier | modifier le code]

On peut (techniquement) faire un lien sur une image avec "link", ok. Mais peut-on l'utiliser dans main ? Et si oui, doit on encourager son usage dans main (en expliquant comment dans cette recommandation) ? --MGuf (d) 28 novembre 2010 à 19:41 (CET)

C'est pour ça que je ne l'ai pas mis sur Aide:Insérer une image. Mais on peut aussi l'expliquer sur Aide:Image cliquable si vous préférez. --Amicalement, Salix ( converser) 28 novembre 2010 à 19:59 (CET)
Je suis d'avis de laisser ce qui se rapporte à "alt", et d'enlever ce qui porte sur "link" : on atteint là une complexité élevée, et je pense que ça apporte plutôt confusion que clarté. --MGuf (d) 28 novembre 2010 à 20:18 (CET)
Ce n'est peut-être pas le meilleur endroit en effet mais il faut bien l'expliquer qq part, et surtout rappeler qu'« un link ne dispense pas d'un alt ». Je vais le transférer par là si ça vous convient. --Amicalement, Salix ( converser) 28 novembre 2010 à 20:57 (CET)
Fait pour être certaine de ne pas l'oublier... --Amicalement, Salix ( converser) 28 novembre 2010 à 21:35 (CET)
Vu, très bien. --MGuf (d) 28 novembre 2010 à 21:37 (CET)
Les choses n'étant malheureusement jamais aussi simples qu'il le faudrait, j'ai complété rapidement sur un aspect oublié, le alt implicite ou explicite. Cordialement, --Lgd (d) 29 novembre 2010 à 07:05 (CET)

"Title"[modifier | modifier le code]

Bonjour,

Le Modèle:Icône de titre est très utilisé. Or il contient un span inutile (extrait du code du modèle : <span title="{{{Texte|exemple de texte}}}">[[Fichier:{{{Image|Fairytale bookmark.png}}}|{{{Taille|20}}}px|link={{fullurl:{{{Lien|Modèle:Icône de titre}}}|{{{Paramètre|}}}}}|alt={{{Texte|exemple de texte}}}]]</span> )

Je transformerai bien cet extrait en :

[[Fichier:{{{Image|Fairytale bookmark.png}}}|{{{Taille|20}}}px|link={{fullurl:{{{Lien|Modèle:Icône de titre}}}|{{{Paramètre|}}}}}|alt={{{Texte|exemple de texte}}}|{{{Texte|exemple de texte}}}]] (suppression du span et ajout de {{{Texte|exemple de texte}}} à la fin).

Or il semble que la gestion par MediaWiki de cette partie ajoutée varie assez souvent. Es ce donc une bonne idée de réaliser ce(s) changement(s) ? --Manu1400 (d) 27 novembre 2010 à 12:27 (CET)

Ne pas toucher, pas de problème urgent. --Lgd (d) 27 novembre 2010 à 13:24 (CET)

Gadget Accessibilité version 1.0[modifier | modifier le code]

Sous Firefox 3.6.8 sur Mac, si on "replie" le menu du Gadget, il y a "fusion" avec le menu suivant "Contribuer" (qui se retrouve alors à droite très légèrement en dessous de "Accessibilité" (test effectué avec vector.css vide).

Cela semble venir de #p-accessibility h5 {float:left; } mais si on enlève ce dernier la case à cocher "fixer" se retouve au mauvais endroit. --Anneyh (d) 27 novembre 2010 à 14:40 (CET)

Fait en dev. la correction sera mise en production lors de la prochaine version. Tant que j'y étais, c'est fait en même temps que l'oubli ci-dessous. --Lgd (d) 27 novembre 2010 à 14:52 (CET)

Bon, mon retour d'expérience vite fait :

  1. T'as corrigé le bug du gadget fixé ? Parce que ca le déplace toujours en haut quand je clique sur le carré. --'toff [discut.] 27 novembre 2010 à 18:55 (CET)
  2. Bug sur le {{drapeau|Slovaquie}} : Drapeau de la Slovaquie

--'toff [discut.] 27 novembre 2010 à 18:55 (CET)

  1. Fait Oups... j'avais juste oublié de porter ce correctif là lors de la mise en ligne ce matin, c'est réparé (actualiser le cache, etc.) Désolé !
  2. Pour le drapeau Slovaquie, l'alerte « L'alternative devrait commencer par « Drapeau... » ou « Pavillon... » » est normale : l'alternative ne commence pas par « Drapeau » ce qui ne permet pas d'identifier exactement vers quoi pointe le lien sur l'image (la page de l'image ou par exemple la page de l'article sur le pays) (voir plus haut). Il reste quelques modèles de pays à corriger de ce type (je vais voir ça).
Cordialement, --Lgd (d) 27 novembre 2010 à 19:23 (CET)
Merci. --Anneyh (d) 27 novembre 2010 à 19:40 (CET)
Heureusement que je veille ! Clin d'œil Merci, ça fonctionne. --'toff [discut.] 27 novembre 2010 à 20:35 (CET)
Pour le drapeau, je comprends et je viens de faire la modif adéquate. Si j'en vois d'autres passer par hasard, je m'en occupe. --'toff [discut.] 27 novembre 2010 à 20:45 (CET)

Alternatives aux images dans les modèles Infobox Université et Coord[modifier | modifier le code]

Si j'utilise le gadget sur Université de Heidelberg, j'ai deux erreurs :

  1. ALT VIDE pour le modèle coord,
  2. "Vérifiez si le lien sur l'image peut être désactivé (LINK vide) (ou si l'image peut être transformée en thumb)" pour le Logo dans l'infobox.

C'est grave, Docteur ? --Anneyh (d) 27 novembre 2010 à 15:33 (CET)

  1. Sauf changements récents, l'icône-lien du globe dans le modèle {{coord}} est générée par un script sur lequel fr.wp n'a pas la main (celui-ci) et qui pose d'autres problèmes par ailleurs. C'est un problème connu, mais dont la correction éventuelle n'est pas du ressort des contributeurs.
  2. Comme pour toutes les images « illustrative d'un article entier », celle-ci ne devrait pas être dans un tableau de données clés type infobox, mais en dehors de celui-ci, et sous la forme en effet d'un thumb. Mais c'est un vaste chantier, celui d'une refonte future des infobox.
Je n'ai pas tout vérifié en détail, mais apparemment et compte-tenu de ces quelques difficultés incontournables, Université de Heidelberg est plutôt un article qui passe bien les exigences d'accessibilité.
Cordialement, --Lgd (d) 27 novembre 2010 à 15:43 (CET)
Merci, je ne touche à rien alors... Merci. --Anneyh (d) 27 novembre 2010 à 15:58 (CET)

est-ce bien ?[modifier | modifier le code]

Bonjour.Je suis allée dans ma page preferance et gadjets . J'ai coché sur tout les gadjets . Est-ce bien ?--MiniRobot (d) 3 décembre 2010 à 20:33 (CET)

Je ne suis pas sûre de comprendre ta question. Tous les gadgets, ça fait peut-être beaucoup, mais à toi de voir.
Il y a pas mal de gens qui ont activé le gadget accessibilité, mais si tu as un problème précis avec ce gadget ou si tu n'es pas sûre de comment traiter les suggestions, c'est bien ici qu'il faut demander. --Anneyh (d) 3 décembre 2010 à 22:16 (CET)

Hockey et accessibilité[modifier | modifier le code]

Bon, pour le plaisir (et mon ego personnel Clin d'œil ) je vous informe que tous les articles labellisés (AdQ et BA) du Projet:hockey sur glace ont été rendu accessibles pour toutes les options du gadget ainsi que pour quelques abréviations. Il doit bien évidemment rester quelques erreurs et oublis mais par rapport au désert précédent, c'est un grand pas en avant. J'ajoute que l'essentiel des contributeurs réguliers du projet sont maintenant sensibilisé et créent dorénavant leur nouveau articles avec un minimum d'accessibilité (les tableaux par exemple). Voilà, c'était mon petit grand plaisir personnel du jour. Je retourne à mes moutons. --'toff [discut.] 4 décembre 2010 à 04:47 (CET)

Hé ? Tu t'en vas pas pour toujours d'ici, dit ? Les moutons, c'est bien, mais bon, ça manque un peu de conversation. Remarque, un palet de hockey, ça doit pas en avoir des masses non plus je suppose... (je suis déjà sorti).
Un grand bravo pour ce double travail d'amélioration et de sensibilisation ! Cordialement, --Lgd (d) 4 décembre 2010 à 17:25 (CET)
L'avantage de la sensibilisation, c'est que j'aurai moins de travail d'amélioration ! Clin d'œil Une petite question sur les drapeaux, plutôt que de créer les modèles (dont on a parlé il y a quelques temps) pour le Massachusetts, je me suis contenté de modifier {{Massachusetts}} en incluant l'alternative. Ça peut suffire ? Et, non, non, je m'en vais pas, j'ai cette PdD dans ma liste de suivi, mais je viendrai moins vous embêter maintenant que j'ai des notions de base !--'toff [discut.] 4 décembre 2010 à 22:52 (CET)
Un grand bravo. :-) Dodoïste [ dring-dring ] 5 décembre 2010 à 00:03 (CET)
Merci Tout rouge fausse modestie--'toff [discut.] 5 décembre 2010 à 01:11 (CET)

J'ai passé en revue rapidement une dizaine d'articles labellisés, et c'est vraiment très bon. J'ai vu seulement deux détails, assez complexes mais qu'il est temps d'aborder.

  1. Dans Ligue nationale de hockey#Équipes actuelles, le tableau contient des titres de colonnes en milieu de tableau. Or, lorqu'on indique un titre de colonne, il est associé à toutes les cellules correspondantes, jusqu'en bas du tabelau. Donc, si un autre titre de colonne se trouve au milieu, les cellules du bas sont associés à deux titres différents en même temps. Visuellement, le tableau est coupéé en deux, mais sémantiquement ce n'est pas le cas, donc un aveugle va avoir de la peine à se dépatouiller. Par exemple, la cellule "Blackhawks de Chicago" est à la fois parmi les "Conférence de l'Est" et les "Conférence de l'Ouest" ! Il faudrait séparer le tableau en deux tableaux distincs.
    Fait Pas de soucis. --'toff [discut.] 5 décembre 2010 à 01:11 (CET)
    Parfait. Dodoïste [ dring-dring ] 5 décembre 2010 à 06:05 (CET)
    Il faut que j'ajoute au gadget une détection de ce cas de figure (c'est noté). Cordialement, --Lgd (d) 5 décembre 2010 à 07:34 (CET)
    C'est en fait un immonde merdier. Mais ça le fera. Cordialement, --Lgd (d) 5 décembre 2010 à 11:59 (CET)
  2. Dans Eagles de Saint-Louis#Joueurs, les trois tableaux qui indiquent les légendes sont à revoir. Soit on en fait des tableaux de données, avec titres et tout, mais dans ce cas on n'a que deux cellules par ligne (terme défini, et sa définition) dans chaque tableau. Soit on fait un tableau de mise en forme, et on enlève le titre du tabelau (caption, « |+ »). Soit on en fait une liste de défitinion correcte (: et ;), ce qui est le plus correct sémantiquement, mais aussi le plus gros changement visuel pour les wikipédiens.
    Tableau supprimé (cétait joli mais pas accessible) et remplacé par les abréviation directement dans les titres de colonnes. Ca le fait ? --'toff [discut.] 5 décembre 2010 à 01:11 (CET)
    Ah oui, très bien vu l'usage des abréviations. C'est la solution la plus simple et efficace, et j'y avais pas pensé. :-) Dodoïste [ dring-dring ] 5 décembre 2010 à 06:05 (CET)
    (encore) une idée de Lgd après avoir relu les Blackhawks de Chicago que je mets en place régulièrement maintenant. --'toff [discut.] 5 décembre 2010 à 07:22 (CET)

Avis bienvenus. Dodoïste [ dring-dring ] 5 décembre 2010 à 00:20 (CET)

Très joli en effet, l'utilisation des abréviations est une nette amélioration. J'ai deux petites questions :
  1. Dans l'infobox, le logo a un attribut link= ce qui fait qu'il n'y a pas de lien vers Fichier:Eagles de Saint-Louis.gif, est-ce normal ?
  2. Dans certains tableaux, il y a des colonnes vides qui font toute la hauteur avec scope=col. Cela me rappelle les bon vieux spacer.gif du temps des mises en pages en tableau. J'aimerai juste comprendre comment cela est vu dans les différents contextes utilisateur (vide donc ignoré ?).
Merci. --Anneyh (d) 5 décembre 2010 à 10:44 (CET)
  1. infobox et logo : c'est effet gênant, cela peut coincer aux yeux des contributeurs pour ce qui est de l'accès à l'auteur de l'image. Mais comme souvent dit, ce sont les infobox qui sont entièrement à revoir, leur code HTML actuel est dénué de sens à différents points de vue. Un peu de patience, voyons ce que va entraîner l'utilisation du gadget de ce côté : j'ai une idée précise d'une refonte des infobox qui ménage le rendu actuel mais avec un code pertinent et notamment une utilisation appropriée de thumb restylés. Mais une chose après l'autre, surtout pour celle-là en particulier Mort de rire.
  1. Pour info, le projet hockey a décidé de mettre les thumb dans l'infobox consacrée aux joueurs. On considère que le rendu n'est pas plus laid et que c'est un plus (facile) pour l'accessibilité (voir là par exemple. --'toff [discut.] 5 décembre 2010 à 18:11 (CET)
  1. les colonnes scope col qui font toute la hauteur : pas d'impact effectif dramatique sur l'accessibilité, même si cela n'est pas élégant ni satisfaisant. Il faut regarder du côté d'une scission de ces tableaux en deux, éventuellement côte à côte (voir le dev suggéré dans la section Tableau ci-dessus) ou sinon remplacer par un simple TD. Mais pas d'urgence.
  1. L'avantage, s'il en est un, c'est que le lignes des colonnes sont d'égale hauteur (ce qui n'est pas forcément le cas avec le dev plus haut) sans surcharger le code. --'toff [discut.] 5 décembre 2010 à 18:16 (CET)
Pour l'utilisation de abbr dans les en-têtes de colonne de tableau: c'est à vendre massivement à tous les projets ayant un rapport quelconque avec le sport, très amateurs de tableaux totalement indéchiffrables pour qui n'est pas un passionné wikipédien Mort de rire.
Cordialement, --Lgd (d) 5 décembre 2010 à 11:58 (CET)
Oui. Mais le code actuel nécessaire est bien trop complexe pour rencontrer un franc succès. Pourquoi avoir limité l'usage du modèle abréviation aux modèles ? Ça simplifierait la vie de pouvoir l'utiliser dans les articles. Ou on fait un second modèle pour les articles ? Dodoïste [ dring-dring ] 5 décembre 2010 à 13:01 (CET)
heu... Où est-ce limité aux modèles ? ah... tu pensais peux-être à quelque-chose comme cela ? On ne va quand même pas créer un modèle dans ce cas, non ? Cordialement, --Lgd (d) 5 décembre 2010 à 13:10 (CET)
Oui, c'est bien à {{abréviation}} - utilisé pour rempalcer le modèle info - que je pensais. Il est très bien. Mais puisqu'il enlève le soulignement il n'est pas adapté aux tableaux dans les articles. Après, quand à savoir si il faut créer un autre modèle ou non, c'est à toi de savoir si il n'y a que quelques personnes qui sont censés l'utiliser, ou si des contributeurs non familiers avec la syntaxe HTML sont aussi censés le faire. Par exemple, la première fois que Égoïté a vu cette syntaxe, elle a répondu « euh ? ». L'avantage d'un modèle, c'est qu'on peut ui associer une documentation utile et précise. Même si elle n'est pas toujours lue. Dodoïste [ dring-dring ] 5 décembre 2010 à 18:23 (CET)
Mouif. Dans ce cas, disons qu'il faudrait récupérer le nom de modèle {{abréviation}}. Mais quand je vois des gens faire « heu ? » devant <abbr title="..."></abbr>alors qu'ils utilisent régulièrement <ref></ref> et autres <ref name="..." />, j'avoue ne pas être vraiment convaincu. Cordialement, --Lgd (d) 5 décembre 2010 à 18:31 (CET)

Je n'ai peut-être simplement pas compris la réponse, mais pourquoi faut-il laisser l'attribut link= pour l'image du logo dans {{Infobox Équipe de hockey sur glace}} ? Ajoute-t-il quelque chose pour compenser la rupture d'accès à la page du fichier ? — Riba (discuter) 5 décembre 2010 à 15:10 (CET)

Langue dans un [long] tableau[modifier | modifier le code]

Bonjour,

Es ce possible de préciser que tout ce qui est dans une certaine colonne d'un tableau est dans telle langue ? (question qui pourrait être posée à la Guilde) --Manu1400 (d) 5 décembre 2010 à 22:00 (CET)

Non, ce n'est pas possible. La langue doit être indiquée pour le contenu de chaque cellule concernée. Cordialement, --Lgd (d) 5 décembre 2010 à 22:02 (CET)

Vérification[modifier | modifier le code]

Bonjour. Je souhaite votre aide pour savoir si cette section est correctement rédigée du point de vue de l’accessibilité. Merci déjà, --Égoïté (d) 9 décembre 2010 à 09:12 (CET)

Rapidement : les généalogies ne peuvent pas actuellement être rendues accessibles, qu'elles soient sous forme d'art ASCII comme celle-ci ou sous forme de tableaux de mise en forme comme beaucoup d'autres. Un arbre généalogique sous forme d'image éviterait de parasiter le contenu avec des choses qui n'ont pas de sens sans la mise en forme (et donc par exemple pas dans un lecteur d'écran), mais impose trop de contraintes pour les contributeurs et pose le problème de l'alternative. Il y aura des solutions par la suite, avec l'amélioration des formats utilisables (SVG, ARIA) mais cela fait partie des choses à long terme.
Tout au plus pourrait-on mettre en place un moyen de contournement du bloc d'art ASCII, comme demandé par WCAG dans ce cas... A voir (je me le note). Cordialement, --Lgd (d) 9 décembre 2010 à 09:50 (CET)
Merci LgD. Autre question : serait-il problématique d’utiliser le modèle citation dans un tableau ? voir [1]. Peux-tu aussi jeter un œil sur ta boite mail ? Merci déjà, --Égoïté (d) 9 décembre 2010 à 11:45 (CET)
Côté accessibilité, non, bien au contraire dans ce cas avec un {{Citation bloc}} ou {{citation début}} etc. Côté rendu, ça va juste créer des marges supplémentaires dans la cellule du tableau, mais sans que ce soit dramatique. On pourrait éventuellement coder les styles qui vont bien dans common.css pour améliorer ce détail.
Ce qui est plus un souci dans ces articles sur les Fées, c'est le modèle {{Encadré}} : il faudrait déjà corrigr le code pour qu'il balise correctement en tant que citation (sauf qu'il n'est pas toujours utilisé pour une citation). Mais il pose autre un problème purement éditorial : un texte utilisé comme une illustration, dont la mise en contexte est laissée largement au hasard, là où le simple fait de mettre la citation dans le fil du texte (avec {{Citation bloc}} ou {{citation début}} etc.) obligerait à travailler davantage cette mise en contexte (et en fait bien souvent à supprimer le texte concerné). Il fut un temps où j'avais prévu de l'euthanasier dans les articles, à vrai dire.
Mail : j'ai vu, je fais ça dès que j'ai un peu plus de temps ce soir ou demain. Cordialement, --Lgd (d) 9 décembre 2010 à 12:21 (CET)
Merci pour toutes tes réponses. Pour le « point de vue » éditorial, je te rejoins totalement. Amclt, --Égoïté (d) 9 décembre 2010 à 12:27 (CET)
Tu ne m’oublies pas ? Modèle:Timide --Égoïté (d) 11 décembre 2010 à 09:01 (CET)
Je ne suis pas sûr d'avoir bien saisi, en fait.J'ai corrigé quelques détails dans Viticulture, qui ne pose pas de souci majeurs pour le reste. Cordialement, --Lgd (d) 11 décembre 2010 à 10:03 (CET)
Ah, ayé, compris Mort de rire. Tableaux et citations étaient bien faits, il y avait déjà le problème de liste que j'ai corrigé sur la version actuelle. Cordialement, --Lgd (d) 11 décembre 2010 à 10:49 (CET)
Mort de rire Merci Lgd, --Égoïté (d) 13 décembre 2010 à 07:48 (CET)