AccueilTableaux de données accessibles

Guide pratique · Tableaux de données

Tableaux de données accessibles : guides des tailles et comparatifs

Mis à jour le 15 juin 2026 Lecture : 10 min Référence : EAA · WCAG 2.1 AA

En bref — un tableau lisible aussi sans les yeux

Les boutiques regorgent de tableaux : guide des tailles, comparatif de produits, fiche technique, grille tarifaire. Pour une personne voyante, l'œil relie une cellule à sa colonne et à sa ligne. Un lecteur d'écran, lui, lit les cellules une à une : sans en-têtes balisés, « 42 » ne veut plus rien dire. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA) exige que la structure du tableau existe dans le code. Les points clés :

  • Un vrai <table> pour les données, jamais un tableau pour la mise en page (critère 1.3.1) ;
  • Des en-têtes balisés <th> avec scope (colonne et ligne) (critère 1.3.1) ;
  • Une légende <caption> qui annonce ce que contient le tableau (critère 1.3.1) ;
  • Les tableaux complexes simplifiés ou cellules associées à leurs en-têtes (critère 1.3.1) ;
  • Pas d'information par la couleur seule (ex. « dispo » en vert) (critère 1.4.1) ;
  • Un tableau lisible sur mobile, au zoom 200 %, sans piège de défilement (critères 1.4.10 et 1.4.4).

Bonne nouvelle : tout se joue dans le balisage HTML. Aucun changement de design n'est nécessaire pour rendre un tableau accessible.

Le guide des tailles est l'un des contenus les plus consultés d'une boutique de mode — et l'un des plus souvent inaccessibles, parce qu'il est codé comme une image ou un empilement de <div>. Or un tableau de données n'est accessible que si le code dit clairement « ceci est un en-tête de colonne, ceci une cellule ». Voici les six règles WCAG que l'EAA impose pour vos tableaux, illustrées sur des cas e-commerce concrets, et comment les vérifier.

Pourquoi un tableau a besoin de structure

Quand vous lisez un guide des tailles, votre œil fait un aller-retour permanent : il croise la ligne « Tour de poitrine » et la colonne « M » pour trouver la bonne valeur. Un lecteur d'écran ne voit pas cette grille : il parcourt les cellules dans l'ordre du code. Si les en-têtes sont correctement balisés, il peut annoncer « Tour de poitrine, taille M, 96 cm » — la donnée reprend son sens. Sinon, l'utilisateur entend une suite de nombres détachés de tout contexte.

L'EAA ne crée pas de règle « tableau » distincte : la référence reste l'EN 301 549, fondée sur les WCAG 2.1 niveau AA, applicables au commerce électronique depuis le 28 juin 2025. Les tableaux relèvent surtout du critère 1.3.1 (Information et relations) : les relations visuelles (cette valeur appartient à cette ligne et à cette colonne) doivent aussi être présentes dans le code.

Les 6 règles d'un tableau accessible

1 Un vrai tableau de données

Utilisez <table> pour des données, pas pour la mise en page

Un tableau de données (guide des tailles, comparatif, fiche technique) doit être un vrai <table> HTML. À l'inverse, n'utilisez jamais un <table> pour positionner des éléments à l'écran (mettre deux blocs côte à côte) : la mise en page se fait en CSS. Un tableau de mise en page brouille la lecture pour les technologies d'assistance, qui annoncent « tableau de 3 colonnes » là où il n'y a aucune donnée tabulaire. Inversement, une grille de tailles bricolée en <div> n'a aucune relation ligne/colonne exploitable.

Conforme — le guide des tailles est un <table> ; la mise en page de la fiche produit se fait en CSS (flexbox/grid).
À éviter — le guide des tailles en image (.jpg) ou en <div> empilés ; un <table> utilisé juste pour aligner deux colonnes de texte.
WCAG 1.3.1 (A)
2 Des en-têtes balisés avec scope

<th> pour les en-têtes, scope pour les relier

Les cellules d'en-tête (la première ligne, souvent la première colonne) doivent être des <th>, pas des <td> mis en gras. Ajoutez l'attribut scope pour préciser ce que l'en-tête couvre : scope="col" pour un en-tête de colonne, scope="row" pour un en-tête de ligne. C'est ce qui permet au lecteur d'écran d'annoncer, sur chaque cellule, à quelle ligne et à quelle colonne elle appartient. Sur un guide des tailles, la ligne d'en-tête (S, M, L, XL) est en scope="col", et la première colonne (Tour de poitrine, Tour de taille…) en scope="row".

Conforme<th scope="col">M</th> en haut, <th scope="row">Tour de taille</th> en début de ligne.
À éviter — toutes les cellules en <td>, les en-têtes seulement reconnaissables au gras ; des <th> sans scope sur un tableau à double entrée.
WCAG 1.3.1 (A)
3 Une légende qui annonce le tableau

<caption> : le titre intégré du tableau

La balise <caption>, placée juste après l'ouverture du <table>, donne un titre au tableau, lu par le lecteur d'écran avant son contenu. Elle aide à comprendre de quoi parle le tableau et à le repérer quand une page en contient plusieurs (par exemple un guide des tailles « Femme » et un « Homme »). C'est une seule ligne de code, souvent oubliée, qui change beaucoup l'expérience.

Conforme<caption>Guide des tailles femme (en cm)</caption> en tête de tableau.
À éviter — deux tableaux de tailles sur la page, sans <caption>, impossibles à distinguer à l'oreille.
WCAG 1.3.1 (A)
4 Simplifiez les tableaux complexes

Cellules fusionnées et doubles en-têtes : à manier avec soin

Plus un tableau est complexe (cellules fusionnées, en-têtes sur deux niveaux, sous-totaux), plus il est difficile à rendre accessible et à lire pour tout le monde. La meilleure stratégie est souvent de le simplifier : découper un grand tableau en plusieurs tableaux simples, chacun avec sa <caption>. Quand un tableau complexe est inévitable, associez explicitement chaque cellule à ses en-têtes (attributs headers et id) afin que la correspondance reste sans ambiguïté.

Conforme — un comparatif découpé en tableaux simples par catégorie ; sinon, cellules reliées via headers/id.
À éviter — un comparatif géant à cellules fusionnées et en-têtes sur deux étages, sans aucune association explicite.
WCAG 1.3.1 (A)
5 Jamais l'information par la couleur seule

Une pastille verte ne suffit pas

Dans un comparatif, on indique souvent une caractéristique présente par une coche verte et absente par une croix rouge — ou une disponibilité par une simple pastille de couleur. Une personne daltonienne ou aveugle ne perçoit pas cette différence. Le critère 1.4.1 (Utilisation de la couleur) impose un second indice : un texte (« Oui »/« Non », « En stock »/« Épuisé »), un symbole accompagné de son texte alternatif, ou une étiquette. La couleur peut rester, mais en complément, jamais comme seul porteur de l'information.

Conforme — la cellule contient « Inclus » / « Non inclus » (la couleur reste un renfort).
À éviter — une cellule vide colorée en vert ou en rouge, ou une coche/croix sans texte ni alternative.
WCAG 1.4.1 (A)
6 Lisible sur mobile et au zoom

Le tableau reste utilisable sur petit écran

Un tableau large doit rester consultable sur mobile et lorsqu'on agrandit la page. Le critère 1.4.10 (Redistribution) demande que le contenu reste utilisable à fort zoom sans défilement horizontal sur l'ensemble de la page ; un tableau peut, lui, défiler horizontalement dans son propre conteneur (placez-le dans un bloc à overflow-x:auto, focusable au clavier). Le critère 1.4.4 (Redimensionnement du texte) impose que le texte reste lisible jusqu'à 200 % sans perte d'information ni texte tronqué. Évitez de transformer le tableau en image « parce que ça tient mieux » : l'image n'est ni zoomable ni lisible par lecteur d'écran.

Conforme — sur mobile, le tableau défile horizontalement dans son cadre, atteignable au clavier ; le texte reste net à 200 %.
À éviter — le guide des tailles en image fixe ; un tableau qui force toute la page à défiler ou tronque les colonnes au zoom.
WCAG 1.4.10 (AA) · 1.4.4 (AA)

Récapitulatif des critères pour les tableaux

Critères des WCAG 2.1 exigés par l'EAA via l'EN 301 549 (niveaux A et AA), appliqués aux tableaux de données.
Point à vérifierNiveauCritère WCAG
Vrai tableau de données, pas de mise en pageA1.3.1
En-têtes <th> + scope (colonne et ligne)A1.3.1
Légende <caption> descriptiveA1.3.1
Tableaux complexes : cellules associées aux en-têtesA1.3.1
Information jamais portée par la couleur seuleA1.4.1
Redistribution / lisibilité au zoom et sur mobileAA1.4.10
Redimensionnement du texte jusqu'à 200 %AA1.4.4
Le piège le plus fréquent en e-commerce : publier le guide des tailles ou la fiche technique sous forme d'image. C'est rapide à intégrer, mais l'image n'a ni en-têtes, ni texte sélectionnable, ni zoom net : elle est invisible pour un lecteur d'écran et illisible pour une personne malvoyante. Un vrai <table> HTML demande à peine plus de travail et règle le problème pour de bon — tout en étant indexable par Google.
Un overlay « accessibilité » ne transforme pas une image de guide des tailles en tableau de données, n'ajoute pas les <th>/scope manquants et ne relie pas les cellules à leurs en-têtes : ce sont des choix de balisage dans votre code. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.

Comment vérifier vos tableaux

Plusieurs vérifications rapides, du plus automatique au plus parlant :

  • Un scan automatique détecte bien plusieurs problèmes : tableau sans en-tête, <th> sans scope, <caption> manquante, tableau de mise en page suspect. C'est un bon premier filtre.
  • L'inspecteur du navigateur permet de vérifier que vos en-têtes sont bien des <th> (et non des <td> en gras) et que scope est présent.
  • Un lecteur d'écran (NVDA, VoiceOver) propose un mode « tableau » pour naviguer cellule par cellule : si chaque cellule est annoncée avec sa ligne et sa colonne, la structure est bonne. C'est le test le plus représentatif.

→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi la structure des titres, autre pilier du critère 1.3.1.

Vérifiez l'accessibilité de votre boutique gratuitement

DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (tableaux sans en-têtes, structure, contraste, formulaires…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.

Rapport WCAG par e-mail sous 24 h ouvrées.

C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.

Questions fréquentes

Mon guide des tailles est une image. Est-ce un problème ?

Oui, c'est l'un des cas les plus fréquents. Une image de guide des tailles n'a ni en-têtes, ni texte sélectionnable, et devient floue au zoom : elle est inaccessible aux lecteurs d'écran et difficile pour les personnes malvoyantes. La bonne pratique est de recréer le guide en vrai tableau HTML (<table> avec <th>, scope et <caption>). Bonus : un tableau HTML est aussi indexable par Google, contrairement à une image.

Quelle différence entre <th> et <td> ?

<td> est une cellule de données ordinaire ; <th> est une cellule d'en-tête (titre de colonne ou de ligne). Mettre un <td> en gras le fait ressembler à un en-tête sans en avoir le rôle pour un lecteur d'écran. Utilisez <th> pour vos en-têtes, avec scope="col" ou scope="row" selon qu'il s'agit d'un titre de colonne ou de ligne.

Faut-il vraiment une <caption> sur chaque tableau ?

Ce n'est pas strictement obligatoire si le tableau est déjà clairement introduit par un titre voisin, mais c'est fortement recommandé : la <caption> est lue avec le tableau et lève l'ambiguïté quand une page en contient plusieurs (tailles femme / homme, comparatif par gamme). C'est une seule ligne de code pour un gain net de clarté.

Comment gérer un grand tableau sur mobile ?

Placez le tableau dans un conteneur à défilement horizontal (overflow-x:auto) qui soit atteignable au clavier, plutôt que de réduire le texte au point qu'il devienne illisible. L'essentiel : le texte doit rester net à 200 % de zoom (critère 1.4.4) et le tableau ne doit pas forcer toute la page à défiler horizontalement (critère 1.4.10). Découper un très grand tableau en plusieurs tableaux plus petits est souvent la meilleure solution.

Un scan automatique détecte-t-il les problèmes de tableaux ?

En partie. Un scan repère bien l'absence d'en-têtes, les <th> sans scope, l'absence de <caption> ou un tableau de mise en page suspect. Il ne peut pas juger si la légende est pertinente ni si l'association des cellules complexes est correcte : une vérification au lecteur d'écran reste utile sur les tableaux à double entrée. Le scan est néanmoins un excellent premier filtre.