Il reste que dans les recommandations sur l’utilisation des sprites mentionnent rarement la question de l’accessibilité. Voir par exemple: http://developer.yahoo.com/performance/rules.html#opt_sprites

Du point de vue strict de la performance (au sens technique, pas commercial), utiliser les sprites y compris pour des boutons d’action sans intitulé fait parfaitement sens. Est-ce le rôle des publications sur la performance web de mentionner ce problème potentiel? Je pense que oui.

Il n’est pas question de cacher les intitulés pour les remplacer par un sprite (ce dont tu parles), mais d’ajouter une icone décorative à côté de cet intitulé pour aider l’utilisateur. Pas de problème spécifique d’accessibilité donc.

Qu’on soit clair, je ne parle PAS de remplacement d’image ici. Et ton problème d’accessibilité est lié au remplacement d’image, pas au sprite.

Sauf cas exceptionnel celui qui supporte CSS saura tirer profit des règles de positionnement de background donc ça ne posera pas de problème. Si tu te débrouilles bien, dans une majorité des cas tu peux trouver un moyen de positionner ton sprites pour que ça ne « casse » pas même si on augmente les taille de police. Bref, il y a des exceptions mais dans l’ensemble ça fonctionne sans dégats ici aussi.

Après dans CSS3 il y a des moyens de découper l’image précisément (au lieu de simplement la positionner avec le risque de voir les autres icones à côté) et de remplacer le contenu de manière propre (sans aucun risque d’accessibilité). Mais … en CSS3, donc pas pour tout de suite.

Je m’étonne qu’Aurélien ou Stéphane n’aient pas relevé — au moins à titre d’avertissement — les gros problèmes d’accessibilité potentiels. Ils parlent du cas des images de fond utilisées comme illustration (ou permettant de préciser un intitulé, mais dans tous les cas on a un intitulé), et du risque de voir apparaitre plusieurs icônes pour un même item, par exemple. C’est effectivement un problème (pour ne pas parler des sprites sous la forme de grilles qui demandent d’utiliser un élément vide en HTML si on veut réellement placer une image comme icône sans afficher d’autres images plus à droite, sous le texte), mais c’est loin d’être le principal.

Le principal problème, c’est l’utilisation d’éléments vides ou d’éléments au texte caché (liens et boutons sans intitulé ou liens et boutons dont on cache les intitulés en CSS) pour créer des boutons cliquables à partir d’une image de fond. Ce n’est pas un problème limité aux sprites, mais la technique des sprites incite très clairement à ce type de pratique. Il suffit de voir les images données comme exemple, dans lesquelles on retrouve souvent des boutons et icônes dont on peut supposer qu’ils seront utilisés sans texte HTML visible.

La technique des sprites serait réellement intéressante si elle permettait d’éviter cet écueil, c’est à dire si on pouvait:

1. utililiser l’élément IMG (avec attribut alt) pour afficher une portion d’image et pas l’image complète;
2. utiliser un mécanisme HTML ou CSS standard pour dire «telle portion de telle image est un équivalent strict du contenu de tel élément».

Vu qu’aucune de ces deux solutions n’existe, il y a un risque fondamental pour l’accessibilité des interfaces. Il appartient bien sûr à chaque intégrateur de faire les choses au mieux, mais vu les mythes sur les remplacement d’images accessibles largement répandus j’ai bien peur qu’attirer l’attention sur les sprites ne bénéficie aux performances qu’au détriment de l’accessibilité.

Sinon, dans l’absolu, propriété content + data URI + CSS variables/constants, peut-être un coup à jouer à l’avenir?

Reste donc le fait qu’on charge une grosse image pour potentiellement ne pas tout utiliser, mais là franchement c’est moi qui vais affirmer que si vous ne faites pas n’importe quoi, c’est plus que négligeables dans le cas qui nous préoccupe.

(Note: Anthony n’arrive pas à envoyer son commentaire, je ne sais pas pourquoi. Si quelqu’un est dans la même situation, envoyez moi un mail)
(qui n’arrive pas à poster de commentaire, je ne sais pas pourquoi

Maintenant un test objectif n’est jamais de trop donc je t’invite à tester, et à nous faire des retours si tu vois quelque chose d’étrange. Je doute cependant que cela puisse être un problème dans ce cas précis.

Je vais dévorer les autres billets, merci !

J’agrandis souvent les polices et urgl (comme on dit en bas-Ougrien).

C’est plus qu’un problème seulement potentiel, c’est un problème réel qui peut même induire des difficultés de compréhension du message véhiculé par l’icône.

J’aurais bien une saisie d’écran à fournir mais je ne sais pas si l’auteur du site en serait ravi.

(waouh mon premier commentaire ici, je peux mourir en paix maintenant) 😉

Le plus simple pour tester c’est YSlow, sinon un outil beaucoup mieux, assez récent, pagetest :
http://pagetest.patrickmeenan.com:8080/

C’est encore mieux que YSlow à mon avis (en tout cas au moins complémentaire car il utilise IE) car il affiche les vrais temps de réponse avec le détail au niveau du lookup DNS contrairement à YSlow, il fait des tests avec et sans cache, et en plus il est dispo online avec un client de test aux états unis.

Sinon, détail important, pour ceux qui se souviennent toujours du problème qu’a IE6 avec les images de fond qui clignotent. Pensez à activer le cache, j’ai pu observer mon design apparaissant tout lentement, deux images à la fois.. images qui sont bien évidemment les même. Ce qui n’était pas terrible pour des ombres portées (de la mort).

Concernant le surcoût de la bande passante, c’est vraiment négligeable comparé au gain en termes de requêtes HTTP. Une requête HTTP, c’est un échange entre le client et le serveur, éventuellement le serveur doit faire un fork, il y a plusieurs accès disques (le fichier demandé, les .htaccess…), etc. Du coup, le plus souvent la phase de préparation du fichier prend plus de temps que le transfert en lui même. Il faut vraiment être dans un cas extrême pour que ça mette plus de temps (on parle des images de l’interface là, ce sont de petites images en général). Donc même si on gagne quelques millisecondes, en compressant mieux les fichiers, elles seront gâchées dès la première requête HTTP supplémentaire.

Pour vous en convaincre, vous pouvez vous amuser avec le full page test de Pingdom, que je trouve assez génial : http://tools.pingdom.com/fpt
Je ne sais pas si vous connaissiez ? Il montre de manière détaillée le chargement complet d’une page. Leur blog est intéressant aussi.

Reste tout de même qu’après il faut souvent repasser derrière l’outil pour afiner la compression, avant d’envoyer le fichier sur le CDN, donc l’url n’est pas forcément encore fixée pour l’outil. Ca n’est pas insurmontable ceci dit.

Merci pour l’URL

En tout cas d’après des tests effectués, c’est LE conseil performance qui permet de gagner beaucoup de temps.

Les thèmes wordpress et autres vont sûrement s’y mettre et livrer une version avec un seul sprite css pour tout le thème.

Ensuite c’est en effet un compromis entre la multiplication des requêtes HTTP et la fréquence d’utilisation des images.

Si tu met bien une expiration explicite sur tes images statiques, que tes pages utilisent toutes une douzaines d’images de fond, il est probable que le gain sur les requêtes compense facilement la différence de poids due aux images non utilisées.

Maintenant effectivement, si tu as peur de ne pas tout utiliser tu peux faire des sprites par thématiques ou par section.

Mais dans l’ensemble, de ce que j’ai pu constater, en cas de doutes il y a plutot intérêt à aggréger qu’à séparer. C’est simplement du au fait que pour toute requête tu as au moins un aller-retour réseau de 30 à 100ms et 1ko entre les entêtes de requête et les entêtes de réponse, et 1ko encore pour le contenu de l’image.
Au final le surcoût de bande passante pour faire passer d’un coup 10 icones dans l’image est assez faible sur le coût total de l’image initiale. Si tu n’utilises pas tout ce n’est pas très grave. Par contre si tu as besoin de lancer une nouvelle requête, là le surcoût est important.
Bien voir aussi que ce sprite servira aussi aux futures requêtes vers le même site, donc peut être que les icones surnuméraires seront utilisées dans les autres pages.

La chose est donc intéressante si on a de nombreuses images dans la page et que l’on les utilise toutes (ou une grande partie).