Si des tableaux sont utilisés uniquement pour aligner du contenu en colonnes visuellement — et non pour présenter des données — ce contenu reste-t-il compréhensible quand on le lit dans l'ordre ?
Critère officiel 5.3 — Pour chaque tableau de mise en forme, le contenu linéarisé reste-t-il compréhensible ?
Pourquoi c'est important
Un logiciel de lecture lit le contenu d'un tableau cellule par cellule, de gauche à droite et de haut en bas. Si un tableau est utilisé pour mettre deux blocs de texte côte à côte, le logiciel les entremêle : une phrase de la colonne gauche, une phrase de la colonne droite, alternativement — rendant le tout incompréhensible.
Exemples concrets
Ce qui est conforme
La page « Nos engagements » présente deux colonnes de texte réalisées en CSS, pas en tableau. Le logiciel de lecture lit intégralement la première colonne, puis la seconde — dans un ordre logique.
Ce qui pose problème
La même page utilise un tableau HTML à deux colonnes pour la mise en page. Le logiciel de lecture entremêle les deux textes : « Nous nous engageons… / La commune de… / à réduire… / Châtillon-sur-Seine… » — une alternance incompréhensible.
Comment agir
Les tableaux de mise en page sont une mauvaise pratique à éviter : demandez à votre prestataire de remplacer tout tableau utilisé uniquement pour l'organisation visuelle par une mise en page CSS. Pour les nouveaux contenus, n'utilisez jamais un bloc Tableau WordPress pour aligner du texte — réservez-le aux données.
Règles clés
- Un tableau de mise en forme ne doit pas avoir de <th>, <caption> ni d'attribut summary.
- Ajouter role="presentation" ou role="none" sur le <table> pour indiquer aux AT que ce n'est pas un tableau de données.
- L'ordre de lecture cellule par cellule (linéarisation) doit être cohérent et compréhensible.
- Préférer CSS flexbox ou grid pour toute nouvelle mise en page — éviter les tableaux de mise en forme.
- Pour les emails HTML, les tableaux de mise en forme restent souvent inévitables — s'assurer que l'ordre DOM est logique.
Erreurs fréquentes
- Tableau de mise en forme avec <th> — annoncé comme en-tête de données alors que ce n'est pas un tableau de données
- Tableau de mise en forme avec un attribut summary — réservé aux tableaux de données complexes
- Tableau de mise en forme dont l'ordre de lecture linéarisé (cellule par cellule) ne produit pas de sens
- Utilisation d'un tableau pour disposer un formulaire — les labels se retrouvent dissociés des champs à la linéarisation
Exemples de code
tableau de mise en forme avec th
✗ Non conforme<table>
<tr>
<th>Notre mission</th>
<th>Nos valeurs</th>
</tr>
<tr>
<td>Texte sur la mission...</td>
<td>Texte sur les valeurs...</td>
</tr>
</table>Les <th> signalent des en-têtes de tableau de données. Le lecteur d'écran annoncera "Notre mission, en-tête de colonne" — sémantique incorrecte pour une mise en page.
tableau de mise en forme correct
✓ Conforme<table role="presentation">
<tr>
<td>
<h2>Notre mission</h2>
<p>Texte sur la mission...</p>
</td>
<td>
<h2>Nos valeurs</h2>
<p>Texte sur les valeurs...</p>
</td>
</tr>
</table>role="presentation" neutralise la sémantique de tableau. Les <td> contiennent des titres <h2> qui structurent le contenu. La linéarisation lit : titre mission → texte mission → titre valeurs → texte valeurs — ordre logique.
alternative CSS recommandée
✓ Conforme<div style="display: flex; gap: 2rem;">
<div>
<h2>Notre mission</h2>
<p>Texte sur la mission...</p>
</div>
<div>
<h2>Nos valeurs</h2>
<p>Texte sur les valeurs...</p>
</div>
</div>Flexbox pour la mise en page visuelle. Le DOM reste linéaire et sémantique. Pas de tableau, pas de risque de confusion avec des données tabulaires.
Référence WCAG : 1.3.2, 4.1.2