Accessibility - More than just checking the boxes

With the new WCAG 2.0 guidelines in full flow, I find myself presenting a number of introductory courses to clients, analysing the new guidelines in some detail.

At the beginning of each course though, I always stress that whilst the course itself is all about the guidelines, the same can't always be said of Accessibility. Time and time again when testing with disabled users, the real issues, the real bona-fide, "can't go any further" barriers are not necessarily attributable to violations of the guidelines themselves. Meeting guidelines and making your site accessible doesn't always go hand in hand, nor should it.

I'm not suggesting we ignore the guidelines. Of course we should adhere to them. What I am saying is that we shouldn't view the guidelines in isolation. By all means, audit against the guidelines but if you want the real insight, straight from the horses mouth so to speak, then you should really test your site with disabled users.

As a general rule, disabled users encounter more issues than able-bodied users. Not only do they experience the same usability issues but they also have an additional layer of difficulty on top, whether that difficulty is caused directly as a result of their disability or by badly marked up pages, poorly presented content or inadequate assistive technology.

As designers, developers (and occassionaly even as accessibility specialists) we often make assumptions about the types of difficulties users with disabilities will encounter. I never fail to be surprised during disabled testing when a user fails to fall over what looked like a glaring hurdle. Conversely, I am also never surprised when a developer tells me that their site is fully accessible only to find that it is almost unusable for users with particular disabilities.

The key thing to bear in mind is that technically accessible is not always accessible in practice. Building a fully accessible form - labels, logical tab order, properly titled buttons, optimised error messages - is one thing. However, if you give this form 40 fields then at the very least it is laborious to navigate for keyboard and screen reader users. For users with a severe physical disability, entering information into 40 fields may become virtually impossible.

The guidelines stipulate that we must provide text equivalents for non-text content. Again, this should be easy enough to achieve. Do this incorrectly however and the constant reading out of over-elaborate and unnecessary alternative text may result in blind users giving up and potentially using a competitors site which doesn't suffer from additional "noise".

Still on the subject of blind users, many navigate using the 'links list' in JAWS or the equivalent in Hal or Window Eyes. Clearly naming your hyperlinks is a requirement of the WCAG guidelines but there is a world of difference between clearly naming then and sensibly naming them. Many a time I have witnessed a blind user looking for contact detail access the links list and press 'C'. After all, pressing 'C' to jump to 'contact us' would make sense, right?

Of course it does. Except if the link to your contact page is labelled 'Talk to us' or 'Get in touch' that is. When pressing 'C' doesn't bring up the required link, it's guesswork time and the blind user ends up pressing random keys or (as is usually the case) listening through all of the links until something sounds right. Testing with disabled users gives us this critical insight into not only which tools are available to them, but exactly how they use them in their day to day interactions with the web.

These examples are only a handful of many similar experiences, gathered from hours of testing with disabled users. Any one of these issues taken in isolation should be enough to highlight the merits of disabled testing. The fact of the matter is that any project where disabled testing takes place regularly highlights numerous accessibility barriers either of the same severity or of a greater severity than those detailed above.

And no amount of 'box checking' is going to solve them.