Tools for Conducting an Accessibility Review

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.

WAVE Toolbar

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.

Two other fantastic resources for picking accessible color combinations: Snook Colour Contrast Check and Contrast-A.

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.

Firebug

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.

Text browsers

In order to see what a non-styled no-images version of the site looks like, I’ll break out Lynx (for PC) and Lynxlet (for Mac). These text browsers are also useful for figuring out whether all links and form elements are accessible. Because Lynx doesn’t handle javascript either, this is a nice method of judging whether or not a page’s scripting degrades gracefully. The version of Lynx I’ve linked to is an already-compiled version which makes it easy for us non-programmers to use. I prefer to use the Mac version because it lets you cut and paste URLs into the terminal window; in Lynx you have to type it all in by hand.

NoSquint

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.

Links Bookmarklets

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.

Keyboard

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.

Summary

So those are the tools I use. What tools do you use to conduct an accessibility review?

This entry was posted in Featured and tagged , . Bookmark the permalink.

12 Responses to Tools for Conducting an Accessibility Review

  1. Pingback: uberVU - social comments

  2. Scott Williams says:

    In addition to the tools you’ve mentioned, I also use AChecker: http://www.achecker.ca/checker/index.php

    Scott

  3. Joe Chidzik says:

    I use IE for the majority of my testing, although after reading this great article, I’m going to give it a go with FireFox\Firebug :) (I do use FF for personal stuff, but use IE with the WAI toolbar for testing).

    One thing that IE still does, and no other browsers do afaik, is to strictly obey the font sizes in the stylesheet. If they are set in pt\px, IE will not resize the text; Firefox, Safari et all simply scale the font size regardless. For this reason, IE is useful for highlighting which websites fail on the 1.4.4 checkpoint: text must resize without the use of 3rd party products, or use of the browser zoom function.

    Fire up IE, set the text-size to largest\smallest and see if any of the text on the page resizes. If it doesn’t, this could be problem for low vision users.

    Another method I use is to switch Windows into one of the high visibility colour schemes (I’m assuming other OS’s have similar choices). A good basic rule with CSS is when setting the foreground colour for an element, always set the background colour as well, and vice versa. If you don’t do this, and someone is using a high visibility colour scheme, any element with only the background colour specified in CSS will adopt the foreground colour of the high-vis colour scheme.

    This can lead to situations where white text is displayed on a white background making it impossible to read.

    Really useful list of browser add-ons, online tools and tips, thanks!

  4. Jared Smith says:

    A very complete list. We use many of these same tools as well. We use the full version of JAWS and often NVDA for screen reader testing, though it’s rare that an actual screen reader identifies issues that are not found through other, free tools available. I use our color contrast checker at http://www.webaim.org/resources/contrastchecker/ to check colors – not because it’s better than the ones you listed, but because I just prefer it and like not leaving the browser. Colorzilla is an invaluable tool for collecting color values from pages (including images). Of course tools are not a full replacement for accessibility knowledge.

    We’re thrilled to see WebAIM resources at the top of the list!

    • Angela says:

      @Jared

      I’m eager to check out NVDA, but I’ll agree that the effort I spend getting up to speed on using JAWS, etc., takes so much time that it hardly seems worth it. Particularly when, as you say, you can use other means to find out the same things.

      Thanks for the info about the WebAIM contrast checker and Colorzilla. I haven’t used them before.

  5. Char James-Tanny says:

    One Firefox add-on I really like is “Web Developer”. It adds a menu (that I never use) and a toolbar with a lot of apps…disable JavaScript/CSS, only show alt attributes, resize window, links to various HTML/CSS/accessibility checkers, and more.

  6. G F Mueden says:

    Both Microsoft and Am Fdn for the Blind have text entry boxes that fail to respect the visitors choice of fonts as set in his software. One site has a repeater box that displays what i write using the font it knows I want. That lets me catch my errors. This page on which I write now has a very wimpy font compared to the font on the rest of the page. I will send a screenshot to anybody who asks for “checker”. gfmueden@verizon.net
    ===gm===

  7. I agree with your approach of avoiding using a screen reader for testing and instead falling back on the standards and code review.
    We use most of the same tools you have mentioned above. We toss in total validator &/or sortsite & vischeck for color blindness related stuff.

  8. dani says:

    You may try WebAnywhere, a text-to-speech online. And maybe you need to add W3C Mobile Checker or ready.mobi to Web Developer tools section.

  9. Pingback: uberVU - social comments

  10. Pingback: Tweets that mention Angela Colter » Blog Archive » Tools for Conducting an Accessibility Review -- Topsy.com

  11. Pingback: Illinois Information Technology Accessibility Act - Topic Research, Trends and Surveys