Sistemas de Diseño Accesibles: CSS Moderno y WordPress FSE

Domina Full Site Editing con CSS moderno. Crea temas accesibles (WCAG 2.2) usando Container Queries, Nesting y tipografía fluida en theme.json.

La web nunca fue diseñada para ser un lienzo estático, aunque pasamos la última década intentando forzarla para que lo fuera. Durante años, la accesibilidad se trató como una capa de barniz final, un ítem en una lista de verificación que se revisaba —con suerte— dos días antes del lanzamiento. Esa era ha terminado.

Con la madurez del Full Site Editing (FSE) en WordPress y la llegada triunfal de características CSS modernas como las Container Queries y el anidamiento nativo (Nesting), nos encontramos ante un cambio de paradigma. Ya no construimos "páginas"; construimos sistemas vivos y respirables. La accesibilidad, bajo los estrictos estándares WCAG 2.2, deja de ser una "característica" para convertirse en la estructura ósea del diseño. Si su sistema de diseño no es accesible por defecto, simplemente es un sistema roto.

Arquitectura Líquida: La Gobernanza Tipográfica en theme.json

El primer error que cometen los desarrolladores al migrar a temas de bloques es tratar el archivo theme.json como una simple hoja de estilos glorificada. No lo es. Es el documento de gobernanza de su sistema de diseño.

La accesibilidad visual comienza con la legibilidad, y en la web moderna, la legibilidad debe ser fluida. Atrás quedaron los días de definir puntos de ruptura (breakpoints) rígidos para el tamaño de la fuente. La implementación de tipografía fluida mediante clamp() directamente en el núcleo del tema asegura que el texto escale matemáticamente entre el contexto móvil y el escritorio, respetando siempre las preferencias de zoom del usuario.

Un sistema tipográfico robusto no es aquel que se ve igual en todos lados, sino el que se lee perfectamente en cualquier circunstancia.

En lugar de luchar con media queries infinitos, definimos la fluidez en la raíz. Al configurar fluid como true y establecer los límites en el theme.json, delegamos el cálculo matemático al motor de WordPress, garantizando que nunca tendremos un texto demasiado pequeño para ser legible ni tan grande que rompa la jerarquía visual.

{
  "settings": {
    "typography": {
      "fluid": true,
      "fontSizes": [
        {
          "size": "clamp(1.1rem, 2vw + 0.5rem, 1.5rem)",
          "slug": "medium",
          "name": "Medium"
        }
      ]
    }
  }
}

Este enfoque "set and forget" elimina el error humano en la edición de contenido y asegura que los encabezados mantengan su estructura semántica visual sin intervención manual.

El Fin del Viewport: Container Queries como Estándar de Inclusión

Durante quince años, el diseño responsivo fue sinónimo de @media (max-width: ...). Sin embargo, desde una perspectiva de accesibilidad y modularidad, las Media Queries son instrumentos contundentes y a menudo imprecisos. Ignoran el contexto inmediato del componente.

Aquí es donde las Container Queries redefinen las reglas del juego para la accesibilidad cognitiva y visual.

Imaginemos una tarjeta de "Llamada a la Acción" (CTA). En un diseño tradicional, esa tarjeta cambia su diseño basándose en el ancho de la pantalla del navegador. Pero, ¿qué pasa si esa tarjeta se coloca en una columna lateral estrecha en una pantalla de escritorio? Con media queries, se rompería o se vería aplastada, dificultando la lectura y la interacción.

Con Container Queries, el componente es autoconsciente. Sabe cuánto espacio tiene disponible y se adapta a él. Esto es vital para la accesibilidad porque permite que los elementos mantengan tamaños de objetivo táctil (touch targets) adecuados (mínimo 24x24px según WCAG 2.2 SC 2.5.8) independientemente de dónde se coloquen en el diseño.

Implementación Práctica en Bloques

Al desarrollar bloques personalizados o patrones, debemos dejar de pensar en la pantalla y empezar a pensar en el contenedor.

.wp-block-group.card-container {
  container-type: inline-size;
  container-name: card;
}

@container card (max-width: 400px) {
  .card-content {
    /* Layout vertical para espacios reducidos */
    flex-direction: column;
    gap: 1rem;
  }
  
  .card-button {
    /* Botones de ancho completo para facilitar el toque */
    width: 100%;
    padding: 1.5rem; 
  }
}

Este enfoque garantiza que, si un usuario con baja visión aumenta el zoom del navegador al 400%, el componente reaccione al espacio reducido y se reajuste a su versión "móvil" optimizada, manteniendo la funcionalidad intacta sin necesidad de scroll horizontal, cumpliendo con el criterio de Reflujo (Reflow) de WCAG.

Automatización Cromática y el Motor de Estilos

El modo oscuro no es una preferencia estética; es una necesidad de accesibilidad para usuarios con fotofobia o sensibilidades visuales. Sin embargo, gestionar el contraste de color (mínimo 4.5:1 para texto normal) en múltiples paletas suele ser una pesadilla de mantenimiento.

El Motor de Estilos de WordPress nos permite abstraer los valores de color en variables CSS semánticas. En lugar de asignar colores directos (#000000), asignamos intenciones (--wp--preset--color--foreground).

La estrategia experta aquí consiste en utilizar el theme.json para definir variaciones de estilo completas. Esto permite cambiar todo el esquema de colores del sitio manteniendo las relaciones de contraste pre-validadas. No se trata de inyectar CSS manual para el modo oscuro, sino de permitir que el sistema intercambie las variables en el :root.

Auditoría Invisible: Accesibilidad en el Flujo de Trabajo

El mayor avance no es técnico, sino procesal. Con el FSE, la interfaz de edición es una representación casi exacta del frontend (WYSIWYG real). Esto nos brinda una oportunidad única: la auditoría en tiempo real.

Ya no debemos esperar a que un auditor externo nos diga que nuestro contraste es pobre. Las herramientas modernas integradas en el ecosistema de bloques pueden alertar al editor de contenido si la combinación de colores de fondo y texto en un bloque específico no cumple con los estándares AA o AAA.

Implementar lógicas de validación visual dentro del editor (usando dispatch y select del data store de WordPress) permite bloquear o advertir sobre configuraciones inaccesibles antes de que se publique el contenido.

La accesibilidad no debe depender de la buena voluntad del editor, sino de las restricciones inteligentes del sistema.

Hacia una Web Intrínsecamente Inclusiva

Construir temas de bloques hoy en día requiere una mentalidad de ingeniero de sistemas. No estamos pintando píxeles; estamos definiendo reglas, restricciones y relaciones.

Al combinar la potencia de las Container Queries para el diseño adaptativo contextual, la fluidez matemática de las variables de fuente y la estructura de gobernanza del theme.json, logramos algo que hace años parecía imposible: un sitio web que es accesible por defecto, resistente al cambio y respetuoso con las necesidades de cada usuario.

El cumplimiento de WCAG 2.2 no se logra "arreglando" cosas al final. Se logra construyendo un sistema que, por su propia naturaleza, rechaza lo inaccesible.