As part of my usability consulting practice, I’m sometimes asked to conduct accessibility reviews of client web sites. The purpose of the review is to identify barriers on the page that would prevent someone who has a disability–who is using an assistive technology or some other adaptive strategy–from using or understanding the content on the web page.
Because the Web Content Accessibility Guidelines (WCAG 2.0) are pretty extensive, and because there’s no tool that will automatically identify all the accessibility barriers in a web page, I use a variety of tools to help me figure out where the barriers are and what’s causing them.
Your first choice should be to have people with disabilities test your website to ensure that it’s accessible. Having me or any other consultant who doesn’t need an assistive technology review a web site is a distant second. Doing an expert review can give you a quick, cheap read on the major accessibility barriers that people are likely to encounter. But to know for sure, ask someone who uses a screen reader, screen magnifier or the keyboard only to check your site.
Now, on to the tools I use to conduct accessibility reviews …
WebAIM WCAG 2.0 Checklist
The guidelines are very extensive–regardless of whether you’re shooting for Level A, AA or AAA–and a little hard to understand. I always keep WebAIM’s WCAG 2.0 Checklist open as a quick reference for what I should be looking for and recommendations for meeting the success criteria.
The Web Accessibility Evaluation Tool is a free service courtesy of the folks over at WebAIM. You can visit the WAVE site and enter the URL of the page you want to check or upload a file if the page isn’t on a publicly available server. But I like using the WAVE toolbar in Firefox. This allows you to evaluate the page as it’s rendered in your browser, which is useful for password-protected or dynamically generated content.
The output of the evaluation shows the original web page with icons that indicate possible accessibility problems and elements you should take a look at to make sure they’re implemented correctly. I like to use it at the beginning of an evaluation just to get a sense of what I’m in for and where I need to pay attention. The Structure/Order View option identifies tells me whether the page uses properly marked-up headings and where they are. The Text-Only View option gives a nice sense of whether a non-styled version of the page makes sense.
Functional Accessibility Evaluator
The Functional Accessibility Evaluator by the University of Illinois at Urbana-Champagne is also a free service. This site produces a report that categorizes the possible accessibility issues (such as “decorative images”), how many instances are on the page, how many instances “fail” and how to correct the failures. Because the FAE uses a combination of guidelines (WCAG, Section 508, Illinois Information Technology Accessibility Act) I don’t use the report it generates verbatim because it may not apply to the guidelines I’m using, but I do find it useful to point out what needs to be investigated further and suggest what to do about it.
Firefox Web Developer Toolbar
I use several of the options in the Web Developer Toolbar. My favorites are Disable Styles (to see if an unstyled page still makes sense), Disable Images, Display Alt Attributes, and Validate HTML.
Contrast Analyzers from Paciello Group and Juicy Studio
The Paciello Group Contrast Analyser is a great little widget that lets you take foreground and background color samples in a web page and determine whether the ratio is sufficient according to WCAG 2.0 guidelines. But sometimes I find that the color that I’ve selected with the widget’s eyedropper tool isn’t exactly what the page’s style sheet says it is.
The Juicy Studio Contrast Analyzer takes the colors specified in the page’s markup and style sheets to determine the ratio. I think this makes it much easier to communicate the source of the problem with developers, but what I find difficult is using the report–which lists every color combination on the page–to figure out which foreground/background pair it’s referring to.
Fangs Screen Reader Emulator
Because I don’t have a vision impairment, I don’t rely on testing with screen readers (like JAWS, Window-Eyes, NVDA, etc.) to identify accessibility barriers. I simply wouldn’t use them the way a person with a vision impairment would. Not to mention the fact that screen readers have a pretty steep learning curve. I prefer to work with a colleague who does have a vision impairment and who does use a screen reader to tell me where she finds barriers. But sometimes it is useful to demonstrate how a screen reader might interpret a given element on a page in order to illustrate why the current approach is a problem. For that, I like to turn to the Fangs Screen Reader Emulator. All I have to do is visit a page, run Fangs, and I get a sort of transcript of how a screen reader is likely to interpret the page. Now here’s a big caveat: screen readers have different “modes”; the mode you’re in will affect what’s read aloud and whether your keystrokes are interpreted as commands to the screen reader or text to go in a website’s form field, for example. You can’t manipulate the mode in Fangs. Even so, I find myself using this nifty tool all the time.
How I ever did accessibility reviews without Firebug, I’ll never know. This little Firefox add-on will do lots of things, but I use it to look under the hood of the page’s markup to find out what styles are being applied to a particular element. Here’s an example of how I used it recently. I was reviewing a page and it looked like the headings were placed in images. Not acceptable as far as WCAG 2.0 goes, but it’s accessible for some assistive technology users as long as you include an alt attribute. The problem was, I couldn’t locate the alt attribute; I couldn’t even locate the image in the markup. I used Firebug to figure out that particular <div> element was styled with a background image. It would have taken me a while to figure out which of the multiple style sheets used on that page contained the styling for that particular <div>. Firebug identified it immediately.
One of the WCAG 2.0 guidelines–1.4.4 Resize text–states that:
“Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.”
Because most browsers don’t give you an easy way to resize text by a specific amount, I use the Firefox add-on NoSquint. It adds a little widget to your browser window that lets you specify the percentage to resize.
Any time I’m trying to convey the notion that text links need to make sense out of context, I wish I had something that would let me pull up a list of links on the page. People seem to get the importance of descriptive link text when they see a list full of “learn mores” and “click heres.” I never had a good way of showing this until I found Subsimple’s link bookmarklets. Just right click on the link to save the bookmark to your favorites. Then trigger the bookmark on the page you want to test. It won’t work if the page uses frames or invalid markup, but if that’s the case you have bigger problems to attend to.
But probably the technique I rely on most often is simply putting the mouse away and tabbing through the site using only my keyboard. I make sure every link and form element takes focus, in a logical way, and can be triggered using the keyboard.
So those are the tools I use. What tools do you use to conduct an accessibility review?