Discussion Wikipédia:Atelier accessibilité/Bonnes pratiques

Quelques remarques

Salut,

J'ai bien vu que tes pages ne sont qu'un exemple, je souhaiterais cependant émettre déjà quelques commentaires.

Il s'agit en effet d'exemples rapides et temporaires qui ne préjugent pas des bonnes pratiques qui pourront être finalement formulées. Il est un peu tôt pour en discuter sur le fond ;-) J'ai répondu ci-dessous pour éclairer le sens des exemples. Cordialement, --Lgd (d) 14 avril 2008 à 15:54 (CEST)

Listes

À Wikipédia:Atelier accessibilité/Bonnes pratiques#Listes, je lis :

• Non accessible : Les conséquences sont : d'une part, item 1; d'autre part item 2 et enfin item 3
• Accessible : * item 1 * item 2 * item 3

→ Je pense que l'exemple n'est pas bien choisi (ou alors je n'ai pas compris, ou alors je suis en désaccord)

« Les conséquences sont : d'une part [...] » n'est pas une « liste non structurée faite au fil du texte », mais un texte parfaitement compréhensible rédigé en langue française, qui est la langue dans laquelle nous rédigeons nos contributions et la langue que comprennent les lecteurs de Wikipédia fr:, quel que soit leur niveau de handicap. Ton exemple semble suggérer que nous devrions remplacer la langue française par une novlangue où les liens logiques seraient représentés graphiquement et la ponctuation remplacée par des astérisques. J'admets qu'il doit bien exister des listes faites au fil du texte qui devraient être remplacées par la syntaxe * item 1 * item 2, et je préfèrerais que tu donnes un exemple explicite.

Images portant une information

À Wikipédia:Atelier accessibilité/Bonnes pratiques#Images portant une information, je lis :

Éviter

• [[Image:Croissance population Paris.PNG]]
• [[Image:Croissance population Paris.PNG|thumb|Croissance de la population parisienne depuis le premier recensement en 1801]]

→ Je pense que le tableau devrait être séparé en plus de zones, ou que des commentaires devraient indiquer en quoi il faut éviter ces formulations.

Le premier exemple que je recopie ici est clair, il s'agit d'éviter de mettre une image sans légende. Le deuxième en revanche semble indiquer qu'il faut éviter les légendes. Quel est le problème de cet exemple ?

le second exemple illustre le problème actuel des légendes de thumb : mediawiki reproduit le texte de la légende pour produire l'alternative textuelle de l'image, alors que ces deux informations devraient pouvoir être saisies distinctement (l'une est affichée, l'autre non. L'une accompagne l'image et l'autre est destinée à la remplacer. Ici, le texte est pertinent en tant que légende, mais pas en tant qu'alternative textuelle : celle-ci doit reproduire l'information principale donnée dans l'image (ici, par exemple, « La population parisienne intra-muros croît de 500 000 habitants en 1801 à 2 142 800 en 2004 »).

C'est donc une limitation technique de mediawiki qui :

• pourrait être résolue par une modification du CMS (un bug est depuis longtemps ouvert à ce sujet)
• pose actuellement et peut-être durablement un problème d'accessibilité éditorial très difficile à résoudre: faut-il tenter de rédiger des légendes/alternatives qui soient pertinentes pour l'accessibilité ? Faut-il privilégier d'autres solutions éditoriales ?

Question totalement ouverte, donc ;-) --Lgd (d) 14 avril 2008 à 15:54 (CEST)

Je lis :

Préférer

• [[Image:Croissance population Paris.PNG|Page du graphique Croissance population Paris.PNG]]

→ Cela me semble ruiner toute possibilité d'imprimer la page, ou plutôt réserve une mauvaise surprise à celui qui l'a imprimée. Je n'ai jamais vu un livre où les légendes étaient renvoyées dans des hors-textes en fin de volume. Si on parle d'internet, renvoyer une légende sur une autre page, cela complique la tache des personnes ayant une connection lente (surtout que la page de l'image contient une image de grande taille, qui peut être longue à charger).

En outre, indépendamment de toute considération d'accessibilité, chaque illustration d'un article d'encyclopédie devrait être suffisante à sa propre compréhension, c'est-à-dire devrait comporter une légende suffisante. renvoyer la légende à une page séparée est une erreur de rédaction d'un texte d'encyclopédie.

Ici, il ne s'agit pas d'une image légendée (thumb) mais d'une image sans légende : le texte « Page du graphique Croissance population Paris.PNG » n'apparaît pas à l'affichage « normal » ni à l'impression : il n'apparaît que lorsqu'il doit remplacer l'image (lecture par une synthèse vocale, affichage avec images désactivées, etc.) --Lgd (d) 14 avril 2008 à 15:54 (CEST)

CSS

Au paragraphe Wikipédia:Atelier accessibilité/Bonnes pratiques#A qui cela bénéficiera-t-il ?, tu indiques qu'il faut tenir compte de certaines règles pour que les internautes qui ne disposeraient pas de Javascript ou de CSS ne soient pas lésés. Tu donnes une illustration où la désactivation de CSS a un effet désastreux sur une table (la Classification périodique). Mais je n'ai pas vu de proposition de solution ou de contournement. Je pense que la section Wikipédia:Atelier accessibilité/Bonnes pratiques#Styles CSS devrait aborder ce problème et donner des conseils.

Cordialement. — Jérôme 14 avril 2008 à 15:02 (CEST)

Tout à fait. Le problème des styles CSS utilisés pour générer un contenu (notamment là où une image devrait être employée) est un des problèmes récurrents de nombreux modèles. La difficulté est que CSS fournit aux contributeurs un moyen simple d'automatiser la production de certains graphiques. Là encore, il s'agit d'une question pour l'instant ouverte. --Lgd (d) 14 avril 2008 à 16:14 (CEST)

Tu confonds « commande style » et « CSS ». C'est gravissime ! Cela discrédite tout ton travail.   <STyx @ 2 décembre 2008 à 14:50 (CET)

Concernant la génération de PDF, l'absence de support de CSS est incompréhensible. Les explications indiquent une règle d'accessibilité mais cela n'a rien à voir: un PDF a nécessairement un rendu graphique avec une mise en page calculée et imposée, le vrai problème est la faiblesse de l'outil actuellement utilisé (qui ne comprend pas les tailles de texte, y compris relatives, la mise en page des tableaux, alors qu'il va continuer à s'améliorer, et il le devrait notamment pour son rendu très mauvais des tableaux où les cellules ont des largeurs makl calculées, débordent et se superposent: le moteur de rendu PDF ne respecte pas du tout les normes HTML de base, même sans CSS).

Concernant le support par les navigateurs, c'est aujourd'hui devenu un faux problème: le support de CSS dans les navigateurs s'est énormément amélioré sur tous les systèmes (merci à Mozilla, KDE, Opéra, Apple, et même à Microsoft). Il ne reste plus que le cas particulier (et très limité) de l'accès par téléphone mobile avec des écrans très peu large, et le problème moins sérieux de la navigation de type WebTV (navigation à la télécommande ou avec une manette à boutons sur console de jeux, sans souris, et un clavier réduit pas adapté à la saisie de texte hormi quelques mots : nombre de navigateurs WebTV, intégrés dans des décodeurs TV, sont basés sur un moteur Opéra ou Mozilla, souvent portés sur plateforme MIPS, mais là encore ce n'est pas une question d'accessibilité du CSS qui est maintenant parfaitement supporté).

Qui utilise encore Lynx pour naviguer sur Wikipédia, quand on ne manque plus d'ordinateur ? Ceux qui ont des consoles texte sont connectés en fait à des serveurs d'applications via le plus souvent un émulateur sur PC ou Mac, machine sur laquelle on a des navigateurs plus adaptés.

Tous les graphiques ne peuvent pas être rendus accessibles, la seule alternative étant alors de les décrire dans un article séparé donnant une représentation totalement différente (avec un tableau simple par exemple).

L'exemple du tableau périodique des éléments est que celui-ci est bien défini en tant que tableau, et comporte tellement d'infos qu'un rendu graphique est nécessaire. C'est le mauvais exemple de cas critiqué pour être inaccessible, alors que dans ce cas précis c'est justement un autre article qui serait à référencer par un lien juste avant le tableau qu'il ne faut pas remanier alros que c'est sous cette forme qu'il est, de loin, le plus pratique à lire et utiliser par le plus grand nombre... OK la couleur n'y est pas indispensable, mais le tableau avec les couleurs apporte un plus pour le repérage. Cela n'empêche pas le tableau d'être parfaitement lisible et interprétable correctement même sans les couleurs.

Vouloir tout remplacer est une chimère. Même le rendu des cartes avec superpositions d'images peut être réglé sans qu'on ait à télécharger des milliers d'images, ce qui est une perte de temps et d'espace considérable, et ne facilite pas du tout les mises à jour et la cohérence. Qu'on nous mette à ce moment-là la possibilité de générer des images inline (en SVG, puisque le format PDF supporte nativement les SVG) si CSS est la mauvaise solution. D'ailleurs il n'y a qu'à voir les sites en technologies propriétaires Flash ou SilverLight qui parviennent très bien à générer des pages en PDF sans tout réécrire: HTML+CSS est la bonne solution portable (et maintenant très bien supportée) pour justement ne pas utiliser ces technos propriétaires.

Bref, quand vous mettez que c'est un problème « urgent » ou « très important » à régler, il ne faut pas recommander de supprimer ces techniques (cette recommandations est inutilement destructive) mais faire en sorte que le code utilisé soit le plus portable possible, et améliorer les outils qui génèrent autre chose que du HTML+CSS.

Sinon on va revenir au temps du HTML 1.0 et on n'aura plus qu'un site tout blanc avec du texte noir et des liens bleus, et plus d'image du tout, comme au temps des premiers navigateurs NCSA Mosaic en HTML 1.0 (qui n'étaient pas normalisés de toute façon), ou à la navigation de type Gopher (par menus avec des listes de numéros de liens, comme sur les horribles serveurs vocaux des centres d'appel téléphoniques, qui sont eux totalement inutilisables et franchement frustrants à utiliser).

OK on doit tenir compte de certaines contraintes techniques, mais aujourd'hui les contraintes les plus sévères pour les utilisateurs sont celles de la sécurité, et cela leur impose de mettre à jour souvent leur navigateur web (et donc de bénéficier aussi de leurs très nettes améliorations depuis 2 ou 3 ans et d'autant plus depuis 2009).

Enfin il faut rappeler que les technologies d'accessibilités ne sont pas encore à l'état de norme, elles sont en grande évolution et ce qu'on bannit aujourd'hui pourrait s'avérer vite utile plus tard avec nes nouveaux outils d'accessibilité qui se développent et permettent de faire ce qu'on croyait impossible avec les normes actuelles. En réalité, ce n'est pas le style local qu'il faut adapter, mais le contenu tout entier (on devrait disposer d'outils pour faciliter la génération de présentations d'articles alternatives quitte à les retravailler pour certains publics, ce qui impose aussi des changements de structure pour une lecture plus linéaire: je ne vois pas comment on peut remplacer un graphique avec le même contenu informatif en Braille par exemple, mais des lecteurs Brailles arrivent qui permettent de retranscrire maintenant aussi des images sur une surface tactile 2D, y compris les photos, si on accepte de ne sacrifier que les couleurs, ce qui porte l'accessibilité à celle des déficients de la différenciation des couleurs...).

Bref il nous faut plus d'outils, mais pas imposer des normes (bêtas) qui imposent de sacrifier le travail réalisé et de le rendre non maintenable à grande échelle. On peut faire autrement et ça passe par la génération de contenus alternatifs supplémentaires (ce que Wikipédia supporte très bien avec des liens vers d'autres articles similaires mais ayant une présentation différente).

Ceci dit je suis d'accord: Wikipédia souffre encore de l'impossibilité de développer séparément des feuilles de style spécifiques au sein des articles sans les mélanger au texte (alors qu'on pourrait tout à fait utiliser cette possibilité pour justement mettre dans l'article plusieurs mises en formes différentes d'un article entier, d'une image, ou d'un paragraphe). On devrait pouvoir décrire le contenu de façon logique, et séparément le mettre en forme en reprenant des éléments par références (lequel contenu devrait se contenter de référencer des noms de "classes" utilisables aussi dans le code CSS libre. Là encore c'est une faiblesse de notre outil actuel, mais un problème pour lequel il faut demander aux développerus d'améliorer les choses au lieu de sacrifier le contenu. 79.94.111.155 (d) 5 août 2009 à 02:59 (CEST)

Pour vous donner rapidement une piste vous permettant d'approfondire cette question et de comprendre quelle est la nature exacte de ces problèmes liés aux mésusages de CSS, je vous invite à consulter la norme d'accessibilité WCAG2 et plus particulièrement la notion de « technologie compatible avec l'accessibilité » (Accessibility Supported'). --Lgd (d) 5 août 2009 à 06:35 (CEST)

Formules mathématiques

Dans la mesure ou dans les préférence l'utilisateur peut paramétrer pour que le logiciel génère les formules en MathML, et qu'il n'existe plus du tout d'import d'images pour des formules, indiquer une faisabilité faible, est-ce vraiment le cas ? bayo 29 avril 2008 à 15:21 (CEST)

Il faut que je revérifie ce que j'avais noté là-dessus, mais si je me souviens bien concernant <math></math>:

• rendu MathML: ce format n'est actuellement pas correctement pris en charge par une partie des navigateurs, et surtout par les aides techniques. Concrètement, un rendu en MathMl n'est pas accessible (même si en théorie ça le ferait).
• rendu PNG: mediawiki génère l'alternative textuelle automatiquement en y insérant la syntaxe LATEX : c'est un moindre mal, et sans doute ce qui peut être fait de mieux pour l'instant, mais là encore, on peut difficilement qualifier ce rendu alternatif d'accessible (LATEX est très mal lu dans un lecteur d'écran, et la formule mise en image pose le problème classique des textes mis en images que le zoom typo des navigateurs ne peut agrandire).
• la solution normale en accessibilité serait: avec le rendu PNG, c'est une image complexe qui nécessite une description étendue (attribut HTML longdesc de l'image, donnant l'url d'un texte reproduisant l'information). Mais :
  • mediawiki ne permet plus de générer un longdesc
  • Où placerait-on la description étendue, c'est à dire la formule sous forme "verbalisée" ? je doute qu'elle soit acceptée dans l'article.

Au bout du compte, j'en suis pour l'instant à estimer que ce problème de priorité élevé (comme tout problème d'alternative textuelle, niveau A, empêchant de percevoir tout ou partie du contenu) n'a pas de solution « réaliste » aujourd'hui. C'est le sens du « faisabilité: faible ».

cela dit, des avis plus expérimenté sur l'usage de <math></math> sont les bienvenus ? --Lgd (d) 29 avril 2008 à 16:36 (CEST)

Sans même parler des personnes ayant un handicape quelconque, je pense qu'il serait intéressant de mettre en place quelques règles pour aiguillier les amoureux des maths qui ont parfois du mal à distinguer l'évidence pour tous de l'évidence pour un doctorant en mathématique. Bon j'exagère un peu mais vous aurez saisi l'idée. ^^

Par exemple, dire qu'on emploi pas des symbole mathématique comme ∨, ∧, ¬, ou ∃ sans :

1. fournir les prononciation équivalente, voir fournir la traduction in extenso des formulations, ou au moins les premières de l'article de manière à ce que le lecteur puisse lire les suivantes
2. pointer vers des pages qui explique le sens des symboles, ou au moins en début d'article signaler que l'article utilise ces symboles dont on trouvera par exemple le sens sur cette page.

Qu'en pensez-vous ?

--Psychoslave (d) 25 janvier 2011 à 18:30 (CET)

Très bonne initiative. Expliquer le sens des symboles (ou abréviations) afin de faciliter la compréhension est bien un critère d'accessibilité. Et cela faciliterait la compréhension pour tous. Bien à toi, Dodoïste ^{[ dring-dring ]} 25 janvier 2011 à 19:11 (CET)

Des bugs?

Bonsoir, en lisant cette page je me pose qq questions:

1. Dans la section liens il y a une contradiction entre [[Discussion Utilisateur:Lgd|<font size="3">✍</font>]] mis dans la colonne accessible et la remarque juste en dessous.
2. dans la section Utilisation de la couleur... il n'y a pas de couleur!

Est-ce normal? --amicalement, Salix ( converser) 1 juillet 2008 à 23:34 (CEST)

Pseudo contenu CSS

Amha c'est faux ! ... ou au mieux mal formulé. Ce n'est pas dû à l'absence de CSS mais au contraire à la présence de

 background-color : white !important

J'ai peur qu'il ait beaucoup de méconnaissance en la matière sur cette page.   <STyx @ 11 novembre 2008 à 19:11 (CET)

ps: M'enfin, de quoi parle-t-on ! Il n'est fait aucun usage de code CSS dans les exemples données.

Ah... Non. C'est vrai. Si si .

Les couleurs de la légende sont uniquement générées via les styles CSS (ici, le bleu ##5498ff en arrière-plan d'un élément sans contenu):

<span style="background-color:#5498ff">    </span> - Nicolas Sarkozy

Les couleurs du maillot sont uniquement générées via les styles CSS (ici, le rouge #ff0000 en arrière-plan d'une image dont une partie est transparente):

<td bgcolor="#ff0000">
  <a title="Team colours" class="image" href="/https/fr.wikipedia.org/wiki/Image:Kit_body.png">
    <img height="59" border="0" width="38" src="http://upload.wikimedia.org/wikipedia/commons/b/bb/Kit_body.png" alt="Team colours"/>
  </a>
</td>

Il arrive que, sur Wikipédia, des gens dont c'est le métier ne racontent pas n'importe quoi. C'est pour cela qu'il écrivent des pages de documentation et de bonnes pratiques . Amicalement, --Lgd (d) 11 novembre 2008 à 19:40 (CET)

Tu confonds « commande style » et « CSS ». C'est gravissime ! Cela discrédite tout ton travail.   <STyx @ 2 décembre 2008 à 14:50 (CET)

Ah. Comme cela t'a déjà été expliqué, certaines choses doivent être précisées sur ce que sont les CSS, sur lesquelles tu sembles (malheureusement) faire une confusion suprenante. En particulier, il n'existe pas de « commande style » : il n'y a pas de « commandes » en HTML, mais des attributs dont la valeur a un type de contenu donné. Il n'existe qu'un attribut HTML style dont le rôle est d'inclure des données de présentation actuellement toujours du type de contenu CSS dans les pages HTML. En version simple, comme GillesC te l'a expliqué : le contenu d'un attribut style est du CSS.

Il est dommage que tu ne parviennes pas à dépasser pour l'instant ce petit cap de formation personnelle sur CSS : c'est un détail apparent, mais aux conséquences importantes sur ce que tu fais pour Wikipédia, au détriment de la valeur de tes contributions par ailleurs vraiment très utiles (J'ai été bluffé par beaucoup de choses dans la structure des modèles, en particulier). A ce stade, j'avoue ne plus trop savoir comment te l'expliquer. Peut-être un manuel d'initiation à CSS ? Un forum où tu pourras poser la question ? Je suis preneur de toute possibilité d'aboutir à passer ce cap. Cordialement, --Lgd (d) 2 décembre 2008 à 15:10 (CET)

• style="commandes de style" tu ergotes
• CSS signifie feuilles pas langage (c'est un gros abus de ... langage ; malheureusement répandu)
• « désactiver les CSS » c'est donc désactiver les feuilles ... et c'est bien différent de la désactivation des commandes de style (« Aucun style » avec Firebug)
• « Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. » : jusqu'à preuve du contraire « style sheets » signifie ... « feuilles de styles »
• stp arrête ce ton supérieur et tes propos insultant du style « j'avoue ne plus trop savoir comment te l'expliquer. Peut-être un dictionnaire ? Tu y verra qu'une feuille n'est pas un langage »   <STyx @ 9 décembre 2008 à 21:45 (CET)

J'observe vos échanges avec Lgd depuis un bout de temps et votre insistance à vouloir lui apprendre son métier est... navrante. Tout le monde peut se tromper, personne n'est infaillible. Mais ne pas vouloir le reconnaître, nier ainsi les évidences et le faire avec autant de mauvaise foi... Allons ! Reprenez-vous ! MammouthLand (d) 10 décembre 2008 à 16:19 (CET)

Bref il faut remanier la page pour clarifier le sens des occurrences de CSS.   <STyx @ 9 décembre 2008 à 21:45 (CET)

• Essayons un peu de littérature : le contenu de l'attribut style crée une feuille de style : un tutoriel, un autre tutoriel, un troisième tutoriel, un quatrième (de Microsoft), une note du W3C, le glossaire d'une méthode d'application de WCAG que je cite ici:

Feuille de style : langage css destiné à la mise en forme des éléments du contenu (exemples : couleur du fond de la page, taille/police/couleur des caractères, positionnement de l'information dans la page Web...). Les styles css peuvent être externes (fichier css), embarqués (déclarés dans l'en-tête de la page) ou en ligne (déclarés via l'attribut style d'une balise).

• La thèse d'Håkon Wium Lie, co-inventeur de CSS:

When CSS1 became a W3C Recommendation in 1996, the current HTML specification [HTML2 1995] did not specify how to link HTML documents to style sheets. Formally, it was outside the scope of the CSS specification to define the linking mechanism, but CSS1 showed a simple example of how it could be done:

<LINK REL=STYLESHEET TYPE="text/css" 
   HREF="http://style.com/cool" TITLE="Cool">
<STYLE TYPE="text/css">
   @import url(http://style.com/basic);
   H1 { color: blue }
</STYLE>

The LINK and STYLE elements were later added to HTML4 [HTML4 1997] along with the STYLE attribute:

<H1 STYLE="color: blue; background: red">

• la désactivation des feuilles de styles implique nécessairement les styles externes, les styles embarqués et les styles en ligne : Techniques For Accessibility Evaluation And Repair Tools, W3C, je cite:

Checkpoint 6.1 - Organize documents so they may be read without style sheets

Technique 6.1.1 [priority 1] Verify that the document is readable when style sheets are not applied.
Evaluation:
Elements:
LINK rel="stylesheet"
STYLE

At least one "style" attribute used on any element

• Désolé pour le ton, mais je fatigue un peu, là. --Lgd (d) 10 décembre 2008 à 05:55 (CET)

Meuh non Lgd, on ne perd jamais son temps à expliquer! à condition de rester calme. En tout cas ces tutorels m'ont l'air parfaits pour l'ignarde que je suis en matière de CSS. Je crois même que j'y comprends enfin quelque chose d'autre que les grands principes de base! Je vais peut-être enfin oser l'utiliser dans mon prochain site web (pour le moment, vu le faible nombres de pages, je continue encore à faire du cousu main!). A+ --amicalement, Salix ( converser) 10 décembre 2008 à 10:43 (CET)

A la main, ya que ca de vrai :) bayo 10 décembre 2008 à 11:01 (CET)

Puis désactiver les styles, c'est mettre son navigateur en mode old school ; on comprend bien qu'un vieux navigateur ne supporte pas les attributs style (PS : le CSS est bien plus vieux que ce que je pensais !) Le CSS est bien un langage (quelque soit son nom). Le contenu de l'attribut style est bien du CSS, même si ce n'est qu'une partie du langage (la partie déclarative, sans les sélecteurs...)

J'ai du mal à comprendre le débat, et quand bien il y a certainement mieux à faire que pinailler pour si peu. On sait bien que les bonnes pratiques ne seront jamais respectées à la lettre, quelque soit leur qualité (pardon si je choque :-) c'est comme ça que je le restant). C'est bien trop contraignant. Mais elles ont le mérite d'exister et au moins de sensibiliser et d'améliorer par-ci par-là les choses. bayo 10 décembre 2008 à 11:01 (CET)

A remanier

De manière globale, les recommandations ne sont pas mise en évidence, manque de clarté, de concision. Mais surtout, les problématiques sont mal exposées.

Certes c'est pas simple de nous mettre dans la peau d'un déficient ou d'émuler une configuration foireuse. Mais il y a une chose qui est flagrante, cette page manque d'accessibilité !   <STyx @ 11 novembre 2008 à 19:31 (CET)

ce sont surtout les bases de l'intégration XHTML CSS sur lesquelles tu peux profiter de l'occasion pour te former.

Pour ce qui est de la rédaction, les critiques précises, les propositions de reformulation, les exemples plus pertinents, etc. sont les bienvenus. J'avoue volontiers avoir plus l'habitude de traiter ce sujet dans le cadre de formations professionnelles que dans un cadre aussi incertain que celui de Wikipédia. N'hésites pas. Cordialement, --Lgd (d) 11 novembre 2008 à 19:44 (CET)

Combinaisons d'images via CSS

C'est faux ! La désactivation des CSS ne détruit pas l'affichage.

Je ne conserve la section que pour tu puisses te rendre compte de ta bourde.   <STyx @ 2 décembre 2008 à 15:01 (CET)

Encore une fois on confond « commande style » et « CSS ». C'est gravissime ! Cela discrédite tout ce travail.   <STyx @ 2 décembre 2008 à 14:57 (CET)

Upright

Pourrait-on expliquer sur cette page l'intérêt qu'il y a à utiliser "upright" plutôt qu'un paramètre de taille fixe? --amicalement, Salix ( converser) 8 avril 2009 à 12:44 (CEST)

Hum... C'est une question d'ergonomie, mais pas d'accessibilité, en fait. --Lgd (d) 8 avril 2009 à 12:46 (CEST)

Je sais, mais comme la nuance échappe à la plupart d'entre nous et que tu as été l'un des premiers à encourager son usage, je crois qu'il serait utile d'en toucher un mot ici, tout en rappelant bien sûr qu'il s'agit plus d'ergonomie que d'accessibilité . --amicalement, Salix ( converser) 8 avril 2009 à 17:44 (CEST)

lang

Bonjour, quel est l'intérêt d'uniliser la syntaxe ''[[Web accessibility Initiative| {{lang|en|Web accessibility Initiative}}]]'' plutôt que celle-ci : ''{{lang|en|[[Web accessibility Initiative]]}}'' ? Il faudrait le préciser. --amicalement, Salix ( converser) 18 juin 2009 à 09:34 (CEST)

Bonjour,

Dans le premier cas, l'attribut title du lien est renseigné correctement, pas dans le second (où il est vide). Or le title est parfois lu par défaut, selon la configuration de l'outil de consultation... il faut donc, s'il est présent, qu'il soit correctement renseigné. Litlok →m'écrire 18 juin 2009 à 10:14 (CEST)

Pas tout à fait

• Le title du lien est identique dans les deux cas (il est systématiquement renseigné sur tous les liens par mediawiki, sauf dans le cas très particulier de certains liens sur une image avec le paramètre link)
• La première syntaxe est une syntaxe de précaution vis à vis des rédacteurs: s'ils doivent mettre le modèle {{lang}} à l'intérieur du lien, sur l'expression précisément concernée, ils seront moins exposés à mêler différentes langues dans le modèle :
  • première syntaxe, ils sont incités à faire [[Web accessibility Initiative|{{lang|en|Web accessibility Initiative}} sur le site du W3C]]
  • Seconde syntaxe, ils risquent de nous faire des {{lang|en|[[Web accessibility Initiative|Web accessibility Initiative sur le site du W3C]]}}
• Par ailleurs, la restitution est plus fiable dans certains modes de consultation des liens de certaines configurations de Jaws avec cette syntaxe : le span lang autour du lien n'est pas toujours pris en compte quand le lien est lu hors contexte dans la liste des liens, ce qui n'est pas le cas du span lang dans le lien.

--Lgd (d) 18 juin 2009 à 11:08 (CEST)

Tiens, c'est bizarre. Tout à l'heure, j'avais fait un test en mode de prévisualisation entre les deux syntaxes, et en regardant le « code source de la sélection » sous Firefox. C'est peut-être l'empilement de ces couches qui a fait que le title était différent (?!?), car dans le premier cas, l'attribut title reprenait le contenu de l'élément a, en ajoutant (page inexistante), mais dans le second il était vide... et je n'ai pas rêvé . Ou alors, c'est peut-être le fait que la page n'existe pas qui a entraîné ce traitement différent. Ou bien encore, une interférence avec un script (monobouc ou Greasemonkey...). En tout cas, je viens de faire un test, et effectivement l'attribut title est identifique. Mais lorsque j'ai fait le test, l'attribut title était vide, et maintenant... il est renseigné. Et ce sur la même page. Je me demande si quelqu'un n'est pas en train de faire mumuse avec mediawiki ... Litlok →m'écrire 18 juin 2009 à 12:37 (CEST)

Si les dev se mettent à bouger le très fragile équilibre actuel sur le title des liens internes, même s'il n'est pas idéal et pas conforme à ATAG, je vais craindre le pire. Espérons que ce soit plutôt une interférence. --Lgd (d) 18 juin 2009 à 13:29 (CEST)

BTW, rien à voir si ce n'est l'accessibilité et le lang, mais un truc amusant: depuis la toute dernière mise à jour, deux des menus et le titrage H5 de l'interface sont joliement dotés de lang="fr" redondants avec celui du html. C'est inoffensif, mais je cherche encore dans quel cas de figure d'internationalisation c'est censé servir (j'ai essayé le chinois et ses deux variantes dans le même wiki, mais c'est pas ça). --Lgd (d) 18 juin 2009 à 13:32 (CEST)

Tableaux triables

Bonjour, il est dit qu'il faut éviter l'usage de deux modèles dans les tableaux triables mais existe-t-il un solution accessible ? --amicalement, Salix ( converser) 30 juin 2009 à 22:42 (CEST)

Hélas non.

Jargon: en l'état de l'art, un tri javascript accessible et sémantique dans un tableau utilise l'attribut HTML id des cellules pour y placer les clés de tri. Le script pourrait être réécrit en ce sens, mais ce serait impraticable car les rédacteurs ne sauront pas respecter les contraintes particulières qui s'appliquent à cet attribut (unicité du contenu dans la page en particulier).

Il faut se contenter de signaler le fait (et de reconnaître que beaucoup de tableaux triables n'ont en fait aucun besoin de l'être : je vois souvent passer des tableaux triables de 3 lignes...) --Lgd (d) 1 juillet 2009 à 06:12 (CEST)

Ok, j'ai retouché la section pour que ce soit bien clair. Vérifie quand même qu'il n'y a pas d'oubli --amicalement, Salix ( converser) 1 juillet 2009 à 09:20 (CEST)

A ajouter

Dans la section Images quid de l'alternative textuelle

• dans les galeries d'images?
• dans les infobox?
• dans les tableaux?

Il faudrait évoquer ces cas paticulier. --amicalement, Salix ( converser) 16 juillet 2009 à 10:42 (CEST)

arf.

Très bien vu, ce sont les questions du contributeur en effet : il aurait déjà les réponses avec le contenu actuel des BP, mais il ne les verra sans doute pas.

Todoïsé, donc. --Lgd (d) 16 juillet 2009 à 11:36 (CEST)

Question au sujet d'un bon exemple

Bonjour

Au sujet de l'exemple du point sur la carte, exemple donné dans le paragraphe Combinaisons d'images via CSS, es ce "faisable" de générer des images qui influeraient le symbole de position ? --Manu1400 (d) 5 février 2010 à 00:56 (CET)

Je ne suis pas certain de bien comprendre mais disons qu'il est tout à fait possible de réaliser une extension mediawiki générant des images de localisation (au sens d'images complètes). --Lgd (d) 26 février 2010 à 06:45 (CET)

tableaux de versions logiciel

Bonjour, une discussion sur la page Libre Office concerne les tableaux récapitulatif des versions. J'ai rien trouvé concernant la coloration de tableau contenant du texte, pas franchement de recommandation, ni ici ni coté charte graphique, alors je viens récolter des avis complémentaires aux bonnes volontés déjà a l’œuvre dans cette page et vous demander où ça serrait le plus judicieux de traiter ça de façon plus ou moins centrale. Merci. :-) 13 juin 2011 à 16:23 (CEST)

La question est plutôt à poser sur Discussion Wikipédia:Atelier accessibilité. Sinon, les critères à respecter en matière de contrastes de couleur sont indiqués dans utilisation de la couleur et dans choix de couleurs et contrastes :

• ne pas donner l'information uniquement par la couleur (ajouter une colonne explicite, ou bien scinder en plusieurs tableaux successifs)
• veiller aux contrastes suffisants (voir l'outil de mesure indiqué dans la bonne pratique).

Cordialement, --Lgd (d) 13 juin 2011 à 18:59 (CEST)

Ok, merci. :-) 14 juin 2011 à 09:19 (CEST)

Caption = |+ ?

Salut. Je viens de me rendre compte que dans le paragraphe Wikipédia:Atelier accessibilité/Bonnes pratiques#Tableaux de données il est indiqué « Utiliser autant que possible l'élément caption pour indiquer le titre du tableau » puis, un peu plus loin « Le titre de tableau est créé à l'aide de la syntaxe |+ ». Je suppose que l'élément caption est codé par |+ ? (En bref, c'est pas très clair pour les non-initiés Bon, je sors. --'toff ^[discut.] 14 juin 2011 à 04:21 (CEST)

Bien vu. Est-ce plus clair ainsi ? Cordialement, --Lgd (d) 14 juin 2011 à 08:34 (CEST)

Carrément ! Merci. --'toff ^[discut.] 14 juin 2011 à 08:51 (CEST)

Raccourci de section

Pourrait-on réflechir à la mise en place des raccourcis menant aux sections pour cette page ? Cordialement. --pixeltoo (discuter) 6 octobre 2011 à 22:05 (CEST)

Doubles, triples, multiples images

Bonjour, je viens de découvrir l'existence des modèles {{Image}}, {{Double image}}, {{Triple image}}, {{Multiple image}}, {{Double image verticale}}, {{Imagedual}}, {{Géolocdual}} ou encore {{Carte double}} dont la documentation renvoie à Wikipédia:Mise en forme des images où il est dit peu de choses et rien sur leur accessibilité. Doit-on décourager l'utilisation d'un ou plusieurs de ces modèles ? --Amicalement, Salix ( converser) 5 novembre 2011 à 22:03 (CET)

Pas grand chose à recommander ou pas pour le moment. J'ai commencé à regarder ce qu'on pourrait faire pour y intégrer correctement des thumbs, j'en suis juste aux essais (Utilisateur:Lgd/Double_image mais ça n'est pas vraiment parlant sans les styles CSS indiqués dans la page, mais pour le moment chargés nulle part). Cordialement, --Lgd (d) 21 février 2012 à 13:12 (CET)

Voici par exemple ce que donne donnait multiple image dans un article. --Amicalement, Salix ( converser) 21 février 2012 à 13:27 (CET)

modèle:en

Bonjour, par ricochets je tombe sur ça, qui signalait en 2009 un pb d'accessibilité avec ce genre de modèle. Est-ce toujours d'actualité ? Anne (d) 23 mai 2012 à 14:25 (CEST)

Je crois que oui, pas plus que les modèles du type {{PDF}}, puisqu’ils n’indiquent pas explicitement ce qui est en Anglais… --Pic-Sou 23 mai 2012 à 16:15 (CEST)

{{Indication de langue}} et {{Indication de format}} utilisent actuellement <abbr>, équivalent à l’utilisation de {{abréviation}} conseillée ici, donc j’aurais tendance à dire que ça a été résolu ? Ltrl G^☎, le 23 mai 2012 à 17:32 (CEST)

[edit] Le problème indiqué à l’époque semble résolu. Pour la clarté des intitulés, il est vrai que les title des modèles de langue ne sont pas forcément très adaptés. Ils me semblent déjà plus clairs pour {{pdf}}, mais il faudrait vérifier pour les autres. — Ltrl G^☎, le 23 mai 2012 à 17:45 (CEST)

Idéalement, il faudrait pouvoir remplir l’attribut lang du lien ou du paragraphe de citation correspondant… --Pic-Sou 23 mai 2012 à 19:06 (CEST)

L'introduction du tag abbr via {{Indication de langue}} et {{Indication de format}} a en effet réglé le problème pour ces modèles.

Pat eilleurs, attention par ailleurs à ne pas confondre l'indication de la langue de la cible des liens externes et l'indication de la langue de leur libellé :

• cible en anglais et libellé en français :

  {{en}} [http://www.w3.org/TR/WCAG20/ Règles pour l'accessibilité des contenus Web]

  Qui donne (en) Règles pour l'accessibilité des contenus Web
• cible en anglais et libellé en anglais :

  {{en}} [http://www.w3.org/TR/WCAG20/ {{lang|en|Web Content Accessibility Guidelines}}]

  Qui donne (en) Web Content Accessibility Guidelines

Cordialement, --Lgd (d) 23 mai 2012 à 20:03 (CEST)

Merci, c'est parfaitement clair même pour moi. Faudrait peut-être mettre à jour ou préciser cette page de "Bonnes pratiques"… Anne (d) 23 mai 2012 à 21:16 (CEST)

Mais ne faudrait-il pas plutôt se démerder pour que la cible soit indiquée comme étant en Anglais, en mentionnant les attributs lang et xml:lang de la balise <a> ? --Pic-Sou 23 mai 2012 à 22:05 (CEST)

lang ne sert pas à cela. Il existe un attribut HTML hreflang pour indiquer la langue de la cible, mais son utilité est en fait réduite (il ne joue aucun rôle en accessibilité, d'ailleurs) et il n'est pas implémenté par mediawiki. --Lgd (d) 23 mai 2012 à 22:11 (CEST)

Ah, ok… faute de mieux… --Pic-Sou 24 mai 2012 à 19:04 (CEST)

Pour une cible en anglais et un libellé en anglais, le modèle {{en}} gère correctement la combinaison suivante (depuis le 14 mai 2007…):

{{en|texte=[http://www.w3.org/TR/WCAG20/ Web Content Accessibility Guidelines]}}

Qui donne (en) Web Content Accessibility Guidelines. Cette syntaxe me semble généralement plus lisible. À l'arrière-plan, le modèle {{en}} fait appel au modèle {{lang}} pour un résultat tout aussi accessible. Je constate malheureusement les modèles correspondants pour d'autres langues ne gèrent pas encore tous ce paramètre : à voir au cas par cas, en attendant que quelqu'un (peut-être via un bot?) ne puisse les mettre tous à niveau. Klipe (discuter) 10 septembre 2013 à 14:05 (CEST)

Infobox à mettre en accessibilité

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)

Bibliographies

Bonjour. Dans la section sur les Wikipédia:Atelier accessibilité/Bonnes pratiques#Syntaxe wiki des listes à puces, listes numérotées, listes de définition, il est écrit qu'il faut « Éviter d'aérer le code en sautant des lignes entre chaque terme défini. Cela aurait pour conséquence de créer une liste de définition pour chaque mot. Tous les éléments de la liste doivent être collés les uns aux autres. ». Est-ce que cela concerne les (sous-)sections « bibliographie » ? Je reconnais que je n'ai pas bien compris quel était le problème d'accessibilité posé par les lignes entre chaque item (si c'est possible de m'expliquer brièvement, je suis preneur). Mais pour moi, une bibliographie (à la syntaxe touffue, donc les lignes de séparation facilitent la lecture du wikicode) diffère du cas où on a une liste du type « liste de définition » : phrase d'introduction-deux points-liste d'énumération. Non ?--Rehtse (discuter) 23 août 2013 à 14:20 (CEST)

Quelle que soit le type de la liste, il faut éviter autant que possible de la briser : les sauts de lignes transforment une liste avec plusieurs éléments en plusieurs listes contenant chacune un élément… On perd tout l’intérêt de la liste (du point de vue sémantique). Pour les lecteurs normaux (avec un navigateur graphique relativement récent, sans difficulté particulière d’accès et de lecture,…) ça ne change pas grand chose, une seule liste étant rendue (presque) exactement pareille à plusieurs. Mais ça peut poser des problèmes de lecture pour des programmes d’extraction de données ou des personnes utilisant un logiciel de synthèse vocale.

Mais retirer les lignes n’est pas la seule solution : tu peux aussi le remplir avec une astérisque seule, ce qui prolonge la liste sans ajouter d’élément. C’est ce que je fais habituellement sur les bibliographies, effectivement illisible sinon, je trouve le résultat assez lisible.

Cordialement — Ltrl G^☎, le 23 août 2013 à 15:17 (CEST)

Merci pour l'astuce, ça fonctionne très bien (j'ai un paquet d'article à améliorer de cette manière...). Et merci aussi pour l'explication (même si ma méconnaissance du domaine fait que je vois pas du tout quelle gêne peut être occasionnée par une liste de ce type en utilisant un logiciel de synthèse vocale, je te fais confiance).--Rehtse (discuter) 23 août 2013 à 16:14 (CEST)

Une synthèse vocale, quand elle rencontre une liste, énonce qu'il s'agit d'une liste de tant d'éléments. Pour donner une idée, si j’ai inséré des lignes superflues entre des items de liste A, B et C, la synthèse lira quelque chose comme « Liste de 1 élément, premier item A, liste de 1 élement, premier item B, liste de 1 élément, premier item C ». Si on n'insère pas de ligne, la synthèse lira « Liste de 3 éléments, premier item A, deuxième item B, troisième item C ». De plus, les lecteurs d'écran (qui sont utilisés par les synthèses vocales) donnent la possibilité de naviguer dans une liste. Cette possibilité disparaît quand la liste est fractionnée. Litlok (m'écrire) 24 août 2013 à 00:19 (CEST)

Super-clair, merci beaucoup. Ça motive pour corriger, et présenté comme ça, je risque encore moins d'oublier d'adopter la bonne démarche.--Rehtse (discuter) 24 août 2013 à 01:04 (CEST)

thumb/vignette

Bonjour

Pour permettre une meilleure accessibilité via lecteurs d’écran, n’est-il pas préférable de remplacer thumb par le français vignette, et les arguments right, left par leurs équivalents en français ? azoée (discuter)

Ces arguments n’étant visibles qu’à l’édition, tu t’intéresse à l’accessibilité de celle-ci ? — Ltrlg (discuter), le 21 octobre 2013 à 08:57 (CEST)

De plus les mots anglais ont l'avantage d'être compris partout sur les projets wikimedia, ce qui rend les traductions plus aisé, si on remplace systématiquement les mots anglais par leurs équivalant en français, les traductions depuis le français sera plus difficile.--Gratus (discuter) 21 octobre 2013 à 09:15 (CEST)

Il me semble tout de même que l’édition sera plus accessible aux francophones avec un code en français. Mais si cela est déjà permis techniquement, pourquoi s’en soucier, à chacun d’utiliser la syntaxe qu’il préfère et l’on verra bien ce qui sera choisi par les éditeurs sur le long terme (il s’opère une sorte de « sélection naturelle » des modèles et de la syntaxe). Et puis quasi tous les modèles ont été francisé, pourquoi pas le positionnement des images. Sans besoin réel, moi j’aurais bien vu le {{DEFAUTSORT: collaborer avec un homologue {{CLEDETRI: plus explicite pour le contributeur francophone. – A2 (discuter) 21 octobre 2013 à 09:46 (CEST)

D'autant que le modèle est bien "fichier:" et non pas "file:"...--Absinthologue (discuter) 21 octobre 2013 à 11:00 (CEST)

Je ne crois pas qu'on tue le contributeur en le forçant un peu à apprendre "left" et "file". Une encyclopédie, après tout, c'est fait pour apprendre aussi. Pas juste se faire des copains et ramasser de belles étoiles. Comme le souligne Gratus, garder la syntaxe compatible avec tout les projects mediawiki (pas seulement wikimedia) est un avantage majeur. En plus de la documentation qui est immanquablement meilleur pour les termes anglais. Permettre le mot vignette oui, le remplacer non. Iluvalar (d) 21 octobre 2013 à 16:34 (CEST)

Débat sans pertinence, l'un ou l'autre, c'est strictement équivalent, chacun peut faire ce qu'il veut. Mais remplacer l'un par l'autre, c'est perdre son temps... • Octave.H ^hello 21 octobre 2013 à 16:49 (CEST)

Octave.H (d · c · b) : et dans le cas de lecteur d’écran pour aveugles ? Ne vaut-il pas mieux des termes francophones quand on est lu en français ?

Si vous trouvez ce remplacement utile, est-ce d'une utilité limitée, très limitée ? azoée (discuter) 21 octobre 2013 à 17:09 (CEST)

@ Azoee : « quand on est lu en français » → quand on est écrit en français. Les lecteurs purs (aveugles ou non) de Wikipédia ne voient aucune différence, seuls les contributeurs la verront — Ltrlg (discuter), le 21 octobre 2013 à 19:54 (CEST)

Justement, non : lis Discussion Wikipédia:Accessibilité, le lecteur d’écran lis tous les mots. Par exemple en haut d’une page il lit « lienCréeruncomptelienseconnecterArticlelienDiscussionlienLirelienModifierlienAfficherl'historiquelienrechercher ». Du coup, je me dis (et cette discussion signale aussi) que si on peut alléger un peu la monotonie de tous ces termes sans intérêt, c’est peut être intéressant. azoée (discuter) 21 octobre 2013 à 19:58 (CEST)

…lit tous les mots se trouvant à un endroit où ils peuvent l’être ; ce n’est pas le cas ici — Ltrlg (discuter), le 21 octobre 2013 à 20:08 (CEST)

┌────────────────────┘
Je suis face à un conflit d’autorité : Le témoignage de Saburry semble indiquer que les mots File:XXX|thumb|left|Légende sont lus ; Et toi tu me dis que non. Est-ce que je teste un lecteur d’écran ? azoée (discuter) 21 octobre 2013 à 21:17 (CEST)

Tu as manifestement mal compris le témoignage (à propos des images : « L'alternative textuelle (« Vue aérienne d'un bâtiment... ») est lue par la synthèse vocale ou traduite en braille mais n'est pas accessible aux autres lecteurs de la page. Ensuite la légende (« Le Palais du Heysel ») est lue en indiquant le lien avant « Heysel » ». Il n’est pas question de thumb). Je pense que tester une lecteur d’écran peut être une bonne expérience (je devrais d’ailleurs le faire aussi ) — Ltrlg (discuter), le 21 octobre 2013 à 21:43 (CEST)

À un autre endroit, il est donné comme exemple : Lien graphique File:UAZ-469_in_Tajikistan.jpg », suivi de la légende. L'aveugle est contente d'entendre « UAZ-469_in_Tajikistan.jpg. Donc moi aussi je vais essayer un lecteur d’écran. azoée (discuter) 21 octobre 2013 à 21:50 (CEST)

Et à un autre endroit : Par ailleurs, on me précise que tant qu'à faire, tout en rajoutant des « alt », on peut aussi franciser les liens photos en mettant « vignette » au lieu de « thumb », « droite » au lieu de « right », « gauche » au lieu de « left », et « fichier: » au lieu d'« image: » ou « file: »..

Pour le premier : quel rapport avec le thumb ? Le problème vient ici de l’absence d’alternative textuelle.

Pour le second : certes, mais c’est un ajout ne provenant pas du témoignage (« Par ailleurs ») qui a plus rapport à la simplicité de la syntaxe pour le nouveau qu’à l’accessibilité aux aveugles.

— Ltrlg (discuter), le 21 octobre 2013 à 22:03 (CEST)

Ce qui importe pour le lecteur d'écran, c'est le code HTML qui est produit. En l'absence d'alternative textuelle, c'est le nom du fichier qui est restitué (donc ici « UAZ-469_in_Tajikistan.jpg »). S'il y a une alternative, c'est celle-ci qui est restituée. En mode consultation donc :

• File n'est jamais lu
• thumb n'est jamais lu
• left n'est jamais lu

C'est tout. Ces instructions sont là, pour permettre à mediawiki de savoir que l'on va faire un lien vers une image, avec telles dimensions et alignée à gauche. Cela n'a aucune influence sur le texte qui est restitué par un lecteur d'écran (et notamment vocalisé par une synthèse vocale ou affiché par une plage Braille). Litlok (m'écrire) 21 octobre 2013 à 22:08 (CEST)

Bien, on avance. Merci.

Je francisais faute de mieux (en première étape avant ajout de alt, parce que j’ai déjà essayé de construire des alternatives textuelles, mais faire concis, tout en ayant la certitude d’être utile, ne m’est pas souvent arrivé.

Donc je vais devoir m’atteler au gros morceau. Merci. azoée (discuter) 21 octobre 2013 à 22:20 (CEST)

Taille des articles

Bonjour, pourrait-on ajouter une section sur la taille optimale des articles qui ne pénaliserait pas ceux qui ont une connexion ou du matériel un peu lent ? -- Amicalement, Salix ^[Converser] 2 janvier 2014 à 11:04 (CET)

Bonjour

Par le passé, certains référentiels (comme le référentiel AccessiWeb 1.0) comportait des recommandations sur la taille des pages, mais ces contraintes n'ont jamais été normatives. Tout au plus pourrait-on recommander de ne pas ajouter de contenu superflu, mais il n'y aurait pas d'impact concret pour le contributeur sur Wikipédia. Avec mon skin personnalisé, par exemple, le poids du contenu HTML de cette page ne représente qu'environ 5% de son poids en tenant compte du JavaScript et des CSS, et ce sans même compter les images. En fait, à moins d'avoir une page extrêmement riche en illustrations, le poids du JavaScript représente la quasi-totalité de celui de la page (ici, par exemple, plus des 4/5). Donner des recommandations sur la taille des articles n'aurait donc que très peu d'impact sur le poids final de la page : cela ajouterait au final une contrainte forte sur le contributeur, sans gain réellement appréciable pour l'utilisateur. Les gains en poids ne sont pas à chercher dans le texte voire dans les illustrations, mais bien dans le JavaScript. Litlok (m'écrire) 2 janvier 2014 à 15:03 (CET)

Wikidata dans les infobox et lecteurs d'écran

Bonjour, les infobox sont-elles lisibles en bon français par un lecteur d'écran quand elles sont remplies via Wikidata (voir Wikipédia:Sondage/Wikidata Phase 2). Merci de faire des tests avec les articles de cette liste : Pages liées au modèle Wikidata. -- Amicalement, Salix ^[Converser] 3 février 2014 à 12:12 (CET)

Bonjour,

Ce qui importe aux lecteurs d'écran n'est pas la manière dont le code est généré, mais bien le code HTML lui-même. À moins qu'un appel à Wikidata ne change par exemple un title sur un lien, ou un lang, je ne vois pas en quoi ce passage pourrait avoir un impact. Litlok (m'écrire) 3 février 2014 à 13:11 (CET)

Mais justement l'infobox, côté code semble incompréhensible, avec des contenus ainsi libellés :

| réalisation = {{Wikidata|P57}}

| scénario = {{Wikidata|P58}}

| acteur = {{Wikidata|P161}}

| production = {{Wikidata|P272}}

Comment le lecteur d'écran parvient-il à rendre ces données intelligibles et modifiables par un mal voyant ? -- Amicalement, Salix ^[Converser] 3 février 2014 à 13:55 (CET)

Il y a deux points de vue :

• du point de vue de la consultation de contenu, cela n'a aucun impact ;
• du point de vue de la modification, cela n'en a ni plus ni moins que pour un utilisateur utilisant un navigateur graphique. Ce genre de code n'est pas moins accessible que le code d'une page wiki « standard » : il est tout aussi cauchemardesque. Un utilisateur qui pourrait modifier le code wiki avec un lecteur d'écran a déjà l'habitude de ces syntaxes biscornues, notamment dans les appels de modèle ou les tableaux, donc a priori cela n'a pas non plus d'impact particulier par rapport à de « simples » appels de modèles dans les infobox. En deux mots, c’est déjà b...élique, cela ne l’est pas plus avec l’ajout de Wikidata . Litlok (m'écrire) 3 février 2014 à 14:04 (CET)

Taille du texte

Bonjour, il nous manque une section traitant de la possibilité (ou non) de modifier ponctuellement la taille du texte par des balises ou des modèles. Une intervention comme celle-ci (pour un qui le dit, beaucoup d'autres doivent le penser) fait se poser la question de l'opportunité des "small" et autres {{petit}} glissés un peu partout par ceux qui ont une oeil de lynx. Certains connaissent assez leur interface pour zoomer/dézoomer à volonté, d'autres sauront peut-être bidouiller leurs préférences, mais c'est loin d'être le cas de tous nos lecteurs, surtout quand on change souvent d'appareil pour consulter l'encyclopédie. -- Amicalement, Salix ^[Converser] 16 avril 2014 à 14:36 (CEST)

Modèle langue et noms anglais

Bonjour, est-il utile (souhaitable ?) de placer le modèle {{langue}} pour les noms d'artistes ou de groupes ? L'article Hellfest est proposé au label BA, aussi est-ce l'occasion de le parfaire. Il est truffé de noms anglophones, par exemple Iron Maiden, qui risque d'être prononcé « y rompt mes dents » ; le problème est que le texte source va être considérablement alourdi en insérant le modèle en question. Alors, est-ce que c'est recommandé ?--Rehtse (discuter) 29 avril 2014 à 16:52 (CEST)

J'ai en partie ma réponse, après avoir installé un lecteur sur mon ordi. Certains noms sont lus « correctement » en anglais, d'autres pas : « i-rond » pour Iron, « Marie l'un ment son » pour Marilyn Manson. Alors ma question reste posée, vaut-il mieux placer le modèle langue systématiquement ?--Rehtse (discuter) 29 avril 2014 à 17:07 (CEST)

Conflit d’édition —  Rehtse Bonjour, si tu ne veux pas que les utilisateurs de lecteur d'écran entendent des « y rompt mes dents » partout, il n'y a pas d'autre solution, à part leur faire lire l'article anglais à la place . Si la prononciation francisée est compréhensible (Hellfest, hard rock, black metal...) on peut à la rigueur s'en passer, mais sur Deuheup purepleu (Deep Purple) c'est mieux ! Bon courage. La prochaine fois, fais un article sur un accordéoniste ou un joueur de biniou français . -- Amicalement, Salix ^[Converser] 29 avril 2014 à 17:11 (CEST)

Double image

Les modèles tel {{double image}}, {{triple image}} sont déconseillés car la taille d'image est définie en pixels.

J'ai réalisé un modèle avec la même fonctionnalité basé sur <gallery> qui n'a plus besoin de taille en pixel : Utilisateur:Zebulon84/Mod12

Pour le moment la taille ne varie pas en fonction des préférences utilisateur, mais peut-être qu'un jour les développeurs de MediaWiki ajouterons cette fonction aux gallery.

C'est suffisant pour ne plus déconseiller l'usage dans le l'espace encyclopédique ?

Zebulon84 (discuter) 5 mai 2014 à 21:44 (CEST)

Excellente initiative Zebulon84 ! Je suis loin d'être spécialiste en code, mais à première vue cela semble déjà bien mieux, surtout avec les alt. Est-ce que tu as prévu le même principe pour remplacer Modèle:Multiple image ? -- Amicalement, Salix ^[Converser] 5 mai 2014 à 23:17 (CEST)

Cela me semble aussi bon. Merci pour le boulot ! Litlok (m'écrire) 5 mai 2014 à 23:48 (CEST)

Je me suis aperçu que mon modèle s'affichait très mal sous ie7, donc je l'ai mis de coté quelque temps. Je viens de le reprendre, en transformant le div-display:table en vrai table.

Je viens donc de créer {{Images}}. -- Zebulon84 (discuter) 30 juillet 2014 à 07:32 (CEST)

Infobox/Titre avec icône

Pour améliorer l’accessibilité, j'ai reprogrammé ce module d'infobox pour :

• qu'il n'utilise plus de table imbriquée,
• n'utilise plus de <th> alors qu'on ne peut pas vraiment lui attribuer de scope,
• permette de ne pas faire de lien vers l'icône (si elle est dans le domaine public),
• permette d'ajouter une alternative dans si on garde le lien.

J'ai essayé de mettre à jour la doc, mais je ne sais pas si mes exemples sont appropriés. Pouvez-vous la relire ?

Zebulon84 (discuter) 17 mai 2014 à 17:28 (CEST)

Salut  Zebulon84 : ! Merci de ta contribution. Alors je vais tenter de te répondre au mieux puisque cela fait bien deux ans que je n'ai plus fait cet exercice.

• J'ai raccourci les exemples d'alternatives textuelles. Vu que l'icône n'apporte pas d'information, il faut juste éviter que le nom de son fichier soit lu à haute voix (ce qui arrive lorsqu'il y a un lien sur image sans alternative). Donc l'alternative textuelle est aussi courte que possible.
• alt={{alternative icône|}}|link={{#if:{{{pas de lien|}}}||http://fr.wikipedia.org/wiki/File:{{#if:{{{3|}}}|{{{3|}}}|Nuvola apps important.png}}}}|]]
• Tu fais appel à {{alternative icône}} qui n'existe pas, je suppose que tu voulais introduire un paramètre.

Pour le reste, ça me semble vraiment très bien. Lorsqu'il n'y a pas de lien, l'alternative textuelle est vide, ce qui est très bien. Une amélioration qui va dans le bon sens. :-) Dodoïste ^{[ dring-dring ]} 18 mai 2014 à 15:33 (CEST)

Merci. J'ai corrigé le alt, Je voulais effectivement faire appel au paramètre et non à un modèle : alt={{{alternative icône|}}}. – Zebulon84 (discuter) 18 mai 2014 à 15:43 (CEST)

:-)

J'oubliais de prendre en compte les erreurs que pourraient faire les Wikipédiens. Si il n'y a pas de lien, certains contributeurs risqueraient de renseigner tout de même l'alternative textuelle (en voulant bien faire). J'ai fait en sorte que cela ne soit pas possible : {{#if:{{{pas de lien|}}}||{{{alternative icône|}}}}}.

Au fait, sais-tu que les icônes créditées dans Wikipédia:Crédits graphiques n'ont pas besoin d'avoir un lien ? Dodoïste ^{[ dring-dring ]} 18 mai 2014 à 16:31 (CEST)

Je savais qu'il y avait une telle page, mais je ne l'ai jamais cherchée. On peut éventuellement l'ajouter à la documentation, mais je crains que cela rende le message plus confus. – Zebulon84 (discuter) 18 mai 2014 à 17:20 (CEST)

En effet, ce n'est pas à ajouter à la page de documentation. Mais ça pourrait servir à régler le problème d'une autre manière. On peut faire la liste des icônes utilisées avec ce modèle, les mentionner sur Wikipédia:Crédits graphiques, et modifier le modèle Titre avec icône pour qu'il ne génère que des icônes sans lien ni alternatives textuelles. Par contre, cette approche nécessite un robot pour faire la liste des icônes utilisées.

Je mentionne cette possibilité au cas où cela te semblerait intéressant (et parce que je venais de m'en rappeler). C'est aussi une option qui peut être utilisée dans d'autres situations, si besoin. Dodoïste ^{[ dring-dring ]} 18 mai 2014 à 17:45 (CEST)

Photomontage

Je viens de découvrir le modèle {{Photomontage}} créé par Zorion le mois dernier, utilisé par les pages de la catégorie Infobox Subdivision administrative - Image mal codifiée

On doit pouvoir adapter l'Infobox pour ne pas catégoriser ces pages, mais ce modèle est-il acceptable pour l'accessibilité ?

Zebulon84 (discuter) 12 juin 2014 à 11:42 (CEST)

Bonjour Zebulon84, il utilise apparemment les tableaux imbriqués, qui ne sont pas accessibles, et je doute que ceci {{!}} soit reconnu comme précédant une alternative textuelle. -- Amicalement, Salix ^[Converser] 12 juin 2014 à 16:39 (CEST)

Salut Zebulon84 ! :-)

Alors comme le dit très justement Salix, les tableaux imbriqués (un tableau contenu dans un tableau, style poupée russe) sont à proscrire. Bonnes pratiques#Cas général.

Ensuite, vu qu'il s'agit d'un tableau utilisé pour de la mise en forme, il faut qu'il soit aussi dépourvu que possible de structure, afin qu'un lecteur d'écran comprenne qu'il s'agit d'un tableau de mise en forme. Or ce tableau comporte plusieurs éléments <tr>. Si possible, il vaudrait mieux utiliser l'élément <DIV> que le tableau. Bonnes pratiques#Tableaux de mise en forme

Enfin, ce modèle ne permet pas d'insérer des alternatives textuelles pour les images. Salix, je n'ai pas compris ce que tu voulais dire par rapport à {{!}} ? Dodoïste ^{[ dring-dring ]} 12 juin 2014 à 17:37 (CEST)

 Dodoïste c'est ce sépare le nom du fichier de ce qui s'affiche dans une bulle au survole (et qui pourrait faire office d'alternative). -- Amicalement, Salix ^[Converser] 12 juin 2014 à 17:40 (CEST)

Ahh, j'ai compris Salix. Tu parles de « {{!}}description de l'image » dans l'exemple donné. Oui, il faudrait que ce soit « {{!}}alt=description de l'image » pour que ce soit accessible. Dodoïste ^{[ dring-dring ]} 14 juin 2014 à 12:39 (CEST)

J'ai modifié le modèle pour qu'il n'y ai plus de tables imbriquées.

J'ai modifié la documentation pour ajouter l'alternative via {{!}}alt=alternative à l'image

Il ne reste plus qu'à ajouter cette alternative dans les exemples. Je vous laisse faire.

Zebulon84 (discuter) 16 août 2014 à 11:36 (CEST)

Merci Zebulon84, c'est déjà une nette amélioration. :-)

Je viens de réaliser que ce modèle est utilisé dans les infobox (j'aurais dû tilter de suite quand tu as parlé d'images dans les infobox en introduction...). L'infobox est aussi faite à partir d'un tableau. Donc quand ce modèle photomontage est inclus dans l'infobox, cela fait un tableau imbriqué. Donc avant ta modification il y avait 3 niveaux d'imbrication de tableaux, maintenant c'est réduit à 2, ce qui est déjà un pas dans le bon sens. Dodoïste ^{[ dring-dring ]} 16 août 2014 à 14:54 (CEST)

Images remarquables
Description	Sélection par département français
01. Ain 02. Aisne 05. Hautes-Alpes 06. Alpes-Maritimes 07. Ardèche 08. Ariège 09. Aude
Source	catégorie Wikimedia Commons

Noter que l'utilisation d'un tableau n'est pas nécessaire du tout depuis que MediaWiki supporte le photomontage directement dans ses galeries (avec "mode=packed-overlay", ou "packed-hover", qui permet de recadrer les photos pour qu'elles s'alignent horizontalement à la même hauteur, en ajustant leur largeur si possible dans les limites d'un facteur d'agrandissement ou réduction de la hauteur initialement indiquée mais sans agrandir au delà de la taille native d'une image bitmap, puis en équilibrant les marges horizontales sur chaque rangée ; la hauteur suggérée par défaut, avant son ajustement automatique selon les images qu'on peut placer sur chaque rangée avec une marge minimale de quelques pixels suppplémentaires entre elles, peut être indiquée avec "heights=" ; le mode "packed-overlay" est pour les galeries dont les images sont de hauteur suffisante pour afficher leur légende par dessus en survolant l'image, sinon "packed" doit être utilisé (la légende sera visible en dessous). La syntaxe peut être

<galery mode="packed-hover" heights="100" style="...">File:Name1.jpg|Légende1↲File:Name2.jpg|Légende2</galery>, ou bien

{{#tag:galery|File:Name1.jpg{{!}}Légende1↲File:Name2.jpg{{!}}Légende2|mode=packed-hover|heights=100|style=...}}.

Cette syntaxe ne génère aucune table, juste des "div", mais l'ajustement automatique nécessite Javascript, sinon les images restent affichées toutes à la hauteur indiquée. Exemple ci-contre qu'on peut inclure dans une table étroite.

Verdy p (discuter) 13 janvier 2018 à 19:14 (CET)

listes à puces

 Rehtse : Salut. Je peine à imaginer un exemple pertinent pour cette proposition. Pourrais-tu élaborer ? Merci. Dodoïste ^{[ dring-dring ]} 14 juin 2014 à 16:24 (CEST)

 Dodoïste : oui. J'ai déjà discuté de ça ici, et cette « technique » permet d'alléger la lecture du code pour ceux qui modifient le code (ou « pire », l'éditeur de WPCleaner) plutôt que de passer par l'éditeur visuel. Exemple, cette section de Watergate.--Rehtse (discuter) 14 juin 2014 à 18:26 (CEST)

Merci  Rehtse. Je partage le besoin d'améliorer la lisibilité du wikitexte, et cette solution est certainement la meilleure dont on dispose actuellement. Le logiciel MediaWiki enlève cette puce vide de la liste, ainsi cela ne pose pas de problème d'accessibilité pour les personnes qui consultent les articles.

Ceci dit, je ne pense pas que ce soit parfait non plus. Puisque le problème est le manque de lisibilité du wikitexte, la solution sur le long terme c'est l'éditeur visuel. Or justement, il ne peut pas interpréter de la même manière que MediaWiki ces puces vides. Donc ces puces vides s'affichent à l'édition. Spontanément, un utilisateur de l'éditeur visuel aurait envie de corriger cette erreur en enlevant la puce vide, non ? Je concède que je m'éloigne nettement des problématiques d'accessibilité. Mais le but de ces bonnes pratiques c'est de proposer des solutions pérennes, et je me demande si celle-ci l'est vraiment ? Est-ce que d'autres personnes ont un avis à ce sujet ?  Litlok ? Dodoïste ^{[ dring-dring ]} 15 juin 2014 à 00:59 (CEST)

Si un utilisateur de l'éditeur visuel supprime la puce vide, alors cela n'a aucun impact puisqu'elles sont de toutes manière ignorées... Je ne vois pas d'inconvénient à les conserver. Si elles sont supprimées, tant pis mais du moment que cela n'a aucun impact sur le code HTML, peu importe... Litlok (m'écrire) 15 juin 2014 à 01:05 (CEST)

Ces « puces fantômes » ne sont utilisées que par les contributeurs qui modifient fréquemment des articles denses. Si quelqu'un venait à supprimer ces puces, rien ne leur interdit de les remettre (toujours dans l'optique de suivre régulièrement le code de ces articles, non pas par choix esthétique), puisque ce n'est pas affiché en « mode lecture » des articles. Je rappelle que l'éditeur visuel colle régulièrement des nowiki (entre autre) dans le code, ce n'est pas pour ça qu'on remet en cause la mise en place de l'éditeur visuel, et l'éditeur wiked en ce moment colle inutilement des « nbsp » autour des caractères de ponctuation qui n'en nécessite pas, et personne n'arrête de l'utiliser pour autant. L'inconvénient des puces de mise en page du code me paraît faible par rapport à leur intérêt (et je rappelle que ce choix est relativement rare, dans les cas de listes touffues).--Rehtse (discuter) 15 juin 2014 à 01:25 (CEST)

Tableau que je ne sais comment améliorer

Bonjour,

j'ai un problème avec un tableau que je n'arrive pas à améliorer. Il s'agit du tableau des appariements du tournoi des candidats (celui qui est dans la boite déroulante) dans l'article Championnat du monde d'échecs 2013. En fait, il n'a pas vraiment 'en-tête de colonne, le en-tête ayant je crois été considérés comme sous-entendus par la personne qui a fait le tableau. Est-ce que je reste dans la même logique et je garde juste un en-tête général avec un scope ? Merci beaucoup.--Soboky ^{[me répondre]} 2 août 2014 à 09:06 (CEST)

 Soboky : Salut. Alors en l'état mettre des scopes cela empirerait la situation. Tous les scopes de colonnes seraient appliqués à toutes les cellules en-dessous. Donc ils s'additionnent. Au 4ème pseudo-tableau, il y aurait 4 en-têtes cumulés pour une cellule de donnée.

Pour comparer avec une situation familière, prenons un aveugle dans le bus/métro/train. En temps normal, une voix indique le nom de l'arrêt auquel on arrive. Eh bien ce serait comme si la voix récitait systématiquement tous les noms des arrêts déjà parcourus en plus de celui auquel on arrive, sans discrimination. Ce serait super inutile et ne ferait qu'augmenter la confusion.

Ce qu'il faudrait faire, c'est casser ce tableau en pleins de petits tableaux accessibles.

Sinon c'est aussi possible de mettre ces en-têtes généraux (Ronde "date") en titres de lignes, avec un rowspan.

Faire des en-têtes plus spécifiques serait utile. Ce n'est pas la priorité, il faut d'abord choisir une des deux options ci-dessus. Cordialement, Dodoïste ^{[ dring-dring ]} 2 août 2014 à 21:35 (CEST)

Cartes

Bonjour, Je cherche comment rendre accessible une carte dans la page géologie du Tarn. Quelqu'un peut-il y jeter un œil et me dire ce qu'il en pense ? Merci. --PANDA 81 je t'écoute 3 avril 2015 à 23:55 (CEST)

Tableau triable

Je ne suis pas d'accord avec la règle qui recommande d'éviter l'utilisation des tableaux triables, car cela revient à supprimer une fonctionnalité utile pour la très grande majorité des utilisateurs. C'est une interprétation abusive des règles d'accessibilité dont l'objet n'est pas de réduire l'accès à une fonctionnalité. D'ailleurs cette règle n'est pas présente dans la version anglophone.

S'il y a réellement un problème, c'est le logiciel Mediawiki ou les modèles de clés de tri qu'il faut corriger : lorsqu'une fonctionnalité est cassée, on la corrige ou on la retire, mais on ne dit pas aux gens de ne pas l'utiliser... Seudo (discuter) 6 juin 2015 à 04:55 (CEST)

Bonjour Seudo Comme un peu partout dans WP, des contributeurs ont créé des codes pour obtenir des mises en pages qui ne sont pas prévues par le wiki de base. En fonction de leur impact négatif sur l'accessibilité, certains peuvent donc être tolérables à petite dose dans quelques articles, d'autres devraient être réservés aux pages de discussion ou seulement à quelques pages de travail et de statistiques des projets et aux pages personnelles. Voilà pourquoi ils ne sont pas interdits dans Wikipédia, mais déconseillés dans les articles. Maintenant, si tu arrives à convaincre Mediawiki d'ajouter cette fonctionnalité de façon à satisfaire tous nos lecteurs, quel que soit le type d'appareil qu'ils utilisent pour consulter Wikipédia, y compris les lecteurs d'écran, personne ne devrait s'y opposer . -- Amicalement, Salix ^[Converser] 6 juin 2015 à 10:08 (CEST)

Ahem... Cette bonne pratique, mise en place bien avant une évolution décisive de mediawiki, est tout simplement obsolète aujourd'hui (mais il faudrait vérifier que tous les emplois des modèles de tri concerné ont bien évacué le souci). --92.90.26.58 (discuter) 8 juin 2015 à 13:53 (CEST)

Le modèle {{Smn}} ne me parait louche. Ce n'est plus pour le tri mais pour aligner les chiffres. Mais je ne m'y connais pas assez en accessibilité pour dire si c'est vraiment un problème. Les autres modèles ne posent normalement plus de problème d’accessibilité s'il sont correctement employés, ce qui devrait être le cas pour les nouveaux tableaux (pour ceux existant la recommandation sur WP:AA/BP est de tout façon peu utile). — Zebulon84 (discuter) 8 juin 2015 à 14:16 (CEST)

Franchement je ne vois pas quel est le problème avec un tableau triable qui n'ôte rien à l'accessibilité à la lecture. C'est une fonction non pas pour la lecture elle-même mais pour faciliter la consultation par une présentation alternative, surtout quand le tableau contient beaucoup de données: le problème d'accessibilité est plutôt l'existence de tableaux ayant trop de données et qu'il conviendrait de scinder en plusieurs parties (limiter le nombre de colonnes de données, pour créer au besoin un autre tableau reprenant en tête de ligne les libellé nécessaires pour les identifier ; d'autre part cela facilite le travail de mise à jour de ces données et évite de tout casser).

Sinon la présentation des tableaux (notamment les alignements) sont aussi là pour faciliter la lecture. Ce n'est pas forcément simple à éditer en "wikicode" et parfois on a besoin de modèles d'assistance pour formater les éléments (ou une sous-page transcluse comme un modèle pour formater plus facilement une ligne complète du tableau). Le tableau doit s'alléger à la lecture de ce qui peut gêner la lecture, mais peut s'enrichir d'éléments qui la facilite comme la mise en évidence de certaines valeurs pour lui donner une forme synthétique montrant mieux ce qu'on devrait y voir.

Le tri reste utile dans tous les cas quand il y a beaucoup de lignes et plusieurs colonnes de données. S'il n'y a qu'une colonne, pas besoin de tableau évidemment, puisqu'alors c'est une simple liste qu'on peut (et devrait) compacter en "multicolonne" si les items sont pas trop larges (n'atteignant pas "40em", généralement avec une largeur de "10em" à "24em", avec un gap de "2em" pour les puces des listes non ordonnées, ou un gap de "2.5em" pour les numéros d'item des listes ordonnées). Si les listes ont peu d'items et les items sont peu larges, on va même les compacter mieux encore en faisant des énumération horizontales sans colonnes dans le même paragraphe (avec juste des ponctuations de séparation). Verdy p (discuter) 13 janvier 2018 à 19:49 (CET)

Né le vs ° et mort le vs †

Bonjour,

Les historiens utilisent souvent les symboles ° et † pour indiquer les dates de naissance et de décès. Je me demandais ce qui en est de l'accessibilité de ces symboles présents dans un certain nombre de biographies ? Est-il recommandé de les remplacer par « né le » et « mort le » ou faut-il respecter le choix du rédacteur ?

Merci, Cymbella (discuter chez moi) - 16 avril 2017 à 18:46 (CEST)

Au sein d'une phrase, on met des mots. Mais dans une simple expression entre parenthèses, ou dans une liste énumérant des noms dont on précise les dates de naissance et décès pour mieux l'identifier, l'usage d'abréviation est préférable pour faciliter la lecture du reste du texte ou ne pas trop allonger les items des listes et garder ces listes compactes (notamment dans une présentation à colonnes étroites (width="16em" environ) pour les listes énumérant de nombreuses personnes, plus d'une vingtaine, ou dans des tables dont une colonne contient des noms de personnes). La lisibilité étant meilleure avec ces abréviation, elles sont plus accessibles, le contexte et l'usage étant assez clair pour indiqué qu'il s'agit de dates de naissance et de décès (dont on précise au minimum l'année complète et pas seulement les deux derniers chiffres). Verdy p (discuter) 13 janvier 2018 à 19:23 (CET)

 Verdy p et Cymbella : l'accessibilité est loin de se limiter à la lisibilité. Je viens par exemple de faire un test rapide avec NVDA : le titre « Né le vs ° et mort le vs † » est lu "né le véesse (deg ou degré? un mot difficile à comprendre) et mort le véesse ". Le caractère † est complètement ignoré, et le ° n'est pas du tout retranscrit comme « naissance ». Ils sont donc vraiment à éviter… Litlok (m'écrire) 13 janvier 2018 à 21:17 (CET)

Tu choisis justement le cas que j'ai décrit et qui proscrit cet usage au milieu d'une phrase. Mais là dans ton exemple c'est pire : on n'a jamais besoin de mettre en même temps les symboles et les mots, c'est l'un ou l'autre, la phrase complète ou la forme abrégée ! Sinon il est conseillé de décrire ces symboles abréviatifs (avec <span title="né le">°</span>) si on les utilise. Même chose que pour d'autres abréviations pour les lecteurs écran comme les unités : 12 <span title="kilomètres">km</span> Verdy p (discuter) 13 janvier 2018 à 21:24 (CET)

Exemple : Nom de l’ouvrage, Jean Machin (°1901 – †1998), 1942, rééd. Nouvelles Édition, Paris, 2007.

Verdy p (discuter) 13 janvier 2018 à 21:24 (CET)

 Litlok : Merci pour ce retour ! J'avais même oublié que j'avais posé cette question, mais dorénavant je n'hésiterai pas à remplacer ces symboles peu accessibles par une expression plus lisible. - Cordialement, Cymbella (discuter chez moi) - 13 janvier 2018 à 21:26 (CET)

Tableaux triables sur les pages d'homonymie de patronymes

Pour info, une discussion a été lancée sur le Bistro à propos du classement des personnalités sur les pages d'homonymie (voir discussion au Bistro du 27 août 2018 et suite discussion au Bistro du 28 août 2018, s'en est suivie une discussion sur la page du Discussion Projet:HomonymieProjet:Homonymie dans laquelle la mise en place de tableaux triables est envisagée. - Cymbella (discuter chez moi) - 28 août 2018 à 22:09 (CEST)

Accessibilité du Modèle:Boîte colorée

Est-ce que les conseil d'accessibilité du Modèle:Boîte colorée, que je viens de rajouté sont satisfaisant ?
Il font suite à la discussion. --ParaBenT (discuter) 5 février 2019 à 06:30 (CET)

Paramètre italique= pour Modèle:Langue avec nom

Pour information : Discussion module:Langue#Paramètre italique= pour Modèle:Langue avec nom. — Thibaut (discuter) 17 janvier 2020 à 14:15 (CET)

Gestion des colonnes dans les listes à puces

Bonjour, en biologie, nous utilisons souvent des listes longues comme le bras pour énumérer les sous-taxons d'un taxon. Or l'utilisation exclusive des * s'avère incompatible avec {{colonnes|nombre=2|liste}} (voir cet exemple). J'avais trouvé un moyen de le rendre compatible en utilisant les :* (voir cet exemple), mais TED me fait remarquer, à juste titre, que cet usage ne fait pas partie des bonnes pratiques. Dès lors, auriez-vous une idée pour contenter les objectifs de tout le monde? D'avance, merci --Abalg ^Bzzzzzz 3 mai 2020 à 04:28 (CEST)

Ne pas mettre de colonne, en particulier dans cet exemple où la liste n’est pas longue comme le bras. TED 3 mai 2020 à 04:38 (CEST)

Images animées

La page fournit des explications très claires sur ce qu'il faut faire... mais hélas peu utilisables pour une quiche dans mon genre, travaillant qui plus est sous MacOS. Est-il possible de demander à un sorcier wikigraphiste de mettre les images suivantes sous un format plus plaisant (i.e. le format Ogg Theora) : Cylindre_sphérique_construction.gif et Cylindre cubique.gif (et tant qu'à faire, peut-être aussi Clifford-torus.gif) ? Merci d'avance.--Dfeldmann (discuter) 19 octobre 2020 à 14:31 (CEST)

Note hors-propos étonnante et choquante

Salut,

Je suis plutôt surpris de lire « d'autres sont dus aux utilisateurs handicapés eux-mêmes (le problème est souvent entre la chaise et le clavier). », cela laisse sous-entendre de mauvaises choses... Je supprime le passage. --LD ^{• m'écrire •} 15 décembre 2020 à 23:50 (CET)

PS je comptais notifier Lgd (d · c · b) qui l’a introduit en 2010 mais le compte est banni. LD ^{• m'écrire •}

Références à un contenu par sa position à l'écran: je ne comprends pas ce que les exemples tentent d'illustrer

Bonjour,

En lisant la section Wikipédia:Atelier accessibilité/Bonnes pratiques#Références à un contenu par sa position à l'écran, je ne comprends pas ce qui différencie le premier exemple du second. Certes, il y a un 1 supplémentaire, mais qu'est-ce que c'est censé démontrer ?

Merci d'avance pour votre aide ‒ TechAcquisitor (discuter) 28 décembre 2020 à 21:38 (CET)

Bonjour TechAcquisitor  : ici la différence tient d'abord à la manière de représenter l’espace. Décrire avec « l'image de gauche » est moins accessible que décrire par « l'illustration numéro 1 » c.à.d associer une illustration à un numéro plutôt qu'à "gauche" / "droite". --LD ^{• m'écrire •} 28 décembre 2020 à 21:53 (CET)

Voir le bandeau dont la bonne pratique est de « ne pas faire reposer la compréhension d'une information sur une référence à la position ou à la forme d'un contenu affiché à l'écran » puisque l’affichage est différent d'un navigateur à l’autre, d'un support (ordinateur - mobile - tablette) à l’autre. --LD ^{• m'écrire •} 28 décembre 2020 à 21:56 (CET)

Bonjour @LD !

Facepalm Autant pour moi, je ne saurais même plus dire ce que j'avais lu initialement. Il est temps que j'aille me coucher

Identifier le contenu plutôt que de faire référence à sa position, c'est bien noté. Merci ! ‒ TechAcquisitor (discuter) 28 décembre 2020 à 22:12 (CET)

Choix de couleurs et contrastes

Bonjour, peut-on rajouter d'autres exemples de contrastes insuffisants : 1/ texte noir sur couleur foncée et 2/texte couleur sur fond de couleur. Merci. -- Amicalement, Salix ^[Converser] 6 février 2021 à 11:56 (CET)