March 15, 2012

Web Accessibility Pays Off in Spades … or Why You Shouldn’t Count on JavaScript

Every web designer tries to make their sites as usable, understandable, and beautiful as possible.  Web accessibility is the practice of ensuring that you site is equally usable and understandable for all people, including the disabled.  It may not be obvious, but many of the web accessibility best practices will help you create a a site that is actually better for all users, not just those people we generally think of as disabled. 

Consider a very common disability that doesn’t usually jump to mind when you say “disabled”: color blindness.  About 7% of men and .4% of women in the united states have some form of color blindness. Because of this, it is not a great idea to use color alone to signal some special functionality on a web page. But “color sighted” users shouldn’t have a problem, right?  Well, not every monitor is properly calibrated and on some low cost LCD monitors your users may have trouble distinguishing colors that are plainly different on your screen.  Even high contrast colors may not show up in black and white printouts of your site.

Setting aside color blindness, let’s look at the much more serious case of total blindness.  In the early days of website development, i.e. the 1990’s, vision impaired users employed screen reading software to translate web pages to spoken language.  These early readers did not support JavaScript.  Consequently, one component of web accessibility has traditionally been to make sure your site will work without JavaScript.  That has change recently though.  A 2010 survy of screen reader users shows that the vast majority of screen reader users have JavaScript enabled.  So, no need to worry about that anymore.…right?  Well, not so fast.

If you rely heavily on JavaScript with no fallback, it is very easy for a small bug somewhere in your code to disable your entire site.  This very thing happened to Gawker Media in 2011 and put a number of top ranking web sites offline for a few hours.  JavaScript dependent sites can fail miserably leaving you with a blank page that isn’t always easy to debug.  If you plan from the start to have a non-JavaScript fall back for all key functionality, you won’t have this problem.

This week I spent some time going through NITRC.org to make sure we didn’t have any obvious accessibility issues. During the investigation I did find some select lists using for sorting reports which required JavaScript to run properly. Users without JavaScript (for whatever reason) would not be able to sort of filter the reports.  Not a huge problem, but it is easily fixed:

<select name=“xxx” onchange=“this.form.submit();”>
    <option>A</option>
    <option>B</option>
</select> 
<input type=submit value=“go” class=“hide-with-javascript” />
<script>$(“.hide-with-javascript”).css(“display”,“none”);</script>’

It is a very simple change and “regular” users who have JavaScript enabled won’t even see the added button because the JQuery script snippet will hide it.

Another web accessibility best practice is providing “Alt” tags for images.  The Alt tag provides a text description of the image. Originally this was used so that screen readers could describe the image to a blind user. Now these Alt tags provide valuable meta information to search engines trying to connect users with your content. Doing this consistently can push your site higher in Google’s search results.

The recent push towards mobile web sites ties in well with the accessibility concept also.  What might work fine on a 21” monitor with a good mouse does not usually work on a 4 inch smart phone screen. Web accessibility recommends using large “click targets” to support users with impaired motor skills. But keep in mind that large targets will help all your users when they are tying to get something done on your web site using a phone or tablet.  Especially if they have to poke at the tiny screen with their finger on a bouncing commuter train.

If you are interested in learning more about Web Accessibility guidelines at the W3C’s Web Accessibility Initiative site.