Lately I’ve been working for a unique client that understands the importance of accessibility, but they view it as a black and white issue. It’s not entirely their fault, but that’s a rant for another day. The core problem is that they equate accessibility to making a site usable by people using a screen reader. If only real accessibility were that easy.

Making a web site accessible for those who can’t see pixels on the screen is important, but for every blind person using a computer, there are (probably) dozens more that we also need to think about, the gray area. These are the people who may have difficulty reading the average well-designed web site. Accessibility for these people is as important as accessibility for the sightless.

These are the people who don’t need a “skip to content” link, but need high contrast, large text pages that are easy to navigate. Liquid layouts and clever design will get you part of the way there, but ultimately, to provide real accessibility you’ll probably have to create an alternate format that these users can use.

So, in the interest of accessibliity, you’ve carefully crafted a primary style and it’s gray area cousin. Your code is clean and accessible, so finally you can step back and admire your beautifuly accessible site right?

Well… almost. You’ve done the legwork, but there is still one major accessibility (and usability) problem. How do you get your gray area users to their version of the site? It’s doubtful the client is going to go for the idea of putting a big black and white button next to their logo advertising the alternate version of the site (it’s not that important to them). There’s really not a place for an accessible link in your standard site design. If only there was a way that we could detect those users that would require the alternate version of the site without the requirement of a link to initiate the switchover.

Introducing Auto Style Switching.

Most average users tend to keep their browsers set to the default font size because this is what most developers design for (or maybe it’s the other way around). Our gray area users have the option to increase the font size globally on all web sites. Those who need a larger font only need to tell their browser to user a larger font.

Using a bit of Javascript we can detect the size of 1em in pixels and judge it’s size relative to the default. This isn’t an exact science since there will always be a variation between browsers and configurations, but we don’t need to be pixel accurate here. If it is beyond a threshold we trigger our high contrast style sheet (using the script by Pault Sowden).

See it in action

Handling the Resize

Although the majority of users will be entering our site with their font size already set to their liking, it is certainly possible that a user might change their font setting after already loading the page.

In Internet Explorer, changing the text size reloads the page (therefore trigering the window.onresize event). So, we could just add that to our initialization:

 window.onresize = window.onload = checkContrast;

Of course it’s never that easy. Safari and Firefox don’t seem to trigger any DOM event so there is no way for us to find out if the text size has been changed.

We could call it a day and accept that we’ve provided support for the majority of users, or we could use setInterval to check our text size a few times a second as a work around. It’s not very elegant, and it almost crosses the line into what might be considered a “hack”, but the setInterval solution is the only one that works for all browsers.

In the end I opted to be as accessable to as many people as possible, which means using the setInterval solution. I check the test area five times a second which should be often enough to provide reasonable feedback, but not so often as to make much impact on our available processor cycles.

See it in action

Allowing Users the Choice

As a last step we should add a link to our site that allows the user to toggle the style that they are presented with. We can work this into our design now without too much fear that those who need it won’t be able to find it. This has been covered in many places, so it’s not really worth reexamining it here.

Variations On a Theme

You don’t need to use the text size to trigger style sheet changes, you could trigger any other interface. Perhaps instead of switching styles, you present a dialog notifying the user of the alternate style, or even send them to a different location.

Additionally, we don’t need to create a binary switch between normal and alternate versions of the site. We really are in the gray area of accessibility. A clever developer can use the realative size difference to adjust the site, triggering variations based on font size using different style sheets, or directly changing the styles of elements. What would you do?

This entry was posted on Monday, July 17th, 2006 at 7:21 pm and is filed under Technique. You can follow any responses to this entry through the RSS 2.0 feed.