accessibility vs. alpha transparency

When we get new toys, we use them... and use them... and use them... Sometimes the problem with new toys is reminding ourselves when not to use them.

Web development is no different. Support for new CSS features means we can start using things like rounded corners, font embedding and proper transparency/opacity - straight from our stylesheets.

New toys, in other words.

Some of these will create merely aesthetic issues (ready for ten-font websites?), but transparency can easily create accessibility problems for your site.

Using transparency has the side effect of reducing contrast; and for some reason it just feels like low-contrast thresholds kick in a little earlier than they do with straight colours. I'm sure it's just the "I wanna use the new toy!" factor, but there it is all the same.

contrast testing after transparency

So how fast do we hit trouble? I did a quick contrast check of black-on-white text with alpha transparency (using rgba colour). I started with opacity 1 (not transparent) and stepped through in 10% increments. Opacity 0 is included purely for the sake of completeness.

Testing alpha transparency - black text on white
rgba Hex Example Swatch CCA Luminosity Test
rgba(0%, 0%, 0%, 1.0) #000000 Example   Passes
rgba(0%, 0%, 0%, 0.9) #1A1A1A Example   Passes
rgba(0%, 0%, 0%, 0.8) #323232 Example   Passes
rgba(0%, 0%, 0%, 0.7) #4C4C4C Example   Passes
rgba(0%, 0%, 0%, 0.6) #666666 Example   Fails 1/4 tests
rgba(0%, 0%, 0%, 0.5) #7E7E7E Example   Fails 3/4 tests
rgba(0%, 0%, 0%, 0.4) #999999 Example   Fails
rgba(0%, 0%, 0%, 0.3) #B3B3B3 Example   Fails
rgba(0%, 0%, 0%, 0.2) #CDCDCD Example   Fails
rgba(0%, 0%, 0%, 0.1) #E5E5E5 Example   Fails
rgba(0%, 0%, 0%, 0) #FFFFFF Example   Fails

So with this simple test, applying 0.6 opacity means you're already into trouble; and 0.5 and below is an accessibility failure. There's only a completely "safe" zone of three steps down from fully opaque - and that's using black and white.

Keep in mind you will hit problems much faster with colours that are closer together. Watch out for the corporate favourite blue-on-blue.

what about backgrounds?

The colour issues are the same for backgrounds, but in practice there's a good chance you'll also be revealing an underlying graphic.

In that case you have to check your foreground colour against several sample points in your background - make sure you get both the lightest and darkest regions.

You also need to consider legibility - is the image interfering too much? Admittedly that's subjective, all I can suggest is it's likely we can't show our nifty background nearly as much as we'd like.

every old problem is new again

It's true that contrast problems aren't new, and there have been clumsy ways to use transparency for quite a while as well. However rgba and hsla colour are easy to use and now available in all good browsers (plus a hack for IE).

Growing acceptance of progressive enhancement is also fuelling the desire to use new features and push web design forwards.

So now that it's easier to implement, it's reasonable to expect an increase in designers and developers experimenting with layering colour and images. That means we need to be sure we catch the potential issues.

solving the problem

No matter how you build a site, you should check the final colour combinations carefully. Even if you already do this, you need to check your tools as not all of them can evaluate transparency.

For example the Juicy Studio Firefox extension read all ten transparencies in my test as pure black, incorrectly giving them all a pass for contrast. Although it's convenient for quick checks of basic colour, the extension currently doesn't evaluate transparency or check the colours in images.

To avoid these issues I recommend using the Paciello Group's Colour Contrast Analyser which is based on the same contrast standards, but offers an eyedropper selection tool. That way you are certain that you're testing the actual output, regardless of the technology you're using.

One good thing about contrast checks is they're not even slightly subjective - use a contrast checker, it will give you an answer (even when your monitor is screwing up your colours). It's a good point to remember when your designer is disappointed they need to change their design - it's not opinion, it's a simple fact.

last thoughts

It's easy to get caught up in the moment when trying something new, but we need to keep a level head and make sure the final product still works. There is nothing stopping us using hsla and rgba, so long as we don't throw out basic accessibility along the way.

The purpose of web pages is to convey information, and accessibility guidelines are there to make sure we do that for everyone. There's no point putting together a technically clever site if the content disappears into a low-contrast mess.

Comments

  1. Anonymous John Faulds, September 11, 2009 9:32 am: 

    Interesting point about the Juicy Studio extension, I wasn't aware of that. But then I've only ventured into using RGBa once so it's not really been an issue up to now..

  2. Anonymous Richard - Accessible Web Design and Test, September 16, 2009 3:16 am: 

    It's also worth noting here that pass fail levels are different for AA compliance and for AAA compliance, and that there are other factors involved like the size of the font.

    I would also highly recommend the Colour Contrast Analyser app, having used it and previous versions for several years now. The latest version did come out just before WCAG2.0 was finalised though so in fact although it fails at <5.0 luminosity contrast for level 2, the official WCAG2.0 figure is 4.5 (which is slightly more forgiving).

    Even using that tool it can be difficult to analyse properly, particularly where fonts are small and antialiasing means that adjacent pixels within a letter form can be significantly different colours.

about

Web development and standards, as seen by Ben Buchanan.