I was interested to read, on the RNIB website, that there are an estimated 2 million people with significant sight loss in the UK, 70% of whom have other disabilities or long term health problems in addition to their sight loss.
That’s a really interesting statistic, because it highlights the fact that when we try to take into account the needs of disabled users, we often aren’t talking about individuals with just one disability. People will often have a combination of needs, and we must respond by designing for this diversity, rather than taking a locked-down, ‘one-size fits all’ approach.
A good real world example of this was when I worked in a library. The library had an easy access PC terminal, offering the following features:
- Raised desk to allow wheelchair users to get nearer the keyboard
- Large-key keyboard
- Trackball mouse
- Screen reader software and headphones
- Screen magnification software enabled by default
Although provision of these facilities was excellent, there was a problem in that often the combination of all of these features proved a barrier in itself. For example, a regular blind user found it difficult to use the large-key keyboard as they were used to a normal keyboard, the layout of which they were instinctively familiar with. Thus, the keyboard was great for users with impaired vision, but not so great for blind users, who had to ask for help finding the location of certain keys (in fact, many keys had been left off completely).
What we quickly realised was that people needed the ability to customise the set-up according to their needs. So we had a normal mouse and keyboard on standby for anyone who requested it, advertised by large-print and Braille posters next to the terminal and backed up by regularly monitoring the terminal to offer assistance. Not the ideal solution, but better than nothing.
This is just as true for web products – we can all too often be guilty of making assumptions about our users and designing solutions based on those assumptions, rather than thinking about real world users. A good example of this is skip links. We know that screen reader users like to utilise skip links, but too many sites hide these links, making them hard to find for sighted keyboard users (for example, those with limited motor skills meaning they can not easily use a mouse). Even worse, when skip links are visible, they are often presented as tiny text, presumably so as not to confuse or distract other users. But what about non-mouse users who have impaired vision and can not read tiny text?
WCAG 2.0 recognises the challenge that all this presents:
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas.
…and it is a reasonable caveat. However, that doesn’t stop us doing all we can to take into account as many different scenarios as possible, and not making assumptions which cause more harm than good. Offering the ability to customise the page in a variety of ways, or at least not blocking the user’s own browser preferences, is crucial. And, as always, user testing remains a vital ingredient.
I’ve probably raised more questions than I have given answers here, but I hope to do more research on this subject soon, so stay tuned.