Cómo crear gráficos accesibles que funcionen para todos

El problema de los gráficos

Los gráficos y diagramas son objetos inherentemente visuales. Codifican la información mediante la forma, la posición y el color: tres canales que resultan irrelevantes o distorsionados para una parte significativa de tu audiencia.

Alrededor del 8% de los hombres tiene algún tipo de deficiencia en la visión del color. Los usuarios de lectores de pantalla no reciben ninguna información significativa de un gráfico de barras en SVG a menos que el desarrollador la haya proporcionado explícitamente. Y los usuarios de teclado a menudo encuentran que los gráficos interactivos son completamente inalcanzables.

El resultado: la visualización de datos es probablemente el área del diseño web donde la brecha entre lo que experimentan los usuarios videntes y lo que experimenta el resto es más amplia. Y es una brecha que las organizaciones rara vez detectan, porque las auditorías de accesibilidad se centran en formularios y navegación antes de llegar a los gráficos de la página de informes.

Esta guía explica lo que realmente exige una visualización de datos accesible: no una lista de verificación, sino una comprensión de por qué fallan los gráficos y qué hacer al respecto.

Por qué los gráficos son especialmente difíciles

La mayoría de los elementos HTML tienen un rol, un nombre y un estado nativos que las tecnologías de apoyo entienden. Un <button> es un botón. Una <table> es una tabla con filas y columnas. Un campo de formulario tiene una etiqueta.

Un gráfico renderizado como SVG o canvas no tiene nada de esto. Es un dibujo. Los lectores de pantalla ven una imagen (con suerte) o nada en absoluto. El desarrollador tiene que reconstruir la capa semántica desde cero.

Al mismo tiempo, los gráficos suelen ser el contenido más importante de una página. Un gráfico de barras con los ingresos mensuales, un gráfico de líneas que sigue el crecimiento de usuarios, un gráfico circular que desglosa la distribución por categorías: con frecuencia son la razón por la que el usuario está en la página. Excluirlos para una parte significativa de los visitantes es un problema grave, no una molestia menor.

El problema del color: nunca dependas solo del color

El fallo de accesibilidad más común en los gráficos es usar el color como única forma de distinguir series de datos o categorías.

Un gráfico de líneas con cuatro líneas diferenciadas solo por el color —rojo, azul, verde, naranja— resulta ilegible para muchos usuarios con deficiencia en la visión del color, y completamente incomprensible para cualquiera que use un modo de alto contraste o una pantalla en escala de grises.

La solución es la codificación redundante: usa el color más al menos otra propiedad visual.

Gráficos de líneas: usa distintos patrones de trazo junto con los colores (continuo, discontinuo, punteado, punto-raya)
Gráficos de barras: usa texturas o patrones junto con los colores, o añade etiquetas de datos directamente sobre las barras
Diagramas de dispersión: usa marcadores de distintas formas (círculo, cuadrado, triángulo, rombo) junto con los colores
Gráficos circulares: añade etiquetas de texto dentro o junto a cada segmento; nunca dependas solo de la leyenda

Esto entra dentro del criterio 1.4.1 Uso del color (nivel A) de WCAG 2.2: el color no debe ser el único medio para transmitir información.

Contraste en los gráficos

Los elementos visuales no textuales, como las barras, los trazos de las líneas y los puntos de datos, deben alcanzar un contraste de 3:1 con respecto a su fondo según el criterio 1.4.11 Contraste no textual (nivel AA). Comprueba la paleta de tus gráficos con un verificador de contraste: muchas paletas de marca que se ven bien en áreas grandes incumplen este requisito en tamaños más pequeños.

El texto dentro de los gráficos —etiquetas de ejes, etiquetas de datos, leyendas— debe cumplir los mismos requisitos de contraste que el texto del cuerpo: 4.5:1 para texto normal y 3:1 para texto grande según el criterio 1.4.3 Contraste mínimo.

Proporcionar alternativas de texto

Todo gráfico necesita una alternativa de texto que transmita los datos que muestra. La forma exacta que adopte depende de la complejidad de los datos.

Gráficos simples: texto alternativo descriptivo

Para un gráfico de barras con cinco valores, un atributo alt bien redactado puede resumir el hallazgo clave:

<img
  src="monthly-revenue.png"
  alt="Monthly revenue Q1 2025: Jan £42k, Feb £38k, Mar £51k,
       Apr £49k, May £56k. Steady upward trend from February onwards."
>

El texto alternativo hace aquí dos cosas: enuncia los puntos de datos y resume la conclusión clave. No te limites a describir el gráfico visualmente («un gráfico de barras que muestra ingresos»). Describe lo que el gráfico comunica.

Gráficos complejos: tablas de datos complementarias

Cuando un gráfico contiene más datos de los que caben en un atributo alt, proporciona una tabla de datos accesible cerca. Esto también sirve a las personas que prefieren los datos tabulares a los formatos visuales. La tabla puede estar oculta por defecto, pero debe ser alcanzable:

<figure>
  <figcaption>Revenue by region, Q1 2025</figcaption>
  <svg aria-labelledby="chart-title" aria-describedby="chart-desc" role="img">
    <title id="chart-title">Revenue by region, Q1 2025</title>
    <desc id="chart-desc">Bar chart showing UK leading with £180k,
    followed by DE at £124k, FR at £98k, and NL at £71k.</desc>
    <!-- chart content -->
  </svg>
  <details>
    <summary>View as table</summary>
    <table>
      <caption>Revenue by region, Q1 2025</caption>
      <thead><tr><th>Region</th><th>Revenue</th></tr></thead>
      <tbody>
        <tr><td>UK</td><td>£180,000</td></tr>
        <tr><td>DE</td><td>£124,000</td></tr>
        <tr><td>FR</td><td>£98,000</td></tr>
        <tr><td>NL</td><td>£71,000</td></tr>
      </tbody>
    </table>
  </details>
</figure>

Patrones específicos para SVG

Los gráficos SVG renderizados en línea (en lugar de como archivos de imagen) pueden hacerse directamente accesibles usando ARIA. Patrones clave:

Añade role="img" al elemento <svg>
Proporciona un <title> como primer hijo del <svg> y vincúlalo con aria-labelledby
Añade un <desc> para descripciones más largas y vincúlalo con aria-describedby
Marca los elementos decorativos (líneas de cuadrícula, marcas de graduación) con aria-hidden="true" para reducir el ruido

En los gráficos interactivos donde los usuarios pueden seleccionar puntos de datos, cada elemento interactivo necesita un rol y un nombre adecuados, además de soporte de teclado.

Navegación por teclado en gráficos interactivos

Si tus gráficos son interactivos —tooltips al pasar el ratón, segmentos en los que se puede hacer clic, selección y zoom—, deben poder manejarse completamente con el teclado según el criterio 2.1.1 Teclado (nivel A).

Para gráficos con muchos puntos de datos, implementa un patrón de tabindex itinerante (roving): solo un elemento del gráfico está en la secuencia de tabulación en cada momento, y las teclas de flecha permiten moverse entre los puntos de datos dentro del gráfico.

<!-- Each bar is a button, navigable with arrow keys -->
<g role="group" aria-label="Monthly revenue bars">
  <rect
    role="button"
    tabindex="0"
    aria-label="January: £42,000"
    onkeydown="handleChartKey(event)"
    ...
  />
</g>

Los tooltips que solo aparecen al pasar el ratón también deben aparecer con el foco de teclado. Un tooltip visible únicamente para los usuarios de ratón es un fallo de accesibilidad.

Elegir el tipo de gráfico adecuado

Algunos tipos de gráfico son inherentemente más accesibles que otros. Cuando puedas elegir:

Tipo de gráfico	Accesibilidad	Notas
Gráfico de barras	Alta	Las cantidades son fáciles de codificar con etiquetas; permite un buen soporte de teclado
Gráfico de líneas	Alta	Usa distintos patrones de trazo; anota los puntos clave
Tabla	La más alta	La más fácil de hacer accesible; a menudo la opción correcta para los datos
Diagrama de dispersión	Media	Requiere una diferenciación cuidadosa de los marcadores; la navegación por teclado es compleja
Mapa de calor	Baja	Depende del color por naturaleza; proporciona siempre una tabla alternativa
Circular/anillo	Baja	Difícil comparar valores; evítalo con más de 3-4 segmentos

En caso de duda, una tabla bien formateada es casi siempre más accesible que un gráfico, y a menudo más fácil de leer independientemente de la discapacidad. No uses un gráfico porque parezca moderno; úsalo cuando realmente ayude a los usuarios a entender una tendencia o una comparación más rápido de lo que lo harían los datos tabulares.

Cómo probar tus gráficos

Los escáneres automáticos de accesibilidad pueden detectar atributos alt ausentes y algunos patrones ARIA, pero no pueden verificar que los datos del gráfico sean significativos, que la navegación por teclado funcione correctamente o que el gráfico tenga sentido para un usuario de lector de pantalla. Prueba con:

Un lector de pantalla (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): navega hasta el gráfico y verifica qué se anuncia
Solo teclado: tabula hasta el gráfico y confirma que todos los elementos interactivos son alcanzables y manejables con el teclado
Simulación de daltonismo: usa Chrome DevTools (Rendering > Emulate vision deficiency) para ver cómo se muestra el gráfico con distintos tipos de deficiencia en la visión del color
Zoom al 200%: verifica que las etiquetas y las leyendas no se superpongan ni queden cortadas

Nuestro servicio de evaluación con lectores de pantalla prueba los gráficos con usuarios reales de tecnologías de apoyo: la forma más rápida de descubrir lo que tus usuarios experimentan de verdad.