Utilisées correctement, les cellules fusionnées d’un tableau ne sont pas un problème en termes d’accessibilité, elles sont une solution

Diverses organisations me confient souvent qu’on leur a conseillé d’éviter de fusionner des cellules dans les tableaux au format PDF pour des raisons d’accessibilité. Ce conseil doit toutefois être nuancé. Le prendre au pied de la lettre pourrait faire plus de mal que de bien.

Un format nécessaire

Lorsqu’on atteint un tableau correctement formaté, l’utilisateur d’un lecteur d’écran va l’entendre lire les en-têtes des colonnes ou des lignes appropriées avant de passer aux données des cellules concernées. L’expression « correctement formaté », dans ce contexte, signifie que la cellule d’en-tête doit :

• être balisée en utilisant la balise <TH>
• posséder des attributs à la portée appropriée (colonnes ou lignes)
• (dans le cas de cellules fusionnées) posséder un attribut d’étendue de colonne ou de ligne approprié

Attributs d’étendue de colonne ou de ligne

Pour qu’une cellule d’en-tête fusionnée « sache » qu’elle doit s’étendre sur deux colonnes, par exemple, elle doit posséder un attribut ColSpan (étendue de colonne ou column span en anglais) avec pour valeur 2. Sans cet attribut, les mauvais en-têtes seront probablement lus avant les données des cellules, rendant ainsi le contenu inintelligible.

Les cellules d’en-tête fusionnées sous MS-Word : des corrections nécessaires

Malheureusement, MS Word ne s’en sort pas très bien avec la génération des attributs d’étendue de colonne ou de ligne. Bien que Word 2003 parvenait (presque) correctement à fusionner les cellules, ce n’est le cas d’aucune des versions suivantes. (Les déboires de MS Word dans ce domaine sont peut-être à l’origine des inquiétudes concernant les tableaux de données en PDF). Ces cellules doivent être corrigées après export du document en PDF, tout comme les en-têtes et leur portée qui nécessiteront probablement des corrections dans tous les tableaux hormis les plus simples.

Les cellules d’en-tête fusionnées sous InDesign : aucun souci

En comparaison, les cellules d’en-tête qui sont fusionnées sous InDesign ne posent absolument aucun souci. Elles héritent automatiquement des bons attributs d’étendue de colonne et de ligne lors de l’export en PDF (bien que les attributs d’en-têtes de colonnes et de portée nécessitent des modifications).

Comment résoudre le problème ?

Il existe tout un tas de guides expliquant comment baliser les tableaux sous Acrobat, je ne vais donc pas recopier ces informations ici (vous pouvez notamment consulter https://blogs.wright.edu/learn/accessibility/pdf-documents/complex-tables-in-pdf/, ou mon livre électronique qui date un peu, mais qui est toujours d’actualité : Design and build accessible PDF tables). Nous nous contenterons de dire ici qu’il s’agit d’un processus simple et évident une fois qu’on est habitué.

Pourquoi est-ce important ?

Afin de vous passer des cellules fusionnées, vous serez obligé de diviser les tableaux en de nombreuses unités plus petites. Par exemple, le tableau ci-dessous devrait être divisé en quatre tableaux distincts : un pour l’équipe rouge 2020, un pour l’équipe bleue 2020, un pour l’équipe rouge 2019 et un pour l’équipe bleue 2019.

Mais en obligeant les lecteurs à naviguer entre plusieurs tableaux, cela rend la comparaison entre les différentes catégories de données (dans notre cas les équipes et les années) plus difficile, le contenu s’en trouve moins utilisable et moins accessible.

En PDF, le tableau ci-dessus (et ceux plus complexes), s’il est formaté correctement, fonctionnera bien que ce soit avec JAWS ou NVDA. Oui, il est vrai que les tableaux complexes créés sous Word sont problématiques pris tels quels. Mais, les corriger sous Acrobat est rapide et facile (une fois familier avec le processus), il n’y a donc aucune raison de se priver des cellules fusionnées quand vous en avez besoin. Au contraire, il est probable que vous rendiez votre contenu moins accessible en vous en passant.