¿Puede crear una tabla adaptable con columnas variables en móvil?

Sí. Una tabla adaptable puede admitir columnas variables, una zona con desplazamiento horizontal, encabezados fijos en listas largas y una vista móvil sin crear un componente por cada ancho. Conserva un contrato de datos e interacción y elige pocos comportamientos según la tarea. Mantén una tabla real cuando se comparen valores entre filas o columnas; apila registros con etiquetas cuando cada fila sea una ficha breve; lleva campos secundarios a una vista de detalle cuando resten espacio a la decisión. Son presentaciones de un mismo modelo, no variantes inconexas.

Antes de dibujar puntos de corte, pregunta qué hay que comparar, qué debe seguir visible al desplazarse y qué detalle puede esperar hasta abrir un registro. Así el componente funciona en escritorio, móvil, con zoom y en ventanas estrechas.

Elige el comportamiento adaptable según la tarea

Una tabla es útil cuando las relaciones entre filas y columnas facilitan revisar o comparar información. Empieza por la tarea, no por el dispositivo. Si alguien de soporte compara responsables, prioridades y actualizaciones de varios casos, la tabla conserva esas relaciones. Si se consulta un registro de cliente cada vez, apilar filas puede facilitar la lectura de etiquetas y valores. Si los campos de auditoría rara vez afectan la decisión, una página o panel de detalle será más claro.

Haz un inventario: identifica la entidad de cada fila, la decisión que facilita la pantalla, los campos necesarios y los opcionales. Señala qué columnas se comparan entre registros. Una tabla de clientes puede necesitar estado, renovación e importe para una revisión financiera; en un directorio móvil quizá basten nombre, cargo y acción de contacto. Una columna de escritorio no tiene que permanecer solo porque exista en el modelo de datos.

La guía de reflow de W3C reconoce que las tablas pueden requerir una presentación bidimensional, mientras que el contenido alrededor debe adaptarse. Su ejemplo de colocar la tabla en un contenedor desplazable limita esa excepción al componente y evita que toda la página se mueva en horizontal. El criterio evalúa el contenido vertical a 320 píxeles CSS, salvo cuando la relación bidimensional sea necesaria; no exige convertir toda tabla en tarjetas.

Usa el diagrama como primera decisión y luego comprueba la tarea con datos representativos. Pide a alguien que encuentre un registro, compare dos valores y ejecute la acción principal. Si esas tareas compiten, ofrece un modo claro o una vista de detalle en lugar de comprimirlo todo.

Haz que la tabla se desplace dentro de su propio marco

El desplazamiento horizontal contenido suele ser la opción más fiel para datos densos. Pon la tabla en un contenedor que pueda desplazarse lateralmente, mantén la página dentro de la vista y deja que las columnas determinen el ancho. Así se conserva la alineación y la comparación entre filas. USWDS recomienda una variante desplazable para tablas densas con muchas columnas y la distingue de las tablas con mucho texto que pueden apilarse.

Haz visible que hay más contenido. Un borde recortado, un degradado sutil o el aviso «Desliza la tabla en horizontal» pueden indicarlo. Conserva una primera columna significativa cuando sea posible: nombre, fecha o identificador ayuda a reconocer la fila al moverse lateralmente. Evita que la primera vista sea un conjunto de métricas sin etiquetas. Si la tabla está dentro de otra zona desplazable, comprueba que el movimiento vertical y horizontal sea previsible.

No fijes el ancho de toda la página para conservar la cuadrícula de escritorio. El contenedor de la tabla puede desbordarse en horizontal mientras títulos, acciones, filtros y explicaciones se adaptan. Esto importa con el zoom y las ventanas estrechas, además del móvil. W3C explica que la relación entre encabezados de filas y columnas puede hacer necesaria una tabla bidimensional; la excepción no incluye el texto ajeno a ella.

La paginación y las acciones en lote necesitan su propio diseño móvil. Mantén los controles cerca de los datos que afectan, indica el rango actual y facilita llegar a la acción siguiente. Si hay muchas páginas, una búsqueda o unos pocos filtros pueden ayudar más a encontrar registros. No hagas que toda la barra de herramientas se desplace porque la tabla lo haga.

Usa una tabla real para descubrir la presión del contenido

Antes de diseñar variantes, añade valores, estados y acciones realistas. El texto de relleno como «Elemento» esconde los problemas que hacen saltar encabezados de línea, ensanchan columnas o chocan con controles. Un buen ejemplo incluye un nombre corto y otro largo, un estado de varias palabras, un icono opcional, una acción por fila y suficientes columnas para probar el ancho móvil.

Apila registros descriptivos con etiquetas explícitas

Apilar funciona cuando cada fila es un registro breve y se consulta uno cada vez. En una vista estrecha, cada fila puede convertirse en tarjeta o bloque: las etiquetas permanecen visibles, aparecen junto a los valores y las acciones ocupan una posición coherente. La guía de USWDS es concreta: cada celda de su variante apilada necesita un data-label que coincida con el encabezado. Esa etiqueta es parte del contrato de contenido, no un adorno que se quite al cambiar el CSS.

No elijas tarjetas solo porque parezcan actuales. Una tarjeta por fila puede dificultar la comparación, porque el valor de un registro deja de alinearse con el siguiente; también aumenta el desplazamiento vertical. Para nombres y descripciones puede funcionar, pero para comparar planes, inventario u horarios quizá convenga conservar las columnas. Evalúa ambas opciones con la misma tarea.

Prueba la vista apilada con etiquetas largas, valores ausentes, distintivos, enlaces y acciones. Las etiquetas deben seguir junto a sus valores; nadie debería deducir que un chip verde significa «Estado» porque desapareció el encabezado. Si reordenas campos, conserva un orden de lectura previsible y no alejes la acción del dato al que afecta.

Algunas tablas tienen columnas agrupadas o encabezados complejos. Convertirlas en tarjetas puede borrar relaciones. Conserva la tabla semántica y ofrece una vista de registro etiquetada cuando la alternativa aplane la estructura. El tutorial de W3C explica cómo se relacionan encabezados y celdas y cuándo una tabla compleja necesita asociaciones como scope, id y headers. Puede cambiar la presentación, pero la información debe seguir siendo comprensible.

Conserva las columnas esenciales y reubica el resto con criterio

Clasifica los campos antes de ocultarlos. «Esencial» significa necesario para identificar una fila o tomar la decisión principal. «Opcional» significa útil en algunos contextos, pero prescindible en la vista estrecha si sigue accesible. «Detalle» significa que pertenece a una página, fila expandida o panel. Ocultar una columna no adapta la interfaz si la información desaparece.

Para cada ancho, define columnas visibles, anchos mínimos y orden. Deja que el texto largo se ajuste antes de comprimir todos los campos. Los números pueden alinearse a la derecha y mantener cifras estables; etiquetas y descripciones necesitan espacio para partirse. Usa un tratamiento uniforme para el valor vacío, para que no parezca un error de renderizado.

Los controles para elegir columnas pueden ayudar a equipos con tareas distintas, pero añaden estado y decisiones. Empieza con una vista útil y pocos campos opcionales con nombres claros. Conserva la selección entre pantallas solo si el producto lo explica. No crees una variante por cada combinación: trata la visibilidad como dato o preferencia cuando corresponda y mantén una jerarquía visual común.

Si un campo se oculta al llegar a cierto ancho, documenta la regla y comprueba que pueda consultarse. La acción debe llamarse «Ver detalles del registro», no depender de un icono sin etiqueta. Debe poder usarse con teclado y mostrar allí el mismo contenido. Carbon recomienda espacio para evitar truncar valores y trata la expansión como forma de mostrar información complementaria. Si truncas, ofrece un modo accesible de leer el valor completo.

Diseña con cuidado los encabezados fijos y las columnas inmovilizadas

Un encabezado fijo ayuda a conservar las etiquetas al recorrer una tabla larga. Úsalo cuando haya muchas filas y se necesite consultar los títulos. Mantenlo dentro del contexto de desplazamiento de la tabla, ten en cuenta la navegación fija del sitio y comprueba que no tape la fila que se lee o enfoca. Inmovilizar columnas cuesta más: fijar la primera puede conservar la identidad de la fila al moverse lateralmente, pero añade capas, sombras y riesgo de solapamiento.

Antes de fijar una columna, comprueba si aporta contexto suficiente y deja espacio para leer la siguiente. Si tapa información o hace que la tabla parezca más ancha, elimínala o utiliza una acción de detalle. Estos comportamientos pueden entrar en conflicto: USWDS indica que su variante con encabezado fijo no es compatible con las variantes desplazables ni apiladas. Combinaciones que parecen sencillas en Figma quizá necesiten rutas distintas de código o no estén soportadas. Decide qué combinación necesitas, pruébala en el navegador real y documenta sus límites. No prometas «fijado en todos los casos» sin comprobar desplazamiento anidado, tacto, foco y zoom.

En una lista moderada, un encabezado normal puede ser más sencillo. Prioriza una lectura estable y, si la gente necesita buscar o filtrar, mejora primero esos controles.

Mantén claras la ordenación y las acciones por fila

La ordenación debe comunicar la acción y el resultado actual. Usa un control manejable con teclado en el encabezado, dale un nombre accesible breve y expón la dirección activa. La guía de WAI recomienda encabezados semánticos y relaciones claras con los datos. Un icono no basta si la dirección o el estado dependen solo del color.

La selección, edición y varios controles en celdas pueden convertir una tabla estática en una cuadrícula interactiva. El patrón grid de WAI-ARIA es un contrato de teclado importante: es un widget compuesto, administra el foco y define navegación con flechas. Puede servir para edición tipo hoja de cálculo, pero añadir role=grid no mejora por sí solo la accesibilidad. Si solo hay que abrir enlaces o botones, una tabla semántica con tabulación normal puede ser más sencilla.

Haz identificables las acciones con tacto y teclado. No dependas de menús que solo aparecen al pasar el ratón; ofrece un disparador visible o foco claro. El menú necesita nombre accesible, entrada lógica del foco y forma de cerrarse o devolverlo. En móvil, «Más opciones» puede ser más claro que un icono diminuto de tres puntos. Después de ordenar, filtrar o cargar filas, comunica cambios asíncronos, conserva el foco al editar o eliminar y explica los resultados vacíos con un siguiente paso. La adaptación incluye carga, vacío, filtrado, selección y error.

Crea un contrato de componente y prueba los anchos reales

Escribe el contrato antes de construir variantes. Define modelo de datos, campos obligatorios y opcionales, semántica de encabezados, orden inicial, selección, acciones, estados de carga y vacío y el comportamiento adaptable para cada contenido. Describe los puntos de corte según el espacio y la tarea, no como «iPhone» o «tablet». GOV.UK también recomienda diseñar para distintos tamaños sin asumir un dispositivo y empezar por una sola columna en pantallas pequeñas.

Prepara datos representativos: un valor largo, otro vacío, un estado, una descripción multilínea, una columna numérica y suficientes filas. Revisa escritorio, una ventana dividida, 320 píxeles CSS o un caso equivalente de zoom y un dispositivo táctil. Comprueba el desplazamiento horizontal de tabla y vertical de página, la visibilidad del foco, el anuncio de encabezados por lector de pantalla, el zoom, los saltos de texto y el acceso a la acción principal.

Registra navegador y tecnología de asistencia probados. Una captura no demuestra teclado ni relaciones semánticas. Las pruebas automáticas detectan problemas de marcado, pero no deciden si apilar perjudica la comparación o si un encabezado tapa el foco. Observa a alguien buscar, comparar y actualizar datos para descubrir dónde pierde contexto.

EmviUI puede aportar una base visual. Su componente de tabla ofrece celdas y variantes adaptables; la guía sobre UI kits y sistemas de diseño explica por qué un kit es solo una capa de un sistema mantenido. Usa el ejemplo para alinear jerarquía, densidad y acciones. Tu equipo sigue siendo responsable del HTML semántico, el comportamiento de datos, el código adaptable y las pruebas de accesibilidad. Un componente de Figma describe la interfaz; no demuestra que la tabla publicada funcione.

En el traspaso, indica qué columnas permanecen visibles, qué zona se desplaza y qué campos pasan al detalle. Las guías de traspaso adaptable de Figma a Tailwind y diseño web adaptable en Figma ayudan a comunicarlo entre diseño y código. Conserva un componente con pocos comportamientos deliberados y revisa su contrato cuando cambien tareas o datos.

En resumen: conserva la tabla para comparar, limita el desplazamiento a su contenedor, apila solo registros descriptivos con etiquetas repetidas y lleva los datos secundarios a una vista de detalle. Pruébala con contenido realista, teclado, zoom y tecnologías de asistencia.

Fuentes primarias: reflow de W3C; tutorial W3C de tablas; tabla de USWDS; tabla de GOV.UK; patrón grid de WAI-ARIA; guía de Carbon.