Outils de visualisation de données accessibles en 2026 :
une stack opérationnelle
Cinq bibliothèques dominent la visualisation de données moderne, mais seules certaines d’entre elles traitent le lecteur d’écran comme un consommateur de première classe. Voici la fiche d’évaluation d’un ingénieur en exercice, rédigée pour les équipes qui mettent des graphiques en production en 2026.
1. Les cinq axes qui déterminent si un graphique est accessible
L’expression « graphique accessible » dissimule un empilement d’exigences discrètes. Un graphique à barres peut être rendu en SVG avec un contraste des couleurs parfait et rester hors d’atteinte pour un utilisateur au clavier. Il peut être navigable au clavier et n’annoncer rien d’utile à un lecteur d’écran. Il peut annoncer les valeurs proprement et quand même laisser sur le côté un utilisateur malvoyant dès la première infobulle. Pour comparer équitablement les bibliothèques, nous évaluons chacune sur cinq axes indépendants qui correspondent directement à l’expérience d’un utilisateur de technologie d’assistance devant une visualisation.
Ces cinq axes ne sont pas une liste de préférences personnelles. Ils sont la traduction pratique des critères de succès WCAG 2.2 (1.4.11 contraste des éléments non textuels, 2.1.1 clavier, 4.1.2 nom, rôle, valeur), des recommandations ARIA Authoring Practices sur les graphiques et diagrammes, ainsi que du projet de note « Data Visualization Accessibility » du groupe de travail W3C Research Questions Task Force qui circule depuis 2023. Toutes les bibliothèques de graphiques produisent du SVG ; toutes affichent une légende d’une forme ou d’une autre ; toutes ont une opinion sur les couleurs. Ce qui les différencie, ce sont les paramètres par défaut — le graphique que l’on obtient en écrivant le minimum de code sensé.
1. SVG avec ARIA sémantique. La bibliothèque produit-elle du SVG (et non du canvas), et ce SVG comporte-t-il des rôles, des libellés et une structure de groupes significatifs plutôt que des nœuds <g> anonymes ?
2. Palettes compatibles daltoniens par défaut. Les palettes catégorielles et séquentielles sont-elles testées pour la DCV directement à la sortie, ou faut-il savoir les surcharger ?
3. Points de données navigables au clavier. Un utilisateur voyant mais limité au clavier peut-il passer en onglet dans le graphique, naviguer entre les marques à l’aide des flèches et lire la valeur de chaque marque ?
4. Hiérarchie de description pour le lecteur d’écran. Y a-t-il un titre, un résumé en une phrase, et des annonces par série et par point — et non pas un simple attribut alt unique ?
5. Vue tableau alternative. Les données sous-jacentes sont-elles disponibles sous forme de tableau HTML lié au graphique ou affiché à côté, pour les utilisateurs préférant une consultation tabulaire ?
« Un graphique livré avec un contraste parfait et une palette compatible daltoniens, mais sans modèle clavier, est un graphique rendu accessible à la moitié seulement de son audience. »
2. Les cinq bibliothèques en lice
Cinq bibliothèques couvrent la grande majorité des nouveaux travaux de visualisation en 2026 : Vega-Lite, Plotly, Observable Plot, Apache ECharts et D3 avec du code personnalisé. Elles occupent différents points sur l’axe d’abstraction — Vega-Lite est la plus déclarative, D3 la plus impérative — et chacune adopte une posture différente vis-à-vis de l’accessibilité. Nous traitons D3 séparément car « D3 + custom » constitue une proposition d’ingénierie fondamentalement différente : l’accessibilité obtenue est celle que l’on écrit.
Aucune de ces bibliothèques n’est hostile à l’accessibilité. Toutes produisent du SVG (Plotly et ECharts peuvent aussi émettre du canvas ; nous évaluons le mode SVG). Toutes acceptent des palettes de couleurs arbitraires. La question est de savoir ce que l’on obtient en écrivant le minimum de code sensé, et combien de reconfiguration il faut pour passer de ce comportement par défaut à un graphique qui respecte réellement WCAG 2.2 AA.
La note « zéro point » attribuée à D3 n’est pas une critique de la bibliothèque — c’est la description honnête de ce que l’on obtient avec un build D3 de base. D3 est une collection de primitives. L’accessibilité d’un graphique D3 est ce que l’auteur y écrit. Un graphique D3 réalisé par un ingénieur qui connaît ARIA peut être le graphique le plus accessible de la page ; un graphique D3 réalisé sans cette connaissance est presque toujours le moins accessible.
3. La matrice d’évaluation : bibliothèque par fonctionnalité d’accessibilité
Les cinq axes de la section un, évalués pour les cinq bibliothèques de la section deux. « Oui » signifie que le comportement par défaut satisfait l’axe ; « Partiel » signifie que la bibliothèque expose les bonnes mécaniques mais ne les active pas par défaut ; « Manuel » signifie que l’ingénieur doit écrire le code correspondant de zéro.
| Vega-Lite | Plotly.js | Observable Plot | Apache ECharts | D3 + custom | |
|---|---|---|---|---|---|
| Sortie SVG avec ARIA sémantique | Oui (SVG, groupes avec titre) | Oui (SVG, libellés ARIA) | Oui (SVG, rôles de marque) | Partiel (canvas par défaut ; rendu SVG en option) | Manuel |
| Palettes compatibles daltoniens par défaut | Oui (Tableau 10 + viridis) | Partiel (palette Plotly par défaut ; palette DCV en option) | Oui (Observable categorical10) | Partiel (schéma par défaut non testé pour la DCV) | Manuel |
| Points de données navigables au clavier | Partiel (focus sur la légende ; marques à configurer) | Oui (navigation par touches fléchées en 2.x) | Partiel (plugin tip donne le focus ; marques manuelles) | Partiel (module a11y en option) | Manuel |
| Hiérarchie de description pour lecteur d’écran | Oui (propriété description spec) | Partiel (titre unique ; par point en option) | Oui (marques ariaLabel + ariaDescription) | Partiel (module a11y émet un alt par série) | Manuel |
| Vue tableau alternative | Partiel (tableau de données facile à rendre) | Partiel (export CSV ; pas de tableau dans le DOM) | Partiel (helper data(), pas de tableau automatique) | Partiel (boîte à outils prend en charge la vue données) | Manuel |
Vega-Lite et Observable Plot se démarquent sur les paramètres déclaratifs par défaut. Plotly se distingue par la navigation clavier intégrée. ECharts dispose du module d’accessibilité optionnel le plus complet de la liste — mais uniquement si vous l’activez. D3 ne vous donne rien et vous donne tout : chaque cellule est « manuel » parce que la bibliothèque n’a pas d’opinion. Aucune de ces bibliothèques n’est une solution en une ligne ; toutes sont viables avec de l’intention.
4. Bon graphique, mauvais graphique : les mêmes données, deux façons
La matrice montre ce qu’expose chaque bibliothèque ; cette section montre ce qu’écrit concrètement un ingénieur. Mêmes données, deux implémentations. La version « mauvaise » se livre vite et paraît correcte sur un écran 27 pouces. La version « bonne » prend 12 lignes de code supplémentaires et satisfait chaque axe de la matrice.
// Vega-Lite — paramètres par défaut uniquement
{
"data": { "url": "complaints.csv" },
"mark": "bar",
"encoding": {
"x": { "field": "category", "type": "nominal" },
"y": { "field": "count", "type": "quantitative" },
"color": { "field": "category" }
}
}S’affiche. Paraît correct. Pas de titre de graphique pour le lecteur d’écran. Pas de description. Pas de modèle clavier sur les marques. Le schéma de couleurs par défaut n’est pas testé pour la DCV avec le nombre de catégories réellement utilisées. Pas de tableau de substitution.
// Vega-Lite — paramètres accessibles
{
"title": "Plaintes par surface, 2024",
"description":
"Graphique à barres de 4 605 plaintes d'accessibilité web, classées par surface. Plus élevé : formulaires (1 940).",
"data": { "url": "complaints.csv" },
"mark": { "type": "bar", "ariaRoleDescription": "bar" },
"encoding": {
"x": { "field": "category", "type": "nominal",
"axis": { "labelAngle": -30 } },
"y": { "field": "count", "type": "quantitative",
"title": "Plaintes" },
"color": {
"field": "category",
"scale": { "scheme": "tableau10" },
"legend": { "title": "Surface" }
},
"tooltip": [
{ "field": "category", "title": "Surface" },
{ "field": "count", "title": "Plaintes" }
]
},
"usermeta": { "embedOptions": { "ariaLabel": "Graphique des plaintes" } }
}Titre, description, palette compatible DCV, axe nommé, champs d’infobulle nommés, description de rôle ARIA sur la marque. Associé à un <table> rendu depuis le même jeu de données, ce graphique satisfait chaque axe de la matrice sans quitter la grammaire déclarative.
Le bon graphique n’est pas un graphique différent. C’est le même graphique avec les paramètres implicites rendus explicites, le titre écrit, la palette nommée, le rôle par marque précisé, et les données également proposées sous forme de tableau. C’est tout l’art de la chose.
Aucune des cinq bibliothèques ne propose de mode par défaut « afficher ce graphique sous forme de tableau ». Le modèle opérationnel consiste à lier les mêmes données à deux composants — le graphique et un <table> HTML en dessous, souvent masqué visuellement mais exposé à la technologie d’assistance via un bouton « Afficher le tableau de données » qui bascule un attribut hidden. Ce modèle coûte environ 20 lignes de code par graphique et se rentabilise dès la première session de recherche utilisateur.
5. Recommandations concrètes, par cas d’usage
Le choix de bibliothèque en 2026 est avant tout une question d’adéquation au flux de travail. Les cinq bibliothèques en lice sont toutes viables. La question est de savoir laquelle correspond au type de graphiques que vous livrez réellement. Cinq cas d’usage courants, cinq recommandations, avec la meilleure alternative citée.
Graphiques éditoriaux / data-journalisme (un seul graphique, soigné)
Recommandation : Observable Plot, Vega-Lite en deuxième position très proche. L’API basée sur les marques de Plot donne des libellés ARIA par marque sans effort, la palette catégorielle est testée pour la DCV, et la sortie SVG se lit proprement. Vega-Lite est en deuxième place parce que la propriété description est le résumé lecteur d’écran en un attribut le plus propre de toutes les bibliothèques — mais Plot l’emporte sur l’ergonomie par défaut pour des pièces éditoriales ponctuelles.
Tableaux de bord créés par des analystes (nombreux graphiques, déclaratifs)
Recommandation : Vega-Lite, Observable Plot en deuxième position très proche. La grammaire de spécification de Vega-Lite permet aux analystes de composer 30 graphiques dans un notebook sans écrire de JavaScript, et les propriétés title + description du schéma fournissent la hiérarchie lecteur d’écran sans plomberie supplémentaire. Associez chaque graphique à un tableau de données rendu par Vega pour satisfaire l’axe du tableau alternatif.
Tableaux de bord scientifiques / BI (exploration interactive)
Recommandation : Plotly.js, ECharts en deuxième position très proche. Plotly est la seule bibliothèque de la liste qui propose la navigation par touches fléchées entre les marques comme comportement par défaut dans la version 2.x. Si votre public s’attend à survoler, zoomer et explorer les données, le modèle clavier intégré de Plotly est le facteur décisif. ECharts rattrape son retard si vous activez le module aria — mais il faut l’activer.
Tableaux de bord opérationnels haute densité (des centaines de points, critiques en performance)
Recommandation : Apache ECharts avec le rendu SVG + module aria activé, Plotly en deuxième position très proche. ECharts offre les meilleures performances de ce groupe pour des graphiques très denses, et le module aria produit des textes alt par série que les lecteurs d’écran traitent correctement. Désactivez le rendu canvas ; il est plus rapide mais l’arbre d’accessibilité disparaît.
Graphiques éditoriaux sur mesure qu’aucune bibliothèque ne rend nativement
Recommandation : D3 avec une couche d’accessibilité écrite à la main. Cette couche est non négociable : un <title> + <desc> à la racine du SVG, role=“img” avec aria-label par marque, un modèle de focus sur chaque marque focusable, et un <table> frère rendu depuis le même jeu de données. D3 est le bon outil quand le graphique n’existe vraiment nulle part ailleurs ; c’est le mauvais outil quand le graphique est un histogramme et que quelqu’un a choisi D3 par habitude.
Le graphique dans une bibliothèque de visualisation n’est que rarement le seul élément sur la page. Les infobulles qui n’apparaissent qu’au survol et jamais au focus, les légendes en <div> et non en <ul>, les anneaux de focus écrasés dans la feuille de style reset de la page, les pastilles de couleur avec un contraste non textuel insuffisant par rapport à l’arrière-plan — ce sont des défaillances de la page qu’aucune bibliothèque de graphiques ne corrigera à votre place. La bibliothèque vous donne les marques ; la page vous donne le reste.
Conclusion : la stack opérationnelle est celle que vous documentez
Aucune des cinq bibliothèques en lice n’est la mauvaise réponse. Toutes satisfont la plupart des axes avec un minimum d’intention. Le meilleur prédicteur d’un graphique accessible en 2026 n’est pas la bibliothèque à la ligne d’import — c’est si l’équipe a écrit, au même endroit que le design system, ce que « graphique accessible » signifie dans cette organisation. Titre. Description. Palette. Modèle clavier. Tableau alternatif. Cinq lignes dans un CONTRIBUTING.md ; la différence entre un graphique qui est livré et un graphique qui arrive à destination.
Choisissez la bibliothèque adaptée au flux de travail, activez ses paramètres d’accessibilité par défaut, associez chaque graphique à un tableau de données, et auditez le chrome de page autour du graphique avec autant de soin que le graphique lui-même. Le graphique par défaut de chacune de ces bibliothèques peut être rendu accessible. Le graphique par défaut d’aucune de ces bibliothèques n’est accessible sans intention.
« La bibliothèque vous donne les marques ; la page vous donne le reste. »