My Accessibility Testing Tools

Recently I was asked how I go about testing the accessibility of a website, something I have only done seriously for a few months. I use a combination of checklists, tools and common sense to draw up a document that explains where things are going wrong and provides guidance or tips to correct the problems.

Here I discuss the tools of my trade with advice thrown in for free.

1. The Ideal Solution

The most obvious way of checking a site’s accessibility is to get users with various impairments to do a round of testing. However, this method generally falls way outside of the majority of projects’ scope, usually due to funding issues. Therefore, I will skip this step and get on to the freebie methods anyone can have a go at.

2. Validate your code – (X)HTML and CSS

This is required for a number of reasons:

  1. Since the beginning of Web Standards Time (WST) we have been preached at to use valid code
  2. It ensures forwards compatibility in new browsers
  3. Makes your debugging life so much easier
  4. Finally, and most importantly, if you want your site to comply with all Priority 2 checkpoints you must have valid code (see Checkpoint 3.2)

Use the validator from the W3C which is found at validator.w3.org/. This application takes either a live URL or a local file and can only check a single file at a time.

3. WCAG Checkpoints

It is a good idea to be familiar with the list of checkpoints provided by WCAG so that you can have them in your mind as you are reviewing pages. I have these printed out on three A4 pages stuck to my cubicle half-wall (an excellent addition to Pimp-my-cubicle) so during those (rare) moments of boredom perhaps they will sink into my subconcious.

You can view the full WCAG checklist or a more detailed look at the checkpoints.

It is well documented that satisfying all checkpoints is impossible, so I usually go for all of Priority 2 and as many of Priority 3 as necessary.

Priority 1: A Web content developer must satisfy this checkpoint.
Priority 2: A Web content developer should satisfy this checkpoint.
Priority 3: A Web content developer may address this checkpoint.

That said, accessibility testing should be about more than just satisfying each checkpoint – usability has an important part to play as well.

A guideline simply offers guidance to what the best practice is – it shouldn’t just be applied without regard to other factors.

webcredible.co.uk

4. Test de Accesibilidad Web (TAW3) – Stand-alone version

This accessibility testing application can be downloaded for free at tawdis.net, instructions for use can be found at the same location. I use it to speed up the process of going through each checkpoint – it’s basically an automation tool.

It is used by typing in a URL and it will step through the site (if you specify to follow links) and check against the WCAG 1.0 checkpoints and report on where they have/may have been broken. It will bring back a lot of ‘maybe’ points because accessibility testing can never be fully machine automated as there are too many items that need human eyes for verification, such as:

  • Checking that simple language has been used (14.1)
  • Has the document been structured to it’s fullest? (3.5)
  • The use of lists where appropriate (3.6)

5. Color Contrast Analyser

As the title gives away, this tool checks that the difference between 2 colours are of sufficient contrast for visually impaired users. This could be the contrast between background and text or between 2 colours of an image providing content (i.e. a map).

Colour Contrast Analyser can be downloaded for free at wat-c.org, you’ll find it at the bottom of that page.

6. No Styling

Get a copy of Firefox with the Web Developer Extension or use IE with the Web Accessibility Toolbar, and use it to disable all CSS styles. This will show your site’s true colours (without colour of course) and you should make sure everything still makes sense and is usable.

7. Screen Reader

This last section is really just a luxury, screen readers cost money and none of the most popular are available free for download. If you are fortunate enough to have a copy of a screen reader such as JAWS or HomePage Reader, then just pass a few pages through it and see if you are able to make sense of what comes out.

Final Note

Accessibility is much more than just ticking off a list of checkpoints! You must look at accessibility while keeping in mind usability. You shouldn’t plough ahead with ensuring a single checkpoint is satisfied at the expense of being able to use the application.

Tags:

4 Responses to “My Accessibility Testing Tools”

  1. Chris Lienert says:

    Firefox extension Fangs (http://www.standards-schmandards.com/index.php?show/fangs) provides a handy way to see what a screen reader would make of your site. Obviously it’s not the same as a real screen reader, but it’s a handy tool regardless.

  2. Emma says:

    Fangs Firefox extension – from the URL above it took about 50 clicks before downloading the actual file!

    I had trouble getting it to work straight after downloading, but I checking for updates fixed that. It does look useful and I’ll test it out on my next project.

  3. JacKP says:

    I’ve written a "ten minute accessibility testing" article myself a while ago (http://www.thepickards.co.uk/Articles/Testing_Accessibility.cfm) . These won’t catch everything – but they’re my ‘quick n’dirty’ tests — a couple you’ve not mentioned, if you don’t mind me sticking my 2p in where it’s not wanted — checking your site is usable without a mouse, and checking that the test resizes easily. And I’ll add further support to TAW3 while I’m on as well.

  4. paul haine says:

    I remember someone at @media this year asking Robin Christopherson about Fangs, and whether it was a viable replacement for JAWS when it came to testing for accessibility — he didn’t think so, and pointed out that JAWS is available for free as a time-limited trial, so you may as well use that instead.

    He also touched upon your final note — that accessibility wasn’t just like checking a list of validation errors. For instance, you can pass a checkpoint that says ‘make sure your text can be resized’ even if resizing that text makes your website or application completely unusable…

Leave a Reply