CSS Sprites and Accessibility

Yahoo’s Best Practices for Speeding Up Your Web Site lists minimizing HTTP requests as the very first recommendation. One of the ways they suggest doing that is by using CSS sprites (which I mentioned previously in Clever Ways to Save Bandwidth).

I recently applied this technique to a series of social media icons. Here’s an example:

The example page uses a single image to display 8 separate icons from the following single image:

CSS sprites of social media icons

Be careful when using background images as links. Since there is nothing inside the anchor element, what appears if the image fails to load, or if the user agent is a screen reader? I added descriptive text to the title attribute of the anchor element. According to Dive Into Accessibility’s article, “Adding Titles to Links”, reading the title attribute is an optional feature in the JAWS screen reader that is not enabled by default. I tested it using a recent demo version of JAWS 12, and it read the title attributes without any settings adjustments. However, in a text-based browser, or with CSS or images disabled, the links will be completely invisible.

Google, in the following example, uses icons in conjunction with text. The icons add to the experience, but the site is still fully functional without the images:
Partial screenshot of Google's search options

What is the gain from this effort to speed up a site?

There’s the reduction in file size–from 20.3 kB to 3.98 kB in my social media icon example, just 20% of the original file size–although part of that is due to a reduction in the overall number of colors. 8-bit images can have at most 256 colors, so the 8 icons share all 256, and are consequently not as true to the originals. Using CSS sprites for logos of different shapes and sizes, or for informational icons, might be a better use since the color palette would be shared.

Google’s sprites are again a good example that combines both logos and informational icons:
Google's CSS sprites

In kilobytes it is still a small savings compared to the bandwidth requirements of most of today’s pages. The savings are just for the initial page load though, because the browser will use cached images on subsequent loads. The user agent still makes a call to the server with every request, thought the server will reply with a short message (304 Not Modified).

There’s still a round-trip between client and server. How long does that take? From my high-speed connection, only a couple milliseconds. From a mobile device? I haven’t tested it, although it is worth trying. The speeds on my 4G mobile device are still excruciatingly slow, so improving speed to mobile devices would go a long way to improving the mobile experience.

Overall, using CSS sprites seems like a trivial savings–one that the user will not notice, one that the server can manage, one that makes the images more difficult to maintain, and one that may reduce accessibility. If your site has extremely high traffic volumes it might be worthwhile to reduce the number of requests to the server, but overall it doesn’t appear to be particularly effective. Feel free to disagree in the comments.

2 thoughts on “CSS Sprites and Accessibility”

  1. While reviewing the comments on High Performance Web Sites: Rule 1 – Make Fewer HTTP Requests, I saw a discussion between Adam Fisk and Steve Souders regarding the bandwidth saved. As Adam points out, the savings comes primarily from the request and response headers, which he finds pretty minimal (as do I).

    Steve’s reply is that the request headers include cookie data, which for many sites could be substantial. Sure enough, the request headers on this WordPress site include cookie data, which makes each request header for each file over 1 kB. If your site makes 30-50 requests, that adds up.

    As with most things, analyze your site (I used the Net panel on Firebug to get a quick idea of the number of requests and the size of the request and response headers) to see how much you’d gain from combining images. It may or may not be worth it.

  2. As Chris said–it’s less about the kB saved. Transfer rates extremely fast. It’s the connections. Most browsers have a fixed number of connections it allows at one time (see: http://loadimpact.com/blog/browser-behaviour-and-performance)

    Internet Explorer 7 will only open max 2 concurrent connections to a webserver, while Internet Explorer 8 will open up to 6 concurrent connections.

    That means if you have to load many external files, that will substantially slow down the load of your site.

    There is a reason every major site uses css sprites.

    You make very good points on usability. We are coping with this at my company, trying to make a good compromise between accessibility and performance.

Leave a Reply

Your email address will not be published.