Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?
Un lecteur d’écran lit un tableau cellule par cellule, de gauche à droite et de haut en bas. Si vous avez utilisé un <table> pour mettre en page visuellement des blocs de contenu, cette lecture linéaire peut produire un nonsens complet : des phrases coupées, des informations dans le mauvais ordre, du contenu qui n’a plus aucun sens hors du contexte visuel.
La règle est double. D’abord, l’ordre des cellules doit rester logique quand on les lit à la suite. Si supprimer le CSS rend la page incompréhensible, le tableau de mise en forme échoue le critère. Ensuite, l’élément <table> doit porter role="presentation" pour signaler aux technologies d’assistance que ce tableau est purement graphique et non sémantique.
Sans role="presentation", un lecteur d’écran comme NVDA ou JAWS annonce « tableau de 3 colonnes et 4 lignes », puis propose des raccourcis de navigation de tableau. L’utilisateur cherche des en-têtes, tente de comprendre les relations entre colonnes — pour découvrir qu’il s’agissait d’un simple bloc de mise en page. C’est une perte de temps et une source de confusion réelle.
Un test pour s'assurer que les tableaux de mise en forme sont correctement linéarisés
Tableau de mise en forme avec role="presentation" et ordre cohérent
- Repérez tous les éléments
<table>utilisés pour la mise en page (pas pour des données tabulaires). - Pour chacun, vérifiez que
role="presentation"est présent sur la balise<table>. - Lisez le contenu des cellules dans l’ordre du DOM (première ligne de gauche à droite, puis deuxième ligne, etc.). Ce contenu linéarisé doit rester compréhensible et cohérent.
- Si les deux conditions sont remplies pour tous les tableaux de mise en forme, le test est validé. Si l’une manque, le test échoue.
Exemples
❌ Non conforme : Tableau de mise en forme sans role="presentation" et ordre incohérent
<table>
<tr>
<td><img src="logo.gif" alt="XYZ alpinisme"></td>
<td rowspan="2" valign="bottom">au sommet !</td>
</tr>
<tr>
<td>XYZ vous emmène</td>
</tr>
</table>En lecture linéaire, un lecteur d’écran lit : « XYZ alpinisme », puis « au sommet ! », puis « XYZ vous emmène ». La phrase « XYZ vous emmène au sommet » est fragmentée et incompréhensible dans cet ordre. De plus, l’absence de role="presentation" pousse le lecteur d’écran à annoncer un tableau à 2 colonnes et 2 lignes, et à proposer des raccourcis de navigation inutiles.
✅ Conforme : Tableau de mise en forme avec role="presentation" et ordre de lecture cohérent
<table role="presentation">
<tr>
<td>
<img src="logo.gif" alt="XYZ alpinisme">
<p>XYZ vous emmène au sommet !</p>
</td>
<td>
<p>Matériel professionnel depuis 1987.</p>
</td>
</tr>
</table>Avec role="presentation", le lecteur d’écran ignore la structure du tableau et lit directement le contenu. L’ordre DOM correspond à l’ordre de lecture attendu. Si l’on supprime le CSS et qu’on lit les cellules à la suite, la phrase reste logique. L’utilisateur ne perd aucune information.
Astuces et pièges
⚠️ role="presentation" ne neutralise pas un ordre de lecture incohérent
Une erreur fréquente en audit : ajouter role="presentation" et considérer le critère comme validé. Ce n’est qu’une des deux conditions. Si les cellules sont lues dans le mauvais ordre (à cause de rowspan, colspan ou d’une structure visuellement maligne), le contenu reste incompréhensible pour un utilisateur de lecteur d’écran, quel que soit le rôle ARIA.
💡 Test de linéarisation : lisez le source dans l’ordre
Pour tester rapidement, ouvrez l’inspecteur et lisez le texte contenu dans chaque <td> dans l’ordre d’apparition dans le DOM. Si cette lecture produit un texte cohérent, le critère est en bonne voie. Vous pouvez aussi désactiver CSS avec les DevTools et lire la page résultante.
⚠️ Les tableaux de mise en forme imbriqués transmettent role="presentation"
Selon la spécification ARIA, role="presentation" sur un <table> supprime la sémantique de l’élément mais pas de ses descendants. Un <table> imbriqué à l’intérieur doit lui aussi porter role="presentation" explicitement s’il est utilisé pour la mise en page.
⚠️ Les tableaux de mise en forme ne doivent pas contenir d’éléments sémantiques de tableau
Un tableau déclaré role="presentation" ne doit pas contenir <th>, <caption>, scope ou headers. Si ces éléments sont présents, le tableau est traité comme un tableau de données — et les règles du critère 5.1 s’appliquent à la place. En pratique, un <th> oublié dans un layout table est un bug fréquent qui contredit la déclaration role="presentation".
⚠️ role="none" est équivalent mais moins lisible
Le RGAA 4.1.2 spécifie role="presentation". La valeur role="none" est son alias dans WAI-ARIA 1.1 et produit le même comportement. Cependant, pour la lisibilité du code et la conformité explicite au critère lors d’un audit, préférez role="presentation".
Questions fréquentes
Comment distinguer un tableau de mise en forme d'un tableau de données ?
Un tableau de données présente des relations entre des informations selon deux axes (lignes et colonnes ont une signification). Un tableau de mise en forme n’est utilisé que pour positionner visuellement des blocs de contenu. Le test pratique : si vous pouvez remplacer le <table> par des <div> et des flex/grid en CSS sans perdre d’information, c’est un tableau de mise en forme. S’il contient des <th> ou une <caption>, c’est un tableau de données.
Comment vérifier la conformité RGAA des tableaux générés par un CMS ?
Oui. L’origine du code (CMS, éditeur WYSIWYG, composant tiers) ne change rien à l’obligation de conformité. Un <table> injecté par un éditeur de contenu sans role="presentation" fait échouer le critère 5.3 exactement comme un tableau écrit à la main. Signalez le problème à l’éditeur de l’outil ou corrigez la sortie HTML.
Quand utiliser role="presentation" sur un tableau de mise en forme pour respecter le RGAA ?
Non. L’ordre visuel et l’ordre DOM peuvent diverger, notamment avec rowspan et colspan. Le RGAA 4.1.2 (critère 5.3.1) exige que l’ordre d’accès aux cellules dans le DOM soit cohérent avec le contenu, pas seulement que le rendu visuel soit correct. C’est pourquoi la technique F49 des WCAG cible spécifiquement les layouts avec rowspan qui cassent la séquence logique.
Pourquoi les attributs summary et caption sont-ils interdits dans un tableau de mise en forme RGAA ?
Non, c’est l’inverse : un tableau de mise en forme ne doit pas avoir de <caption> ni de summary. Ces éléments signalent que le tableau contient des données structurées. Leur présence sur un tableau de mise en forme est une erreur qui relève du critère 5.4 (tableau de mise en forme ne doit pas avoir d’éléments ou attributs propres aux tableaux de données).
Comment tester RGAA 5.3 sur les tableaux de mise en forme avec un lecteur d'écran ?
Avec NVDA, naviguez jusqu’au tableau : s’il annonce « tableau » avec un nombre de colonnes et de lignes, role="presentation" est absent ou ignoré. Avec le mode navigation (touche T pour passer de tableau en tableau), un tableau de mise en forme correctement configuré ne doit pas apparaître dans la liste. Vous pouvez aussi utiliser les DevTools Accessibilité de Chrome : l’arbre d’accessibilité du <table> doit afficher role: none.