Density / Compact Mode

El modo compacto reduce ruido y aumenta la información visible por pantalla, un beneficio real solo para power-users que escanean filas en tablas, dashboards y paneles de recursos. En apps de consumo (correo, feeds, onboarding) la densidad reducida perjudica la legibilidad y abruma al usuario casual. La densidad predeterminada debe ser siempre la más cómoda; el modo compacto es una opción que el usuario activa deliberadamente, no el punto de partida. AWS Cloudscape lo afirma sin matices: el modo cómodo se fija como default en todas las aplicaciones porque el compacto puede dificultar la lectura y prolongar el consumo de contenido.

Los sistemas de diseño maduros definen una escala nominal con alturas de fila exactas en px: tener niveles nominados facilita la comunicación entre diseño, ingeniería y QA, y permite que distintos componentes de un mismo dashboard coexistan en el nivel correcto. IBM Carbon define Compact 24px · Short 32px · Default 48px · Tall 64px (v11 agrega Medium 40px). Material Design parte de densidad 0 (default) y baja a -1, -2, -3; cada incremento reduce la altura del componente en 4dp mediante la fórmula height = base + (interval × scale). Un checkbox "modo compacto" que cambia un padding arbitrario sin documentar la altura resultante conduce a implementaciones inconsistentes.

La densidad se logra reduciendo el padding interno de la celda (arriba/abajo) y los márgenes entre componentes, no achicando la fuente ni el line-height. Reducir el tipo arruina la legibilidad; comprimir el interlineado por debajo de 1.5× hace que usuarios con dislexia o baja visión pierdan el hilo de lectura. WCAG 1.4.12 (AA) exige que el contenido no pierda funcionalidad cuando el usuario ajusta line-height hasta 1.5× el tamaño de fuente, letter-spacing a 0.12em y word-spacing a 0.16em: una tabla que ya comprimió el interlineado a 1.0 para "caber más filas" no sobrevive ese ajuste. El texto en compacto debe tener idéntico tamaño y espaciado de línea que en cómodo; solo cae el padding vertical, de 12px a 2px.

WCAG 2.5.8 (AA, WCAG 2.2) establece que todo target interactivo debe medir mínimo 24×24 CSS px, o tener 24px de separación edge-to-edge respecto a targets adyacentes. En touch, una fila de tabla de 24px viola el criterio si la acción de fila (selección, expansión) es el único target. SAP Fiori documenta explícitamente que cozy (táctil) usa 2.75rem = 44px y compact (ratón) usa 2rem = 32px; aplicar compact en touch no es solo mal UX, es un error de diseño. El nivel Compact 24px de Carbon nunca debe ser el default en táctil. La solución es detectar la capacidad de puntero: pointer: coarse fuerza cómodo (44px), pointer: fine habilita compacto.

La elección de densidad es una preferencia de trabajo personal: un analista que prefiere compacto no quiere reactivarlo cada vez que recarga la app. No persistir este estado es como olvidar el zoom favorito del usuario en cada sesión. La preferencia debe guardarse como mínimo en localStorage y, si la app tiene sesión autenticada, sincronizarse con el perfil del usuario en el backend para conservarse entre dispositivos. La inicialización debe ocurrir en el mount antes del primer render para evitar el flash de densidad incorrecta. Los usuarios reportan frustración activa cuando la densidad no persiste: el hilo "Density will not stay in comfortable" de Gmail acumula decenas de respuestas.

Un dashboard en modo compacto debe tener compactos todos sus componentes relacionados: tabla, encabezado de columnas, toolbar, paginación, filtros y badges de conteo. Mezclar un header cómodo con filas compactas produce inconsistencia visual y confunde la jerarquía de información. SAP Fiori prohíbe explícitamente combinar cozy y compact en la misma página o jerarquía, y recomienda fijar el factor de densidad a nivel de aplicación. IBM Carbon es categórico: la fila del header de columnas siempre debe coincidir con la altura de fila de la tabla. La excepción son componentes que por naturaleza no se densifican (alerts, formularios, paneles de ayuda), no piezas de la misma tabla.

Un control que el usuario no encuentra no aporta valor: el toggle de densidad va en la toolbar de la tabla o en un panel de configuración accesible, no enterrado en settings globales. Como control interactivo requiere nombre accesible (label visible o aria-label), indicación del estado actual con aria-pressed, y operación con teclado (Enter/Space y flechas en un grupo de botones). WCAG 4.1.2 exige que nombre, rol y estado sean programáticamente determinables: un toggle sin aria-pressed es invisible para tecnologías de asistencia. WCAG 1.4.1 prohíbe comunicar el estado activo solo con color; el seleccionado necesita un indicador visual adicional como un checkmark, no únicamente un fondo distinto.

La densidad y el dispositivo de entrada están íntimamente ligados: compacto tiene sentido con ratón (puntero preciso, hover disponible, sin riesgo de tap erróneo); en touch el margen de error táctil promedio supera los 10px, haciendo que filas de 24–32px sean propensas a errores de selección. Implementa detección de capacidad de puntero con CSS @media (pointer: coarse) o JS matchMedia para fuerza cómodo en táctil (min 44px, alineado con WCAG 2.5.5 AAA), deshabilitar o limitar el toggle de densidad en touch, y restaurar el toggle completo en desktop con pointer: fine. El piso absoluto de WCAG 2.5.8 (24px) no es el objetivo de diseño en touch, solo el mínimo legal.