Press "Enter" to skip to content

Category: JavaScript

CSS Sprites vs. High Contrast Mode

Using positioned background images (a.k.a CSS Sprites) has a number of benefits:

  • Performance. One of the performance recommendations made by Yahoo’s performance team is to reduce HTTP requests. One way to do this is using the CSS Sprite technique — combining many images into a single background image.
  • Skin-ability. With the img tag the image URL is in HTML markup where it is hard to change. With CSS Sprites the image URL is in a CSS file making it more convenient to change. Sure you can change the contents of the original file but there are reasons for changing the URL. It is not as easy to move the images to a different server or group them in different image files when the URL is not in CSS.

However there are drawbacks. The biggest is accessibility, specifically high contrast mode. In high contrast mode all background images and colors are ignored — replaced with high contrast colors such as white on black or black on white. The other issue is that background images are not always printed.

The prevailing accessibility advice is to not use background images for functional images. The underlying problem is that there is no way in HTML/CSS to identify a background image as being functional. They are all considered decorative. It is also true that not all img tag images are functional but again there is no way to distinguish them for the purpose of high contrast mode. So high contrast mode makes a reasonable assumption that background images are decoration to be removed and img images are functional and must be shown. From here on I’ll call functional images icons. They either convey important information or are interactive (like a toolbar button for example).

I have seen recommendations that functional background images should be replaced with text when high contrast mode is detected. This does not seem right to me at all. A desktop app does not change its toolbar button icons to text in high contrast mode. The assumption is that icons are already designed to have reasonable contrast.

It also just feels right to me that the icon URLs should come from CSS.

Since I care about performance and accessibility I’m not happy with this conflict. I want a solution that puts the icon URL in CSS, works in high contrast mode and allows me to combine icons into a single image file. Here is what I came up with.

Comments closed

Comments on “Life above the Service Tier”

I have read Life above the Service Tier a few times now. Its a very good paper, one that really changes your perspective, but I wish it was better. If you work on web applications and you haven’t read this paper I recommend that you go read it now — but do come back.

I agree with the overall reasoning and the conclusion.

So one obvious way to correct the thin client architecture is to implement a true MVC framework on the client side… That means that all “Presentation Flows” must occur within the currently ­loaded web page… So one workable model is the Single Page Application (SPA).

First let me get some minor complaints out of the way.

5 Comments

More button woes

The HTML button element has given me trouble in the past. My conclusion was to not use the button element except to progressively enhance the look of buttons. This means the button would initially be an input of type button and JavaScript, if enabled, would change it to a button element.

Well at work I’m working on an app that requires JavaScript and all form submissions are done with JavaScript already so I thought it would be safe to switch over to <button>. The server never uses the button names or values (all needed information is in other inputs – hidden or otherwise) so the IE bugs should not be an issue.

This time the problems I found were exposed with Firefox but the real problem was in the web app code even if the browser behavior was surprising.

2 Comments