Aller au contenu

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

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.

Cette page de discussion est une archive.

Pour intervenir sur les discussions actuelles ou pour en lancer une nouvelle, allez sur la page de discussion actuelle.

Modèle lang et noms scientifiques pseudo latins

[modifier le code]

Bonjour, votre avis serait utile dans cette conversation à propos de {{lang}} appliqué aux noms scientifiques. Merci d'avance. --Amicalement, Salix [Converser] 20 janvier 2013 à 16:41 (CET)

Cette question est très technique : il faut être prudent à l'égard des avis généraux et instinctifs que l'on peut avoir a priori, sans connaître précisément ce type de problématique. Les réponses peuvent sembler déroutantes.
La question a été notamment évoquée au sein des organismes compétents, la WAI ([1] ) et l'IETF ([2]) en 2003. Il en ressort les éléments suivants :
  • avant tout, le tag de langue "la" (latin) est pertinent pour ce vocabulaire, comme l'ont souligné les divers intervenants à cette occasion :
    • Il s'agit de latin contemporain, quelle que soit l'origine des termes, au même titre par exemple que le latin du Vatican qui abonde en termes nouveaux obtenus par des procédés similaires.
    • La question de la prononciation dans un lecteur d'écran se conclue en faveur du latin, au moins dans un contexte français : pour les termes dont la prononciation latinisée n'est pas satisfaisante, ne pas les taguer en latin (prononciation francisée) n'apporte aucune amélioration. Mais pour ceux dont la prononciation latinisée est satisfaisante, ne plus les tagueur en latin dégrade le résultat.
    • La prononciation dans un lecteur d'écran n'est qu'un cas de figure parmi d'autres à prendre en compte. Les questions liées notamment aux traducteurs automatiques et aux outils de correction orthographique se concluent également en faveur du latin : considérer ces contenus comme du français n'apporte aucune amélioration et entraîne au contraire des dégradations pour une partie du lexique dont la latinisation est plus évidente.
  • Une proposition de tag de langue spécifique pour ce lexique a été émise en 2003. Elle a été rejetée : il ne s'agit pas d'une langue, mais d'un lexique technique, comme il en existe de nombreux autres dans le même registre. Il n'y a à l'heure actuelle aucun élément nouveau qui pourrait soutenir une nouvelle proposition en ce sens : une telle proposition aurait très peu de chance d'aboutir si elle était renouvellée.
  • l'éventualité d'une extension au tag de langue "la" a été également évoquée. Par exemple, la-sci pour dire qu'il s'agit de latin, mais scientifique. Elle n'a pas eu de suite et a peu de chances d'en avoir : les bénéfices mesurables d'une telle extension n'ont pas été mis en évidence par rapport à son absence. Elle n'est pas d'une utilité probante s'il s'agit d'indexer du contenu par rapport à d'autres solutions. Elle n'apporte pas de possibilité concrète d'amélioration du traitement de ces contenus par des outils tels que la traduction, la correction orthographique ou la synthèse vocale. Elle poserait par ailleurs de lourds problèmes de délimitation du champ d'application d'une telle extension (en particulier pour la borne chronologique à partir de laquelle un texte pourrait être considéré comme étant en la-sci).
D'autre part, pour un éventuel traitement spécifique de ces termes répondant à un besoin interne au sein de Wikipédia, une adaptation du tag de langue n'est pas nécessaire. Il suffit d'appliquer une classe HTML spécifique en complément de l'attribut lang="la".
En bref : l'utilisation du modèle {{lang|la|XXX}} est utile et pertinente, au moins faute de mieux (si tant est que l'on puisse un jour faire mieux). Si on souhaite spécifier davantage ces termes, il faut recourir à un modèle ajoutant par exemple une classe dédiée, mais qui continue à taguer en latin. — Le message qui précède, non signé, a été déposé par l'IP 90.56.134.127 (discuter)
Non, les noms scientifiques ne sont PAS du latin contemporain. Ce sont des noms scientifiques latinisés partiellement (souvent seulement un 'us' ou 'um' ou 'a' en fin de mot). Je rappelle que ces noms scientifiques contiennent souvent du grec ou des langues indigènes (Beaucoup de jeunes biologistes introduisent le nom d'un de leur directeur de recherche).
Dans la discussion dans le café des biologistes il y a un consensus pour dire que ce n'est pas raisonnable de les prononcer en latin.
Chaque contributeur ne va pas, non plus, décider 'Ce nom sci semble bien prononcable en latin' alors je vais mettre un tag. Ca aboutirait à un bazar sans nom puisque chaque contributeur aurait une opinion différente. Liné1 (d) 23 janvier 2013 à 10:41 (CET)
Liné1, tu te trompes : ce sont bien des noms considérés comme latins (en tout cas par les codes de nomenclature), et le consensus que tu décrit n’existe pas. 90.44.92.66 (d) 23 janvier 2013 à 20:00 (CET)

Infobox à mettre en accessibilité

[modifier le code]

Bonjour,
Dans le cadre d'un vote au label BA de l'article Équipe d'Éthiopie de football, on m'a signalé que l'infobox {{Infobox Équipe nationale de football}} n'était pas "accessible". Quelles sont les modifications à y apporter pour que tout soit conforme ? Merci par avance, Queix አናገረ 31 janvier 2013 à 10:13 (CET)

Tableaux et sous-totaux

[modifier le code]

Salut !

Je ne suis décidément pas doué avec l’accessibilité des tableaux complexes… Émoticône Aussi, je voulais vous poser quelques petites questions : j’ai tenté de retravailler la forme de Lycée_Henri-IV#Structure_p.C3.A9dagogique, et j’ai donc créé ces trois tableaux :

Collège (année 2009 – 2010)
Niveau Nombre de classes Nombre d’élèves
6e 5 170
5e 5 153
4e 5 171
3e 6 171
Total 21 665
Lycée (année 2009 – 2010)
Niveau Nombre de classes Nombre d’élèves
2de 7 268
1re 8 284
Tle 8 279
Total 23 831
Bilan (année 2009 – 2010)
Cycle Nombre de classes Nombre d’élèves
Collège 21 665
Lycée 23 831
Supérieur 8 279
Total 25 1131

Toutefois, plusieurs questions me taraudent : d’une part, est-ce sémantiquement correct de mettre la mention « total » dans la colonne « niveau » ? Puisque « total » n’est, contrairement à « sixième » par exemple, pas un niveau… Ensuite, peut-on baliser les totaux comme des scope="col", ou faut-il utiliser un autre moyen pour les faire ressortir ? Enfin, est-il possible de fusionner ces trois tableaux simples en un tableau complexe avec des sous-totaux, ou est-ce que ça pose des problèmes de sémantique ?

Cordialement Pic-Sou 3 février 2013 à 21:54 (CET)

Bon, déjà un truc qui me choque : tu mets, par exemple, un ! scope="col" | 1131 . Non, il faut comprendre, pour résumer, que le scope="col" est un titre de colonne donc ce n'est pas bon.
Le total ne devrait effectivement pas être situé sous le niveau mais c'est une erreur qui n'est pas si grave comparé à la complexité du code si on veut bien faire.
Pour reprendre ton premier tableau il faut, à minima:
Collège (année 2009 – 2010)
Niveau Nombre de classes Nombre d’élèves
6e 5 170
5e 5 153
4e 5 171
3e 6 171
Total 21 665
plus (trop ?) complexe, il faut gérer avec les "ID" et "HEADERS". Un exemple :

{|
|+Tableau explicatif
! id="saison" | Saison
! id="équipe" | Équipe
|-
| headers="saison" | 1988-89 || headers="equipe" | Bruins
|-
| headers="saison" | 1990-91 || headers="equipe" | Pen's
|} --'toff [discut.] 3 février 2013 à 22:33 (CET)

La complexité ne me gène nullement, ce qui compte, c’est de bien faire… Mais serait-il possible de mettre dans ce cas le sous-total dans le header ? Cordialement --Pic-Sou 3 février 2013 à 23:03 (CET)

Ajout du comte Nemoi – Pitié les gens, évitez d’user d’ids, ça va donner n’importe quoi. Genre, des id="équipe" et des headers="equipe", ou des ids répétés dans la page. Traitez en scope=, et la ligne de totaux comme une ligne normale avec un style adapté.

Collège (année 2009 – 2010)
Niveau Nombre de classes Nombre d’élèves
6e 5 170
5e 5 153
4e 5 171
3e 6 171
Total 21 665

MediaWiki bloque les tableaux plus complexes, donc on nefusionne pas. Ce 4 février 2013 à 09:53 (CET).

✔️ Done, merci ! Émoticône --Pic-Sou 6 février 2013 à 20:02 (CET)

Union des sociétés de gymnastique de France

[modifier le code]

Matpib nous souligne que l'accessibilité de l'article cité en référence et proposé au label BA laisse à désirer, en particulier quant à ses illustrations. Quelqu'un peut-il nous venir en aide sur ce point technique qui dépasse nos compétences ? Et également pour les deux tableaux qu'il estime peu conformes ? Merci d'avance et bon dimanche.--Claude PIARD (d) 24 février 2013 à 14:20 (CET)

C'est fait ! J'ai laissé un petit mot dans la page de débat. Litlok (m'écrire) 24 février 2013 à 15:11 (CET)
Manquait aussi les titres dans les tableaux Émoticône --'toff [discut.] 24 février 2013 à 18:48 (CET)
Oh. Comment ai-je pu oublier Oh ! ? Litlok (m'écrire) 24 février 2013 à 20:58 (CET)
Tu me copieras 100 fois : je n'oublierai pas d'accessibiliser les titres des tableaux ! Émoticône --'toff [discut.] 24 février 2013 à 22:50 (CET)

Tailles images infobox V3

[modifier le code]

Une discussion où il est question du lien éventuel entre accessibilité et largeur d'image d'infobox fonction ou pas de la largeur d'infobox est en cours ici : Discussion modèle:Infobox V3#Tailles images V3. — Oliv☮ Éppen hozzám? 25 février 2013 à 10:11 (CET)

Modèle:Cf. et lang la

[modifier le code]

Bonjour,

Un peu dans le genre de la discussion ci-dessus sur le #Modèle lang et noms scientifiques pseudo latins, doit-on considérer que l’abréviation « cf. » est latine ou non ? Et doit-on utiliser {{lang}} sur {{Cf.}} ?

J’ai posé la question à Nnemo (d · c · b) qui a récemment ajouté le modèle {{lang}} mais je n’ai pas eu de réponses… Je viens donc ici chercher vos lumières.

Cdlt, Vigneron * discut. 26 février 2013 à 16:36 (CET)

Je te conseille la lecture de Discussion modèle:Etc./Suppression#Avis non décomptés : Ce sont aux lecteurs d'écran (puisque c'est à eux que l'on pense ici) de savoir reconnaître une telle abréviation ; de toute façon si ce n'était pas le cas, « cf. » ne se prononcerait pas « confer », (mais « kfeuh » ? Émoticône) qu'on l'estampille français ou latin. Je pense donc que le {{lang|la}} est juste inutile, mais pas gênant. Totodu74 (devesar…) 27 février 2013 à 12:29 (CET)

Le modèle Notes de jeu vidéo

[modifier le code]

Bonjour. Il est indiqué sur sa page de documentation que Modèle:Notes de jeu vidéo pose des problèmes d'accessibilité. Savez-vous à quoi c'est dû ? Est-ce parce qu'il génère un tableau et que ceux-ci sont rendus avec difficulté par les lecteurs pour malvoyant ou est-ce simplement parce qu'il à des défauts de conception ? Pensez vous qu'il puisse être amélioré ? Si oui comment ? Son usage étant vivement conseillé par le Projet:Jeu vidéo, il est souvent utilisé, en particulier sur les articles labellisés. Ça serait donc très embêtant qu'il gène la lecture des articles. --Sylvhem Discuter 1 mars 2013 à 01:57 (CET)

Bonjour. Les tableaux ne sont pas rendus avec difficulté quand il sont bien conçus. En l'état, celui-là ne l'est pas (le bandeau date d'ailleurs de la création du modèle en 2008, c'est pas jeune...) Vite fait, deux points qui sautent aux yeux :
  • Deux tableaux en 1 : les deux sections sont à séparer (la partie compilation est un 2e tableau)
  • Simili titres et sous-titres grâce à la fusion des colonnes : à ne pas faire
En bref, tableau simple dont la correction ne semble pas compliquée. Mais il faudrait séparer en deux tableaux (si je dis pas de bêtise), et là, il faudrait l'aval du projet.--'toff [discut.] 1 mars 2013 à 07:54 (CET)
J'ai commencer la transformation, dès que j'ai le temps je la fini. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 1 mars 2013 à 14:42 (CET)
Merci pour vos retours et votre disponibilité. Je ne pense pas que séparer ce modèle en deux gène qui que ce soit sur le principe. Je vais néanmoins avertir le projet Jeu vidéo de l'existence de cette discussion, ne serait-ce que parce qu'une séparation de ce modèle en deux demanderait de toucher à pas mal d'articles. --Sylvhem Discuter 1 mars 2013 à 21:58 (CET)
Non, non. On ne parle pas de séparer le modèle en deux mais le tableau en deux. (Oui je sais j'ai pas été clair...) Il n'y aurait aucune mise a jour a faire sur les article : ça impacterait juste la présentation. (J'espère que j'ai été plus clair ?) --'toff [discut.] 1 mars 2013 à 23:00 (CET)
Ce n'est pas toi qui n'a pas été clair, c'est moi qui n'ai pas été suffisamment attentif. J'ai lu deux tableaux et j'en ai conclu qu'il fallait séparer le modèle en deux. En tout cas, j'ai averti le projet Jeu vidéo qu'une discussion se tenait ici, attendons leurs avis. --Sylvhem Discuter 2 mars 2013 à 15:29 (CET)

Sacré lifting ! L'important était que l'accessibilité soit améliorée, mais le résultat est aussi très agréable du point de vue graphique. Un petit bémol tout de même. Même si une section n'est pas remplie (par exemple, si il n'y a aucune note pour la presse papier), l'intitulé de cette dernière apparaît quand même (comme ici). En tout cas, merci pour ton travail Ju gatsu mikka.--Sylvhem Discuter 3 mars 2013 à 17:30 (CET)

Je connais le problème et l'avais déjà remarqué, mais j'ai du mal à voir comment le résoudre sans un code trop lourd, je cherche et dès que j'ai une idée, je la teste. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 3 mars 2013 à 18:01 (CET)
c'est bon. (Nous sommes désolé de vous apprendre que la signature a été suspendue pour faute professionnelle) 3 mars 2013 à 18:10 (CET)

Modèles Tableau Coupe...

[modifier le code]

Je suis en train de me pencher sur la conception des tableaux de tennis. Mon objectif est de les reconstruire avec Lua pour résoudre les problèmes de performances du aux ajout de calcul que j'ai ajouter l'an dernier.

Au passage, il est peut être possible de revoir la structure ce ces tableaux, pour facilité la programmation et peut-être améliorer l’accessibilité. Voici l'état des mes réflexions :

version actuelle
1er tour 1/4 de finale Finale
1/2 finale
Joueur 1 (1) 6 4 6    
Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6  
  Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6
 
Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6  
Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6    
 
Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6
  Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6
 
Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6    
 
Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6  
  Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6
 
Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6    
 
Joueur 2 (Q) 6 6 2  
Joueur 1 (1) 6 4 6
  Joueur 2 (Q) 6 6 2
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 6 2
 
version proposée
1er tour
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 4 6 2
Joueur 3 (1) 6 4 6
Joueur 4 (Q) 4 6 2
1/4 de finale
Joueur 1 (1) 6 4 6
Joueur 3 (Q) 4 6 2
1er tour
Joueur 5 (1) 6 4 6
Joueur 6 (Q) 4 6 2
Joueur 7 (1) 6 4 6
Joueur 8 (Q) 4 6 2
1/4 de finale
Joueur 5 (1) 6 4 6
Joueur 7 (Q) 4 6 2
1/2 finale
Joueur 1 (1) 6 4 6
Joueur 5 (Q) 4 6 2
1er tour
Joueur 9 (2/WC) 6 4 6
Joueur 10 (Q) 4 6 2
Joueur 11 (1) 6 4 6
Joueur 12 (Q) 4 6 2
1/4 de finale
Joueur 9 (2/WC) 6 4 6
Joueur 11 (Q) 4 6 2
1er tour
Joueur 13 (1) 6 4 6
Joueur 14 (Q) 4 6 2
Joueur 15 (1) 6 4 6
Joueur 16 (Q) 4 6 2
1/4 de finale
Joueur 13 (1) 6 4 6
Joueur 15 (Q) 4 6 2
1/2 finale
Joueur 9 (2/WC) 6 4 6
Joueur 13 (Q) 4 6 2
Finale
Joueur 1 (1) 6 4 6
Joueur 9 (2/WC) 4 6 2
 

Ce n'est certainement pas parfait, mais j'aimerai savoir si je vais dans le bon sens ou si je fait fausse route. Merci de me dire ce que vous en pensez.

— Zebulon84 (d) 3 mars 2013 à 20:48 (CET)

Vraiment personne n'a d'avis ? — Zebulon84 (d) 8 mars 2013 à 15:34 (CET)
Je pense que c’est effectivement un peu mieux. Peut-être ajouter des <caption> (cachés) à tous les tableaux de données pour préciser à quoi ils se rapportent (Match no 1 du premier tour, etc.) ? — Ltrl G☎, le 22 avril 2013 à 11:38 (CEST)
Merci de cet avis tardif. On peu effectivement ajouter quelques précisions cachées.
Cependant puisqu'il n'y avait pas de réponse j'ai considéré que les deux versions étaient à peu près équivalentes. Comme des tests complémentaires ont mis en évidence des problèmes d'alignements lorsque des cellules sont déformées par du texte trop long (J'ai modifié le joueur 9 sur la "version proposée" ci-dessu pour mettre ce problème en évidence). Comme je n'ai pas réussi à résoudre ces problèmes simplement, je suis resté sur la conception actuelle du tableau. Le nouveau code lua est en place depuis un mois. Ceci-dit si quelqu'un à une solution pour résoudre ce problème d'alignement, je veux bien retravailler ces modèles. — Zebulon84 (d) 22 avril 2013 à 20:43 (CEST)
Je propose plutôt un code comme suit, avec une sémantique plus claire à mon avis (un tableau avec une ligne par phase, dans laquelle chaque case contient une rencontre sous forme d'un tableau imbriqué) et un style facilement passable dans commons.css (les div codant les branches sont à remplacer par du code CSS en :before et :after. Ambigraphe, le 1 mai 2013 à 21:29 (CEST)
version d'Ambigraphe
1er tour
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
1/4 de finale
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
1/2 finale
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
 
Finale
Joueur 1 (1) 6 4 6
Joueur 2 (Q) 6 4 6
 
Je vais voir ce que l'on peut faire dans cette voie la, mais pour le moment ce n'est pas encore ça : je suppose que tu utilises Firefox ou Opera, mais si tu regardes le rendu de ce code avec un autre navigateur c'est en vrac. — Zebulon84 (d) 2 mai 2013 à 03:34 (CEST)

{{Infobox V3/Image}}

[modifier le code]

J’avoue avoir du mal à comprendre en quoi l’alternative par défaut est accessible. À savoir : « Description de cette image, également commentée ci-après » s’ il y a une légende ou « Description de l'image nom de l’image » sinon. Pour moi, ça ne veut rien dire. J’aimerais avoir d’autres avis à ce sujet. — Ltrl G☎, le 22 avril 2013 à 11:31 (CEST)

Liens [modifier] des sections

[modifier le code]

Les développeurs s’apprêtent à changer l’emplacement des liens [modifier] sur les titres de section, passant d’un lien à l’extrême droite positionné en HTML avant l’en-tête à un lien situé juste à droite du titre positionné en HTML après dans ce titre. C’est-à-dire très proche de ce que fait chez nous le script setModifySectionStyle dans MediaWiki:Common.js -- mais je sais pas si c’est strictement identique. Quelqu’un pourrait regarder pour retirer ou l’adapter ce script ? En tous cas, ça fera le bonheur des lecteurs d’écran de façon native sans hack JavaScript. (annonce, explication complète) ~ Seb35 [^_^] 30 avril 2013 à 13:31 (CEST)

Etant donné que Dr Brains (d · c) à modifié le Common.css en prévision de cette évolution, il va certainement adapter ou supprimer le code JavaScript associé en fonction de ce qui est nécessaire. — Zebulon84 (d) 30 avril 2013 à 14:17 (CEST)

Tableau accessible ?

[modifier le code]

Salut. J'ai un petit doute sur l'accessibilité d'un tel tableau : Jeux olympiques d'hiver de 1988#Calendrier malgré la légende mais peut-être me trompe-je ? 'toff [discut.] 12 mai 2013 à 07:21 (CEST)

Quelqu'un a une idée ? 'toff [discut.] 30 mai 2013 à 17:31 (CEST)
Bonjour, le gadget d'accessibilité ne signale rien au niveau de ce tableau (mais il voit, comme toujours, rouge au niveau de l'infobox qui n'est sans doute pas passée au format V3). -- Amicalement, Salix [Converser] 30 mai 2013 à 19:46 (CEST)
J'utilise le gadget aussi donc j'ai les mêmes infos que toi Émoticône Je m'interroge sur l'accessibilité des cases colorées : est-ce que la légende suffit ? 'toff [discut.] 1 juin 2013 à 09:54 (CEST)
Oui, la légende suffit. La couleur est ici un autre moyen de fournir l'information. En deux minutes, je n’ai rien vu de bloquant sur ce tableau (les abréviations des noms des jours pourraient être explicités ou placées dans des abréviations discrètes, mais ce n'est pas rédhibitoire). Pour plus de détails sur cette histoire de légende, il ne faut pas tomber dans la surqualité : les symboles utilisés ne sont pas explicites, certes. Mais ils ne le sont pour personne : un utilisateur ne dépendant pas d'un lecteur d'écran doit lui aussi, au moins au début, faire des aller-retours vers la légende. Litlok (m'écrire) 1 juin 2013 à 15:37 (CEST)
Je penchais moi aussi pour cette vision de la chose mais je préférais avoir l'avis d'un expert. Merci pour ta réponse. 'toff [discut.] 2 juin 2013 à 07:54 (CEST)

Liens internes, images ou modèles dans les titres de section

[modifier le code]

Bonjour,

Dans cette section de Wikipédia:Accessibilité, il est conseillé de ne pas mettre de liens internes dans les titres de section. Pourtant ce conseil n'est pas repris dans Wikipédia:Atelier accessibilité/Bonnes pratiques. Quelqu'un pourrait-il m'expliquer pourquoi cela est nécessaire pour l'accessibilité ? Une source éventuellement ? J'aimerais bien savoir également si possible s'il en est de même pour les modèles et les images dans les titres de section, ou encore les abréviations (informations au survol d'un mot avec la souris). Vous pouvez voir un exemple d'article du Wiktionnaire, où cette pratique est une norme : wikt:manger, si ça permet de rendre la question plus concrète.

En vous remerciant par avance, Automatik (d) 5 juillet 2013 à 14:01 (CEST)

Bonjour,
À part le fait que placer des liens internes (ou externes, d'ailleurs) dans les titres de section pourrait induire une sorte de collision entre deux modes de parcours (par têtes de chapitres/section et par liens), ou de possibles complications avec les attributs title automatiquement ajoutés par MediaWiki dans les liens internes, je ne vois pas en quoi cela serait un obstacle pour la consultation des pages.
Pour les modèles, images et abréviations, le cas est rigoureusement le même qu'au fil du texte. Si le modèle produit du code HTML accessible, l’alternative textuelle de l’image est correctement renseignée (voire explicitement vide), si l'abréviation est utilisée à bon escient cela ne pose pas de problème a priori. Litlok (m'écrire) 19 juillet 2013 à 14:21 (CEST)
Bonjour et merci, c'est assez rassurant de voir que c'est moins contraignant que prévu. Finalement, seule l'alternative est à ajouter. Merci encore. Automatik (d) 19 juillet 2013 à 14:56 (CEST)

Alternative textuelle et infobox

[modifier le code]

Bonjour,

Sauriez-vous me dire où on peut mettre une alternative textuelle dans une info box ? (par exemple pour le phare de voiture dans celle de cet article auquel je collabore souvent ?) J'aimerais aussi savoir s'il y a un risque à faire « trop long » dans le paramètre alt (vous pouvez notamment regarder les descriptions que j'ai faites sur ce même article pour me dire si elles posent problème).

Je passe mon week-end avec une de mes proches, aveugle de naissance qui n'était jamais allée sur Wikipédia avant hier soir et j'en profite pour voir comment elle perçoit les articles où je contribue. C'est une chose de lire les pages d'accessibilité, c'en est une autre que de découvrir que quand on écrit « L'[[Italie]] » sa synthèse vocale lit « L-Lien-Italie ». Même si je sais que ce n'est qu'une personne et donc pas représentatif, cela me permet de me faire une idée vraiment concrète avec quelqu'un qui me dit « J'y arrive/J'y arrive pas. » Bien sûr s'il y a des problèmes, je les indiquerai ici. (Je peux déjà vous dire que l'outil de retour des lecteurs est ce qu'elle a trouvé de plus facile à utiliser, et sans aucune explication de ma part, sachant que je lui avait demandé de lire un article sur une résistante et qu'elle a fait des études d'Histoire. Elle a fait un long commentaire pointant ce qu'elle voyait comme lacunes de l'article, toute seule et sans aucune difficulté. S'il lui avait fallu dénicher seule la page de discussion, je crois qu'elle aurait mis deux ans.

Merci beaucoup.--Soboky (d) 19 juillet 2013 à 12:22 (CEST)

Je viens de rajouter un champ alternative dans le modèle utilisé. Pour le texte de l'alternative, oui, il ne faut pas faire trop long. A priori, 120 caractères est un maximum conseillé. Cordialement. 'toff [discut.] 19 juillet 2013 à 14:36 (CEST)
Merci, mais pour l'infobox, si je trouve ton diff sans problème, ne vois pas à quoi il correspond sur la page. Peux-tu être plus clair s'il te plait ?--Soboky (d) 19 juillet 2013 à 15:09 (CEST)
conflit d'éditEn utilisant le modèle, le risque est minimisé. Ici, par exemple, l’alternative textuelle est automatiquement remplie par « "Description de cette image, également commentée ci-après », qui est un moindre mal (effectivement, quand on clique sur l’image on arrive bien, sur Commons, sur une page de description de l’image, et après cette dernière, dans l’article, se trouve bien une légende si le modèle est correctement utilisé).
Je viens aussi de regarder les alternatives que tu avais placées. La première est impeccable (bâtiment pyramidal etc.) La seconde (sur la photo de Skolimowski) serait inutile dans un monde parfait : il s'agit en effet d'une image décorative, pour laquelle il faudrait une alternative vide. Cependant, MediaWiki insérant automatiquement un lien sur toutes les images, il faut quand même renseigner un alt. Le alt que tu as ajouté n'apporte aucune information, ou plutôt, n’apporte d'information que sur la tenue vestimentaire de la personne. Si le but ici est de montrer à quoi ressemble la personne, alors il faudrait plutôt décrire son visage (oui, je sais, c'est plus difficile !). Cela nous amène à la question de la longueur des alt. La Bonne Pratique correspondante demande de se limier à 120 caractères. En fait, les recommandations officielles demandent de faire aussi concis que possible, et il n'y a pas de limite chiffrée. Cependant, les plages Braille ont des longueurs standardisées (standard de facto) de 40, 60 ou 80 caractères. Donner une limite à 120 permet de cantonner l'alternative à deux ou trois longueurs de plage. Ce n'est pas une catastrophe si l’alternative fait par exemple 130 caractères s'il est impossible de faire plus court, mais il vaut mieux donc éviter... Litlok (m'écrire) 19 juillet 2013 à 14:40 (CEST)
Je comprends. C'est clair que pour décrire les hommes, j'ai l'impression d'avoir moins de possibilités que pour les femmes (coiffure, maquillées ou pas...). Et tout ça est vite subjectif (je trouve que la photo de Skolimowski est très paisible mais j'imagine que je ne peux pas mettre ça. En revanche dire qu'il a « l'air calme » ou « l'air serein », peut-être ?) Merci beaucoup.--Soboky (d) 19 juillet 2013 à 15:09 (CEST)

Diagrammes d'échecs

[modifier le code]

Bonjour,

existe-t-il une bonne pratique concernant les diagrammes d'échecs ? Je viens de lire le début de l'article Partie anglaise avec une synthèse vocale. Le diagramme qui débute l'article n'était qu'une simple liste de cases, du haut jusqu'en bas (« Lien graphique a8, lien graphique b8, lien graphique c8... » jusqu'à « Lien graphique g1, lien graphique h1 » sans aucune indication des pions ou des pièces. Comment faut-il faire pour qu'il décrive aussi la place des pièces ? Merci.--Soboky (d) 24 juillet 2013 à 16:56 (CEST)

C'est un cas particulier. Formellement, on doit considérer à mon avis qu'il s'agit de ce qu'on appelle un « tableau de mise en forme ». À ce titre, il respecte les normes en usage : pas de caption, pas de cellule d'entête. Cela dit, pour les informations qui y figurent, il faudrait effectivement amender le modèle pour que les alternatives textuelles des cases correspondent à leur contenu : case noire vide, case blanche avec fou blanc, etc. mais pour le moment je ne vois pas trop comment faire. Litlok (m'écrire) 24 juillet 2013 à 17:27 (CEST)
Dommage, des aveugles qui jouent aux échecs, c'est quand même relativement courant...--Soboky (d) 24 juillet 2013 à 18:56 (CEST)
Oui. Mais il faudrait une « révolution » dans le fonctionnement de cette classe de modèle, et cela ne peut s'improviser. Je vois à peu près comment on pourrait faire, mais pour le moment la solution la plus simple que j’entrevois consiste en un appel à Lua (quand je parlais de révolution...). Litlok (m'écrire) 24 juillet 2013 à 22:42 (CEST)
✔️ Fait pour {{Diagramme d'échecs}}, en utilisant un sous-modèle, {{Diagramme d'échecs/Intitulés}}
Ce dernier est réutilisable dans les autres diagrammes d'échecs (petit, 8x10, 6x6, Alice).
Toutefois, pour des questions de performances, ce modèle {{Diagramme d'échecs/Intitulés}}, voire tous les modèles de diagramme (pas seulement d'échecs), gagneraient à utiliser Lua.
⇨ Dr Brains ∞ Consultation ∞ 25 juillet 2013 à 23:02 (CEST)
Merci, c'est ce à quoi je pensais mais je n’avais pas voulu me lancer dans un machin aussi usinagazesque Émoticône Litlok (m'écrire) 25 juillet 2013 à 23:29 (CEST)

Lang : script subtag

[modifier le code]

Les subtag d'écritures sont-ils nécessaire pour l'accéssibilité ?

Lorsque je vois Crna Gora et Црна Гора, sachant que c'est du serbe je n'ai pas besoin de regarder le code pour savoir que le premier est en écriture latin et le deuxième en cyrilique. Les navigateurs doivent le savoir encore plus rapidement que moi par les caractères utilisés.

Est-il vraiment nécessaire d'écrire {{lang|sr-Latn|Crna Gora}}, {{lang|sr-Cyrl|Црна Гора}} ou peut-on simplement écrire {{lang|sr|Crna Gora}}, {{lang|sr|Црна Гора}} ?

À noté, wikipédia en serbe code ses pages avec des « lang=sr-el » et des « lang=sr-ec ».

Ma question ne se limite pas au serbe, la même question est valable pour le japonais, le coréen, le mongol, le grec, l'hébreux, l'arabe et bien d'autre.

Zebulon84 (discuter) 14 août 2013 à 02:00 (CEST)

Bonsoir,
Sauf erreur, on est en UTF-8 donc les subtags d'écriture n'ont pas d'importance. Le navigateur ne « sait » rien, il se contente, en réponse à une suite de 0 et de 1, de restituer le glyphe correspondant dans la police de caractères spécifiée.
Cela ne pose a priori pas de problème aux synthèses vocales, pour lesquelles il importe seulement de connaître la langue de prononciation.
Le problème est plus épineux pour les plages Braille. Le nombre de caractères codables est beaucoup plus limité, et il y a forcément des recouvrements. Dans ce cas, j'avoue que je ne sais pas en pratique comment cela se passe quand dans un même texte se succèdent plusieurs langues (on trouve pas mal d'informations sur cet article consacré au Braille).
Cela dit, les normes sont claires : il faut mettre le code de langue, et nulle part le subtag n'est mentionné. Ces normes ont été établies de façon à spécifier clairement ce que les navigateurs et autres outils de restitution doivent s'attendre à trouver comme information d'« étiquetage » accessible. C'est ensuite à ces outils de faire leur boulot (c'est ce qu'on appelle les User Agent Accessibility Guidelines, UAAG) : voir la section sur les UAAG dans l'article sur l’accessibilité numérique). Litlok (m'écrire) 14 août 2013 à 22:48 (CEST)
Merci de cette réponse claire. Zebulon84 (discuter) 15 août 2013 à 08:08 (CEST)

Infobulle

[modifier le code]

Salut. J'ai une petite question : le modèle (par exemple) {{90e}} affiche l'infobulle quatre-vingt-dix. Or, nos amis Suisses ou Belges disent nonante. Je me demandais si, en terme d'accessibilité, ça aurait un impact négatif si l'infobulle affichait, par exemple quatre-vingt-dix (ou nonante) ? 'toff [discut.] 18 août 2013 à 12:09 (CEST)

Bonsoir,
Désolé pour le retard de la réponse. J'ai vu ton message tout à l'heure, et il m'a fallu faire quelques tests.
Dans l'idéal, on pourrait imaginer que le code HTML restitué dépend du pays (détection de l'IP...) ; dans ce cas, cela pourrait être réglé par les variantes linguistiques comme fr-fr pour le français de France, fr-be pour celui de Belgique ou fr-ch pour celui de Suisse (avec un code HTML final de la forme <code><span lang="fr-ch">90</span></code> par exemple, mais tant avec NVDA qu'avec Jaws, cela ne semble pas marcher, et c'est toujours lu comme du fr-fr (quatre-vingt-dix).
Cela dit, les personnes utilisant les synthèses vocales ont l'habitude de surfer et si elles entendent tout le temps quatre-vingt-dix, eh bien elles en ont l’habitude et cela ne pose pas de problème. Ajouter « (ou nonante) » est alors une question de politesse, mais aucune règle n'oblige à le faire. On pourrait même objecter que cela ajoute une redondance au contenu lu, et que c'est donc dommageable (il faut essayer de faire concis) Émoticône, mais là encore, cela ne fait pas l’objet d'une recommandation.
Conclusion : rien ne t'oblige à le faire, rien ne t'interdit de le faire. Au maximum peut-on simplement pointer un risque d'alourdir inutilement la page si tu le fais (les gens ont l'habitude ne pas l’entendre), mais ce n'est pas un critère objectif. Litlok (m'écrire) 21 août 2013 à 02:42 (CEST)
(Avec du retard aussi) Ok, merci de ta réponse. 'toff [discut.] 31 août 2013 à 08:59 (CEST)

Gadget encombrant

[modifier le code]

Bonjour, quelqu'un sait pourquoi le gadget "Accessibilité" ne peut plus être enroulé dans la colonne de gauche ? -- Amicalement, Salix [Converser] 27 août 2013 à 13:04 (CEST)

Parcequ'il n'a pas été mis à jour depuis bien longtemps. J'ai corrigé.
Amicalement — Arkanosis ✉ 27 août 2013 à 14:09 (CEST)
Merci Arkanosis ! Émoticône -- Amicalement, Salix [Converser] 27 août 2013 à 14:51 (CEST)

Galery

[modifier le code]

Que ce soit dans le nouveau mode « packed » ou dans le mode traditionnel, les images d'une gallery ont une taille fixe, indépendante de la taille des images définie en préférence.

  • Dans le mode traditionnel les images ont une taille de 120 (plus grande dimension) correspondant à la plus petite valeur des préférences de taille (en largeur),
  • en mode « packed » les images semblent avoir par défaut une hauteur de 180px. Si les images de cette taille ne tiennent pas sur une ligne, la hauteur est diminuée pour que les images occupe la largeur de la page. Si cette hauteur devient inférieure à 120, un nouvelle ligne est crée avec de nouveau une hauteur d'image de 180px, la première ligne restant dimensionnée en hauteur pour occuper la largeur de la page.

Puisque les galeries ne respectent pas les préférences utilisateur, doit-on déconseiller leur usage dans l'espace principal ?

Sinon pourquoi déconseiller {{Double image}}, {{Triple image}}, {{Multiple image}} ? A noter : ces trois modèles existent sur (en) et leur usage ne semble pas déconseillé.

Zebulon84 (discuter) 28 août 2013 à 05:15 (CEST)

span title

[modifier le code]

Quelle est la meilleure façon d'insérer un span avec un title servant uniquement aux robots ?

  • <span id="xx"> Mon texte </span><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi" style="display:none;">&nbsp;</span>
  • <span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi"><span id="xx" title = ""> Mon texte </span></span>

La première version est celle actuellement utilisée pour les COinS dans les modèles {{ouvrage}} / {{article}}. Le &nbsp; est nécessaires pour éviter que tidy ne supprime le span. Le display:none permet de ne pas l'afficher.

La deuxième version permet d'éviter cette astuce et de réellement encadré le texte représenté par ce title. Le title du premier span est caché à l'affichage par le second, vide. Mais est-il aussi ignoré par les lecteurs d'écran ?

Zebulon84 (discuter) 7 septembre 2013 à 10:25 (CEST)

La deuxième version pose problème avec google chrome car il ignore le title vide
Pour éviter le display:none et l'espace insécable, il suffit de mettre un id (unique de préférence) sur le span. La solution actuellement utilisé est donc :
<span id="xx"> Mon texte <span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi" id="coins_xx"></span></span>
Zebulon84 (discuter) 11 octobre 2013 à 13:22 (CEST)

Avec l'accent ?

[modifier le code]

Bonjour. J'aurais aimé savoir si les prénoms anglo-saxons communs (du genre Michael ou Jane) étaient prononcés à l'anglaise par les synthétiseurs vocaux même sans le Modèle:Lang (vu qu'on ne peut pas l'utiliser pour les noms propres). Est-ce que quelqu'un pourrait me renseigner ? Cordialement. Olyvar (d) 23 septembre 2013 à 19:41 (CEST)

Bonjour,
En fait, les normes d'accessibilité ne requièrent pas d'indiquer un changement de langue sur un nom propre. Par exemple, il est inutile d'indiquer {{lang|en|New York}}, car souvent la prononciation dans la langue d'origine n'est pas la même qu'en français. Je pense qu'il en est de même pour les prénoms... Litlok (m'écrire) 18 octobre 2013 à 08:46 (CEST)

liste et références

[modifier le code]

Sur la page d'un article de qualité, j'ai trouvé le code suivant : 

* {{ouvrage| ... }}
{{Références |groupe=A}}
* {{ouvrage| ... }}
{{Références |groupe=B}}
* {{ouvrage| ... }}
{{Références |groupe=C}}

Ceci génère un code html pas très propre, et probablement peu accessible.

Pour générer un code propre il faut remplacer la syntaxe wiki par de la syntaxe html et écrire : 

<ul>
<li> {{ouvrage| ... }}
{{Références |groupe=A}}
</li>
<li> {{ouvrage| ... }}
{{Références |groupe=B}}
</li>
<li> {{ouvrage| ... }}
{{Références |groupe=C}}
</li>
</ul>

Mais pour le contributeur moyen ce code n'est probablement pas très compréhensible.

Que doit-on privilégier ?

Zebulon84 (discuter) 11 octobre 2013 à 13:32 (CEST)

Bonjour,
Bien que la première syntaxe casse la structure HTML des listes, leur contenu reste consultable (le code HTML reste bien formé). À mon avis, dans ce cas il faut rester pragmatique et garder cette première solution, qui est un compromis acceptable. Il faut cependant garder à l'esprit qu'il faudra corriger ces modèles pour que dans cette situation, ils produisent du code correct. Litlok (m'écrire) 18 octobre 2013 à 08:53 (CEST)
En fait le problème vient de la syntaxe de liste de MediaWiki qui n'est pas conmatible avec l'inclusion de références dans une liste. Il faut donc utiliser la syntaxe html. Si on veut cacher ça dans un modèle, il faut qu'il englobe l'étoile, le modèle ouvrage et les références. Quelquechose du type
{{liste ouvrage référence
|biblio1 = {{article| ... }}
|groupe1 = A
|biblio2 = {{ouvrage| ... }}
|groupe2 = B
|biblio3 = {{ouvrage| ... }}
|groupe3 = C
}}
Sachant que la syntaxe des modèles ouvrage/article s'étant facilement sur 2 ou 3 lignes, je ne suis pas sur que ce soit beaucoup mieux. C'est dommage car la syntaxe html améliore aussi la présentation en décalant sur la droite la liste de référence, la faisant plus clairement apparaitre comme un sous-élément de la référence à l'ouvrage (somme toute logique, la présentation suis le code)
Zebulon84 (discuter) 18 octobre 2013 à 10:59 (CEST)

scope="col" OU headers="" et id=""

[modifier le code]

Bonjour,

Contrairement à ce qui est indiqué sur la page d'aide d'accessibilité ( Dans le cas de tableaux complexes comportant des en-têtes qui ne s’appliquent pas à la totalité d’une rangée ou d’une colonne, l’attribut scope= doit être remplacé par la combinaison des attributs id="" (dans les cellules d’en-tête) et headers="" (dans les cellules de données). Voir à ce sujet l’atelier accessibilité.), le gadget accessibilité ne me renvoie pas d'erreurs sur ce tableau. Où est l'erreur ? Dans le tableau ou dans le gadget ?


Résultats de l'élection cantonale partielle des 6 et 13 octobre 2013 du canton de Brignoles
Candidat Parti Premier tour[1] Second tour
Voix % Inscrits % Exprimés Voix % Inscrits % Exprimés
Laurent Lopez FN 2 718 13,11 40,40 5 031 24,27 53,91
Catherine Delzers UMP 1 397 6,74 20,76 4 301 20,75 46,09
Laurent Carratala FG (PCF)-PS 981 4,73 14,58
Jean-Paul Dispard PDF 612 2,95 9,10
Magda Igyarto-Arnoult EELV 598 2,88 8,89
Christian Proust DVD 422 2,03 6,27
Catégories officielles Nb personnes % Inscrits % Votants Nb personnes % Inscrits % Votants
Inscrits 20 728 100,00 20 728 100,00
Abstentions 13 815 66,65 10 888 52,53
Votants 6 913 33,35 100,00 9 840 47,47 100,00
Blancs et nuls 185 0,89 2,68 508 2,45 5,16
Exprimés 6 728 32,45 97,32 9 332 45,02 94,84

Freeroot (discuter) 18 octobre 2013 à 06:27 (CEST)

Le gadget n'est pas la panacée et n'est qu'une aide. Il ne peut détecter tous les problèmes. En l'occurrence, dans ce tableau, les scope=col consécutifs posent problème. En fait, un scope=col (ou row pour les rangées) s'applique à tout ce qui suit. Il ne s'arrête pas au scope=col suivant. Pour ce tableau en particulier, inscrit fait référence à la fois à catégorie officielle" mais également à "candidat" et "parti". J'espère avoir été clair ? 'toff [discut.] 18 octobre 2013 à 06:39 (CEST)
Pas si clair que ça mais j'ai compris : "inscrit" est référencé par "catégorie officielle" et également à "candidat" et "parti". Du coup il faut que je fasse la manip de mettre des headers et des id partout ? Si oui, les headers seront-ils affichés dans le même format qu'avec les scope ?
(conflit d'édition) Un avis personnel : plutôt que de complexifier avec id/headers, il vaut mieux séparer en deux comme ceci par exemple :
Résultats par candidat
Candidat Parti Premier tour[2] Second tour
Voix % Inscrits % Exprimés Voix % Inscrits % Exprimés
Laurent Lopez FN 2 718 13,11 40,40 5 031 24,27 53,91
Catherine Delzers UMP 1 397 6,74 20,76 4 301 20,75 46,09
Laurent Carratala FG (PCF)-PS 981 4,73 14,58
Jean-Paul Dispard PDF 612 2,95 9,10
Magda Igyarto-Arnoult EELV 598 2,88 8,89
Christian Proust DVD 422 2,03 6,27
Résultats par catégories officielles
Catégories Premier tour Deuxième tour
Nb personnes % Inscrits % Votants Nb personnes % Inscrits % Votants
Inscrits 20 728 100,00 20 728 100,00
Abstentions 13 815 66,65 10 888 52,53
Votants 6 913 33,35 100,00 9 840 47,47 100,00
Blancs et nuls 185 0,89 2,68 508 2,45 5,16
Exprimés 6 728 32,45 97,32 9 332 45,02 94,84

mais ce n'est qu'un avis personnel. (PS : rien à voir avec l'accessibilité mais colspan=1 ne sert à rien puisqu'il indique au tableau de fusionne la cellule en... 1 cellule Émoticône) 'toff [discut.] 18 octobre 2013 à 07:09 (CEST)

Je comprends bien ta solution mais les colonnes ne sont plus ajustées alors c'est pas très harmonieux^^. La discussion continue ci-dessous ;-) Freeroot (discuter) 18 octobre 2013 à 07:15 (CEST)
Là ce n'est plus de l'accessibilité mais de la présentation, mais bon, ✔️ c'est mieux ? 'toff [discut.] 18 octobre 2013 à 07:20 (CEST)
Parce qu'on a de la place sur les cotés et que les nombres ont tendances à être de la même taille, alors il suffirait de persévérer dans ta méthode en mettant un peu plus de width="" et le tour est joué. Merci ;-) Freeroot (discuter) 26 octobre 2013 à 03:45 (CEST)
Résultats par candidat
Candidat Parti Premier tour[3] Second tour
Voix % Inscrits % Exprimés Voix % Inscrits % Exprimés
Laurent Lopez FN 2 718 13,11 40,40 5 031 24,27 53,91
Catherine Delzers UMP 1 397 6,74 20,76 4 301 20,75 46,09
Laurent Carratala FG (PCF)-PS 981 4,73 14,58
Jean-Paul Dispard PDF 612 2,95 9,10
Magda Igyarto-Arnoult EELV 598 2,88 8,89
Christian Proust DVD 422 2,03 6,27
Résultats par catégories officielles
Catégories Premier tour Deuxième tour
Nb personnes % Inscrits % Votants Nb personnes % Inscrits % Votants
Inscrits 20 728 100,00 20 728 100,00
Abstentions 13 815 66,65 10 888 52,53
Votants 6 913 33,35 100,00 9 840 47,47 100,00
Blancs et nuls 185 0,89 2,68 508 2,45 5,16
Exprimés 6 728 32,45 97,32 9 332 45,02 94,84
  1. ↑ « Élection cantonale partielle de Brignoles : résultats du premier tour de scrutin », sur http://www.var.gouv.fr/, préfecture du Var, (consulté le )
  2. ↑ « Élection cantonale partielle de Brignoles : résultats du premier tour de scrutin », sur http://www.var.gouv.fr/, préfecture du Var, (consulté le )
  3. ↑ « Élection cantonale partielle de Brignoles : résultats du premier tour de scrutin », sur http://www.var.gouv.fr/, préfecture du Var, (consulté le )

Accessibilité tableau complexe

[modifier le code]

Bonjour à tous. J'ai un petit problème avec le tableau ci-dessous. Si les titres de colonnes sont bien accessibles, je n'arrive pas à régler le problème des cellules fusionnées sur plusieurs lignes (scope row rowspan). Un spécialiste pourrait-il m'aider ?
Par ailleurs le gadget me dit "Ce tableau devrait avoir un titre caption (code wiki |+)". Et si je ne veut pas mettre de titre , comment je fais ?!

Tableau présentant un pb avec des cellules fusionnées sur plusieurs lignes ("scope row rowspan")
Titre de tableau
Aménagement Année fouille Commune Site Nature Période Responsable de fouille Publication
Construction d’un immeuble sur parc de stationnement souterrain 1999 Orléans 18, rue Porte Saint-Jean Sépultures d’enfants au IIe siècle avant notre ère, tisserands au Ier siècle, terrain vague gallo-romain Tène finale 18, rue Porte Saint-Jean
Projet immobilier 1999 Orléans 20-22 rue Porte Madeleine / 3, rue de la Grille Four domestique de la Tène + une quarantaine de fosses du 1er siècle Tène finale + Antiquité + Moyen Âge 20-22 rue Porte Madeleine / 3, rue de la Grille
Diagnostic 2004 Sandillon "Les Brosseilles" Une fosse du Bronze final IIb dans le Val d’Orléans Bronze final IIb Stéphane Joly Une fosse du Bronze final IIb dans le Val d’Orléans à Sandillon (Loiret) : données archéologiques et contexte environnemental
Autoroute A19 2006-2009 Chevilly "Pièces de Chameul" Occupation protohistorique enclos et structures d'habitat et agricoles (ensilage de céréales), nécropole 70 tombes Âge du Fer - La Tène (+ médiéval et gallo-romain) David Josset La Pièce de Chameul (A19 – A2-7)
Chevilly "Les Herbeauts" et "La Croix Rouge" Aires d'ensilages de céréales (silos ) La Tène finale Eric Frénée
Villereau "Climat de Laveau" Habitat rural (silos, bâtiment sur poteaux) (Zone A + Zone C = 2 fouilles) Fin Hallstatt début La Tène ancienne Christine Pueyo
Neuville-aux-Bois "La Grande Route" Structures d’habitat et d’ensilage de  ; sépultures en silos La Tène David Josset La Grande Route (A19–C1).
Santeau "Le Différent" Habitat rural avec structures de stockage (silos) Hallstatt, La Tène ancienne Eric Frénée
Bouilly-en-Gâtinais "La Maison Rouge" Établissement agricole Premier âge du Fer (Halstatt ; vers -700) Eric Frénée
Courcelles "Haut de l’Aunette à Guignard" Nécropole tumulaire Âge du Bronze Hélène Froquet Tumuli de l'âge du Bronze à Courcelles (Loiret) - Opération A 19, Haut de l'Aunette à Guignard, Courcelles, Loiret, Centre.
Courcelles "La Pièce du Mail" Nécropole tumulaire Âge du Bronze final Hélène Froquet Les nécropoles à incinérations du Bronze final, Courcelles (Loiret)
Boynes "Clos de la Chaise" Structures de stockage (groupe de silos) Âge du Fer Sophie Liegard
Batilly-en-Gâtinais "Les Pierrières" Vaste habitat "aristocratique" délimité par un enclos carré fossoyé (160 m de côté), partitions internes, bâtiments La Tène Sophie Liegard Les Pierrières (site A19 – I1. 1-2)
Corbeilles "Les Grands Réages" Établissement rural à vocation agricole (silos, bâtiments à quatre poteaux, fossés de parcellaires, fosses et foyers) ; site le long de la voie antique Orléans-Sens Âge du Fer à la période augustéenne Nicolas Cayol
Courtempierre "Les Genièvres" Nécropole gauloise, enclos funéraires La Tène Gabriel Drwila
Treilles-en-Gâtinais et Gondreville "Le Cocluchon" Établissement agricole; petits enclos carrés (funéraires ?) de La Tène ; mausolée gallo-romain (fin du Ier s. ap J.-C.) et voie secondaire antique (Montargis à Sceaux-du-Gâtinais) Âge du Fer (La Tène moyenne à finale) Camille Scaon Inscription funéraire trouvée à Gondreville (Loiret, cité des Sénons)
Corquilleroy et Treilles-en-Gâtinais "La Grevasse" Établissement agricole (silos) La Tène ancienne Fabien Langry-Francois
Cepoy "Ferme de Montigny" Enclos d’habitat et nombreux bâtiments sur poteaux (greniers, annexes, habitations ?) La Tène finale (IIe - Ier s. av. n.è.) Johann Blanchard
Rocade nord de Pithiviers 2010 Pithiviers Vieux Chemin d’Étampes Partie d’un établissement rural. Néolithique + Tène Thierry Massat, Christian Cribellier Bois Médor et Vieux Chemin d’Étampes
Création d’une zone artisanale intercommunale 2011 Épieds-en-Beauce Les Chantaupiaux Communautés agropastorales hallstattiennes et laténiennes, lieu de culte augustéen et activités artisanales contemporaines La première implantation est centrée sur la transition entre le Hallstatt final et La Tène A (VIe et Ve s. av. J.-C.), la seconde sur La Tène moyenne (fin du IVe et IIIe s av. J.-C.). Les Chantaupiaux
 

Merci par avance. Roland45 (discuter) 18 octobre 2013 à 07:07 (CEST)

J'ai corrigé en enlevant les scope=row inutiles. Si toutefois tu y tiens, il faut, à mon sens, le faire aussi pour chaque première (et/ou) deuxième cellule en n'oubliant pas (et c'est aussi de là que venait l'erreur) de remplacer le pipe par le point d'exclamation). 'toff [discut.] 18 octobre 2013 à 07:16 (CEST)
Merci bien. Quelle efficacité. Je me passerai des scope=row.Roland45 (discuter) 18 octobre 2013 à 07:19 (CEST)

Méta palette de navigation sous-groupe

[modifier le code]

Bonjour,

Je viens vous parler du modèle {{Méta palette de navigation sous-groupe}}, celui-ci posant de sérieux problèmes d'accessibilité visiblement. Je voulais donc savoir si une solution était envisageable, le modèle étant très utilisé. Suite à une très courte recherche, j'ai découvert qu'un message avait été laissé sur la page de discussion de l'Atelier lors du premier semestre 2008, resté sans suites. Je n'y connais rien en terme d'accessibilité, et j'ai peur de ré-ouvrir une discussion caduque, mais quelques pistes semblaient être données dans le message. J'espère que le problème sera résolu, sinon la raison pour laquelle cela n'est pas possible.

Cordialement, Steven De Oliveira (Un bug ?) 21 octobre 2013 à 16:30 (CEST)

Lgd avait, un temps, évoqué l'éventualité de se pencher sur les méta-palettes (voir ici après avoir créé les infobox v3. Mais depuis, il a d'autres chats à fouetter et personne, me semble-t-il, n'a repris le flambeau. Donc, ça a l'air d'être au point mort. 'toff [discut.] 21 octobre 2013 à 16:47 (CEST)
Ah, donc il n'y a plus rien à faire ? C'est quand même bien dommage. L'Atelier ne peut vraiment pas y jeter un oeil ? Cordialement, Steven De Oliveira (Un bug ?) 21 octobre 2013 à 17:08 (CEST)
Peut-être certains sont assez doués pour jeter un oeil là-dessus, mais pas moi, c'est certain (je n'ai que de vagues notions qui m'ont été données ici). Après, plus rien à faire, pas forcément, il viendra bien un jour ou quelqu'un reprendra le flambeau. 'toff [discut.] 21 octobre 2013 à 17:16 (CEST)
Il existe en effet une éventuelle nouvelle génération de palette de navigation. voir Utilisateur:Hlm Z./Palette de navigation pour la documentation. Elle est actuellement en test depuis septembre 2013 (pas d'annonce officielle car je n'ai pas trop le temps en ce moment). Cordialement, Hlm Z. (discuter) 26 octobre 2013 à 14:07 (CEST)
Intéressant ! Je n'ai fait qu'un rapide détour, mais j'ai remarqué que la [nouvelle] documentation ne mentionnait pas l'utilisation du modèle {{Liste éléments}}, que j'utilise souvent. Vu que ce modèle utilise le modèle {{·}}, est-ce qu'il pose des problèmes d'accessibilité ? Et pourra-t-il être réutilisé à l'avenir ? Cordialement, Steven De Oliveira (Un bug ?) 26 octobre 2013 à 18:50 (CEST)
{{Liste éléments}} pose également un problème d'accessibilité. Une nouvelle classe CSS 'liste-horizontale' devrait être introduite rendant l'utilisation de la balise HTML appropriée pour chaque élément de la liste (et donc d'améliorer l'accessibilité et la sémantique). Des exemples sont disponibles dans la documentation. Cordialement, Hlm Z. (discuter) 26 octobre 2013 à 22:55 (CEST)

Deux ou trois choses sur l'accessibilité aux aveugles

[modifier le code]

Voir ce témoignage très intéressant qui a été déposé sur le bistro du 25 juillet 2013 : Wikipédia:Le_Bistro/25_juillet_2013#Deux_ou_trois_choses_que_je_sais_sur_l.27accessibilit.C3.A9_aux_aveugles. -- Amicalement, Salix [Converser] 18 novembre 2013 à 12:56 (CET)

Réactions

[modifier le code]

Après avoir lu attentivement le témoignage, je dois avouer que les craintes que j'avais sur le sujet ont été confirmées : Wikipédia, comme la plupart des sites internet, n'est pas adaptée, ou plutôt devrais-je dire ne s'adapte pas ou ne propose pas une version adaptée, aux personnes ayant un handicap visuel ! Même s'il existe des moyens techniques pour aider ces personnes à profiter d'Internet, et de manière plus générale d'un ordinateur, il faut admettre que le constat de Soboky est plutôt décevant. Certes, il y a le lecteur d'écran qui renvoie le résultat vers un synthétiseur vocal ou une plage braille, certes, le langage HTML permet la description d'une image à l'aide de l'attribut alt. Mais disons les choses clairement, Wikipédia est en l'état conçue/adaptée pour les voyants ; beaucoup d'éléments, utiles pour les voyants, viennent polluer la lecture d'un non-voyant, tels que l'infobox, les références, les images non correctement décrites, les 20 liens dans un même paragraphe, les nombreuses palettes de navigation, etc. Le projet articles audio semblait être une excellent alternative, bien que la version audio était noyée dans l'article, mais malheureusement en sommeil, et je comprends pourquoi. Imaginez-vous le travail que ça demande, d'autant plus que chaque mise à jour majeure de l'article demande une mise à jour de la version audio. Admettons-le, c'est peine perdue ! La solution est-elle ailleurs ? Personnellement je pense que oui. Il est absurde, pardonnez-moi l'expression, de continuer à penser qu'une seule et même version de Wikipédia doit pouvoir répondre à des besoins différents. C'est comme si on essayait de me convaincre qu'un escalier, sans modification, devrait pouvoir être utilisé par un paraplégique, ou qu'une oeuvre musicale devrait pouvoir être perçue par une personne atteinte de surdité. Non, il faut adapter l'escalier aux paraplégiques tout comme il faut adapter Wikipédia aux non-voyants. Nous avons d'ailleurs une version de Wikipédia adaptée aux mobiles, montrant ainsi que Wikipédia peut s'adapter selon les besoins. Alors que faire ? Créer une version de Wikipédia sans éléments superflus qui permettrait de faciliter le travail d'un lecteur d'écran ? C'est une piste ! Créer une version de Wikipédia sur laquelle il est facile d'accéder à différents éléments à partir du clavier ou de la parole ? C'est une piste ! En tout cas, en France, 1 personne sur 100 est malvoyante et 1 sur 1000 est aveugle, et c'est autant de personnes qui ne peuvent pas profiter pleinement du travail que nous accomplissons chaque jour. Et c'est bien dommage ! Que proposeriez-vous pour améliorer les choses ? – Je viens en paix, Reptilien.19831209BE1 Fichier:Reptilien.19831209BE1 12px.png [Bonjour,_✎] 22 novembre 2013 à 10:58 (CET)

Bonjour, au lieu de devoir créer plusieurs versions de chaque site sur le web, n'est-il pas plus simple de faire plancher des spécialistes pour améliorer les performances des lecteurs d'écran ? Ce qui ne nous dispensera pas bien évidemment de veiller à la bonne tenue des alt, scoop col, caption, lang et autres astuces destinées à leur rendre intelligibles ce que ces appareils ne peuvent pas deviner dans les articles. A nous aussi d'éviter de bidouiller des modèles incompatibles avec ces robots-lecteurs. Il ne devvrait pas être impossible par exemple d'émettre un léger bip pour signaler un lien au lieu de dire "lien", ou de rendre la lecture des références optionnelles... -- Amicalement, Salix [Converser] 22 novembre 2013 à 12:15 (CET)
Pour faire court et répondre à Notification Salix :, les WCAG sont des guides pour la rédaction de contenus accessibles. Ces contenus sont ensuite interprétés par ce que l'on appelle des « agents utilisateurs ». Afin que les éditeurs de ces logiciels sachent comment exploiter au mieux les informations des documents accessibles, d'autres guides ont été écrits, les UAAG. Cela concerne les navigateurs graphiques et, de manière générale, tous les logiciels utilisés pour accéder à des documents en ligne. Les « spécialistes », donc, travaillent depuis des années sur le sujet Émoticône Une dernière remarque enfin : les lecteurs d'écran ne sont ni plus ni moins que les navigateurs graphiques des « robots-lecteurs ». Il s'agit juste de deux manières différentes de restituer un même contenu. Litlok (m'écrire) 3 décembre 2013 à 23:04 (CET)
Notification Litlok : En quoi est-ce incompatible avec ce que j'ai suggéré ci-dessus ? Pourquoi demander à Wikipédia ou tout autre site de palier des problèmes techniques qui sont dus, non à l'absence de balisage du texte, mais à une analyse incorrecte qui en est faite par le robot-lecteur : par exemple il lit "lien web" au lieu d'émettre par exemple un son spécifique, ou faire vibrer la souris, chanter du Claude François, que sais-je... ou tout simplement de se taire quand il rencontre un "nowiki", "colonne" ou "br" qui n'ont pas d'impact audio. Un robot n'est idiot que parce qu'on ne lui a pas programmé la bonne réaction face à un obstacle, non ? -- Amicalement, Salix [Converser] 4 décembre 2013 à 12:42 (CET)
Notification Salix : : de mémoire, les UA (agents utilisateur) doivent indiquer la présence d'un lien. Le standard de facto est l’énoncé explicite tel que tu le mentionnes, mais il est en général possible de paramétrer l’outil. C'est l'exact équivalent sonore de l'information visuelle « souligné en bleu », par exemple, et tout comme il t'est possible, dans les réglages de ton navigateur graphique, de changer l’apparence par défaut des liens, il est possible de le faire pour leur « apparence sonore ». Litlok (m'écrire) 4 décembre 2013 à 14:08 (CET)
Ce qui me conforte dans mon idée, mais ne répond pas à la question de Reptilien. Au bilan, comment faire de notre côté pour aider les robots-lecteurs, sans toutefois compliquer inutilement la rédaction de nos articles pour palier les défauts (de jeunesse ?) de ces outils ? Émoticône. -- Amicalement, Salix [Converser] 4 décembre 2013 à 15:42 (CET)
Suivre les bonnes pratiques de l’Atelier, elles-mêmes inspirées des WCAG. Il est illusoire d'espérer se mettre « dans la peau » d'un outil spécialisé, encore moins d'un utilisateur. Les WCAG ont été conçues pour ne pas avoir à imaginer des situations de handicap. Ce sont, avec les UAAG, le résultat de plusieurs années de travail collaboratif de groupes d'experts et d'utilisateurs pour aboutir à des recommandations de nature technique, destinées à des logiciels, qui à leur tour doivent restituer les informations à leurs utilisateurs. Les BP mises en avant ici sont elles aussi le résultat d'arbitrages entre les recommandations des WCAG d'une part, et les spécificités à la fois de Mediawiki et de la communauté wikipédienne d'autre part... Il n'y a rien de plus à faire. Cela peut paraître frustrant, mais c'est le plus efficace. Litlok (m'écrire) 4 décembre 2013 à 16:34 (CET)
Euh, avoir l’avis et des retours de vrais utilisateurs avec des vrais logiciels qu'ils utilisent, majoritairement JAWS sous windows, à voir sous Mac ou sous d'autres systèmes (Orca https://help.gnome.org/users/orca/stable/preferences_speech.html.fr gratuit pour le coups ) par exemple est sans doute une bonne idée pour se rendre compte concrètement des problèmes et y travailler. Si ça se trouve ça passe concrêtement très bien, de là à dire qu'il n’y a rien de plus à faire je suis pas vraiment sur. — TomT0m [bla] 4 décembre 2013 à 16:49 (CET)
Il se trouve qu'il y en a eu, et que globalement Wikipédia est plus accessible que la moyenne des sites grands publics dont avaient l'habitude les personnes qui ont testé -et ce, grâce à la grande structuration du contenu, ainsi qu'aux normes de rédaction (style encyclopédique notamment...). Cela dit, bien évidemment que les tests utilisateurs sont utiles, pour mettre le doigt là où ça fait mal Émoticône sourire. Quand je dis qu'il n'y a rien de plus à faire, c'est que les limitations de mediawiki sont telles que les bonnes pratiques qui sont ici détaillées sont ce qu'on peut faire au maximum en terme d'« accessibilisation » du contenu sur Wikipédia. Il reste encore énormément de travail ! Litlok (m'écrire) 4 décembre 2013 à 23:07 (CET)

┌──────────────────┘
 Il y a surtout un travail énorme de sensibilisation à faire au sein des contributeurs. Il est hélas trop fréquent de se faire envoyer sur les roses par des contributeurs qui ne voient pas pourquoi se priver d'une jolie (ref. souhaitée) présentation pour le confort d'une minorité de handicapés. Comme nous n'avons aucun moyen d'interdire certains modèles catastrophiques et qu'il n'y a toujours pas de solution accessible, il est difficile de demander à tous de renoncer aux palettes avec sous-groupes, tableaux triables, langage mathématique LaTEx ou encore aux fonds de cartes géocalisés. Il est bien dommage que des modifications comme celle-ci se fassent dans l'indifférence générale. Même une remarque à propos d'un contraste coloré insuffisant reste souvent lettre morte et les encarts d'avertissement dans les documentations n'ont pas l'air d'avoir beaucoup d'impact. Certains modèles pourraient-ils par exemple se voir décerner un label d'accessibilité ? Ce qui a l'avantage d'être une démarche positive. Ou bien passer par une homologation quelconque et, au pire, se voir interdits d'usage dans l'espace encyclopédique, ou d'usage tout court ? Mais c'est moins dans l'esprit de liberté qui règne ici. Et qui est capable parmi nous de juger l'impact d'un modèle sur l'accessibilité ? -- Amicalement, Salix [Converser] 5 décembre 2013 à 15:37 (CET)

Pour Latex, quelqu'un sait si les fonctionnalités comme https://www.mediawiki.org/wiki/VisualEditor/Beta_Features/Formulae ou mathjax, activables dans les préférences, sont accessibles ? Ça me semble largement jouable que le lecteur vocal interpète et sache rendre correctement du MathML, du coup on pourrait utiliser latex sans rien lacher niveau accessibilité. — TomT0m [bla] 8 décembre 2013 à 17:05 (CET)

Échecs

[modifier le code]

Bonjour, pouvez-vous lire cette section et donner vos avis et solutions éventuels concernant l'accessibilité ? Cordialement.--Gratus (discuter) 3 décembre 2013 à 18:42 (CET)

Avis donné ! Litlok (m'écrire) 3 décembre 2013 à 22:54 (CET)

rappel en astérisque

[modifier le code]

Salut. Une vieille question que je me posais. Est-ce qu'un astérisque avec un rappel est accessible ? Du style :

  • machin*
  • truc*
  • bidule

*Rappel de l'astérisque ~
'toff [discut.] 5 décembre 2013 à 21:33 (CET)

S'il y a un grand écart entre l'appel de l’astérisque et son rappel, cela peut être gênant mais ce n'est pas à proprement parler un obstacle. C'est gênant car si un utilisateur voyant peut rapidement scanner la structure visuelle de la page et détecter en bas le rappel de la note, puis revenir à son appel initial, cela est beaucoup plus difficile pour un utilisateur de lecteur d'écran. Pour faciliter cette consultation, dans l'idéal il faudrait placer des liens, un peu à la manière des appels de notes multiples (a, b, c...) mais c'est difficile à gérer, et cela alourdit l’apparence de la page. Plus pratique est la solution de placer le rappel avant la liste. Sorti du contexte, c'est un peu difficile de donner un exemple mais cela pourrait être « les personnes dont le nom est suivi d'un astérisque sont celles qui ont des cheveux roux », puis la liste. Litlok (m'écrire) 5 décembre 2013 à 22:39 (CET)
Un exemple concret : {{Infobox Patrimoine mondial}}. Like tears in rain {-_-} 6 décembre 2013 à 08:14 (CET)
Dans ce cas, la contrainte est principalement graphique et liée à la mise en page. Je n’ai pas de solution miracle : cela reste une gêne, mais comme je l’ai dit, pas un obstacle absolu à la consultation de l'information. Ne pourrait-on pas doublonner l’astérique par une ref en bas de page (qui insère un lien+le lien de retour) ? Litlok (m'écrire) 9 décembre 2013 à 01:01 (CET)
Bonjour, c'est ce que j'allais dire, pourquoi utiliser l'astérisque quand on dispose d'appels de notes dynamiques pour indiquer la source ? C'est ce que nous utilisons dans les taxobox de biologie en renvoyant vers la référence, cf. Modèle:Bioref, ce qui permet en plus de dater la référence. -- Amicalement, Salix [Converser] 9 décembre 2013 à 09:27 (CET)

Accessibilité sur imbrication de tableaux

[modifier le code]

(Les informations recueillies dans cette discussion ont été rapportées dans la documentation du modèle Gallery)

Bonjour,

(C'est un marronnier dont la discussion avait été entamée dans l'aide galerie).

Pour vous me donner votre avis sur la page Machine de Mealy , le gadget me signale la galerie en rouge du fait de l'imbrication de tableaux générée par lemodèle gallery. Cette question est facilement résolue si on remplace par la balise gallery sans mode packed.

Pouvez vous me confirmer que cette imbrication de tableaux pose problème ? Et sur quel support , les smartphones ?

Merci; --Ickx6 8 décembre 2013 à 07:39 (CET)

Bonjour, il ne me semble pas que ce soient réellement des tableaux imbriqués puisque seule la mise en forme est en facteur commun, ce qui ne perturbe pas une lecture linéaire. En revanche, je vois déjà un gros problème avec ce Modèle:Gallery : il fixe la taille des images en pixels, et donc ne permet pas de redimensionner automatiquement les vignettes en fonction des écrans, contrairement à "upright". De plus, il alourdi àmha inutilement le code de la page par rapport aux galeries habituelles. Après test de cet article sur ail-faune, il n'y a pas de problème d'affichage dans ce cas précis puisque les dimensions ne sont pas fixées, par contre du côté accessibilité, il manque soit les alternatives textuelles, soit un "message galerie" pour rappeler qu'il à (du moins en théorie) une description détaillée sur Commons. -- Amicalement, Salix [Converser] 8 décembre 2013 à 10:08 (CET)
Question bête : pourquoi ne pas utiliser <gallery></gallery> à la place du modèle ? 'toff [discut.] 8 décembre 2013 à 11:46 (CET)
Le rédacteur a certainement souhaité agrandir l'affichage par défaut des vignettes qui, en mode galerie traditionnelle, ne sont pas très lisibles et nécessitent de cliquer sur chacune pour voir correctement le contenu. Voir ce test pour comparer le rendu des deux. Dans ce cas précis, cela peut se justifier dans la mesure où il n'y a pas vraiment d'entrave à l'accessibilité (à condition d'ajouter des alt !). -- Amicalement, Salix [Converser] 8 décembre 2013 à 14:03 (CET)
Effectivement, ça se conçoit. Merci Salix (d · c · b) 'toff [discut.] 8 décembre 2013 à 14:32 (CET)
Notification Salix : : par contre pour moi l'utilisation de {{Gallery}} a un gros défaut : la hauteur des légendes est limitée. Ainsi sur mon écran la dernière légende à droite (la plus longue) apparaît tronquée avec un ascenseur pour voir la suite… Ayant un écran en 1920x1200 je trouve ça un peu désagréable ! Émoticône sourire. C'est du moins-accessible pour les personnes sans handicape Émoticône. À noter que j'utilise une taille de fonte un peu plus grande que celle par défaut. Cordialement, Hexasoft (discuter) 9 décembre 2013 à 09:35 (CET)
Notification Hexasoft et Supertoff : Bien vu Hexa, ce n'est pas visible chez moi et la doc n'en dit rien. Depuis mon mini ordi je remarque aussi qu'il y a un immense vide entre le bas de la légende et le "Texte sous les images" quand il y a deux rang d'images. Il faudrait soit améliorer ce modèle, soit au minimum alerter les utilisateurs sur ces défauts dans sa documentation. -- Amicalement, Salix [Converser] 9 décembre 2013 à 09:55 (CET)

Rencontre avec un malvoyant

[modifier le code]

Bonjou,

Hier dans le train j'ai bavardé avec un malvoyant accompagné d'un chien guide. C'était un juriste, passionné d'histoire, qui m'a dit consulter très régulièrement Wikipédia, avec un lecteur d'écran, mais aussi en visuel car il trouve la mise en pages, sobre sans trop de couleurs, très claire et très lisible, beaucoup plus claire que sur d'autres sites. Il apprécie aussi beaucoup la présence de sommaires qui lui facilitent grandement la lecture. Je lui ai laissé mes coordonnées en lui disant de ne pas hésiter à prendre contact s'il rencontrait des difficultés en consultant WP.

Cordialement, Cymbella (répondre) - 13 décembre 2013 à 21:23 (CET)

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Discussion_Wikipédia:Atelier_accessibilité/Archives_accessibilité_2013&oldid=156718181 ».