Cette page a été traduite avec l'aide d'une IA. L'original en anglais fait foi.
La première édition de ces recommandations présupposait un écran : unique, posé sur un bureau, de taille prévisible. Ce présupposé a disparu. Le même paragraphe doit désormais bien se lire sur un téléphone tenu à bout de bras, une tablette, un ordinateur portable et un affichage mural — et, plus important encore, il doit bien se lire pour une personne qui a agrandi sa police système, zoomé la page à 400 pour cent, ou les deux. La typographie fluide est l'art de faire évoluer les caractères sur toute cette étendue ; la typographie fluide accessible consiste à le faire sans contredire silencieusement le lecteur.
Les échelles fluides et la fonction clamp()
L'idiome moderne définit la taille de police avec la fonction CSS clamp() : un minimum, une valeur préférée qui croît avec le viewport, et un maximum. Au lieu de sauter entre des tailles fixes aux points de rupture, les caractères glissent — les titres, grandioses sur un écran de bureau, redescendent avec grâce sur un téléphone, et les largeurs intermédiaires ingrates que les points de rupture ne servaient jamais tout à fait sont gérées automatiquement.
Bien employée, c'est un gain réel pour la lisibilité. Employée sans précaution, elle crée une nouvelle catégorie d'échec d'accessibilité, et cet échec est assez subtil pour survivre à des tests superficiels.
La réserve d'accessibilité
Tout, dans cette publication, repose sur un contrat unique : les réglages de taille du lecteur l'emportent. Les navigateurs permettent aux utilisateurs de définir une taille de police par défaut ; les systèmes d'exploitation offrent une mise à l'échelle du texte ; le critère WCAG 1.4.4 (Redimensionnement du texte) exige que le texte puisse être redimensionné jusqu'à 200 pour cent sans perte de contenu ni de fonctionnalité. Les formules fluides peuvent rompre discrètement ce contrat de deux manières.
Premièrement, une formule construite uniquement sur des unités de viewport — disons une taille dérivée du seul vw — ne répond pas du tout à la préférence de taille de police de l'utilisateur. La page paraît fluide et moderne, et un lecteur qui a réglé son navigateur sur une valeur par défaut plus grande ne constate strictement aucun effet. Le remède consiste à construire les formules sur le rem : garder le minimum et le maximum en rem, et donner à la valeur préférée une composante en rem aux côtés de son terme de viewport. Ainsi, toute l'échelle repose sur le réglage de l'utilisateur, comme il se doit.
Deuxièmement, le clamp lui-même peut combattre le zoom. Quand un lecteur zoome, les unités de viewport rétrécissent en termes CSS, si bien qu'une formule chargée en vw annule partiellement le zoom : le lecteur agrandit la page et le texte grossit moins que le facteur de zoom, et dans les cas extrêmes ne peut atteindre les 200 pour cent qu'exige WCAG 1.4.4. Toute échelle fluide doit être testée à fort zoom — et non présumée conforme.
Reflow et zoom à 400 pour cent
Le critère WCAG 1.4.10 (Redistribution) exige que le contenu fonctionne à une largeur de 320 pixels CSS — l'équivalent d'une fenêtre de 1280 pixels zoomée à 400 pour cent — sans défilement horizontal pour la lecture. De nombreux lecteurs malvoyants vivent à ces grossissements. La typographie fluide aide ici quand elle est honnête : à cette largeur effective, l'échelle doit se trouver à son minimum, les longueurs de ligne doivent raccourcir, et rien ne doit s'échapper du viewport. Les conteneurs à largeur fixe, le positionnement absolu du texte et les mises en page multicolonnes qui refusent de se replier sont les coupables habituels. Testez chaque page de lecture à 400 pour cent ; cela prend une minute et c'est là que se cachent ces échecs.
Les container queries
Les media queries demandent quelle est la taille de la fenêtre ; les container queries demandent quelle est la taille de la boîte du composant lui-même, ce qui est généralement la question à laquelle la typographie a réellement besoin de répondre. Une carte est une carte, qu'elle se trouve dans une barre latérale ou s'étende sur toute la page, et ses caractères peuvent désormais répondre à sa propre largeur, en utilisant les unités de container query pour un dimensionnement fluide au sein du composant. La même réserve s'applique sans changement : les unités relatives au conteneur ne savent rien de la préférence de taille de police du lecteur, elles doivent donc elles aussi être combinées avec des termes en rem et testées sous zoom.
De plus petits outils, des gains réels
Plusieurs propriétés CSS récentes traitent directement de vieux problèmes typographiques :
- text-wrap: balance égalise les longueurs de ligne des blocs courts — les titres avant tout — en éliminant la ligne orpheline de deux mots sous une longue première ligne. Elle est destinée à quelques lignes, non au texte courant.
- text-wrap: pretty permet au navigateur de consacrer plus d'effort à la coupure des lignes du paragraphe, en évitant les derniers mots isolés et en améliorant le drapeau. La prise en charge reste inégale selon les moteurs ; traitez-la comme une amélioration progressive.
- font-size-adjust fait correspondre la hauteur d'x d'une police de substitution à celle de la police web qu'elle remplace. Pendant le chargement de la police web — ou si elle n'arrive jamais — la police de substitution s'affiche à une taille apparente équivalente, ce qui réduit les décalages de mise en page et maintient le texte de substitution aussi lisible que le caractère prévu. Vu la quantité de lecture qui se fait dans les secondes précédant le chargement des polices, cette modeste propriété mérite sa place.
Pourquoi ce chapitre est nouveau
En 2005, il n'existait pas de typographie fluide parce qu'il n'y avait rien sur quoi être fluide : le web mobile existait à peine, le responsive design ne serait formulé qu'en 2010, et clamp(), les container queries, le contrôle de text-wrap et la prise en charge généralisée de font-size-adjust sont tous des développements des dernières années. L'exigence de redistribution elle-même n'est entrée dans WCAG qu'avec la version 2.1 en 2018. La multiplicité des écrans a créé le problème ; le CSS n'a fourni les instruments que récemment ; et la discipline d'accessibilité autour de ces instruments est plus jeune encore.
En CSS
h1 {
/* fluid between bounds; the rem term preserves zoom and settings */
font-size: clamp(2.25rem, 1.4rem + 3.5vw, 4.5rem);
text-wrap: balance;
}
p { font-size: 1rem; text-wrap: pretty; }
/* Test at 200% and 400% zoom — WCAG 1.4.4 and 1.4.10 */Recommandations
- Construire les échelles fluides sur le rem : minimums, maximums et une composante rem dans la valeur préférée, afin que les préférences de taille de police de l'utilisateur se propagent.
- Ne jamais dimensionner le texte avec les seules unités de viewport.
- Tester chaque gabarit à 200 pour cent de zoom, à 400 pour cent de zoom et avec la taille de police par défaut du navigateur augmentée — trois tests différents, tous obligatoires.
- Vérifier WCAG 1.4.10 : à 320 pixels CSS de largeur, la lecture n'exige aucun défilement horizontal.
- Utiliser les container queries pour les décisions typographiques au niveau du composant, avec la même discipline du rem.
- Appliquer text-wrap: balance aux titres ; activer text-wrap: pretty pour le texte courant en amélioration progressive.
- Définir font-size-adjust (et des polices de substitution appariées en taille) afin que le texte soit lisible avant et sans la police web.