Mis à jour 15 juillet 2026

Typographie fluide et WCAG 1.4.4 : le test de zoom

La typographie fluide peut satisfaire WCAG 1.4.4 (Redimensionnement du texte), et le fait qu’elle y parvienne se décide dans l’arithmétique du clamp : les termes en rem répondent au zoom et aux préférences de taille de police, le terme en vw non. Plus la part de rem d’une taille fluide est grande, plus le texte se rapproche d’un vrai 200 % lorsque l’utilisateur zoome à 200 %. Une progression douce comme 16→18px est pilotée à environ 90 % par le rem et zoome presque proportionnellement ; une progression raide déplace le poids vers le terme de fenêtre d’affichage et dégrade discrètement la réponse au zoom.

Cette répartition — quelle part d’une taille vit en rem plutôt qu’en vw — est le sujet de ce guide. C’est l’approfondissement accessibilité de notre guide de la typographie fluide : le mode de défaillance propre à la typographie fluide, les chiffres d’accessibilité du clamp qui le déterminent et un protocole de test que vous pouvez exécuter en dix minutes.

Qu’exige WCAG 1.4.4 ?

Le critère de succès 1.4.4, Redimensionnement du texte exige que le texte puisse être redimensionné jusqu’à 200 pour cent sans perte de contenu ni de fonctionnalité. Deux mécanismes utilisateur comptent, et ils sont différents : le zoom pleine page, qui met à l’échelle le pixel CSS lui-même, et la préférence de taille de police du navigateur, qui modifie la taille par défaut à laquelle se réfèrent les unités rem. Un système robuste répond aux deux. Un texte en unités de fenêtre d’affichage pures ne répond à aucun des deux — ce qui fait de la typographie fluide négligente l’une des rares techniques modernes capables d’échouer purement et simplement à ce critère.

Pourquoi le zoom du navigateur n’atteint-il pas le terme vw ?

Le zoom fonctionne en mettant à l’échelle le pixel CSS : à 200 % de zoom, un pixel CSS correspond à deux pixels physiques. Tout ce qui est déclaré en px ou en rem double donc physiquement. Mais la fenêtre d’affichage compte désormais deux fois moins de pixels CSS de large — une fenêtre de 800 pixels physiques devient une fenêtre d’affichage de 400 pixels CSS — et vw est défini par rapport à cette fenêtre d’affichage. Les deux effets s’annulent : 1vw vaut 8 pixels physiques avant le zoom (1 % de 800) et 8 pixels physiques après (1 % de 400, chacun valant deux). Zoomé ou non, une taille en vw pur s’affiche à la même taille physique. Le texte est sourd au zoom.

Un clamp fluide mélange les deux types de termes, il répond donc partiellement — et « partiellement » peut se calculer.

Quelle réponse au zoom un clamp conserve-t-il ?

Prenez le clamp racine d’une progression 16→18px sur des fenêtres d’affichage de 360→1280 :

font-size: clamp(1rem, 0.9511rem + 0.2174vw, 1.125rem);

Sur une fenêtre de 800px de large, la valeur préférée est d’≈15,22px issus du terme rem plus ≈1,74px issus du terme vw — ≈16,96px au total, répartis à environ 90/10 en faveur du rem.

Zoomez maintenant à 200 %. La part rem double pour atteindre ≈30,43px de taille physique ; la part vw reste à ≈1,74px. Total : ≈32,17px — soit environ 190 % de l’original. Un peu en deçà du proportionnel, et la part manquante est exactement la part vw. En pratique, cela passe : le texte répond fortement, et un vrai 200 % arrive un cran plus loin sur l’échelle de zoom, bien dans les limites de ce que proposent les navigateurs.

Comparez un clamp plus raide hypothétique — clamp(0.75rem, 0.5rem + 1vw, 2rem) — qui, sur la même fenêtre de 800px, vaut 8px de rem et 8px de vw, une répartition 50/50. À 200 % de zoom, il atteint 24 pixels physiques : 150 % de sa taille d’origine. Pour que son utilisateur double réellement le texte, il doit zoomer à 300 %. Cela manque l’intention du critère, et les audits le signalent couramment.

La règle générale découle de l’arithmétique : plus la pente est raide, plus une grande part de la taille vit en vw, et plus la réponse au zoom est mauvaise. La pente n’est pas seulement une décision de design sur la vitesse à laquelle le texte grandit d’un écran à l’autre — c’est une décision d’accessibilité sur la part du texte que le zoom peut atteindre.

Une conséquence de plus qu’il vaut la peine de connaître : les bornes du clamp sont des filets de sécurité pour l’accessibilité. À mesure que l’utilisateur zoome, la fenêtre d’affichage CSS rétrécit, la valeur préférée baisse, et à un moment donné la borne min prend le relais — au-delà d’environ 220 % de zoom dans l’exemple à 800px. À partir de là, la taille est en rem pur et la réponse est entièrement proportionnelle. Les zones plates d’un clamp sont son territoire le plus sûr.

Ouvrez ce clamp racine dans Scale Composer — le mode fluide conserve les quatre chiffres qui le sous-tendent (base 16→18, fenêtres d’affichage 360→1280), l’export CSS écrit le clamp avec sa plage de pixels en commentaire, et l’export DTCG porte les quatre mêmes paramètres, de sorte que l’arithmétique ci-dessus est reproductible.

Le mode fluide de Scale Composer conservant un clamp racine de 16 à 18 pixels, avec le CSS exporté et sa plage de pixels en commentaire

Comment tester le redimensionnement de la typographie fluide ?

Trois vérifications, dans l’ordre de ce qu’elles détectent :

  1. Zoomez à 200 %. Le texte courant devrait s’afficher à près du double de sa taille physique. S’il traîne visiblement — grandit un peu, puis cale — la part de vw est trop élevée quelque part.
  2. Réglez la préférence de taille de police du navigateur sur Grande. Le texte fluide basé sur rem grandit ; le texte ancré en px et en vw ignore complètement le réglage. Cela détecte une défaillance différente de celle du zoom, ce n’est donc pas redondant.
  3. Vérifiez à vp-min, vp-max et en milieu de plage. En dessous du min et au-dessus du max, le clamp est plat — rem pur, les zones les plus sûres. C’est en milieu de plage que le terme vw porte sa plus grande part, alors effectuez la vérification du zoom de la typographie fluide à une largeur intermédiaire, et pas seulement à une taille de bureau confortable.

Pourquoi un clamp racine facilite-t-il l’audit ?

Un système fluide par élément vous donne des dizaines de clamps, chacun avec sa propre pente et sa propre répartition rem/vw — des dizaines d’endroits où une pente raide peut se cacher. L’architecture à clamp racine inverse cela : un seul clamp sur la taille de police racine, tout le reste en rem qui la chevauche. Le comportement au zoom du système entier est le comportement au zoom d’une seule expression, vérifié une seule fois.

Et une progression de base douce se comporte bien par construction : 16→18 sur 360→1280 met environ 90 % de la taille dans le terme rem aux largeurs intermédiaires. Le spectacle à l’échelle du système — la taille qu’atteint un h1 — vit dans le ratio de l’échelle typographique, multiplié par-dessus en rem à l’épreuve du zoom, et non dans la pente de la progression.

Faites les calculs sur une progression plus raide

Le lien entre pente et accessibilité est plus facile à croire quand vous le calculez vous-même : ouvrez une progression de base plus raide dans Scale Composer — 16→24 sur la même plage de fenêtres d’affichage — et refaites l’arithmétique à 800px à partir de son export. La part de rem tombe à ≈65 %, et 200 % de zoom donne désormais ≈165 %. Quelque part entre cette progression et la douce se trouve la réponse propre à votre système — et les plages commentées de l’export vous donnent tous les chiffres dont vous avez besoin pour la trouver.

Continuer la lecture

  • Qu'est-ce que la typographie fluide ?

    La typographie fluide fait de la taille des polices une fonction de la largeur du viewport : un minimum, un maximum et un glissement continu entre les deux. La formule, le système, ce qui reste fixe.

  • Le piège de l'unité vw

    Pourquoi la taille de police en vw pur échoue : aucune borne, insensible au zoom, un seul nombre verrouillant taille et pente. 4vw évalué à cinq largeurs, et le clamp() borné qui le remplace.