Para ajustar los márgenes, últimamente es habitual implementar valores variables entre un mínimo y un máximo con clamp().
Es una solución muy útil para el diseño responsive, pero al considerar la ampliación de la pantalla (zoom) como función de accesibilidad, existe un pequeño inconveniente.
Ejemplo habitual de clamp()
Por ejemplo, al ajustar un margen con clamp(), suele escribirse de la siguiente manera.
:root {
--clamp-base: 16;
--clamp-viewport-min: 375;
--clamp-viewport-max: 1440;
--spacing-lg-min: 24;
--spacing-lg-max: 48;
--spacing-lg-slope: calc(
(var(--spacing-lg-max) - var(--spacing-lg-min)) / (var(--clamp-viewport-max) - var(--clamp-viewport-min))
);
--spacing-lg-intersection: calc(
(var(--spacing-lg-max) - var(--clamp-viewport-max) * var(--spacing-lg-slope)) / var(--clamp-base)
);
--spacing-lg: clamp(
calc(var(--spacing-lg-min) / var(--clamp-base) * 1rem),
calc(var(--spacing-lg-intersection) * 1rem + 100 * var(--spacing-lg-slope) * 1vw),
calc(var(--spacing-lg-max) / var(--clamp-base) * 1rem)
);
}
Omitiré la explicación detallada:
- En smartphones, el tamaño es
--spacing-lg-min - En PC, el tamaño es
--spacing-lg-max - variable y con un escalado fluido en ese intervalo
y es un patrón muy práctico, ¿verdad?
¿Qué trampas hay en la accesibilidad?
El problema surge al intentar cumplir con el criterio de éxito 1.4.4 de WCAG 2.0, «Cambio de tamaño del texto».
Este criterio se definió originalmente con la intención de que el contenido siguiera siendo legible al ampliarse hasta un 200 % en un PC, antes de que los smartphones se generalizaran. Sin embargo, las mismas condiciones también se aplican a los navegadores de los smartphones.
En la práctica, al ampliar al 200 % en un smartphone, suelen producirse los siguientes problemas.
- Al ampliar el texto (zoom), los márgenes basados en la unidad
remtambién se amplían, lo que provoca que se agranden. - Como resultado, los márgenes que rodean el contenido principal se vuelven excesivamente amplios.
- En consecuencia, el área de visualización del contenido se reduce drásticamente, lo que puede provocar roturas de diseño y dificultar la lectura.
Note: Sin embargo, en la práctica, en los sitios gubernamentales extranjeros que están obligados a cumplir con WCAG, parece que tampoco se atiende mucho este punto. Probablemente, la relación coste-beneficio y el hecho de que casi nadie necesite ampliar al 200 % en un smartphone hacen que, a nivel de equipo, se considere que "no hacerlo no causa grandes problemas".
¿Cómo se puede solucionar este problema?
Es importante no usar rem, que se ve afectado por el aumento del texto, sino unidades basadas en el viewport como vw, y evitar que los márgenes se agranden innecesariamente al hacer zoom.
Sin embargo, si se especifica solo con vw, no se aprovecha la ventaja de clamp(), que permite controlar los valores mínimo y máximo.
Aquí entra en juego la función min()!
min() toma el "valor más pequeño" de los valores proporcionados. Aprovechando esta característica, se cambian los valores aplicados en condiciones normales y al aumentar el tamaño.
La sintaxis es la siguiente.
--spacing-lg: min(
calc(var(--spacing-lg-min) / var(--clamp-viewport-min) * 100vw),
clamp(
calc(var(--spacing-lg-min) / var(--clamp-base) * 1rem),
calc(var(--spacing-lg-intersection) * 1rem + 100 * var(--spacing-lg-slope) * 1vw),
calc(var(--spacing-lg-max) / var(--clamp-base) * 1rem)
)
);
Al mostrarlo con 375 CSS px, el primer valor de min es 6.4vw, que equivale a 24px de --spacing-lg-min convertidos a vw.
El valor mínimo de clamp() es 1.5rem = 24px, pero con una ampliación del 200% pasa a ser 48px, por lo que 6.4vw (el valor de la izquierda) es menor y es el que se aplica.
En resumen,
- Visualización normal (100%):
- El valor de
clamp()resulta menor que el valor basado envw. - Como
min()adopta el valor más pequeño,clamp()se aplica y la visualización varía según el ancho de la pantalla.
- El valor de
- Con zoom al 200 %:
- Al ampliar la página, el
remdentro declamp()aumenta, y el valor basado envwresulta menor. - Se aplica el valor basado en
vw, de modo que los márgenes se fijan como proporción del ancho de la pantalla y se evita una ampliación excesiva.
- Al ampliar la página, el
¡De este modo, se logran a la vez la comodidad de un diseño responsive y la atención a la accesibilidad!
Nota: en la vista de PC, a menudo se mantiene mejor el equilibrio del diseño si los márgenes también se amplían, por lo que se toma como referencia --clamp-viewport-min y solo se aplica en smartphones.
Comparación del comportamiento real
Arriba, solo clamp; abajo, min + clamp.
Al ampliar al 200 % en un smartphone, la diferencia se aprecia claramente.
* En iOS Safari, puedes ampliar la página con el icono situado a la izquierda de la barra de direcciones; en Android Chrome, con el icono de la esquina superior derecha.
Conclusión
- clamp() resulta útil para ajustar los espacios de forma adaptable (responsive).
- Sin embargo, al ampliar la vista, los espacios también se agrandan y puede haber problemas de diseño.
- Combinando clamp() con min(), es posible lograr un equilibrio adecuado: variable en uso normal y controlada al ampliar.
Si te preocupa cumplir con WCAG, conviene incorporar este tipo de implementación. Aunque todavía es poco habitual contemplar una ampliación del 200 % en dispositivos móviles, así se mantiene una buena legibilidad habitual y se reducen los riesgos de accesibilidad.
Además, si quieres ajustar otros detalles aparte de los espacios, también puedes definir una media query para puntos de quiebre más estrechos.
@media (max-width: 239px) {
/* 拡大時に適用したいCSS */
}
Por ejemplo, si una pantalla de 375 px se amplía al 200 %, el navegador calcula el ancho del viewport como la mitad (aproximadamente 188 px). Por eso es posible hacer coincidir esta condición estrecha.
* El valor de 239 px es solo un ejemplo: conviene definirlo ajustándolo para dejar margen a futuras pantallas más grandes sin afectar a la visualización normal.
Combinando «clamp() + min()» con una media query para puntos de quiebre estrechos, se logra una accesibilidad más flexible y segura.
Pasó del DTP al mundo web y, sin darse cuenta, domina el maquetado, el frontend, la dirección de proyectos y la accesibilidad: un auténtico "maestro de todas las técnicas". Desde los inicios de Liberogic ha desempeñado múltiples funciones y hoy es una auténtica enciclopedia viviente dentro de la empresa. Últimamente se ha obsesionado con la optimización mediante prompts, preguntándose: «¿No podríamos apoyarnos más en la IA para la accesibilidad?». Su tecnología y su forma de pensar siguen evolucionando.
Ayumu Futamata
Especialista en Accesibilidad Web certificado por IAAP (WAS) / Ingeniero de marcado / Ingeniero frontend / Director web