Tables (web)

Las tablas de datos deben construirse con los elementos nativos: <table>, <thead>, <tbody>, <th>, <td> y <caption>. El atributo scope en cada <th> declara si el encabezado aplica a una columna (col) o a una fila (row), permitiendo que el lector de pantalla anuncie el contexto correcto al navegar celda por celda. El <caption> identifica el tema de la tabla y es útil en casi cualquier situación. Una rejilla de <div> con apariencia de tabla pierde por completo la relación programática entre encabezados y datos, lo que viola WCAG 1.3.1 (Info and Relationships) y deja la tabla inutilizable para tecnología asistiva.

Cada columna se alinea según la naturaleza de su contenido. El texto y los identificadores (nombres, fechas, códigos, teléfonos) van a la izquierda, porque el ojo occidental está habituado a leer desde ese borde. Las cantidades y porcentajes comparables van a la derecha para que el dígito de mayor peso quede alineado entre filas y la magnitud se compare de un vistazo. El encabezado sigue la alineación de su columna. Además, las columnas numéricas requieren font-variant-numeric: tabular-nums para que cada dígito ocupe el mismo ancho: sin él, una cifra proporcional desplaza los decimales al actualizar y rompe la rejilla vertical de la comparación.

No existe un separador universalmente óptimo: la elección responde al tamaño del dataset y al número de estados interactivos. Las líneas horizontales de 1px gris claro son el patrón más versátil y funcionan para cualquier tamaño. El zebra striping aporta a lo sumo una mejora marginal de precisión en datasets muy largos, pero introduce ruido cuando la tabla ya tiene varios estados (hover, seleccionado, deshabilitado): apilar zebra sobre tres estados semánticos crea hasta cinco fondos en conflicto y rompe la continuidad visual. Sin separador solo en datasets pequeños donde el espaciado tipográfico ya orienta la lectura. Importante: cambiar display en filas o celdas para lograr el efecto rompe la semántica de tabla en la mayoría de navegadores; el zebra debe lograrse con background, nunca con cambios de display.

En tablas que superan la altura del viewport, el encabezado debe permanecer visible durante el scroll vertical para que el usuario nunca pierda el contexto de cada columna. El patrón accesible coloca position: sticky; top: 0 en los thead th dentro de un contenedor con overflow-y: auto y altura fija. Es obligatorio añadir tabindex="0" al contenedor para que usuarios de teclado puedan recorrer el área scrollable, con un indicador de foco visible. El antipatrón a evitar es partir el contenido en dos tablas separadas (una para el header fijo, otra para el body con scroll): eso rompe el enlace programático entre encabezado y datos y deja la tabla inservible para lectores de pantalla.

Las columnas ordenables usan un <button> dentro del <th> para que la acción sea activable por teclado, y el <th> lleva aria-sort con el valor activo (ascending, descending o none). Solo un encabezado puede tener aria-sort distinto de none al mismo tiempo; tener dos columnas marcadas como ordenadas confunde a la tecnología asistiva. El indicador visual (flecha o chevron) debe cambiar de forma o relleno, no solo de color: una flecha que pasa de contorno hueco a triángulo relleno comunica el orden a usuarios con daltonismo, cumpliendo WCAG 1.4.1 (Use of Color). Una columna ordenada sin señal programática falla WCAG 4.1.2 (Name, Role, Value).

La altura de fila y el padding determinan cuántos datos caben en pantalla y qué tan cómoda es la lectura. El sistema de IBM Carbon define una escala de densidades confirmada: compact 32px, medium 40px, default 48px y tall 64px (más un nivel condensed de 24px para datos extremos). Compact y medium sirven a herramientas internas con mucha información; default es el uso general; tall facilita lecturas prolongadas o audiencias no técnicas. El padding horizontal mínimo es de 16px por lado, de modo que el espacio entre columnas sume al menos 32px y las celdas nunca se toquen. Ofrecer un selector de densidad y persistir la elección del usuario es práctica recomendada en herramientas enterprise.

En viewports estrechos la estrategia preferida es el scroll horizontal, porque mantiene intacta la semántica de tabla. Se envuelve la <table> en un <div role="region" aria-labelledby="..." tabindex="0"> para que el área scrollable sea anunciada y navegable por teclado, y la primera columna (el identificador) se fija con position: sticky; left: 0 con el background aplicado a nivel de celda. El antipatrón crítico es cambiar el display de la tabla o de las celdas a block o flex para apilarlas: en cuanto se hace eso, la mayoría de los lectores de pantalla dejan de tratarlo como tabla y se pierde toda la asociación encabezado-dato. Si se colapsa a tarjetas, hay que reponer las etiquetas con td::before { content: attr(data-label) }.

Cuando una celda de datos se relaciona con más de un encabezado (encabezados de fila y de columna que se cruzan, o subgrupos con un segundo nivel), el atributo scope bidireccional no basta. En ese caso cada <th> recibe un id único y cada <td> lista los ids de todos sus encabezados en headers="id1 id2 id3", separados por espacios. Para tablas con subgrupos de filas o columnas, los encabezados de grupo usan scope="rowgroup" o scope="colgroup". La recomendación de la W3C es que, si la tabla es genuinamente compleja, conviene a todos dividirla en tablas simples separadas con un encabezado descriptivo: es más fácil de entender y de codificar. Sin id+headers en tablas multinivel, la relación encabezado-celda no es determinable programáticamente y WCAG 1.3.1 falla.