ACCESIBILIDAD ≠ OVERLAY · 36
Tablas accesibles: cuando los datos necesitan contexto, no un overlay
📅 9 de noviembre de 2026 · ⏱ 8 min de lectura
Una tabla puede verse ordenada y seguir siendo incomprensible para quien la escucha o la consulta con ampliación. La accesibilidad exige conservar las relaciones entre cada dato, su fila y su columna.
01. Un número aislado no explica nada
Imagina que consultas los horarios de un servicio y solo escuchas «09:00, 10:00, 11:00, 12:00». Sin saber qué día o qué servicio corresponde a cada hora, la información no permite decidir. La barrera aparece cuando el contexto depende exclusivamente de mirar hacia arriba o hacia la izquierda. No falta información en la pantalla: falta una relación que el software pueda interpretar.
En una tabla de precios ocurre lo mismo. Una cifra puede corresponder al importe mensual, al precio anual o a un suplemento. Si la persona debe memorizar la posición de todas las columnas, consultar la tabla se convierte en un ejercicio de reconstrucción. El objetivo es que pueda responder a una pregunta concreta con autonomía.
02. Decide si los datos necesitan una tabla
Una tabla resulta adecuada cuando comparar filas y columnas aporta significado: horarios, tarifas, características o resultados. Si solo tienes una secuencia de instrucciones o una ficha con dos datos, una lista o varios párrafos pueden ser más claros. La decisión debe partir de la información, no del aspecto cuadriculado que ofrece el editor.
Tampoco conviene utilizar tablas para colocar dos bloques uno al lado del otro. La maquetación corresponde a CSS y a los componentes de diseño. Mezclar presentación y datos introduce una estructura que puede anunciarse sin aportar nada. Antes de programar, escribe qué comparación necesita realizar la persona y elimina columnas que no ayuden a esa tarea.
03. Encabezados que existen también en el código
Poner la primera fila en negrita o con fondo azul no la convierte en un conjunto de encabezados. Las celdas que identifican columnas o filas deben marcarse como th; las celdas de datos utilizan td. En una tabla sencilla, scope="col" y scope="row" permiten indicar la dirección de esas relaciones cuando corresponde.
Por ejemplo, «Servicio», «Lunes» y «Martes» identifican columnas. «Consultas» y «Soporte» pueden identificar filas. Al consultar una hora, interesa reconocer tanto el servicio como el día. No añadas ARIA por rutina para repetir la semántica nativa. Primero comprueba el HTML que produce el componente y después verifica cómo lo interpreta la combinación de navegador y lector de pantalla utilizada.
| Servicio | Lunes | Martes |
|---|---|---|
| Consultas | 09:00 | 10:00 |
| Soporte | 11:00 | 12:00 |
04. Un título útil y una explicación breve
Un caption ayuda a identificar la tabla: «Horarios de atención» dice bastante más que «Tabla 1». El título debe permitir distinguirla de otras sin obligar a leer todo el contenido anterior. Si el periodo, la moneda o la unidad son esenciales, deben quedar claros en la propia tabla o en una explicación asociada.
Una tabla compleja puede necesitar además una indicación de cómo se organiza. Explica, por ejemplo, que cada grupo de columnas corresponde a un trimestre. Esa orientación no sustituye los encabezados de las celdas. Evita descripciones interminables que repitan todos los valores: el propósito es facilitar la consulta, no obligar a escuchar la tabla dos veces.
05. Simplifica antes de combinar celdas
Las celdas combinadas y los encabezados con varios niveles aumentan la dificultad de interpretación y mantenimiento. Antes de usarlos, pregunta si puedes dividir la información en varias tablas más pequeñas, cada una con un título preciso. A veces separar dos periodos mejora mucho más la comprensión que añadir atributos a una cuadrícula enorme.
Cuando la complejidad sea necesaria, modela expresamente los grupos y las asociaciones. Según la estructura, pueden resultar adecuados scope="colgroup", scope="rowgroup" o las relaciones entre id y headers. No son fórmulas intercambiables que deban aplicarse a cualquier tabla. Comprueba las relaciones reales y ensaya la lectura de celdas centrales, bordes y grupos, no solo la primera fila.
06. El móvil no debe borrar las relaciones
Reducir el tamaño de letra hasta que todo quepa en un teléfono convierte una tabla en una imagen difícil de leer. Ocultar columnas sin ofrecer acceso a sus datos tampoco resuelve el problema. El diseño adaptable debe mantener disponible la información necesaria para comparar y decidir, también cuando se utiliza ampliación.
Una región con desplazamiento horizontal puede ser una solución razonable para datos que necesitan dos dimensiones. Debe poder manejarse con teclado cuando sea necesario y ofrecer una indicación comprensible de que existe más contenido. Si transformas filas en tarjetas, conserva etiquetas y significado en el DOM. Comprueba que el cambio visual no elimina la semántica ni obliga a deducir las relaciones.
07. Color, abreviaturas y celdas vacías
Una celda verde no comunica por sí sola «disponible», igual que una celda roja no explica «sin plazas». Añade texto o una alternativa comprensible y comprueba el contraste de letras, controles e indicadores relevantes. Las franjas alternas pueden ayudar a seguir filas, pero no deben ser la única forma de localizar una relación.
Define las abreviaturas que no sean evidentes y expresa las unidades de manera consistente. Distingue entre cero, dato desconocido y servicio no disponible: no significan lo mismo. Una celda vacía puede resultar ambigua tanto visualmente como al escucharla. Una decisión editorial sencilla, como escribir «Sin datos», evita interpretar un silencio como un valor o un fallo de lectura.
08. Ordenación y filtros que se puedan utilizar
Cuando un encabezado permite ordenar, la acción debe ofrecerse mediante un control operable con teclado y con nombre claro. El estado de ordenación debe comunicarse de manera programática cuando corresponda; aria-sort puede expresar ese estado en el encabezado adecuado. Un pequeño triángulo visual no basta para explicar qué columna ordena los resultados.
Después de filtrar, conserva un recorrido de foco previsible e informa del resultado cuando proceda sin generar anuncios constantes. Prueba también el caso sin coincidencias y la restauración del filtro. No conviertas una tabla informativa en una cuadrícula interactiva con navegación especial salvo que el componente realmente lo necesite y su comportamiento esté diseñado y probado.
09. Comprueba tareas, no solo etiquetas
Elige una pregunta verificable: «¿A qué hora atiende soporte el martes?». Resuélvela primero visualmente y después con un lector de pantalla, usando sus comandos de navegación por tablas. La comprobación útil no es escuchar que existe una tabla, sino identificar correctamente el dato y sus encabezados sin perder el contexto.
Repite la tarea con ampliación y una ventana estrecha. Usa teclado para los botones, filtros y regiones desplazables que lo requieran. Las celdas de una tabla estática no necesitan convertirse todas en paradas de Tab. Registra qué combinación de navegador y tecnología de apoyo probaste, qué ocurrió y qué respuesta correcta debería poder obtener una persona.
10. Qué aportan las herramientas y las WCAG
Una herramienta automática puede señalar determinados problemas de estructura, pero no decide si un encabezado describe bien los datos o si dividir una tabla facilitaría una comparación. Tampoco valida por sí sola todos los estados de un filtro. Combina sus avisos con inspección del código, revisión editorial y tareas manuales.
En WCAG 2.2, el criterio 1.3.1, Información y relaciones, es especialmente pertinente para la estructura tabular. Según el componente, también pueden intervenir teclado, contraste, reajuste del contenido y mensajes de estado. La excepción de reajuste para contenido que necesita dos dimensiones no convierte toda la página en una excepción. Evalúa cada requisito aplicable sin presentar una receta como garantía de conformidad.
11. Corregir en WordPress y Divi desde el origen
Revisa qué HTML genera el módulo o plugin de tablas después de guardar la entrada. Un editor puede mostrar una primera fila destacada y publicar solo celdas td. Copiar desde una hoja de cálculo también puede introducir estilos o combinaciones innecesarias. La revisión debe hacerse sobre el resultado real, no únicamente dentro del constructor.
Si el mismo defecto aparece en muchas entradas, corrige el componente o la plantilla compartida y documenta una pauta editorial. Un overlay no puede deducir de manera fiable si una cifra es precio, plazo o porcentaje, ni decidir qué comparación necesita el visitante. Los ajustes de apariencia pueden ser complementarios, pero la relación entre encabezados y datos debe resolverse en el contenido original.
12. Una publicación que siga siendo comprensible mañana
Antes de publicar, confirma título, unidades, encabezados, asociaciones y comportamiento en pantalla estrecha. Añade una prueba concreta a la revisión editorial y repítela cuando cambien los datos o el plugin. Una tabla correcta puede deteriorarse al insertar una columna, combinar dos celdas o sustituir etiquetas por iconos.
Incluye a personas que utilicen tecnologías de apoyo cuando sea posible y atiende a sus dificultades reales. La mejor tabla no es la que acumula más atributos, sino la que permite consultar y comparar sin reconstruir mentalmente su estructura. La accesibilidad se demuestra cuando la persona encuentra el dato correcto, entiende qué significa y puede utilizarlo para tomar su propia decisión.