Un tableau de bord affiche des indicateurs financiers en colonnes : chiffre d’affaires mensuel, marge, nombre de commandes. Visuellement, aucune bordure ne sépare les cellules, la mise en page ressemble à une simple grille de chiffres alignés. En inspectant le code source, le tableau porte un attribut role="presentation", ajouté par l’intégrateur pour, selon son commentaire dans le code, « éviter que le navigateur applique son style de tableau par défaut ».
Ce qu’on voit dans le code
<table role="presentation">
<thead>
<tr>
<th>Mois</th>
<th>Chiffre d'affaires</th>
<th>Marge</th>
</tr>
</thead>
<tbody>
<tr>
<td>Janvier</td>
<td>42 300 €</td>
<td>18 %</td>
</tr>
</tbody>
</table>
La structure HTML reste correcte : un vrai <table>, des <th> pour les en-têtes, des <td> pour les données. Mais le rôle ARIA posé sur l’élément racine indique explicitement aux technologies d’assistance de ne pas traiter ce contenu comme un tableau de données, mais comme une simple mise en forme sans relation sémantique entre les cellules.
Pourquoi c’est un problème
Le rôle presentation, tel que défini par les spécifications WAI-ARIA, indique à l’arbre d’accessibilité qu’un élément et ses enfants n’ont aucune signification structurelle à restituer. Appliqué à un tableau qui contient réellement des données croisées, il supprime toutes les relations entre une cellule et son en-tête de colonne ou de ligne. Un utilisateur de lecteur d’écran qui navigue de cellule en cellule avec les raccourcis dédiés à la lecture de tableaux n’entend plus « Chiffre d’affaires, 42 300 euros », mais un texte brut, isolé, sans repère de colonne.
Ce manquement correspond directement à la thématique 5 du RGAA 4.1, consacrée aux tableaux, dont le premier critère demande que chaque tableau de mise en forme soit correctement identifié comme tel, et implique en creux qu’un tableau de données ne soit jamais dégradé en tableau de mise en forme. Un tableau qui croise des mois et des indicateurs financiers relève sans ambiguïté de la catégorie « tableau de données », pas « tableau de mise en forme ».
Ce qui a motivé cette erreur
L’intention initiale n’était pas malveillante : l’intégrateur cherchait uniquement à retirer les bordures et le style par défaut que certains navigateurs appliquent aux tableaux HTML sans feuille de style associée. Le rôle ARIA a été confondu avec un outil de style, alors qu’il n’agit que sur la couche sémantique, invisible à l’écran mais essentielle pour les technologies d’assistance.
/* Ce que l'intégrateur cherchait réellement à obtenir */
table {
border-collapse: collapse;
border: none;
}
table th,
table td {
border: none;
padding: 0.5rem 1rem;
}
Cette feuille de style suffisait entièrement à obtenir le rendu visuel souhaité, sans toucher à un seul attribut ARIA. Le rôle presentation n’avait donc aucune utilité réelle dans ce cas, il ne faisait que retirer une information dont personne n’avait mesuré la valeur.
Quoi faire à la place
- Ne jamais poser un rôle ARIA pour résoudre un problème de style : chercher d’abord la propriété CSS correspondante.
- Réserver
role="presentation"aux tableaux réellement utilisés à des fins de mise en page pure, un usage aujourd’hui déconseillé au profit de CSS Grid ou Flexbox, mais qui subsiste dans certains gabarits d’e-mail par exemple. - Vérifier, avant toute publication, la restitution du tableau avec un lecteur d’écran en mode navigation par tableau, pas seulement en lecture linéaire.
- Documenter dans le code, par un commentaire, l’intention exacte derrière tout rôle ARIA ajouté, pour éviter qu’un futur intégrateur le supprime ou le copie sans en comprendre la portée.
Un antipatron qui se propage facilement
Ce genre de correction, une fois trouvée par un développeur pressé et publiée dans un gabarit réutilisé, se copie ensuite d’un projet à l’autre par imitation du code existant, sans que personne ne revérifie sa pertinence. Le tableau de bord initial a servi de modèle à trois autres tableaux du même projet, tous corrigés en une seule passe une fois l’antipatron identifié.
Un repère simple à partager avec une équipe d’intégration : un rôle ARIA ne devrait jamais apparaître comme solution à un problème de rendu visuel. Si le style pose problème, la réponse se trouve en CSS, jamais dans l’arbre d’accessibilité.
Ce que ce cas ne couvre pas
Les tableaux réellement décoratifs, utilisés uniquement pour organiser visuellement des blocs sans aucune donnée tabulaire à restituer, constituent un cas distinct où role="presentation" reste pertinent. La distinction entre les deux usages ne se fait jamais sur l’apparence du tableau, mais sur la nature réelle du contenu qu’il transporte.
