Tuesday, 31 January 2012

Part 1: Who Cares about Accessibility Testing- Introduction?

Accessibility, according to Wikipedia, is a general term used to describe the degree to which a product, device, service, or environment is available to as many people as possible. Accessibility can be viewed as the "ability to access" and benefit from some system or entity. Accessibility is not to be confused with usability which is used to describe the extent to which a product (e.g., device, service, and environment) can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. It is one of the sensitive issues that unite opinions, takes center stage, splashed all over newspapers, magazines and forums whenever it is brought to the public attention whether it is about access to public or private entities or something similar. Everyone from Organisations representing disable people to politicians to peer groups joining in to have their voice heard till a satisfactory resolution is proposed.

During my testing career, I have not come across debates or campaigns about accessible web content that caught my eyes. If this issue did ever made headlines then it must have died down during dot com bubble burst or I completely missed it. I have heard the slogan IT for everyone but not Web Accessibility for everyone. I have to admit that I did not have time to trace government policy documents on this issue but I have a sneaky feeling that the message is buried somewhere in the Disability Discrimination Act (DDA) guidelines. In spite of the commercial, ethical and legal implications, many web sites do not adhere to the simplest of W3C WCAG 1.0 and WCAG 2.0, US Section 508 and UK DDA guidelines.

The reason I got interested in the accessibility issues is down to my son who started working with kids with disabilities during his summer vacation couple of years ago and has been doing it since. For him, this started as a way of earning pocket money to pay for his XBOX games that resulted into a passion that he wanted to pursue in life. He was so touched with their inability to do simple day to day tasks, that you and me take it for granted, that he made his mission to help such individuals one day. Therefore he set out to seek a medical degree to get the right qualifications to do the job thoroughly. He is in his third year and has decided to devote rest of his clinical training to become a paediatrician and travel the world when he is fully qualified practitioner. On the other hand, my immediate mission to whom I intend to devote a fair amount of time in the coming months is to find more about web accessibility, its importance to disable people and spread its awareness amongst the testing community.

When I first started researching the subject, I was struggling to find written papers and blogs that are in the public domain. Those I could find were written by tool vendors, consultancies, W3C and National Archive. The one that did help me the most to understand the issues are W3C guidelines and postings on voluntary organisations dealing with disability issues. W3C gives a list of tools that can help you to check out websites whether they comply with W3C guidelines and compliance with Section 508 and DDA act.

HiSoftware & Microsoft in their publication reported that in UK 6% of honour graduates leaving college or university are students with disabilities and 85% recruitment websites are inaccessible to them. 78% people acquire disabilities during their working life and can be helped through accessible web at work. If employers are to attract good graduates and retain partially disabled loyal employees then providing accessible web to this group of people can achieve those goals. It has also long term benefits too to keep them motivated contributors to the business. Denying disable people web content from their websites due to its inaccessibility, not only have detrimental effect on the company’s profit but also it is against their human rights by ignoring well established W3C, section 508 and other guidelines to protect them.

In order to get a feel for what accessible web means to us, I started looking at W3C tool list and tried them on some well established websites such as Amazon. I used selection of tools from limited trial commercial, freely downloadable and built-in Windows 7 utilities such as Inspect Objects and Accessible Event Watcher (accessible via Start\All Programs\Microsoft Windows SDK\Tools). I also ran some tests on couple of blogposts that I regularly visit. I was horrified to learn that all of them have accessibility issues, some more than others. The most common errors were page colour contrast (background to foreground), text font size, and URL link text colour, missing ALT text from forms and images and navigation. I was disappointed with the flow of readability when I used NDVA (screen reader) on some established websites and blogs; even the BBC home page had some issues. It was more like start and stop rather than continuous reading the text with the aid of screen reader. Shopping websites such as Tesco came on top from a small number of sample websites. I noticed an interesting and too familiar error on one of the objects on Amazon home page; the image ‘January sale’ had ALT text showing ‘Boxing Day Sale’ suggesting developers were asked to make ad-hoc changes on the hoop. I also noticed people using smiley faces without ALT text unrecognisable with screen readers.

I have no intention of speculating the reasons why testing blogs have accessibility errors except to say that it may be that authors of these blogs are unfamiliar with accessibility guidelines or HTML code, hard pressed for time to check the contents before posting or have not realised its importance or something else. I cannot stress enough that it is a good practice to adhere to at least basic W3C guidelines because some testers out there may suffers from some kind of disabilities and should not be left out. In the next couple of blogposts I intend to look at 12 prominent Accessibility guidelines and how to test your own website or blog for compliance. I will offer simple tips that you can follow to meet key accessibility guidelines for your blogposts. Are there any volunteers out there who would like me to run some compliance tests on their blog(s)?

This blog has been checked for readability using readability calculator.

Watch this space for more Hints and tips!


Phil said...

I ran the WAVE tool on this site and got 28 accessibility errors...

A previous project I worked on did try to be accessible - but to do so they were told to remove all javascript which basically meant rewriting 1/2 the project

Mohinder said...


Thanks for the comments.
Accessibility a sensitive issue but it has to built-in application instead of baked-in. It should be tackled at the design stage and functional, usuability and compliance teting should be part of the tester's remit.
I have not got much control over the blogger colour scheme and layout but I am working on my own website where I will have more control and check for accessibility before releasing the content. I don't like the blogger anyway but it has done its job for me.


Darren McMillan said...

On the JavaScript issue Phil, that's a flawed one. While back in WCAG 1.0 it was required that if JavaScript was turned off the product had to be equally accessible as before, what really was required back then was a suitable work around. Thankfully WCAG 2.0 recognises this now.

There is lots of nice things you can to within a no script tag, to provide accessible workarounds for JavaScript content, but generally it's all to be taken with a large dose of common sense. Do it as and when needed, not all JavaScript is bad, in fact a lot of it can assist assistive technologies, which for most (unlike back in the day) actually work with JavaScript now.

Like wise CSS can be equally as assistive, with some thought. Goto main content links which skip excessive navigation/banner links can be style to be set off-left to provide a fantastic accessible feature to assistive technologies such as screen readers, while being completely transparent to non assistive technologies.

WAI-ARIA markup has a terrible support adoption record for screen readers. When you consider like web browsers, a lot of people use older screen reader versions, combined with the fact that the majority pay close to $1000 for the proprietary JAWS screen reader so don't want to pay again to upgrade, how much an impact is WAI-ARIA having to end-users? We can't dismiss it's benefits though, hence why it is important to champion its usage, as I do on a weekly basis working for a Digital Agency, creating countless front end web sites each year, because one day it will make the significant difference, until HTML has the chance to catch up in the gaps WAI-ARIA looks to plug.

New tech, opens new opportunities, lets not dismiss it and embrace the opportunities it provides, as long as we can use our common sense, providing accessible web content doesn't have to be the major hurdle many consider it to be.

Phil said...

Thanks for the input Darren. All I know is that the project I was on last year had to get a special sign-off from the accessibility team because it used Javascript. No if's buts or workarounds, they wanted it all gone.

It would be interesting to know how many companies even think of it, never mind bother to implement it

Darren McMillan said...

It sounds like their accessibility team don't really know anything about accessibility then.

It is a crying shame that people can be employed in a role that they clearly don't understand. I hope someone exposes them soon.

Mohinder said...

You can do clever things with JavaScript but you have to be innovative with the logic although it is not code centric. Semantic HMTL elements where available are preferable than custom widgets made accessible via JavaScript. Web designers should be aware of how to replace complex custom widgets with much simpler native elements. They have to think how to replace a combo box with an auto-complete function, a slider with a radio button with distinct values accessible via tabbing to make things easier so they are easier to use with assistive technology. Styling native elements in CSS is hard but it gives a better look and feel interface elements that are easily recognisable and predicted by the users.

You are right in saying that older browsers do not support WAI-ARIA and there are users who have not upgraded to newer version of browsers due to individual reasons. In a recent article it was stated that WAI-ARIA’s lack of robustness is another problem: Its implementation in browsers and assistive technology is not that stable yet. The average update rate for Jaws across all users is much low because of its cost. The situation may be worse at some workplaces where blind people have no access to assistive technology such as screen readers supporting WAI-ARIA. You cannot ignore the WCAG 2,0 guideline which clearly states that ‘Creating content that can’t be used by the general public with disabilities should be avoided’.

QA Thought Leaders said...

Very nice post. Accessibility Testing is often neglected, however in my view it is of high importance. Thank you for sharing this post.