Discussion Wikipédia:Atelier accessibilité

Un article de Wikipédia, l'encyclopédie libre.

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

Vous pouvez également consulter:

Atelier accessibilité
Coordination de l'atelier
Poser une question

Sommaire

[modifier] Accessibilité, qu'est-ce que ça veut dire ?

Bonjour et merci pour cette initiative. Mais juste un mot « Pourriez-vous rendre facilement accessible une définition de l'accessibilité de Wikipédia ? Est-ce que c'est l'Accessibilité du Web ?  » Cordialement. --Bruno des acacias 28 avril 2008 à 08:41 (CEST)

Un peu plus qu'une brève définition, mais les exemples concrets sont nécessaires : Wikipédia:Atelier accessibilité/Qu'est-ce que c'est ? Cordialement, --Lgd (d) 28 avril 2008 à 08:50 (CEST)
Je n'avais donc pas tout lu. Je suggèrerais d'ailleurs de préciser que la question « Qu'est-ce que c'est » dans la liste des raccourcis de « Atelier accessibilité » soit formulée « Qu'est-ce que l'accessibilité ? » que j'ai pour ma part compris comme « Qu'est-ce que l'atelier accessibilité ?  » Pour info. --Bruno des acacias 28 avril 2008 à 09:24 (CEST)

[modifier] Portail:Réalisation audiovisuelle

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)

Vite fait (et pas très bien fait pour l'instant):
  • Plusieurs tableaux ne se linéarisent pas de façon compréhensible: le titre « Réalisateur au cinéma » devrait par exemple être dans la même cellule que « Un réalisateur de cinéma est une personne qui...  ». Pour quelqu'un qui n'a pas l'aide du rendu visuel d'un tableau, les titres qui ne sont pas dans la même cellule que le contenu auquel ils sont associés ne sont pas compréhensibles. Le problème se pose pour:
    • les sous-titres dans « Dans la Réalisation »
    • les sous-titres dans « La Réalisation »
    • les sous-titres dans « Autour de la Réalisation »
    • Les sous-titres dans « Articles par labels »
  • Fait > Il y a logiquement deux niveaux de titres dans la page, mais tous les titres sont au même niveau en h2 (wiki: ==). Les sous-titres comme « Réalisateur au cinéma » devraient être en h3 (wiki: ===)
  • Fait > Plusieurs tableaux mélangent tableau de donnée et tableau de présentation: il faut enlever tous les th (code wiki !) et rester sur des tableaux de présentation.
  • Fait > Je vais y revenir un peu plus tard, mais les images illustratives ou décoratives n'ont pas d'alternatives textuelles ou n'ont pas la bonne (exemple: [[Image:20th Television.jpg|150px]] n'en a pas). Quand on ne précide pas d'alternative, un lecteur d'écran lit le nom du fichier image (c'est un point assez compliqué où mediawiki ne permet pas de faire les choses correctement, et ce sera une des grosses difficultés sur laquelle l'atelier devra trouver une politique à adopter)
  • il y a plusieurs liens qui ne sont explicites (on ne comprendra pas leur sens dans un lecteur d'écran notamment), mais là aussi, il faut regarder plus en détail.
Dans l'immédiat, régler déjà les problèmes de tableaux et de titres, si les pages d'aide et ces explications suffisent. Sinon, râler ici Mort de rire --Lgd (d) 28 avril 2008 à 11:28 (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)

[modifier] Evaluation (rapide) d'une boite

dé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)

Pas de souci, je ne me serais pas lancé dans cet atelier, sinon Clin d'œil. Je me permets juste de déplacer ici, tant qu'à faire.
Utilisateur:Bayo/IJV accessibilité, je n'ai plus trop les yeux en face des trous nà cause d'une blanche passée sur un rapport pour un client, mais sauf erreur de ma part:
  • utilisation de scope: parfait
  • le caption caché avec un titre générique est une excellente idée... Mais va nous poser un problème dans IE6-7, qui ne parviendra pas à appliquer correctement la CSS servant à le masquer (bug dit de « haslayout » faussant le positionnement absolu). Voir si on peut trouver un contournement, sinon, il faudra se passer de caption avec ce design des infoboxV2 (mettre la cellule affichant le titre en <caption> pose d'autres problèmes de CSS, hélas).
  • par contre, les <th scope="col"> cachés servant d'en-têtes au titre visible et à l'image ne me semblent pas pertinents : ils vont être répétés par un lecteur d'écran pour chacune des cellules qui suivent, jusqu'à la fin du tableau, en perturbant les entêtes de ligne et en rendant l'infobox très verbeuse. j'aimerais bien avoir l'avis de GillesC en particulier, mais je penche vraiment pour laisser le titre visible et l'image dans de simples <td> sans en-têtes associés, le rendu étant malgré tout assez intuitif. Le mieux est parfois l'ennemi du bien Clin d'œil.
De mon côté, j'étais parti sur Utilisateur:Lgd/test tableaux/Infobox Cinéma (film, qui résume un peu tout cela (voir un exemple de rendu dans Utilisateur:Lgd/test tableaux, Toy story).
--Lgd (d) 29 avril 2008 à 16:32 (CEST)
A propos du rendu graphique, j'ai testé sur pas mal de navigateur, et en effet le caption est affiché sur IE5,6,7 (mais ca pourrait rester comme ça, ce n'est pas gênant amha). Par contre les th masqués rendent comme une cellule vide sur Safari (Windows) et Konqueror, ce que je trouve plus embêtant. bayo 29 avril 2008 à 18:44 (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)

Merci stef :-) --Lgd (d) 30 avril 2008 à 18:01 (CEST)

[modifier] Modèle:Indication de format et Modèle:Indication de langue

En retouchant le premier, je me suis demandé s'il ne serait pas pratique de remplacer le span par un abbr (peut-être acronym pour le format, en vérifiant bien les modèles qui l'emploient), car c'est le but de ce modèle, non ? Comme ces modèles sont certainement utilisés un bon million de fois, j'aimerais un avis avant de toucher. Merci. bayo 30 avril 2008 à 06:11 (CEST)

Arf :/ je viens de constater que abbr n'est pas supporté par MediaWiki... On peut toujours ouvrir une nouvelle demande sur bugzilla :) bayo 30 avril 2008 à 06:18 (CEST)
Il est ouvert ici depuis assez longtemps: Bug #671 --Lgd (d) 30 avril 2008 à 06:25 (CEST)
Cela dit, il faut savoir que l'utilisation d'acronym et d'abbr est loin d'être simple. Ils ont en fait chacun une double fonction:
  1. expliciter le sens d'un sigle, grâce à leur attribut title : les internautes ayant la capacité d'utiliser une souris dans un navigateur graphique peuvent consulter le title en survolant l'élément. De même, un lecteur d'écran actuel pourra, selon ses réglages utilisateurs, lire le title à la place de l'abréviation ou de l'acronyme. Bonne idée a priori... sauf que:
    • le « tooltip » (bulle d'aide) qui s'affiche au survol est inaccessible au clavier ou en dehors d'un rendu graphique évolué (navigateur texte, différents mobiles, etc.). C'est une demi-mesure d'accessibilité en réalité (tout comme le <span title="..."> des modèles actuels dans Wikipédia). Pour expliciter un sigle de manière vraiment accessible, il faut (et il suffit) d'en faire un lien vers son entrée dans une page de glossaire (ou ici vers sa propre page), ou de l'expliciter directement dans le contexte (exemple: « La SNCF (Société nationale des chemins de fer)... »). En sachant qu'il n'est pas pertinent ni nécessaire d'expliciter systématiquement toutes les occurences de tous les sigles : dans les listes de liens externes, la transformation en lien serait peut-être plus pertinente.
    • en effet, tout expliciter quelque-soit le moyen a ses revers: par exemple, la lecture systématique des title à la place des sigles dans un lecteur d'écran peut rendre le contenu totalement imbuvable à force d'être verbeux, quand ces sigles sont nombreux et répétés. C'est pourquoi les directives WCAG ne recommandent son usage que sur « la première occurence d'une abréviation ou d'un acronyme dans la page ». Pour {{Indication de langue}} et {{Indication de format}}, il faudrait donc veiller à ce que seul le title de la première occurence de chaque langue ou format soit renseignée dans une liste de liens externes... Pas évident à gérer éditorialement ici Clin d'œil. Sinon, à savoir: le problème ne se pose pas pour le <span title="..."> des modèles actuels qui est ignoré par les lecteurs d'écran.
  2. permettre à une synthèse vocale d'adopter le bon mode de prononciation: un acronym étant supposé se lire comme un mot alors qu'une abbr est supposée s'épeler. Sauf que:
    • il est en réalité impossible de définir cette différence d'une manière unique quelque-soit la langue.
    • ce problème de prononciation dans une synthèse vocale ne relève pas de la structure HTML, mais du niveau CSS (les CSS3 « speech ») : une seul élément est donc structurellement nécessaire en théorie. Concrètement, HTML5 et XHTML2 sont d'ailleurs bien partis pour faire disparaître le couple abbr/acronym au profit d'un seul élément abbr.
    • concrètement, les lecteurs d'écran disposent d'un mécanisme de dictionnaire (enrichissable par l'utilisateur) permettant une détection plus ou moins heureuse des acronymes et abréviations.
Au final:
  • oublier acronym
  • redemander l'implémentation d'abbr, pourquoi pas ? Mais je crains un peu les effets pervers de son éventuelle utilisation systématique ici.
  • surtout:
    • Pour la langue de la cible d'un lien externe: le libellé rédigé dans la langue concerné suffit à répondre aux besoins en accessibilité, dès lors qu'on utilise le modèle {{lang}} (exemple: Web Content Accessibility Guidelines 1.0).
    • Pour le format de la cible d'un lien externe: c'est aussi via le libellé du lien que le format doit être indiqué pour que le lien soit explicite et donc accessible (exemple: Lorem ipsum (format PDF)).
Tiens, il faudrait revoir et améliorer Aide:Liens_externes#Accessibilit.C3.A9, à ce propos.
Voilà voilà... --Lgd (d) 30 avril 2008 à 10:00 (CEST)
Sur la retouche que tu as fait, on peut peut-être privilégier un « Titre du document [pdf] » et faire évoluer le modèle : parenthèse, pas de gras, et typo classique. bayo 30 avril 2008 à 11:48 (CEST)
ce serait une très bonne solution. J'hésite encore à proposer des changements un peu « massifs » des habitudes (ici, impactant un très nombre de page de manière très visible), mais je suis peu-être trop prudent Mort de rire --Lgd (d) 30 avril 2008 à 12:11 (CEST)
Non, tu fais bien. Soit c'est une PDD, soit c'est par petite retouche sur une longue période :) Comme [1] couplé avec [2]. bayo 30 avril 2008 à 13:11 (CEST)

[modifier] Fausse carte cliquable à corriger, si quelqu'un s'ennuie... Clin d'œil

Si jamais quelqu'un cherche quelque-chose à faire: {{Carte d'Allemagne avec liens internes}} est un bon exemple de ce qu'il ne faut pas faire à coup de positionnement CSS sur un fond de carte:

  • sans CSS, l'information « position des liens sur la carte » est perdue
  • c'est une imagemap qu'il faudrait utiliser: l'information est alors indépendante de CSS.

Il faudrait donc refaire ce modèle avec une <imagemap>... --Lgd (d) 30 avril 2008 à 18:08 (CEST)

Schleswig-Holstein Mecklembourg-Poméranie-Occidentale Berlin Brandebourg Hambourg Brême Basse-Saxe Saxe-Anhalt Saxe Thuringe Hesse Rhénanie-du-Nord-Westphalie Bavière Rhénanie-Palatinat Sarre Bade-Wurtemberg

Carte des États allemandsÀ propos de cette image

Je veux de l'or pour ça, j'y ai passé des heures et des heures !!!! C'était chaud à faire aussi, alors ? Des commentaires ? Espiègle Sifflote — Steƒ (  Стеф  ) 30 avril 2008 à 21:26 (CEST)

Géniale cette extension. Peux-être rajouter un cadre de fond pour permettre d'accéder à la description de l'image et sa licence ? Mais ça peut aussi perturber la bonne compréhension de la navigation fournie par l'image. bayo 1 mai 2008 à 02:43 (CEST)
Waow o_O
En vrai, j'avais un peu posté ce message histoire de garder une trace de ce modèle et d'évoquer le problème, je ne pensais pas que quelqu'un s'y collerai pour de bon. Stef, bravo !
Cela dit, je vois trois petites améliorations à apporter pour compléter ce travail de titan Clin d'œil :
  • modifier le fond de carte lui-même (ouf, c'est un SVG), pour faire réapparaître les noms des régions. Je demande ça sur l'atelier graphique. En attendant que ce soit fait, je crois qu'il est plus prudent de ne pas mettre à jour tout de suite le modèle: ça risque de ne pas être apprécié (Politique du « l'accessibilité ne modifie pas votre rendu » Clin d'œil)
  • ne pas oublier l'alternative textuelle globale de l'image: Image:... |Carte des États allemands (fait)
  • effectivement, ajouter la petite icône qui va bien pour l'accès à la description de l'image: il suffit de remplacer le desc none par un desc bottom-right (fait).
Par contre, le positionnement de l'icône se fait mal quand l'image est centrée, tiens... --Lgd (d) 1 mai 2008 à 07:09 (CEST)
Lol, ce n'était pas trop compliqué ... Ca m'a passé le temps ! Oui, j'ai remarqué pour l'icône c'est pour ça que j'avais mit desc none... merci pour tes améliorations ! Bonne journée — Steƒ (  Стеф  ) 1 mai 2008 à 09:29 (CEST)
Fait pour mla mise à jour du modèle avec la carte améliorée par l'atelier graphique. --Lgd (d) 1 mai 2008 à 20:07 (CEST)
Mouarf Mort de rire. Il y en a toute une mine, en fait:
J'ai laissé un mot sur la page de l'auteur, pour le mettre au courant. --Lgd (d) 1 mai 2008 à 20:24 (CEST)
Je me permets d'ajouter {{Carte des châteaux cathares}} à la liste, que j'ai pris des heures à faire à une époque où imagemap n'existait pas encore. Je n'ai pas vraiment le temps de m'en occuper en ce moment, si quelqu'un veut donner un coup de main... :) guillom 1 mai 2008 à 21:30 (CEST)
Je ne savais pas merci pour l'info! Désolé d'avoir donné du boulot oups Comment fais-t-on? car je peux aider après tout c'est en partie de ma fauteClin d'œil J'ajoute le pseudo-modèle de la Liste des châteaux français par région qui m'avait donné envie de faire toute cette liste et j'allais continuer...! Merci pour l'info, et pardonnez mon ignorance oups Otourly (d) 1 mai 2008 à 21:59 (CEST)

Je promet de m'en occuper, dès que j'ai le temps. D'ici deux jours, j'aurais finit je pense Clin d'œil Je commencerai demain — Steƒ (  Стеф  ) 1 mai 2008 à 22:58 (CEST)

D'accord Stef mais voudrais tu m'en toucher deux mots, pour savoir comment on fait? Car pour certains j'ai traduit le modèle... Et si je continue pour la Suisse ou la Roumanie il faudra bien que je sache, et je ne vais pas non plus te solliciter à chaque fois! Otourly (d) 1 mai 2008 à 23:06 (CEST)
Il existe l'outil ImageMapEdit mais qui ne semble pas marcher avec le SVG. Avec une petite astuce on peut tout de même lui en faire manger.
Si ya plus simple je suis preneur :) bayo 2 mai 2008 à 00:03 (CEST)
En fait, on peut récupérer l'URL plus simplement, en fessant afficher l'image par le wiki. Une prévisualisation d'une page en plaçant le code [[Image:Routes des châteaux cathares sans.svg]], puis en récupérant l'URL générée pour l'image [3] bayo 2 mai 2008 à 00:11 (CEST)
Plus simplement: depuis la page Image:Italie par régions sans noms.svg, faire un clic droit sur l'image pour accéder à ses propriétés dans Firefox ou IE et faire un copié-collé de l'URL en .png. Opera propose directement une entrée « copier l'url de l'image » dans le même menu contextuel. Sauf erreur de la part, imagemap gère le changement de dimension final, donc peut importe la taille de l'image de travail ? --Lgd (d) 2 mai 2008 à 07:02 (CEST)
Si on génère les poly a partir de l'image miniature ou de l'image en taille normale on va forcément avoir des données différences (elles sont en pixels, par en %). Il faut bien que les données soient relatives a quelque chose, sinon c'est incalculable. En consultant la doc on tombe sur « All coordinates are according to the full-size image ». bayo 2 mai 2008 à 12:51 (CEST)

[modifier] Modèle:Carte d'Italie avec liens internes

Trentin-Haut-Adige Frioul-Vénétie julienne Vénétie Lombardie Piémont Val d'Aoste Ligurie Émilie-Romagne Toscane Marches Latium Ombrie Abruzzes Molise Campanie Basilicate Pouilles Calabre Sardaigne Sicile

À propos de cette image

Et de une de plus — Steƒ (  Стеф  ) 2 mai 2008 à 12:32 (CEST)

Et je rêve, mes coordonnées sont mauvaises ! Faut que je recommence Triste — Steƒ (  Стеф  ) 2 mai 2008 à 12:32 (CEST)
Et une victime de l'échelle, une :P bayo 2 mai 2008 à 12:54 (CEST)
/me confus, confus, confus... mais confus... --Lgd (d) 2 mai 2008 à 12:57 (CEST)
Pourquoi ? Je la recommencerais plus tard, tant pis ... — Steƒ (  Стеф  ) 2 mai 2008 à 13:07 (CEST)
Au fait Stef, je viens de me souvenir qu'il existe it:Template:Italia imagemap donc une traduction de la carte devrait suffire? J'ai trouvé que que ce modèle existant par contre :( Otourly (d) 8 mai 2008 à 21:35 (CEST)

[modifier] Nouvelle fonctionnalité <ref group="foo">

L'extension Cite (ou alors s'agit d'une nouvelle extension parallèle, j'ai la flemme d'éplucher Special:Version ce matin) a une nouvelle fonctionnalité qui peut améliorer significativement l'accessibilité du système de <ref>...</ref>.

Les <ref>...</ref> classiques créent en effet des liens non explicites : le libellé de l'appel de note est un simple chiffre, qui ne permet absolument pas d'identifier le rôle et la cible du lien. Dans chaque note, le lien de retour au texte est un dramatique caractère « ↑ » pas plus explicite, dont le rendu dépend en outre du support Unicode et des polices installées chez l'utilisateurs. Bref, degré zéro de l'accessibilité et, pour être franc, des choses qu'on ne doit jamais faire en développement Web. Ce serait aisément rattrapable si l'extension gérait des title sur ces liens, mais je crois que personne n'a jamais contacté son auteur à ce sujet. Ce qui serait à faire, évidemment Clin d'œil

Bref, avec <ref group="foo">, il est à présent possible de rendre les appels de notes un peu plus accessibles (et ergonomiques, dans la foulée). Voir l'exemple des appels de notes dans la page des bonnes pratiques de l'atelier.

Toutes autres idées pour creuser ça sont les bienvenues... --Lgd (d) 1 mai 2008 à 09:37 (CEST)

j'oubliais: le code HTML produit par les <references group="foo" /> est malheureusement un bel exemple d'utilisation inappropriée des listes de définition, mais bon, c'est un moindre mal... --Lgd (d) 1 mai 2008 à 09:45 (CEST) tiens, non en fait. je n'ai rien dit. --Lgd (d) 1 mai 2008 à 09:48 (CEST)
Ouais mais elles sont moins simples d'utilisation que les simples <ref> et ne permettent pas l'usage de {{références}} pas mal utilisé ... surtout sur les articles de qualité. D'ailleurs, au sujet d'articles de qualité, tu avais parlé d'évaluer l'accessibilité d'un de ces AdQ, je te propose cinéma un des plus longs articles de la wikipédia francophone (35e au 20 avril, désormais quasi stable, en cours de vote). Je l'ai écrit avec quelques autres utilisateurs, il fait partie des articles les plus visités, et le rendre accessible serait une bonne chose je pense, comme tu veux — Steƒ (  Стеф  ) 1 mai 2008 à 09:53 (CEST)
Génial. J'ai pas encore le recule suffisant, mais amha c'est très bien pour séparer les notes de page des références (en regardant la doc ça semble être fait pour) ; mais pouvoir découper toutes les refs en petits paquets (une bonne dizaine de ref sur le même document), dans la pratique ça doit être assez rare. Faudrait voir le rendu sur l'article cinéma :D bayo 1 mai 2008 à 13:08 (CEST)
D'ailleurs, il faudrait peut-être modifier MediaWiki:Cite references link one pour faire apparaitre le groupe (si c'est techniquement possible) ; car le rendu que l'on peut voir sur Aide:Note#Notes groupées ne me semble pas très heureux. bayo 1 mai 2008 à 13:18 (CEST)
Cool, je peux même modifier les messages systèmes Espiègle — Steƒ (  Стеф  ) 1 mai 2008 à 13:20 (CEST)

[modifier] Imagemap et icône de titre

Je sais qu'il est possible de mettre une imagemap sous forme d'icône de titre. Il aurait été possible de remodeler le modèle {{icône de titre}} mais, je sais que l'extension imagemap posait un problème, elle n'acceptait pas les {{{1|...}}}, un débat sur la résolution de ce problème était en cours, quelqu'un sait où il en est ?

Si j'ai bien saisi la question: le problème du passage de variables aux extensions dans les modèles est résolu depuis quelques temps, grâce à un nouveau magic word, #tag. C'est ce qui a permis à Zelda de corriger déjà {{Lien sur icône}}, de manière à ce qu'il ne pose plus de problème d'accessibilité. La correction en suivant d' {{Icône de titre}} est en cours de validation (Voir aussi la discussion sur {{Références}} dans la même page). --Lgd (d) 2 mai 2008 à 20:52 (CEST)

[modifier] Modèle:DemogFR

Bonjour. Il existe quatre ou cinq modèles du genre dans la même catégorie. J'aimerais savoir si dans un cas comme celui là un scope="col" suffit, ou s'il vaut mieux utiliser le couple id, headers (qui est pas mal lourd). C'est, si j'ai compris d'une discussion précédente, ambigu. Merci. bayo 5 mai 2008 à 14:59 (CEST)

Le modèle génère en fait une succession de tableaux à ligne d'en-tête unique (un tableau par « rang »). scope=col suffit donc. Cordialement, --Lgd (d) 5 mai 2008 à 15:03 (CEST)
Mon dieu que c'est rapide, merci... et dans l'hypothèse d'un tableau unique (Modèle:DemogAL mauvais exemple) ? bayo 5 mai 2008 à 15:05 (CEST)
lol, je passais par là, en fait
Dans le cas d'un tableau unique, au contraire, id et headers sont nécessaires : scope distribuerait chaque entête à toutes les cellules d'une colonne, indistinctement. Pour un bon exemple de tableau où headers est nécessaire, voir Benazir Bhutto dans cette page de tests. --Lgd (d) 5 mai 2008 à 15:12 (CEST)
Faut juste prier que deux même boites ne soient pas dans la même page. bayo 5 mai 2008 à 15:53 (CEST)
Au fait: merci pour tes corrections sur les différents modèles démographiques Clin d'œil --Lgd (d) 6 mai 2008 à 08:02 (CEST)
Pas de quoi, je prends ça comme des travaux pratiques, histoire de mieux comprendre ces problèmes. bayo 6 mai 2008 à 10:59 (CEST)

[modifier] Carte de Mars

Bonjour,

J’ai crée {{Carte de Mars}} qui j’en ai bien peur n’est pas très accessible. Est-ce qu’il y a moyen d’arranger la chose ? Je ne sais pas si ImageMap est adapté, dans la mesure où un point de la carte peut correspondre à plusieurs liens. Cordialement, VIGNERON * discut. 8 mai 2008 à 13:22 (CEST)

ImageMap conviendra bien, en modifiant l'image pour y intégrer les textes de lien. Après, les zones cliquables peuvent être plus ou moins découpées pour correspondre aux zones « réelles ». Mais de simples zones rectangulaires juste autour de chaque texte devraient aussi bien convenir, je crois ?
Par contre, je comprends le problème de taille de l'image, mais bon sang que c'est écrit petit ! (7px de rendu courant). Du coup, l'agrandissement typographique dans FF ou IE fait que les textes des liens se mettent à se chevaucher. Encore une raison de préférer des imagemap (mais avec un texte un peu plus grand si possible) : le zoom typo ne marche plus, mais du coup, il ne fait plus de dégâts. Et un zoom graphique (IE7, Opera) peut prendre le relais Clin d'œil --Lgd (d) 8 mai 2008 à 13:41 (CEST)
Hihi... je viens de voir le font-size: 7px généré par le modèle: si possible, ne pas employer de pixels, bien que ce soit une unité théoriquement « relative » : les caractères en pixels ne sont pas agrandissables dans IE. Cordialement, --Lgd (d) 8 mai 2008 à 13:48 (CEST)
Tu veux que j'essaye de découper les zones avec imagemap ? — Steƒ (  Стеф  ) 8 mai 2008 à 14:54 (CEST)
Si tu veux mais certaines zones se chevauchent ou sont les unes sur les autres (un cratère qui se situe sur une plaine par exemple). Je ne sais pas si c'est possible. VIGNERON * discut. 8 mai 2008 à 20:56 (CEST)
Sorry, des soucis avec IRC
Tu peux superposer des zones cliquables d'image MAP en HTML, en effet, en mettant celle du premier plan (le cratère) après avant celle du second plan (la plaine) dans l'ordre du code. Normalement, l'extension devrait le gérer sans problème.--Lgd (d) 8 mai 2008 à 21:05 (CEST)
Testé rapidement dans Utilisateur:Lgd test, ça le fait. Attention à l'ordre des zones Clin d'œil --Lgd (d) 10 mai 2008 à 06:49 (CEST)

Tant qu'on est avec les cartes, un peu rien à voir avec l'accessibilité, je viens de mettre à jour {{Carte des régions françaises}}, mais que pensez vous des paramètres que j'ai ajouté ? C'est fait de telle sorte que le modèle est utilisable pile poile comme une image, et du coup peut être réutilisé plus facilement j'espère. J'aimerais un avis parce que au final ca peut poser un problème lors d'évolutions. Merci. bayo 10 mai 2008 à 18:49 (CEST)

[modifier] Menus déroulants et infobox

Bonsoir, je viens de découvrir dans d'autres circonstances qu'il existe des infobox avec des parties déroulantes comme sur Cowboy Bebop par exemple (il y en a deux). Qu'en est-t-il du point de vue accessibilité? Peux-t-on généraliser cette mise en forme ou non? --amicalement, Salix ( converser) 9 mai 2008 à 00:13 (CEST) PS. ça bosse dure ici. Désolée, je suis prise par d'autres projets en ce moment. A bientôt!

Hum, c'est là où il faut se souvenir que l'accessibilité, ce sont des normes mais aussi un art du compromis:
  1. Points positifs: deux critères majeurs sont respectés:
    1. le contenu concerné est visible par défaut si javascript n'est pas activé ou supporté chez l'utilisateur
    2. les liens [dérouler] sont utilisables au clavier
  2. Le souci majeur: dans un lecteur d'écran en particulier, les liens [dérouler], surtout quand il y en a plusieurs dans la même page, ne permettent pas de comprendre quel va être leur effet. Du coup, il faut une certaine dose de chance ou d'habitude pour accéder au contenu concerné.
    <jargon> Dans createCollapseButtons(), il leur manque un title explicite à générer d'après le contenu du premier th du table class="collapsible", mais celui-ci est trop imprévisible pour que ce soit facile à mettre en place de manière robuste.</jargon>
  3. On peut peut-être contourner ce souci en faisant en sorte qu'un lecteur d'écran n'ait plus besoin qu'on ait suivi le lien [dérouler] pour pouvoir lire le contenu caché. A voir pour tester et proposer la modification du script.
    <jargon>Remplacer le display:none de collapseTable() par une classe de masquage</jargon>
  4. Il y a quelques autres soucis mineurs, mais on peut passer.
    <jargon>Imbrication de deux tableaux de données (infobox et table class="collapsible") et plus généralement utilisation d'un tableau inutile.</jargon>
Conclusion: ce n'est pas optimal, mais c'est améliorable de façon « invisible » sans perturber les contributeurs, et ceux-ci y sont souvent très attachés. Laisser faire... Clin d'œil. --Lgd (d) 9 mai 2008 à 06:11 (CEST)
Merci Ldg pour ces explications détaillées et celles d'ailleurs des autres sections J'ai presque l'impression de comprendre alors que j'en suis encore au niveau Babel proche de 0 dans la connaissance de ce langage technique. Afin de ne pas perdre ces belles analyses dans nos futures archives où peut-on les placer afin d'en faire profiter tous les concepteurs de modèles, infobox et autres palettes? --amicalement, Salix ( converser) 9 mai 2008 à 09:54 (CEST)
<sourire diabolique> le piège a marché Mort de rire
Pour l'instant, Wikipédia:Atelier accessibilité/Bonnes pratiques est un chantier ouvert, qui va sans doute s'orienter vers une page générale et des {{Article détaillé}}, et Wikipédia:Atelier accessibilité/FAQ manque sans doute de détails ou également de renvois vers les mêmes {{Article détaillé}}, je crois. Sinon, je pensais depuis longtemps à un index/glossaire avec des entrées du type « tableau », « [dérouler] », etc. Qu'en penses-tu ? Amicalement, --Lgd (d) 9 mai 2008 à 16:55 (CEST)
Mort de rire Je n'étais pas bien difficile à « piéger » si tu regardes cette modification de ma page perso qui date de... janvier 2007! --amicalement, Salix ( converser) 9 mai 2008 à 23:25 (CEST)

[modifier] Améliorer {{Méta palette de navigation}}

Suite à la pose du bandeau {{Accessibilité à corriger}} sur ce modèle, je fais le point de son évaluation d'accessibilité:

  • C'est un des modèles les plus employés en particulier dans les articles, son impact sur l'accessibilité est important. C'est aussi un modèle qui semble de plus en plus employé, en raison de ses qualités évidentes.
  • En effet, il est d'une grande facilité d'utilisation et de syntaxe pour les contributeurs, il permet d'harmoniser une large partie de la navigation dans les articles, et son codage wiki est de très bonne qualité.
  • Mais il pose, dans le détail du code HTML qu'il génère, plusieurs problèmes d'accessibilité dont les plus importants sont liés à la structure des tableaux HTML. Ces problèmes varient selon les options utilisées. Les voici par ordre de gravité croissante:
    1. Correction éventuelle: en version Avec image dans le corps, c'est un hybride de tableau de présentation et de données, ce qui devrait être évité autant que possible.
    2. Correction recommandée: en version sans groupes ni images, il s'agit d'un tableau de présentation, dont la première cellule ne devrait pas être balisée en th. La correction est possible.
    3. Correction nécessaire: dans toutes les versions reposant sur un tableau de données, l'intégration du modèle {{Tnavbar}} dans l'en-tête th rend celui-ci très difficilement compréhensible dans un lecteur d'écran. On peut envisager de sortir ce modèle du tableau, ou du moins de cette cellule.
    4. Correction nécessaire: en version avec groupes, c'est un tableau de données qui nécessite l'ajout d'attribut scope, correction qui ne pose pas de difficultés.
    5. Correction nécessaire: en version avec sous-groupes, le modèle imbrique deux tableaux de données là où la structure logique du contenu n'en comporte qu'un seul. Etant donnée le fonctionnement du modèle et de son sous-modèle {{Méta palette de navigation sous-groupe}}, ainsi que le nombre de pages qui utilisent cette option, cette correction est pratiquement impossible à apporter (le sous-modèle utilise les mêmes noms de variables que le modèle parent, en particulier).

A noter: on rencontre également d'autres difficultés liées aux images-liens et aux liens [dérouler] non explicites, mais elles ne sont pas propre au modèle, et relèvent de cas plus généraux. Il n'y a pas lieu de les prendre en compte à ce stade.

Parmi les publics bénéficiant de l'accessibilité, l'impact de ces différents points concerne avant tout les utilisateurs de lecteurs d'écrans, pour lesquels les tableaux sont un contenu crucial : selon la structure HTML de ceux-ci, leur contenu peut aller du très facilement compréhensible au plus totalement obscur. Dans la mesure où il s'agit ici d'un élément clé de la navigation dans les articles, il mérite un traitement aussi accessible que possible.

Cela dit, il ne sera certainement pas possible de corriger toutes les points ci-dessus. Le dernier (cas des palettes à sous-groupes) est certainement le plus délicat, et nécessite AMHA, uniquement dans le cas de cette option, un remplacement du modèle par un nouveau modèle plus adapté. Les autres points marqués « correction recommandée » ou « correction nécessaire » ne posent en revanche pas de difficulté technique. La question de la {{Tnavbar}} relève également de l'ergonomie.

Au final: c'est un modèle complexe sur lequel il faut prendre son temps, ne pas forcément chercher une accessibilité optimale, mais bien cibler les corrections réalistes et prioritaires. Maintenant, j'espère qu'Antaya, qui en est l'auteur, voudra bien nous apporter ses précieuses lumières Clin d'œil --Lgd (d) 9 mai 2008 à 09:02 (CEST)

[modifier] Modèle:Méta lien vers portail

Bonjour. Comme on le constate sur Wikipédia:Atelier accessibilité/Suivi des points améliorables, tous les modèles de portail ont le même problème : l'omission d'une description pour l'icône. Je vois trois solution pour résoudre cela, j'aimerais des avis avant d'aller discuter sur la page du modèle et de réaliser la modif.

  1. placer dans « Modèle:Méta lien vers portail » une description générique du genre « Page de description de l'icône utilisée pour le portail machin », que l'on peu créer à partir des paramètres fournis ;
  2. placer une description grâce au paramètre icône : à la place de |icône = Haricot.png, on peut mettre |icône = Haricot.png|Icône représentant un haricot (amha vaut mieux éviter) ;
  3. enfin ajouter au méta modèle un paramètre du genre description icône, solution précédente mais plus propre.

De très loin, la première solution est la plus simple.

Aussi, s'il est possible de savoir ce qu'il mieux de mettre comme texte de description se serait bien, est-ce vraiment mieux de mettre un « Page de description de » (cf. Wikipédia:Atelier accessibilité/Bonnes pratiques#Images décoratives). Merci. bayo 9 mai 2008 à 17:22 (CEST)

Je plussoie la première solution, avec quelque chose de concis, comme « icône du portail machin ».
J'étais au départ plutôt pour des liens très explicites sur toutes les icônes, effectivement comme « Page de description de l'icône...  », mais depuis, plusieurs tests personnels et discussions avec des utilisateurs aveugles m'ont définitivement mis en garde contre les alternatives trop verbeuses : dans un lecteur d'écran (ou tout bêtement dans un navigateur texte), le gain est très faible et il vaut mieux se fier à l'intuition de l'utilisateur, AMHA. Surtout dans un lecteur d'écran où la verbosité est un problème constant (par exemple, le débit de parole des lecteurs est considérablement plus rapide que celui de la parole humaine, ce qui surprend toujours quand on fait une démo : mais essayez de vous imaginez, comme à l'école, en train de tout « écouter d'un bout à l'autre » avant de pouvoir répondre ou agir, c'est très vite insupportable Mort de rire). ah, ce que je regrette que des questions de droit des marques et d'auteur interdisent de mettre ici des captures audios de rendu dans Jaws, comme je le fais IRL dans les évaluations d'accessibilité ^^ --Lgd (d) 9 mai 2008 à 17:32 (CEST)
J'ai fait une proposition de modification de Modèle:Méta lien vers portail implémentant la solution (1) dans Utilisateur:Cépey/test. Voyez Utilisateur:Cépey/Jura transclus ci dessous pour en tester l'effet sur un bandeau à trois liens. —C.P. 10 mai 2008 à 00:14 (CEST)
J'en profite pour demander : Actuellement, le bandeau est codé sous la forme « <div>icône1 lien1 icône2 lien2 ... </div> ». Est-ce que cela serait mieux ou moins bien de le coder sous forme de paragraphe « <p>icône1 lien1 icône2 lien2 ... </p> » ? —C.P. 10 mai 2008 à 00:32 (CEST)
Amha, se ne sont pas des paragraphes, donc non, ya pas de raison d'en mettre. bayo 10 mai 2008 à 00:37 (CEST)
Ici, le choix div ou p ne fera pas de différence significative en matière d'accessibilité. D'une manière générale, dans les cas limites « div ou p ? », c'est moins la sémantique qui permet de trancher que la lisibilité du rendu sans CSS (absence de marges verticales sur l'élément div dans les styles par défaut usuels des navigateurs).
Sinon, côté pertinence de la structure HTML, on pourrait plutôt dire qu'il s'agit d'une liste ul, mais l'impact sera là aussi plutôt réduit, et je ne pense pas que cela vaille la peine de retoucher le fonctionnement des modèles pour cela.
Par contre, je suis plus ennuyé par l'absence de tout espace, dans le code HTML produit, entre le lien icône et le lien texte : elle peut entraîner dans certaines configurations un rendu où les deux liens seront difficiles à distinguer (voir le problème des liens adjacents (RGAA), où le test 10.5.2 est invalidé). La configuration image et CSS désactivées peut sembler rare, mais elle se rencontre notamment chez des utilisateurs de loupe d'écran, où le résultat peut être quelque-chose comme « Icône du portail de la peinturePortail de la peinture ». L'ajout d'un espace (insécable si nécessaire) serait préférable.
Sinon, le test est concluant pour l'alternative textuelle. Cordialement, --Lgd (d) 10 mai 2008 à 05:06 (CEST)
J'ai corrigé le problème de l'espacement. J'ai aussi codé le bandeau sous forme de liste <ul> : le changement est très facile : seulement, avant de mettre à jour les modèles {{Portail}} et {{Méta lien vers portail}}, il faut ajouter une propriété CSS supplémentaire dans la feuille de style commune pour forcer les items de la liste à s'afficher en ligne (demande faite sur WP:DIMS#MediaWiki:Common.css 2) puis patienter quelques temps pour qu'elle se mette à jour dans le cache des navigateurs des lecteurs de WP. —C.P. 10 mai 2008 à 09:33 (CEST)
Je voyais le passage aux ul plus lourd, tiens. Parfait Clin d'œil --Lgd (d) 10 mai 2008 à 10:31 (CEST)
La mise à jour de Commons CSS est faite. bayo 10 mai 2008 à 12:19 (CEST)
Aussi pour l'image, si le seul objectif est de faire court, est-ce-que « Icône décorative » ne serait pas suffisant ? Ya plein de bandeau qui peuvent être patché comme cela. Merci. bayo 10 mai 2008 à 12:22 (CEST)
Non, « Icône décorative » ne décrit pas la cible du lien de façon suffisamment explicite : plusieurs portails sur la même page auront le même intitulé pour des cibles différentes . Il est difficile de trouver un compromis, mais « icône du portail machin » me semble le moins mauvais. --Lgd (d) 10 mai 2008 à 18:53 (CEST)

À cause d'un bogue de IE pour Windows, qui empêchait les liens vers portails de se répartir sur plusieurs lignes lorsque le contenu du bandeau est trop long, j'ai dû légèrement modifier mon code, ce qui requiert un ajustement de la feuille de style (WP:DIMS#MediaWiki:Common.css (bis)). —C.P. 12 mai 2008 à 18:03 (CEST)

Je pense qu'il est temps de mettre en place les nouveaux modèles. Il faudrait qu'un administrateur

  1. remplace Modèle:Méta lien vers portail par ceci : [4];
  2. remplace ensuite Modèle:Portail par ceci : [5].

—C.P. 15 mai 2008 à 16:39 (CEST)

C'est donc fait. bayo 15 mai 2008 à 18:49 (CEST)

Hum, désolé, mais je trouve le résultat très différent de ce qui a été décidé suite à Discussion Wikipédia:Prise de décision/Bandeaux de portail. S'agit-il d'une erreur de codage ou bien est-ce volontaire que maintenant les liens vers les portails apparaissent un par ligne (J'ai aussi codé le bandeau sous forme de liste <ul>) ? L'objectif de la présente discussion n'était-elle pas limitée à ajouter une description pour l'icône ? -- MHM (d)

Il n'y a pas de modification du rendu : il faut simplement rafraîchir le cache de ton navigateur qui continue à appliquer la version précédente de la feuille de style de Wikipédia (Ctrl-F5 sous IE, Shift-Ctrl-R sous Firefox, etc.) Cordialement, --Lgd (d) 15 mai 2008 à 21:12 (CEST)
Merci -- MHM (d) 22 mai 2008 à 08:36 (CEST)

[modifier] Ces maudites infobox

Pour info, quelques essais d'infobox avec une structure de tableau nettement plus accessible (caption, en-têtes th explicites dans tous les cas, plus de cellules de présentation avec un hr, etc.), et permettant de les décliner « ala V2 » ou de façon plus classique. A poursuivre, mais on peut sans-doute arriver à quelque-chose d'acceptable pour tout le monde, AMHA. Utilisateur:Lgd test/infobox (nécessite que vous importiez Utilisateur:Lgd test/infobox.css dans votre monobouc). --Lgd (d) 12 mai 2008 à 20:18 (CEST)

Ca semble marcher sur Safari aussi (3.1.1 sur OS 10.5.2)
MAC (d) 12 mai 2008 à 22:06 (CEST)
Petite erreur dans les styles : La police de caractère des cellules de l'infobox «classique» est trop petite : elle devrait être «95%» (selon MediaWiki:Common.css) — la taille de 90% est propre à la V2 (c'est même la première chose que j'ai contre la V2, mais c'est une autre histoire.). — À part ça, le rendu est bon avec Safari 1.3+ sur Mac. —C.P. 12 mai 2008 à 22:14 (CEST)
Le débat de style est HS dans la mesure ou chacun fait bien ce qu'il veut avec son monobook ; et que la taille du texte de la boite classique n'a pas plus de légitimité que celle de la v2. bayo 12 mai 2008 à 23:04 (CEST)
«Chacun fait bien ce qu'il veut avec son monobook» : ce n'est valable que pour les contributeurs inscrits qui savent comment le faire, voire qui savent qu'on peut le faire. — D'autre part, il n'est pas question ici de débat, mais de respecter le style par défaut actuel. —C.P. 12 mai 2008 à 23:12 (CEST)
Je vois un gros problème a la solution proposée pour remplacer hr. Le code pour les boites a champs masqués dans devenir très complexe. Au passage, je ne comprend pas bien pourquoi le border_ est appliqué a une cellule plutôt qu'a une ligne. bayo 12 mai 2008 à 23:34 (CEST)
Aussi, le hr a exactement le même rôle que les séparateurs de la boite « Tom Brady », a la seule différence qu'il n'y a pas un nom explicite (ou qu'il serait masqué). S'il y a une solution pour creuser dans ce sens, ce serait plus pratique, malgré les id, amha. bayo 12 mai 2008 à 23:57 (CEST)
Je n'avais pas pu tester hier sur Safari, voilà qui est rassurant (je n'étais pas certain du rendu des caption en particulier). Tout cela n'est qu'un premier jet quick and dirty, mais à mon avis:
  • les tailles de texte (valeurs temporaires actuellement, juste pour le test) seront de toutes façon ajustables au cas par cas pour chaque modèle d'infobox. Le modèle par défaut devrait éviter la taille vraiment minimale qui est actuellement celle des infobox V2, mais sans empêcher les ajustements aux moins nécessaires en cas de contenus trop longs sans retour possible à la ligne, par exemple. Sans compter qu'un consensus sur une taille unique me semble illusoire.
  • le code pour remplacer hr est très améliorable, avec plusieurs pistes uniquement CSS à suivre (par exemple, en utilisant les sélecteurs d'éléments descendants et adjacents, si on accepte de se passer de ces bordures dans IE6) . Au-delà de l'accessibilité (pas de cellule vide ou d'en-têtes au libellé souvent artificiel, puisque non nécessaire à l'affichage), c'est aussi un souci de simplicité pour les auteurs d'infobox qui partiraient de ces modèles. Autant éviter à chaque fois que possible:
    • les id / headers, peu maniables et sources potentielles d'erreurs
    • les contenus masqués destinés uniquement aux lecteurs d'écran: leur rôle est tout de même assez obscur pour beaucoup de contributeurs, et ils seront le plus souvent ignorés ou mal rédigés lors de la création de modèles d'infobox. --Lgd (d) 13 mai 2008 à 09:10 (CEST)
Désolé, je n'avance pas très vite, c'est un peu la presse en ce moment. Mais Utilisateur:Lgd test/infobox a été mis à jour avec une gestion uniquement CSS du cas « avec séparation horizontale  » (l'infobox cinéma du test) :
  • Prix à payer : une règle CSS avec des sélecteurs lourds (notamment pour compenser les limitations d'IE) et pas de séparation dans IE6 - un nombre fixe de « groupes de lignes » (5 dans le test).
  • avantages: un minimum d'expressions conditionnelles dans le modèle - la présence des bordures est indépendante de la présence/absence des lignes d'un groupe ou du groupe entier.
Sinon, pour préciser la démarche, le div englobant l'infobox permet de contourner les bugs divers de navigateurs sur la mise en forme du caption et de régler des problèmes de bordures. Il permet aussi de sortir du tableau certains contenus comme des images ajoutées en fin d'infobox, ou de combiner plusieurs tableaux de données pour des infobox complexes, et éviter les tableaux imbriqués. Enfin, l'idée général est qu'un changement dans les classes appliquées à une infobox suffise autant que possible à la faire passer d'un type de présentation à un autre.
Je suis toujours preneur de tests sous Safari, mon mac est en rade pour l'instant. --Lgd (d) 18 mai 2008 à 10:07 (CEST)
Nouvel essai sur Safari 3.1.1 sur Mac OS 10.5.2.
Par contre ça ne marche pas du tout sur Firefox 2.0.0.14 sur le même OS. MAC (d) 18 mai 2008 à 12:51 (CEST)
Humpf, FF est fatiguant, dans le genre pas vraiment multiplateforme. C'est le rendu d'IE6 à peu près. Est-il dramatique ? (C'est de la gracefull degradation, pour tout dire). --Lgd (d) 18 mai 2008 à 14:33 (CEST)
Tu ne fais pas confiance au Safari Windows ? bayo 22 mai 2008 à 10:27 (CEST)

[modifier] Double carte de géolocalisation, Projet:Communes de France/Infobox communes de France

Petit état des lieux du projet de double carte de localisation qui se prépare dans Discussion Projet:Communes de France :


Evaluation accessibilité / solutions
Contexte utilisateur Résultat Commentaire
Sans javascript
  • Deux cartes l'une en dessous de l'autre
  • La géolocalisation n'apparaît que sur la première
 Fait dans Utilisateur:Lgd test/test rendu Géoloc dynamique
Sans CSS
  • Deux cartes l'une en dessous de l'autre
  • L'image du pointeur de géolocalisation s'affiche en dessous des deux cartes, l'information est perdue (pointeur CSS)
 Stop non corrigeable (nécessite le passage à des images complètes intégrant le pointeur)
lecteur d'écran
  • chaque carte est une image-lien sans alternative explicite
  • le pointeur est une image-lien sans alternative explicite
 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
  • lien javascript de passage d'une carte à l'autre non explicite
 Fait le lien reprend l'alt de chacune des deux images de cartes, du type: "Foo sur la carte administrative"
Désactivation des couleurs
  • Pointeur CSS, donc disparition du pointeur
 Stop non corrigeable (nécessite le passage à des images complètes intégrant le pointeur)
Agrandissement de la taille de caractères
  • Rendu correct
 Fait accessible
Accès au clavier
  • lien javascript de passage d'une carte à l'autre fonctionnel
 Fait accessible
Niveaux de contrastes
  • l'image de pointeur offre un niveau de contraste suffisant sur les deux arrières-plans
 Fait 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 Mort de rire
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)

[modifier] 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 Clin d'œil). 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:
{{{nomrace}}}
[[Image:{{{Image}}}|250px|center|nomrace]]
Race de ???? issue de l'espèce :

Nom binominal ???
auteur, date

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 ...
Logo de Wikicommons 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 :

Nom binominal ???
auteur, date

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 caption en plus de scope) et plus efficace en terme de séparation structure/présentation, ce qui permet de varier le rendu plus facilement.
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, utiliser caption pour 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 shiml smilibli Schmilblick 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)
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)

[modifier] 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 Mort de rire). 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)

[modifier] 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 Mort de rire) 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 Clin d'œil.
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 Espiègle — 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 Clin d'œil --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)

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)

[modifier] 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:

// 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;
}

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)

[modifier] 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 Mort de rire 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)

[modifier] Wikipédia:Accessibilité

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 Mort de rire --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 Mort de rire Ouàlà ouàlà... --Lgd (d) 4 juin 2008 à 20:22 (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 Mort de rire -Lgd (d) 8 juin 2008 à 13:40 (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.) :

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.

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ù ? Tire la langue 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 toutClin d'œil --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)

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 Clin d'œil --Lgd (d) 8 juin 2008 à 21:57 (CEST)

[modifier] 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)

[modifier] 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)

[modifier] 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 Mort de rire --Lgd (d) 11 juin 2008 à 22:18 (CEST)