Webdesign Friday (#wdfr) - La communauté des webdesigners francophones

Les vendredis Webdesign !Chaque semaine, un nouvel article par un professionnel du Web.

Font-size, Responsive et Accessibilité : le Bon, la Brute et le Truand

Font-size, Responsive et Accessibilité : le Bon, la Brute et le Truand

Lorsque j’ai commencé à apprendre le métier de webdesigner, il y a maintenant 9 ans, on m’a dit de créer mes maquettes sous Photoshop. Bon, depuis j’ai appris qu’on pouvait très bien les créer sous Illustrator ou Fireworks, mais dans tous les cas, le constat est le même : la majorité d’entre nous pensons les mesures en pixel.

“Normal”, me direz-vous. Je suis d’accord.

Mais lorsqu’on parle de la taille des textes, définie par la propriété CSS font-size, là, rien ne va plus. Certains sont accros au px, d’autres sont entrés à l’école em, et les derniers attendent le messie rem. Il y en a d’autres, mais ce sont les trois plus importantes.

État des lieux.

1. Une font-size à sa mesure

On va commencer par le plus simple…

L’unité px

L’unité px, qui correspond au pixel de votre écran, est celle que la plupart des webdesigners utilisent, ou ont utilisé à leur début.

C’est une unité absolue. Son avantage est que votre texte aura l’exacte hauteur que vous lui avez définie, à l’endroit que vous avez choisi.

Le problème : si vous décidez de changer de taille sur toute une zone, de vous-même, ou (par exemple) avec un bouton laissé à l’utilisateur pour augmenter ou diminuer la taille du texte, titres y compris, là, vous n’aurez d’autre choix que de redéfinir chacun des éléments sur lesquels vous avez spécifié une taille.

Ouest France

Ex. : http://www.ouest-france.fr

C’est là où la solution de l’unité em est intéressante.

L’unité em

Un em correspond à un cadratin, c’est à dire la largeur de la chasse de la lettre “M” majuscule de la police utilisée. (Plus d’informations sur la page Wikipedia Cadratin) Dans la pratique, en CSS, cette unité correspondra à 16px puisque c’est la taille par défaut des navigateurs, et pourra être assimilée au pourcentage.
Comprenez 100% = 1em = 16px.

C’est donc une unité relative, et en ce sens, le problème précédent peut être facilement résolu : vous modifiez uniquement la taille de l’élément englobant votre zone, et les éléments à l’intérieur hériteront de cette nouvelle valeur de référence.

Cette histoire d’héritage nous simplifiera la vie dans ce cas, mais la plupart du temps, disons-le, c’est une vraie plaie !

Partons de ce principe : c’est une unité relative, il faut donc une valeur absolue de référence, qui sera la taille par défaut du navigateur, donc 16px. Espérons déjà qu’elle ne change pas !
16px est alors l’équivalent de 1em… pas simple pour calculer les équivalences en pixels !

Une petite astuce nous permettra d’y voir plus clair : définissez une nouvelle taille à la racine de sorte que la base soit équivalente à 10px. Pour cela, appliquez une font-size à 62.5% de la taille par défaut (produit en croix power !), les dimensions du reste de la page seront ainsi simplifiées.

body { font-size: 62.5%; } /* 16px * 62.5% = 10px */
h1   { font-size: 2.4em; } /* = 24px */
p    { font-size: 1.4em; } /* = 14px */

Vous noterez sûrement l’emploi du pourcentage plutôt que l’équivalent 0.625em. “Pourquoi” ? Vous pouvez remercier nos amis Internet Explorer 6 et 7 qui n’interprêtent pas l’unité em sur les éléments html et body ! (Merci Raphaël Goetter pour cette info !)

Bon, jusque là, tout va bien. Mais c’est maintenant que cette histoire d’héritage vient tout gâcher dans nos calculs !

Imaginons :

<div>
    <h1>Titre</h1>
    <p>Texte</p>
</div>

Je définis sur ma div une font-size à 1.4em, et sur mon titre h1 une font-size à 2.4emERREUR !

Ces 2.4em ne seront pas calculés à partir de mes 62.5% de 16px, mais bien à partir des 1.4em de son élément parent, soit donc 16px * 62.5% * 1.4em * 2.4em ! Chaque élément de votre page hérite de la taille de son élément parent. Une vraie plaie je vous dis !

Vous comprenez donc que l’utilisation de l’unité em est un vrai casse-tête de calcul et de tentative de non-superposition de valeurs.

Mais réjouissez-vous, maintenant arrive l’unité rem !

L’unité rem

L’unité rem (pour “root em”), introduite par le CSS3, est un peu celle qu’on attendait tous. C’est en fait la même que l’unité em, donc relative, mais sans la notion d’héritage. Tout est fonction de la taille de la racine, c’est à dire la taille font-size définie sur l’élément html.

Vous pourrez donc choisir une dimension de base en pourcentage comme ci-dessus, ou en choisir une en px, et ensuite définir vos dimensions sur chaque élément par rapport à celle-ci. Vous aurez la possibilité de tout modifier en une seule fois en changeant uniquement votre dimension de base.

“Mais quel est le hic” me direz-vous ?

Et le hic, celui qu’on attend toujours à chaque bonne nouvelle, a justement tendance à s’estomper : c’est la compatibilité entre navigateurs.

Si on s’en réfère au site caniuse.com/rem, on se rend compte que finalement, on pourrait déjà se mettre au rem puisque compatible sur Firefox 3.6+ (Emmanuel Clément soulève tout de même un problème au zoom sur FF 7.0.1), Chrome 6+, Safari 5.0+ et Opera 11.6+, pour ne parler que des navigateurs desktop. Il faudrait bien sûr prévoir un fallback en px pour Internet Explorer puisqu’elle n’est introduite qu’à partir de la version 9. Enfin… c’est déjà pas si mal.

html { font-size: 62.5%; }
h1   { font-size: 24px; font-size: 2.4rem; }
p    { font-size: 14px; font-size: 1.4rem; }

Ainsi, nous avons la taille en px pour les navigateurs ne comprenant pas l’unité rem, et la deuxième pour écraser la première définition pour les navigateurs plus récents.

Après ça vous me demanderez “mais alors, quelle unité utiliser ?”.
En premier lieu, je vous dirai de choisir celle qui convient le mieux à votre manière de coder, mais dans le contexte actuel du multi-supports, notamment le webdesign responsive, je préfèrerai vous répondre “attention” !

2. Le contexte multi-supports

Si vous vous êtes penchés sur la question du webdesign mobile, tablette et smartphone, pendant plus de 15 minutes, vous avez probablement dû tomber sur des articles tels que celui-ci ou celui-là qui vous expliquent que la résolution unique pour le web à 72dpi, c’est fini !

Désormais, quelqu’un au dessus de nos têtes de webdesigners passionnés semble vouloir s’acharner à nous donner la migraine dès qu’on veux réfléchir à la résolution des supports cibles et aux mesures à employer !

Dites-vous qu’un pixel sur votre écran d’ordinateur n’a pas la même taille qu’un pixel sur votre smartphone ou votre tablette, et même entre appareils de même type. Il faudra donc adapter les tailles de vos textes en fonction du support, voir même le contexte de lecture sur ce support. Le plus sage donc, selon moi, sera d’employer l’unité rem.

“Donc on part sur le rem, c’est ça ?”.

Minute, papillon ! Maintenant arrive une question essentielle, celle de l’accessibilité !

3. Et l’accessibilité dans tout ça ?

Rappelez-vous, sur les anciennes versions des navigateurs, notamment Internet Explorer 6, lorsque vous vouliez zoomer, c’est la taille du texte qui s’agrandissait. Mais si cette taille avait été définie par une unité absolue, donc px, impossible de zoomer.

C’était le propos principal du choix de l’unité de mesure pour les tailles de texte : l’accessibilité ! Il fallait utiliser une unité relative, le em, pour assurer cette accessibilité pour le plus grand nombre, sans mettre de côté les personnes à la vue déficiente.

Mais ça, c’était avant !

Si vous testez le zoom sur votre navigateur actuel, vous verrez alors la page toute entière s’agrandir. Quelle que soit l’unité utilisée pour les tailles de texte, ça fonctionne, et même bien mieux qu’avant.

Alors la question se pose : y’a t-il toujours une question d’accessibilité dans le choix d’une de ces unités ? Mieux vaut-il toujours privilégier une unité relative ?

N’ayant pas les réponses, je laisse la place aux experts en la matière : Élie Sloïm, spécialiste en qualité, conformité et accessibilité des services en ligne, et Laurent Denis, expert en accessibilité, tous deux chez Temesis, Thomas Parisot, consultant web indépendant chez CyneticMonkey, et Stéphane Deschamps, expert en accessibilité et interopérabilité des sites web chez France Télécom – Orange.

Élie Sloïm et Laurent Denis : les référentiels d’accessibilité

Sur le plan de l’accessibilité, utiliser une unité proportionnelle aux réglages de l’utilisateur (em, ex, %, mots-clés) et non avec une unité dépendante du périphérique de consultation (px, pt, cm, etc.) va permettre aux utilisateurs équipés de navigateurs qui ne gèrent pas l’agrandissement des polices en taille fixe d’agrandir les polices sans difficulté.

Pour sa part, le pixel pose un problème particulier : en pratique, l’absence d’unités en pixels était exigée dans certains référentiels d’accessibilité. Elle est liée à l’impossibilité d’agrandir la taille des caractères dans certaines versions d’Internet Explorer (6 et 7).

Note de Raphaël Goetter : IE6 et IE7 figent tous deux la taille en px en effet, mais IE7 introduit un “zoom de page entière”, différent du “zoom texte”, et le zoom par défaut sur IE7 est “zoom sur toute la page” (donc tout s’agrandit, contenus en px y compris), et non “zoom texte uniquement” (où les px sont figés). Il s’agit donc d’un choix volontaire d’utiliser le zoom texte uniquement sur IE7 qui pose des problèmes.

Maintenant : si vous décidez de ne pas vous occuper de ces versions de navigateurs ET de ne pas respecter des référentiels qui contiennent cette exigence, vous ne poserez pas de vrais problèmes d’accessibilité à vos utilisateurs. Si IE6 et 7 vous importent ou si vous devez respecter un référentiel accessibilité, dura lex sed lex, oubliez le pixel.

Note : le pixel est une taille indépendante du media (contrairement au point ou au cm par exemple), mais il a été considéré comme une taille fixe à éviter à cause d’Internet Explorer 6 et 7. Les unités fixes telles que le point sont en revanche parfaitement adaptées dans le cadre d’une feuille de style CSS d’impression (media print).

Thomas Parisot : la relativité du support

L’héritage de la mesure en pixel doit très certainement beaucoup au mode de conception dans… Photoshop (pour boucler sur l’introduction de l’article) : tout est fixe, et à l’opposé de ce que peut être une page Web. Pour peu que l’on vienne du print, le cadre d’un écran d’ordinateur revient à mimer une feuille de papier.

Canevas fixe ou pas, il est plus pérenne de concevoir les grilles de manière relative, rapport à la taille du texte et de la page : la largeur d’une colonne sera en réalité calculée en fonction de la largeur maximale de la page, leur nombre ainsi que la largeur souhaitée des gouttières.

Il en va de même avec tout élément auquel on souhaite attribuer une taille, finalement ; que ce soit du texte ou des blocs.

Stéphane Deschamps : le monde n’avance pas si vite

Il y a pile trois ans, je posais exactement cette même question : et si on se dispensait des polices proportionnelles ? Après tout, tu l’as bien expliqué, les polices en pixels sont déjà recalculées avec des règles de trois internes pour deux raisons : la densité de pixels (dpi, dots per inch, points par pouce) n’est plus de 72dpi depuis longtemps, mais de 96 au minimum sur un écran de bureau et de plus de 300dpi (je crois) sur un iPhone avec retina display.

À l’époque j’ai choisi le status quo et je suis resté en polices proportionnelles, le parc n’était pas assez mûr (beaucoup, beaucoup de IE6-IE7 circulaient encore).

En novembre dernier, ressortie du serpent de mer sur Twitter (lire un résumé de la discussion), et là davantage de voix disent que voilà, ça y est, le parc de navigateurs est mûr. Raphaël (Goetter) notamment, comme tu le notes dans l’article, poussait déjà l’argument que si les gens ne font grossir que la police avec IE, c’est un choix.

Je ne suis absolument pas d’accord, il s’agit de modalités opératoires différentes. Certaines personnes ne comprennent pas leur interface graphique et vont chercher dans les menus, d’autres ne cherchent pas et ont des raccourcis clavier au bout des doigts (j’en suis), et les plus nombreux, c’est sûr, auront les yeux qui zigzaguent sur l’écran et trouveront les contrôles de zoom global de la page (ils sont toujours en bas à droite dans IE ? Je n’en ai pas sous la main pour tester — au passage c’est diablement moins affordant que là où l’on est habitué à chercher les boutons d’interface : dans le bandeau vers le haut du navigateur). Les premières personnes citées iront dans le menu Affichage > Texte > Plus grand. Et boum, seul le texte sera agrandi, si et seulement si on utilise une police proportionnelle ; sans elle, point de salut.

J’ai noté aussi (mais la pratique décline donc c’est sans doute anecdotique) que la technique des faux columns est très mal interprétée par IE7 si on met l’image de background sur le body et qu’on zoome la page. Donc on casse tout, assez violemment.

Je n’ai pas les moyens ni même simplement l’envie de m’aliéner tous les utilisateurs potentiels d’IE qui soit utilisent le clavier et zooment le texte seul, soit utilisent le zoom page et subissent des dégradations inacceptables de l’affichage — je veux bien faire de la dégradation grâcieuse, mais uniquement quand elle est… (wait for it) grâcieuse.

Merci de votre attention et pardon pour ma logorrhée, mais dès qu’on me donne une estrade et un micro, c’est plus fort que moi !

4. Conclusion ?

Le constat est donc clair : lorsqu’il est question d’accessibilité, il est fortement conseillé d’employer une unité relative !

De par son historique, la plupart des experts auront tendance à vous conseiller l’unité em, mais pour ma part, je trouve l’unité rem tout simplement géniale, à tel point qu’elle risque un jour de me faire perdre ma religion (blague de Raphaël — si si, on t’a vu ici !). Mais pour être totalement accessible, compatible, et plein-d-autres-choses-ible, il faudra prévoir un fallback pour IE 6/7 non pas en px, mais bien en em.

Maintenant que les choses sont claires, à vous de voir le parti que vous déciderez de prendre : votre aisance de codage, ou l’accessibilité.

Vous pourrez retrouver ces intervenants sur leur sites respectifs précédemment mentionnés, et également sur Twitter : Raphaël Goetter @goetter, Élie Sloïm @eliesl, Laurent Denis @ldenis, Thomas Parisot @oncletom, Stéphane Deschamps @notabene, et moi même, Matthieu Bué @twikito.

Merci encore pour leur généreuse participation.

Pour aller plus loin…

Merci à tous ceux qui liront jusqu’ici ! :)

A propos de l'auteur : Matthieu Bué

Je suis Web designer, intégrateur spécialisé on-page SEO, formateur, résidant à Bordeaux, spécialisé dans les dernières technologies d'édition Web, notamment en responsive, HTML5, CSS3, jQuery et accessibilité. Trouvez-moi sur Twitter et Google+, ou visitez matthieubue.com et twikito.com.

  • http://guirec.me Guirec

    Très intéressant !

    Pour ma part le rem ne me fait pas plus rêver que cela. J’aime bien la notion d’héritage du em justement.
    Je peux facilement revoir la taille du texte pour un bloc en particulier par exemple.

    Par ailleurs, je n’ai pas l’impression de me prendre la tête avec les calculs. Question d’habitude sans doute.

  • http://twitter.com/chrishrmnn Christophe HERMANN

    Article très intéressant, merci Matthieu (et les contributeurs) !

  • http://twitter.com/MH_UN mhun

    Merci pour les tips !!
    “rem risque un jour de me faire perdre ma religion” ^^

  • http://twitter.com/FlowerMountain Raphaëlle Montefiore

    Article intéressant !

    Concernant REM, moi aussi je l’attendais comme le messie jusqu’à ce que je réalise que la technique du 62,5% que j’utilisais depuis des années me mettais des battons dans les roues.

    En fait il y a beaucoup plus simple, comme l’explique cet article de CSS Wizardry : http://csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided/

    Le truc c’est de choisir une taille de texte par défaut et de définir le font-size du body en fonction. D’ailleurs la valeur par défaut est tout à fait valable car un corps de texte en 16px c’est très lisible.

  • http://accessiblog.fr Olivier Nourry

    A noter que l’émergence des tablettes et autres smartphones crée un nouveau problème, concernant le pixel: ce n’est plus l’unité fixe et immuable qu’il était (ou était sensé être): cf. http://www.alistapart.com/articles/a-pixel-identity-crisis/. Donc, pour ma part, je me range du coté des polices relatives, et d’autant plus que cela concorde avec les exigences d’accessibilité.

  • http://twitter.com/cooperanet cooperanet

    em pour l’instant, rem par la suite!

  • http://victor-brito.name/ Victor Brito

    Histoire de brouiller encore plus les pistes, je tiens à rappeler que la spécification CSS 2.1 range le pixel au nombre des unités relatives. En revanche, le module CSS 3 values and units prévoit, du moins à l’état actuel de son brouillon, de le traiter comme une unité absolue, en le définissant comme égal à 1/96 de pouce (source : http://www.w3.org/TR/css3-values/#absolute-lengths).

    Histoire de jouer au rabat-joie, je tiens également à préciser qu’Internet Explorer 8 et 9 refusent aussi, par défaut, d’agrandir le texte dont la taille de police est fixée en pixels (je parle bien de l’agrandissement du texte uniquement). Or, les parts de marchés de ces deux versions d’IE ne sont, globalement, pas encore suffisamment négligeables pour qu’on se permette d’utiliser le pixel sans heurter sa conscience.

    Enfin, puisqu’Élie et Laurent évoquent les référentiels, je tiens à rappeler que le référentiel Accessiweb proscrit effectivement l’utilisation du pixel pour fixer la taille de police d’un texte destiné à l’affichage sur écran (source : http://www.braillenet.org/accessibilite/referentiel-aw21/glossaire.php#lettreT).

  • http://css4design.com br1o

    J’utilise les em depuis longtemps et je n’ai pas l’impression de galérer avec les calculs : quand je ne veux pas qu’un élément hérite de la valeur précédente, je reset avec un font-size: 1em;

  • http://twitter.com/Twikito Matthieu Bué

    Mais… ça ne donnera que 1em, soit 100% de son élément parent, non ? Donc ça ne change rien !
    Par contre avec 1rem, là…

  • http://css4design.com br1o

    Tiens, par exemple, si je suis ton exemple et que je veux que mon texte n’hérite pas du font-size appliqué sur la , je fais :

    body { font-size: 62.5%; } /* 16px * 62.5% = 10px */
    h1 { font-size: 2.4em; } /* = 24px */
    p { font-size: 1.4em; } /* = 14px */
    div { font-size: 1.4em; }
    p.small { font-size: 1em;}

  • http://twitter.com/Twikito Matthieu Bué

    Hmmm… je suis sceptique.

    Ton p.small héritera de la taille de son élément parent dès l’instant où tu utilises l’unité em. Donc ici, nous seulement tu es obligé de rajouter une classe small à ton paragraphe, mais en plus il aura une taille de 1.4em, comme son élément parent.

    Autrement, c’est que je n’ai rien compris.

  • http://css4design.com br1o

    Non, laisse tomber, c’est moi qui me suis embrouillé avec mon histoire de 1em…

  • http://twitter.com/Twikito Matthieu Bué

    Je me disais… tu m’aurais pourri tout mon article, là ^^

  • http://css4design.com br1o

    T’inquiète, j’aurais checké et double-checké avant d’écrire :-)

  • Pingback: Le meilleur du web #40 : liens, ressources, tutos et inspiration « Design Spartan : Graphisme, Webdesign, Digital painting, Illustration…

  • goetter

    “je tiens également à préciser qu’Internet Explorer 8 et 9 refusent aussi, par défaut, d’agrandir le texte dont la taille de police est fixée en pixels (je parle bien de l’agrandissement du texte uniquement). ”

    Par contre, on est bien d’accord que l’agrandissement du texte uniquement n’est pas le zoom proposé par défaut (en faisant “zoom” ou Ctrl + molette), n’est-ce pas. C’est bien un choix volontaire de l’activer.

  • Pingback: Astuce : display: inline-block et les espaces indésirables | Aldebar

  • Pingback: Le meilleur du web #40 : liens, ressources, tutos et inspiration « Design Spartan : Art digital, digital painting, webdesign, illustration et inspiration…

  • Pingback: Responsive | Pearltrees

  • Yann MORINEAU

    Merci. Ce tutoriel répond exactement à ce que je cherche :)

  • François-Xavier Guillois

    Article très instructif, même 3 ans après ;)

Live Tweet

Dans le Blog

Newsletter

Vous souhaitez être tenu au courant des dernières nouvelles concernant le WDfriday, événements, conférences, barcamps, etc… ?

N'hésitez pas à vous inscrire à notre newsletter !