Herramientas de visualización de datos accesible en 2026:
un stack de trabajo
Cinco bibliotecas dominan la conversación moderna sobre visualización de datos, pero solo algunas de ellas tratan al lector de pantalla como un consumidor de primera clase. Esta es la hoja de puntuación de un ingeniero en activo, redactada para equipos que despliegan gráficos en producción en 2026.
1. Los cinco ejes que determinan si un gráfico es accesible
La expresión «gráfico accesible» oculta un conjunto de requisitos discretamente diferentes. Un gráfico de barras puede renderizarse como SVG con un contraste de color perfecto y seguir siendo inalcanzable para un usuario que solo use teclado. Puede ser navegable por teclado y aún así no anunciar nada útil a un lector de pantalla. Puede anunciar los valores de forma clara y aún así dejar a un usuario con baja visión bloqueado ante el primer tooltip. Para comparar las bibliotecas de manera justa, evaluamos cada una conforme a cinco ejes independientes que reflejan directamente cómo una persona usuaria de tecnología de apoyo real experimenta una visualización.
Estos cinco ejes no son una lista de preferencias personales. Son la traducción práctica de los criterios de conformidad WCAG 2.2 (1.4.11 contraste de componentes de interfaz de usuario y gráficos, 2.1.1 teclado, 4.1.2 nombre, función, valor), las orientaciones de la Guía de Prácticas de Autoría ARIA sobre gráficos y la nota borrador del Grupo de Trabajo sobre Preguntas de Investigación del W3C «Accesibilidad en la visualización de datos» que ha circulado desde 2023. Todas las bibliotecas de gráficos producen SVG; todas generan algún tipo de leyenda; todas tienen una opinión sobre el color. Lo que las distingue son los valores predeterminados — el gráfico que se obtiene al escribir la cantidad mínima razonable de código.
1. SVG con ARIA semántico. ¿La biblioteca genera SVG (no canvas) y ese SVG lleva roles, etiquetas y estructura de grupo con significado, en lugar de nidos anónimos de <g>?
2. Paletas seguras para daltonismo por defecto. ¿Las paletas categóricas y secuenciales han sido probadas para CVD de serie, o hay que saber que deben reemplazarse?
3. Puntos de datos navegables por teclado. ¿Puede un usuario con visión que solo utiliza teclado entrar en el gráfico con el tabulador, desplazarse entre marcas con las flechas y leer el valor de cada marca?
4. Jerarquía de descripción para lector de pantalla. ¿Hay un título, un resumen de una frase y anuncios por serie/por punto — no solo un volcado único de texto alternativo?
5. Vista de tabla alternativa. ¿Los datos subyacentes están disponibles como una tabla HTML enlazada desde el gráfico, o renderizada junto a él, para los usuarios que prefieren el consumo tabular?
«Un gráfico que se entrega con un contraste perfecto y una paleta segura para daltonismo pero sin modelo de teclado es un gráfico que se ha renderizado para la mitad del público.»
2. Las cinco bibliotecas sobre la mesa
Cinco bibliotecas concentran la gran mayoría del trabajo nuevo de visualización de gráficos en 2026: Vega-Lite, Plotly, Observable Plot, Apache ECharts y D3 con código personalizado. Ocupan distintos puntos en el eje de abstracción — Vega-Lite es el más declarativo, D3 es el más imperativo — y cada uno tiene una postura diferente ante la accesibilidad. Tratamos D3 por separado porque «D3 + código personalizado» es una propuesta de ingeniería fundamentalmente diferente: la accesibilidad que se obtiene es la accesibilidad que se escribe.
Ninguna de estas bibliotecas es hostil a la accesibilidad. Todas producen SVG (Plotly y ECharts también pueden emitir canvas; evaluamos el modo SVG). Todas aceptan paletas de color arbitrarias. La pregunta es qué se obtiene al escribir la cantidad mínima razonable de código, y cuánto hay que reconfigurar para pasar de ese valor predeterminado a un gráfico que supere realmente WCAG 2.2 AA.
La valoración de «cero puntos» para D3 no es una crítica a la biblioteca — es la descripción honesta de lo que se obtiene con una construcción estándar con D3. D3 son primitivos. La accesibilidad en un gráfico con D3 es lo que el autor escribe. Un gráfico D3 creado por un ingeniero que conoce ARIA puede ser el gráfico más accesible de la página; un gráfico D3 creado sin ese conocimiento es casi siempre el gráfico menos accesible de la página.
3. La matriz de puntuación: biblioteca por característica de accesibilidad
Los cinco ejes de la primera sección, evaluados frente a las cinco bibliotecas de la segunda sección. «Sí» significa que el comportamiento predeterminado supera el eje; «Parcial» significa que la biblioteca expone los mecanismos adecuados pero no los activa por defecto; «Manual» significa que el ingeniero tiene que escribir el código correspondiente desde cero.
| Vega-Lite | Plotly.js | Observable Plot | Apache ECharts | D3 + código personalizado | |
|---|---|---|---|---|---|
| Salida SVG con ARIA semántico | Sí (SVG, grupos con título) | Sí (SVG, etiquetas ARIA) | Sí (SVG, roles de marca) | Parcial (canvas por defecto; renderizador SVG opcional) | Manual |
| Paletas seguras para daltonismo por defecto | Sí (Tableau 10 + viridis) | Parcial (paleta Plotly por defecto; paleta CVD opcional) | Sí (Observable categorical10) | Parcial (esquema por defecto no probado para CVD) | Manual |
| Puntos de datos navegables por teclado | Parcial (foco en leyenda; marcas requieren configuración) | Sí (navegación por teclas de flecha en 2.x) | Parcial (el plugin tip da foco; marcas de forma manual) | Parcial (módulo de accesibilidad opcional) | Manual |
| Jerarquía de descripción para lector de pantalla | Sí (propiedad description en la especificación) | Parcial (un único título; por punto de forma opcional) | Sí (marcas ariaLabel + ariaDescription) | Parcial (el módulo de accesibilidad emite alt por serie) | Manual |
| Vista de tabla alternativa | Parcial (tabla de datos fácil de renderizar) | Parcial (exportar a CSV; sin tabla en el DOM) | Parcial (ayudante data(), sin tabla automática) | Parcial (la caja de herramientas admite vista de datos) | Manual |
Vega-Lite y Observable Plot lideran en valores predeterminados declarativos. Plotly lidera en navegación por teclado integrada. ECharts cuenta con el módulo de accesibilidad opcional más completo de todas las bibliotecas de la lista — pero solo si se habilita. D3 no da nada y lo da todo: cada celda es «manual» porque la biblioteca no tiene opinión. Ninguna de estas bibliotecas es una solución de una sola línea; todas son viables con intención.
4. Gráfico bueno, gráfico malo: los mismos datos, dos formas
La matriz muestra lo que expone cada biblioteca; esta sección muestra lo que escribe realmente un ingeniero. Los mismos datos, dos implementaciones. La versión «mala» se entrega rápidamente y se ve bien en un monitor de 27 pulgadas. La versión «buena» requiere 12 líneas de código más y supera todos los ejes de la matriz.
// Vega-Lite — solo valores predeterminados
{
"data": { "url": "complaints.csv" },
"mark": "bar",
"encoding": {
"x": { "field": "category", "type": "nominal" },
"y": { "field": "count", "type": "quantitative" },
"color": { "field": "category" }
}
}Se renderiza. Se ve bien. Sin título del gráfico para el lector de pantalla. Sin descripción. Sin modelo de teclado en las marcas. Esquema de color predeterminado no probado para CVD con el número de categorías que se tienen realmente. Sin tabla alternativa.
// Vega-Lite — valores predeterminados accesibles
{
"title": "Complaints by surface, 2024",
"description":
"Bar chart of 4,605 web-accessibility complaints, ranked by surface. Highest: forms (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": "Complaints" },
"color": {
"field": "category",
"scale": { "scheme": "tableau10" },
"legend": { "title": "Surface" }
},
"tooltip": [
{ "field": "category", "title": "Surface" },
{ "field": "count", "title": "Complaints" }
]
},
"usermeta": { "embedOptions": { "ariaLabel": "Complaints chart" } }
}Título, descripción, paleta segura para CVD, eje con nombre, campos de tooltip con nombre, descripción de rol ARIA en la marca. Acompañado de un <table> renderizado desde el mismo conjunto de datos, supera todos los ejes de la matriz sin salir de la gramática declarativa.
El gráfico bueno no es un gráfico diferente. Es el mismo gráfico con los valores predeterminados implícitos hechos explícitos, el título escrito, la paleta nombrada, el rol por marca definido y los datos ofrecidos también como tabla. Ese es todo el arte.
Ninguna de las cinco bibliotecas incluye un modo predeterminado de «renderizar este gráfico como tabla» por sí sola. El patrón de trabajo consiste en: vincular los mismos datos a dos componentes — el gráfico y una <table> HTML debajo de él, a menudo oculta visualmente pero expuesta a la tecnología de apoyo con un interruptor «Mostrar tabla de datos» que cambia un atributo hidden. Este patrón cuesta aprox. 20 líneas de código de framework por gráfico y se amortiza dentro de la primera sesión de investigación con usuarios.
5. Recomendaciones concretas por caso de uso
La elección de biblioteca en 2026 depende principalmente del flujo de trabajo. Las cinco bibliotecas sobre la mesa son todas viables. La pregunta es cuál encaja con el tipo de gráficos que se están entregando realmente. Cinco casos de uso habituales, cinco recomendaciones, con la segunda mejor alternativa nombrada.
Gráficos editoriales / de periodismo de datos (un gráfico, acabado)
Recomendación: Observable Plot, con Vega-Lite como segundo mejor. La API basada en marcas de Plot proporciona etiquetas ARIA por marca de forma gratuita, la paleta categórica ha sido probada para CVD y la salida SVG se lee con claridad. Vega-Lite es el segundo aquí porque la propiedad description es el resumen para lector de pantalla de un único atributo más claro de cualquier biblioteca — pero Plot gana en ergonomía predeterminada para piezas editoriales únicas.
Paneles de autoría analítica (muchos gráficos, declarativos)
Recomendación: Vega-Lite, con Observable Plot como segundo mejor. La gramática de especificación de Vega-Lite permite a los analistas componer 30 gráficos en un cuaderno sin escribir JavaScript, y las propiedades title + description del esquema proporcionan la jerarquía para el lector de pantalla sin tuberías adicionales. Hay que acompañar cada gráfico de una tabla de datos renderizada con Vega para superar el eje de tabla alternativa.
Paneles científicos / de BI (exploración interactiva)
Recomendación: Plotly.js, con ECharts como segundo mejor. Plotly es la única biblioteca de la lista que ofrece de serie la navegación por teclas de flecha entre marcas en la línea 2.x. Si el público espera pasar el cursor, hacer zoom y profundizar, el modelo de teclado integrado de Plotly es el factor decisivo. ECharts alcanza ese nivel si se habilita el módulo aria — pero hay que habilitarlo.
Paneles operativos de alta densidad (cientos de puntos, crítico en rendimiento)
Recomendación: Apache ECharts con renderizador SVG + módulo aria activado, con Plotly como segundo mejor. ECharts es la mejor opción de rendimiento de este grupo para gráficos muy densos y el módulo aria produce texto alternativo por serie que los lectores de pantalla manejan con competencia. Conviene desactivar el renderizador canvas; el canvas es más rápido pero el árbol de accesibilidad desaparece.
Gráficos editoriales a medida que ninguna biblioteca renderiza (personalizado, único)
Recomendación: D3 con una capa de accesibilidad escrita a mano. La capa escrita a mano no es negociable: un <title> + <desc> en la raíz SVG, role=“img” con aria-label por marca, un modelo de foco en cada marca enfocable y un <table> hermano renderizado desde el mismo conjunto de datos. D3 es la herramienta correcta cuando el gráfico genuinamente no existe en ningún otro lugar; es la herramienta equivocada cuando el gráfico es un diagrama de barras y alguien utilizó D3 por costumbre.
El gráfico dentro de una biblioteca de gráficos rara vez es lo único en la página. Los tooltips que solo se activan al pasar el cursor y nunca aparecen al recibir el foco, las leyendas que son <div> en lugar de <ul>, los anillos de foco reemplazados por la hoja de estilos de reset de la página, las muestras de color con contraste insuficiente de componentes no textuales frente al fondo de la página — estos son fallos a nivel de página que ninguna biblioteca de gráficos subsanará por sí sola. La biblioteca proporciona las marcas; la página proporciona el resto.
Conclusión: el stack de trabajo es el que se documenta
Ninguna de las cinco bibliotecas sobre la mesa es la respuesta equivocada. Todas superan la mayoría de los ejes con una pequeña cantidad de intención. El predictor más fiable de un gráfico accesible en 2026 no es la biblioteca en la línea de importación — es si el equipo ha escrito, en el mismo lugar que el sistema de diseño, qué significa «gráfico accesible» en esta organización. Título. Descripción. Paleta. Modelo de teclado. Tabla alternativa. Cinco líneas en un CONTRIBUTING.md; la diferencia entre un gráfico que se entrega y un gráfico que llega.
Conviene elegir la biblioteca que encaje con el flujo de trabajo, activar sus valores predeterminados de accesibilidad, acompañar cada gráfico de una tabla de datos y auditar el entorno de la página alrededor del gráfico con el mismo cuidado que el gráfico mismo. El gráfico predeterminado en cualquiera de estas bibliotecas puede hacerse accesible. El gráfico predeterminado en ninguna de estas bibliotecas es accesible sin intención.
«La biblioteca proporciona las marcas; la página proporciona el resto.»