baroug

L’article signale cette ressource intéressante pour les personnes qui utilisent ce genre de typos : ▻https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html

Résumé :

– Quand on utilise la zone Unicode réservée aux trucs privés, si la fonte se charge mal, on a soit des rectangles pourris, soit des icônes n’ayant rien à voir (emojis, etc). Et si les utilisateurs (dyslexiques par ex) forcent une fonte propre à leur besoin, pareil, ça nique tout.

– Quand on fait bien les choses et qu’on utilise le bon caractère Unicode correspondant au dessin que l’on veut utiliser : beaucoup de lecteurs d’écran lisent la description du dessin ! Et le seul moyen de l’enlever est d’ajouter du « aria » dans le HTML en plus. Cela peut marcher dans certains cas, mais du coup impossible d’ajouter des icônes uniquement en CSS, dans le thème graphique.

Filament a produit une librairie utilitaire contenant CSS et JS nécessaire pour utiliser des fontes d’icônes de manière accessible :
▻https://github.com/filamentgroup/a-font-garde

Mais dans la solution de Filament, dans TOUS les cas d’utilisations, ils demandent à utiliser du HTML supplémentaire spécifique à l’icône. Donc d’après moi, c’est un peu pourri : impossible de faire le choix des icônes (ou pas) uniquement dans le thème graphique…

Sur le long terme, j’ai l’impression que la solution serait que tous les lecteurs d’écran prennent correctement en compte la propriété speak:none.
De cette manière, il suffirait :
1) d’utiliser un bon caractère unicode correspondant au mieux au dessin de chaque caractère de notre fonte d’icône (Fontello permet ça par ex), comme ça le fallback visuel serait bon (sauf s’il n’existe pas et dans ce cas faut utiliser la méthode fallback par image de Filament… galère)
2) d’appliquer sur tous les :before où on veut ajouter une icône, la directive speak:none

Mais actuellement même Caniuse.com ne contient pas les statistiques des propriétés orales de CSS… Il y a un ticket pour voter pour ça ici :
▻https://github.com/Fyrd/caniuse/issues/1515

Voilà, comment est-ce que vous allez faire à l’avenir vous ?

En ce qui me concerne, cela fait de nombreux mois que désormais mon HTML ne contient plus de scories pourries en rapport avec l’aspect graphique, que je n’utilise plus de classes genre « icon », « grid », ou je sais pas quelle merde comme ça, et que j’ajoute tout en CSS grâce aux préprocesseurs (exemple : a.super_lien{ @extend .icon; @extend .icon-super; }).
Du coup la solution de Filament m’embête vraiment…

#accessibilité #icônes #fontes #fonts #intégration #HTML #CSS

Et tiens cc @notabene @nhoizey pour intégration/accessibilité.

Pour ma part, les pictos sont en SVG inline, tout simplement. Si je devais me préoccuper de fallback (je parle de mes projets perso uniquement), j’utiliserais <picture> avec une source SVG et le fallback en PNG.

Merci @rastapopoulos pour le ping, je pensais l’avoir dans mes propres liens, mais ce n’est pas encore le cas…

Nan mais si c’est un truc avec des couleurs, etc, ben oui c’est une image, on l’utilise comme une image. Les icônes en fonte pour moi c’est clairement pour les pictogrammes : qui justement doivent suivre UNE couleur choisie en CSS (celle du texte courant très souvent, et parfois une autre), et à utiliser pour différencier des liens, des boutons, etc, tout en restant sobre.

[ Éditer ] [ Supprimer ]
versus
[ ✎ Éditer ] [ ✖ Supprimer ]

Et dans ces cas là, le fait d’en vouloir ou pas, et le fait de vouloir tels ou tels pictos : c’est un choix du thème graphique. Donc pour moi c’est entièrement au thème graphique de les activer ou pas, et de choisir quelles images ou pas. Sans RIEN changer au HTML (qui ne contient que des classes permettant de différencier le sens de divers liens par exemple, pas leur aspect : « supprimer », « favoris », « inscription », etc).

Le fait de devoir mettre des <img> (ou même des <span> vides) dans le HTML pour afficher des icônes et non des vraies images, c’est totalement carrément plus du hack (comme il dit dans le lien de départ), qu’utiliser des fontes en CSS. Le fait d’avoir ces pictos, c’est une aide visuelle pour aider à mieux distinguer certains éléments pour celleux qui ont des yeux, mais le lien ou bouton lui c’est juste « Éditer » (par ex).

Ah et faut ajouter (et ça a été écrit dans les commentaires) que les fontes informatiques, avec unicode, ont été faites pour contenir des lettres ET des pictos. Donc ce n’est absolument pas un hack du tout, c’est parfaitement prévu, et donc c’est aux navigateurs (visuels ET auditifs) et aux normes web (CSS), de savoir les gérer comme il faut.

Après pour les interfaces où on a des liens ou boutons qui n’ont QUE l’image/picto, là c’est encore autre chose. Mais pour le coup ça pose encore plus de problème ergonomique avant même l’accessibilité : une image seule, tant qu’on ne connait pas l’appli ou le site, difficile de savoir à quoi ça mène (et maintenant dans tous les trucs tactiles on a pas de bulle de survol puisque pas de survol, mais même pour celleux qui ont une souris, ce n’est pas normal de devoir déplacer sa souris un peu partout sur l’écran pour savoir ce que fait l’interface !), donc sauf cas rare et très précis, c’est pour moi de toute façon une mauvaise pratique.

Pourquoi les pictos devraient-ils n’avoir qu’une seule couleur ?

(oui, je sais, les fontes multicolores arrivent…)

Pour ce point, Fontello fait déjà tout ça pour toi, comme IcoMoon mais en logiciel libre et gratuit. Tu peux importer tes SVG perso, puis les sélectionner comme caractères, et leur assigner un code unicode. Ensuite ça te génère la fonte dans plein de formats, et le CSS qui va avec (comme IcoMoon encore une fois).

Une réponse là ▻http://seenthis.net/messages/435520
Mais qui ne prend pas en compte vraiment les problèmes d’accessibilité (juste utiliser le PUA ne suffit pas, puisqu’il y a le problème des fallbacks, et des polices forcées autrement). Or ce sont ces problèmes dont parlent en priorité l’article de départ.

L’explication plus technique de comment ils fonctionnent chez Cloudfour :
▻http://seenthis.net/messages/457318