Discussion Wikipédia:Atelier accessibilité

Ajouter une discussion

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

Vous pouvez également consulter :

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

Pour vous y aider :

Le gadget accessibilité

Pas toutes les couleurs de la Palette officielle de la Charte graphique Wikimedia sont évaluéesModifier

Pas toutes couleurs proposées dans la palette officielle de la Charte graphique Wikimedia issue de Visual Style - Colors n'ont été évaluées. --ParaBenT (discuter) 29 janvier 2019 à 12:40 (CET)Reply[répondre]

Modèle:LangueModifier

Bonjour, je cite le texte de la page WP: Atelier accessibilité :

« Pour que les lecteurs d'écran puissent reconnaître un mot ou une phrase en langue étrangère. Par exemple : ''{{langue|en|Web accessibility}}'' qui donne ceci : Web accessibility. Cela ne change pas l'aspect de l'affichage (sauf paramétrage spécifique de CSS), mais ajoute une balise dans le code html généré. »

Je viens de lire ça et je ne savais pas qu'on pouvait faire apparaître les passages en langue étrangère différemment du texte normal.

Ça m'intéresserait bien de connaitre la méthode pour faire cela, par exemple surligner le texte en langue étrangère en rose pâle (#ffccff), comme ça je pourrais voir les passages dépourvus de modèle {{lang}} sans avoir à activer le gadget Accessibilité.

Merci de me donner le code complet à ajouter à ma page Utilisateur:SyntaxTerror/common.css (si c'est bien là qu'il faut le mettre).

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 13 février 2019 à 18:20 (CET)Reply[répondre]

Salut. Le créateur du gadget ne contribue plus mais tu pourras probablement trouver ton bonheur ici ou mais ne m'en demande pas plus je n'y connais rien. 'toff [discut.] 13 février 2019 à 18:57 (CET)Reply[répondre]
Salut et merci de la réponse rapide   Supertoff. Je ne suis pas très fort en CSS, alors je n'ai pas trouvé le code que je veux... Je vais attendre quelques jours pour voir si on me répond ici, sinon, je demanderai sur le Bistro. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 13 février 2019 à 19:47 (CET)Reply[répondre]
  SyntaxTerror : il est effectivement possible de changer l'apparence du texte balisé avec le modèle {{lang}} en suivant les instructions de la page de documentation du modèle. Mais si j'ai bien compris ta question, il s'agirait pour toi d'afficher différemment les textes en langue étrangère qui ne sont pas balisés avec le modèle. Malheureusement, à moins d'une reconnaissance automatique des langues, c'est pour le moment impossible.
En fait, ce que fait le gadget, c’est mettre en évidence par un changement d'apparence les endroits où le modèle est utilisé, afin de :
  • vérifier qu'il est correctement utilisé
  • vérifier que les endroits du texte où on lit des extraits en langue étrangère n'ont pas été oubliés. Mais il n'y a justement aucune mise en forme spécifique prévue pour ces endroits, et il ne peut y en avoir.
J'espère avoir répondu à ta question, même si la réponse peut te décevoir… Litlok (m'écrire) 14 février 2019 à 10:04 (CET)Reply[répondre]
Merci   Litlok, c'est exactement ce que je cherchais :
Avec span[lang] { background-color: #ffccff; } ça me donne un truc « like this »  .
Quand je verrai un truc « like that », je saurais dorénavant que je peux y ajouter un modèle {{lang}}.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 14 février 2019 à 10:26 (CET)Reply[répondre]
détecter les pages successible d’avoir des lacune de modèle langue : en partant du cas des pages films à généraliser.
À partir d'un retour d'expérience sur les pages cinémas ne faudrait-il pas envisager de demander de générer une liste de maintenance qui liste les pages qui comparent l'info-box et la section fiche technique en posant la question : il a t-il un modèle langue dans le champ | titre original quand le champ | pays = n'a pas la valeur {{France}} ; même analyse dans la section == Fiche technique == avec * Titre original : et * Pays d'origine :. Il se peut que le code langue soit renseigné dans le modèle et pas dans la fiche technique ou inversement ; également se poser la question quand le champ | langue du titre est renseigné, est-ce que dans l'entête le titre de la page a bien un modèle langue ainsi que toute les fois que la page est appelée par un lien est-ce que ce lien est bien inclue dans un modèle langue. --ParaBenT (discuter) 15 février 2019 à 13:35 (CET)Reply[répondre]

┌─────────────────────────────────────────────────┘

  ParaBenT : tu parles d'un tout autre problème. Il faut proposer ça sur la PdD de l'infobox film. Le problème que je vois déjà est que les films avec un titre en français ne sont pas forcément produits en France (par exemple les films belges, mais tous les films belges ne sont pas forcément en français...), et les films produits en France n'ont pas forcément un titre en français.
Côté section fiche technique, c'est du ressort des bots.
À mon avis, tu devrais déjà commencer par en parler sur le projet cinéma qui s'y connaît mieux en articles de films que les contributeurs du projet accessibilité pour éventuellement découvrir des choses auxquelles tu n'aurais pas pensé.
Aussi, dis-toi bien que c'est une goutte d'eau dans la mer : la quasi-totalité des articles comportant des mots en langue étrangère ont des problèmes d'accessibilité au niveau des marqueurs de langue.
Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 16 février 2019 à 08:45 (CET)Reply[répondre]
En effet   SyntaxTerror : sujet est cousin ! Merci pour les retours et les pistes de réflexions. --ParaBenT (discuter) 16 février 2019 à 11:44 (CET)Reply[répondre]

Contribution sur Wikipédia avec un lecteur d'écranModifier

Bonjour, nous avons reçu par courriel une question d'une personne aveugle nous demandant s'il existe des ateliers ou tutoriels pour apprendre à contribuer sur Wikipedia avec un lecteur d'écran. Je n'ai connaissance de rien de tel (les pages de l'atelier accessibilité que j'ai vu me semblent plus tournés vers les valides se préoccupant de l'accesibilité), mais peut-être en existe-t-il ? -Sylvain Boissel WMFr (discuter) 5 mars 2019 à 16:55 (CET)Reply[répondre]

"Wiki voix" téléchargeable sur playstore ? --2A01:E34:ED53:3230:60C5:2535:C84C:6E13 (discuter) 5 mars 2019 à 20:35 (CET)Reply[répondre]
Bonjour. La page en:Wikipedia:WikiProject Accessibility (en anglais) est peut-être intéressante, car en haut à droite elle a une palette verticale avec un menu "For impaired users". En particulier, la première ligne de ce menu est Using JAWS, JAWS étant un lecteur d'écran. Mais il y a une solution peut-être plus simple : poser des questions dans en:Wikipedia talk:WikiProject Accessibility (en anglais), car plusieurs contributeurs de ce projet sont aveugles. Cordialement --NicoScribe (discuter) 6 mars 2019 à 09:27 (CET)Reply[répondre]

Contribution pas du tout adaptée pour des daltoniensModifier

Bonjour, Je viens de faire cette contribution qui nécessite de distinguer 14 couleurs différentes. Je sais que c'est une mauvaise pratique et que les daltoniens vont avoir des soucis pour comprendre le diagramme, mais je ne vois pas comment faire quelque chose d'intelligible pour tout le monde. Quelqu'un aurait-il une idée ? --E.Le Morvan (discuter) 8 avril 2019 à 17:58 (CEST)Reply[répondre]

Remplacer quelques couleurs proches (pour les daltoniens s'entend) par des cases à rayure ? (Sinon, c'est relativement quand même compréhensible pour un daltonien mais c'est vrai que certaines couleurs sont problématiques). 'toff [discut.] 8 avril 2019 à 18:32 (CEST)Reply[répondre]
Et sinon, côté accessibilité, il faut éviter d'imbriquer les tableaux. 'toff [discut.] 8 avril 2019 à 18:33 (CEST)Reply[répondre]
Bonjour.
  Supertoff : j'en profite pour poser une question : je crois savoir qu'il existe quelque part une page qui donne des exemples de couleurs pour les cartes pour qu'elles soient lisibles facillement par le plus grand nombre, mais je n'arrive pas à remettra la main dessus.
Si elle existe vraiment, il serait bien de mettre un lien dans l'Atelier graphique/Cartes. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 8 avril 2019 à 23:26 (CEST)Reply[répondre]

Tableau vs. listeModifier

Bonjour,

Pour faire simple, vaut-il mieux un tableau ou une liste à puces.

Je m'explique : sur WP.(en) les filmographies sont au format tableau sur WP.(fr) majoritairement au format liste.

Mais certaines au format tableau pourraient être aisément reconstruite en liste lorsqu'il n'y a que Année / Titre du film / rôle.

En dehors de l'aspect esthétique et usuel de la wiki francophone, est-ce que ce serait utile de repasser en mode liste question accessibilité ?

Ancien webmaster, les tableaux étaient très mal « digérés » niveau accessibilité à mon époque, est-ce toujours le cas, et la programmation wiki résout-elle ces anciens problèmes ?

Ma demande est peut-être brouillon mais ça fait un moment que je me pose la question.

Merci pour vos éclaircissements. — Lagribouille (discuter) 28 avril 2019 à 00:53 (CEST)Reply[répondre]

Bonsoir,
Cela n'a pas d'importance car les deux sont bien gérés, du moment que le tableau n'est pas trop complexe et utilise le balisage adéquat (avec des ! scope=row ou col par exemple pour indiquer les entêtes de ligne ou de colonne). Litlok (m'écrire) 28 avril 2019 à 01:35 (CEST)Reply[répondre]
  Litlok : - Merci beaucoup. Bonne nuit  Lagribouille (discuter) 28 avril 2019 à 02:27 (CEST)Reply[répondre]

Questions sur l'insertion d'illustrations ou cartes dans des tableaux imbriquésModifier

Bonjour, sur la page du modèle:{{Début de carte}}, il est précisé « Ce modèle pose un problème d’accessibilité important ». Alors on peut aisément comprendre que quand il est en plus inséré dans un tableau directement dans l'article ou par l'intermédiaire des modèles {{Début d'illustration}} et{{Fin d'illustration}} c'est encore pire.

Entre les deux possibilités ci-dessous, faut-il privilégier la seconde ou est-ce kif-kif ?
Cas 1 :

{{Début d'illustration}}
{{Début de carte|style table=float:left; margin:5px;}}[[Image:{{Géolocalisation/France|image}}|200px]]
{{Fin de carte}}
{{Fin d'illustration
|1={{Géolocalisation/France|image}}
|2=Texte Cas 1.}}

Cas 2 :

{{Début de carte|style table=float:right; margin:5px; padding:5px; background-color:#F9F9F9; border:1px solid #AAA}}[[Image:{{Géolocalisation/France|image}}|200px]]
<div style="font-size:92%; text-align:left">Texte Cas 2.<div>
{{Fin de carte}}
Texte Cas 1.
 
Texte Cas 2.

Autres questions :

  • Est-ce utile d'ajouter un texte alernatif à ces illustrations ? Si oui, comment procéder?
  • Quid des recommandations de l'Aide:Carte_complétée ?
  • Faut-il privilégier une autre pratique ?

En espérant avoir une réponse. J'aurais bien notifié le Projet:Cartographie mais fonctionnalité inactive . --Aidewikip (discuter) 15 juin 2019 à 18:21 (CEST)Reply[répondre]

Édit Je crois avoir trouvé un article champion de l'imbrication de tableaux Coupe du monde de snowboard 2018-2019 avec pas moins de quatre niveaux.

{{col-begin}}
{{col-2}}
{|
| valign="top" |
{{Début d'illustration|center}}
{{Début de carte|style table=font-size:80%; line-height:1.1em;}}[[Fichier:{{Géolocalisation/Monde|image}}|500px]]

--Aidewikip (discuter)

Sac de Dinant (1914)Modifier

Bonjour, Je viens de faire toute une série de modifications (principalement des alt= pour les illustrations) sur l'article Sac de Dinant (1914). Si l'un d'entre vous avait le souhait d'en faire une relecture sous cet angle, j'en serais ravi. Les conseils d'amélioration peuvent être laissé sur la pdd de l'article. PS: Les logos des portails ne comportent pas de texte alternatif et j'ignore comment faire ni-même si c'est pertinent de le faire. Bien à vous, — Madel (... le 22 à Asnières ?) 4 août 2019 à 15:42 (CEST)Reply[répondre]

Bonjour. Il y a beaucoup d'images dans cet article où la légende est la même que l'alternative (ou l'inverse) ce qui n'est pas adéquat (même si ça peut l'être parfois). L'alternative doit décrire l'image plus que le contexte. J'ai fait cette modif par exemple même si on peut toujours faire mieux. Cordialement. 'toff [discut.] 4 août 2019 à 18:54 (CEST)Reply[répondre]
Merci beaucoup, j'ai retravaillé les textes alternatifs selon ton conseil. Comment peut-on faire lire l'article par une voix de synthèse pour avoir une idée de ce que cela donne? Je suis sur chrome. Bien à toi, — Madel (... le 22 à Asnières ?) 5 août 2019 à 08:52 (CEST)Reply[répondre]
J'ai trouvé une extension (SpeakIt). La synthèse vocale est d'assez bonne qualité, mais les formatnum sont mal lus (par contre les nombres le sont correctement en l'absence du modèle), la litanie des numéros de référence est un peu pénible et de fait, lorsque le texte alternatif est trop proche de la légende de l'illustration, c'est très redondant d'où ton conseil sur la nécessité de se départir de la légende pour vraiment décrire l'illustration. Bien à toi, — Madel (... le 22 à Asnières ?) 5 août 2019 à 09:27 (CEST)Reply[répondre]

Proposition pour remplacer Modèle:Références nombreusesModifier

Bonjour,

J'ai fait une proposition sur le Bistro pour remplacer le modèle {{Références nombreuses}} qui pose des problèmes d’accessibilité, voir Wikipédia:Le Bistro/6 février 2020#Modèle:références nombreuses. Avis bienvenus. — Thibaut (discuter) 7 février 2020 à 16:34 (CET)Reply[répondre]

Accessibilité des couleursModifier

 
Sur la gauche, les couleurs sont distinguables facilement pour les personnes non atteintes de daltonisme, sur la droite ce que verra un deutéranope. Les couleurs sont différentes, mais encore facilement différentiables.

Bonjour

Je produis parfois des cartes et j'ai longtemps cherché une palette de couleurs accessible aux daltoniens.

J'ai récemment trouvé ce PDF [1] qui est très intéressant et grâce à lui j'ai écrit l'Aide:Accessibilité des couleurs, principalement destinée aux cartes, mais qui peut être utile dans les rares cas d'utilisation de couleurs sur Wikipédia.

Il serait intéressant d'avoir plus de palettes afin de donner un plus grand choix tout en restant accessible aux daltoniens, donc si vous savez où en trouver, je pourrais faire le même genre de charte que celle déjà présente (voir vignette).

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 21 février 2020 à 07:26 (CET)Reply[répondre]

Salut. Au passage, les caractères de la couleur 1C2793 devraient être en blanc parce que pour le coup, c'est pas accessible   'toff [discut.] 21 février 2020 à 07:56 (CET)Reply[répondre]

Problème d'accessibilité aux Alternatives textuellesModifier

La question a déjà été soulevée il y a quelques mois, mais sans réponse. Il n'est plus possible de vérifier l'accessibilité des alternatives textuelles dans les images importées de Commons (alt=), le lien est mort ou bloqué. Quelqu'un sait-il d'où vient le problème ? A-t-il un rapport avec l'apparition de la fenêtre « Légendes » sous les fichiers images, invitant à « Ajouter en une ligne la description de ce que représente ce fichier » ? Eymery (discuter) 3 mars 2020 à 13:55 (CET)Reply[répondre]

Tu parles bien du gadget Accessibilité (js, css), dont la commande "Alternatives" ne produit aucune effet ? Je viens de tester, et j'ai effectivement une erreur JavaScript « Error: Syntax error, unrecognized expression: img[alt$=.png], img[alt$=.svg], img[alt$=.jpg], img[alt$=.gif], img[alt$=.PNG], img[alt$=.SVG], img[alt$=.JPG], img[alt$=.GIF] ». Là je n'ai pas le temps de creuser davantage, mais je devine qu'il s'agit d'une erreur liée à une mise à jour de jQuery, qui a supprimé son moteur de sélection Sizzle au profit du querySelector* natif, supprimant dans l'opération ce genre de sélecteur non standards. od†n ↗blah 3 mars 2020 à 17:04 (CET)Reply[répondre]
  J'ai réparé et ça semble fonctionner de nouveau, de ton côté tu confirmes aussi que c'est bon ? od†n ↗blah 4 mars 2020 à 01:23 (CET)Reply[répondre]

Ça marche ! Merci ! Eymery (discuter) 4 mars 2020 à 12:42 (CET)Reply[répondre]

Alternative et modèleModifier

Bonjour aux membres de l'atelier. Lorsqu'on intègre, dans une description d'image, l'alternative textuelle, celle-ci peut-elle comprendre un modèle ? Je m'explique : dans l'une que je rédigeais, j'avais écrit « La mosaïque du 6ème siècle de Jérusalem » peut-être aurais-je du écrire « La mosaïque du sixième siècle de Jérusalem » ?. Un contributeur, passant par là, a rectifié « La mosaïque du {{s-|VI}} de Jérusalem ». Quelle est la bonne pratique en matière d'alternative, svp ? =>   Sg7438 discuter, c'est ici ! 11 mars 2020 à 15:26 (CET)Reply[répondre]

Bonjour Sg7438. Je n'ai pas de certitude sur l'interprétation du code. Mais il semble absurde de mettre un tel modèle de formatage du texte dans un élément qui n'a pas vocation à être visible mais simplement lu par un logiciel. Par précaution et simplicité, je n'utiliserais que du texte brut. Dans ce cas, ton alternative conviendrait parfaitement. N'hésite pas à expliquer au contributeur, qui a peut-être fait une telle modification par inattention, que cette dernière n'apparaît pas pertinente et peu altérer l'accessibilité, raison d'être de ce paramètre descriptif des images. Par curiosité et pour éventuellement améliorer la documentation, la "correction" a été faite via WPCleaner, AWB ou un autre outil semi-automatisé (voir les balises lors de l'édition) ? Cdlt. --Ideawipik (discuter) 12 mars 2020 à 20:18 (CET)Reply[répondre]
Bonsoir, le diff ne l'indique pas (ici) mais tes propos rejoignent déjà ce que je pensais... J'avais cru le lire, un jour, y a un moment, sur une longue discussion (explicative) relative aux alternatives... Hélas, je ne parviens pas à remettre la main dessus... =>   Sg7438 discuter, c'est ici ! 12 mars 2020 à 20:23 (CET)Reply[répondre]
Bonsoir Sg7438  . C'est en anglais, mais c'est écrit là : en:Wikipedia:Manual of Style/Accessibility/Alternative text for images#Basics : « The alt text should consist of plain text (no HTML or wiki markup such as wikilinks) ». C'est une chose que j'ai découverte en corrigeant des erreurs de LINT. --FDo64 (discuter) 12 mars 2020 à 22:00 (CET)Reply[répondre]
Logique... un grand merci ! je vais donc rétablir, comme j'écrivais mes alternatives ! =>   Sg7438 discuter, c'est ici ! 13 mars 2020 à 07:48 (CET)Reply[répondre]

Un modèle Lien nécessite-t-il aussi un modèle Langue ?Modifier

Bonjour,

Est-ce que le modèle {{Lien}} inclut l'aide à l'accessibilité afin qu'un liseur lise le lien rouge dans la langue spécifiée ? Ou faut-il encadrer le modèle Lien du modèle {{Langue}} ?

Si oui à la deuxième question, ne faudrait-il pas modifier le modèle Lien en conséquence ?

Cordialement, — Daehan [p|d|d] 25 mars 2020 à 10:10 (CET)Reply[répondre]

Salut. Je ne comprends pas bien la question : le lien rouge qui apparaît est le lien vers l'article français inexistant. Il n'y a donc pas lieu de lire dans une autre langue. Quand au (en) qui mène vers l'article étranger, il est lié au tooltip "Équivalent de l’article « XXX » dans une autre langue", donc aussi en français. Cordialement. 'toff [discut.] 25 mars 2020 à 10:33 (CET)Reply[répondre]
Supertoff, par exemple, est-ce qu'un liseur lit en anglais {{Lien|South Australian Register}} ou est-ce qu'il faudrait faire comme ceci pour que ce soit le cas : {{Langue|en|{{Lien|South Australian Register}}}} ? — Daehan [p|d|d] 25 mars 2020 à 11:10 (CET)Reply[répondre]
Bonjour Daehan. Le mieux à l'insertion des modèles Lien est d'utiliser tous les paramètres disponibles (langue, trad, fr et texte), l'écriture compacte étant aussi permise bien sûr mais moins explicite pour les novices. Mon avis personnel sur ta question serait de mettre le modèle Langue autour du Lien si le texte est dans une autre langue que le français mais pas davantage que pour les autres passages ou expressions dans une autre langue dans la page concernée. Cela est surtout valable pour les articles ayant une forte probabilité d'être crées/admissibles, dans l'optique de la conversion future en lien interne classique. Le modèle Lien n'a pas vocation à rester dans les articles mais est là pour faire des appels à traduction. --Ideawipik (discuter) 25 mars 2020 à 12:27 (CET)--Ideawipik (discuter) 25 mars 2020 à 12:07 (CET)Reply[répondre]
On pourrait même imaginer des {{Lien|langue=en|trad=…|fr=nom en français|texte={{Langue|en|texte en anglais}}}} à convertir en [[nom en français|{{Langue|en|texte en anglais}}]] mais il faudra modifier le code des bots convertisseurs pour traiter les cas où texte en anglais est identique à nom en français au nom de l'article (ou de la redirection éventuelle) effectivement crée sur frwiki. --Ideawipik (discuter) 25 mars 2020 à 12:27 (CET)Reply[répondre]
Mettre le modèle lang autour du modèle lien est une fausse bonne idée il me semble : le modèle lien est supprimé par bot quand le lien rouge est créé. Je suppose que le bot laisserait le modèle lang autour du nouvel article et ça n'est pas une pratique qui fait l'unanimité sur Wikipédia.fr. Ça risque de créer des conflits.
La solution d'Ideawipik de mettre le modèle lang dans le paramètre texte me semble la meilleure idée. 'toff [discut.] 25 mars 2020 à 12:43 (CET)Reply[répondre]
Bonjour Supertoff. Pour bien comprendre le risque de créer des conflits concerne les lecteurs automatiques, c'est cela ?
  • Si le libellé d'un lien est identique au nom de l'article cible, est-ce que [[article|{{Langue|en|article}}]] est plus accessible que {{Langue|en|[[article]]}} ?
  • « le bot laisserait le modèle lang ». Tu supposes bien.
--Ideawipik (discuter) 25 mars 2020 à 13:19 (CET)Reply[répondre]
Supertoff, tu dis « le bot laisserait le modèle lang autour du nouvel article et ça n'est pas une pratique qui fait l'unanimité sur Wikipédia.fr. Ça risque de créer des conflits. »
Je ne comprends pas pourquoi. En quoi laisser le modèle Lang autour d'un lien interne pose problème, puisque c'est à ça que ça sert ?
« La solution d'Ideawipik de mettre le modèle lang dans le paramètre texte me semble la meilleure idée » Pourquoi ? Je pense qu'au contraire ça poserait problème au bot... — Daehan [p|d|d] 25 mars 2020 à 14:19 (CET)Reply[répondre]
Pour rassurer Daehan. Non, cela ne poserait pas de problème au bot en l'état. Il peut gérer des paramètres contenant des modèles. La seule ambiguïté concerne la question de syntaxe de mon dernier message, histoire de programmer le bot en conséquence. Donc quel est le consensus général pour cette pratique ? --Ideawipik (discuter) 25 mars 2020 à 15:16 (CET)Reply[répondre]
{{Lang|{{Lien|Titre d'article}}}} deviendrait {{Lang|Titre d'article}} et ce n'est pas une pratique généralisée dans un article et donc à ne pas imposer (un exemple : liens vers Quarterback). {{Lien|{{Lang|Titre d'article}}}} deviendrait Titre d'article (avec un bon paramétrage) : le bot détecte le modèle lien et ce qui est dedans, pas le modèle lien et ce qui est autour. (Sans compter les italiques qui doivent normalement être apposée par convention autour d'un modèle lang et que le bot ne saurait pas gérer.) Bref, la solution d'Ideawipik est de loin la meilleure pour une meilleure gestion interne à WP. 'toff [discut.] 25 mars 2020 à 15:43 (CET)Reply[répondre]
Merci pour la réponse. Pour être précis {{Lang|en|{{Lien|Titre d'article}}}} deviendrait (et devient déjà) {{Lang|en|[[Titre d'article]]}}, si tant est que l'article sur frwiki a été crée avec le même nom que sur enwiki.
Supertoff, je ne comprends pas ton exemple. Sauf à dire qu'il ne faut pas utiliser une syntaxe {{Lien|{{Lang|en|Article inexistant}}}} qui de toute façon ne fonctionne pas et donne « [[:Article inexistant]] [[:en:Article inexistant|<span class="indicateur-langue" title="Article en anglais : « Article inexistant »">(en)]] » mais cela semble logique vu que même pour un lien interne classique [[{{Lang|en|Quarterback}}]] ne fonctionne pas et affiche « [[Quarterback]] ». Une vrai question est donc celle que je réitère sur l'exemple donné. Pour un même rendu visuel, est-ce que [[Quarterback|{{Langue|en|Quarterback}}]] est plus accessible (pour les non-voyants,...) que {{Langue|en|[[Quarterback]]}} ? --Ideawipik (discuter) 25 mars 2020 à 17:43 (CET)Reply[répondre]
Il ne faut pas forcément que le modèle lang perdure. On n'écrit pas {{lang|en|[[Quaterback]]}} dans les articles mais simplement [[Quaterback]]. 'toff [discut.] 25 mars 2020 à 18:20 (CET)Reply[répondre]
Je ne comprends pas que dans l'atelier accessibilité on dise que lang ne doit pas perdurer.
Il y a plusieurs choses que je ne comprends pas, en fait ^^
Tu dis : « {{Lien|{{Lang|Titre d'article}}}} deviendrait Titre d'article (avec un bon paramétrage) : le bot détecte le modèle lien et ce qui est dedans, pas le modèle lien et ce qui est autour. » Qu'est-ce que ça veut dire "avec un bon paramétrage" ? Pour ce que le bot détecte, oui, c'est logique : il transforme Lien en [[]] et s'il y a le modèle Lang autour, c'est parfait : l'accessibilité est conservée. Où est le problème ?
Tu dis que mettre le modèle Lang autour d'un lien interne « n'est pas une pratique généralisée dans un article » mais je ne suis pas d'accord : Lang ne doit pas servir qu'au texte "noir" : pour un mal-voyant, un mot sans lien est aussi important à comprendre qu'un mot avec lien. Tu dis aussi qu'il faudrait systématiquement ajouter l'italique, mais ce n'est pas vrai : un nom d'institution en anglais ne doit pas être en italique, par contre il me semble logique de préciser pour le lecteur des non-voyants que c'est en anglais. J'ai du mal à suivre la logique, désolé. — Daehan [p|d|d] 25 mars 2020 à 18:44 (CET)Reply[répondre]

┌─────────────────────────────────────────────────┘
J'abandonne de tenter de m'expliquer. Il reste qu'une forme est préférable. Bonne soirée. 'toff [discut.] 25 mars 2020 à 19:01 (CET)Reply[répondre]

Désolé   Supertoff, je fais partie de ceux qui ne comprennent pas. La mise en place du modèle {{Langue}} est la toute première recommandation en haut de cette page dans « Petites choses faciles à faire pour l'accessibilité » et une bonne pratique. --FDo64 (discuter) 25 mars 2020 à 19:15 (CET)Reply[répondre]
Idem Daehan et donc FDo64. Pas compris la logique. Ni la raison technique. --Ideawipik (discuter) 25 mars 2020 à 19:19 (CET)Reply[répondre]
Je ne dis pas qu'il ne faut pas, je dis qu'une forme (avec le modèle lang) est préférable à l'autre. Mais je dois être mauvais en explications donc, je confirme que j'abandonne. 'toff [discut.] 25 mars 2020 à 19:21 (CET)Reply[répondre]
Donc pour répondre à la question initiale, l'utilisation du modèle {{Langue}} avec le modèle {{Lien}} est une « Bonne pratique ».
Par contre, la bonne méthode est de l'inclure dans le paramètre texte.
En effet, {{Langue|{{Lien|Titre d'article}}}} n'est pas correct puisque cela inclurait "Équivalent de l’article « XXX » dans une autre langue" dans {{Langue}}.
--FDo64 (discuter) 25 mars 2020 à 22:14 (CET)Reply[répondre]
Bonsoir FDo64, j'en déduis de toutes façons que la réponse à la première question est que l'accessibilité n'est pas contemplée dans le code du modèle lien.
Pour la bonne pratique, j'ai bien compris, et ça répond bien à ma question (à savoir ce que dirait le lecteur), mais ça veut dire qu'une fois l'article créé, on aura [[Titre d'article|{{Langue|en|Titre d'article}}]] : c'est moins bien que {{Langue|en|[[Titre d'article]]}}, non ? — Daehan [p|d|d] 25 mars 2020 à 22:28 (CET)Reply[répondre]
  Daehan : « l'accessibilité n'est pas contemplée dans le code du modèle lien » : dans le cas contraire il aurait fallu deux paramètres puisque, par exemple, un article écrit en anglais peut avoir un titre russe ou japonais. langue texte n'existe pas.
Pour ce qui est de la conversion, seul un dresseur peut te répondre. La contrainte forte étant les titres avec des parenthèses.
--FDo64 (discuter) 25 mars 2020 à 23:20 (CET)Reply[répondre]
Bien vu pour le premier point. OK, merci. Je pense que l'usage de [[Titre d'article|{{Langue|en|Titre d'article}}]] ou {{Lien|langue=en|trad=Titre d'article|fr={{Langue|en|Titre d'article}}}} doit être si peu étendu que ça ne vaudrait pas le coup d'engager des modifications en ce sens. Par contre, l'imbrication que je suggérais au début, je l'ai vu plusieurs fois, il me semble... Peut-être qu'il faudrait demander à un bot de corriger ça. — Daehan [p|d|d] 25 mars 2020 à 23:28 (CET)Reply[répondre]

┌─────────────────────────────────────────────────┘
Bonjour Daehan.

1. Utilisant un programme pour convertir les modèles Lien en liens internes classiques, je donnerais ces conseils pour faciliter tant le travail des bots que la compréhension du modèle Lien par les usagers :

  • ne pas utiliser de modèles dans les paramètres trad et fr mais seulement du texte brut, sans modèle ni mise en forme (pas d'apostrophe d'italique ou de gras par exemple). Par expérience, il est assez rare de rencontrer de telles insertions potentiellement problématiques. Par acquis de conscience vérification faite, pas plus d'une trentaine de cas dont ceux-ci.
  • possibilité d'utiliser des modèles dans le paramètre texte.

Donc, même si certains programmes qui cherchent l'existence d'une traduction(/d'un équivalent) sur frwiki de l'article d'origine (trad) indépendamment de l'existence d'un article nommé fr feront une proposition de substitution, {{Lien|langue=en|trad=Titre d'article|fr={{Langue|en|Titre d'article}}}} est à proscrire et à remplacer par {{Lien|langue=en|trad=Titre d'article (sur enwiki)|fr=Titre d'article (prévision sur frwiki et donc différent d'un existant)|texte={{Langue|en|Titre d'article}}}} (fr étant facultatif si la valeur envisagée pour le titre sur frwiki est identique à celle de trad).
Ces conseils seraient à ajouter à la documentation du modèle Lien si ce n'est pas le cas.

2. L'imbrication{{Langue|xx|{{Lien… que tu suggérais au début ne me semble pas aberrante (il y a plus de 3000 cas existants actuellement) mais seulement si le texte affiché (texte/fr) est dans la langue spécifiée par le modèle Langue). Cela dit quelques bémols :

  • il n'est pas certain que l'article sera crée avec un nom dans une autre langue que le français, même si le paramètre fr l'est. Ce qui engendrerait des conversions {{Langue|en|{{Lien|Titre anglophone sur enwiki}}}}{{Langue|en|[[Titre francpohone sur frwiki|Titre anglophone sur enwiki]]}}.
  • parfois les titres en français sont hybrides « Texte en anglais (précision d'homonymie en français) ».
  • un article peut, un jour, être renommé vers un titre en français.

Ces points m'inciteraient, même si cela peut-être un peu plus compliqué à traiter pour un bot, à préconiser plutôt {{Lien|langue=en|trad=…|fr=nom en français|texte={{Langue|en|texte en anglais}}}}.

En revanche pour la conversion automatisée, notamment si l'article a été crée sur frwiki sous un titre non francophone identique au texte à afficher (paramètre texte hors modèle Langue éventuel), je n'ai pas la réponse en termes d'accessibilité à la question déjà posée plus haut et reformulée par Daehan à la fin de son message du 25 mars 2020 à 22:28. Finalement, grâce à une recherche dans les archives, la formulation compacte semble OK. La documentation du modèle Langue va dans le même sens. Il suffit juste d'apprendre aux bots à gérer ce cas, selon les souhaits de la communauté. --Ideawipik (discuter) 26 mars 2020 à 11:17 (CET)Reply[répondre]

Bonjour Ideawipik et merci pour cette investigation.
Je me permets de remettre en question certains points (chui chiant, mais c'est pas méchant :) ) :
Tu dis « il n'est pas certain que l'article sera crée avec un nom dans une autre langue que le français, même si le paramètre fr l'est. Ce qui engendrerait des conversions {{Langue|en|{{Lien|Titre anglophone sur enwiki}}}}{{Langue|en|[[Titre francpohone sur frwiki|Titre anglophone sur enwiki]]}}. » Le bot va transformer le modèle Lien en lien interne si et seulement si un article portant le nom passé dans le paramètre |fr=, non ? (Ici, le |fr= n'est pas précisé, mais le code prend par défaut le seul paramètre du lien, ce qui revient au même.) Du coup, je ne comprends pas l'hypothèse.
Prenons l'exemple d'un film connu sous son nom anglais mais possédant aussi un autre nom en français. Un utilisateur de lien peut avoir utilisé une forme dans un article, un autre utilisateur la forme trad et fr avec les titres dans les deux langues dans un autre article. Si l'article a été crée avec le titre en français et qu'aucune redirection du titre anglais vers le français n'a été créée, le lien vers l'article existant ne se fera pas et on risque de voir un contributeur créer, sous le nom en anglais, un second article doublon du premier. Voir Projet:Liens rouges/Modèle lien vers un article déjà traduit. C'est ce genre de corrections semi-automatisées (suggestions validées manuellement) qui pourrait engendrer des {{Langue|en|[[Article_en_français|Article_en_anglais]]}}. Il faut songer au fait que :
  • Parfois (fr avec typo improbable, isolée, incorrecte ou ne respectant pas du tout les conventions), la solution n'est pas la création d'une redirection mais la correction des cibles des liens internes dans les articles.
  • Il n'est pas du tout évident pour l'utilisateur, même précautionneux, de définir le paramètre fr (en respectant les conventions de projets et en évitant les risques d'homonymie). Comment savoir sous quel titre sera crée un jour l'article ? Un bot en fonctionnement jusqu'à la fin de l'année 2019 sur les articles transformait les modèles à partir du moment où un article nommé fr existait, sans vérifier qu'il s'agit de l'équivalent de (langue,trad) sur frwiki, engendrant de nombreux liens en dur non désirés, vers des articles crées plus tard pour des sujets homonymes différents (cas facilement compréhensible sur l'exemple des personnes) ou vers des pages d'homonymie. --Ideawipik
Tu dis « parfois les titres en français sont hybrides « Texte en anglais (précision d'homonymie en français) ». » Dans ce cas, on a [[Article_en_anglais (homonymie_en_français)|Article_en_anglais]], donc le lecteur ne devrait lire que le titre en anglais, non ?
Là c'est une question d'accessibilité et de liseuse qui requiert l'expertise d'un usager. Je ne sais pas comment {{Langue|en|[[Article_en_anglais (homonymie_en_français)|Article_en_anglais]]}} ou {{Langue|en|[[Article_en_français|Article_en_anglais]]}} sont traités. La réponse à cette question conditionne le point précédent et le suivant.
Tu dis « un article peut, un jour, être renommé vers un titre en français » Si c'est le cas, la redirection demeurerait en anglais, il faudrait donc conserver le modèle Langue.
100 %   OK avec toi. Des éventualités à considérer : les petits malins qui s'amusent à corriger les redirections sans discernement ; un besoin légitime de corriger par bot la cible des liens dans les articles (création d'un autre article (ou page d'homonymie) avec ce titre (anglophone), décision collective pour éviter confusion, page crée initialement sous un titre incorrect)
Cordialement, — Daehan [p|d|d] 26 mars 2020 à 11:29 (CET)Reply[répondre]
Bonjour Daehan. J'ai trouver un bon concurrent   ; j'aime bien également les réponses factuelles. Réponses dans le texte, entre les lignes. Mais comme tu le pointais, ces cas sont assez minoritaires. Difficile de vraiment identifier les bonnes pratiques. Cdlt. --Ideawipik (discuter) 26 mars 2020 à 13:08 (CET)Reply[répondre]

Modèle chronologiquesModifier

On se posait sur Discord avec @Datsofelija et @Koreller la question des modèles frises chronologiques. Ces modèles sont utilisés pour décrire la succession des modèles dans la gamme d'une marque, par exemple :

Ca permet de visualiser rapidement le truc... Par contre, ça a le défaut de ses avantages, c'est très visuel... Donc question accessibilité aux non/mal-voyants c'est probablement très mauvais. Y a-t-il une règle la dessus? Je me demandais si il était possible de remplacer l'ensemble du truc par une alternative pour les lecteurs d'écran, comme on fait pour les images avec le paramètre alt=. Le fourbe et cruel Raminagrobis Miauler 28 juillet 2020 à 22:40 (CEST)Reply[répondre]

Drapeaux dans les infoboxModifier

Bonjour, pouvez-vous me confirmer/ infirmer le fait que l'usage des drapeaux dans les infobox pose des problèmes d'accessibilité. Et si c'est le cas, pouvez-vous m'expliquer brièvement en quoi consiste problème. Bien cordialement Konstantinos (discuter) 23 août 2020 à 10:42 (CEST)Reply[répondre]

Bonjour. Sauf erreur de ma part, les modèles de drapeaux, {{USA}} ou {{USA-d}} par exemple, sont accessibles puisqu'ils ont une alternative textuelle. Et que ce soit dans une infobox ou pas n'y change rien. Cordialement. 'toff [discut.] 23 août 2020 à 11:51 (CEST)Reply[répondre]
Si cette question faisait suite à la RA « Ajouts systématique de drapeaux dans les infobox », j'y ai aussi répondu là-bas. 'toff [discut.] 23 août 2020 à 12:03 (CEST)Reply[répondre]

Pied de tableauxModifier

Bonjour j’aimerais savoir quoi faire avec les pieds de tableau, Par exemple:

Rang Équipe nationale       Total
1 equipe 1 0 0 1
Total 1 1 1 3

J'ai dans un premier temps transformé !Total par |Total mais j'ai doute sur le fait que ce soit la bonne chose a faire. Est ce que quelqu'un pourrait m’éclairer Programmateur01 (discuter) 27 septembre 2020 à 22:28 (CEST)Reply[répondre]

  vous devez spécifier au moins un utilisateur : bonjour. Utilisateur:Supertoff/Accessibilité des tableaux devrait pouvoir te donner les réponses que tu cherches. Mais ton tableau a l'air ok. 'toff [discut.] 28 septembre 2020 à 07:19 (CEST)Reply[répondre]
Merci pour le lien,
Le problème (visible) avec mon tableau est que s'il est triable, la dernière ligne est aussi classe alors qu'elle devrait être fixe en bas du tableau
Rang Équipe nationale       Total
1 equipe 1 0 0 1
Total 1 1 1 3
Programmateur01 (discuter) 28 septembre 2020 à 10:49 (CEST)Reply[répondre]
Bonjour Programmateur01. La méthode pour les tableaux triables est d'ajouter class="sortbottom" pour la ligne concernée. C'est d'ailleurs indiqué dans l'aide pour l'insertion des tableaux. Et au passage, le style que tu as ajouté manuellement (gras et couleur de fond) à cette dernière ligne est déjà intégré à la classe sortbottomIdeawipik (discuter) 28 septembre 2020 à 12:13 (CEST)Reply[répondre]
Parfait, merci ! (J’étais passé à cote de cette subtilité dans les tableaux) Programmateur01 (discuter) 28 septembre 2020 à 12:19 (CEST)Reply[répondre]
Ah bah, fallait le dire qu'il fallait trier     Programmateur01 : Attention quand même, au cas où, à {{smn}} : Wikipédia:Atelier accessibilité/Bonnes pratiques#Tableaux triables. 'toff [discut.] 28 septembre 2020 à 18:33 (CEST)Reply[répondre]
Je voulais surtout être sur que comment traiter les pieds de tableaux, le cas particulier du tableau triable était secondaire, bref merci a tous les deux pour les liens, Programmateur01 (discuter) 28 septembre 2020 à 18:46 (CEST)Reply[répondre]

Modèle de langue sur les marques et autres nom propres ?Modifier

Bonjour, faut-il utiliser le modèle {{langue}} sur les noms propres et en particulier les noms d’entreprises ou de marques qui ont peu ou pas de notoriété dans la francophonie ? Je suis en train de traduire un article qui liste de nombreux petits éditeurs américains, dont le nom est généralement un mot anglais suivi de « Press » ou « Books » : Groundwood Books, Children's Book Press, Lee & Low Books, Cinco Puntos Press, etc. Faut-il y apposer {{langue|en|...}} ? Merci d’avance. -- Okhjon (discuter) 4 octobre 2020 à 22:24 (CEST)Reply[répondre]

  Okhjon : bonjour. Je vais essayer de ne pas écrire de bêtise. En fait la question à se poser c'est : à quoi sert le modèle lang ? Il permet à un lecteur d'écran d'adapter sa prononciation en fonction de la langue qu'il lit. Je vais essayer de faire simple :
  • books : sans {{langue}}, un lecteur d'écran lambda devrait lire "Boque" au lieu de "boukse" -> modèle utile
  • press : sans {{langue}}, un lecteur d'écran lira "presse" -> modèle inutile (sauf si le lecteur d'écran intègre l'accent "anglais" dans sa prononciation ce qui rendrait la lecture plus "jolie" à entendre mais bon, la voix des lecteurs d'écran n'est pas forcément géniale d'origine, donc je pense qu'on peut s'en passer)
bon, après, j'ai testé avec un lecteur d'écran qui reconnait nativement le français et l'anglais, donc pour books, il prononce correctement, mais je ne suis pas sûr que ce soit le cas pour tous (donc par défaut, il faut présumé que non). Par contre, il n'a pas reconnu "Cinco Puntos". Je suppose que ça doit se prononcer "cineco pounetosse" alors qu'il m'a lu "cinq au pain tôt"  .
En espérant t'avoir aiguillé. 'toff [discut.] 7 novembre 2020 à 09:07 (CET)Reply[répondre]
  Okhjon : j'ai oublié de préciser, puisque ta question est « faut-il ? », qu'il n'y a pas d'obligation pour les noms propres (cf Modèle:Langue). 'toff [discut.] 7 novembre 2020 à 11:31 (CET)Reply[répondre]
Merci beaucoup pour ces clarifications 'toff. -- Okhjon (discuter) 7 novembre 2020 à 12:01 (CET)Reply[répondre]

États dont Élisabeth II est le chef d'ÉtatModifier

Cet article me semble être très représentatif de ce qu'il ne faut surtout pas faire, avec un tableau ne contenant aucune donnée réellement accessible, en dehors des en-têtes de rangées... Et cela depuis la création de la page, le 15 juin 2012. Cc SenseiAC. — Hégésippe (Büro) 25 octobre 2020 à 18:21 (CET)Reply[répondre]

Merci à Supertoff et Ideawipik pour leurs interventions des 28 et 29 octobre, cf. 1 et 2. C'est plus formel que les simples remerciements déjà faits via la fonction dédiée, mais j'y tiens. — Hégésippe (Büro) 29 octobre 2020 à 22:16 (CET)Reply[répondre]
Merci Hégé. Il reste un petit problème de contraste concernant la colonne "État ou royaume". Il faut soit assombrir le fond, soit mettre en gras le texte. Mais pour ce qui touche les couleurs, je ne peux m'en occuper. A+ 'toff [discut.] 30 octobre 2020 à 06:19 (CET)Reply[répondre]
@Hégésippe. De rien. Je voulais laisser un message ici, avant d'être pris par autre chose. En tout cas, c'était un bon exemple d'information donnée uniquement à travers des couleurs et de tableau illisible ne contenant que des… cases vides, pour une information, somme toute, assez simple. On pourrait faire encore mieux en termes d'accessibilité. Peut-être regrouper noms de pays et drapeaux dans la même colonne afin de n'avoir que deux colonnes (en retirant le colspan="2") ou en conserver trois en ajoutant un titre « D. » à son en-tête. Ajouter des « scope= » au tableau, reprendre les couleurs de fond, etc. Pour le premier point, le mieux serait, à mon avis, d'utiliser une colonne conjointe pour pays et drapeaux en se servant des modèles {{Pays}} ou de ceux de Catégorie:Modèle pays et drapeau. Inversement, « Période » pourrait être divisé en deux colonnes (Début et Fin). Je laisse à d'autres le soin de peaufiner cela. En ce qui concerne le contenu, il y aurait aussi quelques dates à vérifier, notamment pour Sainte-Lucie (1982 ou 1979 ?). Bonne journée — Ideawipik (discuter) 30 octobre 2020 à 08:41 (CET)Reply[répondre]
L'ancienne version de l'article contenait ce qui est plus proche d'un graphique que d'un tableau, maintenant ce tableau "nouveau" est tout bonnement ridicule, une liste conviendrait mieux pour faire le job d'autant qu'on a le nom du pays le drapeau est redondant.
L'auteur du graphique a-t'il au moins été prévenu sachant qu'il y avait peut-être passé du temps ? À tout hasard   SenseiAC :.
Arflhn (discuter) 7 novembre 2020 à 04:27 (CET)Reply[répondre]
  Arflhn : l'article a tout simplement été pompé de l'article anglais. Il n'y a pas beaucoup de temps passé dessus pour créer le tableau : version anglaise du 6 juin 2012 vs sur WP.fr le 12 juin. 'toff [discut.] 7 novembre 2020 à 06:12 (CET)Reply[répondre]

Et néanmoins on y perd, ces frises chronologiques ont le mérite d'être claires.

N'y aurait-il pas moyen d'avoir un modèle accessible pour ces frises chronologiques car leur usage est répandu.

Arflhn (discuter) 7 novembre 2020 à 13:57 (CET)Reply[répondre]

Bonjour   Arflhn. L'ancien tableau a été remplacé car, comme cela a été remarqué par le contributeur ayant entamé ce sujet de discussion, il n'était absolument pas accessible, dans sa forme, pour un lecteur mal/non-voyant. Tu peux très bien, si tu le souhaites, remplacer le tableau par une liste ou le modifier afin d'autoriser des tris par date de début et par date de fin. Si on veut faire une illustration graphique alternative de l'information, il est possible d'utiliser une image globale. Ou éventuellement des frises mais alors de "vraies frises" qui ne devront pas perturber la lecture par les liseuses (pas un tableau entièrement vide comme c'était le cas). Je ne sais pas quel élément HTML ou modèle permettrait cela. Est-ce que <timeline> (Aide:Frise chronologique) est accessible ? Si on en croit cette aide, une frise est similaire à une image. — Ideawipik (discuter) 7 novembre 2020 à 16:38 (CET)Reply[répondre]
Comme dit par Ideawipik (d · c · b), rien ne t'empêche de remplacer le tableau par une image. Cependant, l'image perdra complètement les informations accessibles. Dans ce cas, il faut compléter l'image par du texte, par exemple avec une liste à puces comme tu le suggérais (en fait, dans un article encyclopédique, normalement, la frise est un complément visuel au texte, pas l'inverse). 'toff [discut.] 7 novembre 2020 à 20:34 (CET)Reply[répondre]
Je passe sur l'histoire de complémentarité il n'y a pas de bon usage automatique en la matière.
Ce qui m'intéresse surtout c'est de savoir si le modèle Frise est accessible et si non, s'il existe un moyen de le rendre accessible.
Arflhn (discuter) 9 novembre 2020 à 21:58 (CET)Reply[répondre]
  Arflhn : je vais te décevoir : d'abord il n'existe pas de modèle {{Frise chronologique}}. Ensuite oui, une image est accessible pour autant qu'il y ait une alternative textuelle. Cependant, l'alternative d'une image décrit sommairement l'image sans donner d'information. En gros, pour la frise ici, il pourrait y avoir comme alternative : « liste des États dont Élisabeth II est ou a été le chef d'État », mais en aucun cas « Antigua-et-Barbuda, depuis 1981 ; Australie, depuis 1952 ; Bahamas, depuis 1973 » etc. 'toff [discut.] 9 novembre 2020 à 22:17 (CET)Reply[répondre]
@Supertoff tu m'avais bien compris je pense,
Donc y-aurait-il un quelconque moyen pour rendre ces frises accessibles car après-tout ce n'est pas une image avec du vecteur ou du pixel qu'il y a derrière mais du texte.
Arflhn (discuter) 25 novembre 2020 à 12:37 (CET)Reply[répondre]

Modèle animationModifier

Salut,

Existe t'il des problèmes d'accessibilité avec le Modèle:Animation ?

Arflhn (discuter) 28 octobre 2020 à 13:52 (CET)Reply[répondre]

Création d'une catégorie cachée Catégorie:Article contenant un ascenseur horizontalModifier

Bonjour,

Es ce que la création catégorie cachée Catégorie:Article contenant un ascenseur horizontal serait une bonne idée ? Manu1400 (discuter) 30 octobre 2020 à 16:59 (CET)Reply[répondre]

Accessibilité des modèlesModifier

Salut à tous,

Est-ce que cela existe déjà ? Ou à défaut pourrait-on créer un modèle "Accessibilité" à apposer dans la page de documentation des modèles pour voir rapidement s'ils le sont ou non ?

Arflhn (discuter) 9 novembre 2020 à 22:04 (CET)Reply[répondre]

Salut. Déjà, les modèles {{Infobox V3}} sont accessibles à contrario des V2 'toff [discut.] 9 novembre 2020 à 22:21 (CET)Reply[répondre]
PS : une catégorie devrait être suffisante non  ? 'toff [discut.] 9 novembre 2020 à 22:30 (CET)Reply[répondre]
  Supertoff :, un bandeau dans la page de documentation me semble plus visible, ces catégories de maintenance sont souvent utilisées par les seuls projets concernés.
Arflhn (discuter) 25 novembre 2020 à 12:34 (CET)Reply[répondre]

Inutilité de {lang} pour les anglicismes ?Modifier

Discussion Wikipédia:Le Bistro/5 décembre 2020#Utilisation du modèle langue -- Irønie (d) 5 décembre 2020 à 15:07 (CET)Reply[répondre]

Réponse apportée. 'toff [discut.] 5 décembre 2020 à 22:04 (CET)Reply[répondre]

Le modèle Méta chronologie problématique ?Modifier

Bonjour,

En utilisant le gadget accessibilité sur cette page, il semblerait que le tableau généré par Modèle:chronologie santé et médecine (lui-même généré par Modèle:Méta chronologie) possède une balise peu recommandable si l'on souhaite obtenir un tableau accessible.

Voici le message en question:

« Ce tableau ne devrait pas avoir de titre caption (code wiki |+)</caption> »

Également, est-il toujours recommandé d'utiliser cet outil ?

Merci d'avance pour vos réponses. ‒ TechAcquisitor (discuter) 31 décembre 2020 à 18:16 (CET)Reply[répondre]

Je ne suis absolument pas un expert en questions d’accessibilité, mais je crois comprendre que le message que tu décris est lié à cette recommandation et notamment la référence 18 (liant vers F46 des WCAG 2.0) : le tableau de l’infobox contient une balise <caption> vide, pouvant faire croire à certains outils qu’ils s’agit d’un tableau de données (avec un contenu intéressant sur le fond) alors qu’il s’agit que d’un tableau de mise en forme (utilisé seulement pour obtenir un certain résultat visuel sans que la structure "tableau" ne soit absolument nécessaire).
Je n’ai pas regardé le wikicode de l’infobox, mais s’il est possible de retirer facilement la balise <caption> (ou |+ en wikicode) ça devrait résoudre la problématique d’accessibilité.
~ Seb35 [^_^] 3 janvier 2021 à 17:04 (CET)Reply[répondre]
Cette question m’a intrigué et j’ai cherché plus profondément. Il s’agit en fait du paramètre "group1" (et paramètres numérotés similaires) de Modèle:Méta infobox navigation et plus précisément du paramètre "text" de Modèle:Infobox V3/Tableau début. Le modèle "Méta infobox navigation" est utilisé dans Modèle:Palette Années avec un paramètre "group1" vide, ce qui donne une balise <caption> affichée mais vide.
Toutefois, je ne sais pas exactement comment bien résoudre cela du point de vue accessibilité d’une part, et d’autre part la dimension technique comporte une certaine complexité du fait que des modèles sont utilisés des dizaines de milliers de fois. ~ Seb35 [^_^] 3 janvier 2021 à 19:08 (CET)Reply[répondre]
  TechAcquisitor : C'est normalement corrigé grâce aux indications de   Seb35. Un mauvais test dans {{Infobox V3/Tableau début}} qui ne fonctionnait pas lorsque le paramètre text était vide. --FDo64 (discuter) 4 janvier 2021 à 00:26 (CET)Reply[répondre]
Salut @Seb35 & @FDo64
Merci beaucoup pour vos réponses.
Même après la purge du cache (dans le doute), l'erreur est toujours détectée par le gadget. Honnêtement, je n'ai pas plus d'idées que vous pour trouver une solution (la quantité de modèles me donne le tournis un peu). ‒ TechAcquisitor (discuter) 4 janvier 2021 à 14:32 (CET)Reply[répondre]
C’est effectivement compliqué de s’y retrouver dans ces modèles (j’y ai passé un peu de temps hier pour m’y retrouver).
La modif que tu as faites, FDo64, a pour effet de donner la balise <caption> suivante quand text est vide : <caption class="hidden" style="background:#CEE0F2;" id="mwBw">Données clés</caption> qui fait 1x1 px (voir les styles de .hidden dans MediaWiki:Common.css).
J’aurais plutôt fait quelque chose comme {{#if: {{{text|x}}}|<caption …etc…>{{{text|Données clés}}}</caption>}}
Pour : 1/ afficher le <caption> avec le texte quand text est présent et non-vide, 2/ ne rien afficher quand text est présent et vide, 3/ afficher <caption>Données clés</caption> quand text est absent.
Par contre, je ne sais pas pourquoi ça n’a pas été fait dès le début et qu’il a été choisi d’utiliser une classe CSS hidden, autrement dit j’espère que ça ne casserait pas certaines choses (bots, JS) qui s’appuieraient sur la présence de la balise <caption>. ~ Seb35 [^_^] 4 janvier 2021 à 15:31 (CET)Reply[répondre]
Pour les problèmes d'intégration avec le reste de l'environnement (les bots), je peux toujours faire passer l'info au Projet:Bot pour avoir une idée.
Cela dit: le CSS, même encore aujourd'hui, est souvent utilisé comme vraie-fausse-solution pour faire disparaître du contenu, mais c'est une grossière erreur. M'enfin... ‒ TechAcquisitor (discuter) 4 janvier 2021 à 19:28 (CET)Reply[répondre]
Pour information, c'est un spécialiste de l'accessibilité qui a développé la brique {{Infobox V3/Tableau début}} donc je ne comprends pas pourquoi la modification que j'ai effectuée n'a pas suffit.
De plus, si j'ai bien compris le problème soulevé c'est que caption était vide, maintenant il ne l'est plus.
--FDo64 (discuter) 4 janvier 2021 à 19:34 (CET)Reply[répondre]
Bonsoir @FDo64 & @Seb35
En activant le bouton "Tableaux" de l'outil accessibilité, la balise html caption vide n'est pas détectée sur {{Infobox V3/Tableau début}}; en revanche, l'exemple sur Modèle:Chronologie santé et médecine#Exemple est souligné en rouge, avec le même message d'erreur.
Il semblerait que le souci provienne précisément de ce modèle plutôt que de {{Infobox V3/Tableau début}}. ‒ TechAcquisitor (discuter) 5 janvier 2021 à 20:31 (CET)Reply[répondre]
En fait, {{Modèle:Infobox V3/Tableau début}} comporte caption comme beaucoup d'infobox. Même si l’outil ne le revèle pas sur la page, il existe. Je pense qu'il serait bon d'uniformiser les modèles avec insource:/caption/. Il faudrait notifier Wikipédia:Atelier accessibilité, Projet:Modèle et peut-être même Projet:Charte graphique pour trouver une solution pérenne. Pour ce modèle, ainsi que beaucoup d'autres, il faudra qu'un administrateur fasse la modification. Il me semble que @Jules* et @VIGNERON ont une certaine expérience dans ces projets, qui plus est, ils pourraient réaliser la modification. --LD m'écrire 10 janvier 2021 à 22:42 (CET)Reply[répondre]
Salut ! L'atelier est déjà notifié semble-t-il @LD (à moins qu'il existe une autre page où il serait utile d'informer le projet). Merci pour ta réponse
cc   Projet:Modèle  - Projet:Charte graphiqueTechAcquisitor (discuter) 11 janvier 2021 à 01:07 (CET)Reply[répondre]

Mystérieux point d'exclamation dans l'interface de WikipédiaModifier

Veuillez m'aider... J'ai créé ma 1e page depuis 10 ans dans Wikipédia. Il y a après la création un affreux petit symbole "point d'exclamation rouge dans un triangle rouge" sur la 1e ligne après le nom de l'article, avec le timestamp de la dernière modif (le timestamp est clickable mais pas le symbole rouge). QUE VEUT-DIRE CE SYMBOLE BIZZARE SVP ? — Le message qui précède, non signé, a été déposé par l'IP 66.158.152.57 (discuter), le 1 février 2021 à 23:49 (CET) 66.158.152.57 (discuter) 2 février 2021 à 02:14 (CET)alainr345Reply[répondre]

Encore faudrait-il savoir de quelle page vous parlez ? 'toff [discut.] 2 février 2021 à 09:34 (CET)Reply[répondre]

Création d'articlesModifier

Bonjour,

Je ne parviens plus à trouver là où je sais combien d’articles que j’ai créés. Merci d’avance. --CuriousReader (discuter) 9 mars 2021 à 16:36 (CET)Reply[répondre]

Sur Wikiscan, champ « Articles créés », ou sur Xtools.
Tous ces liens sont accessibles tout en bas de votre liste de contributions. — Thibaut (discuter) 9 mars 2021 à 16:38 (CET)Reply[répondre]
  Thibaut120094 : merci beaucoup. Wikipédialement ! --CuriousReader (discuter) 9 mars 2021 à 17:31 (CET)Reply[répondre]

Projet:Articles audioModifier

Bonjour,

Je me demande s'il ne faudrait pas faire mention du Projet:Articles audio dans les pages de l'atelier accessibilité.

Si vous connaissez un endroit où vous pouvez y mettre un lien, n'hésitez pas à l'y insérer.

Bien cordialement,

--Hérisson grognon [mais gentil] 12 mars 2021 à 18:49 (CET)Reply[répondre]

Rupture d'action du gadget accessibilité dans la détection des alt= après la rencontre du Modèle:Relevé hydrologique ? Peut-on trouver une explication/solution ?Modifier

Une réponse a été apportée.

Bonjour, suite aux vérifications d'accessibilité sur le Portail:Lacs et cours d'eau, il s'avère que l'outil/gadget d'Accessiblité s'arrête d'agir après la rencontre du Modèle:Relevé hydrologique : exemple article Somme   faux, alors que canal de la Somme est   OK. Pouvez vous voir pourquoi ? ou mieux solutionner le sujet, sachant que le modèle relevé hydrologique a deux points particuliers : l'appel Timeline et l'appel de la catégorie Catégorie: Accessibilité : Graphique timeline sans alternative !  . PS: J'ai vérifié avec les quatre navigateurs Brave (habituel), Firefox, Google Chrome et Safari.

En vous remerciant d'avance de votre retour.--Philippe rogez (discuter) 24 mars 2021 à 15:16 (CET)Reply[répondre]

Bonjour. La demande n'est pas claire : je n'y ai rien compris : quel article est concerné, que veut dire "après la rencontre du Modèle:Relevé hydrologique", par quelle détection (le gadget en comporte 6, dire "faux" à propos du gadget ne veut rien dire). Merci de préciser votre demande. 'toff [discut.] 24 mars 2021 à 17:35 (CET)Reply[répondre]
Bonjour Supertoff. Je tente une traduction. Il s'agit de la détection « Alternatives ». En gros, dans la page Somme (fleuve), aucune image ne possède d'alternative textuelle. Le gadget indique à juste titre « ALT MANQUANT » pour les images du début de l'article mais pas pour celles de la fin, à partir de la section Somme (fleuve)#Canal de la Somme. D'où l'étonnement de Philippe rogez. Notons toutefois que si on clique sur modifier ladite section en wikicode et que l'on prévisualise, le gadget signale bien le défaut de texte alternatif. Il reste à trouver si une quelconque erreur de syntaxe, dans la page ou dans un modèle est à l'origine de ce léger problème. Le contributeur suggère que le problème puisse être lié à la présence de l'histogramme dans la section précédente de l'article, ce que la remarque ci-avant n'exclut pas. Voilà pour la clarification. Bien à vous. — Ideawipik (discuter) 24 mars 2021 à 19:23 (CET)Reply[répondre]
Merci de la clarification. C'est effectivement dû à {{Relevé hydrologique}} : si on le supprime en prévisualisation, les alt manquants apparaissent. Voilà pour ce qui est de la raison. Pour ce qui est de la solution, je n'en ai pas : le contributeur à l'origine de ce gadget a été banni (comme quoi on peut faire des choses bien et d'autres moins) et je n'ai pas les connaissances suffisantes pour corriger ou aider à corriger mais peut-être qu'un lecteur de cette section sera plus doué que moi. 'toff [discut.] 24 mars 2021 à 19:36 (CET)Reply[répondre]
Idem. Plus généralement un conflit avec la balise/extension <timeline> et peut-être d'autres. — Ideawipik (discuter) 24 mars 2021 à 19:48 (CET)Reply[répondre]
L’arrêt du script en milieu de page est corrigé (modulo les mises à jour de cache, je ne sais pas pourquoi ça ne veut pas passer chez moi). Par contre il faudra peut-être voir à avoir un comportement spécifique à <timeline>, je ne suis pas convaincu que le message affiché soit pertinent. — bonnes contributions, Ltrlg (discuter), le 7 avril 2021 à 15:06 (CEST)Reply[répondre]
bonjour Ltrlg (d · c · b)  Ltrlg : Super résultat  . merci encore de ta participation. Il me semble que l'on cherchait un spécialiste dans ce genre de spécialité technique, depuis un certain temps...   très cordialement et A+--Philippe rogez (discuter) 7 avril 2021 à 15:14 (CEST)Reply[répondre]
Je connais bien la structure actuelle du gadget, car c’est moi qui l’ai commise. Je suis un peu moins au point sur les détails de chaque test, mais je peux aider à les modifier ou à en créer au besoin. Je ne suis pas très actif sur Wikipédia ces derniers temps, mais si vous avez besoin d’un coup de main sur le gadget, je vois les notifications depuis les autres projets. — bonnes contributions, Ltrlg (discuter), le 7 avril 2021 à 16:18 (CEST)Reply[répondre]

┌────────────────┘
  Ltrlg : merci de cette offre de services, c'est bien aimable à vous/toi/? j'ai donc finalement modifier mon article test Somme (fleuve) pour les Alt=. Il me reste quatre soucis, dont trois que je n'ai pas encore eu le temps de regarder.

  1. Ce fameux relevé hydrographique avec Timeline me demande maintenant un alt= : suffit-il de modifier le modèle ?
  2. la galerie affiche un message rouge demandant de rajouter tous les alt= sur les images incluses alors que les paramètres y sont ? or gallery n'est pas un modèle !?!...
  3. mes palettes de fin d'article ne sont pas ok pour l'accessibilité, mais je ne sais pas encore quoi faire pour les mettre à jour.
  4. l'infobox Cours d'eau est une infobox v2 il faudrait qu'elle devienne V3 pour être accessible. souci identifié  .

que penses-tu des trois premiers soucis ? merci d'avance et à te lire--Philippe rogez (discuter) 7 avril 2021 à 16:29 (CEST)Reply[répondre]

  1. À ma connaissance, <timeline> ne permet pas de définir une alternative, d’où ma remarque précédente : il me semble inutile d’embêter les contributeurs avec ce problème non soluble en l’état.
  2. Ce message est affiché inconditionnellement par le gadget. Tu peux l’ignorer, puisque les alternatives sont présentes sur toutes les images. Il serait mieux que le gadget détecte automatiquement ce cas et n’affiche pas le message, et ça ne devrait pas être très compliqué à mettre en place.
  3. Les palettes sont un problème connu depuis des années, qui ne peut pas être corrigé au niveau des articles. Il y avait eu un brouillon de réforme, mais qui n’a jamais été appliqué. Tu peux les ignorer également. En gros la situation ressemble aux infobox (il y a plein de modèles à migrer), mais en plus les briques de base ne sont pas disponibles.
Une remarque au passage : je ne suis pas convaincu par les alternatives dans la galerie, identiques aux descriptions en-dessous. Une description de l’information visuelle supplémentaire serait souhaitable à mon avis.
— bonnes contributions, Ltrlg (discuter), le 8 avril 2021 à 22:40 (CEST)Reply[répondre]

Problème d'urlModifier

Adresse URL de « Gadgets »Modifier

Bonjour,
ayant modifié la première phrase de Activer le gadget accessibilité, pourriez-vous vous assurer que l'initiative est heureuse ?
Merci et Cordialement. 6PO (discuter) 3 juin 2021 à 12:52 (CEST)Reply[répondre]

Merci pour l'initiative, légèrement modifiée, avec une syntaxe de lien interne. — Ideawipik (discuter) 3 juin 2021 à 14:05 (CEST)Reply[répondre]
  Ideawipik (le lien interne — très judicieux — était hors de mes compétences !). Cordialement. 6PO (discuter) 3 juin 2021 à 20:49 (CEST)Reply[répondre]

Accessibilité des transcriptions phonétiques ?Modifier

Bonjour,

Le wikicode suivant :

La [[ville]] de '''Columbus''' (<small>prononcé en [[Anglais américain|anglais]] :</small> {{MSAPI|/kəˈlʌmbəs/}})
pose-t-il des problèmes d’accessibilité aux personnes aveugles et malvoyantes ? (page Columbus (Ohio)). Je me pose la question depuis longtemps. Merci de bien vouloir m’éclairer. Cdlt, Jihaim 9 juin 2021 à 23:18 (CEST)Reply[répondre]

Bonjour Jihaim  
La balise n'avait pas lieu d'être, je l'ai retirée. Merci ! — LD m'écrire 21 juillet 2021 à 04:18 (CEST)Reply[répondre]
Bonjour LD   et toutes mes excuses pour cette réponse trop tardive. Problème : il existe beaucoup beaucoup de transcriptions phonétiques avec cette wikisyntaxe. J'en ai effacé quelques-unes mais plus tard quelqu'un les réinstalle. Dès lors que faire ? Cordialement, Jihaim 19 août 2021 à 13:44 (CEST)Reply[répondre]
Bonjour Jihaim  
La première chose à faire serait d'ouvrir le dialogue en rappelant WP:Accessibilité avec les personnes concernées, et pour prévenir cette mésaventure, justifier l'édition par cette recommandation. LD m'écrire 19 août 2021 à 13:58 (CEST)Reply[répondre]
Un petit coucou à @Lœnidra. Je suggère que nous discutions avec @LD (et d'autres j'espère) de ces problèmes d'accessibilité. Cdlt,--Jihaim 19 août 2021 à 14:45 (CEST)Reply[répondre]
@LDAutre exemple, Baton Rouge. Jihaim 19 août 2021 à 14:50 (CEST)Reply[répondre]
Considérant le fait que les personnes ayant des difficultés de lecture peuvent zoomer l'entièreté du texte, on pourrait se dire que ce n'est pas problématique. Néanmoins, le fait d'avoir deux polices différentes peut poser des problèmes de lecture.
En ce sens, ces réflexions sur la perception de W3 sur la taille du texte devraient s'appliquer : il est préférable d'éviter deux polices différentes, le fait de diminuer la police localement peut restreindre l'accessibilité aux personnes ayant une vision du tunnel.
Si le texte mis entre <small> n'est pas essentiel à la lecture, il est toujours possible de privilégier une note. LD m'écrire 19 août 2021 à 15:05 (CEST)Reply[répondre]
Par ailleurs, s'il est vrai qu'on peut agrandir le texte, le texte en small reste toujours relativement petit par rapport au reste du texte, donc la personne devra agrandir encore plus pour pouvoir lire. — Thibaut (discuter) 19 août 2021 à 15:11 (CEST)Reply[répondre]
Bonjour, c'est vrai que ça peut poser problème. Je m'étonne de ne pas y avoir penser plus tôt… Je suis d'accord que la plupart du temps, le texte mis avec la balise small n'est pas très important et on ferait mieux de le mettre en note, ou de ne rien mettre du tout. --Lœnidra (discuter) 20 août 2021 à 10:09 (CEST)Reply[répondre]

Modèles, maintenance, etc.Modifier

Bonjour,

Je contribue de manière un peu masquée à l’accessibilité depuis mes débuts (vers 2011) grâce au gadget.

Mais aujourd'hui, je me suis dit qu'une patoune de plus serait la bienvenue.

J'ai commencé par créer {{accessibilité à revoir}}Catégorie:Accessibilité à revoir en signalant la création dans WP:Annonces. Également, les futurs nouveaux verront dans Aide:Que faire sur Wikipédia ? que c'est une tâche récurrente !

Je me dis également qu'un « mois de l'accessibilité » serait une bonne idée ! Un concours visant à améliorer l'accessibilité des pages, tout en permettant également de « sensibiliser » (je mets des guillemets car ce n'est pas partisan) les contributeurs : j'imagine que cette notion est encore assez floue, même si c'est un pré-requis pour les labels par exemple. Je vois souvent des questions et remarques sur les alternatives : les contributeurs ne manquent pas de bonne volonté mais seulement d'informations à ce sujet  

Ou bien proposer au Wikipédia:Wikiconcours pour sa session de septembre de faire une session spéciale Accessibilité ou créer un podium ou un prix spécial ! Bref, que d'idées !

Hormis cela, j'ai mis à jour Modèle:Blason-ville pour qu'il soit plus accessible  

Hâte de continuer cette aventure dans le projet ! — LD m'écrire 21 juillet 2021 à 04:38 (CEST)Reply[répondre]

  LD : salut. Pour info : {{Article hockey non accessible}} 'toff [discut.] 21 juillet 2021 à 12:30 (CEST)Reply[répondre]
Coincoinci supertoff   ça reste assez spécifique  
Aussi, j'ai créé Aide:Dyslexie, je ne sais pas trop comment le relier à l'atelier... — LD m'écrire 21 juillet 2021 à 13:26 (CEST)Reply[répondre]
Oui le hockey c'est spécifique, mais rien n'empêche de sous-catégoriser le hockey dans ta catégorie globale   'toff [discut.] 21 juillet 2021 à 17:43 (CEST)Reply[répondre]

Accessibilité du texte situé à coté de palettes latérales ou d'infoboxModifier

Bonjour   Manjiro91 et Tractopelle-jaune. En réaction à cette modification de la page Wikipédia:Atelier accessibilité, il me semble qu'elle a été réalisée parce que sur les écrans étroits, le modèle inséré latéralement à droite peut prendre une bonne part de la largeur d'affichage. Cela réduit l'espace restant pour le paragraphe situé à gauche et on se retrouve avec un ou deux mots par ligne. Ce problème concerne potentiellement toutes les pages sur Wikipédia, en particulier des pages de documentation de modèles de type infobox. Il est évident que la solution apportée n'était pas bonne, car elle altérait l'affichage et la lisibilité dans le cas général, avec des retours à la ligne inopportuns, tant pour le lecteur que pour la syntaxe HTML. Y a-il une prise en charge globale, à la source, de ce cas, par MediaWiki ou par une configuration CSS ? Ce serait logique. Dans le cas contraire, insérer le premier paragraphe dans un <div style="min-width:200px"> (largeur arbitraire), permettrait de garantir une largeur minimale pour le texte. Le cas ici était un peu différent. Merci Tractopelle-jaune d'avoir modifié la page, afin de limiter les risques d'affichage sur trois colonnes, avec du texte très étroit entre deux panneaux latéraux et pour les explications. — Ideawipik (discuter) 9 août 2021 à 23:19 (CEST)Reply[répondre]

Salut   Ideawipik,
Il n'y a aucune prise en charge globale de ces problèmes de flottants. Les cas problématiques dans les articles sont assez rares. Généralement, on les retrouve sur nos pages méta, et comme tu le mentionnes, dans les documentations de modèles. Ce sont par définition des pages un peu plus « brouillonnes » et techniques, souvent composés de multiples cadres et boîtes de navigation, d'exemples, de bouts de code, etc.
Parfois, changer l'ordre des cadres et objets flottants permet de régler déjà pas mal de problèmes, comme ici. J'ai passé la boîte raccourci en premier, car c'est un flottant droite. Il est suivi du fil d'Ariane (non flottant). Donc si la place manque pour le fil d'Ariane, il est renvoyé dessous. Et ce sans laisser de possibilité au paragraphe de tenter de s'y glisser subrepticement. J'ai ensuite mis l'avenue des cafés et bistros après le {{Clr}} suivant le cadre de navigation. Ainsi ce premier peut s'afficher (sur ordinateur de bureau) à droite de la table des matières (donc sans perte de place). Si la place manque, la table des matières est renvoyée dessous. Cet ordre force obligatoirement — quand la place manque — le RI de cette page à s'afficher entre le cadre de navigation et l'avenue des cafés et bistro. Il ne peut plus « divaguer » ailleurs.
Pour les documentations d'infobox, je pense que tu parles du problème des exemples. Avec le code à droite, et le rendu à gauche. C'est bien ça ?
Pour ces cas, j'ai plutôt tendance à agir au coup par coup, en vérifiant les points suivants :
  1. Le rendu de l'infobox doit être appelé avant d'afficher le wikicode dans la balise <pre>, ainsi l'infobox flottera à droite, en réduisant mécaniquement la taille du bloc <pre>.
  2. Ajouter la propriété CSS min-width:250px; (valeur arbitraire) à la balise <pre> : <pre style="min-width:250px;">. Ainsi, si la largeur de la fenêtre/écran n'est pas suffisante, le code n'est pas affiché à côté de l'infobox, mais renvoyé après celle-ci.
  3. Très important, ne pas oublier de mettre un coup de {{Clr}} après la fin du bloc <pre>. Cela à pour effet de forcer la terminaison des flottants, avant qu'un autre contenu puisse être affiché. Autrement, cela peut vite devenir le bordel (décalages intempestifs).
Et parfois, une « frappe chirurgicale » peut être effectué au début d'un RI ou paragraphe récalcitrant (sur des pages méta), quand malgré un traitement en bonne et due forme, des mots se retrouvent isolés. Cela consiste à ajouter un modèle {{nobr}} comme ceci. Ici, il est positionné pour empêcher une césure entre les deux mots, la partie avant le nobr (« L' ») n'a pas besoin d'être intégrée dedans, car un retour à la ligne ne peut pas s'effectuer dans une élision. Ainsi, le code reste plus propre et compréhensible. Cette solution est préférable que d'englober tout en paragraphe dans un <div>. C'est beaucoup moins lourd, plus facilement compréhensible par la plupart des éditeurs (même s'ils ne saisissent pas la raison exacte de l'utilisation du modèle à tel endroit, ils comprennent facilement ce qu'il fait). Comme ces deux mots sont devenus insécables, et qu'ils sont situés au début du paragraphe, ils n'arrivent plus à se glisser dans l'espace réduit disponible. Le paragraphe est alors intégralement reporté après le cadre. Si ces deux mots arrivent à se glisser ensemble dans l'espace disponible, on peut considérer que la largeur est suffisante pour permettre une lecture acceptable du reste du paragraphe.
L'autre problème des largeurs fixes, c'est que c'est très contraignant, et que cela a un impact global avec des effets indésirables possibles. Pour régler un seul problème, on impose une taille minimum qui n'est d'ailleurs pas forcément en relation avec la police utilisée et sa taille. On peut très bien configurer son navigateur pour réduire la taille de la police par défaut, et l'imposer si nécessaire aux sites. Une solution généralisée en pixels ne tient pas compte de cela, alors qu'un ajout chirurgical de {{nobr}} au début d'un paragraphe récalcitrant permet de rétablir la situation, sans autre impact.
De manière générale, l'interface mobile est peu utilisée pour les contributions avancées. Quel que soit (ou sera) son niveau de qualité, un téléphone portable reste foncièrement inadapté à une rédaction profonde ou à une maintenance efficace et efficiente. Je pars du principe qu'avoir quelques soucis de rendu sur des pages méta n'est pas très grave, s'agissant de contributeurs qui savent généralement ce qu'ils viennent y chercher.
On a déjà une telle dette technique concernant les documentations de modèles et les pages méta en général, qu'avant de me préoccuper de légers problèmes de rendus sur une plateforme spécifique — fondamentalement inadaptée pour contribuer de manière efficiente — j'essaie de commencer par le début : avoir des modèles documentés. Car parfois on en est encore là.
N'hésite pas en cas de questions. Je ne suis pas un expert en CSS (je ne suis pas programmeur), mais j'essaie de faire au mieux (et surtout que ce soit relativement propre).
Bonne soirée.
--Tractopelle-jaune (discuter) 10 août 2021 à 00:41 (CEST)Reply[répondre]
Merci Tractopelle-jaune pour la réponse complète qui servira aussi à d'autres. J'avais également pensé au {{nobr}} sur les premiers mots d'un paragraphe, pour le même effet et avais effectivement en tête les <pre>, en rédigeant le message sur l'attribut de style "min-width", adapté aux balises pré-existantes. La largeur fixe (en px) est à mettre en relation avec celle également fixe des infoboxes, mais on peut aussi spécifier des tailles en "em" pour moins dépendre de la police. En résumé : dans le texte simple (cas le plus courant), la solution "nobr" présente moins d'inconvénients que l'ajout d'une <div>, comme tu l'as bien détaillé.
Note : La surprise de   Manjiro91 peut aussi venir de la présence de caractères espaces insécables (que rien ne distingue, à l’œil dans le wikicode, des espaces normales) directement dans le texte. Ainsi, dans la première phrase de la section « Gadget accessibilité », il y avait un tel caractère entre ces deux mots, ce qui pouvait conduire à une ligne isolée « Le » et tout le reste du texte reporté sous le panneau latéral. Une correction a été apportée. — Ideawipik (discuter) 10 août 2021 à 06:57 (CEST)Reply[répondre]

Améliorations de l'accessibilité défaites par un utilisateurModifier

Bonjour, j'ai un différent avec   Berdea qui défait les améliorations effectuées par plusieurs participants de ce projet. Il favorise ses propres choix aux problèmes d'accessibilité. Je suis en pleine discussion avec lui <ici>, et le problème est identique sur bien d'autre palettes.

Je prends ses propos pour de l'obstruction. Cela couplé à d'autres problèmes de passages en force ou de guerres d'éditions, devient un problème de comportement. J'espère bien ne jamais avoir à faire de RA et préfère donc venir ici prendre conseil.

Concrètement, il refuse la mise en place du modèle {{liste horizontale}} (qui est accessible) et lui préfère les modèles obsolètes {{Liste éléments}} et {{·}} (qui posent des problèmes d'accessibilité). Il lui reproche la puce (qu'il n'aime pas) et les problèmes de sécabilité. Dans l'exemple ci-dessus, je lui ai démontré que le problème de sécabilité dévoilait un problème de conception de la palette. Nous avons là des listes à deux niveaux. Le premier niveau concerne un pays, le deuxième des pages dédiées. {{Liste horizontale}} répond à cela.

En tout cas, j'estime ces reproches très négligeables par rapport aux améliorations d'accessibilité apportées par {{liste horizontale}}.

J'irai même plus loin. J'aimerai faire une demande de bot pour remplacer puis supprimer {{Liste éléments}}.

Peut-être que je me trompe ? Peut-être que je surinterprète ? Peut-être que les explications que je lui fournis ne sont pas suffisamment claires ?

Votre aide et vos conseils seront les bienvenus.

--FDo64 (discuter) 27 décembre 2021 à 12:32 (CET)Reply[répondre]

Bonjour, je découvre ces listes et je trouve ça hyper intéressant - mais ne peut pas vous être d'un grand secours pour votre dispute... Mais apparemment cette liste horizontale n'est que pour les palettes ?... Je m'intéresse à l'accessibilité, sans beaucoup la pratiquer, surtout pour réfléchir à des façons de voir les choses. Touam (discuter) 30 décembre 2021 à 08:12 (CET)Reply[répondre]
Bonjour Touam  . Le modèle {{liste horizontale}} sert principalement pour la navigation sans être dédié aux palettes. Il sert également aux Infobox (par exemple, {{Guerres apaches}} et {{Fidji JO}}), aux portails et projets (par exemple, Portail:Ardennes/Arts) et même au Bistro.
--FDo64 (discuter) 30 décembre 2021 à 09:41 (CET)Reply[répondre]
Bonjour   Berdea et FDo64, je partage l'avis de FDo64 sur les avantages de l'harmonisation avec le modèle {{Liste horizontale}} davantage accessible.
En ce qui concerne la taille de la puce, de simples lectures sur divers navigateurs (en configuration par défaut) permettent de constater que la taille des puces peut différer d'un navigateur à l'autre. Ces réglages correspondent donc autant à des configurations logicielles de l'utilisateur qu'à des choix de rédaction sur Wikipédia. Concrètement, il est possible de personnaliser les puces par exemple en imposant dans son Utilisateur:Pseudo/common.css une image donnée ou, plus logique avec le fonctionnement en display inline, modifier le séparateur par défaut, par exemple
 
.liste-horizontale li:not(:last-child):after {
	content: "\A0•";
}
.
Si le séparateur par défaut est jugé globalement trop petit, on peut le modifier dans le common.css général. Il y a des idées de caractères dans en:Interpunct#Similar symbols. Cordialement. — Ideawipik (discuter) 2 janvier 2022 à 19:50 (CET)Reply[répondre]
Bonjour   FDo64 et Berdea,
J'interviens avec retard, mais je manque régulièrement de temps pour WP.
Je confirme entièrement les propos de FDo64. Et je rappelle que le modèle {{Liste éléments}} est destiné a être abandonné une fois que son remplacement aura été achevé. Les jours de ce modèle obsolète sont comptés depuis longtemps...
Il s'agit d'un modèle totalement archaïque, produisant une sortie HTML non-accessible (mélange de contenu et d'éléments de décoration). Son existence est (était) liée étroitement à l'existence d'un navigateur tout autant archaïque que lui, nommé Internet Explorer 7, navigateur qui n'en faisait qu'à sa tête quant au respect des standards du web...
Et je suis assez dérangé par le fait que des contributeurs annulent des travaux de maintenance visant à une meilleure accessibilité par derrière, car le rendu ne leur plaît pas. Cette palette, en utilisant {{Liste éléments}}, est totalement inaccessible au vu de sa taille.
Il n'est pas possible d'ajuster la taille de la puce avec {{Liste horizontale}}, car justement ce modèle ne génère pas ces puces lui-même, il ne fait qu'appeler la classe liste-horizontale définie dans MediaWiki:Common.css. Ce sont ces règles CSS qui vont gérer la mise en forme des éléments contenus dans ces listes.
Et c'est exactement ça le but, car les puces et parenthèses sont des éléments décoratifs, ils n'ont pas leur place dans le contenu. La séparation entre les différents contenus étant assurée sémantiquement (par le balisage HTML de liste).
Et autrement, pour la palette en question, les parenthèses sont parfaitement adaptées, car ce sont clairement des éléments de niveaux différents (pays → partis).
--Tractopelle-jaune (discuter) 8 janvier 2022 à 18:46 (CET)Reply[répondre]

Détection des médias inclus avec légendesModifier

Bonjour. Juste pour signaler une nouvelle détection relative à l'accessibilité des images : « Médias inclus avec légendes ». La "légende" n'est pas affichée mais est utilisée comme alternative ; sa valeur n'est pas forcément pertinente pour cela. Informations en anglais : mw:Help:Lint errors/inline-media-caption. On peut retrouver la liste des pages concernées sur l'encyclopédie Wikipédia francophone ici : Spécial:LintErrors/inline-media-caption. Le logiciel WPCleaner (fonction Linter) permet de repérer assez facilement, dans les pages, les syntaxes d'insertion d'image et modèles à améliorer. Point connexe : l'outil met aussi en évidence les images sans description alternative. — Ideawipik (discuter) 15 janvier 2022 à 12:08 (CET)Reply[répondre]

Bonjour et merci @Ideawipik, le Module:Wikiprojet est très concerné, il me semble que la correction est simple : la ligne 235 pourrait-elle changer en :wikitext( string.format( '[[Fichier:%s|40x20px|alt=<!--vide-->]]', projet.image, projet.nom ) ) ?
Une alternative vide, étant donné que l'icône est non essentielle, me paraît convenir. Il me semble cependant que alt="" ne suffit pas, bien que recommandé pour les alternatives décoratives, d'où ma proposition de commentaire HTML. Qu'en dis-tu ? LD (d) 15 janvier 2022 à 14:27 (CET)Reply[répondre]
Bonjour LD. Dans ce cas, je pense que le mieux est de mettre alt= sans rien derrière, pas même un commentaire HTML. Cela sort l'occurrence des cas détectés et correspond tant à ce qui est préconisé sur l'aide MediaWiki qu'à ce qui figure sur le guide HTML5 w3.org. Néanmoins, la présence d'un commentaire ne semble pas poser de problème technique. Elle peut avoir l'avantage de marquer que l'absence est volontaire et, dans ce cas, « non pertinent ici » ou « inutile ici » est peut-être plus explicite que « vide ». À toi de voir. — Ideawipik (discuter) 15 janvier 2022 à 15:08 (CET)Reply[répondre]

Dialogue dans un tableauModifier

Bonjour

Je viens de tomber sur un tableau avec un dialogue (Well... nobody's perfect!#Situation), en anglais à gauche et en français à droite.

Les balises d'indication de langue sont correctes, mais j'ai des doutes sur son accessibilité (et aussi sur son affichage sur les petits écrans).

Existe-il un modèle pour une telle présentation qui éviterait d'utiliser un tableau ?

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 janvier 2022 à 18:08 (CET)Reply[répondre]

Bonjour Şÿℵדαχ₮ɘɼɾ๏ʁ. On peut proposer (valeur de taille à préciser)
{{Début de colonnes|taille=25|nombre=2}}
{{Début de bloc solidaire}}
…
{{Fin de bloc solidaire}}
{{Début de bloc solidaire}}
…
{{Fin de bloc solidaire}}
{{Fin de colonnes}}
Tu peux même régler les marges avec un des paramètres marge ou style1 dans {{Début de colonnes}} et éviter l'usage détourné des « : ».
Enfin, y a-t-il un intérêt à ajouter des balises <poem>, actuellement absentes ? Attendons d'autres avis. Bien à toi. — Ideawipik (discuter) 15 janvier 2022 à 18:23 (CET)Reply[répondre]
Bonjour Ideawipik
Le problème est que justement, il n'est pas recommandé d'utiliser le paramètre nombre à cause de l'affichage sur les écrans en basse résolution. Ça ne concerne pas que les portables, mais aussi ceux qui lisent les articles avec un zoom très élevé. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 janvier 2022 à 18:45 (CET)Reply[répondre]
  SyntaxTerror : Il n'y a aucun problème à utiliser le paramètre nombre si — et seulement si — le paramètre taille est défini.
Le paramètre nombre se comporte alors uniquement comme un nombre de colonnes « maximal » autorisé. Cela évite d'étaler sur 5 ou 6 colonnes une liste, avec plus que 2 ou 3 éléments par colonne.
Mais si la largeur est limitée (smartphone), alors il peut très bien y avoir un nombre inférieur de colonnes que ce maximum possible. Le reste étant renvoyé dessous.
--Tractopelle-jaune (discuter) 15 janvier 2022 à 19:06 (CET)Reply[répondre]
Conflit d’édition et donc même réponse que la précédente. Rebonjour SyntaxTerror Il n'est pas recommandé d'utiliser le paramètre nombre seul mais le paramètre nombre associé au paramètre taille ne pose pas de problème. Le premier définit un nombre maximum de colonnes et le dernier assure une largeur minimum pour chaque colonne. Si l'écran n'est pas assez large, les deux éléments se retrouvent l'un au-dessous de l'autre. Le plus dur est de trouver une valeur pour taille la plus universelle possible. En raison de l'éventualité décrite, il serait préférable de rappeler, dans la version en français, l'initiale ou le nom du locuteur en début de ligne (au moins pour les deux premières). Aurais-tu préféré une traduction tirade par tirade ? — Ideawipik (discuter) 15 janvier 2022 à 19:13 (CET)Reply[répondre]
Conflit d’édition   SyntaxTerror : Par contre, en complément, effectivement, la doc de {{Début de colonnes}} n'en parle pas clairement (voir pas du tout). Il faut consulter celle de {{Colonnes}} pour avoir les explications détaillées (ces deux modèles gèrent les colonnes de la même manière).
Je rajoute immédiatement à ma todo-list une mise à jour urgente de cette page de doc, largement obsolète, ainsi que ses données TemplateData inutilisables en pratique (TemplateData est utilisé comme tableau de paramètres).
--Tractopelle-jaune (discuter) 15 janvier 2022 à 19:18 (CET)Reply[répondre]
  Tractopelle-jaune et Ideawipik : merci pour ce précisions.
En fait, je ne pense pas que cet article soit admissible après tout, sur wp.en il y a une simple mention sur la page d'homonymie en:Nobody's Perfect et je pense que ça serait suffisant.
Je ne vais pas passer plus de temps là-dessus tant que l'admissibilité n'aura pas été démontrée. Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 15 janvier 2022 à 20:12 (CET)Reply[répondre]

┌─────────────────────────────────────────────────┘

  SyntaxTerror et Ideawipik : Alors voilà :

  concernant Well... nobody's perfect!#Situation ; tableau de mise en page et listes de définition remplacés par {{Début de colonnes}} et {{Fin de colonnes}} + balise <poem> (diff).

  concernant la réécriture de la documentation de {{Colonnes}} (diff).

  concernant la réécriture de la documentation de {{Début de colonnes}} (diff).

Il me reste encore {{Fin de colonnes}} (ainsi que {{Début de bloc solidaire}} et {{Fin de bloc solidaire}}) à traiter, mais c'est moins urgent.

--Tractopelle-jaune (discuter) 21 janvier 2022 à 01:02 (CET)Reply[répondre]

Une classe CSS pour remplacer les usages détournés des en-têtes de tableau ?Modifier

Bonjour. J'observe régulièrement des tableaux pour lesquels les en-têtes (wikicode « ! » en début de ligne) sont utilisés de manière détournée à des fins de mise en forme (Wikipédia:Atelier accessibilité/Bonnes pratiques#Tableaux de mise en forme). Si on veut conserver le rendu esthétique, il faudrait remplacer ces ! texte par des |style="background-color:#eaecf0;"| '''text'''. Cependant, imposer une valeur de couleur de fond en dur dans les articles ne semble pas idéal car d'une part quiconque peut personnaliser son affichage de tableau avec une couleur différente pour ces éléments correspondant à <th> en HTML, d'autre part, la couleur fixée pour ces éléments est définie par le projet MediaWiki ou Wikipédia (peu importe à quel niveau) et peut être amenée à évoluer. Existe-t-il ou serait-il opportun de créer une classe CSS permettant d'imposer cette couleur de fond ? Elle serait définie à l'identique de celle des en-têtes dans le projet. Cela dit, on peut aussi considérer que la mise en gras du contenu suffit à mettre en exergue la ligne ou colonne concernée. Vos avis sont bienvenus. Cordialement. — Ideawipik (discuter) 19 janvier 2022 à 18:37 (CET)Reply[répondre]

Formats de dateModifier

Bonjour.

Du point de vue de l'accessibilité, tous les formats de date sont-ils équivalents ou certains formats sont-ils à privilégier ou à proscrire : {{date|25 janvier 2022}}, {{date|25.1.2022}}, {{date|25/1/2022}}, {{date|25-1-2022}}, {{date|25|1|2022}}  ?

Merci d'avance pour votre retour.

Cordialement, — Nad.Roz M'écrire 25 janvier 2022 à 07:34 (CET)Reply[répondre]

Bonjour. Sauf erreur de ma part, c'est le rendu final qui est important et pour toutes ces manières de les écrire dans le modèle, elles renvoient à chaque fois vers 3 liens : 22 janvier, janvier 2022 et 2022. Cf Wikipédia:Atelier accessibilité/Bonnes pratiques#Liens.
Après d'un point de vue personnel, je préfère la notation {{date|25 janvier 2022}} ou {{date|25|janvier|2022}} car je croise régulièrement des contributeurs qui utilisent la forme inversée (2022/01/25 par exemple). Sachant que parfois les américains mettent le mois avant le jour parfois, quand le numéro du jour est inférieur à 13, ça peut amener parfois à confusion : 02/01/2022 = 1er février ou 2 janvier ?. Mais c'est un avis perso. 'toff [discut.] 25 janvier 2022 à 10:18 (CET)Reply[répondre]
Merci @Supertoff. — Nad.Roz M'écrire 25 janvier 2022 à 20:54 (CET)Reply[répondre]
Bonjour Nad.Roz. Réponse semblable à la précédente. S'agissant du même modèle ({{date}}), toutes les syntaxes sont autant "accessibles" du point de vue du rendu, mais la version avec le mois en toutes lettres prête un peu moins à confusion dans certains cas, dans le texte. Dans une liste ou un tableau, sans équivoque possible, peu importe. Le modèle Date, outre l'ajout de liens internes, sert à respecter les règles typographiques qui requièrent une insécablité entre le numéro du jour et le nom du mois. Entre le mois et l'année, la règle est plus souple, mais Wikipédia en français a choisi de rendre insécable l'ensemble des trois éléments. Le modèle se charge aussi de mettre en forme le « 1er » avec exposant. Si tu souhaites bien formater les dates, sans ajouter de liens internes, tu peux utiliser {{date-}}. Attention, certains paramètres, de type date, de modèle ne nécessitent pas de formatage. Ils acceptent des formats bruts. C'est le cas des |date= des modèles bibliographiques et des paramètres |date de naissance= et |date de décès= de certaines (assez disparates) infobox relatives aux biographies ; les modèles assurent la mise en forme. Pour revenir aux modèles {{date}} (et variantes cf. Modèle:Palette Modèles liés au temps) et aux paramètres |date=. En général, on n'y touche pas, à partir du moment où le rédacteur ne s'est pas trompé. Il n'y a pas de raison d'imposer une forme de code plutôt qu'une autre. Ainsi, le modèle accepte indifféremment {{Date|1 May 2020}}, {{date|1 Mai 2020}} ou encore {{date|1er mai 2020}}, on pourra préférer une version en français, idéalement sans majuscule au mois, par cohérence avec le rendu, mais il ne faut pas éditer des articles pour ces détails de wikicode sans influence sur leur rendu (modifications cosmétiques fortement déconseillées). Ne cherchons pas non plus à faire des économies de quelques octets par articles au détriment de la clarté. Cordialement. — Ideawipik (discuter) 25 janvier 2022 à 22:13 (CET)Reply[répondre]
Merci @Ideawipik pour ces précisions utiles et intéressantes. Mon interrogation porte aussi sur la lisibilité des dates par les synthétiseurs vocaux en fonction du format date utilisé (comme pour le Modèle:Langue). Cordialement. — Nad.Roz M'écrire 26 janvier 2022 à 21:42 (CET)Reply[répondre]
@Nad.Roz. Dans les réponses précédentes, on peut lire « rendu » au sens visuel mais aussi au sens du code HTML généré qui sera identique quelle que soit la variante de syntaxe employée par l'utilisateur du modèle. C'est ce code HTML qui est lu par les synthétiseurs vocaux. Ils n'ont pas accès au wikicode. Sauf si on parle d'édition (après un clic sur « Modifier le code »)…
Détail supplémentaire à propos des modèles concernés, ils permettent d'assurer un tri chronologique correct dans les tableaux triables, car ils intègrent l'équivalent de la fonction de {{Tri}} (attribut data-sort-value).Ideawipik (discuter) 26 janvier 2022 à 22:24 (CET)Reply[répondre]
Merci beaucoup @Ideawipik et @Supertoff d'avoir pris le temps de me répondre et pour vos réponses complètes !  Nad.Roz M'écrire 26 janvier 2022 à 22:40 (CET)Reply[répondre]

Police de caractères LucioleModifier

Pour information : Discussion Projet:Scripts et gadgets#Utiliser la police Luciole. od†n ↗blah 15 février 2022 à 18:07 (CET)Reply[répondre]

Titre en anglais de jeu vidéo avec chiffre romain dans un article : LI + Langue + nobr = ?Modifier

Bonjour,

Ayant décidé, pour mes petits travaux de wikignome, de joindre accessibilité avec {{langue}} et typo avec {{nobr}} (entre autres), je me suis trouvé devant ce titre : The Elder Scrolls V: Skyrim → j'ai fait ça : ''[[The Elder Scrolls V: Skyrim|{{nobr|{{langue|en|The Elder Scrolls}} {{rom-maj|V|2=title="Nombre 5 écrit en chiffres romains"}}}}: {{langue|en|Skyrim}}]]'' ? [Il s'agit en particulier de faire dire au lecteur d'écran « cinq » (à la manière des pratiquants) et non « five », tout en conservant le V.]
The Elder Scrolls V: Skyrim : en soi le rendu fonctionne pour un humain sans problèmes d'accessibilité, mais est-ce que c'est à la fois OK pour le wikicode (bots etc.) et efficace en termes d'accessibilité (le contenu du title n'étant en plus apparemment pas lu ?) (WP:MORDRE  ) Merci pour vos lumières !
--   jilucorg → ✉ 21 février 2022 à 13:01 (CET)Reply[répondre]

Bonjour. Déjà, je peux me tromper mais àmha il y a une erreur dans ton code : il faut enlever les guillemets. Et pour faire simple, {{rom-maj|V|Nombre 5 écrit en chiffres romains}} donne : V si c'est ce que tu veux faire (l'infobulle fonctionne) ou éventuellement {{rom-maj|V|2=Nombre 5 écrit en chiffres romains}} qui a le même rendu : V.
En ce qui concerne l'accessibilité, et toujours si je ne dis pas de bêtise, un lecteur d'écran va lire : "The Elder Scrolls Nombre 5 écrit en chiffres romains Skyrim" (avec l'accent anglais avant et après le "Nombre 5 écrit en chiffres romains"). Alors qu'il suffit d'écrire ''[[The Elder Scrolls V: Skyrim|{{nobr|{{langue|en|The Elder Scrolls}} {{rom-maj|V|5}}}}: {{langue|en|Skyrim}}]]'' qu'un lecteur d'écran va rendre comme ça : "The Elder Scrolls 5 Skyrim". 'toff [discut.] 21 février 2022 à 17:22 (CET)Reply[répondre]
Ah merci beaucoup pour la correction ! Je ne savais pas si {{rom}} et {{rom-maj}} servaient bien par eux-mêmes à l'accessibilité. Je rectifie de ce pas.
--   jilucorg → ✉ 21 février 2022 à 17:44 (CET)Reply[répondre]
Quelques points pour mon avis :
  • Le {{nobr}} ne me semble pas justifié (il peut être contre-productif de trop empêcher les césures).
  • Pourquoi chercher à mettre le « 5 » en français, sachant que de toute façon tout le texte autour est en anglais ?
  • Il existe un modèle {{V}}, qui fait pile poil {{rom-maj|V|5}}.
En appliquant ces quelques points, on obtient le code ''[[The Elder Scrolls V: Skyrim|{{langue|en|The Elder Scrolls {{V}}: Skyrim}}]]''.
od†n ↗blah 21 février 2022 à 18:36 (CET)Reply[répondre]
Entendu pour le {{V}}, Od1n, le truc c'est qu'entre cette remarque sur {{nobr}} et celle d'Ideawipik, moi je ne sais plus trop sur quel pied danser…
--   jilucorg → ✉ 21 février 2022 à 21:17 (CET)Reply[répondre]
Au cas où, je rappelle que les chiffres romains ont leurs caractères spéciaux propres : Aide:Liste de caractères spéciaux#Chiffres romains majuscules. TED 21 février 2022 à 19:03 (CET)Reply[répondre]
« Pourquoi chercher à mettre le « 5 » en français, sachant que de toute façon tout le texte autour est en anglais ? » parce que personnellement quand je lis ce titre je le lis en anglais sauf le 5   Après, effectivement, c'est de l'ordre du détail, on pourrait très bien faire simple et tout laisser en anglais. 'toff [discut.] 21 février 2022 à 19:21 (CET)Reply[répondre]
Bonjour Jilucorg. D'accord sur tous les points de la réponse d'Od1n, avec peut-être, pour assurer une insécabilité, cette suggestion dont il faudrait vérifier la prise en compte par les lecteurs vocaux. ''[[The Elder Scrolls V: Skyrim|{{langue|en|The Elder Scrolls&nbsp;{{V}}: Skyrim}}]]''
Remarques relative à la (sur)abondance d'espaces insécables. Sur un support numérique dont le rendu dépend des configurations des utilisateurs (variabilité des largeurs d'écran…), des groupes insécables longs peuvent être un frein à la lisibilité et avoir un effet inverse de celui recherché, indubitablement valable pour les textes imprimés figés sur la page. Je tiens à préciser que le Lexique… dans sa section « Coupure de mots » indique que les dates s'écrivent avec une espace insécable obligatoire entre le quantième et le nom du mois. Il propose également une telle espace entre le mois et l'année en chiffres, mais il précise que l'on « pourra admettre » une coupure entre le mois et l'année (pas entre le jour et le mois). Les expressions concernant les saisons (exemple « printemps 2022 » ou « hiver 2009-2010 ») pourraient peut-être rentrer dans le même cadre d'exceptions. Une recherche rapide ne permet pas de rencontrer ces cas dans des manuels typographiques (mis à par le fait qu'il faudrait écrire en toutes lettres quand on écrit la décennie sans le siècle, comme « années soixante », expression de toute façon déconseillée sur Wikipédia qui préconise « années 1960 »). Avis aux experts ! Cet exemple de publication en ligne trouvé au hasard sur openedition.org ne présente pas d'insécabilité entre le mot années et les quatre chiffres de ladite décennie. Le cas des saisons/années est selon moi dans la zone grise. Mais, plus généralement, même si le sens a bien son rôle dans l'édiction des règles typographiques, il ne faut pas confondre "groupements insécables" typographiques et groupes sémantiques ne justifiant pas l'insécabilité.
P.S. – Merci d'avoir soulevé la question et de t'intéresser à l'accessibilité. — Ideawipik (discuter) 21 février 2022 à 20:35 (CET)Reply[répondre]
Bonjour Ideawipik, merci de ce regard, je tâcherai de prendre garde à la longueur des chaînes, c'est vrai qu'il faut penser en particulier aux smartphones…
--   jilucorg → ✉ 21 février 2022 à 20:56 (CET)Reply[répondre]
Eh oui Supertoff, merci ! Comme je l'avais indiqué, pas un joueur ne dira « The Elder Scrolls Five », lecture orale qui pourrait surprendre le lecteur (malvoyant), ce qui est je crois déconseillé…
--   jilucorg → ✉ 21 février 2022 à 20:51 (CET)Reply[répondre]

Coupe du monde de biathlon 2021-2022Modifier

Bonjour. Le contributeur Supertoff a posé un bandeau d'accessibilité sur la page Coupe du monde de biathlon 2021-2022. Il dit qu'il y a un problème à corriger sur les tableaux. Il faudrait votre aide, car personnellement, je n'y comprends rien et ne vois pas où est ce problème qui a failli générer une guerre d'édition (dans la mesure où j'ai voulu retirer ce bandeau, ne comprenant pas son objet). Donc, si quelqu'un pourrait aller voir ça, et éventuellement corriger ce qui ne va pas, ça permettrait d'enlever le bandeau d'accessibilité sur une page sûrement très consultée. Merci d'avance. Jmex (♫) 13 mars 2022 à 14:30 (CET)Reply[répondre]

Bonsoir,
J'ai tenté une contribution sur la section Classements généraux avec des div avec la propriété flex. Si le résultat est satisfaisant en revanche je ne sais pas si c'est autorisé d'insérer ce genre de code html sur les articles, seulement 4 articles utilisent le même procédé. Et ça ne me parait pas une bonne idée de laisser ce genre de code assez complexe sur l'article sans qu'il se dégrade au fil du temps, passer par un/des modèle(s) serait mieux mais il ne me semble pas qu'il en existe un qui utilise la propriété CSS flex pour l'instant.
J'avais testé également avec les modèles {{Début de colonnes}} et {{Fin de colonnes}} en mettant autour de chaque tableau les modèles {{Début de bloc solidaire}} et {{Fin de bloc solidaire}} mais cela produit un léger décalage sur la 2e colonne. D'autres avis ? Cordialement --Rayquachu (discuter) 15 mars 2022 à 22:18 (CET)Reply[répondre]

Infos à intégrer dans la légende alternativeModifier

 
Don Cherry est l'entraîneur de l'équipe entre 1974 et 1979.

Bonjour tout le monde,

Question naïve d'un débutant (sur WP, et encore plus dans le domaine de l'accessibilité) : quand on rédige un texte alternatif associé à une image, faut-il considérer que la légende elle-même sera lue en supplément ? si oui, j'imagine qu'il faut éviter la redondance dans le texte du alt ; sinon il faut probablement commencer par reprendre les infos de la légende qui sont a priori l'essentiel à connaître.

Je ne sais pas si je me suis bien fait comprendre, n'hésitez pas à me demander de clarifier (je mets la page en suivi).

La réponse pourrait être intégrée explicitement dans les pages d'aide, par exemple Aide:Insérer une image (wikicode, avancé).

Question connexe : j'imagine que les fautes d'orthographe dans le texte alternatif n'ont pas grande importance, si elles ne s'entendent pas, et qu'on les corrige surtout pour le confort de lecture des personnes travaillant sur l'article ?

Bravo pour votre travail, bien cdt — Couleys [कुरा गरौं] 2 avril 2022 à 12:00 (CEST)Reply[répondre]

  Couleys : Bonjour. D'abord un lien utile : Wikipédia:Atelier accessibilité/Bonnes pratiques. Ensuite, la légende et l'alternative n'ont pas le même but et ne doivent (peuvent) donc pas être identiques. La légende est un texte libre laissé à l'appréciation du contributeur. L'alternative est une description de l'image. Par exemple, si tu vas sur l'article Bruins de Boston, tu y verras la photo de Don Cherry (que je reproduis ici). La légende dit : « Don Cherry est l'entraîneur de l'équipe entre 1974 et 1979. » alors que l'alternative décrit l'image : « Photographie couleur de Don Cherry en costume-cravate dans les tribunes d'une patinoire. Il porte une chapka surmontée de deux drapeaux canadiens. ». Est-ce que ça répond à ta question ? 'toff [discut.] 2 avril 2022 à 12:34 (CEST)Reply[répondre]
Merci ! c'est parfaitement clair en termes de pratique à suivre ; juste pour ma compréhension (et pour mémoriser…), ça veut dire que dans le cas d'une « lecture audio » (je ne suis pas familier de la terminologie, et je me fais une idée a priori du processus) de l'article, la légende sera lue par la machine avant le texte alternatif ? — Couleys [कुरा गरौं] 2 avril 2022 à 12:43 (CEST)Reply[répondre]
J'avais oublié de notifier 'toff dans ma réponse (et ma question). J'espère mettre en pratique ce conseil, par exemple dans cet ajout. Bien cdt — Couleys [कुरा गरौं] 9 avril 2022 à 19:51 (CEST)Reply[répondre]

Nouveau calendrier bistro sans quadrillageModifier

Bonjour à tous,

Après une discussion sur le bistro voir Wikipédia:Le Bistro/4 juin 2022#Proposition pour refaire le calendrier à droite du bistrot il a été évoqué l'idée de refaire le calendrier et la boite du bistrot pour un peu moderniser avec un rendu final qui devrait ressembler à ça. Cependant il n'y a plus le quadrillage pour les jours et je me posais la question si oui ou non cela était un problème pour l'accessibilité.

Cordialement, Edoirefaitdel'art (discuter) 4 juin 2022 à 22:09 (CEST)Reply[répondre]

Bonjour. En termes d'accessibilité, le quadrillage n'apporte rien. Ce qui est important c'est le contraste. Par contre, utiliser les points d'exclamation (dans ton exemple) pour faire du gras, c'est non accessible. 'toff [discut.] 4 juin 2022 à 23:47 (CEST)Reply[répondre]

Alternatives textuelles des images, logos, etc.Modifier

Pour ceux intéressés :

Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 10 août 2022 à 00:58 (CEST)Reply[répondre]

Retour à la page du projet « Atelier accessibilité ».