Discussion Wikipédia:Brouillons/Infobox

Infos techniques

Si vous voulez voir à quoi ca ressemble :

• Mettre @import "http://fr.wikipedia.org/w/index.php?title=Wikipédia:Brouillons/Infobox.css&action=raw&ctype=text/css"; dans son monobook.css.
• Mettre loadJs('Wikipédia:Brouillons/Infobox.js'); dans son monobook.js
• Rafraichir son cache avec Ctrl+F5

Avis

Bon elle a une tronche plutôt sympa cette infobox . Par contre je ne saisis pas tout à fait la motivation... Le but est bien de remplacer la classe infobox existante j'imagine, je ne vois pas trop l'intérêt d'avoir deux classes... En tout cas, pour moi, une infobox doit forcément avoir par essence la classe infobox, avec éventuellement des classes supplémentaires pour modifier le comportement standard (dans l'esprit de wikitable, gauche et droite). Quelques remarques :

• Peux tu mettre ton CSS dans une page à part qu'on puisse l'importer et avoir une version a jour :

  @import "http://fr.wikipedia.org/w/index.php?title=Utilisateur:Tavernier/infobox.css&action=raw&ctype=text/css";

• Je ne vois pas trop l'intérêt du <div>. En quoi est-il nécessaire ?
• Il manque des marges à gauche (et en bas?), du coup l'infobox est un peu trop près du texte
• Je me méfierais de la pseudo classe :after qui, il me semble, ne marche pas sous IE

Voila, c'est tout pour le moment --Zelda _♪ 3 juillet 2007 à 19:34 (CEST)

• C'est fait
• Sémantiquement, une infobox est d'abord un bloc, ce n'est pas fondamentalement un tableau quoi. Et graphiquement, le caption se trouve ainsi à l'intérieur du cadre, ce qui est tout de même plus joli
• C'est corrigé
• Oui ca ne marche pas avec IE mais la difféence ne se voit presque pas. Sur les navigateurs "standart compliant" ca affiche juste une espace insécable et un ":".

Créer une classe de transition est à mon avis indispensable pour le deuxième point. On peut modifier le css ici mais si les infobox en aval n'ont pas une structure div>table ca ne fonctionnera pas du tout. Une fois que l'une ou l'autre des classes s'impose (on impose rien pour le moment vu que le look monobookien ne semble pas faire l'unanimité), on pourra éventuellement songer à une fusion pour avoir au final une seule classe. Il s'agit àmha de quelque chose de suffisamment trivial et à la fois trop technique pour qu'une PDD soit nécessaire, mais de suffisamment visible pour qu'on ne puisse l'imposer à coups de bots et de modification de la classe actuellement utilisée. Tavernier 3 juillet 2007 à 20:12 (CEST)

Bon je continue sur cette page en ce qui concerne le code histoire de pas polluer Commons.js

1. Pour le coup de la caption c'est une très bonne raison. C'est dommage de devoir faire ça pour contourner une différence de comportement entre navigateurs (due aux manques de la norme CSS2), mais bon... Le dernier truc que j'ai à opposer c'est qu'à mon avis, il faut faire simple car les utilisateurs qui font des infobox ne sont généralement pas des codeurs. J'ai peur que rajouter un div leur complique un peu la vie. Est-il à ton avis possible de laisser le truc ouvert et de permettre l'utilisation ou non du div ?
2. Pour la période transitoire, OK. C'est vrai que la présentation de l'infobox casse pas mal avec l'ancienne
3. Pour les ':', je pense sincèrement que c'est pas une bonne idée . Pour plusieurs raisons : Le type qui code son infobox sous IE ne verra pas les ':' et les rajoutera, du coup les gars sur Firefox en verront 2. J'imagine déjà les trolls... J'imagine aussi qu'il y a des cas où on a pas envie de mettre les deux points au bout, mais au milieu, genre :

superficie :
(km²)

L'exemple n'est peut-être pas très bien choisi, mais j'espère que tu comprendras ce que je veux dire . Bref, je laisserai les petits infoboxeurs se débrouiller, comme ils le font actuellement. --Zelda _♪ 5 juillet 2007 à 20:04 (CEST)

Ok pour les : , même si je trouve ca dommage qu'il faille rajouter  : dans chaque cellule (peu lisible et je leur trouve un je ne sais quoi de superflu, sans compter que Microsoft a promis d'axer ses efforts au niveau des standarts). J'en ai profité pour changer l'architecture intrinsèque. On passe d'une forme 100% tableau à une forme "boite de chocolats" où l'on met ce qu'on a envie (des images, des tableaux, etc.), ca permet d'être plus flexible aux futures évolutions des infobox à mon avis (qui sait ce que les wikipédiens voudront y mettre ? et honnetement ces lignes de tableaux avec des colspan ont de quoi rendre malade n'importe quel amoureux de code html propre ). Tavernier 5 juillet 2007 à 22:47 (CEST)

Résumé des principales modifications

1. Une infobox se place dans une section == fiche résumé == de préférence en bas des articles, juxtaposées au catégories. Cela permet de regrouper les meta-informations dans une seule zone et apporte plusieurs avantages : Les <meta name="keywords" ne sont pas remplis avec les liens des infobox, mais avec ceux des résumés introductifs. Ainsi pour Paris on n'aura plus "Paris,Juillet 2007,Modèle discussion:Portails des villes de France,Modèle discussion:Villes France 100 000 hab,-52,10 janvier,10 juillet,1108,1137,1150,1179" mais "Ville, France, Capitale, etc". De même sur lynx ou avec un lecteur d'écran ce n'est pas l'infobox qui s'affiche/est récitée en premier mais le résumé introductif.
2. Une infobox est titrée selon son thème et plusieurs thèmes peuvent être traités. Ainsi un pays peut disposer d'une infobox === pays ===, mais également d'une infobox === membre de l'ALENA ===, etc. Une pesonnalité qui a occupé plusieurs fonctions au cours de sa vie peut être doté d'une infobox === joueur de tennis ===, === chanteur ===, === homme politique ===, etc.
3. Bien que structurellement placées en bas, il est plus pratique sur les navigateurs graphiques de les avoir sous les yeux dès le début de l'article. À cette fin un javascript fait "remonter" les infobox.
4. Leur apparence dépend strictement et uniquement du skin utilisé par le lecteur. ainsi avec monobook on aura un bord gris médian et un fond gris clair, avec cologneblue on aura des bords bleus, etc.
5. Ce qui permet de distinguer les infobox sont leur titres (voir le point numéro 2), peut être une image (à discuter), voire une couleur (si on considère que choisir une couleur est neutre, compatible avec une charte graphique, etc).
6. Les éléments html utilisés ne sont plus <th>, <tr> et <td>, mais <dl>, <dt> et <dd>, les listes de définition étant à priori les éléments les plus appropriés aux infobox : [1].
7. Structurellement, une infobox n'est plus un tableau, mais une "boite de chocolats" (concrètement un <div>) où l'on y met ce qu'on veut : des images, des listes de définition, des cartes, voire des tableaux.

Voilà, toutes discussions sont ouvertes à propos de ces changements. Tavernier 13 août 2007 à 18:22 (CEST)

Ma foi, alors, allons-y courageusement (Je vais encore fâcher Tavernier, mais je n'y peux rien et je le regrette vraiment): modifier le rendu linéaire du HTML en écrivant l'infobox en fin d'article dans la source pour la déplacer ensuite (via CSS ou le DOM) en début d'article est problématique en matière d'accessibilité. Dans le détail, ce problème du rendu de l'ordre linéaire est un sujet très complexe et l'objet de discussions expertes ouvertes, notamment dans le cadre de la WAI. Mais là, il ne s'agit pas de conjectures expertes, et sous cette forme particulière, ça ne passe dans aucune méthode d'application de WCAG, au niveau minimal fixé (priorité 1). Concrètement, une fois testés, les exemples existants ne me sont pas compréhensibles dans un lecteur d'écran (Jaws) ou une loupe d'écran (ZoomText) sous diverses configurations. Alors: et si on oubliait sagement cette (fausse bonne) idée aventureuse, svp ? ;) --Lgd 13 août 2007 à 19:02 (CEST)

Je demande des sources parceque je n'ai eu aucun problème avec lynx et tout autre dispositif ne gérant pas le javascript (les infos sont présentes bien qu'en bas des articles et facilement accessibles via le sommaire). Et si des logiciels sont incapables de prendre en compte ce déplacement d'éléments, ce sont ces logiciels qui sont en défaut (sinon à quoi sert le javascript ?). Et merci d'éviter les remarques personnelles. Tavernier 13 août 2007 à 19:17 (CEST)

Bon, je tente: tu fais des tests utilisateurs, ce qui est très bien, et je salue ce souci. Mais juger et décider à partir de là est une erreur méthodologique établie de longue date en matière d'accessibilité : en raccourci, une série de tests utilisateurs ne testera que l'accessibilité pour une série très limitée de profils utilisateurs théoriques (diverses IE+JAWS n'y rentrent pas, s'il faut un exemple), alors que la prise en compte de l'accessibilité par la conception Web et ses standards vise et atteint une accessibilité beaucoup plus large, à défaut d'être réellement universelle (le handicap cognitif est le seul écueil inévitable, en fait). Pour dépasser ce stade primaire et inefficace de l'accessibilité tentée via des regards utilisateurs tronqués, des normes (WCAG) et des méthodes d'applications (accessiweb, Anysurfer, RGAA) ont été créée par des gens dont c'est le métier. L'idée générale est d'utiliser ces outils. Les outils en question disent "non" aux idées ci-dessus (qui ont, je le reconnais, toute l'apparence d'être de bonnes idées, pourtant, mais c'est un domaine technique complexe). Quelqu'un dont c'est le métier vient dire ici que c'est à éviter. Voilà, maintenant, on peut en faire plein de choses ;) --Lgd 13 août 2007 à 19:44 (CEST)

« diverses IE+JAWS n'y rentrent pas » Quels sont les points qui bloquent ces "divers" JAWS ? « Les outils en question disent "non" aux idées ci-dessus » Lesquelles ? Et en quoi ? Tavernier 13 août 2007 à 20:06 (CEST)

Je ne vois pas de « bonne idée ». Pour moi, mettre en fin des articles le contenu qui résume les points clé a toutes les apparences d'une idée insensée ! Et sortir du JavaScript/DOM pour faire de la mise en page statique est d'une inélégance informatique certaine. Marc Mongenet 19 août 2007 à 03:47 (CEST)

je vais aggraver les choses; les listes de définition sont le dernier élément à utiliser dans ce cas (inutiles car sans prises en compte pertinente par les implémentations, et au contraire nuisibles car recul de la précision du titrage qui est, lui, parfaitement implémenté) --Lgd 13 août 2007 à 19:15 (CEST)

Ce sont des éléments spécifiés par le w3c. Si certains dispositifs ne les prennent pas correctement en charge, ce sont ces dispositifs qui sont en défaut. Tavernier 13 août 2007 à 19:18 (CEST)

<censuré />Hummmpf. Laissons tomber ;) --Lgd 13 août 2007 à 19:28 (CEST)

Maintenant tu peux dire qu'un <table> farci de colspan placé en tête d'article comme c'est actuellement est la meilleure solution qui soit et préférer ne rien changer, ou alors proposer d'autres solutions pour faire avancer schmilblick. Tavernier 13 août 2007 à 19:42 (CEST)

Faire avancer les choses, oui, mais pas de manière désordonnée et sans méthode. Des choses sont en cours. Il s'agit juste d'éviter de perdre maintenant du temps avec des modifications ou adoptions de contraintes inutiles sous prétexte d'accessibilité mal gérée. --Lgd 13 août 2007 à 19:57 (CEST)

Je suppose que tu as un ordre, une méthode et des idées à nous proposer ? Tavernier 13 août 2007 à 20:08 (CEST)

En fait j'apprécierais vraiment que tu ailles directement au but en disant ce qui ne va pas ou non et pourquoi ca ne va pas. En l'état tu t'es contenté de quelques allusions aux lecteurs ou aux loupes d'écran, or j'ai fait des tests avec les deux outils et je n'ai rencontré absolument aucun problème (et le zoom fonctionne parfaitement avec les 3 navigateurs principaux, même firefox 2) donc je doute que tu aies vraiment pris le temps de regarder la structure de la page ou ce que fait le code javascript avant de critiquer. Maintenant si il existe certains lecteurs et zooms qui supportenet mal ce modèle, autant je comprend qu'il faille faire des efforts pour internet explorer vu le nombre de gens qui utilisent ce logiciel "déficient", autant que ne vois pas pourquoi on en ferait pour une minorité qui utilise des outils d'accessibilité déficients alors que des outils gratuits ne posent aucun problème (la loupe et le narrateur de windows n'en posent pas par exemple). Tavernier 14 août 2007 à 01:55 (CEST)

La plupart des infoboxes de Wikipédia me semblent constituer un usage raisonnable des tables. Ça ne me semble en tout cas pas moins raisonnable que l'usage de listes de définitions. Marc Mongenet 19 août 2007 à 04:07 (CEST)

Je trouve les remarques de Lgd argumentées plus rationnellement que les tiennes, Tavernier !

Un style basé sur des tests réalisés à l'instant T avec un ensemble logiciel E dans une configuration C par un développeur de culture K me semblent beaucoup moins faciles à maintenir que ceux basés sur des références et recommandations du WCAG, partie intégrante du W3C.

D'autre part, je ne vois pas ce que les colspan ont d'inélégant. RockyRoad 19 août 2007 à 06:55 (CEST)

Désolé mais les remarques de Lgd ne sont en rien argumentées et les votres non plus (il a juste dit que ca ne marchera pas avec les lecteurs d'écran et certains JAWS, or j'ai montré qu'il n'en est rien, et l'échange en est resté là). Enfin c'est sur que ca fait plus cool d'être d'accord avec un Lgd qu'avec un Tavernier sur ces questions, même lorsque cet LgD est bien forcé d'avouer par son silence qu'il a eu tort. Tavernier 19 août 2007 à 08:00 (CEST)

Non, c'est simplement que je ne donne pas suite à la controverse, ne souhaitant pas polémiquer inutilement. --Lgd 19 août 2007 à 08:33 (CEST)

Lorsque je réfute précisément tes arguments et te demande des explications et des critiques constructives, tu considères cela comme une controverse ? Tavernier 19 août 2007 à 08:45 (CEST)

Oui. Mon propos n'est pas d'avoir raison (controverse). Mais de ne pas poursuivre un débat où l'on chercherait à avoir raison sur tel ou tel constat limité, quand il s'agit d'un problème de méthodologie. Tel test utilisateur donnera à penser que ce que tu proposes est accessible, et tel autre donnera à penser le contraire. C'est la raison pour laquelle la base du travail en accessibilité des contenus web est d'évacuer cette méthode trompeuse des tests utilisateurs, au profit de tests déterminés par une méthodologie d'application de WCAG, où l'on commence par « oublier » volontairement les contextes utilisateurs spécifiques. Les tests utilisateurs interviennent après, en phase éventuelle d'optimisation, une fois la base WCAG A ou AA établie.

La première idée que j'ai à faire passer dans les formations à l'accessibilité des contenus qui constituent une large partie de mon métier est justement celle-là: l'accessibilité n'est pas une somme de solutions spécifiques à telle ou telle situation de handicap, ni à tel ou tel contexte utilisateur dépendant uniquement de ce qu'on sait ou peut tester (handicap précis, navigateur, support des surcouches javascript et CSS ou des plugins flash et autres, etc.)

• Parce que cette démarche est illusoire (on pourra accumuler autant de solutions qu'on voudra, on ne couvrira pas les besoins variables à l'infini ou presque)
• Parce qu'elle ne permet pas de répondre aux exigences posées en la matière (voir l'introduction de l'article accessibilité du Web pour la définition du champ de l'accessibilité). Ni de bénéficier en retour des gains induits (référençabilité, interopérabilité, maîtrise technique, etc)
• Parce qu'elle est inutilement coûteuse (rien ne nécessite pour l'accessibilité la manip DOM que tu proposes, car elle touche un niveau de priorité très bas dans la question de l'ordre linéaire des contenus)
• Parce qu'elle est trompeuse (je crois être accessible en ayant résolu le problème sur lequel je me suis fixé arbitairement, quand d'autres sont beaucoup plus obstructifs, comme la question du titrage.
• Enfin parce qu'elle repose sur des techniques non éprouvées : manipuler l'arbre du document pour supprimer et générer des noeuds est facile, mais son support par les aides techniques est encore en développement, et évaluer son impact sur l'accessibilité dans les aides techniques actuelles est extrêmement difficile.

Ce que tu proposes touche (malheureusement) à au moins deux sujets particulièrement complexes à traiter en accessibilité: la manipulation dynamique du DOM et les listes de définitions. Si le sujet t'intéresse, je peux te donner des liens vers des listes de discussions spécialisées et vers des archives de travail récent traitant de ces problèmes. Mais dans l'immédiat, le sens de mon intervention (très maladroitement formulée, je le reconnais bien volontier à la réflexion) est de dire: attention, sujet difficile, sur lequel il n'y a pas de réponses simples et immédiatement applicables. Ne pas s'aventurer et privilégier les autres solutions déjà éprouvées (structure en tableau de présentation non problématique, respect de l'ordre linéaire du HTML, pas de manip DOM).

Voilà, voilà... Sinon, si tu es disponible pour t'investir dans l'accessibilité de Wikipédia, puis-je te contacter par ailleurs ? --Lgd 19 août 2007 à 11:26 (CEST)

(message lu, j'y répondrai dans une semaine). Tavernier 22 août 2007 à 23:54 (CEST)