Discussion Wikipédia:Atelier accessibilité

Vous êtes ici : Accueil > Contribuer > Ateliers > Accessibilité > Poser une question

Cette page est destinée aux questions générales ou techniques portant sur l'accessibilité de Wikipédia.

Vous pouvez également consulter :

• la FAQ accessibilité
• les bonnes pratiques d'accessibilité

Poser une question

Petites choses faciles à faire pour l'accessibilité
tout en meublant les longs après-midi pluvieux

• Indiquer les changements de langue du contenu à l'aide du modèle {{lang}}
  (Comment faire ?)
• Corriger des balisages de tableaux à l'aide de titres de tableaux et de la syntaxe scope
  (Comment faire ?)
• Vérifier à l'aide du gadget que les listes * ou # ne comportent pas de lignes vides
  (Comment faire ?)
• Corriger les mauvais usages de la syntaxe « ; » pour faire une sorte de titre en gras
  (Comment faire ?)
• Corriger les mauvais usages de la syntaxe « : » pour indenter un contenu
  (Comment faire ?)
• utiliser les modèles de citation pour... baliser les citations
  (Comment faire ?)

  Pour vous y aider:

Le gadget accessibilité

Les discussions anciennes sont archivées :

• /Archives accessibilité 2008 - premier semestre
• /Archives accessibilité 2008 - second semestre
• /Archives accessibilité 2009 - premier semestre
• /Archives accessibilité 2009 - second semestre
• /Archives accessibilité 2010 - premier semestre
• /Archives accessibilité 2010 - second semestre
• /Archives accessibilité 2011 - premier semestre
• /Archives accessibilité 2011 - second semestre

Longueur des articles

Bonjour, certaines pages mettent vraiment longtemps à s'afficher quand la liaison internet est un peu capricieuse. Je ne me souviens plus de la méthode pour trouver le poids d'une page et puis y a-t-il des recommandations de limitation à ce sujet quelque part ? --Amicalement, Salix ( converser) 4 janvier 2012 à 10:40 (CET)

Oh, un de mes serpents de mer préféré, l'un des plus jolis

Pour aller à l'essentiel:

• rappel : le poids de la source wiki indiqué par mediawiki (par exemple dans les historiques) n'est pas une donnée significative : deux articles de même poids « wiki » peuvent donner des pages finales (celles qui sont consultées) de poids réel très différents, selon le rôle des images, des modèles etc.
• pour évaluer le poids final d'une page, le mieux est de passer par un service en ligne (ça peut aussi se faire via une extension du navigateur quand on utilise par exemple Firefox, mais cela peut alors être trompeur, je n'entre pas dans les détails obscurs). Un exemple de service de ce type : [1], mais on peut trouver plus simple et en français.
• pour les recommandations : il n'y en pas, ou du moins celles qui traînent encore ça et là dans les pages meta de Wikipédia sont obsolètes. Disons qu'un gros article peut couramment atteindre 1 Mo au final sans que ce soit choquant. Cela place les articles Wikipédia dans la catégorie des obèses si on compare à ce qui se fait sur d'autres sites où ce souci de qualité est spécifiquement pris en compte, mais c'est comme ça.
• pour aller plus loin : pour le moment, je ne sais pas. La difficulté serait de trouver quoi dire aux contributeurs dans quelque-chose qui est très technique (l'impression de vitesse d'affichage en fonction du codage de la page a autant d'importance que la vitesse réelle même si c'est fictif ; l'optimisation réelle du poids des pages Wikipédia passe avant tout par celle des images, qui est loin d'être simple ; l'optimisation javascript joue elle aussi un rôle important ; on a pas du tout la main sur ce que font les développeurs en matière d'astuces de codage des pages et qui n'est pas forcément heureux ; etc.). AMHA, retenir simplement que quand l'intérêt éditorial incite à déplacer une partie du contenu vers un article détaillé en laissant un résumé dans l'article principal, c'est toujours bien.

--Lgd (d) 4 janvier 2012 à 11:03 (CET)

aller, ma question habituelle : je serais curieux de savoir à quels « détails obscurs » tu penses dans le point #2. od†n ↗^blah 4 janvier 2012 à 16:52 (CET)

Par exemple, en cas de proxy FAI optimisant le contenu. --Lgd (d) 4 janvier 2012 à 17:18 (CET)

Merci pour cette réponse rapide et complète. Où peut-on lire exactement pour commencer le poids de la source wiki car c'est déjà, si je comprends bien, un indicateur de longueur du code qui permet de débusquer les logorrhées verbales. --Amicalement, Salix ( converser) 4 janvier 2012 à 11:37 (CET)

Il est vrai que les articles longs sont parfois accompagnés de beaucoup d’images pour les rendre plus digestes, cependant cela n’est pas très indicatif : par exemple les timeline utilisent une certaine place dans les articles, alors que l’appel à une image de Fichier: est beaucoup moins lourd.

Le poids de la source est indiquée par Mediawiki dans l’historique pour chaque version, entre le nom d’utilisateur et le résumé d’édition, et y est visible à condition de ne pas avoir activé le gadget « HistoryNumDiff »
Ltrl G, le 4 janvier 2012 à 13:55 (CET)

Merci Ltrl, j'avais coché ce gadget ! Mais comment éviter d'avoir des poids lourds comme Roger Federer ou Napoléon III qui flirtent avec les 300 000 octets ? --Amicalement, Salix ( converser) 4 janvier 2012 à 14:36 (CET)

Petite question à propos des liste de définitions

Est-ce que quelqu’un pourrait me dire si j’ai raison de penser que des listes de définitions seraient plus adaptées à cette page que des listes classiques ?
Ltrl G, le 4 janvier 2012 à 17:36 (CET)

Tout à fait, comme dans l'exemple du Glossaire du cinéma. --Lgd (d) 4 janvier 2012 à 17:51 (CET)

 Fait. Encore du travail à faire dessus, mais pas tout de suite
Ltrl G, le 4 janvier 2012 à 18:26 (CET)

Et là ?
Ltrl G, le 7 janvier 2012 à 00:05 (CET)

Oui, mais le besoin est moins évident que dans le cas de page proprement « glossaire ». --Lgd (d) 7 janvier 2012 à 00:10 (CET)

Mais comme les éléments de la liste actuelle sont orphelins, autant transformer, non ?
Ltrl G, le 7 janvier 2012 à 00:48 (CET)

Belle infobox

Je viens de tomber sur ceci : {{Infobox Joueur de basket-ball}}. Dans la section « Carrière professionnelle », la mise en page (qui ressemble au tableau qu’elle devrait être) est faite avec… des <br />.
Ltrl G, le 4 janvier 2012 à 21:45 (CET)

Oui, le problème est fréquent en fait. Le souci est que c'est un mode de saisie très pratique pour les contributeurs. Il évite de leur imposer l'usage de sous-modèles (types sous-groupes de palettes ou listes horizontalisées des palettes par exemple) ou celui de multiples paramètres numérotés foo1=... | foo2=... | foo3=... etc. avec en prime une limite du nombre d'occurences à déterminer dans le modèle. D'autre part, la correction de l'infobox nécessite alors un passage de correction dans chaque article, pas forcément aitomatisable avec un bot. Ce n'est pas simple. C'est douloureux. C'est comme ça... --Lgd (d) 5 janvier 2012 à 21:59 (CET)

Infobox V3 et carte

Comme ma question semble, par deux fois, avoir échapper à vos regards plus haut, je la remet ici. Y-a-t'il un moyen de résoudre le problème ci-dessous, que cela soit par un nouveau bloc V3, une « class » particulière, ou carrément la refonte total du système de carte géolocalisé ? 十月 三日 (^o^) appelez moi Ju (^o^) Livre d'Or 5 janvier 2012 à 19:24 (CET)

le Problème

Atelier accessibilité

Localisation sur la carte de Russie : Moscou.

---

---

Localisation sur la carte de Russie : Moscou.

---

capture d'écran du problème, au cas où

 

Note : j'utilise Windows 7 et Firefox 8.0. 十月 三日 (^o^) appelez moi Ju (^o^) Livre d'Or 5 janvier 2012 à 19:25 (CET)

Encore une fois, désolé si la première fois n'était pas passée : Il ne faut pas mettre de modèles de cartes avec géolocalisation, de cartes complétées ou autres cartes bricolées avec des astuces CSS dans les infobox V3. Cela n'a pas de sens : tu mets un bidouillage techniquement périlleux et par ailleurs dramatique pour l'accessibilité dans un modèle d'infobox destiné à obtenir un résultat dont l'accessibilité est certifiée. Ces choses-là sont très bien dans des infobox V2, qui sont d'excellents modèles, tant qu'il n'y a pas enfin une solution de génération de cartes côté serveur.

Un peu fatigué ce soir, d'où ma réponse rapide, mais à ta disposition pour expliquer en détail. Cordialement, --Lgd (d) 5 janvier 2012 à 21:08 (CET)

Réponse du comte Ɲemoi – Le projet des infoboîtes V3 restera un échec tant qu’il ne sera pas admis qu’il y a des demandes et que les modèles d’infoboîtes doivent s’y plier. Un modèle de carte accessible est à coder, sinon il y aura des hacks. Mais je me répète, non ? ce 5 janvier 2012 à 22:32 (CET).

Un modèle de carte fait en CSS avec un assemblage d'une image de fond (image HTML ou background CSS) et de ce qu'on voudra (texte, lien image, élément vide rempli avec un background, combinaison des précédents) de la manière CSS qu'on voudra (positionnement, autre) ne peut pas être fait de manière accessible, parce que le recours à CSS pour générer un contenu ne peut pas être accessible : CSS ne sert fondamentalement pas à générer du contenu, mais uniquement à en faire la mise en forme. Il est donc inutile de réclamer le codage d'un modèle de carte accessible.

Les seules solutions s'appellent génération d'image côté serveur ou SVG directement servi au navigateur. Pour le moment, elle n'existent pas dans l'univers Wikimedia. Donc, on garde le bricolage à base de CSS qui est inévitable ; on sait que ce n'est accessible, on en tient compte et on passe à autre chose sans compromettre ce qui se fait en dehors de ce type de contenus.

Encore une fois : Dès lors qu'une infobox n'est pas actuellement portable en V3, il n'y a aucun souci pour qu'elle reste en V2 et il n'y aura aucun bénéfice à en faire à tous prix une V3 non accessible. --Lgd (d) 5 janvier 2012 à 22:42 (CET)

Il y aurait, cela dit, quelque-chose d'extrêmement pervers à faire des « hacks » (forcer des modèles non pertinents en V3), à les encourager ou à les provoquer : faire une V3, c'est pour le rendre accessible. Faire ce genre de hacks, c'est bosser pour faire inévitablement du non accessible tout en voulant faire de l'accessible. Personnellement, le masochisme n'est pas ma tasse de thé, pas vous  ? --Lgd (d) 5 janvier 2012 à 23:00 (CET)

Réponse du comte Ɲemoi – Il est parfaitement possible d’obtenir un modèle affichant une carte et facilitant l’accès à tous, en rangeant les coordonnées géographiques dans un zouli tableau permettant l’affichage d’une carte « pour ceux qui trouvent ça utile ». Les infoboîtes v2 génèrent un code html abscons et rarement accessible, il est encore temps que le projet accessibilité formalise une solution pour régler ce problème, avant que ce ne soit fait par d’autres. La seule solution pour éviter les hacks, c’est d’offrir des méthodes pour faire ce que l’on souhaite qui facilitent l’accès à tous, en attendant un avenir meilleur pour la technique. Ce 5 janvier 2012 à 23:21 (CET).

Le problème technique d'accessibilité n'est pas de fournir une pseudo-alternative du type tableau de coordonnées. Sinon, ce serait déjà en place... A ce stade, je laisse d'autres tenter de faire de la pédagogie, je perds mon temps (Pour ceux qui me connaissent personnellement ou professionnellement, il est extrêmement rare qu'en tant qu'expert accessibilité, je dise « non, ça, il n'y a pas moyen ». Si je le fais dans ce cas, ce n'est pas à la légère du tout, du tout, du tout...). Bonsoir, --Lgd (d) 5 janvier 2012 à 23:29 (CET)

Réponse du comte Ɲemoi – Le but d’un atelier d’accessibilité sur Wikipédia, c’est de faire au mieux avec ce qu’on a, pas de laisser une situation moisir en traitant de manière irréprochable 0,1 % des infoboîtes. La solution optimale n’est effectivement pas possible actuellement, mais entre les infoboîtes v2 et elle, il y a une bonne dizaine de pas, que l’on gagnerait à faire. Si ce n’est l’atelier d’accessibilité qui s’en charge, c’en sera d’autres. Ce 5 janvier 2012 à 23:40 (CET).

Le cas Nemoi

Je regrette d'en venir là, mais bon, vu ce qui précède, appelons un chat un chat et ne tournons plus autour du pot.

@Nemoi, d'autres te l'ont fait remarquer dans une discussion similaire il y a peu ici : tu es le seul à te placer à propos de ces modèles d'infobox V3 dans une position systématique d'obstruction, d'opposition, de cafouillages qui partent en discussions stériles avec comme seul résultat que ce travail reste pour le moment en suspens.

Je pose clairement la question aux autres contributeurs qui s'investissent dans ces problèmes d'amélioration de l'accessibilité : quelle solution pouvez-vous apporter à ce problème ?

Pour ma part, je suis frappé du décalage complet entre les discussions de ce type ici et ce qui se fait malgré tout ailleurs aujourd'hui même avec d'autres intervenants. Et très simplement incertain quant à la suite à donner à ce que je peux faire dans ce domaine avec vous. Dans tous les cas, il est évident que cela n'ira pas loin sans que quelque-chose ne se décide. Et je ne ferai pas les choses à la place d'autres personnes à cet égard.

Après mes premiers tests dans ce domaine en 2008, il a fallu repousser et attendre 2 ans avant de pouvoir enfin amorcer cette amélioration des infobox, à cause d'un problème similaire. Je ne le ferai pas deux fois.

Cordialement, --Lgd (d) 5 janvier 2012 à 23:47 (CET)

Réponse du comte Ɲemoi – On voit quelqu’un qui refuse toute amélioration concrète des infoboîtes telles qu’elles sont actuellement sous prétexte que l’avenir serait radieux. Sauf qu’en l’état, il y a de plein d’infoboîtes de créées et d’améliorées, qui ont des codes catastrophiques, et rien n’est fait à ce sujet. Ta pratique de ces modèles est très limitées, comme le démontre le modèle : Tapis persan qui donne comme rendu sur la moitié des articles où il est placé ceci… génial, je suppose que c’est toi qui va corriger, n’est-ce pas ? Pour ma part, j’attaque une vraie refonte des infoboîtes dans le mois ; ça signifie que le plus gros du problème d’accessibilité est réglé d’ici mars, si personne ne me met de bâtons dans les roues. Ce 6 janvier 2012 à 00:03 (CET).

Il t'es venu à l'esprit que tu pouvais (apparemment depuis quelques temps au moins) signaler ce problème ici ? Dans ma page de discussion ? Dans la page de discussion du modèle ? Quelque-part ? Parce que la solution est triviale (si quelqu'un peut prendre la liste des pages liées, regarder le cas échéant pour un bot ? Fait).

Ou bien c'est juste une variante du piratage de compte administrateur auquel tu t'étais livré et qui était aussi, sans doute, une manière collaborative de faire les choses ? Bon, bref, moi, je suis usé par ce genre de choses et de pratiques. --Lgd (d) 6 janvier 2012 à 00:37 (CET)

Réponse du comte Ɲemoi – Une attaque personnelle de plus, et encore pour masquer ton incapacité à régler correctement le problème des infoboîtes. Il est vrai que quand je vois qu’est notée par toi en V3 l’infoboîte Bataille Rome antique, tu te situes bien pour parler des hacks de modèles. Il serait préférable que je me charge de ce dossier, comme je me suis chargé des hiddenStuctures, ce que tu n’avais réussi à faire depuis 2008, tu dis ? quelle efficacité… Ce 6 janvier 2012 à 00:53 (CET).

Résumons : ma pratique des modèles est très limitée, je suis incapable de régler correctement le problème des infoboîtes, Modèle:Bataille Rome antique est apparemment un mauvais modèle hacké, j'ai été incapable de régler le problème des hiddenStuctures. Il faut indéniablement se poser la question, mais je laisse la réponse éventuelle à d'autres contributeurs : je suis manifestement incompétent à tous égards. Dès lors, dois-je continuer à intervenir dans ce genre de choses  ? Pourquoi ne pas laisser Nemoi régler à lui seul en un mois le plus gros du problème d’accessibilité, comme il le propose ? --Lgd (d) 6 janvier 2012 à 08:17 (CET)

S'il gère « l'accessibilisation » des modèles comme il a réglé le problème du modèle:Infobox Tapis persan, alors cela va être très efficace et très rapide. Udufruduhu (d) 6 janvier 2012 à 10:08 (CET)

Pour modèle:Infobox Tapis persan, je me suis effectivement trompé au mois d'août dernier, en retirant trop vite le code temporaire qui évitait l'erreur de rendu, croyant avoir effectué les corrections dans les articles. En fait, j'avais oublié ces corrections que je n'avais apparemment pas notées dans ma page de suivi. My fault, donc. Mais s'agissant d'à peine une trentaine d'articles et d'un projet très peu actif, il n'y a apparemment eu aucun signalement d'erreur nulle part. Bref, je suis repassé ce matin dans les articles concerné, c'est réparé à présent, mes excuses pour cette erreur. --Lgd (d) 6 janvier 2012 à 10:21 (CET)

Pas de souci, j'avais bien compris. Je signifiais juste qu'étant donnée la solution simple au problème, je ne comprends pas que Nemoi avec ses grandes capacités ne l'ait pas trouvée et résolu le problème directement… Udufruduhu (d) 6 janvier 2012 à 10:49 (CET)

Réponse du comte Ɲemoi – Car quitte à faire 18 éditions, il aurait été intelligent de renommer l’infoboîte, et de la passer en paramètres nommés, de lui écrire une documentation, et de passer tout dans les articles ; l’infoboîte a été corrigée par Ju gatsu mikka, mais cela n’est même pas répercuté dans les articles malgré les éditions de Lgd, qui — je confirme — n’a pas une pratique des modèles, c’est-à-dire ne songe absolument pas à comment il vont être introduits et maintenus dans l’espace encyclopédique. Je ne suis pour ma part pas partisan du travail vite fait mal fait. Ce 6 janvier 2012 à 13:07 (CET).

Techniquement je suis une truffe, par contre cela fait longtemps que je suis les interventions des uns et des autres. J'admire votre niveau de connaissance dans ce domaine, ce qui est rare sur Wikipédia. Je témoigne simplement que Lgd sait parfaitement travailler en binôme, avec modestie et efficacité, quand c'est au sein d'un dialogue ouvert et consensuel. On s'en fiche de savoir qui est le plus fort en codage : deux cerveaux valent toujours mieux qu'un ! L'important c'est de faire progresser l'accessibilité et - selon l'avis de la plupart des intervenants ici - d'avoir des infobox V3 irréprochables sur ce point. Mais, Nemoi, on ne peux pas affirmer à quelques lignes d'écart que « Le but d’un atelier d’accessibilité sur Wikipédia, c’est de faire au mieux avec ce qu’on a, pas de laisser une situation moisir en traitant de manière irréprochable 0,1 % des infoboîtes » et dans la section en dessous « Je ne suis pour ma part pas partisan du travail vite fait mal fait ». Cela me semble tout à fait contradictoire et àmha il vaudrait peut-être mieux, dans ces conditions, utiliser tes compétences et ton expérience à l'amélioration et l'entretien des infobox V2 qui seront encore pendant longtemps largement en usage. --Amicalement, Salix ( converser) 6 janvier 2012 à 14:22 (CET)

Modèle:Infobox subdivision du Népal

La récente conversion à moitié de cette infobox au format V3 par Nemoi n'aide vraiment pas : faute d'utiliser le modèle approprié pour l'image, le résultat n'est pas accessible. Prendre le temps de bien faire les choses, de demander de l'aide au besoin, ce serait vraiment préférable. Là encore, je ne sais plus par quel bout prendre ce genre de contribution. C'est désarmant, cette manière d'ignorer complètement ce qui est dit, écrit, expliqué, répété… --Lgd (d) 14 janvier 2012 à 13:32 (CET)

Réponse du comte Ɲemoi – Ben écoute, tu n’as qu’à la remettre dans une version avec des hiddenStructure, si ça te fait plaisir. Ce 14 janvier 2012 à 13:45 (CET).

District de Dhading
धादिङ जिल्ला

Légende de la carte

•       District de Dhading
•       Autres districts de la zone de la Bagmati
•       Autres zones de la région Centre
•       Autres districts, zones et régions

Bon, essayons une solution faute de mieux. Est-ce que tu pourrais, en guise de minimum d'effort pour participer de manière collaborative:

• signaler ici les modèles que tu convertis ?
• demander de l'aide en cas de difficulté ?

Voici un point de départ pour corriger le code que tu as produit (résultat ci-contre) :

{{Infobox V3/Début|background=#e0e0e0|text=District de Dhading<br><span lang="ne" class="lang-ne" style="font-size:90%;">धादिङ जिल्ला</span>}}
{{Infobox V3/Image|image=Dhading district location.png|alt=Localisation sur la carte du Népal}}
{{Infobox V3/Titre Bloc|class=hidden||text=Légende de la carte}}
<ul class="legend" style="text-align:left; border:1px solid #ccc; margin:0.3em auto; padding: 5px;">
<li style="list-style:none;"><span style="border: 1px solid black; background-color: red;">    </span>  District de Dhading</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #c0c0c0;">    </span>  Autres districts de la [[Bagmati (zone)|zone de la Bagmati]]</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #f2f2f2;">    </span>  Autres zones de la [[région de développement Centre|région Centre]]</li>
<li style="list-style:none;"><span style="border: 1px solid black; background-color: #fcf5e3;">    </span>  Autres districts, zones et régions</li>
</ul>
{{Infobox V3/Fin}}

Quelques conseils :

• Ne pas utiliser la syntaxe *<li> (c'est de là que venait le div excédentaire généré par mediawiki pour la légende) ;
• Ne pas ajouter xml:lang dans les modèles : il est automatiquement généré par mediawiki en présence d'un lang ;
• Ne jamais inclure l'image d'une infobox V3 avec un paramètre {{{image}}} et des image=[[Image:Dhading district location.png|250px|Localisation du district de Dhading]] dans les articles : cela casse l'accessibilité de l'image.
  Utiliser uniquement le modèle {{Infobox V3/Image}}. S'il faut modifier la manière dont l'image est indiquée en paramètre dans les article, il y a un code temporaire pour cela qui permet de faire les modifications via un bot ou à la main selon les besoins, puis de basculer sur le modèle d'image accessible :

  {{#ifexist:Media:{{{image|}}}|{{Infobox V3/Image|image={{{image|}}}|legend={{{légende|}}}}}|<div class=center>{{{image|}}}</div>}}
  

• Ne pas mette d'attribut style="list-style:none;" sur un span : il ne sert à rien
• Prendre le temps de faire les choses proprement.

--Lgd (d) 14 janvier 2012 à 14:03 (CET)

Réponse du comte Ɲemoi – L’infoboîte ne sera pas accessible de toute façon, elle utilise une légende basée sur la couleur… Quant à la modification que tu proposes, elle impose de passer sur tous les articles (ai rédigé avant ton édition de correction) ; n’hésite pas, c’est ton code, le mien date d’octobre, une époque où je n’avais pas encore réalisé complètement les embêtements que représentent les infobox v3. Ce 14 janvier 2012 à 14:22 (CET).

Oui, il faut passer dans les articles pour mettre à jour le paramètre image et ensuite enlever le code temporaire et le remplacer par le modèle {{Infobox V3/Image}} simple. Cela peut se faire à la main dans les infobox peu employées ou via un bot, comme cela a déjà été fait lors de nombreuses conversions… --Lgd (d) 14 janvier 2012 à 14:31 (CET)

Bon, bref. J'ai corrigé l'infobox (qui comportait une autre erreur, d'ailleurs, sur l'affichage de la population), un bot va passer mettre à jour les articles. Si on pouvait éviter de rejouer ça trop souvent, ce serait mieux. --Lgd (d) 14 janvier 2012 à 16:07 (CET)

Réponse du comte Ɲemoi – Ça n’en reste pas moins qu’une infoboîte v3 intrinsèquement non accessible comportant un hack pseudo-html et un hack incompréhensible par une majorité de personnes (et qui donc sera très certainement corrigé d’une autre manière — peut-être accessible — si quelqu’un édite le modèle). Enfin, elle a gagné en propreté du code, c’est certain ; plus que quelques milliers comme ça… Ce 14 janvier 2012 à 16:27 (CET).

Si tu veux poursuivre dans cette voie avec moi, je veux bien, au contraire : cela sera peut-être utile pour améliorer ce ou ces modèles. Mais dans ce cas, merci de détailler précisément ici le ou les critères WCAG2 non respectés, l'impact, les solutions potentielles, leur faisabilité, ainsi que les éventuelles contraintes tierces. Si tu souhaites discuter sérieusement et utilement d'accessibilité, il faut le faire rigoureusement. --Lgd (d) 14 janvier 2012 à 16:35 (CET)

Et comme c'est une bonne occasion de réfléchir à ce souci, voici mon analyse :

• le problème que tu sembles soulever (plus haut) est celui de la carte, mais encore faut-il le préciser : l'utilisation de la couleur sans motif ou hachures dans les différentes zones n'est pas conforme à WCAG (critère 1.4.1) : les zones, bien que délimitées par un contour ce qui est déjà bien, ne sont différenciées que par leur couleur.
• une remarque : l'information dispose cependant d'une alternative partielle dans la page (selon l'état d'avancement de l'article), via l'introduction et la section géographie. Bien que cette information ne soit pas directement présente dans le contexte immédiat de l'image (dans l'infobox), ce n'est pas négligeable.
• la solution pour une accessibilité optimale serait la modification de la carte, pour y utiliser des hachures par exemple en complément de la couleur.
• mais la faisabilité n'est pas des plus évidentes : adopter une convention accessible pour des cartes de ce type est même extrêmement complexe dès qu'on dépasse le stade de la correction d'une ou deux cartes isolées et simples.
• en outre, cela dépend de contraintes tierces : les cartes en question obéissent à des usages/conventions qu'on ne va pas aller modifier d'un claquement de doigt et la question dépasse le seul site fr.wikipedia.org puisqu'elles sont utilisées sur d'autres projets.

Donc, l'amélioration a été poussée au mieux et répond entièrement à l'objectif fixé pour ces refontes V3, qui est essentiellement le problème de la sémantique HTML (structure de tableau, de listes, etc.) et la question des alternatives d'images.

Pour l'histoire du ou des « hacks », par contre, je n'ai pas compris à quoi tu faisais allusion. Là aussi, une explication précise et rigoureuse aiderait. --Lgd (d) 14 janvier 2012 à 16:55 (CET)

Réponse du comte Ɲemoi – Côté code html : une infoboîte qui commence par une carte avec alternative générale et sa légende (qui n’apporte rien) suivies d’une section « Administration » qui reprend la légende en sens inverse (sachant que les infos principales de situation, on les a dès l’intro de l’article…), c’est un coup à donner envie de sauter l’infoboîte en entier. On a vu pire, et offrir un lien pour sauter les sections incriminées est très dangereux à suggérer sur un site collaboratif, mais je trouve pas que la solution actuelle « offre une alternative présentant la même information ».

Mais c’est du pinaillage. Je suis pour ma part beaucoup plus inquiété par la maintenance du code wiki ; le fait de laisser traîner des trucs que (presque) personne ne comprendra comme :

{{Infobox V3/Titre Bloc|class=hidden||text=Légende de la carte}}

ne me semble pas du tout une bonne idée, pour ce que ça risque fortement d’être copié à droite à gauche sans maîtrise, genre sans légende après… Moins grave, mais méritant autant d’attention (note : et c’était valable y compris pour ma version d’octobre), il en va de même pour le code pseudo-html, qui va être copié (erreurs comprises… il en restait même après ton passage ) probablement à divers endroit, avec autant d’adaptations que de risques d’évolution vers un code non accessible ; c’est pourquoi — mais cela se sait — je pense qu’il serait bien mieux de créer le modèle correspondant, afin de garder une certaine maîtrise sur les utilisations, et pouvoir rapidement passer à des trucs mieux foutus dès que l’occasion s’en présenterait (y compris pour une hypothétique équipe « cartes hachurées »), plutôt que d’avoir à courir partout à ce moment-là. Ce 14 janvier 2012 à 21:08 (CET).

On ne parle plus d'« infoboîte v3 intrinsèquement non accessible », donc ?

Sinon :

• Je vois mal le problème de maintenance avec {{Infobox V3/Titre Bloc|class=hidden|text=Légende de la carte}} ?
• « Code pseudo-html » ? Tout à l'heure, c'était « hack pseudo-html » : je suppose que tu parles de la même chose, mais je ne sais toujours pas en quoi ce serait un « hack » ?
• Sinon, un modèle à la place du code wiki HTML de la légende en dur : oui, tout à fait (d'ailleurs, il y a peut-être bien, déjà, un modèle de ce type à utiliser/améliorer il existe, mais devra être amélioré: {{Légende}}). Donc, un modèle de légende, pas un modèle de brique V3. Dans ce cas, n'hésites pas.

--Lgd (d) 14 janvier 2012 à 21:25 (CET)

Oubli: il ne faut surtout pas se mettre à ajouter des liens du type « passer ce contenu ». Ce genre de choses est réservé à des cas très spécifiques de contenus. --Lgd (d) 14 janvier 2012 à 21:31 (CET)

Réponse du comte Ɲemoi – Tant que les yeutants ont plus d’informations que les non-yeutants, « on » parlera d’« infoboîte v3 intrinsèquement non accessible ». Sinon :

• Un hack pseudo-html est un code pseudo-html suffisamment compliqué pour que le wikicontributeur moyen ait toutes les chances de ne pas le comprendre, et donc de le recopier en croyant bien faire mais en faisant n’importe quoi.
• Le problème de maintenance de {{Infobox V3/Titre Bloc|class=hidden|text=Légende de la carte}} est que peu de personnes comprennent de quoi il s’agit, et que c’est autant de chance de le voir maltraité ; avec le modèle : Légende tel qu’il est conçu, il serait préférable à mon avis d’en faire un {{titre de la légende}}.
• Mais plus globablement, il serait bien mieux que l’on n’ait pas à y penser (à cette ligne de titre de légende) ; car « que l’on ait à y penser » signifie que cette ligne va être oubliée, souvent, très souvent… Il y a diverses solutions pour cela, qui reviennent toute à dire « si vous avez besoin de faire une légende de carte, utilisez ça », ce ça en question pouvant être un paramètre particulier « légende de carte » dans le modèle : infobox V3/Image, ou un modèle qui encadre toujours {{Légende}} (qui n’affiche rien lorsqu’en infoboîte, mais qui fabrique une jolie boite-grise en dehors), un modèle supplémentaire d’infobox V3, etc. Ce 16 janvier 2012 à 21:21 (CET).

La notion d'accessibilité totale n'est pas vraiment un objectif opérationnel pertinent. Je t'invite à consulter cette conférence qui t'en dira plus sur le sujet (voir ce qui y est dit sur le niveau AAA vers 6:45). Ici, la question de l'accessibilité de l'information véhiculée par les images de contenu/d'illustration d'une manière générale est particulièrement difficile à résoudre dans Wikipédia, et ne se traitera ni localement ni à brève échéance. Le cas des cartes n'en est qu'une illustration. Faire de cette question un critère impératif pour qualifier les améliorations d'accessibilité serait une erreur aujourd'hui.

Pour un modèle générique {{Légende de carte}} : oui, mais si on parvient à gérer la présence / absence du texte masqué « Légende ... » selon qu'on est dans une infobox ou non (entre autres problèmes à résoudre). --Lgd (d) 17 janvier 2012 à 08:25 (CET)

Réponse du comte Ɲemoi – Si la notion d’accessibilité « totale » n’était pas l’objectif (ce que je conçois tout à fait, au demeurant ; et je n’ai pas besoin de voir deux guignols-malgré-eux sur scène pour cela ), pourquoi ton obstruction quant au module : Carte des Infobox v3 ? c’est le même niveau d’accessibilité que celui dont on est en train de parler : celui d’avoir une carte qu’une personne non-zeutante ne peut comprendre directement, avec l’espoir que ce sera explicité ailleurs…

Concernant le masquage de {{Légende de carte}}, c’est un problème à régler en CSS. La partie difficile me semble de réussir à faire des classes génériques, qui puissent être utilisées pour d’autres cas que celui-ci en particulier. Ma logique de code voudrait :

• que les infoboîtes portent la classe boite-grise ;
• que la classe boite-grise annule son effet lorsqu’imbriquée (permettant de gérer le modèle : Portail en pur CSS) ;
• que la légende forme une « boîte », portant la classe boite-grise, pouvant être placée dedans ou dehors des infoboîtes ;
• et qu’il y ait une classe particulière pour gérer les textes qui sont les « titres de boite-grise lorsque la boîte est indépendante », masqués à l’affichage lorsque la boîte grise est imbriquée.

Je te fais les classes approximatives si tu n’as pas compris l’idée. Ce 18 janvier 2012 à 19:09 (CET).

Le guignol va commencer par attendre des excuses. En fait non, je vais plus simplement passer à autre chose que de tenter de faire quoi que ce soit avec toi. Définitivement. --Lgd (d) 18 janvier 2012 à 19:15 (CET)

Modèles de légende améliorés ?

Suite à la suggestion de Nemoi, pour un essai de modèles de légende améliorés (mise en liste LI), voir Utilisateur:Lgd/Légendes. C'est à tester, mais ça semble jouable (laisser à mediawiki le soin de générer automatiquement le UL n'est pas très rassurant a priori, mais c'est ce qu'il fait de toute façon avec la syntaxe wiki des listes). Avis bienvenus. --Lgd (d) 15 janvier 2012 à 12:20 (CET)

Finalement, j'ai tenté le coup. --Lgd (d) 15 janvier 2012 à 20:06 (CET)

Réponse du comte Ɲemoi – Il me semble que mettre un retour à la ligne après le </li> limiterait l’obligation d’entourer de <div></div>, non ? Ce 16 janvier 2012 à 21:21 (CET).

Apparement non, au moins pas dans les cas que j'ai rencontrés (tester Utilisateur:Lgd/Légende dans Concessions étrangères de Tientsin et Championnat de RDA de football 1990-1991 par exemple). --Lgd (d) 17 janvier 2012 à 08:08 (CET)

Attributs de mise en forme HTML v. styles inline

Bonjour,
La prochaine version de mediawiki (1.19) devrait, selon ce qui est prévu aujourd'hui, modifier l'utilisation des attributs de mise en forme HTML.

Exemple-type : <div align=right> dans la source wiki :

• donne aujourd'hui <div align=right> dans le HTML final.
• donnerait avec mediawiki 1.19 <div style="text-align: right"> dans le HTML final.

C'est une excellente chose, mais qui est susceptible d'avoir un effet de bord dans quelques cas. Le passage des attributs de mise en forme aux styles inline modifie en effet la priorité du paramètre de mise en forme :

• l'attribut align=right est écrasé par les styles de common.css appliqués via des classes (ou id).
• le style="text-align: right;" écrase les styles de common.css appliqués via des classes (ou id).

Illustration:

<div align=right class="center">
Code actuel : la classe center écrase le align.

<div style="text-align:right" class="center">
Code prévu dans mediawiki 1.19 :
le style text-align:right écrase la classe center.

On pourrait donner un exemple similaire pour les articles où figure un tableau avec la classe wikitable ou sortable et des bgcolor.

Autrement-dit, des attributs de mise en forme HTML présents par erreur dans des modèles où ils n'ont actuellement aucun effet pourront parfois, une fois transformés en styles inline, modifier le rendu du code dès lors qu'une classe est présente.

Bonne incitation à se mettre dès aujourd'hui à la chasse à ces attributs au moins dans les modèles, mais aussi dans les tableaux présents directement dans les articles, pour :

• les remplacer, s'ils sont nécessaires, par un style inline
• les supprimer s'il s'agit de la situation décrite ci-dessus.

Ce qui serait encore mieux, ce serait de nettoyer enfin et pour de vrai les pages d'Aide syntaxique de toute mention de ces attributs...

--Lgd (d) 9 janvier 2012 à 22:40 (CET)

Sinon, bonne nouvelle : la réparation des liens d'accès directs « Aller à : Navigation, recherche » est enfin prévue (ces liens de navigation clavier fonctionnent tant bien que mal sur fr.wp après que les ai un peu réparés, mais c'est loin d'être optimal, et ce n'est pas du tout le cas ailleurs ) --Lgd (d) 9 janvier 2012 à 22:49 (CET)

Pour aider, il faudra un petit tableau des codes à remplacer et de ceux à utiliser dans ces corrections. Je me le note, mais si ça dit à quelqu'un de le faire ?

Le Projet:Correction syntaxique est aussi à sensibiliser là-dessus, c'est en plein dans son champ d'action. --Lgd (d) 10 janvier 2012 à 08:35 (CET)

<soliloque /> La fonctionnalité n'est apparemment pas activée sur le wiki de test 1.19. Elle ne le sera sans doute pas sur fr.wikipédia avant quelques temps, une fois faite la mise à jour (j'ignore où en est exactement son développement, mais l'idée est bien d'anticiper la chose qui va tout à fait dans le sens des règles d'accessibilité WCAG ). --Lgd (d) 15 janvier 2012 à 11:56 (CET)

Éventuelle PDD sur le rendu des appels de notes & références, avis bienvenus

Il s'agit davantage d'ergonomie que d'accessibilité à proprement parler. Mais des avis seraient bienvenus pour permette d'avancer la suggestion de formulation actuelle qui envisage le retour à l'affichage des crochets ou l'adoption de parenthèses dans ces liens.

La discussion (un peu confuse parfois) porte pour le moment sur la question de s'en tenir dans un premier temps à cette seule proposition, ou bien d'inclure déjà dans cette PDD d'éventuelles exceptions permettant au contributeur de choisir au cas par cas s'il va utiliser des parenthèses, des crochets ou rien.

Cordialement, --Lgd (d) 14 janvier 2012 à 12:33 (CET)

C'est pas plutôt à voir avec les mathématiciens et autres utilisateurs de codes spécialisés ? Car pour les autres wikipédiens cela se résumerait à un choix purement esthétique, pas forcément judicieux. Faut-il vraiment une PDD générale pour une si petite chose ? --Amicalement, Salix ( converser) 15 janvier 2012 à 12:50 (CET)

Disons que l'usage actuel (ne pas utiliser de crochets) est ancien et bien enraciné sur fr.wp et que la question touche à des susceptibilités typographiques, chose toujours très délicate ici (d'où le passage en PDD). Une si petite chose, mais de grandes passions . --Lgd (d) 15 janvier 2012 à 13:01 (CET)

Raison de plus, dans ce cas, pour accumuler un maximum d'arguments en faveur des crochets avec les projets les plus concernés. En cours de vote, ce ne sont pas deux ou trois spécialistes qui pourront faire pencher la balance si les arguments esthétiques ou littéraires pèsent déjà si lourd au regard de la majorité. --Amicalement, Salix ( converser) 15 janvier 2012 à 16:02 (CET)

Longueur des alternatives textuelles

Bonjour,
J'ai finalement formalisé une bonne pratique sur la longueur des alternatives textuelles d'images (suite à l'évolution de certains documents normatifs sur le sujet). Relectures bienvenues. Cordialement, --Lgd (d) 19 janvier 2012 à 10:55 (CET)

Usage du « : » pour indenter

Bonjour, dans votre « Petite liste de choses à faire » je découvre : Corriger les mauvais usages de la syntaxe « : » pour indenter un contenu. Est-ce à dire que ce « : » est réservé aux listes de définitions ? Dans les articles de maths il y a plein de « : » qui servent juste à mettre en retrait, sans la centrer, une ligne de formule au milieu d'un texte. Ces « : » sont-ils fautifs et si oui, par quoi les remplacer ? Anne Bauval (d) 20 janvier 2012 à 20:18 (CET)

La syntaxe « : » devrait en effet être réservée aux seules listes de définition (ou description).

On peut créer facilement un modèle du type Modèle:Tab remplaçant l'usage de « : », mais avant d'envisager cela, une question à tout hasard : l'indentation des formules est-elle systématique (hors cas de centrage) ? Dans ce cas, on pourrait l'automatiser dans les navigateurs récents, sans que les contributeurs n'aient plus aucune syntaxe à saisir : tout paragraphe (ligne en wiki) ne comportant qu'une formule (non centrée) serait automatiquement mise en retrait. Par exemple, la saisie suivante indenterait :

Sa [[bijection|réciproque]] est 

<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

Les saisies suivantes n'indenteraient pas :

• rendu sans retour à la ligne :

Sa [[bijection|réciproque]] est 
<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

• rendu avec retour à la ligne:

Sa [[bijection|réciproque]] est<br>
<math>f^{-1}(x) = - \frac{dx - b}{cx - a}</math>

Le nom provient de ce que si on rajoute à...

Cordialement, --Lgd (d) 20 janvier 2012 à 21:13 (CET)

Merci, c'était pour m'assurer que je ne faisais pas de bêtise, avant de publier ce genre de rectif dans Transformée en Z. Il y reste encore un vilain truc dans cette section (dans la dernière des 4 boîtes déroulantes) :

:----0-1-1-2-3-5-8 etc

Quand on vire le « : », ça donne une horreur.

Je ne sais pas répondre à ta question (je constate seulement que c'est systématique dans les vieux articles de maths sur WP.fr), je vais la poser au Thé.

Anne Bauval (d) 20 janvier 2012 à 23:20 (CET)

Depuis des années que j'en parle… La proposition de Lgd me semble parfaitement sensée et réalisable. Le problème est toujours le même : il faut intervenir sur Mediawiki et, pour cela, réussir à faire bouger les développeurs… En tout cas si besoin j'ai une ou deux expressions régulières qui feraient le boulot et dont je me sers déjà depuis des années. — Florian, le 25 janvier 2012 à 19:27 (CET)

C'est a priori réalisable plus simplement avec juste l'ajout d'une règle CSS dans Common.css, pour les navigateurs modernes (sous réserve que mes suppositions ci-dessus soient exactes quant aux usages de syntaxe envisageables dans ces articles). Cordialement, --Lgd (d) 25 janvier 2012 à 19:36 (CET)

Il ne faut pas oublier le problème des formules qui sont écrites sans <math>, qui ne seraient pas détectées et qu’il faudrait réécrire.
Ltrl G, le 25 janvier 2012 à 20:19 (CET)

Dans ce cas, si vous souhaitez corriger ce problème :

• solution 1 : créer un modèle d'indentation et modifier tous les articles concernés, qu'ils utilisent ou non <math> ;
• solution 2 : mettre en place la solution CSS d'indentation automatique de <math>, créer également un modèle balisant les formules qui n'utilisent pas <math> et modifier les seuls articles concernés par ce cas ;
• solution 3 : ne plus indenter.

Il n'y aura pas de solution « magique » si les contenus ne sont pas balisés d'une manière systématique (qu'il s'agisse d'une solution locale ou mediawiki). Cordialement, --Lgd (d) 25 janvier 2012 à 20:36 (CET)

Monobook etc.

Bonjour, c'est volontaire que Aide:Monobook soit incompréhensible au commun des mortels ? Je voudrais indiquer un bouton bien pratique mais j'ai la sensation qu'il manque un bout de code. Pour ajouter un bouton à la toolbar, j'ai trafiqué sur ma page Commons.js les codes qu'on m'avait donnés, bêtement copiés/collés, et qui fonctionne très bien mais la façon de les organiser n'est indiquée en clair nulle part. Comment lire et utiliser les pages MediaWiki:Common.css et MediaWiki:Common.js ? Et puis entre vector.js, monobook.js et commons.js que faut-il préférer ? et pourquoi MediaWiki:Monobook.js est déplacé (sur commons.js) mais pas MediaWiki:Monobook.css ? Un courageux pour créer une page d'aide et peut-être actualiser cette page sur un monobook un peu dépassé ? --Amicalement, Salix ( converser) 26 janvier 2012 à 12:54 (CET)

Ma todolist est un peu pleine pour le moment, hélas. Allez... Un autre courageux ? Cordialement, --Lgd (d) 28 janvier 2012 à 11:48 (CET)

Ah, si on avait une page d'aide .js et .css pour les nuls... (soupir) --Amicalement, Salix ( converser) 28 janvier 2012 à 19:16 (CET)

Texte et traduction en vis-à-vis

Bonjour, une question bête : quelle est la façon la plus accessible de mettre un texte et sa traduction en vis-à-vis ? Est-ce qu'un tableau minimal du style

{|
| Texte
| Traduction
|}

est approprié ? – Swa cwæð Ælfgar (d) 26 janvier 2012 à 20:23 (CET)

Le tableau convient. Il peut être comme ci-dessus (simple tableau de mise en forme inoffensif dans ce cas), soit, éventuellement, sous la forme d'un tableau de données explicite :

{|
|+ Versions originale et française de la charte klingon
|- 
! scope=col | Texte original en klingon
! scope=col | Traduction
|-
| Texte
| Traduction
|}

Il faut en revanche éviter les mélanges entre les deux types de tableaux (retirer le titre ou remplacer les ! scope=col par de simples | dans le tableau de données). --Lgd (d) 27 janvier 2012 à 14:13 (CET)

Merci à Od1n pour la correction de mon énorme bourde de syntaxe dans l'exemple ci-dessus . --Lgd (d) 28 janvier 2012 à 11:45 (CET)

Confusions, homonymies et autres

Bonsoir. Je propose de passer les petite icônes des modèles du type {{homonymie}}, {{confusion}}, {{homophonie}} dans la feuille de style CSS, comme cela a été fait avec les bandeaux de section. Pour cela, je pense qu’il faudrait :

• Ajouter dans la feuille de style css commune les classes .homonymie, .homophonie, .confusion,​ parmi les

.indentation,    /* pas d’image correspondante */
.loupe,          /* loupe, voir le [[modèle : Article détaillé]] */
.general,        /* flèche pour le [[modèle : Article principal]] */
.accessibilite,  /* symbole handicap, pour le [[modèle : Encart]] */
.incomplet,      /* cône de chantier pour le [[modèle : …]] */
.sources,        /* livre ouvert du [[modèle : Section à sourcer]] */
.important,      /* triangle rouge : mise en garde   */
.en-travaux,     /* triangle jaune : en construction */
.wikispecies, .metawiki, .wikiversity, .wikipedia, .wikibooks, .wikinews, .wikiquote, .wikisource, .commons, .wikimedia, .wiktionary{}​ de la partie bandeaux ;

• Rajouter le code .hr {border-bottom: 1px solid gray;}​ pour gérer les bordures optionnelles en bas de ces modèles
• Rajouter les classes

.homonymie     {
  background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/3/3e/Disambig_colour.svg/17px-Disambig_colour.svg.png");
  background-position:1px 0;}

.confusion     {
  background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/6f/Confusion_colour.svg/17px-Confusion_colour.svg.png");
  background-position:1px 0;}

.homophonie    {
  background-image:url("//upload.wikimedia.org/wikipedia/commons/thumb/6/63/Homoph_colour.svg/17px-Homoph_colour.svg.png");
  background-position:1px 0;}
​

• Et enfin modifier tous les modèles affichant une icône d’homonymie en conséquent, à savoir selon le schéma <div class="(homonymie|confusion|homophonie) {{#if: {{{nohr}}}||hr}}">Texte</div>​. On en profiterait pour supprimer les {{{1}}}​ qui ne servent à rien et sont souvent dupliqués sur la même page.

Qu’en pensez-vous ?

Cordialement --Pic-Sou 29 janvier 2012 à 22:31 (CET)

Ces icônes ne posent actuellement pas de problème d'accessibilité : ce sont des liens vers l'aide, avec l'alternative textuelle appropriée. Ce lien est présent également sous forme textuelle dans une partie des usages d'{{Homonymie}}, mais pas dans tous et pas dans {{Voir homophones}} ni {{Confusion}}.

La modification proposée reviendrait donc à supprimer le lien d'aide. Bien qu'il ne soit pas présent sous une forme très explicite (beaucoup d'utilisateurs ignorent sans doute sa présence), sa suppression ne va pas de soi. Donc, à mon avis, ce n'est pas à décider ici.

Remarque : cela fait très longtemps que je souhaiterais voir systématiquement utilisée une icône d'aide unique et explicite dans tous les cas où figure un renvoi à une page d'aide, que ce soit depuis un modèle, depuis l'interface liée aux messages systèmes, etc. C'est encore un de ces chantiers qui attend d'avoir le courage de s'y attaquer . Cordialement, --Lgd (d) 31 janvier 2012 à 09:29 (CET)

Pourtant, c’est plus un truc décoratif qui ne devrait pas être visible dans un navigateur texte ou audible lors d’une synthèse vocale qu’une image nécessaire à la compréhension du contenu. Et, oui, j’ignorais que ce lien existait. Peut-être vaudrait-il mieux que le lien vers la page Aide:Homonymie soit sur le mot « homonyme » que sur l’icône ? Cordialement --Pic-Sou 31 janvier 2012 à 10:20 (CET)

Il me semble que le terme « homonyme » (ou équivalent) n'est pas présent dans toutes les déclinaisons de ces modèles et qu'il n'y a donc pas toujours de quoi fournir un lien textuel.

Sinon, pour préciser un autre point plus général : quand une image est purement décorative (pas de lien, pas d'info etc.), elle peut être gérée soit en image HTML avec un alt vide, soit en image CSS avec un résultat identique du point de vue accessibilité. C'est pour d'autres raisons (performances, industrialisation du code, etc.) qu'on la passe souvent en image CSS. Mais ce n'est pas toujours nécessaire ni profitable. C'est un peu compliqué et à voir à chaque fois selon le contexte. Ici, si ce n'était pas des images-liens, ce serait en effet profitable. Cordialement, --Lgd (d) 31 janvier 2012 à 12:29 (CET)

OK, merci pour les informations ! Cordialement --Pic-Sou 31 janvier 2012 à 19:35 (CET)

Réponse du comte Ɲemoi – J’avais regardé à faire ça, mais arrêté, n’ayant pas trouvé de solution propre pour gérer tous les problèmes. Le lien d’aide cité par Lgd est le principal obstacle ; il faut préciser que certains « liens d’aide » n’aident pas du tout, comme celui sur le modèle : Autre qui envoie vers l’aide : Redirection… Un second est la complexification du code html : pour quel intérêt ? quelle logique sous-jacente ? je n’aime pas trop ça. Bref, c’est l’un des trucs qui traîne depuis assez longtemps dans mes tests, mais je n’ai pas de solution propre qui évite d’ouvrir plein de discussions partout. Ce 1 février 2012 à 01:28 (CET).

Refonte des palettes et boîtes déroulantes, faire une première phase de tests rapides

Bonjour,
Les modèles de palettes de navigation et de boîtes déroulantes posent depuis longtemps des problèmes de sémantique, d'accessibilité, de scripts redondants etc. Je me suis un peu attaqué au souci en tirant parti de ce qui était à présent possible via la dernière mise à jour de mediawiki (1.18).

Je n'en suis pas encore au stade où il s'agit d'une proposition de refonte finalisée : différents modèles de variantes ne sont pas couverts, le résultat des palettes n'est pas encore géré dans les vieilles versions d'Internet Explorer (6 et 7), les boîtes déroulantes sont pour le moment en version minimale, les options de mises en couleur de tout cela sont réduites au minimum et il reste d'autres bricoles à traiter.

Mais des essais en prévisualisation dans diverses palettes de navigation seraient nécessaires à ce premier stade, surtout si vous avez en tête des palettes de navigation un peu spéciales (je laisse de côté le test des autres boîtes déroulantes pour le moment).

Si vous voulez bien vous prêter au jeu (en sachant que vous allez certainement rencontrer de la casse, le but est justement de la détecter), voici les indications nécessaires pour tester :

1. ajouter au tout début du common.css personnel la ligne:

   @import "//fr.wikipedia.org/w/index.php?title=Utilisateur:Lgd/Palettes/palettes_V2.css&action=raw&ctype=text/css";
   

2. ajouter au tout début du common.js personnel la ligne:

   importScript('Utilisateur:Lgd/Palettes/palettes V2.js');
   

3. actualiser le cache de votre navigateur ;
4. Pour tester une palette de navigation en prévisualisation uniquement, aller sur la page du modèle de palette concerné (par exemple Modèle:Palette GP Formule 1 2011) et remplacer la ligne :

   {{Méta palette de navigation
   

   par

   {{Utilisateur:Lgd/Palettes/Méta palette de navigation V2
   

   puis cliquer sur « prévisualiser ».

Le rendu que vous obtiendrez n'est pas le rendu final après la mise à jour définitive des palettes, mais un rendu de transition entre une étape de mise à jour automatique et la finalisation manuelle dans chaque palette (les explication sont dans Utilisateur:Lgd/Palettes/Méta palette de navigation V2 pour les curieux). Le besoin est de vérifier que ce rendu transitoire n'est pas cassé de manière problématique, même s'il peut comporter des imperfections (par exemple, perte d'un alignement, etc.)

Dans vos retours, pensez à bien indiquer quel est le modèle de palette et si besoin votre navigateur, sa version et votre système d'exploitation (ne faites pas de retour pour Internet Explorer 6 et 7, ce n'est pas prêt pour ceux-ci).

J'espère avoir expliqué ça de façon à peu près humaine, mais sinon, passez simplement à autre chose .

Cordialement, --Lgd (d) 31 janvier 2012 à 12:23 (CET)

bonjour !

Voila mon retour : Chrome 16.0.912.77 m sous Vista et sur la palette Modèle:Palette GP Formule 1 2011. Le v pour voir la palette est centré sur le trait d'encadrement de la palette sinon tout le reste me semble bien rendu et bien passé. (je sais pas si je t'aide là ...) --TaraO (d) 6 février 2012 à 16:47 (CET)

Même chose sur Modèle:Palette Penguins de Pittsburgh mais avec en plus, la perte de l'alignement du texte à gauche. --TaraO (d) 6 février 2012 à 16:50 (CET)

Avec chrome sous Ouindose XP (pourquoi changer un truc qui marche?) je n'ai rien noté d'étrange en testant plein de palettes au hasard. Sauf pas pu voir ce que ça donne pour Modèle:Palette Patrimoine mondial en France et trouvé un record (?) de longueur : Modèle:Palette Cathédrales en France. --Amicalement, Salix ( converser) 6 février 2012 à 22:11 (CET)

Firefox sous windows 7 : Pas problème particulier à part celui de la perte d'alignement à gauche souligné par TaraO (Modèle:Palette Blackhawks de Chicago par exemple). Pour le v centré sur le trait d'encadrement, il semble que ce soit le cas pour tous au vu de Utilisateur:Lgd/Palettes/Méta palette de navigation V2. --'toff ^[discut.] 7 février 2012 à 04:41 (CET)

Edit : à priori, l'alignement à gauche sera possible avec class=left. Question : faudra-t-il à chaque liste rajouter le sous-modèle liste pour l'alignement ? --'toff ^[discut.] 7 février 2012 à 04:49 (CET)

Merci pour vos retours. Le souci d'alignement de la {{Tnavbar}} (que je n'ai pas dans mon rendu) est sans doute dû à une petite rencontre inattendue entre les styles de la palette et mes autres styles personnels, ce qui fait que j'aurai pu longtemps passer à côté . Je vais arranger ça.

Pour Modèle:Palette Patrimoine mondial en France : c'est normal, c'est une de ces rares palettes à utiliser un modèle intermédiaire, Modèle:Méta palette Patrimoine mondial. Ce qui me fait penser qu'il faudra les recenser...

@'toff : Cela va dépendre de ce qui se décidera quant à la conservation ou non des paramètres de mise en forme actuels des palettes (stylegroupe, styleliste, etc). Dans tous les cas, le passage systématique au modèle de liste dans chaque palette constituerait une seconde phase (longue et manuelle) d'amélioration. Vous pouvez d'ailleurs déjà aider en utilisant systématiquement l'actuel {{Liste éléments}} dans les palettes. Cordialement, --Lgd (d) 7 février 2012 à 05:33 (CET)

Si je vois bien la facilité de passer de {{Liste éléments}} à un autre sous-modèle, je ne suis pas persuadé de l'intérêt d'un tel sous-modèle quand il est si facile et moins complexe de coder en dur ? --'toff ^[discut.] 7 février 2012 à 06:54 (CET)

Si par « coder en dur » tu veux dire les multiples variantes de fausses listes actuelles à base de caractères typos, l'intérêt est justement de les remplacer par de véritables listes structurelles . Sinon, c'est que j'ai mal compris la question ? Cordialement, --Lgd (d) 7 février 2012 à 06:59 (CET)

Au temps pour moi, je viens effectivement de me rendre compte de ma profonde bêtise... T'es pas à l'aube de laisser l'atelier à des blaireaux comme moi Yapukafokon ! J'ai bon ? --'toff ^[discut.] 7 février 2012 à 07:20 (CET)

PS : Sur ce coup là, t'as le droit de taper même sur la tête ! --'toff ^[discut.] 7 février 2012 à 07:20 (CET)

Rien de spécial pour moi (pas de comportement non désiré), mais je pense qu’il faudrait par défaut que les textes soient alignés à gauche, et que les différents sous-groupes devraient être mieux distingués (en gros, sur Utilisateur:Pic-Sou/Brouillon 3, qu’il y ait une séparation visible entre les première, deuxième et troisième ligne). Cordialement --Pic-Sou 7 février 2012 à 09:19 (CET)

C'est le cas une fois la seconde phase effectuée, c'est à dire une fois le modèle de liste utilisé. Il est normal que ce ne soit pas visible dans ces tests, donc. --Lgd (d) 7 février 2012 à 09:33 (CET)

Titres dans des tableaux

Que penser de ce type de tableaux ?

Ltrl G, le 31 janvier 2012 à 15:59 (CET)

C'est un cas typique de tableau complexe où des en-têtes de colonne ne s'appliquent qu'à certaines lignes, ingérable avec scope. A éclater en autant de tableaux simples successifs qu'il y a de blocs (les en-têtes actuels en colspan devenant les titres de tableaux). L'autre solution disponible est AMHA à éviter à tout prix dans les articles vu la complexité et la fragilité de sa syntaxe. Cordialement, --Lgd (d) 31 janvier 2012 à 23:13 (CET)

Un truc comme ça ?

=== Information ===
{| class="wikitable alternance"
|+'''1xx'''
|-
! scope="col" | Code
! scope="col" | Message
! scope="col" | Signification
|-
| 100 || {{lang|en|''Continue''}} || Attente de la suite de la requête
|-
| 101 || {{lang|en|''Switching Protocols''}} || Acceptation du changement de protocole
|-
| 102 || {{lang|en|''Processing''}} || [[WebDAV]] : Traitement en cours (évite que le client dépasse le temps d’attente limite).
|-
| 118 || {{lang|en|''Connection timed out''}} || Délai imparti à l'opération dépassé
|}

=== Succès ===
{| class="wikitable alternance"
|+'''2xx'''
|-
! scope="col" | Code
! scope="col" | Message
! scope="col" | Signification
|-
| 200 || ''OK'' || Requête traitée avec succès
|-
| 201 || {{lang|en|''Created''}} || Requête traitée avec succès avec création d’un document
|-
| 202 || {{lang|en|''Accepted''}} || Requête traitée mais sans garantie de résultat
|-
| 203 || {{lang|en|''Non-Authoritative Information''}} || Information retournée mais générée par une source non certifiée
|}

ou, pour les titres, peut-être inverser : === 2xx === et |+'''Succès''' ? --'toff ^[discut.] 1 février 2012 à 05:20 (CET)

Fait selon la solution de 'toff ?

@'toff : sur un wikitable, il est inutile de mettre les caption en gras.

Ltrl G, le 17 février 2012 à 23:46 (CET)

C'est (à priori) vrai maintenant. Mais il y a quelques temps, ce n'était pas le cas sous tous les navigateurs. Une vieille habitude --'toff ^[discut.] 18 février 2012 à 00:32 (CET)

Tableau construit avec le modèle légende

Bonjour,
J'ai fait le tableau suivant. Un utilisateur l'a modifié par ce tableau construit avec le modèle {{légende}}. J'avoue que je trouve que le 2^e tableau à l'avantage de ne pas prendre une espace beaucoup trop grand dans l'article, mais je me demandais si c'était correct au niveau accessibilité. Merci! — Riba ^(discuter) 6 février 2012 à 16:39 (CET)

C'est pratiquement indifférent (le second étant une liste en un seul bloc et non un tableau, malgré ce que suggère le rendu). Cordialement, --Lgd (d) 6 février 2012 à 16:46 (CET)

Images dans un tableau qui apportent du sens

Je tombe aujourd'hui sur un article de sport qui utilise dans un tableau un modèle pour mettre une image de croix. La présence ou non de ce "truc" apporte une information utile, mais est-ce que en l'état, ces tableaux sont "accessibles" ?
Comment les améliorer si besoin ?
(pas plus de 50 en main pour l'instant)
Merci de vos avis, --MGuf (d) 7 février 2012 à 21:18 (CET)

Maintenant, ça devrait aller mieux. --Pic-Sou 7 février 2012 à 21:25 (CET)

Si jeune mabuse, ta modif ne change rien, car il y avait déjà une syntaxe "non" dans le modèle, en "légende".

Ma question va plus loin : un lecteur normal peut (peut-être) le sens d'avoir cette croix dans une case ou pas, mais qu'en est-il dans la vraie accessibilité, puis que le sens de la croix n'est pas "non", mais "cette épreuve n'existait pas à cette époque". On va améliorer, notamment grâce à une légende, mais je souhaite un avis autorisé et argumenté de spécialistes. Merci. --MGuf (d) 7 février 2012 à 21:36 (CET)

@Pic-sou : il y a en fait deux syntaxes possibles pour l'alternative d'image : explicite sous la forme [[Fichier:Exemple.jpg|alt=texte de l'alternative]] et implicite sous la forme [[Fichier:Exemple.jpg|texte de l'alternative]]. Les deux produisent le même attribut alt de l'image. La seconde produit en plus le tooltip (bulle d'aide) au survol du lien. --Lgd (d) 8 février 2012 à 05:28 (CET)

Une légende sera en effet nécessaire d'une manière générale. Si elle a plusieurs entrées, le modèle {{Légende}} peut éventuellement servir. Par ailleurs, j'ai corrigé le modèle {{Non g}} pour qu'il permettre de saisir l'alternative de son choix. Il faudrait donc, dans ces articles, corriger sous la forme {{Non g||alt=épreuve inexistante à cette date}} (attention au double pipe). --Lgd (d) 8 février 2012 à 05:25 (CET)

Couleurs d'un portail.

Bonjour,
Pouvez-vous me dire si les couleurs du portail:Calvados, correspondent au normes d'accessibilité ?
Merci,--AM 23 (d) 10 février 2012 à 19:52 (CET)

Colour Contrast Analyzer (utilitaire gratuit, téléchargeable, sans installation) donne :

Pour le texte noir sur le fond : ok

Pour le texte bleu (liens) sur le fond : pas bon (mais je tempère : je suis deutéranope et je n'ai pas de problème avec ce portail)

Pour le texte noir sur fond bleu dans les titres : pas bon (mais comme au-dessus, c'est pas rédhibitoire àmha)

Pour le texte bleu (liens et bouton [modifier]) sur fond bleu : pas bon (et àmha, améliorable : je pense qu'il faudrait éclaircir le bleu)

Ce n'est qu'un avis perso et celui d'un utilitaire. Voir avec des spécialistes de la question. --'toff ^[discut.] 11 février 2012 à 00:18 (CET)

Bonjour AM 23. A vue de nez les bandeaux de titre ne sont pas top, surtout quand il y a un lien bleu (ferme à demi les yeux et vois ce que ça donne ou recule de ton écran de quelques mètres). Quoi qu'il en soit, un Portail:Calvados ça s'arrose ! --Amicalement, Salix ( converser) 11 février 2012 à 01:04 (CET)

Dans un autre domaine, les listes non structurées dont les élément sont séparés par des ~ (qui seront amenées à prendre de l’ampleur, j’imagine), c’est pas top. Je ne parle pas des couleurs, parce qu’avec mes préférences, je cherche un peu les ennuis de lisibilité… Ltrl G, le 17 février 2012 à 22:57 (CET)

Pour ce qui est des couleurs, le fond bleu #2288CC      pose un gros problème de contraste avec le bleu des liens. Les autres combinaisons de couleur ne posent pas de problème de contraste notable.

Pour les listes, vous devriez en effet regarder du côté du modèle:Liste éléments : il ne produit pas encore actuellement le code qui conviendrait, mais son utilisation permettra de régler automatiquement le problème lors de sa prochaine mise à jour. Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Modèle de liste en ligne

Plutôt que d'utiliser un modèle comme Liste éléments, dont la définition est à la fois limitative (pourquoi à 155 éléments ?) et lourde (combien de tests à chaque emploi ?), peut-on imaginer définir une classe listeligne à l'intérieur de laquelle les listes non ordonnées seraient affichées en ligne ? Du point de vue utilisateur, on écrirait en code wiki

{{liste en ligne|
* des choses
* et d'autres}}

Dans le modèle « Liste en ligne », on placerait le contenu dans un <span class="listeligne"> et dans le Commons.css, on définirait en inline les tags .listeligne > ul. Non ? Ambigraphe, le 18 février 2012 à 11:01 (CET)

C'est justement le rôle du modèle {{Liste éléments}}, qui le fait le fera une fois mis à jour de manière plus robuste que ce que ferait le type de modèle que tu proposes (jongler dans un modèle avec un mélange de syntaxe wiki HTML - ul - et de syntaxe wiki wiki - * - pour les listes réveille parfois de vieilles fragilités du parseur). Il ne pose pas par ailleurs de problèmes de performances. Cordialement, --Lgd (d) 18 février 2012 à 11:42 (CET)

Ambigraphe n’a pas proposé un tel mélange, il me semble : il propose d’englober la liste dans un <span> dans un <div> avec une classe particulière qui permettrait de rendre inline la ou les listes qui se trouvent à l’intérieur en appliquant via common.css cette propriété sur les <ul> du code HTML. Ltrl G, le 18 février 2012 à 12:11 (CET)

Utiliser un conteneur de type <div class="inline_list">...</div> autour de la liste cassera l'imbrication de listes (le problème se pose déjà avec les listes des références). C'est pourquoi la classe doit être appliquée sous forme d'un <ul class="inline_list">...</ul> dans le modèle. Cordialement, --Lgd (d) 18 février 2012 à 12:18 (CET)

OK, j'ai vu le problème. L'interprétation de l'astérisque en début de ligne est plus compliquée que je ne me l'imaginais. Merci pour les réponses, je reviendrai quand j'aurais de meilleures idées. Ambigraphe, le 18 février 2012 à 14:03 (CET)

Codes CSS pour les mathématiques

J'ai deux questions à peu près indépendantes mais qui concernent toutes deux le code CSS et le projet Mathématiques.

1. J'ai créé pour certains portails de mathématiques une sous-page /Style (telle que « Portail:Mathématiques/Style ») qui définit notamment les couleurs à employer pour le portail. Est-ce satisfaisant d'un point de vue accessibilité ?
2. Certains contributeurs souhaitent voir s'afficher les théorèmes, propriétés et définitions dans les articles dans des cadres colorés. Il n'y a pas de consensus à ce sujet, voire une opposition du gros des troupes, mais je pense qu'on pourrait autoriser ceux que ça intéresse de redéfinir des attributs de style dans leur propre css. Pour cela, il faudrait peut-être (je suis néophyte sur le sujet) que ces classes soient définies globalement. Si c'est bien le cas, comment faire ?

Merci d'avance, Ambigraphe, le 17 février 2012 à 14:40 (CET)

Pour le deuxième point, cela pourrait rejoindre àmha l’idée soulevée un peu plus haut d’un modèle encadrant les formules pour les indenter. Ltrl G, le 17 février 2012 à 23:20 (CET)

Bonjour,

1. Cela n'a pas d'impact en tant que tel du point de vue accessibilité. Après, tout va dépendre des styles en questions, le risque principal se situant du côté d'éventuels choix de couleurs d'arrière-plan. Pour le moment, pas de souci, donc.
2. Pour que des modèles soient plus aisément personnalisables, il faut en effet les doter d'une classe, mais sans que cela nécessite forcément de définir leur détail dans Mediawiki:Common.css. Par exemple, un modèle du type :

   <div class="foo" style="background: yellow">...</div>
   

   Sera personnalisable via le common.css personnel avec quelque-chose comme

   .foo {background: pink !important;}
   

   Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Merci pour ces réponses.

En ce qui concerne le style du portail, idéalement j'aimerais utiliser une sous-page « Portail:nom_du_portail/Style.css » qui serait appelée automatiquement par le serveur (comme la feuille de style personnalisée) pour chaque portail, ou mettre les classes des cases du tableau (bordure et espacement) dans le commons.css.

Pour les indentations de formules, je pense que le mieux est d'utiliser une syntaxe du genre :

{{bloc|<math>\int_a^b\frac{\mathrm d x}{x} = \ln\left(\frac{a}{b}\right)</math>}}

Ambigraphe, le 18 février 2012 à 09:30 (CET)

Utiliser une sous-page d’un portail pour une feuille de style css n’est pas une bonne idée. Un vandale peux très facilement s’amuser à blanchir artificiellement toute les pages l’utilisant via un petit body { display:none; } ou quelque chose du genre. Il faut donc qu'elle soit au moins semi-protégé. De plus, l’espace Mediawiki: est là pour cela. Tpt (d) 18 février 2012 à 09:57 (CET)

Ah, je n'avais compris le rôle de la sous-page de portail. Indépendamment des questions de vandalisme, cela me semble en effet à éviter car disperser les styles dans divers espaces compliquerait considérablement leur suivi et leur maintenance. D'autre part, c'est à vérifier, mais il ne me semble pas possible d'obtenir l'export au format css d'une page de ce type. Enfin, plus généralement, il n'existe pas actuellement de mécanisme d'inclusion de CSS conditionnelles dans mediawiki (selon la manière de mettre en oeuvre ton idée, la css ne sera pas appelée ou bien elle sera quelle que soit la page comme si les styles étaient dans Common.css, donc sans aucun avantage).

C'est un manque en effet, mais mieux vaut éviter de bricoler : ce serait une évolution de mediawiki à gérer nativement. Cordialement, --Lgd (d) 18 février 2012 à 11:56 (CET)

L'utilisation d'une page « Mediawiki:Projet:Mathématiques.css » au lieu de « Projet:Mathématiques/Style.css » me conviendrait presque aussi bien, à ceci près que faire des essais dans l'espace Mediawiki est moins aisé pour moi que dans l'espace Portail.

Quant au mécanisme d'inclusion conditionnelle de CSS, il est déjà appliqué pour la personnalisation CSS, non ? (Ou bien je n'ai rien compris au film, hypothèse vraisemblable). Ambigraphe, le 18 février 2012 à 14:08 (CET)

Il n'y a aucune inclusion conditionnelle en fonction de l'espace de nom de l'article ou de la page auquel s'appliquerait la css en question (pour les CSS éditables, c'est à dire en dehors de celles du noyau et des extensions). Une CSS personnelle est systématiquement chargée quelque-soit la page consultée, dès lors que l'utilisateur l'a créée.

D'autre part, externaliser les styles d'un portail dans quelque-chose comme Mediawiki:Common.css/Mathématiques.css n'aura qu'un intérêt très limité, surtout si tu n'es pas admin et que tu ne peux pas modifier une page dans cet espace : il faut alors, pour que cette CSS soit prise en compte, recourir à un @import dans Mediawiki:Common.css, ce qui est pénalisant en terme de performances, pour le coup. Je l'ai fait récemment avec MediaWiki:Common.css/taxobox v3.css sur laquelle travaille Hexasoft afin de lui simplifier la mise au point des styles de taxobox V3, mais ce sera un @import temporaire, très probablement (voir ici).

Il est peut-être possible que mediawiki 1.19 change un peu la donne, mais c'est à voir (Je n'ai pas regardé en détail ce qui est annoncé sur ce sujet, ce n'est pas très clair). Cordialement, --Lgd (d) 18 février 2012 à 16:02 (CET)

Merci pour ces précisions. La raison de mon acharnement est la définition du style pour toutes les cellules d'un tableau. Si je pouvais définir ce style dès le haut de table, ça m'irait, mais je n'ai pas trouvé comment faire. Du coup, la solution utilisée actuellement consiste à définir ce style à chaque cellule du tableau, ce qui est un peu laborieux. Pour gérer ce style globalement, j'ai eu recours à la création d'une page de style incluse à chaque cellule. Mais je n'ai pas l'impression que ce soit très propre. Ambigraphe, le 18 février 2012 à 20:12 (CET)

En revanche, je n'ai toujours pas compris pourquoi d'une part on peut « systématiquement [charger une page nom_utilisateur/common.css] dès lors que l'utilisateur l'a créée » et d'autre part on ne peut pas systématiquement charger une page nom_du_portail/style.css dès lors qu'elle est créée. Ambigraphe, le 19 février 2012 à 13:33 (CET)

As-tu une page précise pour le tableau ? (le cas échéant sur ma pdd, on déborde un peu du champ de l'atelier accessibilité).

Pour la seconde question : simplement parce que le mécanisme n'existe pas côté mediaWiki. Il existe un mécanisme qui gère le fait que l'utilisateur soit connecté et la prise en compte de ses css/js personnels, ce qui est très simple. Il n'existe pas actuellement de mécanisme mediaWiki gérant le fait que la page X est affichée quelque-part et qu'il existe un(e) css/js Z qui y serait associé(e) (et encore faudrait-il définir cette association de manière exploitable par le CMS). Ce sont fonctionnellement deux choses très différentes. Cordialement, --Lgd (d) 19 février 2012 à 13:55 (CET)

En raison du caractère formater et automatique de tout ce qui n'est pas "contenu" dans les pages :

Les feuilles de style css sont chargé dans l'ordinateur client par un ligne situé au début du code de la page a afficher.

Sur un site personnel que l'on bidouille soit même page après page, il est donc assez facile de décider qu'une page va comporter des feuilles de style supplémentaires. Mais sur un site comme wikipédia, où la création de page peut se faire à la volée, il est important de garder une interface toujours similaire et, donc, que toute la partie concernant notamment les feuilles de style soit automatisée.

Par conséquent, nous ne pouvons pas décider d'ajouter une feuille de style sur une page en particulier et il n'est pas envisageable non plus de la mettre dans le code automatique, ce qui forcerait sont chargement même quand elle n'est pas nécessaire et donc un diminution conséquente et inutile des capacités. 十月 三日 (^o^) appelez moi Ju (^o^) Livre d'Or 19 février 2012 à 13:51 (CET)

Non, ça ne pose pas de problèmes de cet ordre (l'association de CSS à des pages spécifiques via un CMS est une chose courante, que ce soit sur de petits sites personnels ou sur des sites plus complexes que Wikipédia). En revanche, le besoin n'a pas été identifié sur Wikipédia pour le moment (cela viendra sans doute). --Lgd (d) 19 février 2012 à 13:58 (CET)

Lang dans poem

Bonjour,

Si on veut de l'italique entre des balises <poem>, il faut répéter les deux apostrophes au début de chaque ligne. Faut-il faire de même avec {{lang}} ?

<poem>''{{lang|ang|Ða se eorl ongan for his ofermode}}
''{{lang|ang|alyfan landes to fela laþere ðeode}}.</poem>

Ou bien est-ce qu'il suffit de l'ouvrir au début et de le fermer à la fin ?

<poem>''{{lang|ang|Ða se eorl ongan for his ofermode
''alyfan landes to fela laþere ðeode}}.</poem>

– Swa cwæð Ælfgar (d) 17 février 2012 à 23:00 (CET)

Un petit test avec le gadget accessibilité suffit pour dire que la syntaxe « simple » fonctionne même si le code produit (en prévisualisation) est étonnant [édit] est bien complexe ! cf ci-dessous pour une autre solution plus simple — pour la langue comme pour l’italique. Ltrl G, le 17 février 2012 à 23:07 (CET)

Une solution plus simple (pour le code produit) :

''<poem lang="ang" xml:lang="ang">
Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.
</poem>''

Peut-être un modèle ({{poème étranger|ang|…}} ?) pour le <poem lang="ang" xml:lang="ang"> ?

Ltrl G, le 17 février 2012 à 23:26 (CET)

Juste une précision: il est inutile d'écrire le xml:lang : il est automatiquement produit par mediaWiki. Cordialement, --Lgd (d) 18 février 2012 à 07:36 (CET)

Effectivement, mais comme j’étais parti du code HTML, je ne l’avais pas remarqué… Ltrl G, le 18 février 2012 à 11:39 (CET)

En fait, la syntaxe suivante est largement suffisante (je suis bête de ne pas y avoir pensé alors qu’il me semble l’avoir déja utilisée) :

''{{lang|ang|<poem>
Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.
</poem>}}''

Ltrl G, le 18 février 2012 à 11:50 (CET)

Adopté. Merci ! – Swa cwæð Ælfgar (d) 18 février 2012 à 16:30 (CET)

J’ai essayé de créer {{poem}}, mais ça déconne… --Pic-Sou 18 février 2012 à 17:16 (CET)

Il faut utiliser {{#tag:}}. --Lgd (d) 18 février 2012 à 17:26 (CET)

Rhaaah le gland ! Le pire, c'est que je devais le savoir… Bon, tout est corrigé, donc maintenant on peut même faire :

{{poem|Ða se eorl ongan for his ofermode
alyfan landes to fela laþere ðeode.|ang}}

Cordialement --Pic-Sou 18 février 2012 à 17:44 (CET)

Je ne connaissais pas {{#tag:}}, ça a l'air intéressant. Mais est-ce qu'on n'aurait pas plutôt pu modifier le modèle {{Vers}} plutôt que de créer {{poem}} (dont la dénomination laisse un peu à désirer) ? Ambigraphe, le 18 février 2012 à 20:15 (CET)

Insérer un lien dans un aricle

Bonjour,

Je voulais modifier un article et y ajouter un liens mais je ne l'ai pas publié car je n'ai pas réussi à ajouter un lien. Donc ma question aujourd'hui est comment ajouter un lien dans un article ? Voilà merci aurevoir !

--Chaussettes12 (d) 29 février 2012 à 12:12 (CET)

Il existe plusieurs types de liens : Aide:Liens. JackPotte ($♠) 29 février 2012 à 13:16 (CET)

Au-delà des apparences, le compte qui a créé cette section relève a priori plus du vandalisme (peut-être gentil et innocent, genre ado) qu'autre chose.

Dans tous les cas, ce n'est pas le lieu. Pour les questions de cet ordre, aller sur WP:Questions techniques. --Lgd (d) 29 février 2012 à 13:20 (CET)

Balises math

Bonjour, quelle tuile ! depuis hier soir tous les symboles "ordinaires" entre balises maths (typiquement : $a$), qui truffent le corps du texte des articles de maths, sont "forcés en png" (je crois que c'est comme ça qu'on dit), en tous cas : sont trop gros. Est-ce temporaire ou définitif ? (svp, ne me répondez pas qu'il suffit de modifier mes préférences ou css ou je ne sais quoi, réservé aux initiés) Anne (d) 1 mars 2012 à 09:14 (CET)

Je vais tâcher de regarder plus en détail dans la journée pour le souci de taille des images, mais c'est lié en effet à la mise à jour de mediawiki (voir le bistro du jour). A priori, c'est durable (rien n'est définitif en la matière ) et, désolé, cela entraîne que choisir une autre option nécessite de cocher une case dans les préférences du compte (ce qui n'est tout de même pas vraiment un truc d'initié, on a beaucoup plus barbare dans le genre, hélas : en fait, le système des options à cocher dans les préférences du compte sont ce que Wikipédia ou n'importe quel autre site pourrait offrir de moins geek ). Cordialement, --Lgd (d) 1 mars 2012 à 09:29 (CET)

Merci, mais pas trouvé quelle case il fallait cocher dans les préférences pour retrouver l'apparence que ça avait « avant ». Oui, je sais, je suis niaise, mais probablement pas la seule, et puis faut penser aux lecteurs lambda, qui n'ont même pas de compte. Anne (d) 1 mars 2012 à 10:18 (CET)

C'est en effet absolument épouvantable. Quel est le cheminement de prise de telle décision ? Y a-t-il eu consultation d'auteurs d'articles, au moins sur la Wikipédia en anglais ? La réponse vis-à-vis des préférences du compte ne me satisfait pas : je ne me préoccupe pas de la question comme lecteur mais comme auteur d'articles, et ne puis cocher les préférences des comptes de mes lecteurs (particulièrement de ceux, nombreux, qui lisent non connectés). Touriste (d) 3 mars 2012 à 11:49 (CET)

Le choix semble désormais réduit à image png (défaut) ou laisser code tex (cf Préférences/Apparence/Rendu des maths)

Cantons-de-l'Est nous indique dans RAW 40 que « Le rendu de LaTeX en MathML étant trop primaire, cette option est abandonnée. Parmi les deux options qui restent (voir dans le bas de cette page), une seule donne un résultat intéressant pour les navigateurs qui montrent les images - « Toujours produire une image PNG » -, l'autre est pour les navigateurs en mode texte (Lynx par exemple). » (il serait intéressant de trouver le texte original pour voir la raison de l’abandon de HTML simple). Je crois qu’il faudra donc faire avec les images png…

Ltrl G, le 3 mars 2012 à 12:02 (CET)

Réponse partielle à ma question : des échanges sur le Bistro des matheux anglophones me renvoie à [2], une "Request for Comments" sur le site de mediawiki (que je n'ai pas encore lue). Touriste (d) 3 mars 2012 à 12:05 (CET)

Sur le fond : le rendu de <math> et de ce type de contenus est une vieille épine très difficile à gérer dans les contenus Web (et pas seulement dans le cadre très limité des projets basés sur mediawiki)... Désolé, mais je doute que cet atelier y soit très utile. Son rôle se borne à aider les contributeurs à utiliser de manière « accessible » les solutions en place dans ces projets, et parfois à améliorer l'accessibilité de celles-ci. Il n'intervient pas sur des questions très en amont et sans rapport immédiat avec l'accessibilité, telles que « est-ce ou non un souci que MathML ne soit plus géré ».

Le choix récemment fait de ne plus gérer MathML me semble assez brutal, a priori, cela dit. Mais, à l'usage, cela fait longtemps que j'ai constaté que, quand on parle de « navigateurs texte » dans le développement de mediawiki, c'est qu'on va d'abord dire et ensuite faire des sottises... C'est un bon signal d'alerte, connu par ailleurs. Cordialement, --Lgd (d) 3 mars 2012 à 12:08 (CET)

Complément : le développement de mediawiki s'oriente apparemment vers l'implémentation prochaine de MathJax (voir [3]). --Lgd (d) 4 mars 2012 à 10:47 (CET)

{{lang}}

Bonjour, deux questions à propos de ce modèle :

• faut-il absolument utiliser le code : {{Lang|''code-langue''|texte=''texte''}} et non plus {{Lang|''code-langue''|texte}} ?
• est-il possible de créer un gadget pour la barre de modification (celle classique) pour ajouter le code de ce modèle automatiquement (en un clic) ?

Merci de vos réponses, Prosopee (d) 4 mars 2012 à 09:54 (CET)

Le code explicite (« texte=texte ») n'a aucun caractère obligatoire. Il n'est que rarement nécessaire à vrai dire. Je corrige la documentation du modèle sur ce point.

L'ajout de ce bouton se fait déjà via certains scripts d'utilisateurs. Mais ceux-ci rencontre un souci temporaire lié à la dernière mise à jour de Mediawiki, qui devrait être résolu dans les jours qui viennent.

Je réfléchis par ailleurs à une solution plus générique et plus simple pour les contributeurs que ces scripts personnels, sans pour autant multiplier les gadgets très spécifiques dans les préférences... Cordialement, --Lgd (d) 4 mars 2012 à 11:01 (CET)

Le script que j’utilise actuellement fonctionne toujours mais risque d’être un peu difficile à repérer au milieu du reste (très pratique : une fenêtre me demande le code de langue puis le modèle est inséré… hop, on peut passer à la suite). Ltrl G, le 4 mars 2012 à 11:11 (CET)

[edit] En gros, c’est insertTags('{{lang|'+prompt('Code de langue ?\n')+'|', '}}') dans un lien… Ltrl G, le 4 mars 2012 à 11:17 (CET)

Merci de vos réponses, je suis fixé. Pour le gadget : ce serait super ca rles scripts ce n'est pas trop mon truc... A voir donc. Prosopee (d) 4 mars 2012 à 19:58 (CET)

L'article Websourd est proposé à la suppression

Bonjour, L’article « Websourd » est proposé à la suppression (cf. Wikipédia:Pages à supprimer). Après avoir pris connaissance des critères généraux d’admissibilité des articles et des critères spécifiques, vous pourrez donner votre avis sur la page de discussion Discussion:Websourd/Suppression. Le meilleur moyen d’obtenir un consensus pour la conservation de l’article est de fournir des sources secondaires fiables et indépendantes. Si vous ne pouvez trouver de telles sources, c’est que l’article n’est probablement pas admissible. N’oubliez pas que les principes fondateurs de Wikipédia ne garantissent aucun droit à avoir un article sur Wikipédia.

ConradMayhew (d) 4 mars 2012 à 12:44 (CET)

Si vous connaissez cette association ou pouvez juger de son intérêt, n'hésitez pas à participer au débat de suppression ConradMayhew (d) 4 mars 2012 à 12:44 (CET)

Pour s'en tenir à l'important, l'article est très évidemment « beaucoup et encore au-delà à améliorer ».

Cela dit, vue comme ça au premier coup d’œil, la proposition de suppression est cocasse (pas tout à fait dans certains détails, mais ils ont été masqués). Puis, à mieux y regarder, on s'aperçoit que c'est juste l'effet mécanique des... modèles : {{admissibilité à vérifier}} suivi de {{suppression}} avec un petit coup de pouce du folklore des « Patrouilleurs » qui conduit à des choses beaucoup trop formelles et irréfléchies.

Ce n'est pas grave, cela dit : la conservation de l'article est assez prévisible. Pire : sa suppression éventuelle ne conduira qu'à son inévitable recréation plus tard sous une rédaction plus obéissante aux usages et plus dissuasive pour les pistoleros de la maintenance. C'est ça qui est génial, au fond, avec Wikipédia .

Mais c'est marrant, quand même, de supprimer un article sur un des acteurs majeurs de l'accessibilité Web en France . Cordialement, --Lgd (d) 4 mars 2012 à 14:51 (CET)

Je ne sais pas le raisonnement de Lgd. TiboQorl ne s'est pas enregistré comme patrouilleur, donc je ne vois pas quel est le rapport entre sa demande de suppression et la patrouille?

Si l'on parle de mon intervention (j'étais effectivement patrouilleur), elle a uniquement consisté à notifier cet atelier et le projet handicap afin que des gens qui connaissent le domaine puissent donner leur avis sur un sujet qui est dans leur périmètre. ConradMayhew (d) 4 mars 2012 à 20:08 (CET)

Ma remarque n'avait aucun rapport avec ton intervention pour avertir de cette PàS, qui était au contraire bienvenue, même si cet atelier n'a pas pour propos la rédaction et le suivi des articles sur le sujet. Cordialement, --Lgd (d) 4 mars 2012 à 21:03 (CET)

Ca marche. Je reconnais bien évidemment avoir utilisé pour cette annonce un espace qui n’est pas prévu pour cela. Désolé mais je plaide les circonstances atténuantes : c'était pour la bonne cause! Je suis un fervent défenseur de la patrouille, mais aussi un fervent adversaire de la suppressionnite aigüe : on ne devrait supprimer un article qu'après avis de ceux qui connaissent le sujet, sinon on dégomme tout et n'importe quoi juste parce qu'on n'y connait rien! En lisant ton commentaire plus haut, je pense qu'au final on se rejoint assez bien sur cette conclusion… Cordialement, ConradMayhew (d) 4 mars 2012 à 22:22 (CET)

Articles-galeries

Bonjour, un article comme Sporophore est-il acceptable sur Wikipédia à condition d'y ajouter simplement des « alt » ? --Amicalement, Salix ( converser) 4 mars 2012 à 13:10 (CET)

Ps. C'est pour savoir si on peut encourager ce type d'article qui semble bien pratique mais qui repose essentiellement sur des images ou s'il vaut mieux trouver une autre solution (pas pour servir d'argument à une suppression ). Est-ce totalement indigeste pour un lecteur d'écran ou améliorable ? Faut-il demander l'ajout de texte explicatif ? Faut-il limiter la longueur des galeries ? Faut-il préférer l'externalisation des galeries sur des pages Commons avec descriptif là-bas ? Tout à la fois ? Bref peut-on multiplier ce type d'article ? --Amicalement, Salix ( converser) 4 mars 2012 à 17:16 (CET)

Les questions liées à l'accessibilité sont les mêmes que pour tout autre article, quel que soit sa forme. Les images de galerie nécessitent des alt, comme pour toute autre galerie. Et si on ne pouvait pas en mettre, ce défaut d'accessibilité ne devrait pas pour autant peser dans le choix éditorial d'encourager ou non ce type d'article .

Mon avis est un poil plus que psychorigide sur ce genre de choses, mais c'est totalement assumé : l'accessibilité est un outil au service des contenus, rien de moins mais rien de plus. Ce sont donc les contenus et leur pertinence ou leur besoin qui tranchent .
D'ailleurs, c'est pourquoi, à vrai dire, on ne parle sagement jamais ici de certains modèles très employés, à l'accessibilité littéralement dramatique... mais totalement irremplaçables en matière de contenu : il serait absurde pour l'encyclopédie de supprimer les feuilles de match, par exemple... Cordialement, --Lgd (d) 4 mars 2012 à 18:28 (CET)

Certes, mais je ne voudrais pas être celle qui naïvement irait encourager leur multiplication si d'autres mises en forme plus accessibles existent ou que certaines astuces ou restrictions permettent de limiter les dégâts. C'est là que les conseils éclairés de cet atelier s'avèrent utiles . --Amicalement, Salix ( converser) 4 mars 2012 à 18:52 (CET)