Discussion Wikipédia:Articles de qualité/Accessibilité

Nouveau critère ?

Depuis que l'on m'en a parlé, je m'efforce d'ajouter des alternatives textuelles aux images pour des questions d'accessibilité. Et je me rend compte par ailleurs que les bonnes pratiques d'accessibilité sont souvent inconnues du grand public. Etant donné que les AdQ et les BA sont les articles « exemplaires » (à valeur d'exemple) de Wikipédia, je me demandais s'il ne serait pas intéressant d'ajouter un critère du style « respect des bonnes pratiques concernant l'accessibilité » aux conditions d'attribution des labels AdQ et BA. Ascaron ¿! 12 août 2010 à 14:17 (CEST)

Bonjour,
Une discussion avait déjà eu lieu il y a longtemps sur cette idée (voir ci-dessus, section « Articles de qualité et accessibilité, tâtage de terrain »), et je me souviens l'avoir vu rapidement évoquée une ou deux fois depuis. Jusqu'ici, disons que cela n'a pas éveillé beaucoup d'attention.

Concrètement, l'invitation à tenir compte autant que possible dans les AdQ etc. des bonnes pratiques d'accessibilité figure déjà dans ce tableau indicatif.

S'il s'agit plus loin, ce qui pourrait être une excellente chose, il faut cependant le faire avec prudence :

• s'assurer avant tout que cette démarche ne suscite pas de réticences : la prise en compte de ces questions qui semblent assez lointaines pour beaucoup de contributeur n'a de chance d'être profitable que si elle est volontaire et bien acceptée
• il ne serait pas réaliste aujourd'hui de demander le respect de l'ensemble des bonnes pratiques dans ces articles : plusieurs se heurtent aux limites techniques actuelles de mediawiki, certaines sont en contradiction avec les souhaits éditoriaux immédiats, d'autres sont vraiment difficiles à mettre en œuvre pour des rédacteurs qui ne sont pas des techniciens (il ne s'agit pas de transformer ceux qui sont avant des producteurs de contenu en spécialistes d'une question technique).

Il faut donc plutôt de s'en tenir à une liste très réduite de quelques bonnes pratiques de niveau prioritaire, à la mise en œuvre aisée et qui ne présent aucune contradiction avec les souhaits éditoriaux.

Je recommanderais de retenir comme critères à valider pour un contenu de qualité (ce qui ferait déjà beaucoup) :

• les tableaux de données (présence du titre de tableau et des en-têtes de colonne et de ligne correctement balisées ; en revanche, ne pas prendre en compte la question des tableaux triables)
• les changements de langue (qui sont déjà assez bien passés dans les usages)
• les titres de section (absence de faux-titres simulés par divers moyens)
• les citations (mise en œuvre aisée, déjà en grande partie dans les usages via les modèles)
• les listes (à puces, numérotées, de définition, idem)
• la couleur (plus délicat, mais souci partagé par un assez grand nombre de contributeurs apparemment)

Ce sont en fait tout simplement les principaux critères que l'on retrouve dans toutes les directives d'accessibilité pour les rédacteurs de contenu dans d'autres projets, en particulier ceux qui ont des obligations légales à cet égard (sites publics français par exemple).

En revanche, les alternatives textuelles, par exemple, sont clairement à exclure même s'il s'agit d'un problème de niveau prioritaire : elles sont beaucoup trop complexes à gérer pour les rédacteurs et les implémentations actuelles dans mediawiki et dans ses extensions sont de toute façon à revoir.

Enfin, pour ce qui de la manière de proposer cela : il faudra établir une liste de ces BP sur une page spécifique, sous une forme simplifiée, et présenter une argumentation mettant en particulier en évidence le fait qu'il s'agit de pratiques déjà en partie adoptées indépendamment de l'accessibilité, qu'il s'agit donc surtout de « consolider ».

Cordialement, --Lgd (d) 15 août 2010 à 07:27 (CEST)

En prenant en compte tes remarques, voilà à quoi pourrait ressembler le critère à ajouter à Wikipédia:Articles de qualité :

« Un article de qualité doit se conformer aux principales Directives d'accessibilité des contenus Web détaillés sur cette page. »

Ascaron ¿! 15 août 2010 à 12:07 (CEST)

y'a du bon. Je me demande s'il ne serait pas habile de renommer et de compléter l'essai dans le sens Wikipédia:Articles de qualité/qualité technique, pour y ajouter les considérations sur les tailles d'images (WP:IMG) qui sont à présent bien admises. Je n'aime pas le terme « technique » là dedans (c'est de la qualité éditoriale sur le fond, mais ce dernier terme ne sera pas bien compris ici dans ce cas), mais bon, c'est ce que j'ai de mieux sous la main pour le moment. Dodoiïïïïste ?  ? Cordialement, --Lgd (d) 15 août 2010 à 12:13 (CEST)

Les considérations sur les images devraient plutôt faire l'ajout d'une précision au critère n°3 ; par exemple :

« L'article doit contenir des illustrations pertinentes, avec des légendes courtes et un statut légal acceptable, respectant les recommandations en vigueur. [...] »

Ascaron ¿! 15 août 2010 à 13:03 (CEST)

J'avais dans l'idée que donner aux contributeurs participant à la validation des contenus de qualité une amorce de grille de critère organisée (le purement rédactionnel d'un côté, le plus formel ou technique de l'autre) serait profitable, mais dans un premier temps, ta proposition se tient. Cordialement, --Lgd (d) 15 août 2010 à 13:07 (CEST)

J'aime bien aussi. Quand au nom... « conventions techniques » ? Cela évite de répéter le mot « qualité ». Mais je suis pas trop convaincu. « Conventions de syntaxe wiki » ?

Au niveau de la structure, le début est très bon. Mais on pourrait affiner un peu :

1. Un résumé par section qui tient en un paragraphe est excellent. Mais il gagnerait à être plus vulgarisé car actuellement le style est complexe et plein de jargon.
2. Un exemple de syntaxe valide ou d'erreur courante (selon lequel est le plus pertinent), oui. Par contre, ne pas en faire trop : pour les titres de section, il n'est pas nécessaire de mentionner la syntaxe « <h4> » qui n'a pas vocation à être utilisée dans les articles.
3. Un lien vers les bonnes pratiques pour en savoir plus est très bien aussi. Par contre, c'est insuffisant dans les cas des tableaux et des couleurs, où une page dédiée serait nécessaire. Et peut-être qu'il faudrait plus de précisions au sujet des changements de langue, vu que nous avons eu plusieurs de demandes de précisions et confusions à ce sujet : pas de changements de langue sur les noms, ni sur les mots étrangers entrés dans l'usage, etc.

Un bon début, donc. Á peaufiner. :-) Dodoïste ^{[ dring-dring ]} 15 août 2010 à 22:46 (CEST)

Voilà les quelques modifications que j'ai réalisés :

1. Pour davantage vulgariser, j'ai uniquement conservé les références au wiki et donc retiré celles à l'HTML (lang, ul, ol, dl, dt dd). Le reste de la page me semble suffisamment "accessible" aux lecteurs.
2. Ces pages dédiées aux tableaux et aux couleurs existent-elles déjà ? Je devrais peut être mettre un lien vers Aide:Les tableaux pour les novices (il faut vérifier que cette dernière page est à jour d'un point de vue accessibilité). Pour les couleurs, c'est souvent un sujet sensible ; je n'ai donc pas préciser. Pour les changements de langues, je n'ai pas trouvé de discussions sur la pdd de l'atelier relatives à cette question : n'hésite donc pas à modifier la page.

Ascaron ¿! 16 août 2010 à 08:24 (CEST)

C'est un très bon départ. J'ai déjà quelques idées d'améliorations. Mais avant toutes choses, j'aimerais relancer un marronnier (désolé) : la documentation des modèles {{Guillemets}} et {{Citation}} est évasive et ne renseigne en rien sur la finalité du <span class="citation">...</span> introduit par Citation, et n'indique pas pourquoi Guillemets est à proscrire. Des éléments de réponse nous sont fournis dans la PDD de Guillemets, mais ces informations devraient être mises en lumière dans la documentation. J'ai tourné en rond entre la documentation, les BP et le brouillon d'Ascaron pendant 15 minutes ce matin avant de comprendre que Guillemets était obsolète depuis un an !

Sinon, pour le brouillon, est-ce qu'il faut se cantonner à un pense-bête succinct et efficace, ou bien détailler dans chaque paragraphe les raisons pour lesquelles telle syntaxe est plus accessible que l'ancienne ? Voire jusqu'à donner des exemples d'application particuliers (utilisation des listes de définitions pour les voxographies de films par ex.) ? Tachymètre ^(me parler) 16 août 2010 à 12:10 (CEST)

Pour le brouillon, je pense en effet qu'il ne faut pas trop détailler les directives sous peine de tomber dans des critères abscons qui ne risque pas d'être appliqués par la suite. C'est la raison pour laquelle est ajouté plusieurs liens vers l'atelier accessibilité si le lecteur veut de plus amples infos. Ascaron ¿! 16 août 2010 à 12:25 (CEST)

Merci Ascaron pour ces améliorations. :-)

C'est cela. Il faut que cette page reste une liste de critères rapide à lire. Des détails sont bienvenus sur les bonnes pratiques ou une page dédiée. La page Aide:Les tableaux pour les novices est à jour niveau accessibilité, et ses consorts le sont autant que possible (mais pas entièrement sur certains détails). Par contre, ces pages ne sont pas suffisemment complètes niveau accessibilité.

Une bonne partie du code utilisé pour la mise en page de Wikipédia:Articles de qualité/Accessibilité est justement non accessible. Les tableaux sont utilisés pour de la mise en forme en faisant usage de gras pour simuler un titre. Il vaudrait mieux utiliser de bons titres de tableaux, comme dans les bonnes pratiques de l'atelier. Dodoïste ^{[ dring-dring ]} 16 août 2010 à 21:30 (CEST)

Si je ne me trompe pas, les seuls aspects non accessible du code sont la simulation de titre ; malheureusement, je ne sais pas régler le problème sans casser l'ergonomie : ni avec les ==== (qui son habituellement réservés pour des titre de section) ni avec la balise |+ qui permet de mettre un titre au dessus des tableaux et non dans les demi-tableaux. Si tu as une solution, je suis toute ouïe . Ascaron ¿! 17 août 2010 à 08:09 (CEST)

Sinon, concernant le contenu, je pense que la page est arrivée à maturité ; si tu le désires Dodoïste, il ne te reste plus qu'à apporter des précisions sur les changements de langues. Tachymètre veut peut être proposer d'autres améliorations. Dans tous les cas, quelle est l'étape suivante ? Une proposition par PDD ? Ascaron ¿! 17 août 2010 à 08:09 (CEST)

(retour ligne) Je viens de réécrire certains passages pour les rendre plus clairs. À propos des listes de définition, depuis peu, j'applique une recommandation (je ne sais plus où je l'ai lue) demandant de remplacer les listes par des listes de définitions quand c'est possible : avant/après pour les descriptions, avant/après pour les voxographies. Est-ce que c'est correct et si oui, devons-nous préconiser cette méthode dans la check-list ? Ensuite, concernant la célèbre boîte déroulante... Laquelle de ces deux propositions vous paraît la moins mauvaise : tableau enroulable ou tableau enroulé ? Une section sur les boîtes déroulantes est-elle prévue ? Tachymètre ^(me parler) 17 août 2010 à 11:12 (CEST)

J'ai retiré une explication sur la bonne pratique des citations car je pense qu'il faille se limiter à l'énoncé de la pratique, les raisons étant détaillées dans l'atelier. Pour le remplacement des listes par des listes de définitions, si tu retrouves la référence alors oui, je pense qu'il serait bon de l'ajouter à la page. Enfin, pour les boîtes déroulantes, il n'y a aucun paragraphe sur le sujet dans les bonnes pratiques de l'atelier accessibilité ; je serais donc contre l'ajout d'une section sur les boîtes déroulantes tant qu'il n'y aura pas un paragraphe dans l'atelier car la page pour le critère AdQ est (et doit le rester) un morceau simplifié de l'atelier. Ascaron ¿! 17 août 2010 à 12:16 (CEST)

J'ai fait deux modifications de mise en page, qui sont accessibles. Si cela vous convient, on l'étend au reste de la page. Je conviens que c'est un peu moins joli, si vous avez d'autres idées de mise en page accessibles, n'hésitez pas. Mais c'est pas facile.

Pour la suite, surtout pas de PDD, c'est bien trop lourd. Et surtout, pas nécessaire. Ces bonnes pratiques-là sont en train d'entrer dans l'usage. Elle sont déjà adoptées sans réticence. Il s'agit plutôt d'encourager l'accessibilité par des initiatives comme celle-ci. Il n'y a pas non plus besoin d'une PDD pour changer les critères AdQ, surtout lorsqu'il y a consensus (cf. une modification quelques sections au-dessus).

Pour les listes de définitions : L'usage dans Unreal (jeu vidéo)#Armes est presque correct. Mais il ne faut pas de retour à la ligne entre chaque définition. Faute de quoi cela créée plusieurs listes de définitions d'un élément, au lieu d'une liste de définitions de plusieurs éléments. Voir ma précision dans ces bonnes pratiques. Dans Red Faction#Personnages et voix la principale définition devrait être liée au nom défini comme pour les noms des interprètes. Et le symbole Unicode est lu comme un "point d'interrogation" par la plupart des lecteurs d'écrans. Faudrait utiliser une icône accessible à la place.

Les boîtes déroulantes ne posent pas de problème d'accessibilité majeur. L'amélioration de ces boîtes déroulantes est complexe, et passe par une modification du script et des modèles. Au niveau éditorial, les boîtes déroulantes en soi ne sont pas néfastes pour l'accessibilité (bien au contraire).

Ah, j'ajoute que vous avez fait plusieurs usages de <ins> dans cette page, afin de produire un soulignement. En fait, ins (insert) est utilisé avec del (deletion) dans les discussions, afin de signaler un texte qui a été rajouté après une seconde édition. Pour la mise en forme, mieux vaut utiliser <u> pour faire un soulignement. Dodoïste ^{[ dring-dring ]} 18 août 2010 à 00:10 (CEST)

Pour la mise en page, c'est certes moins joli mais je trouve cela également moins clair ; il me semble plus facile avec la première mise en page de repérer en un coup d'oeil la bonne pratique d'un coté, et l'exemple de l'autre. Je ne sais pas ce qu'en penses les autres ? Ascaron ¿! 18 août 2010 à 09:20 (CEST)

J'ai retouché les deux premiers critères de Wikipédia:Articles de qualité/Accessibilité. Mieux ? J'aimerais beaucoup avoir une mise en page jolie et claire, mais sachant que cette page sert de référence en matière d'accessibilité, il faudrait que ce soit accessible. Et nos outils sont assez limités au niveau de la mise en page. Dodoïste ^{[ dring-dring ]} 18 août 2010 à 18:40 (CEST)

Je suis d'accord avec toi sur le fait que la page doit être exemplaire. Néanmoins, je ne comprend ce qui n'est pas accessible dans la mise en page. Je viens par exemple de corriger les pseudo-titres du dernier paragraphes. Y at-il d'autres points non accessible dans ce paragraphe ? Ascaron ¿! 18 août 2010 à 19:02 (CEST)

Il me semble que ta proposition est correcte. De plus, le tableau utilisé pour la mise en forme est correct (ordre linéaire, pas de structure élaborée ou de titres qui indiqueraient à tort qu'il s'agit d'un tableau de données). Á priori, si tu préfères cette mise en page, c'est OK. Dodoïste ^{[ dring-dring ]} 18 août 2010 à 21:21 (CEST)

Si vous souhaitez conserver cette mise en page (peu agréable dans certaines résolutions ou en cas d'agrandissement de la taille de caractères), il faut remplacer le titre H5 par un titrage H4, pour respecter l'ordre hiérarchique des niveaux de titres de section.

Quelques autres corrections moins essentielles :

• le terme « directives » est habituellement réservé aux WCAG. Ici, le terme courant serait « critère » ou « bonne pratique ».
• une bonne pratique qualité (et non accessibilité cette fois-ci) invite à réserver le soulignement aux hyperliens.
• pour les contrastes, fournir le lien vers l'outil de test semble préférable (sinon, personne ne sait comment vérifier le respect de ce critère).
• peut-être faudrait-il préciser que ces critères s'appliquent avant tout au contenu propre de l'article : certains ne sont actuellement pas respectés par différents modèles très utilisés (infobox et palettes de navigation en particulier), mais difficilement améliorables. Il ne faudrait pas que cela conduise à des débats peu utiles pour ou contre leur utilisation dans les articles concernés.

Enfin, les discussions dans cette page me semblent bien confidentielles et l'adoption de ce nouveau critère d'articles de qualité un peu trop brutale : attention à ne pas faire grincer de dents . --Lgd (d) 19 août 2010 à 07:29 (CEST)

J'ai corrigé quelques titres h5 et précisé le critère. Pourrais-tu m'indiquer le lien de l'outil de test des contrastes que je ne connais pas ? Pour cette page de discussion, elle n'avait pas vraiment pour but d'y continuer la discussion ; juste de laisser un trace des discussions. Ascaron ¿! 19 août 2010 à 10:17 (CEST)

Merci pour la modification. Je n'ai pas le temps de vérifier, je suppose que tu l'as appliqué pour tous les titres concernés ?

non justement ; les titres des exemples (à droites) sont tjs en h5. En h4, ils sont trop "gros". Ascaron ¿! 19 août 2010 à 10:44 (CEST)

C'est ce que Dodoïste rappelait quelque-part dans ces discussions : mediawiki n'est pas un outil apte à permettre de faire correctement des mises en page un peu avancées, et ne permet de gérer aisément que des mises en formes plutôt « linéaires ». En outre, le problème « En h4, ils sont trop "gros" » est typiquement ce qu'on veut inciter les rédacteurs à éviter . Si on remonte à la source du problème, une mise en forme plus habituelle évacuerait cette question. Cordialement, --Lgd (d) 19 août 2010 à 11:23 (CEST)

Bon, je me résigne (mais conserve la mise en page actuelle). J'irais me flageller cet après-midi pour me faire pardonner. Ascaron ¿! 19 août 2010 à 12:49 (CEST)

Pour les contrastes, l'outil le plus utilisé est celui indiqué dans la bonne pratique (Color Contrast Analyzer, version gérée par le Paciello Group). Il faudrait documenter un peu plus son usage (indiquer que l'algorithme à utiliser est celui par défaut, c'est à dire contraste/luminosité et indiquer que seul le résultat "Texte AA" doit être pris en compte). Mais ce n'est pas si évident et je n'ai pas d'avis définitif sur le fait de retenir ou non ce critère pour l'instant. La liste que j'avais faite était une proposition ouverte, à travailler, pas une liste finalisée . Tout ce qui touche à l'usage de la couleur dans WP est délicat. A l'inverse, la question est le plus souvent réglée dans les chartes éditoriales ou les règles d'accessibilité de projets par une simple interdiction ou impossibilité pour les rédacteurs d'utiliser des propriétés de couleurs. Bref, c'est à voir. Cordialement, --Lgd (d) 19 août 2010 à 10:32 (CEST)

Je dirais même que l'usage de la couleur est très délicat. L'outil de contraste me parait bien trop compliqué ; mieux vaut éviter de l'intégrer à la liste. Ascaron ¿! 19 août 2010 à 10:44 (CEST)

Le cas des listes de définitions

Donc, le ; permet de générer les balises <dl> et <dt>, et : les balises <dd>. Et il ne doit pas y avoir de lignes vides entre les points-virgule sous peine de créer une multitude de <dl> au lieu d'une seule. Dans l'exemple Unreal (jeu vidéo)#Armes, ça passe au niveau de l'esthétique (mis à part un interligne plus resserré). Mais dans l'exemple de Red Faction#Personnages et voix, on va casser l'esthétique de départ : tous les paragraphes sont décalés à droite.

1. Est-ce qu'il existe un alias de : qui offre les mêmes avantages sans le décalage à droite, ou faut-il se résigner à s'habituer à cette nouvelle mise en page ?
2. Pour le caractère unicode, on doit utiliser avec la syntaxe [[Fichier:Arrow right.svg|16px|link=]] sans paramètre |alt= puisque c'est un symbole, c'est bien ça ? Tachymètre ^(me parler) 18 août 2010 à 22:32 (CEST)

Pour l'interligne plus resserré, c'est facilement réglable dans MediaWiki:common.css.

Pour les paragraphes décalés à droite, c'est inévitable. En toute franchise, ça me semble pas grave du tout. Pour ma part, je trouve que c'est mieux car la structure devient plus claire. C'est très variable d'une personne à l'autre, donc mieux vaut ne pas trop s'en soucier. Les Wikipédiens ont tendance à être bien trop pointilleux sur des détails de présentation. Alors que MediaWiki n'est fait que pour produire du contenu de manière assez brute, et pas du tout pour faire du haut design.

1. Il faut se résigner à à s'habituer à cette nouvelle mise en page. On peut modifier la mise en page via MediaWiki:common.css, mais cela affectera toutes les listes de définitions. Et dans de nombreux cas, le décalage à droite est désiré. Donc, pas possible. On pourrait le faire en utilisant la syntaxe HTML, et en lui assignant une classe déterminée dans MediaWiki:common.css. Mais cela rendrait la syntaxe bien plus complexe, ce qui n'est pas désirable.
2. Presque. Avec le paramètre « alt= », mais vide puisque c'est un symbole. [[Fichier:Arrow right.svg|16px|link=|alt=]] :-)

Bien à toi, Dodoïste ^{[ dring-dring ]} 18 août 2010 à 23:01 (CEST)

Okay, je viens d'appliquer les changements et je vais essayer de faire passer le message (je sens que ça va grincer un peu au début !). Dans quels cas doit-on mettre une alternative vide ou remplie ? BP#Recours aux symboles graphiques Unicode ne donne pas dans le détail et laisse perplexe : en quoi une image qui ne peut pas être lue par un lecteur d'écran serait mieux qu'un caractère qui lui non plus ne peut pas être lu (mais qui est en revanche plus facile à mettre en place) ? Et quid des navigateurs qui ne peuvent pas afficher certains caractères unicode ? Tachymètre ^(me parler) 18 août 2010 à 23:33 (CEST)

Bonjour,
Je passe rapidement corriger une erreur sur la question des symboles graphiques unicode : ils doivent être évités uniquement quand ils véhiculent une information, parce que celle-ci ne sera pas restituée ou compréhensible dans tous les contextes utilisateurs, au contraire de l'alternative textuelle de l'image. Mais lorsqu'ils sont uniquement décoratifs, il n'est pas nécessaire d'imposer leur remplacement par des images avec alt vide : il n'y a pas de perte d'information, tout au plus un rendu inattendu par exemple en cas de police non supportée. Inutile d'ajouter une contrainte superflue . Cordialement, --Lgd (d) 19 août 2010 à 07:26 (CEST)

J'ai bien compris qu'il n'y avait pas de perte d'information. Mais je pensais plutôt au confort de lecture donc tu parlais. Un utilisateur de lecteur d'écran, en tombant sur un contenu lu comme « ? » ne saura pas qu'il n'a effectivement manqué aucune information, si ? Et puis, c'est peut-être plus simple pour les éditeurs si il s'agit de remplacer toutes les icônes unicode par une image ? Je ne suis pas sûr, mais la question est digne d'intérêt à mon avis.

Tachymètre, merci pour tes corrections en ce qui concerne les listes de définition. :-) Dodoïste ^{[ dring-dring ]} 20 août 2010 à 21:14 (CEST)

Outil de vérification rapide

Bonjour,
Pour que ces bonnes pratiques ne restent pas lettre morte et pour faciliter leur mise en oeuvre, il sera nécessaire de fournir aux contributeurs un outil leur permettant de vérifier rapidement leur respect dans les articles.

Pour cela, il serait possible de remettre à jour le gadget accessibilité (MediaWiki:Gadget-Accessibility.js et MediaWiki:Gadget-Accessibility.css) qui est pour l'instant limité aux tableaux de données :

• corriger le script pour qu'il fonctionne indifféremment sous vector et sous monobook (le script se borne à appliquer une feuille de style spécifique et à ajouter dans le menu de gauche un lien permettant de l'activer et de la désactiver à volonté).
• compléter la feuille de style pour qu'elle mette en évidence les changements de langue, les citations, les entrées de listes de définition
• documenter le gadget avec notamment des captures d'écran illustrant son fonctionnement

Si quelqu'un se charge de la première étape, je pourrais m'occuper du reste (mais je manque beaucoup de temps en ce moment).

A titre indicatif, un outil similaire côté client révèle immédiatement plusieurs erreurs dans les AdQ actuellement en cours de proposition : tableaux de données et changements de langue dans Histoire des Juifs en Tunisie, tableaux et citations inappropriées dans Pégase (mythologie), tableaux et changement de langue erroné dans Antarctique, etc. Comme quoi, ce petit lot de bonnes pratiques n'est déjà pas si évident à mettre en oeuvre . Cordialement, --Lgd (d) 20 août 2010 à 06:27 (CEST)

Cela me semble être une très bonne idée mais je ne suis pas en mesure de corriger le script. Dodoïste est peut être plus compétent que moi. Ascaron ¿! 20 août 2010 à 08:11 (CEST)

Mieux vaut tenter une demande sur le Projet:Javascript, ou directment à user:Dr Brains. :-) Je me débrouille en CSS, mais il faudrait que je me penche sérieusement sur le JavaScript et j'ai pas le temps tout de suite. Dodoïste ^{[ dring-dring ]} 20 août 2010 à 21:17 (CEST)

Mise à jour : finalement, la refonte du gadget accessibilité est en cours, essentiellement orientée vers cette sélection de bonnes pratiques AdQ. Voir Refonte du gadget accessibilité sur l'Atelier. Cordialement, --Lgd (d) 12 novembre 2010 à 14:22 (CET)

Quelques remarques

Bonjour, suite aux remarques sur Discussion:Maltais/Article de qualité, j'ai lu cette page, et je vais vous faire subir mes réflexions à ce sujet.

Il y a 21 fois le mot bonne ou bonnes dans cet article. Il n'y aurait pas moyen d'utiliser des termes plus neutres tels que pratiques compatibles avec les normes d'accessibilité, ou encore pratiques facilitant l'accessibilité etc... ? Parce que pour l'instant, ça donne un peu l'impression que l'on veut convaincre à tout prix.

Beaucoup de normes auxquelles vous vous référez datent de 1999 ! Si ce n'est pas la préhistoire, pour le web c'est au moins les temps héroïques ! Ont-elles encore la moindre valeur actuellement ? Compte tenu de l'énorme accroissement de la puissance de calcul des ordinateurs depuis cette date, et de l'amélioration des logiciels en découlant, les logiciels d'accessibilité ont certainement des possibilités qui n'existaient pas à cette époque.

Vous avez choisi de rendre les articles plus accessibles, et cela, au détriment de certaines possibilités (il n'y a qu'à voir dans les discussions les difficultés que vous avez rencontrées pour faire une page conseil exemplaire au niveau accessibilité), mais il y a une option qui ne semble pas avoir été explorée : Pourquoi ne pas garder les articles tels qu'ils sont et créer des versions spéciales accessibilité, de la même façon qu'il existe des pages web pour le haut et pour le bas débit. Je ne dis pas que c'est la solution, mais un débat aurait pu avoir lieu. Par similitude, quand on crée une rampe d'accès pour les personnes à mobilité réduite devant un édifice public, on ne supprime pas pour autant les escaliers. La création du braille n'a pas fait disparaître les alphabets classiques. Dans les hôtels, il y a des chambres accessibles pour les personnes handicapées, on n'impose pas pour autant que toutes les chambres soient sur ce modèle. Dans les émissions télévisés sous-titrées ou doublées par un langage gestuel, on n'a pas supprimé la parole pour autant. À chacun de ces exemples, on double, on ne remplace pas.

Autre remarque, si on travaille à rendre accessible un article, cela permet la lecture de cet article. Si on travaille à améliorer les logiciels, cela permets une meilleure accessibilité à plein d'articles N'est-ce pas sur ce plan à que la bataille de l'accessibilité doit se jouer ? Je prends l'exemple de l'article maltais, où le mot maltais revient à tous moment, et où l'alphabet utilise des lettres propre à cette langue, pourquoi les logiciels de lecture d'écrans ne pourraient-ils pas analyser le contexte, et en déduire que les mots inconnus en français sont à lire en maltais ? Et mettre autant de règles n'est-ce pas contre-productif au final : Si il y a moins de normes, les développeurs de logiciel seront obligé de travailler à faire en sorte que leurs logiciels reconnaissent -par exemple- tous les tableaux, et non pas seulement ceux qui seront arrangé selon leur volonté. Pourquoi les guillemets ne seraient-ils pas mieux reconnus, etc... Alors que là, c'est facile pour un fabricant de logiciel de se dire : ce n'est pas à moi d'améliorer, les pages n'ont qu'à se plier à nos normes.

Et une question, les lecteurs d'écran, à ce que j'ai pu voir, demande une langue au départ, et, apparemment, s'en tiennent à cette langue pour toute la lecture. Du coup, quel est vraiment l'intérêt de renseigner la langue à chaque fois ? Existe-il beaucoup de logiciels qui peuvent tirer partie de cet ajout ?

Je pense aussi à une autre solution coûteuse en temps, mais facile à faire : Enregistrer des versions audio des articles, ce serait plus agréable à entendre que les voix de synthèse, et ne demande pas de compétences spéciales. Cela éviterait de se prendre la tête avec les questions techniques, faciliterait dans beaucoup de cas l'accessibilité, et, Wikipédia étant basée sur le bénévolat conviendrait à merveille pour ce genre d'expérimentation.

Comme c'est un sujet que je connais mal, j'ai sûrement écrit plein de bêtises, merci de m'en excuser par avance.

cordialement,--Xavier (d) 3 janvier 2011 à 11:19 (CET)

• « Bonnes pratiques » est un simple terme technique, désignant une notion précise. C'est la traduction courante de « Best practices », sans aucune honteuse intention abominablement sous-jacente d'enduire le lecteur de quoi que ce soit. Donc : non sur ce point.
• Les normes d'accessibilité Web définies dans le cas de la WAI du W3C ne datent pas de 1999, mais de 2008 et il s'agit de leur dernière version, dont le déploiement est suivi de très près via les techniques WCAG2.0 dont la dernière mise à jour date du milieu 2010. Donc : non sur ce point.
• L'outil « version accessible » (défini dans WCAG2.0) n'est pas ignoré, mais il s'agit d'un dernier recourt que ne justifient pas les difficultés rencontrées dans WP. Donc... idem.
• Maltais etc. Ce sont des questions déjà prises en compte. Pour aller rapidement : c'est un peu plus compliqué que cela.
• Renseigner la langue : l'idée est au contraire qu'une langue par défaut a été indiquée, et qu'on se contente de signaler la langue spécifique de certains contenus.
• Version audio : c'est une erreur courante. Une version audio peut être un complément de dernier niveau (accessoire) à une démarche d'accessibilité, mais il est précédé des mesures qui permettent aux logiciels d'aide technique et en particulier aux lecteurs d'écran non seulement d'écouter le contenu dans de parfaites conditions, mais aussi et surtout d'interagir avec l'interface comme dans n'importe quel navigateur. Donc : non, pas sous la forme où vous l'envisagez (cela dit, des versions audios plus ou moins médiocres de certains articles existent déjà : cela pose aussi d'autres problèmes de réalisation et d'actualisation).
• Pleins de bêtises : oui, mais vous n'êtes pas le premier et c'est tout à fait compréhensible dans un domaine technique un peu complexe. Cordialement, --Lgd (d) 3 janvier 2011 à 11:43 (CET)

Avec ces réponses péremptoires, peu explicatives et un rien condescendantes, je suis convaincu..........de ne plus m'en occuper. Cordialement,--Xavier (d) 3 janvier 2011 à 12:01 (CET)

Désolé si elles ont paru condescendantes : elles sont rapides (un expert accessibilité, comme tout autre professionnel, peut être occupé ailleurs IRL) et sont certes un peu lasses, sur des questions que l'on voit régulièrement revenir et qui relèvent avant tout de la méconnaissance d'un sujet complexe où, contrairement à ce que semble croire un certain public, les gens concernés ont déjà réfléchi pour simplifier autant que possible les choses pour les producteurs de contenus. Cordialement, --Lgd (d) 3 janvier 2011 à 12:08 (CET)

L'atelier accessibilité veut imposer des bonnes pratiques, si les mêmes questions reviennent régulièrement, peut-être qu'il y a un manque d'explication à ce sujet, ou que ces explications ne sont pas suffisamment claires ou convaincantes. Cordialement, --Xavier (d) 3 janvier 2011 à 12:18 (CET)

Les explications sont forcément améliorables : poser des questions très précises à propos de tel ou tel contenu ou bonne pratique précisément identifiés, avec exemple à l'appui, sera bienvenu pour y contribuer. Mais il y a aussi des questions précises auxquelles la réponse peut être négative, comme ci-dessus. Quand vous venez me dire par exemple que l'on s'appuie sur des normes dépassées parce que datant de 1999 alors que la WP francophone a été la première à tenir compte des normes les plus récentes de 2008 et qu'elle est la seule à suivre l'évolution des documents d'application de celle-ci, vous comprendrez que ma réponse soit assez rapide : c'est une simple perte de temps. Cordialement, --Lgd (d) 3 janvier 2011 à 12:25 (CET)

Écoutant les remarques formulées dans Discussion:Maltais/Article de qualité, je suis les conseils, et je vais là : Wikipédia:Articles de qualité/Accessibilité#Changements_de_langue, et je tombe sur : « Les Directives pour l’accessibilité du contenu web ont été publiées en 1999 par la Web Accessibility Initiative du W3C. »

Ceci peut expliquer mon erreur ! Cordialement, --Xavier (d) 3 janvier 2011 à 12:56 (CET)

On va finir par y arriver . Les questions utiles sont donc dans Discussion:Maltais/Article de qualité et concernent la mise au norme des tableaux d'une part, et d'autre part de manière totalement indépendante la question du support linguistique d'une langue dans les synthèses vocales. a partir de ce genre de chose, on peut commencer à expliquer et surtout à travailler utilement. Cordialement, --Lgd (d) 3 janvier 2011 à 13:05 (CET)

J'ai reformulé pour éviter la confusion. Ce sera déjà ça.

En ce qui concerne le ton de Lgd : il peut en effet sembler condescandant ou dénigrant, mais ce n'est pas l'intention. C'est assez inévitable lorsqu'on doit, d'une manière ou d'une autre, démontrer que « non, on ne fait pas n'importe quoi, on a une démarche bien pensée et on fait au mieux, tout en sachant que ce n'est pas parfait ». La méthode d'appplication sur laquelle on se base, les WCAG, ont été pensées par un grand nombre d'experts spécialisés dans le domaine et reconnus internationalement. Les WCAG ont été testées, évaluées, etc. On sait que ce n'est pas parfait, mais on sait aussi pouquoi c'est difficile de faire mieux.

Dans ce contexte, il est nécessaire de pouvoir dire simplement « on s'y connaît », et de le faire sentir d'une manière ou d'une autre. Je ne pense pas non plus que tu sois tout blanc dans l'histoire non plus, Xavier. Tes remarques partent d'une bonne intention, certes, mais c'est rarement suffisant. Tu sais que tu ne connais pas grand-chose au sujet, mais tu viens quand même tenter de refaire le monde, avec un espoir un peu naïf que les questions que tu soulèves n'ont pas déjà été pensées. Pour la personne qui te lit, soit tu te prends pour un génie qui a tout compris en deux secondes et qui va tout révolutionner d'un coup, soit la personne a l'impression que « ce Xavier qui débarque d'on ne sait d'où me prend pour un guignol qui ne sait pas ce qu'il fait ». La manière dont tu as exprimé tes questions ne jouent pas non plus en ta faveur. Je dis ça pour aider, hein. ;-) Dodoïste ^{[ dring-dring ]} 6 janvier 2011 à 00:11 (CET)

Longueur & poids

Le critère 5 de l’ADQ, qui est centré sur l'accessibilité, est invoqué pour ne pas labelliser un article en raison de sa taille (son poids, sa longueur). Ne faudrait-il pas insister sur ce point sur cette page ? Zythème ^{Paroles dégelées} 23 février 2021 à 10:53 (CET)