Pour chaque tableau de données complexe ayant un résumé, celui-ci est-il pertinent ?
Un utilisateur aveugle qui arrive sur un tableau de données complexe — plusieurs groupes d’en-têtes, des cellules fusionnées, des axes croisés — ne peut pas le scanner visuellement pour en saisir la structure. Il navigue cellule par cellule, sans repère global. Le résumé est ce qui lui dit, avant qu’il commence : « voici comment ce tableau est organisé, voici comment le lire ». Si ce résumé est vague ou trompeur, il empire la situation.
Le critère 5.2 ne vérifie pas si un résumé existe — c’est le rôle du critère 5.1. Il vérifie que le résumé présent est pertinent : qu’il décrit réellement la structure du tableau ou explique comment le naviguer. Un résumé qui répète le titre du tableau, ou qui se contente de dire « tableau de données statistiques », n’apporte rien.
Un résumé pertinent répond à ces questions : comment les en-têtes sont-ils organisés ? Faut-il lire en ligne ou en colonne pour trouver une valeur ? Y a-t-il des groupes de colonnes ? C’est précisément ce que décrit la technique H73 du W3C : une brève explication de la façon dont les données sont organisées ou de la façon dont le tableau se navigue.
Si le tableau possède aussi un <caption>, le résumé ne doit pas le dupliquer. Le <caption> identifie le tableau ; le résumé explique sa structure. Ce sont deux rôles distincts.
Un test pour évaluer la pertinence du résumé de tableau
Pertinence du résumé d'un tableau complexe
- Identifiez tous les tableaux de données complexes ayant un résumé (ceux repérés lors du test 5.1.1).
- Pour chaque résumé trouvé, vérifiez qu’il remplit au moins l’une de ces conditions :
- Il décrit la structure du tableau (organisation des en-têtes, groupes de lignes ou colonnes) ;
- Il explique comment naviguer dans le tableau pour trouver une valeur précise.
- Vérifiez que le résumé ne se contente pas de répéter le contenu du
<caption>. - Si tous les résumés remplissent ces conditions, le test est validé. Si un seul résumé est absent de sens ou trompeur, le test est non validé.
Exemples
❌ Non conforme : Résumé qui duplique le titre sans apporter d’information structurelle
<table summary="Horaires de bus du réseau urbain">
<caption>Horaires de bus du réseau urbain</caption>
<thead>
<tr>
<th scope="col">Ligne</th>
<th scope="col">Lundi-Vendredi</th>
<th scope="col">Samedi</th>
<th scope="col">Dimanche</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Ligne A</th>
<td>6h00 - 22h00</td>
<td>8h00 - 20h00</td>
<td>9h00 - 18h00</td>
</tr>
</tbody>
</table>Le summary répète mot pour mot le contenu du <caption>. Un lecteur d’écran lit les deux à la suite : l’utilisateur entend deux fois la même information sans rien apprendre sur la structure du tableau. La technique H73 du W3C précise explicitement que le résumé ne doit pas dupliquer le titre.
✅ Conforme : Résumé qui explique comment naviguer un tableau d’horaires complexe
<table aria-describedby="resume-horaires">
<caption>Horaires de la ligne 12 — direction Centre</caption>
<thead>
<tr>
<th scope="col">Gare du Nord</th>
<th scope="col">Place de la République</th>
<th scope="col">Hôtel de Ville</th>
<th scope="col">Châtelet</th>
</tr>
</thead>
<tbody>
<tr>
<td>07h00</td>
<td>07h08</td>
<td>07h15</td>
<td>07h22</td>
</tr>
<tr>
<td>07h30</td>
<td>07h38</td>
<td>07h45</td>
<td>07h52</td>
</tr>
</tbody>
</table>
<p id="resume-horaires">Les colonnes représentent les arrêts desservis, de gauche à droite dans l’ordre du trajet. Les lignes représentent les départs successifs. Repérez votre arrêt en tête de colonne, puis lisez vers le bas pour trouver l’heure de passage.</p>Le résumé explique la logique de lecture : comment les colonnes et les lignes sont organisées, et comment trouver l’information recherchée. L’utilisateur de lecteur d’écran comprend la structure avant de naviguer cellule par cellule. L’implémentation via aria-describedby est valide en HTML5, contrairement à l’attribut summary déclaré obsolète.
Astuces et pièges
⚠️ Résumé identique au caption
C’est l’erreur la plus fréquente en audit. Le résumé dit « Tableau des résultats financiers 2024 » pendant que le <caption> dit exactement la même chose. L’utilisateur de lecteur d’écran entend l’information deux fois, sans rien apprendre de plus. Le résumé répond à « comment est-ce structuré ? », pas à « quel est ce tableau ? ».
⚠️ Résumé vague ou générique
Un résumé comme « Ce tableau présente des données statistiques » ne vaut rien. Il n’explique ni la structure, ni comment lire les intersections, ni l’organisation des en-têtes. Pour qu’un résumé soit pertinent, il doit être spécifique : quelles dimensions croise le tableau, comment localiser une valeur précise.
⚠️ Critère non applicable si aucun résumé n’est présent
Le critère 5.2 ne s’applique que si le tableau complexe possède déjà un résumé. S’il n’en a pas, c’est le critère 5.1 qui est concerné. En audit, un tableau complexe sans résumé fait échouer 5.1 mais rend 5.2 non applicable. Ce sont deux défauts distincts qui ne se confondent pas.
💡 L’attribut summary est obsolète en HTML5 — mais son contenu reste audité
La technique H73 du W3C repose historiquement sur l’attribut summary de <table>, déclaré obsolète depuis HTML5. Les auditeurs RGAA vérifient aussi les alternatives valides : un texte adjacent lié via aria-describedby, ou un bloc <details> placé avant le tableau. Ce qui compte au regard du critère 5.2, c’est le contenu du résumé, quelle que soit la technique d’implémentation.
⚠️ Un résumé trop long peut nuire à l’expérience
Un résumé pertinent n’est pas un résumé exhaustif. S’il liste toutes les valeurs du tableau ou décrit chaque cellule, il devient un obstacle à la navigation. L’objectif est une brève explication de la structure et de la navigation — deux à quatre phrases suffisent généralement pour les tableaux les plus complexes.
Questions fréquentes
Comment évaluer si un résumé de tableau est pertinent selon le RGAA ?
Posez-vous cette question : en lisant uniquement le résumé, un utilisateur aveugle saurait-il comment chercher une valeur précise dans ce tableau ? Si la réponse est non, le résumé échoue au critère 5.2. S’il se contente de répéter le titre ou d’indiquer que le tableau contient des données, il n’est pas pertinent.
Comment différencier l'usage de aria-describedby et de summary pour résumer un tableau RGAA ?
Oui, c’est même la méthode recommandée en HTML5. Ajoutez un texte descriptif dans un élément identifié (par exemple un <p id="resume-tableau">), puis associez-le au tableau via aria-describedby="resume-tableau". La pertinence du contenu reste soumise au critère 5.2, quelle que soit la technique retenue.
Dans quels cas le critère RGAA 5.2 s'applique-t-il aux tableaux de mise en forme ?
Non. Les critères 5.1 et 5.2 ne concernent que les tableaux de données complexes. Les tableaux de mise en forme sont traités par les critères 5.7 et 5.8 du RGAA. Un tableau de mise en forme ne doit pas avoir de résumé — ce serait une fausse information restitué aux lecteurs d’écran.
Comment auditer efficacement le critère RGAA 5.2 sur la pertinence du résumé ?
Ouvrez l’inspecteur de code et cherchez les attributs summary sur les balises <table>, ainsi que les associations aria-describedby pointant vers un texte descriptif. Pour chaque résumé trouvé sur un tableau complexe, lisez son contenu et vérifiez qu’il explique la structure ou la navigation. Comparez ensuite avec le <caption> s’il existe — si les deux textes sont identiques ou quasi-identiques, le critère échoue.
Que doit contenir le résumé d'un tableau sans <caption> pour satisfaire le critère 5.2 ?
Non. Ces deux rôles restent distincts même sans <caption>. Le résumé doit se concentrer sur la structure et la navigation. L’absence de titre est un problème traité par le critère 5.4, pas par le 5.2. Mélanger les deux informations dans le résumé nuit à la clarté et rend l’audit de chaque critère plus difficile.