Accessibility Testing: The Answer to the Common Question of ‘Why?’

Often when I recommend to project managers or developers that a project should include accessibility testing, I w3c-1299614815will get asked, “Why?” Not always a simple ‘why,’ but a “Why would a blind person use this site?”; “Why is a screen reader important on a mobile?”; “Why would anyone use just a keyboard?”; “Why are color ratios important?”

Often, all these questions can be chalked up to just not understanding the audience requiring an accessible website. I will try to educate as best as possible by giving some statistics and reasons as to why accessibility is important.

First, the testing is not just covering blind users, but those that are deaf, short-sighted, arthritic, color-blind, dyslexic – the list is actually quite exhaustive. Screen reader users, for instance, are not just users with a sight issue, but sometimes people who find it easier to have the content read out to them, like someone who finds the screen too small or has issues that make reading more difficult.

Another point many business users will take an interest in is the potential loss of business by not being accessible, and/or potential legal cases. I have given a few examples of this in uTest University tutorials on accessibility, so please check them out for more details.

I guess that with all types of testing, we all get the same questions around why it is important, but I am surprised when I get asked this by testers I work with. Is accessibility lesser to other versions of testing? Sometimes the same testers will assume that accessibility testing is either easy or subjective and not a true form of reproducible testing. I have found this can be the case, but not necessarily.

Usability testing is less measurable as it will ask for user feedback, and we know that each person is different. Yet usability testing is given more kudos than accessibility testing, which has a globally recognized list of checkpoints.

I have also found that most accessibility companies have adapted the W3C checkpoints and don’t have a governing body to regulate them. In some cases, the fact that the company has no regulator to answer to means that they’ll sometimes fail code due to an out-of-date rule. JavaScript, for instance, is very accessible these days, but some accessibility companies claim that you must have JavaScript-free versions of sites to pass their testing. This reputation for accessibility testing has harmed those that do keep up to date and don’t try to enforce rules that might have been true 10 years ago.

To summarize, accessibility isn’t about taking away functionality or making things difficult for the team, but rather making sure all possible users have a way to use the system. In the future, it would be nice if there was a governing body for all companies that claim to test against the W3C checkpoints, but until then, I am happy to build more courses on how to test these checkpoints, and make sure companies don’t become complacent and detract from the big picture.

Helen Burge has been testing for over 10 years in a mixture of disciplines including functional, accessibility (WCAG 2.0 checkpoints using JAWS oHelen Burger NVDA), performance and automation. She is a recognized accessibility expert with several articles in uTest University.

Comments

Trackbacks

Leave a Reply