We spend a lot of time on the very basics. It takes a lot of effort just to make Firefox accessible with the various tools out there, to create the polished experience that people with disabilities want. We struggle to create new standards to allow the future dynamic web to be accessible.
But what about the web itself? Content needs to be accessible, right? Too many web pages don’t bother, probably because of lack of awareness or knowledge of the issues, or a concern about the amount of work involved.
Fortunately, there are tools to help developers that are willing to try them. What web accessibility testing tools exist for Firefox?
- The Firefox Accessibility Extension from the University of Illinois. This one
- The WAVE toolbar from WebAIM (please help review so they can get out of the addons sandbox!)
- WAT toolbar (being ported to Firefox, not available yet). If you want to check it out now, try WAT for IE.
- The Color contrast analyzer also from the WAT folks, has the beginnings of a table and live region analyzer. Eventually this will become part of the WAT toolbar.
- TAW3 from Fundación CTIC, an automated checker that creates a report from the page.
Outside of Firefox, there are others, such as the IBM Rational Policy Tester Accessibility Edition (what a mouthful!) — formerly known as just “Bobby”. Feel free to add a comment about any tools you like (or don’t).
Major Opportunities to Improve
Accessibility testing could become part of mainstream tools like Firebug or the Web Developer Toolbar. This would raise awareness quite a bit, as these extensions are used by millions of developers. We’d need to do a good job of finding a natural way to integrate into the features that already exist. For example, the Firebug HTML view could highlight incorrect markup or accessibility violations. There could be a quick search for various kinds of markup, and we could have a log of errors can help developers jump back to the root source code which caused the problems. We can learn from accessibility tools that visualizing problems right in the page content is very useful. And in general, if we’re to successfully integrate, we need to have a high signal to noise ratio — developers will ignore a11y errors if they are not accurate and important.
Another place to improve is Web 2.0 and AJAX accessibility testing. Current generation accessibility tools expect static pages. As we know, the web is not static. The new tools need to help developers add the right WAI-ARIA markup to put meaning to the dynamic chaos.
Finally, we can use open source methodologies and work together better as a community. Why should there be so many independent efforts? Let’s pool resources this time around. IBM, the Paciello Group and the University of Illinois are already in discussions about how we can work together on a new generation of tools. The plan is share and reuse code as much as possible, and make features available both in mainstream and specialized accessibility tools.
Where do we go from here?
Please share your insights. We need as many perspectives as possible!
- Which of the current generation of accessibility tools works best for you and why?
- What are the best features of each tool?
- What are possible integration points in mainstream tools like Firebug?
- Where do current tools fail
- What features would help you test AJAX or Web 2.0 accessibility and WAI-ARIA (JavaScript widgets, live regions, drag and drop, landmarks, etc.)? (Feel free to ask me if you want to know more about this new area).
Feel free to dream.
Access Garage 
There is no excuse for NOT testing web pages using a screen reader. The test “browse non-visually” could educate web developers as well as the excellent tools you list.
NVDA, non-visual desktop access, from http://nvacess.org is free, open source. Could some of the test tools be integrated with this screen reader, e.g. to beep on the silly “click here” link text? NVDA, like all other screen readers, will have trouble with some web page features but will work sufficiently on most pages to reveal glaring errors. My favorites are: lack of H headings, redundant navigation links, and complex use cases. Compare the original and accessible Amazon pages to execute the simple use case to buy a book you already know you want.
Warning: while NVDA is trivial to install, testers might need to experiment with better voices available for about $30.
P.S. I am visually impaired, not a professional tester.
Hi Aaron.
While learning about accessibility and extracting good practices from the Web Content Accessibility Guidelines, I found tools like Cynthia Says useful for quick checks. Beyond that, I use various features of the Web Developer Toolbar for testing accessibility. Here’s a useful article about that: Evaluating Web Sites for Accessibility with Firefox.
I also use the Web Accessibility Toolbar for IE for some tests, like colour contrast testing and sometimes for readability scoring.
You mentioned validation, Aaron. The HTML Validator extension for Firefox has an option to include accessibility warnings in its results based on WCAG checkpoints. I’ve also just discovered the Total Validator extension for Firefox which includes accessibility warnings too, but seems to be of limited value for daily use.
I think it’s important to say that it is about educating users as much as educating developers. There are extensions and plugins out there such as the Text size toolbar and the RNIB Surf Right toolbar that are helping to make useful accessibility features more prominent in the browser’s UI by putting it in the chrome rather than having them hidden away in menus and dialogs.
While it’s great that there is screen reader software freely available to test with (even JAWS and Window-Eyes have time-limited demo versions), I’ll have to disagree with slger about testing. Testing web pages with a screen reader as someone without decent knowledge of typical screen reader features and knowing enough about actual user behaviours can result in false positives and false negatives. I’ve been using screen reader software for some time (my sight is fine) and I know JAWS pretty well, but I do not consider myself to be a suitable replacement for user testing with disabled people.
Back in the days of Firefox 1.5 there was a Firefox extension called Fangs that opened my eyes to accessibility issues. When activated on a web-page it would read through the DOM like JAWS, only instead of reading the page contents via a text-to-speech engine it would just put the text into a text-box with only a minimum of formatting to highlight the land-marks a visually-impared user would use to navigate (headings, links, etc.)
It was great at presenting accessibility issues in a way that sighted individuals could immediately grasp – I even used it once to show a manager the accessibility implications of two alternative site designs. Unfortunately, the extension wasn’t updated to work with Firefox 2, let alone Firefox 3, and I miss it.
@Screwtape
Fangs for Firefox 3 is available:
http://www.standards-schmandards.com/2008/fangs-for-firefox-3/