Wikipédia:Atelier accessibilité/Taxobox et infobox

Un contenu riche et complexe

Exemple de problème d'accessibilité possible au niveau de la géolocalisation : le point apparait hors de la carte.

Les taxobox et de nombreuses infobox ont un contenu varié :

• titres (les info et taxo box sont sectionnées, chaque section ayant une sorte de titre, le tout ayant un titre généralement redondant avec celui de l'article)
• images (généralement, l'image réputée symbolique de l'article, mais aussi des images annexes - blasons, signature d'un auteur, etc. - et beaucoup de cartes)
• diagrammes en HTML qui sont une question à eux seuls (cas-type : les diagrammes de lignes ferroviaires)
• tableaux de données simples, et parfois des tableaux plus complexes (à double entrées, ou imbriqués)
• listes, parfois imbriquées (arborescences)
• interfaces dynamiques javascript (cartes de géolocalisation, boîtes déroulantes)
• éléments de navigation (liens suivant et précédent dans des séries linéaires, liens vers des catégories)
• texte : citations, exemples de contenu dans une langue sujet de l'article, etc.
• appels de notes (<ref>)
• etc.

On constate également une tendance régulière à développer de plus en plus cette complexité de contenu (éléments javascripts, images multiples, infobox combinées).

Voir le rendu des articles sur un site destiné aux mobiles comme http://fr.m.wikipedia.org peut déjà aider à faire prendre conscience de certains problèmes.

Exemple d'infobox peu accessibles et leur rendu pour les mobiles (à actualiser):

Rendu d'une infobox sur un club de foot avec écran désactivant certaines fonctions.

• Cartes géographiques : Paris > Paris(point de géolocalisation hors de la carte),
• Mise en page des données : Conca > Conca (mise en page instable)
• images composées : Crawley Town Football Club > Crawley Town Football Club (problème d'images)
• problèmes de contrastes : Place René-Cassin, Associação Desportiva Atlética do Paraná ou BB 66600
• largeur excessive : Nohic > Nohic (problème de coordonnées géographiques)
• etc.

Actuellement, un code impropre et simplificateur

Cette richesse de contenu correspond en fait à ce qu'il faudrait considérer comme une « mini-page », en termes de structure. Or, le code actuel n'est pas écrit en fonction de la nature de l'information et des besoins de structure, mais de manière uniquement visuelle : faire en sorte que cela s'affiche comme le tableau qu'on souhaite voir apparaître. Il ne comporte pas les structures pertinentes (thumb pour les images), mêle tableaux de données et de présentation, éléments de contenu et de navigation, etc.

Dès lors, ce code donne un rendu apparemment satisfaisant dans la combinaison navigateur graphique/souris/écran/pas de handicap technique ou personnel, mais se révèle impropre dans d'autres conditions d'accès ou de réutilisation du contenu, faute de comporter les éléments appropriés.

Le résultat: un contenu non accessible

Exemple d'utilisation de la couleur et des styles CSS (en haut) non accessibles (en bas, rendu sans CSS)

Ce contenu est donc difficile à consulter et à comprendre dans de nombreux cas, et pose des difficultés de nature très diverse :

• la structure mêlant tableau de présentation et de données est difficile à comprendre en particulier dans un lecteur d'écran, ou dans tout autre contexte de navigation où elle sera linéarisée (certains mobiles).
• la multiplication des liens dans les infobox « repousse » d'autant l'accès aux liens du contenu de l'article pour les utilisateurs naviguant au clavier
• le contenu de l'infobox « repousse » d'autant l'affichage du contenu propre de l'article pour les utilisateurs de mobiles.
• les images ne bénéficient pas du mécanisme des thumb qui bénéficie aux utilisateurs en bas-débit et à ceux ayant une résolution réduite
• certaines infobox comportent un pseudo-contenu CSS qui sera dénué de sens sur un mobile, dans un lecteur d'écran, un navigateur texte.
• le souhait de varier les couleurs en répliquant directement la palette du projet dans l'infobox conduit parfois à des contrastes très insuffisants (voir ici).
• problèmes d'impression, de réutilisation du contenu sur d'autres medias
• etc.

Que faire ?

• Privilégier le texte de l'article qui ne doit pas être vidé au profit de l'infobox.
• Mieux gérer le contenu, évaluer sérieusement la plue-value des différents éléments et les possibilités de les intégrer de manière plus pertinente comme blocs contextuels dans le reste de l'article (les cartes dans la section géographie, etc.) Version simple: plutôt qu'une infobox/taxobox usine à gaz, privilégier des blocs spécifiques présents dans les sections appropriées de l'article, et réserver la taxo/infobox à un nombre aussi réduit que possible de données clées. (exemple d'amélioration concertée)
• Corriger le code actuel, pour un rendu affiché similaire, de manière à avoir recours aux tableaux seulement pour les contenus qui justifient des tableaux de données et utiliser une structure plus appropriée pour les autres contenus (version simple: une infobox/taxobox est un div composé de plusieurs sous-éléments, qui peuvent être des tableaux, ou des listes, ou des thumbs, etc.).
• Utiliser le principe du méta-modèle et de ses sous-modèles (voir les palettes de navigation et leur succès), aussi appelé « briques » etc. pour que le modèle utilisé par les contributeurs reste simple, en décalant le code compliqué dans les sous-modèles qu'il utilise.

Quelques questions pour une éventuelle démarche sur les infobox

Quelques questions notées rapidement pour des contributeurs s'intéressant à des décisions à propos de la maudite infobox:

• Un problème de définition de son rôle :
  • l'infobox résume-t-elle des informations contextualisées (et référencées) dans le corps de l'article ou bien y a-t-il des informations qu'elle est seule à délivrer indépendamment de celui-ci, sous une forme rapide ?
  • les champs d'une infobox doivent-ils correspondre à des notions triviales ou immédiatement vérifiables via des bases de données externes sur le sujet de l'article, ou peut-on inventer des champs et des classifications ?
  • quel est le degré de complexité admissible des champs d'une infobox ? Doit-elle à tout prix tout résumer de l'essentiel ? Un tableau de données à double entrée peu lisible dans ce cadre réduit de présentation y est-il pertinent ?
  • dans quelle mesure le contenu de l'infobox doit-il systématiquement comporter une image symbolique du sujet ou identifiable à celui-ci ? Doit-il comporter d'autres images qui peuvent par ailleurs être présentées de manière contextualisée dans le corps de l'article ?
  • l'infobox est-elle considérée comme pertinente nécessairement pour tous les articles ?
• Des questions de contenu :
  • quel contenu en matière d'images ?
  • des éléments de navigation y sont-ils pertinents (navigation dans une série d'article) ?
  • des liens vers des catégories y sont-ils pertinents ?
  • des interfaces javascript dynamiques y sont-ils pertinents ?
  • des contenus nécessitant d'être associés à une référence faute d'être référencés ailleurs dans l'article y sont-ils pertinents ?
  • l'infobox ne gagnerait-elle pas à rester un simple tableau annexe résumant quelques données qui peuvent l'être, sous la forme champ/valeur ?
• Des questions techniques :
  • dans quelle mesure la liberté de présentation (couleurs, détails de tailles de police, de graisse, de séparateurs et de titres) doit être conciliée avec les autres considérations ?
  • un méta-modèle unique peut-il être envisagé s'il facilite la déclinaison d'une structure et d'un code commun par les contributeurs, sans qu'ils aient à se préoccuper des aspects techniques ou visuels, et avec ce qui serait demandé de liberté en matière de contenu et de rendu ?
  • quel niveau d'interopérabilité et d'accessibilité viser ? Les infobox doivent-elles prendre en compte le rendu sur un mobile ? Dans des aides techniques ? En connexion bas-débit ? Doivent-elles prendre en compte les fonctionnalités d'impression PDF ?