Pour résumer rapidement le débat technique, la condition majeure de l'accessibilité d'un tableau de données est qu'une aide technique dispose des indications nécessaires pour relier correctement chaque cellule de contenu du tableau à la ou les cellules d'en-têtes qui en donnent le sens (Non, les aides techniques ne peuvent pas déduire toute seule cette information du tableau..) Pour cela, HTML prévoie deux dispositifs apparemment concurrents :

  • un sympathique, qui se résume à indiquer sur la cellule d'en-tête qu'elle s'applique à la colonne ou à la ligne dans laquelle elle figure, via un attribut SCOPE.
  • un beaucoup moins sympathique qui contraint à donner un identifiant à chaque en-tête et à lui attacher une à une chaque cellule de contenu via un attribut HEADERS reprenant le ou les identifiants concernés.

Le premier est sympathique parce qu'il se prête très bien à la génération automatique d'en-têtes accessibles dans l'interface d'un CMS. Le second est une abomination exigeant pratiquement, sauf si vous limitez votre rédacteur à quelques modèles de tableaux pré-définis, à coder la chose à la mimine ou à passer par une interface qui va lui valoir une jolie prise de tête.

Le souci historique est que le second (HEADERS) a été plus vite implémentée par les aides techniques que le premier : à plus ou moins juste titre, une vieille méfiance subsiste dans le milieu de l'accessibilité Web envers le merveilleux attribut SCOPE : on lit un peu partout que son usage doit être réservé aux tableaux simples, et proscrit pour les tableaux complexes.

Là où cela devient amusant, c'est quand arrive la seconde partie du marronnier : l'attribut SUMMARY. Ce "résumé de tableau" qui n'est pas du tout destiné à résumer quoi que ce soit est censé être utilisé pour expliquer à l'utilisateur comment sont organisées les données du tableau. C'est un mode d'emploi pour la lecture, si vous voulez. Une sorte de notice de montage pour étagères IKEA, en pire parce qu'on fait ça en aveugle : il faut monter l'étagère dans un lecteur d'écran.

Immanquablement, aucun rédacteur n'ayant la moindre idée d'à quoi sert ce SUMMARY, l'erreur commune est de le prendre pour un résumé de l'information apportée par le tableau, ce qui conduit en général à en faire un doublon parfaitement inutile du titre CAPTION dudit tableau (vous suivez, dans le fond ?). Passons et supposons que nous avons des "powered-rédacteurs de contenu".

Ce SUMMARY n'est nécessaire, nous dit WCAG2.0, que pour les tableaux complexes... Expliquer à l'utilisateur qu'un tableau à simple entrée présente des colonnes toutes simples avec une ligne d'en-têtes unique n'est en effet pas d'une utilité foudroyante, à part faire bavarder Jaws. Voire susciter l'angoisse de l'utilisateur de Jaws qui se demande si cette indication est bien claire et si le tableau ne serait pas, en réalité, plus complexe que ça puisqu'il a nécessité un SUMMARY. Vu que de toutes façons 98% du Web n'est pas accessible y compris quand il prétend l'être, on apprend vite à se méfier...

Mais personnellement, j'ai aussi un doute sur la pertinence de choses théoriquement superbes comme "ce tableau vous présente une distribution des colonnes en 5 niveaux d'en-têtes et de sous-en-têtes en fonction de... Les en-têtes de ligne intermédiaires séparent les données qui..." Dans deux secondes, on va me parler d'intégrales quand je cherche bêtement à comprendre la taxe carbone...

A ce stade, une question s'impose : au fait, à partir de quel stade un tableau est-il complexe ? Disons juste, dans le cadre de ce billet, qu'il serait temps de mettre en oeuvre une suite de tests vérifiant enfin les implémentations de SCOPE et de HEADERS pour trancher cela du côté technique. J'ai ma petite idée sur la réponse, qui n'est pas étrangère à ce qui suit. Je vais donc froidement affirmer que ce n'est pas la question majeure, en fait.

En effet, dans tous les cas, un tableau de données n'est rien d'autre qu'une représentation spatiale d'un ensemble d'informations complexes qui seraient difficilement compréhensibles sans ce détour graphique. Bref, c'est une image, une métaphore. La consultation d'un tableau sans ce support visuel est déjà d'une certaine façon un non-sens. Les attributs d'accessibilité SCOPE ET HEADERS tentent d'y remédier en fournissant aux lecteurs d'écran de quoi permettre à l'utilisateur une pénible élucidation de la chose, tout comme le tableau affiché tente déjà de fournir à l'internaute en général l'occasion de saisir de quoi on cause. Dés lors, envisager de publier des tableaux complexes est de la pure perversité, quelque-soit le public pris en compte.

Sans compter que, dès que le support visuel se dégrade parce que le premier coup de scroll vertical a fait disparaître les en-têtes cabalistiques... (Nous aurons en effet la décence ne pas parler du support de THEAD, par exemple).

Bref :

  • les tableaux complexes exigeraient des HEADERS que les rédacteurs sont bien en peine d'utiliser ? Bwa, ils n'ont qu'à ne pas faire de tableaux complexes.
  • les tableaux complexes exigent la rédaction d'une description de la structure du tableau dans un SUMMARY dont l'intelligibilité réelle va être plus que discutable ? Bwa, ne pas faire de tableaux complexes.
  • les tableaux complexes ont d'autant moins de chance d'être compréhensibles quoi qu'il en soit sans le support de la métaphore visuelle ? Bwa...

Non ? Mais dites : vous croyez vraiment que le visiteur lambda les comprend, ces merveilleux tableaux complexes créés par des polytechniciens dans un contexte souvent administratifs, très en amont de la publication Web, hum ? Comme souvent, le problème est en fait entre la chaise et le clavier.

Marcel, si tu te pose une question d'accessibilité : fais péter ton tableau complexe. Tu vas voir: tu peux en faire plusieurs tableaux simples. Et tu vas faire beaucoup plus d'heureux que tu ne le penses.