Anyone can test a web page or even an entire site for accessibility. The necessary knowledge isn’t PhD level or even too vast. It does require familiarity with HTML and CSS, the ability to appreciate the unique challenges faced by users with various disabilities, and an understanding of the W3C Accessibility Guidelines. Beyond that, all you need is the desire and time.
Step 1 – Validate HTML and CSS
This step may come as a surprise to many. After all, wouldn’t invalid code either not work or leave a visible bug? Actually, the answer is not necessarily.
The reason can be that some WISIWIG editors generate invalid code and hard-core programmers who write their code by hand can easily omit some bit of HTML or CSS “grammar”. This doesn’t mean non-functioning code it just means it doesn’t meet the standards. I won’t go into specifics here, just think of it as sort of similar to formal collegiate writing. There is a particular standard which is expected. A paper could be written differently, more “free form”, it could contain all the ideas and arguments, and it could be just as well thought out – but because it doesn’t meet the standard it would not get a top grade.
Validating your code has a number of advantages. It decreases the probability of cross browser problems, it tends to eliminate or reduce so called code bloat, and valid code tends to be easier to maintain as well as being compatible with a broader range of assistive technologies used by people with disabilities.
Step 2 – Automated Accessibility Testing
Automated accessibility testing is an often misunderstood step in the overall process. To some it is everything that needs to be done. “My site is Bobby compliant. Doesn’t that mean it’s accessible?” To others it’s a red herring and should be avoided all together. My take is that it’s an invaluable step. When writing an article I rely on the spellchecker to catch my typos even though I know I still need to go through and check out the copy myself to make sure I have written “Dave” and not “Cave”, for instance. Automated testing finds many issues which could easily be missed by reading the code and so I always begin with it.
Depending on the scale of your project you might be able to use one of several free web based validators or you may opt to buy one of the testing packages available on the market.
The report you will get will include tests which cannot be run by the validator but which it flags for manual examination. Make sure to go through these as well. Most of the tools will describe the issue enough for someone with the above mentioned prerequisites to test.
And lastly, make sure to have any issues raised, fixed before continuing. Doing so will greatly reduce the time required for the remainder of testing.
And please, I cannot emphasize enough that automated testing alone cannot assure accessibility. Please continue with the steps below.
Step 3 – Keyboard Testing
This a simple but very important step. Hide you mouse and navigate your web site using only your keyboard. If you have never done this then you are likely to learn something.
Various groups of people can’t or don’t want to use a mouse. For some it’s just confusing or difficult, especially those with certain motor control problems or sometimes seniors. For others, like blind web users, it’s impossible. Making sure every link, form field, button, or any other functionality in the page is accessible via the keyboard is a basic necessity of web accessibility – but you may also find that to get to the main content or primary form on the page you need to click the Tab Key many times. Though technically accessible, this is extremely inconvenient.
Again, be sure to make any changes required which this phase of testing brought up before continuing.
Step 4 – Screen Reader Testing
To conduct screen reader testing you will need to install the necessary software . It will take some time to get used to and configure your screen reader so be patient. Begin by simply turning off your monitor and listening to your page. Does it make sense? Many web designs depend on visual cues and can get close to unintelligible when those cues aren’t available.
Next, try to carry out one or more of the tasks your website was built for. If it’s an online store, find a product and make a purchase. If it’s an informational site then find key information. Remember – this is the reason you built the site and it is the reason you are making it accessible. If it core functionality depends on a complex form, can you tell which fields are required? If it’s a shopping cart, can you see how much you have spent before making the purchase?
Step 5 – Target Audience Testing
Various conventions of web design have emerged in the course of the World Wide Web’s short existence which we have grown used too and even depend on to help us navigate a new site. Links appear in a different color (often blue) and underlined. Site wide or global navigation is usually found along the top of the page. Small pictures can often be clicked to get a bigger one. Similarly, there are conventions used in quality accessible design but naturally those of us who aren’t dependant on accessible design may not be aware of them. These might include links, sometimes invisible, along the top of a page which allow the user to skip to various parts of the page, colors with high contrast values or just consistent design throughout the site.
Web accessibility isn’t just fulfilling a set of requirements or validating against predefined checkpoints. It also means quality design. And just as it’s best to leave questions of browser based user interface design to an expert it’s best to have your site checked over by an expert in screen reader user interface design when considering accessibility. And though in theory, there is no reason a sighted specialist couldn’t become such an expert, one who is dependant on screen readers will more likely be intimate with their functions and use, the frustrations of poor web site design and solutions which ease or eliminate those frustrations in practice, not just in theory.