En version mobile, un tableau devient « carte ». Avec une structure accessible, il guide tout type de lecteur dès l’entrée et renforce la qualité d’un article WordPress. Cet article vous guide dans la création d’un tableau responsive et accessible.
Points clés de l’article
- Un tableau de données sert à comparer vite, sans perte de contexte.
- Une structure HTML claire aide les lecteurs d’écran et la lecture mobile.
- Le mode “cartes” évite le scroll horizontal sur téléphone.
- Un conteneur dédié et un préfixe de classes limitent les conflits de thème.
- Un test clavier et un contrôle des en-têtes suffisent pour une première validation.
Pourquoi soigner les tableaux sur WordPress ?
Un tableau contient souvent des informations clés. Il résume, compare et segmente ces informations. Sur mobile, un tableau trop large devient pénible à lire. Un lecteur doit alors zoomer, glisser et revenir en arrière. Un tableau pensé pour le mobile garde le rythme de lecture et rassure.
Comprendre ce qu’un tableau rend possible…
Un tableau de données relie des lignes et des colonnes : il permet de repérer rapidement une tendance ou une différence. Il évite aussi les répétitions dans le texte. Quand la structure est propre, une technologie d’assistance retrouve les relations entre cellules. Cette logique reste valable même si le rendu change avec le CSS.
Quand un tableau devient une bonne idée…
Un tableau fonctionne très bien pour des tarifs, des options, des étapes, des comparatifs. Il aide aussi pour des calendriers ou des listes de critères. Il devient moins utile quand il sert juste à aligner du contenu. Dans ce cas, il est préférable d’utiliser une liste ou des cartes simples. Une seule règle pratique existe : un tableau sert à des données, pas au design.
Prompt efficace
Pour un tableau responsive et accessible WordPress en HTML personnalisé avec CSS personnalisé. Dans ce prompt, la colonne principale est « Critère » et en version mobile, son arrière-plan est rouge.
À partir du contenu proposé. [sujet : …]. Générer un tableau explicite, lisible et robuste face aux styles du thème.
1) Objectif et sortie attendue
✅ Produire un bloc complet prêt à coller dans WordPress.
✅ Inclure le HTML et le CSS.
✅ Encapsuler le tableau dans un conteneur dédié .cmp-table-wrap.2) Mise en page desktop
✅ Largeur du tableau. width: 100% dans son conteneur.
✅ Largeur du conteneur : .cmp-table-wrap centré avec max-width: 75% sur desktop.
✅ Sur tablette et mobile : .cmp-table-wrap passe à max-width: 100%.3) Responsive mobile en cartes
✅ Breakpoint mobile : @media (max-width: 720px).
✅ Transformation en cartes sur mobile :
– thead masqué visuellement mais conservé pour l’accessibilité.
– tr, td affichés en bloc pour éviter tout ascenseur horizontal.
✅ Bandeau mobile :
– Un bandeau rouge #fe5353 apparaît en haut de chaque carte.
– Contenu du bandeau. valeur de la colonne 1. Critère.
✅ Sur mobile, fond transparent sur les cartes et sur les cellules. Aucun fond blanc ajouté.4) Robustesse face au thème WordPress
✅ Préfixe de classe unique obligatoire :
– Toutes les règles CSS commencent par .cmp-table-wrap .cmp-table.
✅ Utiliser !important uniquement dans la règle mobile, uniquement là où nécessaire pour imposer l’affichage en cartes.
✅ CSS dédié. Ne pas modifier les styles des autres tableaux du site.5) Accessibilité. Obligatoire
✅ Ajouter un caption clair.
✅ Ajouter scope= »col » pour les en-têtes de colonnes.
✅ Ajouter scope= »row » pour la première cellule de chaque ligne (critère).
✅ Ajouter une description via aria-describedby vers un texte d’aide .sr-only.
✅ .sr-only pour un texte invisible visuellement mais lisible par lecteurs d’écran.
✅ Focus visible si éléments interactifs existent :
– Ajouter des styles :focus-visible pour a, button, et [tabindex= »0″].
– S’il n’y a aucun élément interactif, ne pas inventer de boutons ou liens.6) Design et contraintes d’affichage
✅ Bordures visibles en dark et light :
– border-color: rgba(128,128,128,0.5).
✅ Textes lisibles :
– font-size: 16.4px.
✅ Aucun ascenseur horizontal :
– Ne pas utiliser overflow-x:auto.
– Gérer les mots longs :
. overflow-wrap: anywhere;
. word-break: normal;
✅ Optionnel si utile. Utiliser un colgroup pour maîtriser les largeurs de colonnes en desktop.7) Rédaction
✅ Français simple et très compréhensible.
✅ Aucun “je” ni “vous”.
✅ Formulations courtes pour limiter les césures en série.
✅ Améliorer le contenu proposé si nécessaire :
– Orthographe.
– Formulations simples et prudentes.
– Pertinence des mots-clés.
✅ Compléter les colonnes sans contenu proposé, pour atteindre exactement le nombre de colonnes demandé, avec prudence.8) Colonnes à produire
✅ Colonne 1. Critère
✅ Colonne 2. […]
✅ Colonne 3. […]
✅ Colonne 4. […]
✅ Colonne 5. […]
✅ Colonne 6. […]9) Contenu proposé
[… HTML ou données sources à transformer …]
Les bases d’un tableau accessible
Un tableau accessible commence par une structure HTML sémantique. Un lecteur d’écran doit annoncer le sujet du tableau et ses en-têtes. La règle la plus rentable consiste à déclarer clairement les en-têtes de colonnes et de lignes. On utilise alors <th> avec scope="col" et scope="row". Cette approche réduit les ambiguïtés, même dans des tableaux simples.
Donner un nom au tableau avec caption
Le titre du tableau se place dans <caption>. Il donne le thème en une phrase courte. Il sert aussi de repère pour la navigation assistée. Une description courte peut compléter via aria-describedby et un texte .sr-only. Cette aide explique la lecture attendue ou le contenu des colonnes.
Garder un focus visible en cas d’interactions
Un tableau peut contenir des liens ou des boutons. Dans ce cas, le focus clavier doit rester visible. La pseudo-classe :focus-visible fournit un retour clair sans bruit visuel au clic souris. Un simple contour suffit pour respecter l’usage clavier. Cela améliore la navigation pour beaucoup de profils. Cela reste utile même hors lecteur d’écran.
Rendre le tableau responsive, sans scroll horizontal
La lecture mobile demande une autre forme. Le format “cartes” fonctionne bien car il garde une ligne par bloc. Chaque carte affiche un bandeau de titre, puis des champs étiquetés. Le tableau garde son <thead> pour l’accessibilité, mais on le masque visuellement. On ajoute des libellés via data-label pour rappeler le nom de chaque colonne. Cette méthode évite l’ascenseur horizontal et accélère la lecture.
Éviter les débordements liés aux mots longs
Les débordements viennent souvent d’URLs, de codes ou de mots très longs. Une règle simple limite le risque. overflow-wrap: anywhere; autorise la coupure quand il le faut. word-break: normal; garde une lecture naturelle. Un table-layout: fixed; et un colgroup stabilisent aussi les colonnes sur desktop. L’ensemble rend le tableau plus prévisible sur WordPress.
Sécuriser le rendu dans WordPress
WordPress et les thèmes ajoutent des styles par défaut. Un tableau peut donc changer d’apparence après une mise à jour de thème. Un conteneur dédié comme .cmp-table-wrap isole le style. Un préfixe de classe sur toutes les règles limite les collisions. Sur mobile, !important peut servir uniquement pour imposer l’affichage en cartes. Cette approche protège le rendu sans casser les autres tableaux.
Bon réflexe côté éditeur
Le bloc Tableau existe dans l’éditeur. Il reste pratique pour des tableaux simples. Pour un rendu “cartes” et une accessibilité maîtrisée, un bloc HTML personnalisé apporte plus de contrôle. Un contrôle rapide consiste à vérifier la présence d’un en-tête de tableau, puis une légende claire. Des plugins peuvent aussi signaler des erreurs d’accessibilité pendant l’édition.
Méthode rapide pour tester un tableau responsive et accessible
- Commencer par un test mobile : vérifier l’absence de scroll horizontal et la lisibilité des cartes.
- Passer ensuite au clavier avec Tab : le focus doit rester visible sur chaque élément interactif.
- Enfin, vérifier les en-têtes : chaque ligne doit annoncer son critère et chaque colonne son nom.
- Autre méthode : tester le HTML du tableau avec l’outil d’Accessibilité Web.
Sources de confiance
- W3C WA : Tables Tutorial
- W3C : WCAG 2.2
- W3C WAI : Understanding SC 1.3.1
- MDN : Table accessibility
- GOV.UK : Content design. Tables
FAQ TABLEAU RESPONSIVE ET ACCESSIBLE
Questions fréquemment posées
Le scroll horizontal cache souvent des colonnes. Il casse la comparaison et fatigue la lecture. Les cartes gardent une ligne complète sous les yeux. Elles ajoutent aussi les libellés de colonnes, donc le sens reste clair. Pour un tableau de contenu éditorial, les cartes sont presque toujours préférables.
Oui, car il clarifie la structure. Un lecteur d’écran lit alors la bonne ligne et la bonne colonne. La lecture devient aussi plus stable en cas de zoom ou de style utilisateur. WCAG insiste sur les relations et la structure, pas seulement sur le visuel. Ce travail aide donc bien plus que l’accessibilité seule.
<caption> donne un nom au tableau. <th> déclare les en-têtes. scope="col" et scope="row" relient les cellules aux bons en-têtes. Une description via aria-describedby aide pour les tableaux denses. Ces éléments couvrent l’essentiel des cas courants.
Un wrapper dédié isole le style. Un préfixe de classes limite les collisions. Sur mobile, !important peut forcer l’affichage en cartes si le thème écrase les règles. Il vaut mieux limiter !important à cette zone. Cette stratégie reste propre et maintenable.
Tester sur mobile d’abord, puis réduire la fenêtre du navigateur. Vérifier l’absence de scroll horizontal. Tester ensuite la navigation au clavier et le focus visible. Contrôler enfin les en-têtes et la présence d’un caption. Ces tests couvrent les erreurs les plus fréquentes.
