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.

Navigation methods in mobile web usability

During my experience testing mobile websites, it has become apparent that users are split on their preferred navigation style. I have come to realise that this is a complex issue to resolve. Normally as a usability consultant, consistency is something which I regularly find myself recommending to clients. While the same principle applies in mobile sites, it may be better to alter the design according to the type of handset the user owns and keep the style consistent throughout their experience.

The split related to the type of navigation style used and how well each method worked: a traditional search form or a 'drill-down' type of navigation. The 'drill-down' method allows the user to search for something by selecting a series of options or answering a number of questions, similar to a decision tree.

Using a search form is the ideal solution for some. It is common on the web and therefore familiar to users across multiple platforms. It also gives them a sense of control. Most importantly users perceive a search form to be the quickest route to a set of results. This is most attractive as users always want to find information in the quickest way possible.

However, search forms were originally designed for the web and not for mobile browsing. Not all mobile phones have full keyboards therefore typing on a mobile phone is not as easy or convenient. It is made even more difficult when trying to type on the move or with one hand, for example, the URL may use characters not commonly used during day to day texting. Also, someone commuting to work by bus/train for example is less liked to have both hands free. In this situation, a system which allows someone to navigate with one finger would be easier to use.

So which navigation works best? The answer is both but is dependent on the type of handset being used and maybe even the users' experience with that device. Sophisticated mobiles such as the iPhone can cope much better with traditional websites. Older phones or phones with small screens cannot manage full scale pages as well and this forces the user to scroll horizontally. While Blackberry's and other PDA's have more keyboard functionality, many have to contend with a limited number of buttons.

In a situation like this, longitudinal diary style studies would provide valuable feedback from users who experience the mobile web in real life situations. The findings would go some way to resolving the split between searching traditionally and drilling down through a site. It would also help to determine which mobiles work best for each navigational style.