ACCESSIBILITÉ ≠ OVERLAY · 36
Tableaux accessibles : les données ont besoin de contexte, pas d’un overlay
📅 9 novembre 2026 · ⏱ 8 min de lecture
Un tableau peut sembler bien organisé tout en restant incompréhensible lorsqu’on l’écoute ou qu’on utilise un agrandissement. L’accessibilité exige de préserver les liens entre chaque donnée, sa ligne et sa colonne.
01. Un chiffre isolé ne suffit pas
Imaginez consulter les horaires d’un service et entendre seulement «09:00, 10:00, 11:00, 12:00». Sans savoir à quel jour ou à quel service correspond chaque heure, impossible de prendre une décision utile. L’obstacle apparaît lorsque le contexte dépend uniquement d’un regard vers le haut ou vers la gauche. L’information est visible, mais les logiciels ne disposent pas des relations nécessaires.
Le problème se retrouve dans un tableau de tarifs. Un montant peut désigner un abonnement mensuel, un prix annuel ou un supplément. Si la personne doit mémoriser la position de chaque colonne, la consultation devient un exercice de reconstruction. Le but est de pouvoir répondre à une question précise de manière autonome.
02. Déterminez si les données nécessitent un tableau
Un tableau est pertinent lorsque la comparaison entre lignes et colonnes apporte du sens : horaires, tarifs, caractéristiques ou résultats. Pour une suite d’instructions ou une fiche comportant peu d’informations, une liste ou des paragraphes peuvent être plus clairs. Le choix doit découler des données plutôt que de l’apparence quadrillée proposée par l’éditeur.
Évitez également les tableaux pour disposer deux blocs indépendants côte à côte. La présentation relève du CSS et des composants de mise en page. Mélanger présentation et données introduit une structure susceptible d’être annoncée sans aider la compréhension. Avant de développer, définissez la comparaison attendue et supprimez les colonnes inutiles à cette tâche.
03. Des en-têtes présents dans le code
Mettre la première ligne en gras ou sur fond bleu ne transforme pas ses cellules en en-têtes. Les cellules qui identifient des lignes ou des colonnes doivent utiliser th ; les données ordinaires utilisent td. Dans un tableau simple, scope="col" et scope="row" peuvent préciser la direction des associations pertinentes.
Par exemple, «Service», «Lundi» et «Mardi» identifient les colonnes. «Consultations» et «Assistance» peuvent identifier les lignes. Pour comprendre une heure, il faut connaître le service et le jour. N’ajoutez pas systématiquement ARIA pour répéter la sémantique native. Examinez d’abord le HTML du composant, puis la manière dont le navigateur et le lecteur d’écran restituent les relations entre les cellules.
| Service | Lundi | Mardi |
|---|---|---|
| Consultations | 09:00 | 10:00 |
| Assistance | 11:00 | 12:00 |
04. Un titre utile et une orientation concise
Un caption permet d’identifier le tableau : «Horaires d’accueil» est plus informatif que «Tableau 1». Le titre doit permettre de le distinguer des autres sans lire tout le texte précédent. Lorsque la période, la devise ou l’unité sont essentielles, indiquez-les clairement dans le tableau ou dans une explication associée.
Un tableau complexe peut aussi nécessiter une courte description de son organisation. Précisez, par exemple, que chaque groupe de colonnes correspond à un trimestre. Cette orientation ne remplace pas les en-têtes des cellules. Évitez les descriptions interminables répétant toutes les valeurs : il s’agit de faciliter la consultation, pas d’imposer deux lectures successives avant d’atteindre l’information recherchée.
05. Simplifiez avant de fusionner les cellules
Les cellules fusionnées et les en-têtes à plusieurs niveaux compliquent l’interprétation et la maintenance. Avant de les employer, envisagez plusieurs tableaux plus petits dotés de titres précis. Séparer deux périodes peut améliorer davantage la compréhension que multiplier les attributs dans une immense grille.
Lorsque la complexité est nécessaire, représentez explicitement les groupes et les associations. Selon la structure, scope="colgroup", scope="rowgroup" ou les relations entre id et headers peuvent convenir. Ce ne sont pas des recettes interchangeables applicables à tout tableau. Vérifiez les relations réelles et testez les cellules centrales, les limites et les différents groupes. Une première ligne correctement annoncée ne valide pas tout le tableau.
06. Le mobile doit préserver les relations
Réduire la taille du texte jusqu’à faire tenir tout le tableau sur un téléphone rend l’information difficile à lire. Masquer des colonnes sans proposer un autre accès à leurs données ne résout pas davantage le problème. L’adaptation doit conserver les informations nécessaires pour comparer et décider, y compris avec un agrandissement.
Une zone défilant horizontalement peut être raisonnable pour des données nécessitant deux dimensions. Elle doit être utilisable au clavier lorsque nécessaire et indiquer clairement la présence de contenu supplémentaire. Si les lignes deviennent des cartes, préservez les libellés et leur sens dans le DOM. Vérifiez que la transformation visuelle ne supprime pas la sémantique et n’oblige pas à deviner les associations.
07. Couleurs, abréviations et cellules vides
Une cellule verte ne signifie pas à elle seule «disponible», pas plus qu’une cellule rouge n’explique forcément «complet». Ajoutez du texte ou un autre équivalent compréhensible et vérifiez le contraste des textes, commandes et indicateurs pertinents. Des couleurs alternées peuvent aider à suivre les lignes, sans devenir l’unique moyen de comprendre leurs relations.
Expliquez les abréviations peu évidentes et utilisez des unités cohérentes. Distinguez zéro, information inconnue et service indisponible : ces situations sont différentes. Une cellule vide peut être ambiguë aussi bien visuellement qu’à l’écoute. Une décision éditoriale comme écrire «Aucune donnée» évite de prendre un silence pour une valeur ou pour un dysfonctionnement du lecteur d’écran.
08. Rendez le tri et les filtres utilisables
Si un en-tête permet de trier, proposez cette action par une commande utilisable au clavier et dotée d’un nom clair. Communiquez l’état du tri de manière programmatique lorsque nécessaire ; aria-sort peut l’indiquer sur l’en-tête concerné. Un petit triangle ne suffit pas pour expliquer quelle colonne détermine l’ordre actuel.
Après un filtrage, conservez un parcours de focus prévisible et annoncez les résultats pertinents sans multiplier les interruptions. Testez aussi l’absence de résultats et la réinitialisation du filtre. Ne transformez pas un tableau informatif en grille interactive avec une navigation particulière sans nécessité réelle. Tout comportement supplémentaire doit être conçu et testé, plutôt que supposé accessible parce qu’il paraît plus sophistiqué.
09. Testez des tâches plutôt que des balises
Choisissez une question vérifiable : «À quelle heure l’assistance est-elle disponible le mardi ?». Répondez visuellement, puis avec un lecteur d’écran et ses commandes de navigation dans les tableaux. Le test utile ne consiste pas à entendre qu’un tableau existe, mais à trouver la bonne donnée avec ses en-têtes sans perdre le contexte.
Répétez la tâche avec agrandissement et fenêtre étroite. Utilisez le clavier pour les boutons, filtres et zones défilantes qui le nécessitent. Toutes les cellules d’un tableau statique n’ont pas à devenir des arrêts de tabulation. Documentez le navigateur, la technologie d’assistance, le résultat observé et la réponse correcte qu’une personne devrait pouvoir obtenir.
10. Le rôle des outils et des WCAG
Un outil automatique peut signaler certains défauts de structure, mais ne décide pas si un en-tête décrit correctement ses données ou si plusieurs tableaux faciliteraient la comparaison. Il ne valide pas non plus tous les états d’un filtre. Combinez les alertes avec une inspection du code, une relecture éditoriale et des tâches manuelles.
Dans les WCAG 2.2, le critère 1.3.1, Information et relations, est particulièrement pertinent pour la structure tabulaire. Selon le composant, clavier, contraste, redistribution et messages d’état peuvent également intervenir. L’exception de redistribution pour un contenu nécessitant deux dimensions ne dispense pas toute la page. Évaluez chaque exigence applicable sans présenter une recette technique comme une garantie de conformité globale.
11. Corrigez WordPress et Divi à la source
Examinez le HTML produit par le module ou l’extension de tableaux après l’enregistrement. Un éditeur peut mettre la première ligne en évidence tout en ne publiant que des cellules td. Un collage depuis un tableur peut également ajouter des styles et des fusions inutiles. La vérification doit porter sur le résultat réel, pas uniquement sur le constructeur.
Si plusieurs articles partagent le défaut, corrigez le composant ou le modèle commun et documentez une règle éditoriale. Un overlay ne peut pas déduire de façon fiable si une valeur est un prix, un délai ou un pourcentage, ni déterminer la comparaison attendue. Les réglages d’apparence peuvent compléter le travail ; les relations doivent exister dans le contenu original.
12. Une information encore compréhensible demain
Avant publication, contrôlez titre, unités, en-têtes, associations et comportement sur petit écran. Intégrez une tâche précise à la vérification éditoriale et répétez-la après une modification des données ou de l’extension. Un tableau correct peut se dégrader après l’ajout d’une colonne, une fusion ou le remplacement de libellés par des icônes.
Associez si possible des personnes utilisant des technologies d’assistance et prenez en compte leurs difficultés concrètes. Le meilleur tableau n’accumule pas les attributs : il permet de consulter et de comparer sans reconstruire mentalement sa structure. L’accessibilité se démontre lorsque la personne trouve la bonne donnée, comprend sa signification et peut s’en servir pour prendre sa propre décision.