Pour ajuster les marges, l'approche consistant à utiliser clamp() pour rendre la valeur variable entre un minimum et un maximum est aujourd'hui très courante.
C'est très pratique pour l'adaptation responsive, mais si l'on prend en compte l'agrandissement d'affichage (zoom) lié à l'accessibilité, il existe un piège à éviter.
Exemples courants de valeurs clamp()
Par exemple, lorsqu'on ajuste une marge avec clamp(), on écrit souvent le code comme suit.
: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)
);
}
Nous ne détaillerons pas davantage ici :
- Sur smartphone, la taille de
--spacing-lg-min - Sur PC, la taille de
--spacing-lg-max - Elle reste fluide et se redimensionne en douceur entre ces deux états
Un modèle très pratique, n'est-ce pas ?
Les pièges de l'accessibilité, vous connaissez ?
Le problème survient lorsqu'on tente de respecter le critère 1.4.4 « Redimensionnement du texte » des WCAG 2.0.
Ce critère a été défini à l'origine, avant la généralisation des smartphones, dans l'intention que le contenu reste consultable sur PC lorsqu'il est agrandi jusqu'à 200 %. Or les mêmes conditions s'appliquent aujourd'hui aux navigateurs mobiles.
Lorsqu'on agrandit une page à 200 % sur smartphone, on observe souvent le phénomène suivant.
- Lors du zoom sur le texte, les marges définies en
remsont elles aussi agrandies, proportionnellement au reste du contenu. - Il en résulte des marges excessivement larges autour du contenu principal.
- En conséquence, la zone d'affichage du contenu se réduit fortement, ce qui peut entraîner des problèmes de mise en page et une lisibilité dégradée.
Note : En pratique, les sites gouvernementaux étrangers soumis à une obligation de conformité aux WCAG n'appliquent pas toujours ce critère. Cela peut s'expliquer par le rapport coût-bénéfice ou par le fait que le besoin d'agrandir une page à 200 % sur smartphone reste marginal, si bien que, sur le terrain, il est parfois considéré comme « pas indispensable, sans grand risque ».
Comment résoudre ce problème ?
Il est important d'utiliser des unités basées sur la fenêtre d'affichage, comme vw, plutôt que rem, qui sont affectées par l'agrandissement du texte, tout en veillant à ne pas rendre les marges excessivement grandes lors du zoom.
Toutefois, si l'on n'utilise que vw, on ne profite pas de l'avantage de clamp(), qui permet de contrôler les valeurs minimale et maximale.
C'est là qu'intervient la fonction min() !
min() retient la plus petite des valeurs passées en arguments. En tirant parti de cette particularité, on peut basculer entre la valeur appliquée en affichage normal et celle appliquée en agrandissement.
Voici la syntaxe.
--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)
)
);
Affiché à 375 px CSS, la première valeur de min correspond à --spacing-lg-min, soit 24 px, convertis en 6,4vw.
La valeur minimale de clamp() est de 1,5rem = 24 px, mais à 200 % d'agrandissement elle passe à 48 px. La valeur de gauche, 6,4vw, est donc plus petite et c'est celle qui est appliquée.
En résumé,
- Affichage normal (100 %) :
- La valeur de
clamp()est plus petite que celle basée survw. - Comme
min()retient la plus petite valeur,clamp()s'applique et l'affichage varie selon la largeur de l'écran.
- La valeur de
- Lors d'un zoom (affichage à 200 %) :
- Lors du zoom, le
remdansclamp()augmente, et la valeur basée survwdevient plus petite. - La valeur basée sur
vwest appliquée et les marges restent proportionnelles à la largeur de l'écran, ce qui évite un agrandissement excessif.
- Lors du zoom, le
Ainsi, il est possible de concilier « la praticité du responsive » et « la prise en compte de l'accessibilité » !
Note : sur ordinateur, un agrandissement incluant les marges préserve généralement mieux l'équilibre du design. C'est pourquoi --clamp-viewport-min sert de référence et n'est appliqué qu'aux smartphones.
Comparaison du comportement réel
En haut : clamp seul. En bas : min + clamp.
Sur smartphone à 200 % de zoom, la différence est très nette.
Note : sur iOS Safari, le zoom se fait via l'icône à gauche de la barre d'adresse ; sur Android Chrome, via l'icône en haut à droite.
Conclusion
- clamp() est pratique pour ajuster les marges de manière responsive
- Toutefois, lorsqu'on zoome, les marges sont elles aussi agrandies, ce qui peut entraîner des problèmes de mise en page
- En combinant avec min(), on obtient un compromis équilibré : variable en temps normal, contrôlé lors du zoom
Si vous visez la conformité WCAG, ces techniques d'implémentation sont une bonne précaution. Prendre en compte le zoom à 200 % sur smartphone est encore rare, mais cela permet de préserver la lisibilité habituelle tout en réduisant les risques en matière d'accessibilité.
Par ailleurs, si vous souhaitez ajuster d'autres aspects que les marges, vous pouvez aussi utiliser des media queries ciblant des breakpoints plus étroits.
@media (max-width: 239px) {
/* 拡大時に適用したいCSS */
}
Par exemple, pour un écran de 375 px de large zoomé à 200 %, le navigateur calcule la largeur du viewport comme « la moitié de la taille » (environ 188 px). Il est donc possible de cibler précisément cette condition étroite.
Note : 239 px n'est qu'un exemple. Il est recommandé de définir cette valeur en laissant une marge pour de futurs écrans plus grands, sans affecter l'affichage normal.
En associant « clamp() + min() » et des media queries sur des breakpoints étroits, vous obtenez une gestion de l'accessibilité plus souple et plus sûre !
Passé du DTP au Web, il maîtrise aussi bien le balisage que le frontend, la direction de projet et l'accessibilité : un véritable « sage de la technique ». Actif chez Liberogic depuis ses débuts, il est aujourd'hui une référence interne incontournable. Ces derniers temps, il explore avec passion l'optimisation par l'IA : « Ne pourrait-on pas davantage s'appuyer sur l'IA pour l'accessibilité ? » Sa technique comme sa réflexion continuent d'évoluer.
Ayumu Futamata
Spécialiste certifié en accessibilité web IAAP (WAS) / Intégrateur balisage / Ingénieur frontend / Directeur web