Tipografía fluida y WCAG 1.4.4: la prueba del zoom
La tipografía fluida puede cumplir la WCAG 1.4.4 (Redimensionar el texto), y que lo haga o no lo decide la aritmética dentro del clamp: los términos en rem responden al zoom y a las preferencias de tamaño de fuente, el término en vw no. Cuanto mayor sea la proporción en rem de un tamaño fluido, más cerca llega el texto de un 200% real cuando la persona hace zoom al 200%. Una transición suave como 16→18px está impulsada en un 90% aproximadamente por rem y hace zoom de forma casi proporcional; una transición pronunciada desplaza el peso hacia el término del viewport y degrada de forma silenciosa la respuesta al zoom.
Ese reparto —cuánto de un tamaño vive en rem frente a vw— es el tema de esta guía. Es el análisis a fondo sobre accesibilidad de nuestra guía de tipografía fluida: el modo de fallo específico de la tipografía fluida, los números de accesibilidad del clamp que lo deciden y un protocolo de prueba que puedes ejecutar en diez minutos.
¿Qué exige la WCAG 1.4.4?
El Criterio de éxito 1.4.4, Redimensionar el texto exige que el texto pueda redimensionarse hasta el 200 por ciento sin pérdida de contenido ni de funcionalidad. Importan dos mecanismos de la persona usuaria, y son distintos: el zoom de página completa, que escala el propio píxel CSS, y la preferencia de tamaño de fuente del navegador, que cambia el tamaño por defecto al que hacen referencia las unidades rem. Un sistema robusto responde a ambos. El texto en unidades de viewport puras no responde a ninguno, lo que convierte a la tipografía fluida descuidada en una de las pocas técnicas modernas que pueden incumplir este criterio por completo.
¿Por qué el zoom del navegador no alcanza el término en vw?
El zoom funciona escalando el píxel CSS: al 200% de zoom, un píxel CSS se corresponde con dos píxeles de dispositivo. Por tanto, todo lo declarado en px o rem se duplica físicamente. Pero ahora el viewport tiene la mitad de píxeles CSS de ancho —una ventana de 800 píxeles de dispositivo de ancho se convierte en un viewport de 400 píxeles CSS— y vw se define en relación con ese viewport. Los dos efectos se cancelan: 1vw son 8 píxeles de dispositivo antes del zoom (1% de 800) y 8 píxeles de dispositivo después (1% de 400, cada uno con un valor de dos). Con zoom o sin él, un tamaño en vw puro se renderiza al mismo tamaño físico. El texto es sordo al zoom.
Un clamp fluido mezcla ambos tipos de término, así que responde de forma parcial, y «parcialmente» se puede calcular.
¿Cuánta respuesta al zoom conserva un clamp?
Toma el clamp de la raíz para una transición 16→18px a lo largo de los viewports 360→1280:
font-size: clamp(1rem, 0.9511rem + 0.2174vw, 1.125rem);
En una ventana de 800px de ancho, el valor preferido es ≈15,22px del término en rem más ≈1,74px del término en vw: ≈16,96px en total, repartido aproximadamente 90/10 a favor de rem.
Ahora haz zoom al 200%. La parte en rem se duplica a ≈30,43px de tamaño físico; la parte en vw se queda en ≈1,74px. Total: ≈32,17px, alrededor del 190% del original. Un poco por debajo de lo proporcional, y la parte que falta es exactamente la parte en vw. En la práctica esto pasa la prueba: el texto responde con fuerza, y un 200% real llega un paso más adelante en la escala de zoom, dentro de lo que ofrecen los navegadores.
Compara un clamp hipotético más pronunciado —clamp(0.75rem, 0.5rem + 1vw, 2rem)—
que en la misma ventana de 800px es 8px de rem y 8px de vw, un reparto 50/50. Al
200% de zoom alcanza 24 píxeles de dispositivo: el 150% de su tamaño original.
Para que su usuario duplique de verdad el texto, tiene que hacer zoom al 300%.
Eso incumple la intención del criterio, y las auditorías suelen marcarlo.
La regla general se desprende de la aritmética: cuanto más pronunciada es la pendiente, más parte del tamaño vive en vw, y peor es la respuesta al zoom. La pendiente no es solo una decisión de diseño sobre la rapidez con la que crece el texto entre pantallas: es una decisión de accesibilidad sobre cuánto del texto puede alcanzar el zoom.
Una consecuencia más que conviene conocer: los límites del clamp son salvaguardas de accesibilidad. A medida que la persona hace zoom, el viewport CSS se encoge, el valor preferido baja y, en algún momento, el límite mínimo toma el control: pasado aproximadamente el 220% de zoom en el ejemplo de 800px. A partir de ahí el tamaño es rem puro y la respuesta es totalmente proporcional. Las zonas planas de un clamp son su territorio más seguro.
Abre este clamp de la raíz en Scale Composer: el modo fluido guarda los cuatro números que hay detrás (base 16→18, viewports 360→1280), la exportación de CSS escribe el clamp con su rango en píxeles comentado, y la exportación DTCG lleva los mismos cuatro parámetros, así que la aritmética anterior es reproducible.

¿Cómo se prueba la tipografía fluida para el redimensionado?
Tres comprobaciones, en orden de lo que detectan:
- Haz zoom al 200%. El texto del cuerpo debería renderizarse a casi el doble de su tamaño físico. Si se queda visiblemente corto —crece un poco y luego se estanca— la proporción en vw es demasiado alta en algún punto.
- Configura la preferencia de tamaño de fuente del navegador en Grande. El texto fluido basado en rem crece; el texto anclado en px y en vw ignora por completo el ajuste. Esto detecta un fallo distinto al del zoom, así que no es redundante.
- Comprueba en vp-min, vp-max y rango medio. Por debajo del mínimo y por encima del máximo el clamp es plano —rem puro, las zonas más seguras—. El rango medio es donde el término en vw carga con su mayor proporción, así que ejecuta la comprobación de zoom de la tipografía fluida en un ancho de rango medio, no solo en un cómodo tamaño de escritorio.
¿Por qué un clamp de raíz facilita la auditoría?
Un sistema fluido por elemento te da docenas de clamps, cada uno con su propia pendiente y su propio reparto rem/vw: docenas de lugares donde una pendiente pronunciada puede esconderse. La arquitectura de clamp de raíz invierte eso: un solo clamp en el tamaño de fuente de la raíz, y todo lo demás en rem montado sobre él. El comportamiento de zoom de todo el sistema es el comportamiento de zoom de una sola expresión, verificado una vez.
Y una transición base suave se comporta bien por construcción: 16→18 sobre 360→1280 pone alrededor del 90% del tamaño en el término en rem en anchos de rango medio. El drama a nivel de sistema —cuánto llega a crecer un h1— vive en la razón de la escala tipográfica, multiplicada por encima en rem seguro para el zoom, no en la pendiente de la transición.
Haz los cálculos en una transición más pronunciada
La conexión entre pendiente y accesibilidad es más fácil de creer cuando la calculas tú: abre una transición base más pronunciada en Scale Composer —16→24 a lo largo del mismo rango de viewports— y rehaz la aritmética de los 800px a partir de su exportación. La proporción en rem baja a ≈65%, y ahora el zoom al 200% da ≈165%. En algún punto entre esa transición y la suave está la respuesta de tu propio sistema, y los rangos comentados de la exportación te dan cada número que necesitas para encontrarla.