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

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

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)

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)

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)

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)

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)

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

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)

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)

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)

Dialogue dans un tableau

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)

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)

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)

 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)

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)

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)

 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)

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

 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)

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

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)

Formats de date

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)

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 = 1^er février ou 2 janvier ?. Mais c'est un avis perso. 'toff ^[discut.] 25 janvier 2022 à 10:18 (CET)

Merci @Supertoff. — Nad.Roz ^M'écrire 25 janvier 2022 à 20:54 (CET)

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 « 1^er » 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)

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)

@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)

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)

Police de caractères Luciole

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

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

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)

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)

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)

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)

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)

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)

« 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)

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 {{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)

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)

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)

Coupe du monde de biathlon 2021-2022

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)

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)

Infos à intégrer dans la légende alternative

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)

 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)

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)

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)

Nouveau calendrier bistro sans quadrillage

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)

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)

Alternatives textuelles des images, logos, etc.

Pour ceux intéressés :

• Discussion modèle:Infobox Organisation2#Pas d'alternative textuelle pour les images, logos, blasons ?  Fait.
• d:Wikidata:Property proposal/alt text
• T166094 sur Phabricator

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

Modèle Lecture audio

Bonsoir,

L'article Whonix utilise un arbre généalogique pour mettre en forme un schéma sur son fonctionnment. Manifestement pas très accessible, je souhaiterais le remplacer. Ne trouvant pas d'images sur Commons (et n'ayant pas le temps pour l'instant de la créer), existerait-il un modèle uniquement visible pour les systèmes de lecture audio afin d'indiquer le contenu du schéma temporairement ?

Merci d'avance, ⁣

🐢 Monsieur Tortue (💬) 16 août 2022 à 21:01 (CEST)

Bonjour Mr Tortue. Faire une capture d'écran du tableau et la télécharger sur Commons prendrait cinq minutes, faire un SVG peut être une vingtaine, donc ce n'est pas le problème ici, il suffit de demander (sur l'atelier graphique, ou à moi directement).

Par contre, je ne vois pas trop l'utilité de ce tableau composé en gros de deux lignes. Une bien meilleure solution serait de l'expliquer par un court paragraphe, qui conviendrait à tout le monde, voyants, malvoyants et aveugles. En gros, au lieu de mettre une alternative textuelle pour le tableau, on ne met que l'alt. dans un paragraphe et le problème est réglé.

Sans compter que les tableaux ne sont ni accessibles, ni compatibles avec la version mobile du logiciel de rendu (c'est à dire que ça s'affiche très mal sur une partie des téléphones portables en gros).

Par contre, le problème majeur que je vois sur cet article est le manque cruel de sources : apparemment il n'y a aucune source secondaire, à part pour une phrase du RI (et aller les prendre que wp.en ne réglera pas le problème, il y a là-bas un bandeau disant que ce sont principalement des sources primaires). Cordialement, Şÿℵדαχ₮ɘɼɾ๏ʁ 17 août 2022 à 17:37 (CEST)

Taille de police

Je signale cette discussion et phab:T316948. Cordialement, Patafisik (WMF) (discuter) 2 septembre 2022 à 18:46 (CEST)

Accessibilité palette

Bonsoir. Je n'arrive pas à accéder complètement à la palette Modèle:Palette Droits LGBT en Afrique. En cliquant sur "modifier le code", on a seulement accès à la modif du bandeau et aux catégories mais pas au corps de la palette (liste des pays). Pouvez-vous m'aider ? Polymagou (discuter) 15 décembre 2022 à 00:55 (CET)

Bonjour. Cette question n'a pas de rapport avec l'accessibilité. Cependant, le texte de la palette est ici : Modèle:Méta palette de navigation Afrique mais attention avant de le modifier, ça touche beaucoup d'article via l'insertion dans d'autres palettes comme Modèle:Palette Droits LGBT en Afrique. 'toff ^[discut.] 15 décembre 2022 à 07:28 (CET)

OK, merci beaucoup. Polymagou (discuter) 16 décembre 2022 à 01:10 (CET)