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.
Conclusion
Website accessibility is something every company and
organization needs to consider if they have or are planning to have a web
presence. It’s not only morally correct but it increases your potential
customer base and it is increasingly becoming the law.
Testing doesn’t need to be difficult or expensive. Depending
on the scope of your site compliance can be achieved entirely in-house by
following the steps above. If you haven’t got the available resources or feel outside,
expert help is required there are a number of consultants from which to choose.
One should be aware, however, that the services rendered can range from
automated testing only (perhaps appropriate for a web development team which is
not particularly knowledgeable in accessibility issues but able to understand
and implement post test recommendations) to full, regular audits costing 10’s
of thousands (possibly appropriate for a company with a large and regularly
changing website such as an on-line auctioneer or a newspaper). It is vital,
therefore, to understand one’s needs and know which service to seek.
For any larger testing effort target audience testing is key.
Unfortunately, most accessibility testing companies don’t offer the service,
and some don’t even offer screen reader testing.
Resources
Free
Online HTML & CSS Validators
HTML Validation (http://validator.w3.org/“>http://validator.w3.org/)
CSS Validation
(http://jigsaw.w3.org/css-validator)
Free
Online Accessibility Validators
WebXact (http://webxact.watchfire.com)
Cynthia Says (http://www.cynthiasays.com)
Automated Accessibility Testing Software
InFocus (http://www.ssbtechnologies.com/products/infocus/index.html)
Bobby
(http://www.watchfire.com/products/desktop/accessibilitytesting/default.aspx)
Screen
Readers
JAWS (http://www.freedomscientific.com)
IBM HomePage
Reader (http://www-3.ibm.com/able/solution_offerings/hpr.html)
Miscellaneous
W3C
Accessibility Guidelines (http://www.w3.org/TR/WCAG10-HTML-TECHS/)
Accessibility
Testing and Target Audience Testing Solutions
(http://www.pageaccessibilitylabs.com)
Nik Page has been working in SEO, website accessibility and usability testing since the early 90’s.
He is currently General Manager of Page Accessibility Labs