Visualización de datos accesible

La visualización de datos es una de las herramientas más poderosas del arsenal del desarrollador moderno, y una de las que con mayor frecuencia resultan inaccesibles. Un gráfico que resulta atractivo para los usuarios videntes con una percepción normal del color puede resultar completamente incomprensible para un usuario de un lector de pantalla, una persona con deuteranopía o alguien que navega exclusivamente mediante el teclado. No se trata de un caso aislado: aproximadamente 1 de cada 12 hombres y 1 de cada 200 mujeres padecen algún tipo de deficiencia en la visión del color (cifras de prevalencia basadas principalmente en estudios de población del norte de Europa; las tasas varían según la población). Según la OMS, alrededor del 16 % de la población mundial —aproximadamente 1.300 millones de personas— vive con algún tipo de discapacidad.

¿La buena noticia? La accesibilidad en la visualización de datos es, en gran medida, un problema de ingeniería con soluciones bien conocidas. Esta guía te guía paso a paso por cada aspecto —desde el contraste de colores y el marcado semántico hasta los patrones ARIA, la navegación por teclado y las alternativas a las tablas de datos— para que tus gráficos y paneles de control sean accesibles para todos.

1. WCAG 2.2 para la visualización de datos: lo esencial

Las WCAG 2.2 estructuran los requisitos en torno a cuatro principios: Percibible, Operable, Comprensible y Robusto (POUR). Cualquier fallo en la visualización de datos puede atribuirse a una infracción de uno o varios de estos principios. La siguiente tabla relaciona los criterios de éxito más relevantes para los gráficos con cada principio del Nivel AA.

2. Color: Más allá del rojo y el verde

El color es el problema de accesibilidad más habitual en la visualización de datos. La solución no consiste en evitar el color, sino en no basarse nunca únicamente en él. La accesibilidad del color en los gráficos consta de tres aspectos: la selección de la paleta, los índices de contraste y la codificación redundante.

2.1 Paletas aptas para personas con daltonismo

La combinación más peligrosa en la visualización de datos es la del rojo y el verde, una combinación que aproximadamente el 8 % de la población masculina no puede distinguir. La siguiente paleta se encuentra entre las opciones más recomendadas para personas con daltonismo en la investigación sobre visualización de datos, y está diseñada para que sea distinguible en casos de deuteranopia, protanopia y tritanopia; no obstante, las combinaciones específicas deben validarse con un simulador de daltonismo para el contexto concreto de tu gráfico.

2.2 Codificación redundante

La técnica de accesibilidad más eficaz para los gráficos es la codificación redundante: transmitir la misma información a través de varios canales visuales al mismo tiempo. Nunca confíes solo en el color: combínalo con al menos uno de los siguientes elementos: forma, patrón, posición, etiqueta o textura.

3. Marcado semántico y ARIA para gráficos

Gráficos generados en SVG o <canvas> a menudo resultan inaccesibles para las tecnologías de apoyo sin un esfuerzo deliberado. SVG puede muestra la semántica cuando se ha redactado correctamente; <canvas>, al tratarse de una superficie de mapa de bits, carece por completo de un modelo de accesibilidad inherente. En cualquier caso, una accesibilidad significativa requiere una estrategia de marcado deliberada. A continuación se presenta la jerarquía de enfoques, desde el más sencillo hasta el más completo.

3.1 Accesibilidad del formato SVG

El formato SVG cuenta con semántica de accesibilidad nativa cuando se utiliza correctamente. Un gráfico SVG totalmente accesible requiere <title>, <desc>, y los roles correspondientes en el elemento más externo.

<!-- Accessible SVG bar chart shell -->
<svg
  role="img"
  aria-labelledby="chart-title chart-desc"
  viewBox="0 0 600 400"
  xmlns="http://www.w3.org/2000/svg">

  <!-- Screen readers read title + desc as the alt text -->
  <title id="chart-title">Monthly active users, Jan–Jun 2025</title>
  <desc id="chart-desc">
    Bar chart showing MAU growth from 42,000 in January to
    89,500 in June 2025. Peak month: June. Lowest: January.
  </desc>

  <!-- Each data bar is individually focusable -->
  <g role="list" aria-label="Monthly data bars">
    <g role="listitem">
      <rect
        tabindex="0"
        role="img"
        aria-label="January: 42,000 monthly active users"
        x="40" y="200" width="60" height="168"
        fill="#0072B2"
        aria-describedby="jan-tooltip"
      />
      <text id="jan-tooltip" class="sr-only">
        January 2025, 42,000 users, 112% of Q4 average
      </text>
    </g>
    <!-- Repeat for each data point -->
  </g>
</svg>

<!-- Always provide a visible data table fallback -->
<details>
  <summary>View data as table</summary>
  <!-- Full table here -->
</details>

3.2 Gráficos de Canvas

<canvas> se representa como un mapa de bits — tiene no semántica de accesibilidad inherente. El patrón de lienzo accesible utiliza un subárbol DOM de reserva dentro del elemento `canvas` que las tecnologías de asistencia leen en su lugar.

<canvas
  id="revenue-chart"
  width="800"
  height="400"
  aria-label="Revenue by region, Q1 2025"
  role="img">

  <!-- Fallback: AT reads this when canvas is unsupported -->
  <p>
    Q1 2025 Revenue by Region: EMEA £2.4M (38%),
    Americas £2.1M (33%), APAC £1.8M (29%).
    EMEA leads for third consecutive quarter.
  </p>
  <table>
    <!-- Full data table -->
  </table>
</canvas>

<!-- For Chart.js: use the accessibility plugin -->
<script>
new Chart(ctx, {
  plugins: [{
    id: 'a11y',
    afterRender(chart) {
      // Rebuild live ARIA region from chart data
      const liveRegion = document.getElementById('chart-live');
      liveRegion.textContent = buildSummary(chart.data);
    }
  }]
});
</script>

4. Navegación mediante el teclado y gestión del foco

La accesibilidad mediante el teclado en los gráficos implica tres cosas: poder acceder a todos los elementos interactivos con el teclado, manejar dichos elementos sin necesidad del ratón y recibir la misma información (información sobre herramientas, zoom, filtros) que los usuarios que utilizan el ratón.

4.1 El patrón de tabindex itinerante

En los gráficos con muchos puntos de datos (por ejemplo, un gráfico de dispersión con 200 puntos), incluir cada punto en el orden de tabulación dificulta la navegación. Utiliza el tabindex itinerante patrón: solo hay un punto en la secuencia de tabulaciones a la vez (tabindex="0"); las teclas de flecha permiten desplazar el foco dentro del grupo de gráficos.

// Roving tabindex for interactive chart data points
class AccessibleChart {
  constructor(containerEl) {
    this.points = [...containerEl.querySelectorAll('[data-point]')];
    this.currentIndex = 0;
    this.init();
  }

  init() {
    // Set initial roving tabindex
    this.points.forEach((pt, i) => {
      pt.setAttribute('tabindex', i === 0 ? '0' : '-1');
      pt.addEventListener('keydown', (e) => this.handleKey(e, i));
    });
  }

  handleKey(e, idx) {
    const { key } = e;
    let next = idx;

    if (key === 'ArrowRight' || key === 'ArrowDown')
      next = Math.min(idx + 1, this.points.length - 1);
    else if (key === 'ArrowLeft' || key === 'ArrowUp')
      next = Math.max(idx - 1, 0);
    else if (key === 'Home') next = 0;
    else if (key === 'End')  next = this.points.length - 1;
    else return;

    e.preventDefault();
    this.points[idx].setAttribute('tabindex', '-1');
    this.points[next].setAttribute('tabindex', '0');
    this.points[next].focus();

    // Show tooltip programmatically
    this.showTooltip(this.points[next]);
  }
}

4.2 Indicadores clave

Las WCAG 2.2 introducen requisitos más estrictos para los indicadores de foco a través de la norma 2.4.11 «Apariencia del foco» (AA). El indicador debe tener un área de al menos el perímetro del componente sin foco multiplicado por 2 píxeles CSS, con una relación de contraste de al menos 3:1 entre los estados de foco y sin foco.

/* WCAG 2.2 AA compliant focus indicator for data points */
[data-point]:focus-visible {
  /* 2px offset, 3px ring = clearly visible at any size */
  outline: 3px solid #005fcc;
  outline-offset: 3px;

  /* Additional contrast boost for AAA */
  box-shadow: 0 0 0 5px rgba(0, 95, 204, 0.2);
}

/* Respect user preference */
@media (forced-colors: active) {
  [data-point]:focus-visible {
    outline-color: Highlight;
    outline-width: 3px;
  }
}

5. Patrones de lectores de pantalla

Diseñar para lectores de pantalla significa diseñar una experiencia auditiva lineal a partir de datos que , por naturaleza, son espaciales y visuales. La idea clave es que no se trata de convertir el gráfico , sino de redactar una narración de lo que este transmite.

5.1 Cómo redactar buenas descripciones de gráficos

Una buena descripción de un gráfico consta de tres partes:

1. Tipo y finalidad: «Gráfico de barras que muestra los ingresos trimestrales del ejercicio fiscal 2025».
2. Conclusión principal: «El tercer trimestre fue el más sólido, con 4,2 millones de libras, lo que supone un aumento del 28 % con respecto al segundo trimestre».
3. Excepciones destacadas o contexto: «La caída del primer trimestre se atribuye a las interrupciones en la cadena de suministro registradas en enero».

5.2 Regiones activas para gráficos dinámicos

Cuando los datos de los gráficos se actualicen en tiempo real (paneles de análisis, herramientas de supervisión), utiliza las regiones activas de ARIA para notificar los cambios sin interrumpir la posición de lectura actual del usuario.

<!-- Polite live region: announces after current speech -->
<div
  id="chart-status"
  role="status"
  aria-live="polite"
  aria-atomic="true"
  class="sr-only">
</div>

<!-- Assertive region: interrupts for critical alerts only -->
<div
  id="chart-alert"
  role="alert"
  aria-live="assertive"
  class="sr-only">
</div>

<script>
// When data updates, push a human-readable summary
function announceChartUpdate(newData, isAlert = false) {
  const id = isAlert ? 'chart-alert' : 'chart-status';
  const el = document.getElementById(id);

  // Clear then set: forces screen readers to re-read
  el.textContent = '';
  requestAnimationFrame(() => {
    el.textContent = buildSummary(newData);
  });
}
</script>

6. Tablas de datos accesibles como alternativa

Cada gráfico debería ir acompañado de una tabla de datos accesible, ya sea visible o accesible a través de un widget de despliegue. No se trata solo de un requisito de accesibilidad, sino de una buena arquitectura de la información. Las tablas permiten a los usuarios encontrar valores concretos, que los gráficos a menudo ocultan.

6.1 Prácticas recomendadas para el marcado de tablas

7. Comparación de tipos de gráficos: ventajas e inconvenientes en materia de accesibilidad

No todos los tipos de gráficos ofrecen el mismo nivel de accesibilidad de forma predeterminada. La siguiente matriz evalúa cada tipo habitual en cuatro aspectos relacionados con la accesibilidad, con soluciones recomendadas para los casos más complejos.

Demostración de gráficos accesibles

El siguiente gráfico de barras aplica los patrones descritos en esta guía. Cada barra puede recibir el foco del teclado y tiene un aria-label, y el gráfico incluye una tabla de datos alternativa visible.

8. Calculadora de impacto: cómo estimar tu público excluido

Una de las formas más eficaces de conseguir el apoyo de la organización para las iniciativas de accesibilidad es cuantificar el público afectado. Utiliza la calculadora que aparece a continuación para estimar cuántos usuarios se ven actualmente excluidos por los errores habituales de accesibilidad en los gráficos.

9. Comprobación de la implementación

Ninguna herramienta automatizada puede detectar todos los problemas de accesibilidad: según los estudios, las herramientas automatizadas solo detectan entre el 30 % y el 40 % de los incumplimientos de las WCAG. Una estrategia de pruebas completa combina el análisis automatizado, las pruebas manuales y las pruebas con usuarios que utilizan tecnología de apoyo.

9.1 Cadena de herramientas de pruebas

9.2 Secuencia de pruebas recomendada

10. Lista de verificación para la implementación

Utiliza esta lista de verificación al lanzar cualquier gráfico, panel de control o función de visualización de datos nuevos. Todos los elementos marcados como «WCAG AA» son obligatorios para cumplir con la normativa legal en muchas jurisdicciones (EN 301 549 en la UE, Sección 508 en EE. UU.).

«La accesibilidad no es una función que se añada al final de un proyecto, sino una característica de calidad que debe integrarse desde la primera decisión de diseño. En el caso de la visualización de datos, esto significa que la pregunta nunca es “¿cómo hacemos que este gráfico sea accesible?”, sino “¿cuál es la forma más accesible de comunicar estos datos?”» — AIOPSGROUP Engineering Practice