Accessibility: The perils of ignorance.

The article that sparked an idea for this post was around the usage of Captchas to prevent spam bots from accessing sites by Santhosh Tuppad (he’s a great blogger; go and subscribe to his blog if you haven’t already).  Now I find this interesting because I did a lot of accessibility testing for my previous employers, and made some assumptions about the end users which later surprised me, when I’d got the chance to actually meet and test with a real blind, end user.  So naturally it got me thinking about why we make such strong assumptions, in regards to accessible users using our products.

I find it surprising that the software development industry as a whole is often guilty of replacing the word guideline, with standards, when they look into accessibility guidelines such as the Web Content Accessibility Guidelines (WCAG).  We are all guilty of this to some degree.  We take it as a standard, and assume that as long as we follow this standard, we’ll be fine.  Now we all know that standards never work!   Even with the best intentions, they are misused, misinterpreted, not read, ignored, and disregarded (because we’d thought of a better way!), need I go on?  If you really want to amuse yourself at peoples misinterpretations of a standard, go read Martian Headsets by Joel Spolsky, it’ll make you laugh, cry, and despair when you realise that this happens with everything that we’d considered a standard at some time.

The fact is, that for accessibility, those few countries that have chosen to enforce it to some extent, still insist on developing their own guidelines, or standards, which basically extend the already too detailed WCAG.  Take my home nation Britain for example, who decided to develop such a standard, this BS 8878 standard, can be yours for a bargain £100 (yeah right!)  You’ll take nothing new from it, as it basically extends WCAG once more, and for that pleasure you’ll be slightly poorer, more confused, and probably need some training course, or expensive consultant to make sure that you’re doing it correctly anyway.

So with the slight rant over, I’d like to get to my point.  Creating an accessible product, is all about meeting the needs of your end users that will use its accessible features.  You can have all the guidelines catered for in the world, and be compliant with any standard you choose to follow, what you can’t ensure though, is that this accessible product you’ve developed, is usable for its target audience.  Guidelines and standards don’t get you that!  Real user feedback does.

When I first started testing products for accessibility, my previous employer wasn’t concerned with general accessibility issues, the main goal for them was creating a usable product for visually impaired users.  As such my main objective as a tester, was to consider the needs of visually impaired users when testing the product.  We had lots of discussions, and read lots of guidelines (mainly WCAG).  As far as we were concerned our main objective was to ensure that the tab order on our websites worked, and perhaps make sure that we provided suitable alt text for any graphics.

I did my best to shift myself into the shoes of a visually impaired user, and for the most part I did a pretty decent job.  Things which later came to light as major issues when we’d eventually hired a real visually impaired user to test our product; well I’d raised most of them as concerns previously.  The problem was that people weren’t convinced, since they had it in their minds that we only needed to fix tab order issues and perhaps add some alt text here and there.

Most visually impaired users don’t use a web browser in the same manner as we would, as they rely upon tools to read text elements from the page to them.  A simple glance at the documentation for any of these tools will uncover a mass of alternative site navigation methods, such as reading only links on a page, or headings, or using the find mechanism to locate what your looking for, or even the newish ARIA Landmarks feature.  These of course are only some examples, and in fact they could use any combination of them to get to where they want to go.

The most important aspect to consider though, is that everyone is different.  We’ll all have our preferred methods of doing things, and this is why accessibility guidelines wont fit everyones needs.  What they will do though, is provide you with a pretty good foundation for making sure that you’re not a million miles away from something usable.  That being said, I’ve seen some horrible accessible features in my time, which are completely unusable for their intended audience.  At face value they look good enough, however they’d obviously not been tested properly with their target audience present, or in mind.

Jamie Cuthbertson (the blind consultant I’d paired with) sent me on some screen reader surveys done by WebAIM one day, which showed that of the audience surveyed, only 10% of users preferred to browse websites using tab order.  Shocking huh?  It also completely crumbles the assumptions my previous employers had around what was required for an accessible product.  Myself, I’d have thought it would be much higher, but I was fully aware that a single means of navigation would be unrealistic.  Having paired with Jamie, it really opened my eyes (no pun intended), to just how many navigation methods a blind user might use.  It’s completely context sensitive, with each user having a preferred method no doubt, but endless alternatives, should something block their path.

So be sure to keep your end user in mind, and realise that guidelines won’t ensure that your accessible product is actually a usable product for end users.  If you can, do some research into what accessibility groups are saying about products similar to yours.  Even better, hire in some real users with the disabilities that you’re trying to cater for, and get their invaluable feedback.  Most importantly, realise that a main component of accessibility is usability.

Thanks for reading.

Related posts:

  1. Accessibility: Pairing with a blind consultant.