Hermano estructural de “La especificidad de CSS no es tu mayor problema.”, misma distinción, capa diferente.
Disponible también en Inglés
El problema
Una tabla de comparación de productos se despliega en una página de comercio electrónico. Dos productos, una columna cada uno, una fila para cada especificación: peso, dimensiones, duración de batería, garantía. Está construida con CSS grid: un div contenedor, una fila de divs de encabezado y un bloque de divs de valores debajo. Grid gestiona la alineación. Las media queries la colapsan a una sola columna en dispositivos móviles. Se ve exactamente como una tabla porque, visualmente, lo es.
Tres revisiones independientes coinciden en el mismo trimestre. Una auditoría de accesibilidad la señala: un lector de pantalla anuncia «Duración de batería» y luego lee dos números seguidos, sin nada que vincule ningún número a un producto. Una revisión de datos estructurados la señala: un proceso de extracción automatizado, diseñado para incorporar fichas técnicas a un flujo de comparación, no puede determinar de forma consistente qué valor pertenece a qué columna. Una prueba puntual con un asistente de compras con IA señala un tercer problema: al preguntarle por el peso de un producto, responde con la cifra del otro producto.
Tres equipos, tres herramientas, tres tickets. Nadie nota que están describiendo el mismo defecto desde tres ángulos distintos, porque nadie examina el marcado debajo de grid.
Por qué existe el problema
El enfoque basado en grid existe por una razón real. El diseño con tablas históricamente ha presentado resistencia al diseño responsivo: colapsar una tabla de forma limpia en una pantalla estrecha, sin que JavaScript reordene las filas en tarjetas, nunca ha sido sencillo. Recurrir a divs y CSS grid en lugar de una etiqueta <table> resuelve ese problema con limpieza y, para gran cantidad de contenido, es la decisión correcta. Una cuadrícula de fotos no tiene una relación inherente entre sus celdas. Tampoco la tiene un diseño de tarjetas para un índice de blog. La posición es la única relación que esos diseños necesitan, y CSS grid la proporciona a la perfección.
El primer principio
Una ficha técnica es distinta. «Duración de batería», «Producto A» y «18 horas» no son tres datos independientes ubicados uno al lado del otro. Uno es una especificación, uno es un producto y otro es un valor; el propósito de la fila es la relación entre ellos. Esa relación tiene que residir en alguna parte. En la versión con grid, reside en un solo lugar: el orden en que los divs aparecen en el código fuente, combinado con la posición que CSS les asigna en pantalla. Nada en el marcado la declara. El navegador construye exactamente el DOM que se le entregó, y ese DOM no tiene el concepto de «esta celda pertenece a este encabezado», porque nada se lo indicó.
Demostración del principio
La etiqueta <table> fue creada para resolver exactamente esto. <th scope="col"> y <th scope="row"> no solo se ven como encabezados: le dicen al navegador, de forma explícita, qué celdas gobierna cada encabezado. Esa relación pasa a formar parte del árbol de accesibilidad, computable por cualquier consumidor que lo recorra, en lugar de reconstruirse a vista a partir de la posición de la columna:
<table>
<caption>Product specifications</caption>
<thead>
<tr>
<th scope="col">Specification</th>
<th scope="col">Product A</th>
<th scope="col">Product B</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Battery life</th>
<td>18 hours</td>
<td>14 hours</td>
</tr>
</tbody>
</table>
Enter fullscreen mode Exit fullscreen mode
/* Versión con Grid: resultado idéntico en pantalla, sin relación declarada */
.spec-row {
display: grid;
grid-template-columns: 1fr 1fr 1fr;
}
Enter fullscreen mode Exit fullscreen mode
Ambos renderizan las mismas tres columnas. Solo uno le indica a un consumidor qué valor corresponde a qué encabezado sin pedirle que lo infiera de la posición donde se ubican las cajas.
El punto de dolor
Ese es el defecto real detrás de los tres tickets. El árbol de accesibilidad no tenía elementos a partir de los cuales computar una relación, por lo que el lector de pantalla anunció la etiqueta y luego los valores, en secuencia, sin ningún vínculo entre ellos. La herramienta de extracción no tenía una relación declarada que leer, así que recurrió al orden del documento y a la posición de las columnas; lo cual funcionó, en su mayoría, hasta que un producto tuvo una especificación de la que el otro carecía, una celda vacía se colapsó y cada valor posterior en esa fila se desplazó en silencio una posición hacia la izquierda. El asistente de IA encontró la misma desalineación durante ese mismo caso límite y respondió con la cifra de la columna vecina. Tres herramientas, tres síntomas, una fila que nunca declaró su significado.
Nada de esto fue un fallo en el proceso de un equipo en particular. La revisión de accesibilidad tenía razón. La revisión de extracción tenía razón. La prueba de IA tenía razón. Cada una observaba la misma relación no declarada y encontraba una forma distinta en que se manifestaba su ausencia. Parchar cada síntoma por separado —un aria-label aquí, un data-attribute allá, un caso especial en el script de extracción para el escenario de la especificación faltante— habría producido tres arreglos acoplados a una estructura que aún no declaraba su significado. Notas desde el pase de este sábado reconstruye el mismo componente de comparación como una tabla adecuada con las relaciones de scope correspondientes, y luego ejecuta las mismas tres comprobaciones sobre él —lector de pantalla, proceso de extracción y consulta de IA— sin parches, sin casos especiales y sin columnas desplazadas que puedan malinterpretarse.
La lección más amplia
Es tentador concluir que un documento bien estructurado satisface a todo lector de forma automática. No es tan así. Un lector de pantalla, un rastreador de búsqueda y una herramienta basada en LLM son tres sistemas distintos con tres flujos de procesamiento diferentes, y ninguno está obligado a interpretar un documento de la forma en que el autor lo concibió. Lo que elimina una relación declarada es algo más acotado y más útil: elimina la falla específica derivada de que un consumidor tenga que adivinar algo que el documento fuente podría haber declarado de forma simple. No puedes controlar cómo decide cada sistema leer una página. Puedes controlar qué parte del significado de esa página depende de que un lector adivine correctamente.
Vale la pena preguntarse, la próxima vez que tres auditorías independientes regresen recomendando tres arreglos distintos para el mismo componente: si encontraron tres problemas, o una sola relación no declarada manifestándose como tres síntomas diferentes.