Cette page a été traduite avec l'aide d'une IA. L'original en anglais fait foi.
L'édition de 2005 répondait à la question de la taille par un nombre : un minimum de 14 points, soit environ 19 pixels en Verdana, pour un texte courant accessible. C'était un nombre défendable pour son époque — les tailles traditionnelles de l'imprimé, 9 et 10 points, étaient manifestement inadaptées aux écrans grossiers, et l'énorme hauteur d'x de Verdana faisait de 19 pixels une lecture confortable. Mais la leçon plus profonde des deux dernières décennies est qu'aucun nombre unique ne peut être la réponse, parce que le lecteur, et non le designer, est désormais l'autorité finale en matière de taille. Le travail du designer est passé du choix de la bonne taille à la construction d'un système qui survit aux choix du lecteur.
Ce qui a changé depuis 2005
Trois développements ont restructuré la question.
Premièrement, la valeur par défaut du navigateur a fixé le plancher. Tous les grands navigateurs livrent une taille de texte par défaut de 16 pixels CSS, et les utilisateurs peuvent l'augmenter dans les réglages. Seize pixels sont devenus le contrat effectif entre la plateforme et le lecteur : un texte courant à la taille par défaut, ou plus grand, respecte ce contrat ; un texte courant en dessous passe outre une préférence que l'utilisateur a peut-être délibérément définie. L'ancien chiffre de 19 pixels en Verdana compensait la hauteur d'x hors norme de Verdana et le rendu de l'époque ; dans un caractère de labeur moderne typique, 16px se lit de manière comparable. Pour les caractères à petite hauteur d'x, 17 ou 18px est l'équivalent honnête — l'intuition de 2005 selon laquelle la hauteur d'x compte davantage que la taille nominale survit pleinement, et le CSS l'encode même désormais dans la propriété font-size-adjust, qui met à l'échelle les polices de substitution selon un rapport de hauteur d'x constant, de sorte qu'un remplacement de police ne puisse pas rétrécir silencieusement le texte.
Deuxièmement, les normes d'accessibilité ont fait de la redimensionnabilité, et non de la taille, l'exigence testable. Le critère de succès WCAG 1.4.4 (Redimensionnement du texte) exige que le texte puisse être agrandi à 200 pour cent sans perte de contenu ni de fonctionnalité ; le critère 1.4.10 (Redistribution) exige que le contenu se redistribue à fort zoom sans défilement bidimensionnel. Une page composée à une taille fixe généreuse peut néanmoins échouer aux deux ; une page à 16px avec une mise en page résiliente les passe. Le centre de gravité de la norme est le parcours de zoom, non le point de départ.
Troisièmement, les écrans à haute densité ont levé les anciennes contraintes vers le haut. Le texte ne se dégrade plus à la mise à l'échelle, si bien que les inquiétudes de 2005 sur la stabilité de la mise en page sous mise à l'échelle relèvent désormais de réponses d'ingénierie plutôt que de typographie.
Respecter l'utilisateur : rem, pas px
La pratique la plus lourde de conséquences à adopter est le dimensionnement des caractères en unités rem. Un rem est relatif à la taille de police racine, qui hérite de la valeur par défaut du navigateur — ainsi, un utilisateur qui relève sa valeur par défaut de 16 à 20px voit chaque élément dimensionné en rem grandir proportionnellement. Un texte figé en px ignore entièrement cette préférence.
La défense courante — « les utilisateurs du px peuvent toujours zoomer » — n'est que partiellement vraie, et la distinction compte. Le zoom pleine page met à l'échelle le texte en px, certes. Mais les réglages de taille de texte du navigateur, sur lesquels beaucoup d'utilisateurs malvoyants s'appuient précisément parce qu'ils persistent sur tous les sites sans manipulation page par page, n'affectent pas du tout le texte dimensionné en px. Figer les caractères en pixels désactive en silence le mécanisme d'accessibilité le plus durable de la plateforme. La même logique s'oppose à donner à l'élément racine une font-size en px (la vieille astuce « html { font-size: 62.5% } » est acceptable parce qu'elle est proportionnelle ; « html { font-size: 10px } » ne l'est pas).
L'interlignage relève de la même discipline : spécifiez-le sans unité (1,5 pour le texte courant est une valeur par défaut saine) afin qu'il évolue avec la taille finale du texte, plutôt que de rester figé à une valeur en px calculée pour le viewport du designer.
Un dimensionnement fluide sans perdre le plancher
Le responsive design a ajouté un nouvel outil et un nouveau mode d'échec. La fonction clamp() permet à une taille de respirer avec le viewport — clamp(1rem, 0.9rem + 0.5vw, 1.25rem) définit un plancher, un milieu fluide et un plafond — ce qui est réellement utile pour les titres et pour le texte courant appelé à grandir sur les grands écrans.
Le mode d'échec est le dimensionnement fondé sur le seul viewport. Un texte dimensionné purement en unités vw ne répond pas au zoom : quand l'utilisateur zoome, la largeur CSS du viewport rétrécit proportionnellement et le texte se recalcule à peu près à la même taille apparente, mettant en échec WCAG 1.4.4. La défense est intégrée au motif recommandé : incluez toujours un terme en rem dans l'expression fluide et un minimum en rem dans clamp(), afin que la préférence de l'utilisateur comme le zoom conservent leur prise. Puis vérifiez en zoomant réellement à 200 pour cent et en confirmant que le texte a doublé de taille.
Une architecture de taille moderne
En assemblant les pièces, une échelle typographique défendable pour une lecture accessible ressemble à ceci : texte courant à 1rem minimum (16px aux réglages par défaut, davantage pour les caractères à petite hauteur d'x), texte secondaire jamais en dessous d'environ 0,875rem et jamais pour une lecture soutenue, titres sur une échelle à ratio modeste exprimée en rem avec une fluidité clamp() optionnelle, et chaque font-size fixe en px traitée comme un défaut. La recommandation de 2005 sur le petit texte tient sous forme actualisée — un texte réellement petit n'est tolérable que pour de courtes chaînes accessoires, jamais des passages continus, et les règles de contraste de WCAG se durcissent pour lui : un texte en dessous de 18pt en romain (ou 14pt en gras) exige un rapport de contraste de 4,5:1 au lieu du 3:1 accordé au texte de grande taille, une reconnaissance explicite du fait que taille et contraste se négocient l'un contre l'autre.
Pour les lecteurs malvoyants, rien de tout cela ne remplace le grossissement ; cela fait fonctionner le grossissement. La mesure du succès n'est pas l'apparence de la page à 100 pour cent, mais le fait qu'elle demeure une colonne unique et lisible à 200 et 400 pour cent de zoom.
En CSS
html { font-size: 100%; } /* the reader's choice is the unit */
body { font-size: 1rem; } /* 16px floor for continuous text */
h1 {
/* the rem term keeps user settings and zoom in charge */
font-size: clamp(2rem, 1.2rem + 3vw, 4rem);
}
small { font-size: 0.875rem; } /* captions only, never body text */Recommandations
- Traiter 16px (1rem) comme le plancher du texte courant ; le relever pour les caractères à petite hauteur d'x.
- Dimensionner tous les caractères en rem ; spécifier l'interlignage sans unité (environ 1,5 pour le texte courant).
- Ne jamais figer le texte courant en px, et ne jamais donner à la taille de police racine une valeur en px.
- Utiliser clamp() pour la typographie fluide, toujours avec une composante rem afin que le zoom et les préférences de l'utilisateur continuent de s'appliquer.
- Utiliser font-size-adjust pour que les polices de substitution conservent la hauteur d'x voulue.
- Tester à 200 pour cent de zoom (WCAG 1.4.4) et en redistribution à 400 pour cent (WCAG 1.4.10) comme contrôle qualité de routine.
- Réserver les tailles inférieures au texte courant aux courts textes accessoires, et accorder au petit texte le contraste plus strict de 4,5:1 qu'il exige.