|
Discussion Wikipédia:Atelier accessibilité/Archives accessibilité 2008Accessibilité, qu'est-ce que ça veut dire ?Bonjour et merci pour cette initiative. Mais juste un mot « Pourriez-vous rendre
copié depuis Discussion Utilisateur:Lgd Tu voulais passer sur le portail:réalisation audiovisuelle pour m'aider à le rendre accessible. Ce n'est pas le portail le plus visité, c'est sûr, mais, si ça peut en aider un ... Tiens moi au jus ෴ Steƒ ( Стеф ) 26 avril 2008 à 20:59 (CEST)
Op, j'ai commencé le travail par les tâches les plus simples, je verrais ce que je peux faire pour linéariser les tableaux par la suite. — Steƒ ( Стеф ) 30 avril 2008 à 18:32 (CEST) Evaluation (rapide) d'une boitedéplacé de Discussion Utilisateur:Lgd Pardon de te déranger, j'aimerais juste un avis rapide sur Utilisateur:Bayo/IJV accessibilité (par de discussion pour une usage), me dire par exemple dans quelle direction creuser. J'ai testé avec Fongs, ca me semble assez correcte. Je ne sais pas bien s'il vaut mieux que je place cette demande sur la page de l'infobox V2 (qui je pense devrait un peu décanter) ou et l'atelier accessibilité. Dis-moi si je déplace cette demande, merci. bayo 29 avril 2008 à 15:31 (CEST)
Pour information, les cinq infoboxs cinéma possèdent désormais la syntaxe "plus accessible" élaborée par lgd — Steƒ ( Стеф ) 30 avril 2008 à 17:53 (CEST)
En retouchant le premier, je me suis demandé s'il ne serait pas pratique de remplacer le
Fausse carte cliquable à corriger, si quelqu'un s'ennuie... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Contexte utilisateur | Résultat | Commentaire |
|---|---|---|
| Sans javascript |
|
 dans Utilisateur:Lgd test/test rendu Géoloc dynamique
|
| Sans CSS |
|
 non corrigeable (nécessite le passage à des images complètes intégrant le pointeur)
|
| lecteur d'écran |
|
le pointeur est finalement un pseudo-contenu CSS. En revanche, les cartes ont pour alternative par exemple "Foo sur la carte administrative", ce qui est trompeur et totalement inapproprié... |
| lecteur d'écran |
|
le lien reprend l'alt de chacune des deux images de cartes, du type: "Foo sur la carte administrative"
|
| Désactivation des couleurs |
|
non corrigeable (nécessite le passage à des images complètes intégrant le pointeur)
|
| Agrandissement de la taille de caractères |
|
accessible
|
| Accès au clavier |
|
accessible
|
| Niveaux de contrastes |
|
accessible
|
- C'est vraiment pas mal leur système. Sinon il me semble assez curieux de ne mettre qu'un lien pour passer d'une image à une autre. Deux liens séparés me semblerais quand même visuellement plus explicite que se soit pour connaitre l'état ou savoir ce que l'on peut/veut faire.
- Une autre solution pour le problème des deux cartes, serait de faire ajouter la deuxième par justement le javascript, ou tout du moins de la démasquer.
- Pour la négociation là bas, bon courage... bayo 22 mai 2008 à 10:48 (CEST)
- <passage en coup de vent> Oui, deux liens séparés (enfin, un lien actif et un libellé qui sert également, du coup, de titre à la carte en cours), ce serait de toutes façons plus ergonomique, au-delà de l'accessibilité.
- Faire ajouter la carte via javascript, ce serait un peu la solution "pauvre", mais possible. Est-ce que ça ne spécialise pas encore un peu plus le JS à cette seule infobox communes et lieux de France ? Le javascript doit appeler l'url de l'image, le modèle fournit pour l'instant le nom de la page de l'image... Souci ? (je n'ai pas regardé en détail).
- Sinon, c'est une modification assez profonde du modèle: deux cartes de géolocalisation successives, que le javascript "met en boîte".
- Quoi qu'il en soit, je crains que ce ne soit un modèle à faire évoluer après coup, ou en faisant des modifs "techniques" sans changement de rendu. Côté pédagogie, c'est un peu... disons... loupé pour l'instant, je dois le reconnaître
- Plus sérieusement, la géolocalisation actuelle, avec son contenu généré CSS, est un problème d'accessibilité lourd, mais qu'on ne pourra AMHA résoudre qu'en amenant une extension ad hoc générant les images géolocalisées à partir d'une image de fond de carte, des coordonnées longitudes/latitudes et du mode de projection. De la génération d'image côté serveur comme le fait déjà timeline par exemple. Avec un coût côté serveur (pas dramatique) et côté bande passante. En attendant, j'aurais aimé éviter de nouveaux problèmes d'accessibilité s'ajoutant au problème de fond, mais bon. A voir, pour l'instant, je suis ça en lâchant prise... --Lgd (d) 22 mai 2008 à 19:42 (CEST)
Infobox race et infobox V2
Bonjour, en s'inspirant de Catégorie:Modèle infobox race animale je dois créer un modèle « Race de lapin », et ensuite viendront d'autres du même type, pour harmoniser les articles sur les races d'élevage. J'avais commencé à créer un modèle adaptable à tous les cas, avec en bas un exemple sur les lapins, en faisant du copier/coller/bidouiller car ce n'est pas mon fort 
). Vincnet a aussi cogité sur le sujet sur l'une des ses pages. Afin de (re)partir sur de bonnes bases d'accessibilité et de répondre aux éxigences des infobox V2, que suggèrez-vous? Je vois que le Modèle:Infobox Race de chien a été repris. Est-ce correcte? Comment puis-je l'adapter? Esprit Ldg es-tu là ?. --amicalement, Salix ( converser) 18 mai 2008 à 21:16 (CEST)
- Hum... J'avais commencé à regarder les taxobox qui sont construites sur le principe adopté par Vincnet pour les biolobox de son essai, mais faute de temps, je n'ai pas encore vraiment de modèle à proposer. Il faudrait voir du côté de ce qu'Hexasoft a fait pour en alléger le code en recourant à CSS, qui serait déjà un bon point de départ. C'était en discussion dans le café des biologistes, mais je sais pas trop où ça en est actuellement.
- Pour le moment, ce que je vois dans Utilisateur:Vincnet/Boite est assez délicat à paramétrer pour l'accessibilité, comme les taxobox : on est souvent dans le cas des « en-têtes de colonnes intermédiaires » qui nécessitent un code assez abominable pour les auteurs de modèle. j'aimerais beaucoup trouver une solution plus légère, peut-être sous la forme de plusieurs tableaux simples successifs au lien d'un seul tableau complexe. Voir sans tableau du tout. Il faut voir ce qu'en penserait Vincnet et s'il est intéressé par un coup de main éventuel.
- Sinon, pour essayer de donner un point de départ sur les autres pistes:
- J'ai corrigé {{Infobox Race de chien}} pour améliorer son accessibilité
- Ci-dessous, les boîtes de ton essai Utilisateur:Salix/Essai de box universelles (race et variété) corrigées (j'espère ne pas avoir trop modifié le rendu, c'est un peu vite fait. Il y a d'ailleurs un doute selon le navigateur sur le rendu souhaité: c'est avec ou sans bordures intérieures ?) :
| {{{nomrace}}} | |
| [[Image:{{{Image}}}|250px|center|nomrace]] | |
| Race de ???? issue de l'espèce : | |
| Origine | Pays/Région |
|---|---|
| Diffusion | Mondiale/Nationale/Régionale/Locale/Protégé |
| Taille | Grande/Moyenne/Petite |
| Robe | couleurs/motifs/longueur |
| Utilisation | Agrément/alimentation/santé/symbole/industrie |
| Autres races de la même espèce : | |
| Liste des races de ... | |
| Voir aussi Catégorie: Races de ... | |
 vous trouverez d'autres documents sur[[commons:{{{1}}}|cette race]] sur Commons. | |
| {{{nomsubdivision}}} | |
| [[Image:{{{Image}}}|250px|center|nomsubdivision]] | |
| Variété(ou autre) de ???? issue de l'espèce : | |
| Origine | Pays/Région |
|---|---|
| Diffusion | Mondiale/Nationale/Régionale/Locale/Protégé |
| Critère3 | choix1/choix2/choix3... |
| Critère4 | choix1/choix2/choix3... |
| et plus | ... |
| {{{nomrace}}} | |
| [[Image:{{{Imagelapin}}}|250px|center|Race de lapin]] | |
| Race de Lapin domestique issue de l'espèce : Oryctolagus cuniculus (Linnaeus, 1758) | |
| Origine | Pays/Région |
|---|---|
| Diffusion | Mondiale/Nationale/Régionale/Locale/Race préservée |
| Taille | Géante/Moyenne/Naine |
| Robe | Unie/Tachetée/Pointée/???/Blanc |
| Poils | Angora/Tête de lion/Courts/Duveteux |
| Oreilles | Longues/Tombantes/courtes |
| Utilisation | Culinaire/Vestimentaire/Compagnie |
| Autres races de lapins domestiques : | |
| Liste des races de lapins | |
| Voir aussi Catégorie: Race de lapin | |
- une dernière possibilité serait d'utiliser qui est en cours sur l'amélioration des InfoboxV2 (voir ces exemples après avoir ajouté l'appel de CSS qui va bien dans ton monobook.css personnel Utilisateur:votre_pseudo/monobook.css) : pour le coup, le code est nettement meilleur pour l'accessibilité (utilisation de
captionen plus descope) et plus efficace en terme de séparation structure/présentation, ce qui permet de varier le rendu plus facilement.
- une dernière possibilité serait d'utiliser qui est en cours sur l'amélioration des InfoboxV2 (voir ces exemples après avoir ajouté l'appel de CSS qui va bien dans ton monobook.css personnel Utilisateur:votre_pseudo/monobook.css) : pour le coup, le code est nettement meilleur pour l'accessibilité (utilisation de
- Dans tous les cas, l'idée générale pour l'accessibilité de ces infobox, c'est:
- pas de tableaux imbriqués qui aboutissent souvent à quelque-chose de très difficile ou d'impossible à comprendre dès que l'on a plus le support visuel complet pour s'aider (utilisateurs de lecteurs d'écran, mais aussi dans certains cas d'autres utilisateurs voyants n'ayant pas le rendu CSS).
- n'utiliser les en-têtes
!que pour les en-têtes de ligne, donc là où il y a deux cellules côte à côte et que la première explicite la seconde, en précisant bien les! scope=row. Dans ce cas, ils doivent systémtiquement être présents. - utiliser des cellules normales et des styles CSS pour la ligne de titre principale de l'infobox et les autres lignes roses et vertes:
| style="background:pink;text-align:center;font-weight:bold"par exemple : ce ne sont pas des en-têtes qui s'appliqueraient à la totalité d'une colonne du tableau. Pour faire mieux, utilisercaptionpour la ligne de titre principale de l'infobox (mais il est plus délicat à mettre en forme visuellement
- Voilà voilà... Je reste à l'écoute (mais je serais peu présent cette semaine, étant en déplacement). Amicalement, --Lgd (d) 19 mai 2008 à 07:09 (CEST)
- Merci beaucoup pour cette première approche. Je ne suis par sûr de tout comprendre mais cela devrait me permettre de faire avancer le
shimlsmilibliSchmilblick avec les autres contributeurs. --amicalement, Salix ( converser) 19 mai 2008 à 11:44 (CEST)- Oui désolé, les taxo/biolo-box sont un beau problème. Pars de ton essai corrigé, AMHA. --Lgd (d) 19 mai 2008 à 12:36 (CEST)
- Merci beaucoup pour cette première approche. Je ne suis par sûr de tout comprendre mais cela devrait me permettre de faire avancer le
- Avant tous je pense qu'il est nécessaire de choisir entre uj modèle commun ou un modèle pour chaque animaux, et les différentes sous-parties qui compose cette infobox et sont contenu.--— Pako- 15 juin 2008 à 18:01 (CEST)
- je pense qu'il est préférable d'avoir un sous-modèle commun qui soit conforme aux chartes graphique, et différent modèles plus simple à utiliser. ce système permettrait de créer des boites facilement évolutive, vu la diversité des situations. Vincnet G discuss 15 juin 2008 à 18:14 (CEST)
- Les catégories sont inutile dans une infobox, sous quel forme les sous-modèle? oon insère suivant l'animal un sous-modèle aux modèle general ou le modèle general dans le modèle spécifique ? personnellement je suis plus pour le 1er choix.--— Pako- 15 juin 2008 à 18:17 (CEST)
- je pense qu'il est préférable d'avoir un sous-modèle commun qui soit conforme aux chartes graphique, et différent modèles plus simple à utiliser. ce système permettrait de créer des boites facilement évolutive, vu la diversité des situations. Vincnet G discuss 15 juin 2008 à 18:14 (CEST)
Gadget à développer pour faciliter les tests d'accessibilité
Pour tester rapidement l'accessibilité d'un tableau (présence du caption, des scope, id et headers), j'ai bricolé un petit outil grâce aux monobooks CSS et javascript qui montre ces informations juste en passant la souris sur le tableau.
Peut-être pourrait-on transformer cela en gadget pour que ce soit facilement utilisable. Pour cela, il faudrait modifier le script utilisé afin d'ajouter une barre d'outils « accessibilité » et un premier bouton permettant d'activer ou de désactiver l'inspection des tableaux (c'est assez infernal quand c'est actif en permanence mais qu'on fait autre chose dans les articles 
). Je pense à une barre d'outils, car d'autres scripts du même type sont à prévoir, plus des liens vers certains outils externes. Des avis, des gens intéressés ? --Lgd (d) 19 mai 2008 à 07:44 (CEST)
- Bonjour. Je viens donc d'en faire un gadjet, ca ne mange pas de pain. C'est accessible par Préférences > Gadjets > Outils avancés > dernière case à cocher. Ce qui affiche une portlet supplémentaire. Voici les fichiers :
- J'ai fait en sorte que se soit facilement extensible avec son monobook, de telle sorte que l'on peut prototyper de nouvelles fonction JavaScript avant de demander à un admin de rajouter le truc (ça peut soulager). Par exemple le code suivant dans son monobook :
accessibilityTools["foo()"] = "Inspection toto";- pardon d'être trivial :) ajoute un outil décrit par « Inspection toto » et appel la function
foo()quant on clique dessus. S'il faut changer des trucs, rajouter des trucs, n'hésitez pas. bayo 22 mai 2008 à 12:20 (CEST)- Excellent. J'ai quelques stagiaires en accessibilité qui vont cogiter sur de nouveaux « toto » demain, je sens. --Lgd (d) 22 mai 2008 à 19:45 (CEST)
Accessibilité des boîtes déroulantes
Bonjour, de plus en plus de contributeurs souhaitent mettre les listes trop longues ou les "Notes et références" dans des boîtes déroulantes. Est-ce une tendance à encourager ou non? Nous avons vu plus haut que c'est un désastre lorsqu'il y a des parties déroulantes dans une infobox, qu'en est-il de l'emploi de ces boîtes dans les articles? (cf. Transfusion sanguine chez les Témoins de Jéhovah pour une autre version déroulante : à hauteur limitée). Si cela pose d'autres problèmes il serait bien d'en toucher un mot dans les bonnes pratiques et la FAQ. --amicalement, Salix ( converser) 25 mai 2008 à 07:47 (CEST)
- En laissant de côté les problèmes d'accessibilité propre au système de notes (une chose de plus sur la todo de l'atelier ) qui se posent avec ou sans mise en boîte :
- « Notes et références » (ou autres listes longues) mises en boîtes déroulantes avec {{Boîte déroulante début}} : pas de désastre, mais là encore, c'est améliorable, pour la même raison (je vais tester aujourd'hui la modification évoquée ci-dessus qui contourne le problème du lien dérouler/enrouler non explicite dans un lecteur d'écran). Donc, disons: pas de raison suffisante pour une objection côté accessibilité.
- « Notes et références » mises dans une boîte à hauteur limitée, avec ascenseur, comme évoqué sur le Bistro : pas de problème d'accessibilité dans la mesure où la boîte contient des liens. Sans entrer dans les détails, la présence des liens de retour au texte au début de chaque note (↑) garantit qu'on pourra utiliser les ascensseurs au clavier. Si la boîte ne contenait que du texte sans aucun lien, en revanche, elle poserait un problème d'accessibilité au clavier (impossibilité de faire défiler le contenu pour le lire).
- Cela dit, ergonomiquement, ces boîtes à ascenseurs sont loin d'être une réussite, mais c'est une autre question
.
- Quoiqu'il en soit, je viens de virer la boîte des notes et références. Même si c'est accessible, c'est horrible, et nulle part il est indiquer que la longueur des références est un problème. Sinon, avec cinéma, on ne serait pas dans la merde
— Steƒ ( Стеф ) 25 mai 2008 à 09:12 (CEST)
- Cf ma suggestion sur le Bistro: que les contributeurs qui souhaitent avoir ces boîtes utilisent leur monobouc, fait pour ça --Lgd (d) 25 mai 2008 à 09:15 (CEST)
- J'ai remis la boite, Stef, pour que les discussions où je l'avais citée restent compréhensibles. Je l'enlèverai plus tard. Mica (d) 25 mai 2008 à 09:30 (CEST)
- Plutôt que de me reverter, il te suffisait d'indiquer une version de l'article où il y avait la boîte ... Quelqu'un va sûrement le faire à ma place ... — Steƒ ( Стеф ) 25 mai 2008 à 09:34 (CEST)
- Salix l'a fait. Mica (d) 25 mai 2008 à 09:35 (CEST)
- Plutôt que de me reverter, il te suffisait d'indiquer une version de l'article où il y avait la boîte ... Quelqu'un va sûrement le faire à ma place ... — Steƒ ( Стеф ) 25 mai 2008 à 09:34 (CEST)
- Cf ma suggestion sur le Bistro: que les contributeurs qui souhaitent avoir ces boîtes utilisent leur monobouc, fait pour ça
- Quoiqu'il en soit, je viens de virer la boîte des notes et références. Même si c'est accessible, c'est horrible, et nulle part il est indiquer que la longueur des références est un problème. Sinon, avec cinéma, on ne serait pas dans la merde
J'ai créé un gadget selon le code de lgd (d · c · b) : mediawiki:gadget-referencederoulante et mediawiki:gadget-referencederoulante.css. Tout se passe maintenant dans vos préférences, onglet gadgets et section gadgets généraux — Steƒ ( Стеф ) 25 mai 2008 à 11:09 (CEST)
Ces boîtes sont techniquement intéressantes mais inutiles. On limite la taille de 5% du texte, tout le reste reste comme avant, l'accès n'est pas amélioré ni la mise en page. Je ne vois pas l'avantage de ces boîtes déroulantes. Si on compare avec l'écrit, ce qui ferait sens ce serait une frame en bas de fenêtre qui se synchroniserait avec la lecture de l'article en haut de fenêtre - mais c'est probablement impossible avec la grammaire Wiki. MAC (d) 25 mai 2008 à 12:23 (CEST)
Accessibilité clavier, correction des liens « Aller à »
Mediawiki génère en début de chaque page deux liens cachés destinés à faciliter la navigation au clavier (Pour les faire apparaître, désactivez les styles CSS). Ces liens donnent un accès rapide, dans la page, au début du menu de navigation et au formulaire de recherche. Ils sont supposés permettre à des utilisateurs naviguant au clavier d'éviter de très nombreuses tabulations à travers tous les liens du contenu d'un article s'ils veulent utiliser les liens des menus ou la recherche.
Mais... Ces liens souffrent de deux erreurs classiques :
- ils sont masqués dans la feuille de style par défaut à l'aide d'un
display:none, dans l'idée qu'ils servent principalement aux utilisateurs non voyants (lecteur d'écran). Or, ceux-ci n'y pas accès, le display:none masquant définitivement ces liens même au lecteur. - en réalité, les principaux bénéficiaires de ces liens d'accès rapide ne sont pas les utilisateurs de lecteurs d'écran, qui bénéficient de moyens d'accès aux différentes zones de la page, natifs dans leur lecteur et beaucoup plus « puissants ». Le premier public bénéficiaire est celui de tous les utilisateurs voyants naviguant au clavier : handicapés moteurs, absence de dispositif de pointage, etc.
Ces liens ne devraient donc pas être masqués par défaut, de manière être utilisables par tous les publics concernés.
Comme il n'est cependant pas souhaitable (ou souhaité) de modifier le rendu graphique et d'encombrer l'interface avec de nouveaux liens affichés en début de page, on recourt fréquemment à une astuce:
- les liens sont masqués par défaut (mais de manière à être perceptibles dans un lecteur d'écran)
- un javascript appelé au chargement des pages leur permet d'apparaître à la première tabulation, c'est à dire dès que le visiteur tente de naviguer au clavier dans la page.
Pour corriger, il faut:
- l'ajout d'une fonction dans MediaWiki:Common.js, du type :
// skip links
function showSkipLinks() {
var skip_links = document.getElementById('jump-to-nav').getElementsByTagName("A");
for (var i=0; i<skip_links.length; i++) {
skip_links[i].className="hidden";
skip_links[i].onfocus=function() {
this.className="";
}
}
}
addOnloadHook(showSkipLinks);
- l'ajout d'une classe de masquage générique dans MediaWiki:Common.css (qui aura d'autres usages pour l'accessibilité) :
/* liens d'accès directs */
#jump-to-nav {
display: block;
}
.hidden {
position: absolute;
left: 0;
top: -5000px;
width: 1px;
height: 1px;
overflow: hidden;
}
- Des modifications de libellé des messages systèmes concernés (rendre explicites MediaWiki:Jumptonavigation et MediaWiki:Jumptosearch)
Le souci à régler est le message système MediaWiki:Jumpto (texte « Aller à ») dont il faut pouvoir supprimer le rendu (Je dois m'arrêter pour l'instant, mais je vais revoir ça ce soir.)
A part ça, pas d'objections, d'idées, tout ça ? --Lgd (d) 26 mai 2008 à 10:04 (CEST)
- Bon, souci corrigé, le script pour MediaWiki:Common.js et la CSS pour MediaWiki:Common.css sont prêts: Utilisateur:Lgd test/demo.css et Utilisateur:Lgd test/demo.js. Pas de modification des messages systèmes, finalement. --Lgd (d) 29 mai 2008 à 07:09 (CEST)
Balises span
Bonjour peut-on encourager ou non l'utilisation des balises <span></span>? Si oui comment expliquer ça clairement sur Aide:Notes? C'est actuellement uniquement indiqué en pense-bête dans le bas de la page. --amicalement, Salix ( converser) 26 mai 2008 à 11:27 (CEST)
- Ne pas encourager, et même cacher subrepticement sous le tapis...
- Le système des
<ref>pose déjà à lui tout seul un gros problème de navigation au clavier dans IE : si on suit au clavier le lien d'appel de ref, la référence reçoit bien le focus visuel (elle s'affiche en haut de la febnêtre du navigateur). Mais la tabulation suivante ne marche pas: au lieu de donner le focus au premier lien présent dans la référence (la flèche de retour au texte), elle ramène... au début de la page de l'article. C'est lié à un bug connu d'IE, et à la forme des ancres HTML utilisées. C'est corrigeable de manière centralisée, via une amélioration simple de l'extension utilisée pour les notes et références. - Le système des
<span>utilise le même type d'ancres HTML, qui sont tout aussi inutilisables dans IE. Mais là, si ça se multiplie dans les articles, ce n'est pas corrigeable de manière centralisée, contrairement aux refs elles-mêmes. En fait, ce n'est peut-être même pas corrigeable compte-tenu des contraintes de la syntaxe Wiki (à confirmer). - En général, on évite autant que possible de tenir compte d'un bug de navigateur (puisqu'il est supposé devoir être corrigé à terme). Mais quand il s'agit à la fois d'IE et d'un mécanisme aussi important que la navigation au clavier, il faut bien en tenir compte.
- En prime, mais ça c'est hors avis sur l'accessibilité: ces petits jeux de parcours d'ancre en ancre sont ergonomiquement assez médiocre, tout de même... --Lgd test (d) 26 mai 2008 à 11:47 (CEST)
- Merci pour cette explication limpide Lgd. Je vais donc le supprimer de l'Aide notes et avertir le projet Sources! --amicalement, Salix ( converser) 26 mai 2008 à 11:50 (CEST)
- /me va finir par y croire, que c'est limpide Un truc bien pour le projet sources et pour l'accessibilité, c'est
<ref group="Montesquieu ">...</ref>: pertinent pour rassembler les différentes notes se rapportant à un même ouvrage, et génère des liens d'appels de notes plus explicites que les « 1 », « 2 » etc. --Lgd (d) 26 mai 2008 à 12:21 (CEST)
- /me va finir par y croire, que c'est limpide
- Merci pour cette explication limpide Lgd. Je vais donc le supprimer de l'Aide notes et avertir le projet Sources! --amicalement, Salix ( converser) 26 mai 2008 à 11:50 (CEST)
Cette page est très déroutante, à chaque fois je me demande s'il ne faudrait pas la réécrire en intégrant une vraie partie consacrée aux handicaps. Après tout elle est liée dnas la boite à "accessibilité à tous", pourquoi mettre les handicapés à part? C'est encore pire quand on arrive sur Wikipédia:Atelier accessibilité où l'on tombe sur la page de projet alors qu'on est sensé être dans des pages explicatives. Et que dire de Wikipédia:Réservé aux adultes ? qui n'est qu'une suite de discussions... Il s'agit tout de même de recommendations, pas des pages de travail! Qu'en pensez-vous? --amicalement, Salix ( converser) 3 juin 2008 à 14:24 (CEST)
- Ps. pourquoi c'est bizarre et tout rose sur cette page?????
- je plussoie, mais que verrais-tu dans cette partie ? Des recommandations issues de Wikipédia:Atelier accessibilité/Bonnes pratiquesou quelque-chose de plus général peut-être inspiré de Wikipédia:Atelier accessibilité/Qu'est-ce que c'est ? (en beaucoup plus court) ?
- ... Rose... Rose ? Où ça, rose ? --Lgd (d) 4 juin 2008 à 07:37 (CEST)
- Bonjour Ldg. j'ai un fond rose pâle en premier niveau de conversation à partir de là, cela depuis mon dernier post. Pour les niveaux suivants ça redevient jaune. C'est uniquement sur cette page et je ne vois vraiment pas ce qui merdouille dans son code... Pour la page accessibilité je verrais bien une synthèse de tous les cas possibles selon les groupes de lecteurs concernés pour exposer leurs problèmes (matériel: ordinateurs limités, pas de souris, pda et mobiles, impression, paramètres personnels... enfants, déficients (daltonisme, personnes âgées...) handicapes lourds, moteurs ou visuels, lecteurs d'écran...) etc. + une page Aide:Accessibilité pour les lecteurs qui rencontrent des problèmes + Si besoin est, on crée quelques articles d'aide détaillés si ça se complique + on met des rappels ou les bons liens dans les pages d'aides habituelles + on retravaille l'article Accessibilité en le liant aux autres (voir "accessibilité" dans l'outil Recherche) En résumé. Je pense que, si on veut que l'accessibilité soit prise en compte par tous, on doit éviter de tout centraliser sur quelques belles pages que personne ne prendra la peine de lire. A nous de glisser des remarques un peu partout, là où les contributeurs piochent leur infos générales, comme ici. Il faudrait convenir à cet usage d'une typo ou d'un logo discrêt mais bien reconnaissable à placer en tête des remarques concernant l'accessibilité. Cela aiderait àmha à les populariser et à attirer l'attention. Des idées? --amicalement, Salix ( converser) 4 juin 2008 à 11:35 (CEST)
- PS. le pbm de rose se situe sans doute au niveau de « Evaluation accessibilité / solutions » dans cette partie de la page. --amicalement, Salix ( converser) 4 juin 2008 à 11:41 (CEST)
- Voir essai de logo et typo ici: Aide:Insérer_une_image#Illustration_standard. Je demande en même temps au bistro ce qu'ils en pensent : ICI --amicalement, Salix ( converser) 4 juin 2008 à 13:10 (CEST)
- Bonne idée.
- Une 'tite classe CSS pour faire disparaître l'icône du contenu HTML, et la remettre comme il faut en tant qu'image décorative CSS: Encarts accessibilité dans les pages d'aide] (à convertir en modèle le moment venu, avec ajout des styles dans Common.css).
- Sinon, je plussoie chaudement la stratégie du noyautage des pages d'aide --Lgd (d) 4 juin 2008 à 16:37 (CEST)
- Désolée Ldg, mais là je suis larguée... ça sert à quoi ce test? --amicalement, Salix ( converser) 4 juin 2008 à 19:48 (CEST)
- Mille pardons Pour la peine, j'irai faire une purge d'historique, promis : c'est juste pour voir ce que donnerait le modèle final pour ces encarts d'aide, où l'image n'est pas dans le code Wiki, mais juste dans la couche de décoration de la page. Ce que cela change, c'est qu'il n'y a plus ce maudit lien sur l'image, qui pose de gros problèmes d'accessibilité et qui ne sert à rien pour les lecteurs. --Lgd (d) 4 juin 2008 à 19:56 (CEST)
- Merci, mon pauvre cerveau frôlait la surchauffe. J'ai cru un instant qu'il fallait que tous les lecteurs trafiquent leur monobook pour voir l'icône! Du moment que ça ne change rien à l'aspect visuel... moi... --amicalement, Salix ( converser) 4 juin 2008 à 20:04 (CEST)
- PS. Au fait le rose à disparu! C'était quoi? J'espère ne pas avoir fait une boulette --amicalement, Salix ( converser) 4 juin 2008 à 20:07 (CEST)
- Ah, le « truc à modifier dans le monbouc », c'est juste pour pouvoir regarder ce que donne le test : pour l'instant, cela repose sur du code (CSS) qui est uniquement dans mon monobouc personnel. Le «
@import» en question sert à importer ce code dans ton monobouc personnel. Mais au final, si le modèle est adopté et mis en place, ce code sera porté dans le Common.css que tous les utilisateurs reçoivent sans le savoir. - Sinon, pour le rose, tu n'y es absolument pour rien, rassure-toi. Disons que je vais taire l'origine du problème. J'ai déjà assez de mal comme ça avec la source du problème et mes maigres talents diplomatiques Ouàlà ouàlà... --Lgd (d) 4 juin 2008 à 20:22 (CEST)
- Ah, le « truc à modifier dans le monbouc », c'est juste pour pouvoir regarder ce que donne le test : pour l'instant, cela repose sur du code (CSS) qui est uniquement dans mon monobouc personnel. Le «
- Mille pardons Pour la peine, j'irai faire une purge d'historique, promis : c'est juste pour voir ce que donnerait le modèle final pour ces encarts d'aide, où l'image n'est pas dans le code Wiki, mais juste dans la couche de décoration de la page. Ce que cela change, c'est qu'il n'y a plus ce maudit lien sur l'image, qui pose de gros problèmes d'accessibilité et qui ne sert à rien pour les lecteurs. --Lgd (d) 4 juin 2008 à 19:56 (CEST)
- Désolée Ldg, mais là je suis larguée... ça sert à quoi ce test? --amicalement, Salix ( converser) 4 juin 2008 à 19:48 (CEST)
- Voir essai de logo et typo ici: Aide:Insérer_une_image#Illustration_standard. Je demande en même temps au bistro ce qu'ils en pensent : ICI --amicalement, Salix ( converser) 4 juin 2008 à 13:10 (CEST)
Sur l'Aide:Note j'avais ajouté des petites remarques qui gagneraient bien à avoir ce logo aussi. --amicalement, Salix ( converser) 5 juin 2008 à 00:20 (CEST)
- Je pense qu'on peut créer le modèle idoine et généraliser ça. --Lgd (d) 6 juin 2008 à 13:42 (CEST)
- On en a besoin sur Aide:note. Je fais du provisoir comme sur Aide:Insérer_une_image#Illustration_standard ou tu peux créer le modèle? --amicalement, Salix ( converser) 8 juin 2008 à 13:39 (CEST)
- Tout'suite M'dame, on y va M'dame -Lgd (d) 8 juin 2008 à 13:40 (CEST)
- Tout'suite M'dame, on y va M'dame
- On en a besoin sur Aide:note. Je fais du provisoir comme sur Aide:Insérer_une_image#Illustration_standard ou tu peux créer le modèle? --amicalement, Salix ( converser) 8 juin 2008 à 13:39 (CEST)
- Exemple de syntaxe
{{Encart|aide_accessibilite|Dans cet exemple il est souhaitable d'écrire en légende une phrase comme « Ruban de pellicule photographique ». Pensez notamment aux logiciels de synthèse vocale pour mal-voyants et à la consultation sur du matériel n'affichant que le texte.}}- Rendu (actualisez le cache de votre navigateur si l'icône n'apparaît pas
- Mozilla / Konqueror / Firefox / Opera : Shift-Ctrl-R, Internet Explorer : Ctrl-F5, Safari : Cmd-R.) :
- J'ai enlevé l'italique, qui ne semblait pas faire l'unanimité. L'icône est un peu réduite en taille pour ne pas perturber l'interligne. Tu me dis si tu vois des améliorations... -Lgd (d) 8 juin 2008 à 13:54 (CEST)
- C'est où? c'est où ?
Malgré 3 bonnes cuillérées de purge je ne vois pas où s'applique le modèle... --amicalement, Salix ( converser) 8 juin 2008 à 14:10 (CEST)
- Je viens de mettre à jour Aide:Insérer_une_image#Illustration_standard pour l'y ajouter. -Lgd (d) 8 juin 2008 à 14:13 (CEST)
- ça y est, ça marche, je le vois 5/5 ci-dessus! Bravo! Quelle est le nom exact de la page du modèle pour que je le mette en pense-bête sur ma page perso? --amicalement, Salix ( converser) 8 juin 2008 à 14:18 (CEST)
- Modèle:Encart -Lgd (d)
- Arf, C'était quand même bien en italique... /me se tâte pour la rétablir... -Lgd (d) 8 juin 2008 à 14:31 (CEST)
- Suggestions d'amélioration : Est-il possible de retirer la puce avec « aide_accessibilite » dans la partie " Rendu dans les articles" ? car cela prête à confusion tant qu'il n'y a pas d'autre paramètre possible... et peut-être mettre Aide:Insérer_une_image#Illustration_standard comme bon exemple d'utilisation dans les pages. C'est vrai que c'était mieux en italiques... Il n'y a eu qu'une seule remarque contre ça après tout --amicalement, Salix ( converser) 8 juin 2008 à 14:35 (CEST)
- Je l'ai appliqué sur Aide:Note, rumf, pas très visible sans italiques... --amicalement, Salix ( converser) 8 juin 2008 à 14:40 (CEST)
- Italique remis en place (actualiser le cache etc.) -Lgd (d) 8 juin 2008 à 14:47 (CEST)
- Bravo Ldg, c'est parfait! Nous verrons bien s'il y a des schtroumpfs grognons qui n'aiment pas les italiques, mais àmha c'est plus repèrable comme ça. --amicalement, Salix ( converser) 8 juin 2008 à 21:01 (CEST)
- Sinon, pourra toujours leur proposer de mettre des petits drapeaux autour, à la place de l'italique.
Ne me cherchez pas, je suis déjà sorti depuis longtemps, là --Lgd (d) 8 juin 2008 à 21:09 (CEST)
- Sinon, pourra toujours leur proposer de mettre des petits drapeaux autour, à la place de l'italique.
- Bravo Ldg, c'est parfait! Nous verrons bien s'il y a des schtroumpfs grognons qui n'aiment pas les italiques, mais àmha c'est plus repèrable comme ça. --amicalement, Salix ( converser) 8 juin 2008 à 21:01 (CEST)
- Italique remis en place (actualiser le cache etc.) -Lgd (d) 8 juin 2008 à 14:47 (CEST)
- Suggestions d'amélioration : Est-il possible de retirer la puce avec « aide_accessibilite » dans la partie " Rendu dans les articles" ? car cela prête à confusion tant qu'il n'y a pas d'autre paramètre possible... et peut-être mettre Aide:Insérer_une_image#Illustration_standard comme bon exemple d'utilisation dans les pages. C'est vrai que c'était mieux en italiques... Il n'y a eu qu'une seule remarque contre ça après tout
- ça y est, ça marche, je le vois 5/5 ci-dessus! Bravo! Quelle est le nom exact de la page du modèle pour que je le mette en pense-bête sur ma page perso? --amicalement, Salix ( converser) 8 juin 2008 à 14:18 (CEST)
- Je viens de mettre à jour Aide:Insérer_une_image#Illustration_standard pour l'y ajouter. -Lgd (d) 8 juin 2008 à 14:13 (CEST)
- C'est où? c'est où ?
- J'ai enlevé l'italique, qui ne semblait pas faire l'unanimité. L'icône est un peu réduite en taille pour ne pas perturber l'interligne. Tu me dis si tu vois des améliorations... -Lgd (d) 8 juin 2008 à 13:54 (CEST)
Soit dit en passant, j'ai corrigé le Mediawiki.js, tu devrais jeter un oeil à ma modif au cas où ... J'ai supprimé un .png et ajouté des " " pour l'url, sinon, ça ne passait pas, je crois. Par contre, je ne crois pas qu'un modèle encart soit à soliciter ... Si chacun en va de sa sauce, chacun mettra sa petite image, et on aura un encart sur chaque page ... Non, je crois qu'il faudrait se maintenir à un modèle simple destiné à l'accessibilité, comme celui-ci ... Car il n'est pas indiqué, ou j'ai mal lu, qu'il faut l'aide d'un admin et d'une classe spéciale pour le modèle ... Cordialement — Steƒ ( Стеф ) 8 juin 2008 à 21:49 (CEST)
- Ah, justement, pour le PNG/SVG, on en discutait, et il semble préférable de garder plutôt l'extension complète (foo.svg.png).
- Les guillemets autour de l'URL ne sont pas nécessaires. Leur absence est en fait un filtre pour d'anciennes versions de navigateurs.
- Pour ce qui est du modèle {{encart}} et de ses futurs développements, deux choses:
- pour créer un nouveau type d'encart, avec une nouvelle icône, il faut en effet passer par un ajout dans common.css et donc par un admin, ce qui est tout de même un filet de sécurité. Cela dit, j'ai improvisé la page de documentation un peu vite, et c'est sans doute à y préciser.
- certains modèles existants peuvent déjà tirer profit de {{Encart}}, Voir ces exemples (mais il faut ajouter des bouts de mes monobook pour les visualiser). Disons que c'est une façon de préparer l'avenir et le passage en background CSS de certaines icônes actuelles --Lgd (d) 8 juin 2008 à 21:57 (CEST)
Modèle Titre incorrect
Bonjour tout le monde,
Je remarque que le modèle {{Titre incorrect}} est de plus en plus utilisé. On voit même certain cas vraiment exotique comme Qâbûs (Ziyarides) (masqué par Chams al-Ma`âlî Qâbûs), Kay Ka'us (Ziyarides) (par Kay Kâ'ûs), ou F dièse a dièse infini (par f♯a♯∞). Dans le cadre de la discussion de la PdD sur les apostrophes (ici), il est aussi envisagé de l’utiliser pour tous les titres contenant une apostrophe. Je crois qu’un simple renommage pourrait suffire (contraire au cas de {{minuscule}}) mais je ne suis pas expert. Que pensez-vous de ces utilisation ? VIGNERON * discut. 4 juin 2008 à 20:17 (CEST)
- Je regarde ça dès que possible. A priori, il faut voir:
- si et comment un lecteur d'écran gère la modification de la page via javascript après le chargement. Si je me souviens bien, le nouveau titre est lu et l'ancien évacué.
- Surtout, sur le fond, il y a un problème d'accessibilité lourd quand le modèle est utilisé comme dans Qâbûs (Ziyarides) : on ne peut pas vraiment parler de perte d'information pour les utilisateurs sans javascript, mais l'information est tout de même très différente. A voir au cas par cas...
- En revanche, en cas d'utilisation pour l'astropophe, cela ne devrait pas avoir d'impact sur l'accessibilité. --Lgd (d) 6 juin 2008 à 13:41 (CEST)
- Sur un plan plus large, le modèle titre incorrect devrait etre utilisé si, et seulement si, mediawiki ne peut pas rendre le nom du titre (la plupart du temps, c'est pour des questions de typographie, genre François 1er. Il y a des cas ou ce sont des caractères interdits, {, [ et # si je me souviens bien. Dans tous les autres cas, il faut faire un renommage sans se poser de question. Sinon, pour l'accessibilité, je n'ai pas trop d'avis. J'avais vu que le modèle était bien foutu pour le cas ou javascript n'est pas activé, mais je n'ai pas d'idée de ce que ça peut rendre sur les lecteurs d'écrans. Maloq causer 11 juin 2008 à 21:45 (CEST)
Aller à : Navigation, Rechercher
Bonjour,
Depuis une bidouille récente dont je n’ai pas compris tout les tenants et aboutissants (mais ce n'est pas le sujet), le sous-titre « Aller à : Navigation, Rechercher » apparaît furtivement tout le temps sur toutes les pages. Apparemment, il y aune bonne raison pour cela, je ne demande donc pas le retrait de ce bout de texte. Par contre, serait-il possible de le mettre sur la droite ? et pas à gauche, juste sous le titre (où il accroche fortement le regard et est visible comme le nez au milieu de la figure). VIGNERON * discut. 11 juin 2008 à 21:38 (CEST)
Est-ce vraiment vital ? Je n'ai pas de souci philosophique ou technique à le faire, mais disons que bof, cela va nécessiter plusieurs lignes de CSS pour vraiment peu de choses. Si on réduisait la taille de caractères de cette mention, ce serait un bon compromis ? Cordialement, --Lgd (d) 11 juin 2008 à 21:45 (CEST)- Humpf, ne pas parler au pif un soir de fin de formation particulièrement chargée. Pas de souci, on arrange ça. -Lgd (d) 11 juin 2008 à 21:47 (CEST)
- Ok, merci. En petit cela aurait bien, mais le problème est surtout le positionnement juste sous le titre (là où les yeux vont direct). VIGNERON * discut. 11 juin 2008 à 21:53 (CEST)
Listes sur 2 colonnes : quelle est le bon code?
Bonsoir, ça se passe ICI. Lequel choisir du point de vue d'un accessibilitologue? --amicalement, Salix ( converser) 11 juin 2008 à 22:11 (CEST)
- Accessibilitologue ? On ne me l'avait jamais fait. J'adopte --Lgd (d) 11 juin 2008 à 22:18 (CEST)
Burnout accessibilité
Bon chouette nous nous sommes croisé par hasard mais je tape à la bonne porte ! Je suis entrain de refondre l'article Burnout (médecine) et ne sachant que trop ce que sont les problème d'accessibilité je tente de rendre son vaste contenu le plus accessible possible, ayant entamé une bonne moitié du contenu, plutôt que de tout refaire, je privilégie de le rendre accessible au fur et à mesure de ma rédaction, aussi si vous pourriez vérifier les éventuelles lacunes afin que je corrige, -- Cordialement. Micthev (parler) 21 juin 2008 à 12:05 (CEST)
- Bonjour, je ne suis pas une spécialiste mais tu peux en attendant je pense trouver des réponses sur cette page: Wikipédia:Atelier accessibilité/Bonnes pratiques. Bonne rédaction!--amicalement, Salix ( converser) 21 juin 2008 à 13:25 (CEST)
- Bonjour, merci beaucoup, j'ai lu avec attention les recommandations et effectué les changements nécessaires, cela étant si quelqu'un pouvait venir jeter un œil au cas où j'aurais omis quelque chose ce serais sympa -- Cordialement. Micthev (parler) 22 juin 2008 à 10:32 (CEST)
Mise à jour de la recommandation sur l'usage de la couleur
hello,
Devant la multiplication des infobox, palettes ou parfois simples tableaux bariolés de couleurs et posant des problèmes d'accessibilité (contraste, utilisation de la couleur comme seul véhicule de l'information), je pense qu'une mise à jour de la recommandation Wikipédia:Limitez l'usage de la couleur dans les articles est nécessaire. J'ai donc commis un premier jet consultable dans l'historique (je n'ai pas voulu la laisser comme version en cours, histoire de ne pas avoir l'air de passer en force). Vos avis et votre participation seront les bienvenus --Lgd (d) 3 juillet 2008 à 11:19 (CEST)
Pour cela me parrait raisonnable. Il faudrait peut-être aussi évoquer les symbolisme des couleurs perçu parfois différemment selon les cultures. --amicalement, Salix ( converser) 3 juillet 2008 à 12:31 (CEST)
- Oui, certainement, mais la page ne me parait pas adapté à cet aspect, c'est mon avis après — Steƒ ( ???? ) 3 juillet 2008 à 13:20 (CEST)
- Il s'agirait juste d'informer le contributeur que ça peut poser un problème sur certaines pages, pas de se lancer dans une étude de la symbolique colorée à travers les âges et les continents qui aurait sans doute pour résultat de n'utiliser que... le transparent! Mais c'est simplement une suggestion car on m'a rapporté des anecdotes cocasses à ce sujet dont j'ai malheureusement oublié les tenants et aboutissants. --amicalement, Salix ( converser) 3 juillet 2008 à 13:50 (CEST)
- Ok, beh pourquoi pas, en intro ? — Steƒ ( ???? ) 3 juillet 2008 à 17:02 (CEST)
- Où vous voulez En tous cas le texte de Ldg me convient, ce qui était la question de départ. Désolée pour la digression. --amicalement, Salix ( converser) 3 juillet 2008 à 17:49 (CEST)
- Où vous voulez
- Ok, beh pourquoi pas, en intro ? — Steƒ ( ???? ) 3 juillet 2008 à 17:02 (CEST)
- Il s'agirait juste d'informer le contributeur que ça peut poser un problème sur certaines pages, pas de se lancer dans une étude de la symbolique colorée à travers les âges et les continents qui aurait sans doute pour résultat de n'utiliser que... le transparent!
- Oui, certainement, mais la page ne me parait pas adapté à cet aspect, c'est mon avis après — Steƒ ( ???? ) 3 juillet 2008 à 13:20 (CEST)
Publicité
Bonsoir, je vous signale que j'ai rajouté l'atelier sur l'annuaire des discussions, rubrique ateliers. c'est ICI. Merci d'en vérifier le résumé. --amicalement, Salix ( converser) 6 juillet 2008 à 00:57 (CEST)
M
Bonjour. Comme ça en passant, je me demandais s'il ne serait pas, assez simple, et plus correcte de placer un petit code autour du modèle {{m}} ? Ca peut même aider à comprendre. Oui, quand je m'éloigne un peu de Wikipédia je peux me permettre d'adopter des atitudes suicidaires :) bayo 8 juillet 2008 à 10:34 (CEST)
- Pertinent, oui. Prévois du temps pour expliquer pourquoi
{{m}}change de rendu et pourquoi c'est normal, et pourquoi etc. --Lgd (d) 8 juillet 2008 à 12:17 (CEST)
Rose des vents...
Bonjour !
Incidemment, je suis tombé sur l'article Rochefort (Charente-Maritime). On trouve dans la partie Géographie une superbe rose des vents, avec des liens vers les communes avoisinantes. Le tout est bien évidemment mis en page dans un tableau, et donc dans un lecteur d'écran, on perd l'information sur la direction (sans parler de la légende sur la rose des vents). En creusant un peu, je me suis rendu compte que cette pratique semble répandue. Il faudrait corriger cela (je pense à une image map...), et pour inciter les contributeurs qui semblent accros à cette représentation, essayer de faire du lobbying auprès d'eux pour ne pas avoir à repasser sans cesse derrière... Je me serais bien lancé dans l'affaire, avec création d'un modèle kivabien pour que l'utilisation en soit la plus souple possible (et que les susdits contributeurs y voient un intérêt personnel de simplification), mais chacun sa spécialité, et j'avoue avoir du mal encore avec la syntaxe des fonctions parseur... GillesC ?m'écrire 8 juillet 2008 à 12:18 (CEST)
- Hello, un autre format est utilisé sur l'article Neuchâtel. Personnellement, je trouve cette représentation laide et cette rose des vents inutile. Il y a des dizaines de sites qui proposent des cartes interactives pour ceux qui veulent voir quel village est voisin de quel autre, et une brève géographie se retrouve déjà dans la fiche de la localité. MAC (d) 8 juillet 2008 à 18:35 (CEST)
- +1 Je ne suis pas fan non plus. Une carte avec image map serait plus parlante et plus accessible. Et pourtant, Rochefort, je connais bien! --amicalement, Salix ( converser) 8 juillet 2008 à 20:20 (CEST)
- Bof. L'image MAP devrait être générée individuellement pour chaque Commune, ce qui est actuellement peu envisageable. Sans compter que ça va faire hurler dans les chaumières.
- Il serait préférable de faire évoluer le modèle {{Localisation ville}} de manière transparente pour les contributeurs :
- déplacer les images décoratives en arrière-plan CSS pour supprimer les alternatives vides d'images liens
- remplacer éventuellement le tableau par un positionnement CSS (mais ce n'est pas indispensable)
- générer automatiquement via le modèle les informations qui manquent, en classe
.hidden: « ...est situé au nord-ouest de... », etc.
- Le résultat sera accessible dans le contexte « tableaux linéarisés et pas de support de CSS screen », ce qui limite au mieux les dégâts (le résultat reste non accessible sous un mobile qui linéarise les tableaux mais exploite les styles screen). Cordialement, --Lgd (d) 9 juillet 2008 à 12:16 (CEST)
- Je ne pensais pas à une image map montrant effectivement la zone autour de chaque commune, mais quelque chose de plus général. Si les contributeurs veulent une rose de vents, on peut la laisser, mais générer le code html avec un modèle du genre {{Rose des vents|nord=|nord-est=|est=(...)|nord-ouest=}}, où chacun des paramètres est optionnel, pour produire comme code :
- <img src="rosedevents" alt="Environs de la commune de ..." usemap="#rose" /><map id="rose"><area shape="poly" coords="ce qu'il faut pour tracer une part de camembert" alt="Nom de la commune (localisation)" href="commune"/>(...)</map>, avec localisation=nord, sud-est ou autres... Ce serait peut-être une piste pour {{localisation ville}}. GillesC ?m'écrire 9 juillet 2008 à 12:53 (CEST)
- Ah non, zut, ça ne marcherait pas. Parfois, il y a plusieurs villes dans une direction donnée
... GillesC ?m'écrire 9 juillet 2008 à 13:00 (CEST) - Par ailleurs, l'information (Le libellé des noms des lieux concernés) ne serait donc pas immédiatement visible dans la page, contrairement au modèle actuel ? --Lgd (d) 9 juillet 2008 à 13:02 (CEST)
Oups. Figure-toi que je n'avais même pas pensé à ça... Pfff... Vivement les vacances... Bon, finalement, retour au bon vieux tableau, même si sémantiquement je préfèrerais une liste, voire même une liste de définition...GillesC ?m'écrire 9 juillet 2008 à 13:33 (CEST)
- A priori, ca vient tout du même contributeur [6], il n'est peut-être pas au courant qu'un modèle existe. Ca serait bien de le prévenir et de tout remplacer par le modèle, question de cohérence. bayo 9 juillet 2008 à 14:01 (CEST)
- En passant : Le rendu de cette rose des vents est désastreux dans un cas comme Marquefave. La commune de Carbonne est clairement au sud ouest et pourtant, à voir la rose, on dirait qu'elle cerne totalement Marquefave de l'ouest au sud, ce qui ne correspond pas du tout à la réalité sur cartes! --amicalement, Salix ( converser) 9 juillet 2008 à 14:27 (CEST)
- Je serais plutôt pour une recommandation de suppression pure et simple de cette représentation qui me semble encore une fois inutile. MAC (d) 9 juillet 2008 à 18:27 (CEST)
- Son utilité est un autre problème, qui n'est pas du ressort de cet atelier . Cela dit, en attendant une suppression éventuelle, je vais voir ce que je peux faire pour « sémantiser » et rendre plus accessible {{Localisation ville}} (et tant qu'à faire, remplacer les cas comme Rochefort (Charente-Maritime) par ce modèle). --Lgd (d) 9 juillet 2008 à 18:34 (CEST)
- Son utilité est un autre problème, qui n'est pas du ressort de cet atelier
- Je serais plutôt pour une recommandation de suppression pure et simple de cette représentation qui me semble encore une fois inutile. MAC (d) 9 juillet 2008 à 18:27 (CEST)
- En passant : Le rendu de cette rose des vents est désastreux dans un cas comme Marquefave. La commune de Carbonne est clairement au sud ouest et pourtant, à voir la rose, on dirait qu'elle cerne totalement Marquefave de l'ouest au sud, ce qui ne correspond pas du tout à la réalité sur cartes! --amicalement, Salix ( converser) 9 juillet 2008 à 14:27 (CEST)
- A priori, ca vient tout du même contributeur [6], il n'est peut-être pas au courant qu'un modèle existe. Ca serait bien de le prévenir et de tout remplacer par le modèle, question de cohérence. bayo 9 juillet 2008 à 14:01 (CEST)
- Ah non, zut, ça ne marcherait pas. Parfois, il y a plusieurs villes dans une direction donnée
Projet infobox commune
Bonjour, pourrais tu jeter un oeuil la dessus [7], ainsi que sa page principale pour avis éclairé. Certains point relévent de problèmes d'accessibilité, d'autres non ...? --H du Viala (d) 12 juillet 2008 à 11:45 (CEST)
- Vu, on va y jeter un zoeil. Merci, --Lgd (d) 13 juillet 2008 à 10:39 (CEST)
Logo de biohomonymie
Bonjour, il faudrait jetter un coup d'oeil à ça: Discussion_Projet:Biologie/Le_café_des_biologistes#Biohomonymies_et_interwikis avant que nous prenions une décision. Un avis accessible? --amicalement, Salix ( converser) 15 juillet 2008 à 21:55 (CEST)
- Ça peut être fait de manière accessible à l'aide du modèle {{Encart}} et d'une classe appropriée dans Common.css, mettant l'icône à sa place, c'est à dire en image d'arrière-plan. --Lgd (d) 16 juillet 2008 à 07:56 (CEST)
- Ok, merci de ta réponse; Je transmets au café des bios. --amicalement, Salix ( converser) 16 juillet 2008 à 10:15 (CEST)
Bonjour.
Bon, je vais sans doute poser une question bête, préparez-vous.
Avec le méta-modèle {{CIO-d}}, les modèles du type {{ITA-d}} donnent 
, avec un lien vers la page de licence du drapeau. Pourquoi est-ce qu'on n'utiliserait pas le même système que pour {{Encart}}, pour tous ces modèles ? Ce serait mieux que d'avoir un lien (inutile et non explicite) vers la licence de l'image (« Image:Flag of Italy.svg »), du moins c'est ce que j'en retire en lisant les bonnes pratiques pour les images.
Ça ne pose pas non plus de problème de masquer le lien vers la page de licence, dans la mesure où les drapeaux sont du domaine public. Qu'en pensez-vous ? Je suis à côté de la plaque ? Une IP, le 16 juillet 2008 à 21:47 (CEST).
- Non, vous avez plutôt raison, mais cela dépasse de très loin la capacité de compréhension du wikipédien moyen, et donc ce que wikipédia peut tolérer. --Lgd (d) 16 juillet 2008 à 21:52 (CEST)
- Mais on ne peut pas le mettre en place ? Je veux dire, il n'est pas nécessaire d'avoir l'assentiment du Wikipédien moyen, ça ne changera pas sa façon de procéder pour insérer un tel drapeau (même si dans l'absolu il faudrait se limiter sur ça, même en rendant le truc accessible). Une IP, le 16 juillet 2008 à 22:22 (CEST).
- C'est marrant, après deux jours au vert, j'avais la même idée à te proposer pour les blasons et autres logos ......Mais pourrais tu expliciter tes réticences, je ne suis pas ton raisonnement. --H du Viala (d) 16 juillet 2008 à 23:14 (CEST)
- Je ne suis pas certain que faire exploser les pages de style avec des centaines (des milliers) d'images (et autant de classes CSS) soit une bonne idée. Comme il n'est pas possible de mettre du style dans le HTML directement, il me semble préférable de rester raisonnable. bayo 17 juillet 2008 à 09:46 (CEST)
- Je suis juste soutier de base
et ne connais pas les rouages profond de WP, et de plus, pas franchement partisan des drapeau, blasons et autres logos qui se baladent partout. Par contre, il me parait que la lutte contre l'inflation de ces vignettes est une cause perdue d'avance tant elles sont actuellement à la mode. Pour moi la solution de la sagesse consiste à tenter de limiter la "casse", d'ou la proposition. Effectivement, si le "remède" est pire que le mal ....
Une idée peut être stupide : créer un "meta-modéle" ramenant à la création d'une seule (ou d'un nombre faible de) classe CSS ne pourrait t'il s'envisager ? (dans le genre des "briques" pour infobox de Lgd) --H du Viala (d) 17 juillet 2008 à 10:03 (CEST)
- Je suis juste soutier de base
- Je ne suis pas certain que faire exploser les pages de style avec des centaines (des milliers) d'images (et autant de classes CSS) soit une bonne idée. Comme il n'est pas possible de mettre du style dans le HTML directement, il me semble préférable de rester raisonnable. bayo 17 juillet 2008 à 09:46 (CEST)
- C'est vrai que d'un certain côté, rendre le truc « respectable », c'est inciter les Wikipédiens à en insérer encore plus, alors que ça devrait être la tendance inverse (c'est quand même dommage que les gens ne sachent pas se limiter d'eux-même aux endroits, relativement rares, où ça peut avoir une certaine utilité). D'autre part si j'ai bien compris, ce système est un pis-aller à la façon dont MediaWiki insère les images, donc le mettre en place de manière généralisée, c'est aussi inciter les développeurs à ne pas se bouger pour corriger le problème (enfin si j'ai tout bien compris).
- Et si en plus côté technique ça alourdit, comme le fait remarquer Bayo, c'est pas la peine ! Merci de vos réponses. Une IP, le 17 juillet 2008 à 10:54 (CEST).
Browsershot
Hello. Je ne sais pas si vous connaissez, mais ça peut éventuellement être utile : http://browsershots.org (exemple pour la page d'accueil de Wikipedia en largeur 800). guillom 26 juillet 2008 à 11:35 (CEST)
Bonjour.
Je ne sais pas si vous êtes au courant, mais il y a actuellement une discussion sur l'intérêt des blasons et des drapeaux dans les modèles du type {{France}} (.svg){kind=small}
France). La proposition actuelle me semble aller à l'encontre des recommandations en matière d'accessibilité : en effet il est question de transmettre des informations uniquement par le biais d'une image, ce qui donnerait « 
» sans jamais mettre le texte « France » (« il est interdit d'associer un drapeau/blason au nom du territoire qu'il représente (principe de non-répétition, c'est l'un ou l'autre) »).
Vu que c'est une prise de décision, ça aura force de loi, donc il me semble important de prendre position vis à vis de ça. 83.196.51.60 (d) 2 août 2008 à 14:27 (CEST)
Questions diverses
Bonjour, j'aurais quelques petites questions sur l'accessibilité (j'espère que je me suis pas trompé d'endroit 
).
- Les Bonnes pratiques recommandent l'utilisation de {{lang|en|toto}}, or j'ai pu lire que les modèles ne passent pas sur la version Mobile. Qui a la priorité ? Ya le même problème avec {{Date}}, à l'heure où un bot le remplace partout.
- Les Bonnes pratiques recommandant
<ol start="1998"> <li>item <li>item <li>item </ol>
Est-ce à dire que
*[[1998]] *[[1999]]
ne doit pas être utilisé ? Pour par exemple les filmographies/ludographies où toutes les années ne sont pas présentes, peut-on utiliser la première syntaxe ? Peut-on y mettre un lien ?
- La FAQ explique : « Un lien vers une source qui n'est pas en françois doit simplement, pour être accessible, permettre à l'utilisateur d'anticiper le résultat de son action avant qu'il ne décide de le visiter. Pour cela, il suffit que le libellé du lien soit lui-même dans la langue en question, ou que celle-ci soit mentionnée s'il est en français. » Comment fait-on au final ? Par exemple, j'ai pour (mauvaise ?) habitude d'utiliser
<ref name="GameSpot Versions">
{{en}} {{Lien web
|url = http://www.gamespot.com/XXX/similar.html?mode=versions
|titre = Synthèse des versions de ''XXX''
|site = [[GameSpot]]
}}</ref>
en pensant que c'était une bonne idée que d'indiquer ce qu'est cette source pour un non english speaker. Est-ce mal ? Vaut-il mieux mettre
<ref name="GameSpot Versions">
{{en}} {{Lien web
|url = http://www.gamespot.com/XXX/similar.html?mode=versions
|titre = ''XXX'' {{lang|en|Release summary}}
|site = [[GameSpot]]
}}</ref>
- Dans les palette de navigation, l'utilisation de
{{nobr|''[[XXX]]'' {{·}}}} {{nobr|''[[XXX]]''}}est-elle correcte ?
Je pense que c'est tout... C'étaient mes petites interrogations, merci pour vos réponses . Jean-Frédéric (d) 20 août 2008 à 20:35 (CEST)
- Pour essayer de répondre rapidement :
- « les modèles ne passent pas sur la version Mobile » : Un bug dans une version triturée des articles de Wikipédia ne devrait pas influencer notre manière de mettre en forme le contenu. Sinon on s'en sort pas. Comme indiqué dans la discussion pointée, les modèles du genre {{er}} ou {{e}} on le même problème, et se serait régresser que de remplacer tout ça par du HTML.
- « <ol start="1998"> » je n'ai pas trop d'avis sur l'accessibilité, par contre, on évite clairement le HTML dans les articles. Aussi l'exemple indiqué, par rapport a son utilisation pratique est assez délicate. Classiquement, dans une liste de films, comme indiqué, il peut y avoir plusieurs fois la même date, ou des années manquantes et donc son application dans les articles serait assez casse gueule. Il ne pourrait en effet pas y avoir de liens.
{{lang|en|non english speaker}}décrit, plutôt pour automatisation, que la langue du texte dans le modèle est l'anglais. Cela n'indique généralement rien visuellement, il me semble important de rajouter ce petit{{en}}, d'autant plus qu'un titre en anglais peut cacher un article en français :)- En soit
{{nobr}}n'est pas problématique. Il indique par du style que le contenu doit être affiché d'un tenant sur une seule ligne. Comme ce n'est que de la mise en forme, il n'y a, me semble-il aucun problème. Il me semble (je suis pas spécialiste de l'accessibilité du tout) que{{·}}l'est un peu plus, car il sert de séparateur, ou le français utiliserait une virgule ou un point-virgule (que normalement MediaWiki force automatiquement a ne pas être en début de ligne). L'idéal serait enfin d'avoir des listes HTML (ul,li), avec mise en forme en ligne, ou le séparateur serait du style. Autant dire que ce n'est pas près d'être utilisé.
- J'espère avoir répondu pas trop mal :) bayo 8 septembre 2008 à 14:49 (CEST)
Modèle:Date
Bonjour les ti-cocos! Juste mentionner que {{Date}}, comme tous les modèles, ne sont pas décelés lorsque l'on consulte Wikipédia sur des PDA ou téléphones mobiles. À première vue, il est normal de ne pas voir les modèles sur un très petit écran (comme les infoboxes), mais pour ce qui est des dates, il me semble très problématique que les dates n'apparaissent pas!
Exemple : Jean Charest (né le sous le nom de John James Charest) ... voir le résultat sur un PDA
Au plaisir. — Antaya @ 21 août 2008 à 09:56 (HAE)
- Voir cette requête pour les bots datant d'août 2008. 83.194.220.158 (d) 7 septembre 2008 à 21:35 (CEST)
- Très très très curieux se service wap buggé :/ /me se demande pourquoi ça tourne sur wikipedia.org... bayo 8 septembre 2008 à 14:01 (CEST)
- Si, comme le dit Antaya, ce non-affichage des modèles est effectivement volontaire, et que le but est d'éviter les infobox (trop grosses pour les petits écrans), il faudrait qu'ils limitent les modèles qui ne sont pas affichés aux infobox, et continuent d'afficher les autres.
- Il serait peut-être pas mal de créer un tag à placer dans les modèles pour dire à la version wap si elle doit ou non le prendre en compte. Un truc du style
__NOWAP__qu'on mettrait dans toutes les infobox (et peut-être aussi les modèles de géolocalisation qui sont très probablement rendus n'importe comment sur les mobiles, les modèles de maintenance également envahissants, etc.) mais évidemment pas dans les modèles de date, de siècles, de formatage, etc. 83.194.220.158 (d) 8 septembre 2008 à 15:51 (CEST)- Encore faurait-il que cela soit pris en compte dans le contenu délivré par le serveur, ce qui à mon avis requiert l'action des développeurs... GillesC ?m'écrire 8 septembre 2008 à 16:34 (CEST)
- Oui c'est clair, il y a de très fortes chances que ça ne puisse pas se faire à notre niveau ; c'était juste une remarque comme ça, une idée en l'air, en sachant que ça ne sera probablement jamais suivi d'effet (qui s'occupe de cette version mobile ?). 83.194.220.158 (d) 8 septembre 2008 à 16:59 (CEST)
- Toutes les infoboxs, et boites de navigation ont des classes HTML explisites. Il est par exemple assez facile, je pense de « nettoyger » les pages de Wikipédia en retouchant sa feuille de style. Mais la logique de filtrer a priori les modèles m'échappe complètement. Depuis des lustres on utilise, toutes langues confondus les modèles pour la mise en forme du texte. bayo 10 septembre 2008 à 11:48 (CEST)
- Oui c'est clair, il y a de très fortes chances que ça ne puisse pas se faire à notre niveau ; c'était juste une remarque comme ça, une idée en l'air, en sachant que ça ne sera probablement jamais suivi d'effet (qui s'occupe de cette version mobile ?). 83.194.220.158 (d) 8 septembre 2008 à 16:59 (CEST)
- Encore faurait-il que cela soit pris en compte dans le contenu délivré par le serveur, ce qui à mon avis requiert l'action des développeurs... GillesC ?m'écrire 8 septembre 2008 à 16:34 (CEST)
- Très très très curieux se service wap buggé :/ /me se demande pourquoi ça tourne sur wikipedia.org... bayo 8 septembre 2008 à 14:01 (CEST)
showSkipLinks - jump-to-nav
Bonjour, Comme précisé plus haut, ce lien sert à l'accessibilité, mais chez moi -firefox-, il s'affiche une ou deux secondes au chargement de chaque page, puis s'efface. Je me demandais s'il n'existait pas une possibilité de mieux le cacher, c'est perturbant ces deux liens qui disparaissent. Vu la complexité derrière, je préfère vous poser la question avant de corriger tout seul :)
Bien cordialement, Plyd /!\ 25 septembre 2008 à 10:36 (CEST)
- en plus pour les gens qui n'ont pas le javascript activé, ça s'affiche systématiquement. Je supprime ? Plyd /!\ 2 octobre 2008 à 09:53 (CEST)
- Bonjour. Je n'ai pas trop suivi ce point, mais j'imagine que tu peux directement ajouter un
#jump-to-nav {display: none;}- Dans ton monobook perso. bayo 2 octobre 2008 à 10:50 (CEST)
besoin de votre avis sur les onglets dans les taxobox !
Tcho
est ce que vous pouvez nous dire sur cette page ce que vous pensez de l'utilisation des onglets dans cet exemple... merci ! Poleta33 (d) 30 octobre 2008 à 13:57 (CET)
Paramètre de couleur, contraste du texte et sapins de Noël
Bonjour,
Suite à cette question à propos d'un modèle d'infobox, un rapide sondage me ramène des choses comme EADS, Bic, Brasseries Kronenbourg, Renault (Groupe), Opel, France Télécom, Apple, Inc.... Des avis, des propositions, des bonnes volontés ? Un kärcher ? Y a-t-il un docteur dans la salle ? ;-) --Lgd (d) 3 novembre 2008 à 07:55 (CET)
, le modèle ne modifie plus la couleur du texte. --Lgd (d) 4 novembre 2008 à 07:16 (CET)
Alternatives textuelles des images, une amélioration majeure
Bonjour,
Une modification récente de mediawiki va permettre d'améliorer considérablement le très douloureux problème des alternatives textuelles d'images : il est désormais possible de spécifier un paramètre alt qui sera transcrit comme tel par mediawiki. Voir Bugzilla 368 Image syntax shouldn't use caption as alt= text et les releases notes. Il va falloir regarder ça de près, mettre à jour les bonnes pratiques, l'aide, différents modèles, et intervenir par exemple auprès d'initiatives telles que Wikipédia:WikiProject Check Wikipedia? qui pourraient en profiter pour traiter ce paramètre.
Pour résumer rapidement:
[[Image:Exemple.jpg|thumb|alt=alternative textuelle spécifique|légende de l'image]] permet à présent d'indiquer d'une part une alternative textuelle, et d'autre part une légende distincte.
Le point noir (il y en a forcément un) est que ces %$Sgn!§ ont évidemment choisit l'alternative nulle en dernier ressort, si le paramètre alt n'est pas renseigné, ce qui est catastrophique puisque chaque image est une image-lien. Mais bon, un pas après l'autre . Cordialement, --Lgd (d) 4 novembre 2008 à 07:04 (CET)
- Comment expliquerais-tu ça pour cette page? : Aide:Insérer une image --amicalement, Salix ( converser) 4 novembre 2008 à 18:38 (CET)
- Premier jet, n'hésitez pas à améliorer. Cordialement, --Lgd (d) 5 novembre 2008 à 07:11 (CET)
- Voir également Discussion Utilisateur:Maurilbert pour quelques questions et précisions essentielles, avec un exemple d'image dont le sens est indispensable à la compréhension d'un article, et un autre exemple pour une image illustrative. --Lgd (d) 5 novembre 2008 à 07:56 (CET)
- Bonjour, j'ai essayé d'harmoniser toute la page mais il reste un gros problème: comment mettre une alternative textuelle dans les galeries???? --amicalement, Salix ( converser) 5 novembre 2008 à 11:06 (CET)
- On ne peut pas. A présent, gallery génère une alternative obligatoirement vide. La correction relève des développeurs. --Lgd (d) 5 novembre 2008 à 11:32 (CET)
- Ok. J'ai ajouté un avertissement pour la section galeries. J'ai bon? --amicalement, Salix ( converser) 5 novembre 2008 à 12:04 (CET)
- Très bien. --Lgd (d) 5 novembre 2008 à 19:13 (CET)
- Ok. J'ai ajouté un avertissement pour la section galeries. J'ai bon? --amicalement, Salix ( converser) 5 novembre 2008 à 12:04 (CET)
- On ne peut pas. A présent, gallery génère une alternative obligatoirement vide. La correction relève des développeurs. --Lgd (d) 5 novembre 2008 à 11:32 (CET)
- Bonjour, j'ai essayé d'harmoniser toute la page mais il reste un gros problème: comment mettre une alternative textuelle dans les galeries???? --amicalement, Salix ( converser) 5 novembre 2008 à 11:06 (CET)
utilisation du contenu généré CSS, de la couleur, et minute philosophique
Quelques objets du délit: Modèle:Arbre généalogique, Modèle:Légende, Modèle:Élément/mini table périodique (et je vous épargne les Catégorie:Modèle Géolocalisation qui relèvent également d'une autre variante du contenu généré CSS)
Que faut-il expliquer à l'auteur de ces modèles ?
- qu'une des informations essentielles qu'il croit présente dans son modèle n'y est qu'en apparence ?
- que Wikipédia privilégie certes le sens et le contenu sur la technique, mais que tout l'intérêt du media adopté par Wikipédia est l'interopérabilité, la réutilisabilité, l'accessibilité, toutes mises à mal par son modèle ? Et qu'il y a, pour cela, une certaine utilisation pertinente de l'outil, et d'autres qui ne le sont pas ?
Ou faut-il s'attaquer au (gros) chantier de reformulation de Wikipédia:Limitez l'usage de la couleur dans les articles et de sa transformation en règle, via une PDD harassante ? (la possibilité pour les contributeurs d'agir sur les couleurs du rendu, en dehors des classes créées via des pages protégées comme Common.css, s'avère à l'usage une erreur évidente: au lieu de laisser ce contributeur travailler tranquillement sur le contenu, il va falloir aller lui casser les pieds avec des considérations techniques).
Avis et bonnes volontés bienvenues --Lgd (d) 6 novembre 2008 à 06:02 (CET)
Des images, des images, et... des images (supersize me, version pixel)
Au fait, qu'est-ce qu'on fait d'un modèle comme {{panorama}}, surtout quand il est utilisé comme ça ? --Maurilbert (discuter) 8 novembre 2008 à 03:45 (CET)
- J'ai corrigé {{panorama}} pour qu'il gère également un paramètre
alternative. Si celui-ci est absent, le modèle génère unalt="Image panoramique"générique (faute de mieux...). - Sinon, je prèfère rester lâchement dans une totale neutralité sur l'usage et les abus éventuels d'images panoramiques . --Lgd (d) 9 novembre 2008 à 11:06 (CET)
Une nouvelle infobox unique pour les communes
Voir : Discussion Projet:Communes de France chapitre 39, et surtout la nouvelle infobox utilisée dont je doute fortement des progrès en accessibilité. --H du Viala (d) 9 novembre 2008 à 20:07 (CET)
- Hum... Pour résumer le fond de ma pensée, après quelques semaines loin de tout cela:
- La géolocalisation côté client via le pseudo-contenu CSS (méthode actuelle dans Wikipédia) est une erreur de fond, et je ne parle même pas d'accessibilité mais des bases de l'interopérabilité et de la sémantique. Je ne vois pas (ou plus) l'intérêt de faire semblant et de perdre du temps avec un système dont la seule évolution pertinente sera la suppression et le remplacement par une génération côté serveur d'images réellement signifiantes.
- La double géolocation est utilisée de manière irréfléchie (intérêt limité vue le choix des cartes) et le script pénalise les performances de rendu. Il n'est d'ailleurs pas acquis qu'il soit conservé et qu'il ne soit pas supprimé un jour ou l'autre. En cas de « quadruple géolocalisation », je m'étonne de la quasi absence d'information spécifique apportée par l'alternance de cartes comme Image:Charente-Maritime department relief location map.jpg et Image:Charente-Maritime department location map.svg. Même étonnement pour les pages comme celles des Communes de Polynésie où le modèle embarque, sans le montrer, deux fois la même carte sans géolocalisation et avec des alternatives textuelles vides. On peut encore citer le lien qui alterne son libellé entre « départementale » et... « départementale », le script associé qui ne semble pas fonctionnel dans IE, etc.
- En dehors de la géolocalisation, les dégât
sont partiellementauraient pu être limités par le fait que cette nouvelle infobox est issue des corrections que j'ai déjà faites sur un autre modèle d'infobox.Finalement, cela ne fait jamais qu'une infobox concurrente de plus, pas plus accessible que les autres.Malheureusement, les ajouts propres à cette infobox sont faits en dépit des règles de base pourtant présentes dans les pages d'aide à la syntaxe wiki (imbrication de tableaux, balisage d'en-têtes erronés, liens « détail » non explicites). Côté gestion du modèle, sa lourdeur est évidente (abus de#switch:inutiles). - Les infobox finiront par évoluer dans le bon sens et par devenir réellement signifiantes et accessibles, avec des contenus effectivement pertinents. Mais ce n'est certainement pas par celles des Communes de France que je reprendrai ce chantier.
- Donc... Désolé, mais, pour ma part, je botte en touche, ayant assez donné et ayant d'autres priorités. Mon seul avis serait de corriger au moins cette pléthore inutile de modèles, qu'un meta-modèle pourrait rationaliser. (Mis à jour, je n'avais pas tout vu hier) Cordialement, --Lgd (d) 9 novembre 2008 à 20:31 (CET)
Modèle:Infobox Communes de France est proposé à la suppression
|
Bonjour,
Un article dans l’édition duquel vous vous êtes investi ou de votre domaine de connaissance, Modèle:Infobox Communes de France, a été proposé à la suppression (cf. Wikipédia:Pages à supprimer). La discussion a lieu sur la page Discussion modèle:Infobox Communes de France/Suppression. Après avoir pris connaissance des Critères d’admissibilité des articles, vous pouvez y donner votre avis. |
Vous ne pouvez vraiment pas arrêter deux minutes de faire n'importe quoi dans tous les sens, avec de projet Communes de France et ces infobox ?
On ne supprime pas un modèle, sauf très particulier et absolument impossible à corriger, pour des raisons d'accessibilité. On le corrige ou on s'abstient d'intervenir à ce titre.
J'ai donné mon avis et je me suis abstenu d'intervenir plus avant, en expliquant qu'il ne s'agissait que d'un avsi personnel, justement pour éviter ce genre de choses. Mais je vous remercie d'avoir pris le problème de l'accessibilité en otage dans les conflits entre contributeurs de ce projet, c'est brillant. Vraiment brillant. --Lgd (d) 10 novembre 2008 à 18:25 (CET)
- Je ne suis pas membre du projet communes de France, et ce n'est pas moi qui fait n'importe quoi en créant pléthore de modèles contre l'avis des autres membres du projet. Je me suis contenté de proposer à la suppression ce modèle qui pose tant de problèmes et qui semble paralyser les discussions pour un modèle unique. Ce que j'espère, c'est pouvoir ainsi sortir ce projet et ses membres des conflits dans lesquels ils se sont embourbés. Je ne prends personne en otage, au contraire, j'essaye de débloquer une situation dans laquelle tous sont otages les uns des autres. TED 10 novembre 2008 à 18:38 (CET)
- Non. Pour débloquer la situation en question, il aurait été pertinent d'évoquer le fait que ce modèle avait été créé puis répandu contre l'avis général des contributeurs impliqués dans ces débats. Tu pouvais même ajouter le fait que cela ait été fait sous des motifs d'edits fantaisistes (je me souviens avoir passer des « typos » comme motifs d'édits où le modèle était ajouté aux articles). Tout cela permettait de réverter, voire de proposer la suppression du modèle, mais intelligemment. Là, tu as juste pris le prétexte le plus démagogique.
- Ce que je regrette, c'est l'image que cela donne du travail fait ici. Ce n'est pas pour rien, justement, que je ne me rue pas sur les PàS. --Lgd (d) 10 novembre 2008 à 18:59 (CET)
Mise à jour des bonnes pratiques accessibilité
Hello,
Les bonnes pratiques ont subi un petit lifting, avec une présentation plus lisible, différentes mises à jour, des exemples plus appropriés. Vos avis ?
Sinon, je commence à me tâter sérieusement pour lancer dans quelques temps une PDD sur un premier lot de ces BP, une fois leur rédaction finalisée. Voilà, c'est dit . --Lgd (d) 11 novembre 2008 à 12:58 (CET)
Lien sur image, une excellente nouvelle
Une excellente nouvelle pour l'accessibilité: mediawiki implémente à présent des lien sur image enfin corrects, avec la possibilité de renseigner une alternative textuelle parfaitement pertinente et pas de souci de title (du moins, pas de souci pour les liens externes, pas de souci majeur pour les liens internes).
Ce sont potentiellement toutes les icônes utilisées dans les bandeaux qui peuvent devenir enfin accessibles, par exemple.
En revanche, il va falloir veiller à ce que l'alternative soit alors systématiquement renseignée: mediawiki génère (hélas) une alternative vide si celle-ci n'est pas indiquée... --Lgd (d) 13 novembre 2008 à 00:17 (CET)
Bonjour ! Je me pose une question ce matin : dans cet article, j'ai mis un {{lang}} pour la prononciation du mot, mais... le titre lui-même est à prononcer en anglais. Y a-t-il quelque chose à faire dans un cas comme ça ? Merci d'avance ! --Maurilbert (discuter) 19 novembre 2008 à 14:02 (CET)
- Hélas non. Cordialement, --Lgd (d) 20 novembre 2008 à 02:39 (CET)
Tableau triables
Bonjour, peut-on encourager l'utilisation de ce type de tableau dans les articles? Voir aide tableaux. --amicalement, Salix ( converser) 19 novembre 2008 à 17:33 (CET)
- Bien:
- C'est utilisable au clavier
- Pas de contenu parasite quand javascript est désactivé
- Moins bien:
- L'alternative textuelle des boutons de tri est peu ou pas compréhensible (« ? » ou « ? », alors que « tri en ordre croissant » et « tri en ordre décroissant » auraient été pertinents.)
- Pas bien du tout:
- On ne peut évidemment pas empêcher l'utilisation de
{|class="wikitable sortable"malgré le souci d'alternative textuelle (qui est suceptible d'être corrigé par les développeur mediawiki un jour). En revanche, celles des modèles {{Smn}} et {{Tri}} devrait être découragée. - Par ailleurs, le tri dans 80% des tableaux triables n'a aucune utilité, mais c'est fun et donc interactif, je suppose)
- Cordialement, --Lgd (d) 20 novembre 2008 à 02:31 (CET)
- Merci pour cette réponse. Au fait, en parlant de tableau, ce tableau est-il vraiment compréhensible avec un lecteur d'écran? Il me semble que non. --amicalement, Salix ( converser) 24 novembre 2008 à 14:43 (CET)
- Parfaitement compréhensible (concrètement: lorsqu'on se déplace de cellule en cellule, le lecteur dispose des métadonnées nécessaires pour rappeler quel est l'en-tête de colonne appliqué à la cellule en cours). heureusement: c'est moi qui ai écrit cet exemple --Lgd (d) 24 novembre 2008 à 14:49 (CET)
- Ouf! C'était juste pour être sûre que rien ne nous avait échappé... --amicalement, Salix ( converser) 24 novembre 2008 à 14:59 (CET)
- Parfaitement compréhensible (concrètement: lorsqu'on se déplace de cellule en cellule, le lecteur dispose des métadonnées nécessaires pour rappeler quel est l'en-tête de colonne appliqué à la cellule en cours). heureusement: c'est moi qui ai écrit cet exemple
- Merci pour cette réponse. Au fait, en parlant de tableau, ce tableau est-il vraiment compréhensible avec un lecteur d'écran? Il me semble que non. --amicalement, Salix ( converser) 24 novembre 2008 à 14:43 (CET)
Intégration d'un logo dans un modèle
Bonjour, il faudrait ajouter le logo 
à ce modèle: {{Biohomonymie}}, juste à la suite de la phrase du haut : « Nom vernaculaire ou
nom normalisé ambigu (logo)», ceci afin d'indiquer aux non francophones qu'il s'agit d'un article d'orientation et pas d'un taxon biologique. Comment le faire proprement du point de vue accesibilité. Autement dit, Lgd pourrais-tu le faire à l'occasion? --amicalement, Salix ( converser) 22 novembre 2008 à 11:50 (CET)
- Je suis passé dessus pour retirer une icône, et du coup j'ai patché un autre modèle. Je voulais savoir si ce n'est pas trop verbeux, et comme maintenant il y a des
alt, vaut-il mieux l'elle ou l'autre de ces deux descriptions, ou ni l'une ni l'autre, d'ailleurs :D[[Image:Nuvola apps important.svg|15px|Icône pour souligner l'importance du texte]] blablabla blablabla[[Image:Nuvola apps important.svg|15px|Attention|alt=Icône pour souligner l'importance du texte]] blablabla blablabla
- Merci encore. bayo 25 novembre 2008 à 16:16 (CET)
[[Image:Nuvola apps important.svg|15px|Icône attention !]] blablabla blablabla, peut-être. --Lgd (d) 25 novembre 2008 à 16:18 (CET)
Accessibilité des pages d'aide
Bonjour, au moment où le projet aide songe à créer une charte graphique, et en faisant quelques statistiques en cliquant plusieurs fois sur Special:Random/Aide, quelles sont les erreurs à ne pas commettre. Que dire en particulier des pages liées aux onglets?
- Aide:Tout l'indispensable... :
- Aide:Sommaire :
- Aide:Poser une question :
- Wikipédia:Accueil des nouveaux arrivants :
- Projet:Service de Parrainage Actif/Parrainés :
- Wikipédia:Demander :
et aussi
- Aide:Premiers pas :
- etc.
--amicalement, Salix ( converser) 24 novembre 2008 à 19:55 (CET)
- Il n'y a rien de particulier par rapport à n'importe quelle autre page. Si je regarde plus précisément les pages ci-dessus, on peut simplement noter:
- Ne pas utiliser
;(liste de définition) pour faire un paragraphe introductif d'une liste à puces (Aide:Tout l'indispensable..., section « pour aller plus loin » ): utiliser un simple paragraphe ou un titre (===) - Fournir une alternative descriptive aux images en thumb (paramètre
altdes thumbs) et, autant que possible de manière pertinente, aux icônes du type
et 
- Ne pas casser la structure hiérarchique du titrage (
h2,h3,h4) qui avait été corrigée dans les pages comme Wikipédia:Demander et qui est actuellement correcte.
- Ne pas utiliser
- Le modèle onglet ne pose pas de problèmes majeurs (C'est un tableau de présentation, mais il se linéarise correctement et ne comporte pas de code propre aux tableaux de données)
- Sinon, ce n'est pas de l'accessibilité, mais en CSS:
float:centern'existe pas etdisplay:blockest redondant et inutile quandfloatest appliqué à la mêmediv(Projet:Service de Parrainage Actif/Parrainés). --Lgd (d) 25 novembre 2008 à 03:11 (CET)- Merci pour ces réponses précises. Donc les encadrés ne posent à priori pas de problèmes? --amicalement, Salix ( converser) 25 novembre 2008 à 11:15 (CET)
- Hello. Je viens de retoucher Aide:Tout l'indispensable... avec des
;:, ça vaut ce que ça vaut hein :) C'est peut-être complètement HC. bayo 25 novembre 2008 à 15:47 (CET)- Bah, ce serait mieux d'éviter, justement : les listes de définitions sont couramment détournées de leur usage sur Wikipédia (à cause de leur usage dans les discussions, comme ici), mais si on peut ne pas les détourner en plus pour en faire des pseudos-titres, ce serait tout de même déjà un premier pas : leur utilisation à la place des titres réduit la pertinence de la table des matières (qu'il s'agisse de la TOC de mediawiki ou de la table extraite par les aides techniques). Voir l'aspect norme d'accessibilité WCAG.
- Compromis: des paragraphes avec des
strongseraient déjà un moindre mal. --Lgd (d) 25 novembre 2008 à 16:00 (CET)- Hop, voilà des titres normaux. La page reste tout aussi consultable ; j'oserais même dire quelle est mieux :) bayo 25 novembre 2008 à 16:31 (CET)
- Je les ai passés en sections de niveau 5, pour alléger la page en attendant une idée géniale. --amicalement, Salix ( converser) 25 novembre 2008 à 17:23 (CET)
- Nan. Jamais de H5 après des H2
- C'est corrigé, avec des
<h3 style="font-size: 1em;border: 0;">qui ont la même allure, sans les liens d'édition en prime. Mieux ? --Lgd (d) 25 novembre 2008 à 17:37 (CET)- J'avais dit « en attendant une idée géniale » ... C'est impec mais comment veux-tu qu'un wikipédien moyen, c'est à dire sans CSS (Cerveau Special Style) et sans greffe d'« htmoëlle », puisse trouver ça
Tu triches! --amicalement, Salix ( converser) 25 novembre 2008 à 18:14 (CET)
- C'est généralement le but des modèles. Ca intéresserait pas mal de monde amha de mettre ça dans un modèle genre
{{m|sous-titre|niveau de titre|texte}}, car ce genre de mise en forme est pas mal utilisé partout. (dommage qu'on ne puisse pas automatiser la réutilisation du titre précédent + 1). bayo 26 novembre 2008 à 10:49 (CET)- J'avais proposé il y a pas de temps de placer les styles nécessaires dans MediaWiki:Common.css, quand j'avais déjà fait ce type de correction pour Aide:Sommaire par exemple. La proposition reste d'actualité, avec en effet le modèle qui va et quelques classes CSS mutualisant les options les plus couramment utilisables de titres stylés comme un de ses niveaux précédent. Je mets ça sur ma todo. --Lgd (d) 27 novembre 2008 à 05:44 (CET)
- Quelque-chose comme Utilisateur:Lgd_test#Next ? (à poursuivre) --Lgd (d) 29 novembre 2008 à 06:59 (CET)
- J'avais proposé il y a pas de temps de placer les styles nécessaires dans MediaWiki:Common.css, quand j'avais déjà fait ce type de correction pour Aide:Sommaire par exemple. La proposition reste d'actualité, avec en effet le modèle qui va et quelques classes CSS mutualisant les options les plus couramment utilisables de titres stylés comme un de ses niveaux précédent. Je mets ça sur ma todo. --Lgd (d) 27 novembre 2008 à 05:44 (CET)
- C'est généralement le but des modèles. Ca intéresserait pas mal de monde amha de mettre ça dans un modèle genre
- J'avais dit « en attendant une idée géniale »
- Nan. Jamais de H5 après des H2
- Je les ai passés en sections de niveau 5, pour alléger la page en attendant une idée géniale. --amicalement, Salix ( converser) 25 novembre 2008 à 17:23 (CET)
- Hop, voilà des titres normaux. La page reste tout aussi consultable ; j'oserais même dire quelle est mieux :) bayo 25 novembre 2008 à 16:31 (CET)
- Bah, ce serait mieux d'éviter, justement
- Hello. Je viens de retoucher Aide:Tout l'indispensable... avec des
- Merci pour ces réponses précises. Donc les encadrés ne posent à priori pas de problèmes? --amicalement, Salix ( converser) 25 novembre 2008 à 11:15 (CET)
![[3]](https://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Routes_des_ch%C3%A2teaux_cathares_sans.svg/744px-Routes_des_ch%C3%A2teaux_cathares_sans.svg.png){kind=link}
probleme avec un tableau sur Eleutherodactylus
Tcho
suivant la resolution, l'affichage du tableau de l'article Eleutherodactylus (la grande liste avec toutes les especes) s'affiche differemment : avec une resolution faible, la liste commence apres la taxobox, avec une forte resolution, la liste commence au niveau du sous-ordre de la taxobox... qu'est ce que vous conseillez dans ces cas la sachant qu'on aimerait quand meme utiliser un tableau pour ne pas avoir un article tres tres long avec pas grand chose dedans ?... Poleta33 (d) 26 novembre 2008 à 10:41 (CET)
- Bonjour. C'est de la mise en forme hors du cadre de l'accessibilité.
- Toutefois, pour sauter la taxobox, il suffit de placer un {{clr}} afin pour forcer l'usage d'une zone sans elements flotants.
- Je n'avais au début pas bien compris la demande, j'ai alors ajouté {{Début de colonnes}} pour demander la mise en forme de colonnes du coté du navigateur. Ca permet d'avoir des colonnes homogènes (si le navigateur le supporte) quelque soit la résolution, par contre il y a de temps en temps un découpage du texte des puces (le debut en bas, la fin sur la colonne suivante), que l'on peut peut-être corriger par du style (amis spécialistes CSS). A vous de voir si c'est mieux ou moins bien.
- CSS3 devrait corriger le problème en évitant des sauts de colonnes pour certains éléments, et on peut alors appliquer cela assez facilement dans Wikipédia.
- bayo 26 novembre 2008 à 11:09 (CET)
- je plussoie bayo : il est préférable d'utiliser le modèle sans tableaux de mise en forme, même s'il ne donne le rendu souhaité que dans Firefox et Safari. --Lgd (d) 27 novembre 2008 à 05:41 (CET)
Bonjour,
Je suis surpris de trouver dans la page Wikipédia:Atelier accessibilité/Suivi des points positifs des points tels que ImageMap et {{Lien sur icône}}. Je pensais que les ImageMaps étaient spécialement mauvaises pour l'accessibilité. Le modèle Lien sur icône utilise pour l'instant toujours des ImageMaps, alors qu'il y aurait moyen d'utiliser la fonctionnalité des liens sur images implémentée récemment dans MediaWiki.
J'ai aussi trouvé dans cette page les équations mathématiques, qui me paraissaient poser un gros problème d'accessibilité. À moins que les lecteurs d'écran lisent le TeX, puisque le code TeX utilisé est mis en texte alternatif de l'image.
— Delhovlyn • [discuter] – 6 décembre 2008 à 10:16 (CET)
- L'extension
<imagemappermet de produire soit une image cliquable (élémentsmapetarea), soit une simple image lien qui respectent toutes deux les règles d'accessibilité WCAG (alternatives textuelles de l'image et des zonesarea, utilisation pertinente de l'attributtitledu lien, etc.).<imagemap>est, à cet égard, largement préférable aux superpositions de liens textes ou graphiques sur une image de fond de carte via CSS. Pour approfondir, voir la méthode d'application RGAA. Peut-être ta remarque sur l'accessibilité des imagemap vient-elle d'une confusion entre images cliquables côté client (imagemap, accessibles) et images cliquables côté serveur (effectivement et définitivement non accessibles) ? - Avant que la récente implémentation de la syntaxe wiki
[[Image:Exemple.jpg|Alternative textuelle|link=page cible]]ne permette d'obtenir immédiatement un lien sur image accessible, {{Lien sur icône}} permettait de parvenir à ce résultat, d'où cette évaluation initiale dans Wikipédia:Atelier accessibilité/Suivi des points positifs. Son utilisation n'est évidemment plus nécessaire à présent, mais j'avoue que j'ai du retard dans la mise à jour de cette page (dont la forme est à revoir, en fait), et que je me suis surtout concentré sur la mise à jour des bonnes pratiques, notamment sur les liens sur images et sur imagemap. - Les équations mathématiques sont un sujet plus complexe que je n'ai pas encore eu le temps de documenter, mais en résumé: même si le résultat est imparfait, la fonctionnalité
<math>permet une accessibilité minimale, dans la mesure où elle génère essentiellement une image PNG dont l'alternative textuelle est potentiellement compréhensible pour un utilisateur habitué à ce contexte mathématique. Les limites en matière d'accessibilité ne tiennent pas tant à cette fonctionnalité de mediawiki qu'aux difficultés propres aux contenus mathématiques. Cordialement, --Lgd (d) 10 décembre 2008 à 08:38 (CET)
- J'ajouterais à cette réponse de Lgd que j'avais à une époque exploré divers outils de génération automatique de code HTML à partir de (La)TeX. La solution consistant à donner comme alternative de l'image le code (La)TeX est effectivement la moins mauvaise. J'en ai rencontré qui, probablement par excès de bonne volonté, reproduisaient graphiquement les symboles mathématiques (pour un signe ?, par exemple, le logiciel utilisait une combinaison d'espaces et de caractères /, | et \). Quand le MathML « sémantique » sera supporté par les navigateurs (et pas uniquement le MathML « de présentation), on pourra envisager de l'utiliser, mais nous en sommes loin. GillesC ?m'écrire 10 décembre 2008 à 10:31 (CET)
- J'ai un peu de mal avec MathML.
- MediaWiki convertit donc à la volée en MathML de présentation ? (préférence utilisateur)
- Dans la mesure ou MediaWiki convertit à la volée, y-a-il un problème à décrire les équations en MathML sémantique
- Comme il y a des préférences utilisateur, on pourrait bien choisir entre MathML sémantique/présentation, pas besoin d'attendre que les navigateurs graphiques le supporte.
- Ya certainement des pages qui expliquent tout ça... mais comme vous en parlez :-) bayo 10 décembre 2008 à 11:14 (CET)
- Justement, je viens de régler dans mes préférences (rendu des maths) l'affichage en MathML, mais n'ai pas vu de changement dans le code HTML produit (en tout cas aucun sur la page de test que j'ai consultée )... Le fait est qu'aux dernières nouvelles, le MathML sémantique n'était que peu, voire pas, pris en charge nativement. Mais il en était de même de SVG il y a quelques années, ainsi que de SMIL ah oui, oups, on me souffle dans l'oreille que ce dernier format serait plutôt encore mal supporté, même s'il n'est pas encore tout à fait moribond. GillesC ?m'écrire 10 décembre 2008 à 11:41 (CET)
- Justement, je viens de régler dans mes préférences (rendu des maths) l'affichage en MathML, mais n'ai pas vu de changement dans le code HTML produit (en tout cas aucun sur la page de test que j'ai consultée
- J'ai un peu de mal avec MathML.
- L'extension
-ms-
Un peu rien à voire avec l'accessibilité. Au grès de mes navigations, je suis tombé sur le préfixe CSS -ms- pour identifier les propriétés uniquement Microsoft ; par ailleurs, mon navigateur me fatigue à relever des erreurs sur la propriété zoom. Serait-il envisageable de remplacer ces zoom par des -ms-zoom ? Je n'ai bien sûre pas testé :-). Merci. bayo 10 décembre 2008 à 11:20 (CET)
- Ce préfixe CSS2.1 est théorique et n'est pas implémenté par le navigateur visé (IE). --Lgd (d) 10 décembre 2008 à 11:55 (CET)
- Ah oui, ce serait bien que Firefox arrête de relever cette erreur systématiquement. — Delhovlyn • [discuter] – 14 décembre 2008 à 16:25 (CET)
- Je me passerai moi aussi volontier de cette erreur formelle, mais il n'y a pas d'alternative sans effets de bords divers et plus ou moins prévisibles. D'autres propriétés (valides CSS2.1) produisent le même effet que
zoom:1, et je les privilégie à chaque fois que c'est possible (width:100%,floaten particulier). Malheureusement, à la différence dezoom:1, elles ne sont évidemment pas indifférentes aux autres navigateurs qu'IE et, en fonction du contexte CSS, s'avèrent souvent inutilisables quand elles provoquent des résultats indésirables. C'est pourquoi la gestion du haslayout passe principalement aujourd'hui par la propriétézoom. Le seul défaut de mediawiki est de ne pas donner la main aux contributeurs sur les CSS en commentaires conditionnels pour IE, ce qui oblige à mettre ceszoomdans Common.css et dans les attributsstyle. - Pour relativiser tout de même le souci : l'ajout de cette propriété permet d'éviter des bugs lourds de rendu dans IE, provoquant notamment des pertes de contenu en cas de bug de reflow (exemple), et les visiteurs ou la plupart des contributeurs ne naviguent pas avec une console d'erreur --Lgd (d) 15 décembre 2008 à 07:37 (CET)
- En fait il faudrait peut-être demander un message système MediaWiki:IEfixes.css. — Delhovlyn • [discuter] – 16 décembre 2008 à 20:11 (CET)
- Moui. Message système ou Mediawiki:ie7.css et Mediawiki:ie6.css sur le modèle de Mediawiki:Common.css, ce serait indifférent. Le template de base de Wikipédia devra dans les deux cas être modifié pour générer, si ces CSS ont été créée, deux appels de feuilles de styles en commentaires conditionnels. Et il resterait à gérer des déclinaisons entre skins. Mais je doute que la modification soit jugée vraiment pertinente côté développement, l'utilisation de ces correctifs étant un peu pointue et encore assez rare dans les diverses Wikipédias. --Lgd (d) 17 décembre 2008 à 08:09 (CET)
- En fait il faudrait peut-être demander un message système MediaWiki:IEfixes.css. — Delhovlyn • [discuter] – 16 décembre 2008 à 20:11 (CET)
- Je me passerai moi aussi volontier de cette erreur formelle, mais il n'y a pas d'alternative sans effets de bords divers et plus ou moins prévisibles. D'autres propriétés (valides CSS2.1) produisent le même effet que
- Ah oui, ce serait bien que Firefox arrête de relever cette erreur systématiquement. — Delhovlyn • [discuter] – 14 décembre 2008 à 16:25 (CET)
Utilisation du parseur
Hello. En voulant éditer Wikipédia:Notoriété des associations, j'ai eu le message suivant :
- « Attention : Cette page contient trop d’appels dispendieux de fonctions du parseur. Il devrait y en avoir moins de 500 sur le nombre actuel de 647. »
Est-ce que cela est dû aux nombreux modèles inclus dans cette page ? Et que convient-il de faire ? Amicalement, Dodoïste [réveille-moi] 14 décembre 2008 à 15:10 (CET)
- Trop de if, switch, etc. Donc, oui, c'est à cause des modèles inclus dans la page. Que convient-il de faire est autre chose. Est-il obligatoire d'user de {{Jurisprudence PàS}} ou de {{a}} ? Si non, les virer en les remplaçant par un simple lien est une solution. (Par contre, je ne pense pas que cette question soit en rapport avec l'accessiblité). Amicalement — Steƒ ????? 14 décembre 2008 à 15:16 (CET)
- Note: le coupable principal est
{{#ifexist:...}}, en fait, dans ce modèle {{a}}. --Lgd (d) 14 décembre 2008 à 15:22 (CET)- Merci de vos réponses. Je vais voir si on peut se passer de ces modèles. Si cela concerne ou pas l'atelier accessibilité, je réalise à l'instant que la Guilde des guildes aurait peut-être été mieux...
Pardon. Dodoïste [réveille-moi] 14 décembre 2008 à 15:23 (CET)
- À savoir que les deux fonctions présumées coupables seraient
{{#ifexist:...}}et{{PAGESINCATEGORY:...}}, comme indiqué sur Catégorie:Page avec trop d'appels dispendieux de fonctions parseurs. — Delhovlyn • [discuter] – 14 décembre 2008 à 15:54 (CET)
- À savoir que les deux fonctions présumées coupables seraient
- Merci de vos réponses. Je vais voir si on peut se passer de ces modèles. Si cela concerne ou pas l'atelier accessibilité, je réalise à l'instant que la Guilde des guildes aurait peut-être été mieux...
- Note: le coupable principal est
Cartes de répartition dans les taxobox
Salut, on aurait besoin d'un avis à propos de l'accessibilité des cartes de répartition biologiques placées dans les taxobox? ça se passe ici.--amicalement, Salix ( converser) 14 décembre 2008 à 16:58 (CET)
Encore moi. La généralisation de ce modèle dans le but de mettre le titre des articles d'une grande partie des taxons biologiques en italiques à partir des genres et en dessous (voir taxon), poserait-elle un problème? Si oui y aurait-il une autre solution pour obtenir le même résultat? --amicalement, Salix ( converser) 14 décembre 2008 à 19:42 (CET)
- On me semble que cela avait été abordé ici. Ce modèle est inoffensif ou presque : il représente juste un zest de javascript inutile mais sans conséquences pour l'accessibilité. Il est en effet inutile ou plutôt illusoire, puisqu'il ne s'agit que de cosmétique et que la structure HTML ne comporte de toutes façons pas le balisage sémantique qui ferait que cet italique existerait vraiment et serait porteur de sens. Mais bref, si cela suffit en l'état à faire le bonheur des amateurs de typographie fine, tant mieux
- Il n'y a pas d'autres moyens pour le faire, donc: ne pas toucher aux habitudes. Cordialement, --Lgd (d) 14 décembre 2008 à 19:53 (CET)
- Merci pour ta réponse rapide Lgd. Ça a déjà été abordé, je sais, mais la discussion n'est pas close et l'utilisation massive de ce modèle est à nouveau envisagée alors que nous avons des avis techniques contradictoires. Pour être certaine de comprendre : que veux-tu dire exactement par "illusoire" et "cosmétique"? Qui n'aurait pas les italiques à l'écran? --amicalement, Salix ( converser) 14 décembre 2008 à 20:24 (CET)
- C'est une information qui n'est pas dans la source de la page, et qui n'y est ajoutée qu'en apparence, par le navigateur lorsqu'il l'affiche. Dés lors:
- Sans javascript, pas d'italique : utilisateurs sur des réseaux où il a été désactivé par les administrateurs réseaux (pour des motifs mystérieux), utilisateurs l'ayant désactivé parce que les javascripts rencontrés sur leurs sites favoris leur posent des problèmes, mobiles et PDA dont les capacités javascript sont variables, etc.
- Réutilisation du contenu de Wikipédia: pas d'italique (on ne récupère pas nécessairement, et plutôt pas, les multiples javascripts locaux quand on réutilise juste des contenus d'articles).
- S'il était possible de baliser ce titre, via la source des articles, avec l'élément HTML
idont le rôle est justement de définir des contenus dont le rendu en italique a une « sémantique », le sens serait alors présent pour tout le monde et dans toutes les réutilisations. Mais mediawiki ne le permet pas.--Lgd (d) 14 décembre 2008 à 20:32 (CET)- Merci beaucoup pour ces éclaircissements . --amicalement, Salix ( converser) 14 décembre 2008 à 22:23 (CET)
- Merci beaucoup pour ces éclaircissements
- C'est une information qui n'est pas dans la source de la page, et qui n'y est ajoutée qu'en apparence, par le navigateur lorsqu'il l'affiche. Dés lors:
- Merci pour ta réponse rapide Lgd. Ça a déjà été abordé, je sais, mais la discussion n'est pas close et l'utilisation massive de ce modèle est à nouveau envisagée alors que nous avons des avis techniques contradictoires. Pour être certaine de comprendre : que veux-tu dire exactement par "illusoire" et "cosmétique"? Qui n'aurait pas les italiques à l'écran? --amicalement, Salix ( converser) 14 décembre 2008 à 20:24 (CET)
Créer un modèle dédié ?
Bonjour Lgd ! Qu'en est-il de l'idée que tu avançais le 4 juillet sur Discussion_Projet:Biologie/Le café des biologistes#Titre et italique : « créer un modèle dédié {{Italique}} sur le principe de {{minuscule}} (mais en utilisant l'astuce javascript, sans bandeau) facilitera en effet la maintenance ultérieure : en fonction des développements futurs de {{DISPLAYTITLE:}}, les différents usages de {{titre}} devront peut-être être revus. » ? TED 15 décembre 2008 à 00:44 (CET)
- Pssit, {{titre}} redirige sur {{Titre incorrect}}--amicalement, Salix ( converser) 15 décembre 2008 à 01:19 (CET)
- Si j'ai bien suivi, les termes à mettre en italique dans le titre sont systématiquement latins ? Et le passage par un paramètre de la taxobox serait de bonne gestion ? Dans ce cas, le modèle {{Italique}} est inutile, un sous-modèle de la Taxobox étant suffisant pour la maintenance future. D'autre part, la chose devrait au moins gagner un peu en utilité (même si cela reste du code généré en javascript) en en profitant pour signaler le changement de langue.
- Le paramètre saisi par les contributeurs dans la taxobox serait alors du type :
| realtitle= ''{{lang|la|Lorem ipsum}}'' (Oiseau)- et le code wiki à générer via le sous-modèle de taxobox serait:
<span id="RealTitleBanner" style="display:none"><span id="RealTitle">''{{lang|la|Lorem ipsum}}'' (Oiseau)</span></span>- Enfin, j'ai testé rapidement le résultat côté performance du rendu dans les navigateurs : la fonction javascript
rewritePageH1()semble s'exécuter environ deux fois plus rapidement avec ce code qu'avec le modèle {{Titre incorrect}}. Que demande le peuple ? --Lgd (d) 15 décembre 2008 à 05:05 (CET)
- Ah, une précision (après être retourné lire les échanges sur le sujet) : contrairement à ce qui s'est dit début septembre, il n'est pas nécessaire d'obliger les contributeurs à saisir
<i>...</i>au lieu de''...'': le javascript n'exploite pas la syntaxe saisie par les contributeurs, mais le XHTML finalement produit par mediawiki à partir de celle-ci, et ce résultat est identique dans les deux cas. --Lgd (d) 15 décembre 2008 à 07:15 (CET)
- Ah, une précision (après être retourné lire les échanges sur le sujet) : contrairement à ce qui s'est dit début septembre, il n'est pas nécessaire d'obliger les contributeurs à saisir
Super ! Merci beaucoup. Une (dernière ?) question : quand tu parles d'un sous-modèle de taxobox, est-ce que tu veux dire qu'on peut l'intégrer à un des modèles existant, ou bien est-il préférable de faire un modèle dédié ? TED 16 décembre 2008 à 03:42 (CET)
- Deuxième question : est-il nécessaire de préciser {{lang|la|…}} ? Pourquoi le mettre ? J'ai fait un test sur : Utilisateur:TED/Salix lacrymosaridensTED 16 décembre 2008 à 03:54 (CET)
- C'est indifférent
- C'est une plue-value importante. L'indication de la langue de traitement du contenu n'a pas d'impact sur le rendu affiché, mais cette métadonnée est nécessaire pour les rendus par une synthèse vocale et pour les outils de traduction. Elle est également exploitée par les moteurs de recherche. Cependant, dans ce cas, comme c'est un bricolage via javascript, ce ne sera exploité que par les synthèses vocales des lecteurs d'écran.--Lgd (d) 16 décembre 2008 à 07:21 (CET)
- OK. Une nouvelle question : est-ce que pour les contributeurs, il ne serait pas préférable d'avoir un modèle hors de la taxobox, qui se placerait en haut de la page d'édition ? Histoire de ne pas avoir à fouiller toute la page en cas de pépin.
- Serait-il possible de passer le modèle lang à l'intérieur du modèle ? On n'indiquerait plus que deux paramètres : ce qui est en latin, et ce qui est en français.
- Et encore : sur le café des biologistes, Salix affirme que « pas accessibles avec certaines configurations + complication du code et du temps de chargement de milliers de pages selon les modèles ». Est-ce que tu confirmes ? TED 16 décembre 2008 à 13:54 (CET)
- Pourquoi pas... Il y avait d'autres arguments, il me semble, en faveur de la taxobox, mais les contributeurs concernés sauront mieux te répondre que moi.
- On peut imaginer un modèle auquel on passe comme paramètres ce qui est en latin et ce qui est en français, mais l'intérêt est limité : l'usage du modèle {{lang}} se répand, et son utilisation directe par les contributeurs est de toutes façons une nécessité dans tous les autres contextes.
- Pour ce qu'il y a à dire en matière d'accessibilité, de code etc. voir ci-dessus, section « Modèle:Titre incorrect ». --Lgd (d) 17 décembre 2008 à 05:39 (CET)
- Justement, je lis ci-dessus que tu dis que c'est « sans conséquence pour l'accessibilité », et que « la fonction javascript
rewritePageH1()semble s'exécuter environ deux fois plus rapidement avec ce code qu'avec le modèle {{Titre incorrect}}. Que demande le peuple ? ». Il me semble que c'est à l'opposé des affirmations de Salix, non ? TED 17 décembre 2008 à 11:57 (CET)- Je n'affirme rien TED, je me contente de lire ce qu'a dit Lgd dans ses différentes interventions sur le sujet. A propos du premier modèle : « La question de la mise en italique du titre se résume finalement à surcharger les pages avec un modèle {{titre}} (...) qui contribue à dégrader l'accès aux articles en alourdissant le traitement des pages par les navigateurs (ce modèle exige un détour javascript), encore une fois sans qu'aucune sémantique ne soit produite au passage. » , et ci-dessus à propos du second code, qui peut « s'exécuter environ deux fois plus rapidement avec ce code qu'avec le modèle {{Titre incorrect}}. » d'où j'en conclue qu'il ralenti deux fois moins, mais ralentit quand même! --amicalement, Salix ( converser) 17 décembre 2008 à 18:27 (CET)
- Argh, pris entre le marteau et l'enclume je suis . Bon, mon souci est cependant de ne pas trancher à votre place, mais de vous donner les infos pour le faire. Désolé si, dans cette question d'alourdissement du traitement, elles prêtent à confusion. Tâchons de faire le plus clair possible :
- * la fonction javascript qui intervient avec le modèle {{Titre incorrect}} ou avec le code proposé ci-dessus est dans la catégorie des peu gourmandes : son temps d'exécution est de l'ordre de 1 à 3 ms sous Firefox3 avec une machine disons moyenne.
- * par comparaison, les fonctions les plus gourmandes actuellement, qui constituent des problèmes lourds, prennent plusieurs dizaines de ms, voire plusieurs centaines pour les totalement inacceptables.
- * il faut également prendre en compte l'accumulation de fonctions javascript: une petite plus une petite plus... vous avez compris que la traque à l'inutile n'est pas inutile
- * en conclusion, cette mise en italique n'est pas un problème à elle seule, mais dans son contexte, la plus-value de l'italique seule me semble faible. Avec la mention de la langue et le fait d'attirer l'attention des bio-zoo-etc.-istes sur le modèle {{lang}} dont ils devraient en fait être de gros consommateurs, la plus-value est déjà plus conséquente.
- Je ne tenais pas à me mouiller, mais bon, elle a l'air bonne, donc je risque un orteil : si c'est l'occasion de généraliser l'usage de {{lang}}, je voterai pour l'italique. Dans le cas contraire, ou si l'usage de {{lang}} peut être évoqué à propos des articles bio-etc sans passer par là. mon vote serait négatif. Le tout en précisant bien que j'ai aucun avis sur la pertinence de l'italique par ailleurs (règles typographiques applicables dans le contexte particulier de ces articles, etc.)
- Voilà, en espérant avoir mieux répondu à votre question. Cordialement, --Lgd (d) 17 décembre 2008 à 19:10 (CET)
- Argh, pris entre le marteau et l'enclume je suis
- Donc, si j'ai bien compris, Salix, tu parlais bien toujours du premier modèle sur le café des biologistes, alors que je n'en parlais plus.
- Pour généraliser l'usage de {{lang}}, ce qui me semble une bonne idée : il y a aussi tous les titres des taxons en zoologie au-dessus du genre qui ne se mettent pas en italique, mais qui sont des noms latins. TED 18 décembre 2008 à 04:37 (CET)
- Etant déjà convertie depuis longtemps à l'usage de {{lang}} pour les termes étrangers je ne peux qu'approuver. Il faut simplement savoir que son utilisation au sein du texte est un peu fastidieuse et que, s'il est adopté pour les titres, il faudra logiquement l'adopter pour toutes les occurrences en "latin" dans les articles de biologie. La question est donc de savoir s'il s'agit vraiment de langue latine, nécessitant une prononciation différente du français, ou de noms scientifiques normalisés qu'il est admis de prononcer à la française, contrairement à une citation latine. Dans la première hypothèse la généralisation de ce modèle reviendrait à utiliser la plupart du temps une syntaxe comme ceci dans le texte :
''{{lang|la|[[Chat à pieds noirs|Felis nigripes]]}}''ce qui serait une nouveauté dans les pages et les habitudes de nos biologistes. Cela nécéssiterait l'adaptation des modèles contenant des noms scientifiques latins (Taxobox, cladogrammes...), la formation des contributeurs qui comme TED n'en comprennent pas spontannément l'intérêt, la pose sans doute à la main sur tous les articles et une maintenance pointue car je doute qu'un robot soit capable de détecter automatiquement un nom latin et parce que l'oubli de ce modèle n'est pas visible sur un écran classique. Il faut être bien conscients de tout cela. --amicalement, Salix ( converser) 18 décembre 2008 à 08:05 (CET)- (Plus exactement
''[[Chat à pieds noirs|{{lang|la|Felis nigripes}}]]'') - Mais surtout : l'utilisation de {{lang}} est en effet fastidieuse et son emploi ne sera jamais systématique, loin de là. C'est pourquoi certains usages stratégiques me semblent intéressants, et notamment celui sur le titre : il garantit par exemple qu'au moins la première lecture du terme dans l'ordre du contenu sera correcte. --Lgd (d) 18 décembre 2008 à 08:17 (CET))
- (Plus exactement
- Etant déjà convertie depuis longtemps à l'usage de {{lang}} pour les termes étrangers je ne peux qu'approuver. Il faut simplement savoir que son utilisation au sein du texte est un peu fastidieuse et que, s'il est adopté pour les titres, il faudra logiquement l'adopter pour toutes les occurrences en "latin" dans les articles de biologie. La question est donc de savoir s'il s'agit vraiment de langue latine, nécessitant une prononciation différente du français, ou de noms scientifiques normalisés qu'il est admis de prononcer à la française, contrairement à une citation latine. Dans la première hypothèse la généralisation de ce modèle reviendrait à utiliser la plupart du temps une syntaxe comme ceci dans le texte :
- Je n'affirme rien TED, je me contente de lire ce qu'a dit Lgd dans ses différentes interventions sur le sujet. A propos du premier modèle : « La question de la mise en italique du titre se résume finalement à surcharger les pages avec un modèle {{titre}} (...) qui contribue à dégrader l'accès aux articles en alourdissant le traitement des pages par les navigateurs (ce modèle exige un détour javascript), encore une fois sans qu'aucune sémantique ne soit produite au passage. » , et ci-dessus à propos du second code, qui peut « s'exécuter environ deux fois plus rapidement avec ce code qu'avec le modèle {{Titre incorrect}}. » d'où j'en conclue qu'il ralenti deux fois moins, mais ralentit quand même! --amicalement, Salix ( converser) 17 décembre 2008 à 18:27 (CET)
- Euh, Salix, je ne comprends pas ce que tu nous reproches à ma formation, et à moi : la formulation de ta phrase est aussi limpide qu'un lac de jus de carotte.
- Je comprends très bien l'intérêt de {{lang}}. Concernant le latin scientifique, il n'est pas prononcé à la française : par exemple, Felis nigripes ne se prononce pas « Feuli nigripeu » mais bien « Féliss nigripèss ».
- Je crois qu'on peut facilement généraliser le modèle lang dans les taxobox, en l'intégrant au modèle. À moins que cela ne ralentisse le chargement de la page de faire appel à des modèles imbriqués.
- Pour les titres, j'ai créé des ébauches de modèles à partir du code fourni par Lgd ci-dessus : Utilisateur:TED/Modèle:Titre taxon et Utilisateur:TED/Modèle:Titre taxon zoo qui fonctionnent avec deux paramètres : le premier paramètre est le nom (ou la locution) en latin et le second paramètre, optionnel, contient ce qui n'est pas en latin (par exemple en cas d'homonymie avec une expression française entre parenthèses). Le modèle Titre taxon met automatiquement le nom latin en italique : c'est valable pour les genres, les espèces et tous les autres taxons en botanique, et le modèle Titre taxon zoo ne met pas le nom latin en italique, et est valable pour tous les autres taxons en zoologie. J'ai utilisé le premier modèle sur Utilisateur:TED/Salix lacrymosaridens. On peut aussi l'intégrer aux taxobox si c'est souhaitable.
- Ces modèles pourraient aussi être généralisés en mettant la langue en paramètre, et serait alors utilisable pour toutes les autres langues : voir Utilisateur:TED/Modèle:Titre lang (qui ne met pas d'italiques, mais il me semble que les mots étranger se mettent en italique quand ils ne sont pas entrés dans la langue française).
- Lgd, peux-tu me dire ce que tu penses de ces modèles ? Je ne suis pas habitué avec les modèles, et c'est la première fois que j'en crée complètement un (j'ai déjà fait des modèles, mais par modification d'un modèle existant ressemblant à ce que je voulais faire). En particulier en terme d'accessibilité (puisque c'est l'objet de cet atelier). TED 18 décembre 2008 à 23:26 (CET)
- Hum... je suis très embêté, la situation est nouvelle, mais : là, je crois que vous avez tous les éléments que cet atelier pouvait vous apporter pour éclairer la décision à prendre si vous souhaitez tenir compte des questions sur lesquelles il est compétent. Mon avis personnel sur tel ou tel modèle, telle ou telle décision, je vais éviter ici, j'ai déjà trop fait en ce sens dans d'autres cas, et ce n'était pas une bonne chose. Et puis, je ne suis pas l'atelier accessibilité --Lgd (d) 18 décembre 2008 à 23:35 (CET)
- Euh ? Ce n'est pas ici qu'on peut demander un avis en terme d'accessibilité sur des modèles ? En quoi la situation est-elle nouvelle ? Si c'est le modèle:Titre lang qui te gène, laisse-le tomber : ce sont surtout les deux autres modèles qui m'intéressent. TED 19 décembre 2008 à 00:24 (CET)
- ce qui est nouveau, c'est que le champ de compétence de cet atelier est sur le point d'être un poil instrumentalisé (involontairement) dans une discussion qui n'a maintenant plus grand chose à voir avec l'accessibilité sur le fond (l'italique, les noms de zozios, salix et TED, pour le dire brutalement). D'autres intervenants auront peut-être un éclairage neuf à apporter, mais pour ma part, j'ai atteint ma limite de pertinence. Donc je me tais --Lgd (d) 19 décembre 2008 à 00:29 (CET)
- @ TED : Pour les question techniques il y a aussi Wikipédia:Questions techniques et Projet:Modèles qui donnent un coup de main à l'occasion.
- @ Lgd : Merci pour tout, tu as raison, ce n'est pas à cet atelier de trancher. Si tu as du nouveau par la suite concernant l'amélioration éventuelle de l'accessibilité des titres en italiques, n'hésite pas à le signaler au café des biologistes.
- Bonnes fêtes de fin d'année à tous! --amicalement, Salix ( converser) 19 décembre 2008 à 13:08 (CET)
- pas de souci, je reste dispo si vous avez besoin d'un coup de main pour un modèle sur lequel vous êtes d'accord. Joyeuses Pâques. --Lgd (d) 20 décembre 2008 à 15:25 (CET)
- ce qui est nouveau, c'est que le champ de compétence de cet atelier est sur le point d'être un poil instrumentalisé (involontairement) dans une discussion qui n'a maintenant plus grand chose à voir avec l'accessibilité sur le fond (l'italique, les noms de zozios, salix et TED, pour le dire brutalement). D'autres intervenants auront peut-être un éclairage neuf à apporter, mais pour ma part, j'ai atteint ma limite de pertinence. Donc je me tais
- Euh ? Ce n'est pas ici qu'on peut demander un avis en terme d'accessibilité sur des modèles ? En quoi la situation est-elle nouvelle ? Si c'est le modèle:Titre lang qui te gène, laisse-le tomber : ce sont surtout les deux autres modèles qui m'intéressent. TED 19 décembre 2008 à 00:24 (CET)
- Hum... je suis très embêté, la situation est nouvelle, mais : là, je crois que vous avez tous les éléments que cet atelier pouvait vous apporter pour éclairer la décision à prendre si vous souhaitez tenir compte des questions sur lesquelles il est compétent. Mon avis personnel sur tel ou tel modèle, telle ou telle décision, je vais éviter ici, j'ai déjà trop fait en ce sens dans d'autres cas, et ce n'était pas une bonne chose. Et puis, je ne suis pas l'atelier accessibilité