Icones Fonts et accessibilité

De plus en plus de sites proposent des tutoriels et des listes de fontes “graphiques” pouvant être intégrées dans des pages web grâce à la quasi-universelle propriété CSS3 @font-face :

—-

C’est la mode !

• http://css-tricks.com/examples/IconFont/
• http://icomoon.io/app/
• http://fontello.com/ 
• http://kudakurage.com/ligature_symbols/

Avantages

Les avantages de cette méthode sont multiples :

• les icônes sont vectorielles, donc agrandissables ou rapetissables sans dégradation visuelle,
• elles sont stylables et modifiables en clin d’oeil, juste en CSS (couleur, dégradés, ombrages, rotation, etc.), c’est parfait pour la maintenance de son site,
• il est plus pratique de manier une fonte unique que de multiples images ou d’avoir à créer des sprites,
• il n’y a qu’un seul fichier de police à charger, donc une seule requête HTTP.

EDIT : et SVG dans tout ça ?

Le format SVG pourrait avantageusement remplacer cette technique de polices-icônes puisqu’il est vectoriel et donc librement agrandissable sans pertes.

Malheureusement, son support actuel est encore délicat puisque seule la récente version IE9 le supporte avec le reste du monde. Il serait donc nécessaire d’ajouter une ressource JavaScript pour le simuler (donc une requête, du poids et une baisse de performance). De plus, à ma connaissance, un format SVG n’est pas intuitivement stylable en CSS comme le serait un caractère de texte.

Et l’accessibilité dans tout ça ?

Certes, un caractère typographique n’est pas une image et ne bénéficie pas de l’irremplaçable attribut “alt”.

Cependant, je trouve à cette technique au minimum trois avantages que n’ont pas les images classiques :

• la possibilité d’agrandir l’icône sans perte de qualité visuelle est un atout pour certains mal voyants ou déficients moteurs,
• un pictogramme de ce type s’adaptera automatiquement à un affichage réglé sur contraste élevé, ou selon des prédispositions colorimétriques,
• la modification intuitive et rapide via CSS favorise l’emploi de feuilles de styles utilisateurs personnalisées.

Le problème des lecteurs d’écrans

Il fallait un hic et le voici…

Dans la pratique, une icône-fonte va généralement être intégrée de cette manière en HTML :

En supposant que l’élément span contiennent un caractère “t” d’une police d’icônes correspondant visuellement au pictogramme “Twitter”. Si tel est le cas, la lettre “t” sera lue par les synthèses vocales.

Par exemple VoiceOver et NVDA prononceront toujours « t » + « un truc », ce qui peut devenir perturbant. Et c’est bien ça le problème.

Quelques ressources en disent plus sur le sujet :

• http://filamentgroup.com/lab/dingbat_webfonts_accessibility_issues/
• http://yatil.net/a-better-way-to-use-icon-fonts

Un moyen de s’en sortir ?

Je n’aime pas rester sur une impression d’inachevé. J’ai donc cherché et testé un certain nombre de techniques (voire bidouilles) pour obtenir le résultat tant espéré : un pictogramme “accessible”, c’est à dire dont l’information est restituée de la meilleure manière possible et sans gêne à l’écoute.

Mes tests ont été effectués sur VoiceOver (sur iPhone4) et NVDA 2011.3 (sur Firefox 10) (voir tous les tests en fin de billet).

title

L’attribut title désigne une infobulle, qui peut être lue dans certaines conditions par les lecteurs d’écrans, ce qui peut être pratique pour contrer la lecture de notre “t”.

Sur les exemples suivants, VoiceOver prononce “un truc chouette”, et non “t”, ce qui nous arrange :

Mais il prononce “t” sur cet exemple si l’icône est apportée via :before (voir plus loin) :

Après quelques tests, il s’avère que title n’est lu que lorsque le lien était complètement vide ou non restitué. Ce c’est pas forcément ce que l’on veut obtenir finalement.

:before / :after

CSS 2.1 offre la possibilité de générer du contenu à l’aide des pseudo-éléments :before et :after (devenus ::before et _::afte_r en CSS3). Cela semble parfait au premier abord pour ajouter du contenu non pertinent qui ne doit pas être restitué par les synthèses vocales.

Pas de chance : lorsque l’icône est appliquée sur a:before {font-family: icon; content: “t”}, la lettre “t” est quasiment toujours prononcée sur VoiceOver et NVDA, ce qui ne nous arrange pas.

Une solution est de l’appliquer sur un élément interne tel que span ou abbr pour que “un truc chouette” soit restitué par VoiceOver :

Cependant, on déchante vite sur NVDA : il prononce systématiquement le contenu généré, soit la lettre “t”. Aucun de mes essais de masquage de cette lettre parasite n’a été concluant sur cette synthèse.

speak: none

Supprime le rendu vocal d’un élément (peut être écrasé par l’un de ses descendant). Malheureusement reconnu ni par NVDA ni VoiceOver (et sans doute d’autres), donc assez peu utile sauf en bonus ajouté à une autre technique, en espérant un éventuel support dans l’avenir.

aria-hidden=”true”

aria-hidden compte parmi les états (states) proposés par la spécification WAI / ARIA. Il permet aux lecteurs d’écrans et aux agents utilisateurs de ne pas rendre perceptible un contenu et sa descendance.

Il est actuellement très bien reconnu par VoiceOver, mais pas du tout sur NVDA.

Il semble cependant que WAI / ARIA fasse partie des priorités d’un bon nombre de synthèses vocales et on peut gager que leur support à moyen terme s’améliore grandement. J’ai envie de parier là dessus.

role= “presentation”

Un landmark ARIA moins intéressant que prévu : correspond à du contenu non pertinent mais lu quand même.

role= “image”

Un autre landmark ARIA apportant une sémantique spécifique d’image à un élément. Associé à aria-label, il permettrait en outre d’ajouter du texte alternatif.

Tout serait parfait s’il était reconnu par les lecteurs d’écrans, ce qui n’est pas le cas 😦

@media speech et aural

Tels les célèbres médias screen et print, il existe des médias destinés aux lecteurs d’écrans : speech (CSS3) et aural (CSS2, désuet).

Leur support est extrêmement faible (à l’exception d’Opera et quelques ovnis) et ça ne semble vouloir s’arranger. Bref, à oublier pour l’instant.

C’est un peu dommage : une spécification existe, elle est capable de répondre parfaitement à des besoins d’accessibilité, mais… elle n’est pas supportée par les synthèses vocales.

Conclusion

Mes tests sont forcément peu fiables puisque seuls deux lecteurs d’écrans ont été mis à contribution.

Ma conclusion personnelle est qu’à l’heure actuelle, je n’ai trouvé aucune solution réellement multi-plateformes pour éviter le désagrément de la lecture d’une lettre parasite.
Cependant (et c’est là que vous pouvez troller ou me taper), il me semble que l’on est plus dans le domaine de la “gêne” que d’une méthode non accessible : tout le contenu pertinent est bel et bien restitué si l’on emploie l’une des deux techniques suivantes :

• Version picto + texte (recommandée) : Un truc
• Version picto uniquement :

De plus, il est à espérer que aria-hidden=”true” sera bientôt pleinement supporté par toutes les synthèses vocales, ce qui règlerait (définitivement ?) le problème.

Si vous avez réussi à lire ce billet jusqu’au bout, votre avis sur le sujet m’intéresse grandement.