N’enterrons pas trop vite les polices-icônes (icon fonts) !

29 juillet 2015, par Audrey Maniez

Certains partent en guerre contre les icon fonts, et vont même jusqu’à souhaiter leur disparition, en invoquant des questions d’accessibilité.

Explorons ensemble ces arguments en détail.

Les icônes

Pour réaliser des icônes sur un site web, plusieurs techniques sont disponibles :

  • Utiliser une image en propriété de fond. Inconvénient de cette technique : vous ne pouvez pas fournir d’alternative texte à cette image. Dans le cas où l’image serait l’unique contexte (un bouton icône), et qu’elle ne serait pas affichée (en cas de non-chargement des images par exemple), le sens de l’élément serait perdu. De plus, les utilisateurs de lecteurs d’écran n’auront pas accès au sens de cette icône qui n’est véhiculé que par sa représentation visuelle.
  • Utiliser une image en propriété de fond avec un texte associé (caché hors écran, destiné généralement aux utilisateurs de lecteurs d’écran, ou visible selon le contexte). L’inconvénient reste le même que précédemment, mis à part que maintenant nous avons un texte disponible pour les lecteurs d’écran. Cette implémentation reste un sujet discuté aujourd’hui. Elle n’est pas la plus recommandée, mais nous n’en ferons pas état dans cet article.
  • Utiliser une image html (via la balise img). Cette technique reste une des plus robustes. Vous pouvez définir une alternative à l’image via l’attribut alt="", accessible aux utilisateurs de lecteurs d’écran et qui s’affichera à la place de l’image si elle n’est pas disponible.
  • Utiliser une image au format svg via la balise svg.
  • Utiliser un caractère d’une icon font associé à un texte caché ou non selon le besoin.

Il existe d’autres techniques, comme les ligatures, que nous ne détaillerons pas ici.

Les images svg et les icon fonts partagent un avantage non négligeable pour l’accessibilité : elles sont toutes les deux redimensionnables par l’utilisateur, contrairement à une image standard. Si un utilisateur a besoin d’agrandir la taille des caractères, ces deux éléments se redimensionneront également.

Aujourd’hui, le débat se situe sur l’implémentation à privilégier pour la mise en place de ces icônes, et particulièrement sur les 2 dernières évoquées : utiliser une icon font ou une image svg ?

Pour consulter les arguments invoqués contre les icon fonts, nous renvoyons au tweet de Jeffrey Zeldman qui reprend une présentation de Seren Davies.

Les icon fonts

Une icon font est une icône générée à partir d’un fichier de police. Plutôt que d’insérer une image dans le texte ou une image en propriété de fond d’un élément, on insère un contenu généré à partir d’un fichier de police, en utilisant le caractère Unicode correspondant dans le fichier de police :

.my-icon:before{
  content:"\F052";
}

L’une des polices les plus connues est Font Awesome.

Avez-vous pensé aux lecteurs d’écran ?

Premier argument souvent avancé contre les icon fonts : la restitution par un lecteur d’écran, de l’élément généré, risque d’être étrange.

En effet, puisque les icon fonts sont générées via une plage de caractères différente de celle de nos caractères européens, la restitution correspondante est forcément incompréhensible. L’expression renvoyée n’aura aucun sens.

La solution est donc de faire en sorte que cet élément ne soit tout simplement pas restitué.
WAI-ARIA propose un attribut simple, aria-hidden, dont la valeur "true", permet d’inhiber la restitution de l’élément porteur de cet attribut ainsi que de ses enfants. Dans le cas d’icônes décoratives, on en conclut que ce problème de restitution n’en est pas un. En effet, il vous suffit d’affubler la balise qui contient cette icône du bon attribut sur le modèle :

<p>
<span class="icon-pdf" aria-hidden="true"></span> Voici une liste de document PDF
</p>

En fait, toutes les icônes doivent êtres traitées en images décoratives, c’est-à-dire que si ces icônes servent à véhiculer une information et qu’elles sont l’unique contexte (un bouton avec une icône seule), il est essentiel de lui fournir un intitulé texte.

Pour des questions de design, et si l’icône est suffisamment explicite, on va pouvoir cacher ce texte visuellement (hors écran), pour qu’il reste accessible au lecteur d’écran justement. On arrive alors à :

<button>
<span class="icon-help" aria-hidden="true"></span>
<span class="sr">Mode d'emploi</span>
</button>
.sr{
 position:absolute;
 top:-10000em;
}

Avez-vous pensé aux personnes dyslexiques ?

Certains utilisateurs vont vouloir utiliser une police différente de celle que vous avez choisie pour votre site. Dans le cas des personnes dyslexiques, la police la plus connue (mais pas la seule) est OpenDyslexic.

À partir du moment où l’utilisateur a chargé sa police, les polices que vous aviez définies pour votre site sont tout simplement écrasées. Puisque votre icon font utilise une plage de caractères non européens, ce qui avant était une icône, se transforme en petit carré gris ou en hiéroglyphe d’un autre monde. En bref, l’utilisateur se retrouve avec des caractères incompréhensibles.

Vous en voyez l’exemple dans l’image ci-après, avec les boutons Twitter. Les boutons de gauche sont réalisés avec une icon font, les boutons de droite sont incompréhensibles (ou vides) car nous avons désactivés les polices personnalisées.

On prend en compte essentiellement les personnes dyslexiques, et les utilisateurs de lecteurs d’écran, mais d’autres utilisateurs, ayant des problèmes de vue divers, vont vouloir utiliser une police différente de la vôtre : plus grasse, ou plus fine, etc. L’idée au final, c’est surtout de laisser l’utilisateur personnaliser sa consultation du site, et de lui laisser la voie libre pour modifier ce qu’il veut sans pour autant risquer une perte d’information.

Ce problème de chargement de police personnalisée existera toujours, on ne pourra, et on ne voudra jamais empêcher l’utilisateur d’utiliser la police qu’il souhaite. Heureusement, on peut contourner le problème pour les icon fonts.

Il y a quelques mois déjà, Filament Group a développé un joli petit script, A Font Garde, qui permet de tester si votre fichier de police est chargé ou non. Cela vous permet alors de conditionner l’apparition de l’icône et la mise en place soit d’une image, soit d’un texte de remplacement.
Si le fichier est chargé, une valeur de classe est alors ajoutée à l’élément html, et vous permet donc de réaliser une classe conditionnelle en css :

<html class="access42-font">
<p>
  <span class="icon-help" aria-hidden="true"></span>
  <span class="sr fb-text">Mode d'emploi</span>
</p>
</html>
.access42-font .icon-help:before{
 content:"\F025";
}
.access42-font .fb-text{
 position:absolute;
 top:-10000em;
}

Ainsi, si ma police n’est pas chargée, l’icône ne s’affiche pas et le texte apparaît à la place.

Dans le cas d’images de décoration, le désagrément est surtout esthétique, quoique. Si on s’intéresse à des personnes ayant une déficience intellectuelle, la présence d’une icône peut justement venir expliciter les termes. Mais pas de souci non plus, avec ce script, vous pouvez aussi fournir une image html en alternative de l’icône qui ne serait pas chargée.

Consulter toutes les possibilités d’implémentation grâce au script A Font Garde.

Nous vous conseillons par ailleurs, la lecture des guides de l’UNAPEI sur la méthode facile et à comprendre, qui mettent en avant l’utilisation d’icônes pour expliciter, faciliter la compréhension des contenus pour des utilisateurs ayant un handicap mental ou cognitif.

Testons ensemble

Nous allons faire un petit test ensemble.

  1. Regardez le bandeau du haut du site Access42. Vous voyez deux boutons : un mode d’emploi et un configuration. Vous avez vu ? On continue alors.
  2. Rendez-vous sur la documentation de Firefox pour modifier les polices des sites web.
  3. Retournez sur le site d’Access42 et rafraîchissez la page.
  4. Regardez les boutons en haut. Vous voyez des caractères bizarres ? Vous avez perdu de l’information ? Non ! Les boutons mode d’emploi et configuration, ont été remplacés par des images pourvues d’une alternative texte. Ça marche bien ce petit script  :-)
Attention : il y a une légère amélioration à faire au script. Nous avons remonté une issue sur le dépôt GitHub concernant celle-ci. Pour réaliser le test de chargement de la police, le script va comparer la longueur de chaînes de caractères. Pour cela, le script va devoir injecter une chaîne de caractères de test, qui n’a pas de sens. Dans le script original, cette chaîne de caractères est lu par un lecteur d’écran. Il suffit d’ajouter un attribut aria-hidden="true" à cet élément.

Nous vous conseillons donc de modifier le script afontgarde.js, à la ligne 37, sur le modèle :
html = '<div aria-hidden="true" style="' + style + '">' + TEST_STRING + '</div>';

À notre tour de poser des questions : Avez-vous pensé aux contrastes ?

Un utilisateur qui a besoin d’utiliser d’autres couleurs, pour des problèmes divers dus à la vision des contrastes, va utiliser des styles personnalisés pour adapter l’apparence de votre site. Les styles personnalisés permettent de styler tous les éléments du site selon ses besoins : la couleur des polices, la taille des caractères, la couleur de fond, etc.

Styles personnalisés : svg vs icon font

Dans une feuille de style utilisateur, on va souvent venir remplacer toutes les couleurs de fond d’éléments. Si l’élément svg est défini en noir et que ma feuille utilisateur contient une propriété de fond de couleur noire pour tous les éléments, mon icône n’est plus visible.

Mon utilisateur peut modifier la couleur du svg, mais la marche à suivre n’est pas des plus simples :

  • Si l’élément svg est correctement formé, l’utilisateur doit pouvoir modifier la propriété fill du svg et définir la couleur.
  • Dans le cas d’un svg complexe, il faut non pas modifier la couleur de l’élément lui-même, mais la couleur du ou des éléments qu’il contient. Ainsi si le svg contient plusieurs éléments (path,circle...), il faut redéfinir ses éléments, et contrairement à une icon font, ces éléments ne sont pas prédictibles. On ne sait pas à l’avance si le svg sera constitué d’une droite ou d’un cercle. De plus, plusieurs attributs permettent de styler un élément contenu dans le svg : l’attribut style, fill, stroke, et encore une fois, ceux-ci ne sont pas prédictibles a priori.

La possibilité de modification des svg dépend alors de leur construction et de leur implémentation.

Avec une icon font, on ne rencontre pas ce problème. La couleur est définie uniquement par la couleur de police. Si l’utilisateur choisit une police orange sur un fond bleu, l’icône devient jaune et reste contrastée selon le souhait de l’utilisateur.

La question de la pertinence des icônes utilisées

Et si le problème était ailleurs ? Avez-vous pensé au fait que votre icône (svg ou autre) est incompréhensible pour tout le monde ?

Au final, la question n’est pas tant icon fonts, icône svg... que : est-ce que mon icône veut dire quelque chose pour tout le monde, tout handicap confondu ?

Une personne qui a des problèmes de compréhension, quelle que soit l’implémentation que vous avez choisie, c’est le même combat, elle n’y comprendra rien. Votre burger menu reste tout autant incompréhensible, et donc inaccessible.

Implémentez des title sur vos icônes, accompagnez les d’un texte visible, permettez à vos utilisateurs de désactiver les icônes pour n’afficher que le texte, c’est pour nous une problématique supérieure. D’ailleurs nous travaillons, chez Acces42, sur un mécanisme qui permettrait à l’utilisateur de désactiver l’utilisation des icon fonts au profit de simples textes.

Les icon fonts ne posent pas de problème au regard de l’accessibilité, si on prend la peine de le faire correctement.

En cadeau la police Access42, créée par nos soins grâce au script Font Custom et Inkscape  :-).