This article will discuss different ways to Validate and Test your projects for Accessible criteria, including using standard web browsers and screen readers. I'll also list some of the more popular testing tools I've come across.

This is the third in a series of planned articles dealing with Web Accessibility. In this series I will cover what is Accessibility, how to build Accessibility into web projects, how to test and validate for Accessible users and some other factors to keep in mind when dealing with Accessibly minded projects.

Validation

Validating that your site matches a certain Accessibility standard can be a tricky proposition. Ideally you would have identified what standard of Accessibility the project must meet. Is it WCAG A or AA? In this way you can clearly define what criteria you need to test against.

In the testing tools section below there are several tools that allow you to pick an Accessibility standard and test against those specific criteria.

Another way of testing is by emulating the variations of the user experience. You could do this by turning off images and disabling Flash and JavaScript.

Another angle on validating your site is to actually try the other browser variants your disabled user may be using to surf your site. Using a text only browser such as Lynx would show you valuable insight.

There is also a handy screen reader emulator plugin for Firefox, called Fangs (http://www.standards-schmandards.com/projects/fangs/, it shows you the relevance of page elements very well.

Similarly using a screen reading browser like Jaws (http://www.freedomscientific.com/products/fs/jaws-product-page.asp) will show you a totally different site experience. For enabled users switching to use a screen reader can be quite a shocking experience.

When using browsers like these test to see if your sites information is as easily available using the text or voice browser as it is using a GUI browser. It will give you valuable insight into how people are may actually be using the site. It will also show you the differences in prominence between visible elements and elements marked as more important with meta data, such as headings etc.

NOTE: I have never seen a site pass Accessibility validation whilst fail on W3C markup. Make sure your code is well structured, and that you are following the regular best practice for coding.

Testing

After implementing any Accessibility changes you must be able to demonstrate that you have measured you changes against defined testable success criteria. Bear in mind that you may not only need to implement coding changes to a project, but also show the tests involved in validating those changes.

In much the same way as you might test for browser compatibility the key here is to test early and test often. It is much easier to test as you go through a project, discovering any issues as you progress, rather than finding a large volume of Accessibility issues as you reach the end of the project life.

NOTE: One simple 'gotcha' here is your document type definition. WCAG testing will throw up massive amounts of validation errors if you have defined a document as xhtml, and not closed every element, even down to the self closing /br tags. Vice versa is also true, so pick a document type, and stick to it.

Testing Tools

I've been using Total Validator for a while now, it's quite flexible, and allows you to pick specific levels of compliance for testing. You can test individual pages using an online interface, or buy the desktop application.

There are of course a huge variety of testing tools, a few of the more popular ones are WAVE from WebAim, and the W3C markup validation service here: http://validator.w3.org/

The W3C has a huge list of tools here: W3C tools

If you are working with a client the key here is to discover what they will use to test for coding standards and Accessibility validation. If your chosen test suite contradicts a clients test results then all your work has been for nothing.