Should Sighted Developers Use Screenreaders To Test Accessibility?
September 23rd, 2010
There is some controversy about the idea of sighted web designers and developers using screenreading software to test web sites for accessibility. Some people suggest one must use a screenreader to test their sites. Others believe it is counter productive. I think that very few sighted people can get the correct results by using screenreaders to test a website. I further think that too many people think that the accessibility testing is complete once they’ve used a screenreader on their website.
Different Ways to See Content
A major problem is that sighted visitors and blind visitors experience web pages quite differently. A sighted user tends to scan the content on the page
“at a glance” – Our gaze can jump from right to left, top to bottom, and back. Someone relying on screendreading software gets to see the information in
the order it appears on a page – They see the information in a “top-down” fashion.
Adept screenreader users can usualy skip from heading to heading (if headings are used on the page), or go from link to link. Yet it is still a very linear
way to look at the content.
Different Ways to Use Screenreaders
Robyn Hunt tweeted:
But sighted ppl will not use screen readers in same way as blind, if u c what I mean.
Screenreaders are very complex applications. Habitual users of screenreader have keyboard shortcuts memorised, and can switch between different modes (where the behaviour of keyboard shortcuts is different depending on the mode).
It would be difficult to become adept at using screenreading software unless it is used often. I am aware of at least one course on web accessibility that
requires its students to become “proficient” in the use of screenreader for testing. But proficiency doesn’t really compare to the skills developed by
someone using screenreading software daily. And these kind of skills must be maintained.
I used to be proficient in the use of JAWS – I had to learn because some of my staff were using it and didn’t have monitors plugged in to their computers.
But even when I used JAWS regularly, I wouldn’t have thought of using it for testing.
Comparison With Wheelchair Use
I like to compare the occasional use of screenreading software to test website to the occasional use of a wheelchair to test accessibility. Someone who
doesn’t use a wheelchair daily doesn’t have basic skills that permit fluent use of the chair. For example, “popping a wheelie” allows getting up and down
small changes of level. If you don’t have that skill, you’re likely to think that something perfectly accessible, isn’t. Someone just trying a wheelchair
once in a while also doesn’t have the shoulder, arm and wrist muscles developped in a similar way to a wheelchair user’s arms. Pushing a wheelchair is
harder if you don’t have those muscles.
In fact, there are studies that show that sitting people in wheelchairs to create “disability awareness” actually causes a negative perception of the situation – people only see the negative without realising the positives.
Incomplete or Innacurate Results
If you don’t develop and maintain the skills required to use screenreading software you may find web accessibility issues where there aren’t, and miss those issues that *are* present. This is more problematic than not using screenreading software to test.
Accessibility Is Not Just About Blindness
A site could be fully accessible to a screenreader user, yet not at all accessible to other people. I wrote
Accessibility Is Not Just For Screenreader Users a couple years ago. You may wish to read it to get an idea of other conditions that affect access on the web.
I am concerned that the push for developers to use screenreader to test website is shoving other needs aside. Developers think that their responsibility
to accessibility begins, and ends, with making sure their sites work well in screenreading software. But that is not the case at all. If we are concerned
about accessibility, and we should be concerned, we must bear in mind all the various barriers our designs can cause.
So, How Should We Test?
There are many tools out there that allows a developer to test sites. I don’t use screenreading software when I test a site for accessibility. I am not
proficient in the use of screenreader, and wouldn’t use such software often enough to remain proficient were I to use it occasionaly. So I use my browser,
I look at the source code of pages, and I rely on WCAG
(even though it’s imperfect).
I also use Lynx,
a text-only browser, to test pages. If the content is accessible in Lynx, it is most likely to be accessible through screenreading software. That said,
there may be issues where the screenreader interacts with visual browsers and interprets CSS commands such as display:none; correctly.
Beware Your Tools – No Single Tool Is Perfect
Just like Lynx alone cannot determine how accessible a website is, screenreader software cannot determine how accessible a site is. Each tool or method of testing gives a different view of the barriers encountered on a site.
So, if you opt to use a screenreader application to test your site, be prepared to:
- 1. Learn to use the application properly,
- 2. Maintain your skills with the application,
- 3. Remember you may encounter false-positives,
- 4. Remember that accessibility is not just about screenreader users,
- 5. Screenreading software is only one of many tools that can be used to test for accessibility.
What Do You Think?
What do you think of this? Are you a developer who uses screenreader software to test? Or do you prefer to avoid using screenreaders?
[Edit] Note: Please let me clarify that I am NOT suggesting that sighted developers should not conduct accessibility testing! Of course accessibility testing should be conducted – that is a given as far as I’m concerned. I just don’t think sighted developers can develop and maintain sufficient proficiency to effectively and efficiently do accessibility testing with screenreaders.
Reproduced from http://accessibility.net.nz/blog/should-sighted-developers-use-screenreaders-to-test-accessibility/
