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:
Darren,
This is very interesting stuff. Presumably hardware issues come into play here as well as we have to consider the actual hardware devices visually impaired users might use? I have a blind friend who has a USB device attached to his laptop which converts everything on the screen to braille for him for example and thus it hinders him to have a site with a lot of Flash animations.
Many thanks for an interesting post.
Regards,
Stephen
Hi Stephen,
Thanks for the comment. Hardware is another consideration for sure. Sadly I’ve not had the privelage yet of testing with any accessible hardware. We tested braille output, for the screen reader we had planned to support using a software emulator, which showed both the braille and the text that it had converted, side by side. Obviously this was not ideal, but as we knew exactly who would be using the software, we knew that they didn’t require any braille support. However we at least could check and see if it worked anyway, using an emulator. Obviously if the client did require braille support, then we’d probably would have purchased, or at least leased some hardware similar to what they would be using.
It’s a very interesting consideration though, and most likely may turn up some issues, with the various ways devices output to braille. Just like all the other accessible hardware devices that interact with software in some form, there are sure to be many variables to consider when testing these.
Even the screen reading software, we used. This had huge differences in usage compared with other screen reading software on the market. Even the way it interpreted web pages was different. Navigation mechanisms for users again varied between each screen reader. So for a company to say they support screen readers, is a big claim. Often what happens though, is a supported software list is issued, and only what has been sufficiently tested will appear on this.
Back on the hardware aspect, the area I find most exciting just now in accessible hardware / software design is eye tracking software that allows users who can’t use their arms to interact with the computer, just like any other. Using eye tracking software, blinks, and eye movement gestures to allow them to complete tasks just like any normal user would on their computer. Incredible, and it would be a dream (or a least mine) to be involved in the testing of such technology. Just think how this could transform the life’s of those unfortunate enough to have been paralysed from the neck down.
Thanks,
Darren.
Very true about meeting the guidelines doesn’t mean that your product is accessible by the target end-users. It is very important for tester to pair with blind end-users if their product is for visually impaired. Also, usage of the tools that blind users use would be a good way (Example: JAWS). You might say that “Section 508″ standards are met but, that doesn’t mean Web Accessibility is of good enough quality now. It has to be tested in various approaches like pairing with a blind end-user, accessing the web page through different screen-readers and not only one till especially the disclaimer is made that this webpage could be accessed only by “X” screen-reader (“X” could be any screen reader here) and many more.
Nice post, Darren.
Thanks,
Santhosh Tuppad
Hi Santhosh,
Thanks for the comment. For the most part screen readers are improving. It’s like web browsers though, there are still those using older versions, refusing to upgrade (in some cases due to cost, which is fair enough). So for business to business targeted products, you can to an extent declare your supported screen readers. For public facing products, and websites, it becomes slightly harder, as unlike browsers which are free, a lot of users are using paid for products.
Take JAWS for example, which is the most well known, and used proprietary screen reader. If you are upgrading from JAWS11 to their latest version JAWS12, it’ll cost you between 10% – 20% of the original purchase price, if you’ve purchase an upgradable (with limits) license. Now that may not seem like much, but consider that useful features between versions don’t change much. So a user might very well wait a few versions without bothering to upgrade; at which point they’d have to pay the full price again, which isn’t cheap (nearly $1,000). So it’s not to say we can’t say we don’t support older versions of screen readers, or even a select few; we can still do this. What we need to consider though is the users feelings when we convey this message, and how it could possibly impact the company’s image. So if we did put such a disclaimer on the website we might say something like “We support [X], [Y] and [Z] screen reading software, if you are using a previous version, or an alternative product and encounter issues navigating our product/site, we’d suggest you use [X] product, which is free and fully compatible. You can obtain the latest version of X from [link].”
Hey wait a minute, I’m a tester right? Why do I even care about disclaimers, and such things? Well, we all should. Everything is testable right? If it has an impact of some sort on the companies image, then it should always be in our consideration.
I wrote about consideration for company image previously in an article titled Image show you care! I’ve got a follow up in the backlog, still to be written, which shows poor company image, from my personal experiences. Have a read if you like, it’s probably my shortest post ever, so it shouldn’t take very long! This is a great feat for me, as I always struggle to keep my articles short. I guess I like to write? Or something like that. Anyway I’ll stop writing this rather long comment reply now
Thanks,
Darren.
Good article, Darren.
I’m assuming the input from your consultant was ultimately more valuable than the voluminous content of BS 8878 (Hmm, BS – that reminds me of another acronym…).
I wonder if the drafting of BS8878 standard involved any such consultation with the demographic, and if it was did it get lost under a mountain of beaurocracy. Can’t see why I’d pay £100 for the privilege of reading such a document only to find it’s largely thoughtless rhetoric.
Hope you’ve been enjoying the sunshine in Troon.
Del.
Hey Del,
Yeah Jamie was a breath of fresh air. Our team at the time never bothered to read the BS (yeah I think the same thing when I read that
) article because it hadn’t been finalised (I think it was still in draft status) at the time that we started making our product accessible. Having read the draft, which is free for anyone to read, I can honestly say it is unneeded padding which people can do without. With it being a legal obligation for some companies, I’m unsure if they can get away with not purchasing it, which is a shame.
WCAG v2 has already been widely criticised for being excessively wordy, so I can’t see why governments see it necessary to further complicate things by padding out what is already a lengthy set of guidelines, with needless nonsense, which people don’t really need. When you consider that WCAG is only one of several accessible guidelines available you can see why people feel frustrated, and tend to ignore, or skim by compliances, using automated checkers, as a form of validation. The only reasonable conclusion I can come to for these documents, based around existing documents, it thatsome form of intelligent thought process has went into this , which likely means, they had a meeting or two, and someone thought it would be a good idea (and a waste of my tax money) to develop such a document because people really need it.
Troon is lovely, thanks for asking.