Marcel, fais péter ton tableau !

Par Laurent Denis, le 25 octobre 2009, dans .

L’un des plus beaux marronniers actuels de l’accessibilité des contenus est la gestion des attributs d’accessibilité des tableaux de données : quand peut-on se contenter des solutions simples à mettre en œuvre ? Quand faut-il en passer par un code abominable dans lequel s’empêtrent rédacteurs et développeurs d’outils de saisie ?

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.

7 commentaire(s)

  1. Par Denis Boudreau, le 26 octobre 2009 à 6 h 54 min :

    C’est une belle occasion de se pencher sur l’attribut @summary. Comment écrire un bon résumé pour un tableau complexe de données (parce qu’on a pas toujours le choix de le peter, notre gros tableau)?

    Le “summary” veut compenser le manque de vision globale de l’utilisateur non-voyant en donnant une brève description de l’organisation du tableau. il peut être aussi long que nécessaire bien que c’est toujours souhaitable de ne pas abuser.

    Un bon sommaire doit décrire les grandes catégories d’information présentées par colonne et par ligne et signaler les irrégularités éventuelles correspondant aux cellules fusionnées. L’effet recherché ici est une vue d’ensemble, c’est pourquoi il n’est pas utile de reprendre dans le sommaire tous les titres de colonne et de ligne, mais plutôt d’en décrire les grandes catégories.

    Les associations explicites avec @scope, ou @headers et @id feront le reste du travail.

    Note : Il ne faut pas inscrire de summary vide (summary=””) pour les tableaux de présentation, parce que c’est un des critères utilisés par les lecteurs d’écran pour distinguer entre les tableaux de présentation et les tableaux de données. La présence de et attribut ferait passer la synthèse vocale en mode lecture de tableau complexe, ce qui rendrait plus intolérable encore l’expérience de navigation dans un site non accessible.

  2. Par Stéphane Deschamps, le 26 octobre 2009 à 10 h 34 min :

    Des petites balises <code> aideraient grandement à la lecture… 😉

    Pour le reste, lecture de fond à venir, je reviendrai, hahaha. (insérer ici rire à la Dark Vador)

  3. Par Laurent Denis, le 26 octobre 2009 à 17 h 47 min :

    Juste pour signaler, en pleine action, que s’il est déjà pervers de chercher une métaphore textuelle à la métaphore graphique que sont les tableaux, ça l’est encore plus de chercher des tests unitaires de validation d’accessibilité de tableaux quand ils sont rédigés sous forme purement textuelle…

  4. Par Florent V., le 27 octobre 2009 à 19 h 37 min :

    «parce qu’on a pas toujours le choix de le peter, notre gros tableau»

    Oué, OK. Solutions qui me viennent comme ça:

    1. Imposer le choix de le péter, le tableau. Pour cela, commencer par péter les genoux des gens qui veulent conserver l’intégrité de leur tableau complexe, et puis ça ira mieux. OK, mauvais conseil.

    2. Faire une alternative accessible au tableau complexe, sous la forme d’un contenu compréhensible. Ha ha.

    3. Ne rien faire, ou juste le minimum. Ne pas passer une journée à tenter d’accessibiliser deux-trois tableaux hallucinants, pour un gain trop faible. De toute façon le travail fait serait cassé par un contributeur non-expert à la moindre modification. Signaler si besoin les contenus excessivement complexes qui posent des problèmes d’ergonomie et d’accessibilité. Et voilà.

    Troller sur le blog Temesis: check.

  5. Par Laurent Denis, le 28 octobre 2009 à 7 h 01 min :

    @Denis Boudreau :
    Bien-sûr, l’approche directe décrite ici n’est pas toujours praticable. Elle l’est cependant, d’expérience, dans laplus grande partie des cas. Elle a surtout le mérite d’isoler et de limiter étroitement les cas où un contenu produit en amont, indépendamment du Web, doit y être reproduit sans changement. Au moins, Marcel aura une méthode de travail réaliste et utile dans la plupart des cas qu’il a à traiter, et ne se plaindra que dans des cas où il y est contraint.

    A propos du summary vide : oui, en théorie, mais hélas pas tout à fait dans les implémentations actuelles.

    Certes, en principe, l’analogie ALT / SUMMARY qui a suggéré cette idée du summary vide des tableaux de mise en forme est une confusion et il ne faudrait pas utiliser de SUMMARY vide.

    Mais dans la réalité, les lecteurs d’écran visent avant tout le Web non accessible. Dès lors, l’heuristique “tableau de données ou tableau de mise en forme ?” n’est hélas pas simple. Elle ne tient pas forcément compte des informations standards. Par exemple, des tableaux de données irréprochables ne sont pas reconnus comme tels par Jaws, en raison de la présence d’une trop grande quantité de texte, ce qui suggère un tableau de mise en forme abusivement doté d’éléments ou d’attributs propres à un tableau de données. Ou encore : la présence d’un SUMMARY vide ou l’absence de SUMMARY ne sont pas décisifs. J’ai sous l’oreille en ce moment un superbe tableau de mise en forme, dénué de SUMMARY et de toute autre élément propre aux tableaux de données… immédiatement signalé par Jaws comme étant un tableau de données. Et inversement, un autre tableau de mise en forme avec SUMMARY renseigné… que Jaws ne me signale pas comme tableau de données.

    Le principe de non confusion entre tableau de données et de présentation via l’absence des attributs et éléments CAPTION, TH, SCOPE, etc. est pertinent et nécessaire, mais il ne contraint pas les aides techniques, qui sont loin d’être des agents utilisateurs conformes 😉

  6. Par rico, le 31 octobre 2009 à 23 h 00 min :

    Si j’ai bien compris vos points de vue, confronté à ma vision des choses (mais il est bien tard…) :

    – soit on met en place un tableau “simple” et l’on peut aisément le rendre accessible ou compréhensible par le plus grand nombre,

    – soit on met en place un tableau “complexe” et on est certain que personne n’y comprendra rien avec ou sans réflexion sur l’accessibilité de ce dernier.

    C’est plutôt sympa comme conclusion d’autant que de mon point de vue un tableau peut toujours, même quand il est simple, poser des problèmes d’accessibilité du point de vue cognitif… Alors qu’un tableau simple peut simplement être converti en une liste (avec quelques répétitions je le concède). Et vous pouvez regarder autour de vous notamment chez les enfants, tout le monde fait des listes (merci père noël) et tout le monde sait lire des listes (mêmes complexes et longues), mais ce n’est pas le cas des tableaux…

    Alors pourquoi ne pas abolir les tableaux complexes qui ne servent au final qu’à leur créateur à s’autosatisfaire de leurs capacités, et remplacer les tableaux “simples” par de “simples” listes ?

  7. Par truffo, le 1 novembre 2009 à 18 h 12 min :

    Je suis plutôt en accord avec le point de vue de rico.

    Il y a toujours le choix entre une liste et un tableau simple, le tout est une question de présentation. Certain seront plus compréhensible sous formes de liste d’autres sous formes de tableau, le choix est totalement transparent niveau accessibilité (si c’est bien codé)

Les commentaires sont fermés.