Since before Web-accessibility evaluation tools were available, developers have used JAWS to test their Web sites. I have for so long that not using it never occurred to me. I was spurred to consider the possibility at a recent demo about the newest version. Eric Damery of Freedom Scientific, the maker of JAWS, proposed it. This post details the reasons I am considering no longer using JAWS for Web accessibility testing. Future posts will discuss alternatives.
Description of JAWS
JAWS is wonderful software. For a person with a significant visual disability, it reads aloud or converts to Braille the content sighted people view on their computer screens. Without the JAWS screen reader or one of its competitors, hundreds of thousands of people would be unable to use computers, nor would they be able to access the Web.
Using JAWS For Accessibility Testing
People who are blind have long been considered the most excluded from the Web. This is the central reason Web accessibility standards have been focused on making sites accessible to them. (An even larger excluded population are people with cognitive disabilities, but that is a topic for another day.) Thus accessibility-minded developers have always considered it important to test sites with a screen reader. JAWS is chosen for this because people with visual disabilities use it more, by far, than any other screen reader.
Another benefit of accessibility testing with JAWS is that sites made compatible with it also often work well for people with physical disabilities. People who can not use a mouse, and/or who use a single-switch device instead of a keyboard, can navigate an accessible Web site in a way similar to that of JAWS users. A simple approximation of this experience is to visit a Web site and attempt to navigate it using only the Tab key.
Reasons I Am Considering No Longer Using JAWS
- Though I have used JAWS to help test Web accessibility since the time (1995) it was first available, I know only enough about it for such testing. Like all screen readers, JAWS is complicated. For people who must use it to access a computer, many months are typically needed to learn it well. Over the years, as I have hired developers and introduced them to Web accessibility and JAWS, it has been difficult for each to master it sufficiently for accessibility testing. In part this is because they don’t have to use it all the time as people who are blind do.
- Another reason developers find JAWS troublesome is that the Web content it reads can not be visually tracked. The temptation for sighted developers to watch JAWS is too great. They are so dependent upon their sight that trying to get them to test Web sites while their screens are off, for instance, is difficult.
- Sighted developers inexperienced with JAWS, and sighted people to whom JAWS is being demonstrated, are often confounded by the way it reads Web content. They expect it to read an entire Web page as they perceive they do. Instead, JAWS reads Web pages in chunks and pauses before links. This behavior closely mimics what sighted people really do, which is to skim Web page content.
- JAWS is expensive. At the time of this writing, it costs $895 for most people, plus an annual software maintenance agreement (SMA) of $120. Cost alone can be an initial barrier for people who are blind and, as a population, are chronically underemployed. For developers who use JAWS to test accessibility, Freedom Scientific requires the more expensive professional version. Its cost of $1,095 plus a $200 yearly SMA can be a barrier for developers without institutional backing. To evangelize accessibility testing to other developers, I am interested in lower-cost or free alternatives.
- “Ninety percent of blind people don’t use a screen reader.” Kevin Carey, Chairman of the Royal National Institute of Blind People (RNIB), said that recently at an INMD seminar for Web developers. He also said that is the reason Web sites should be made “self-voice”. I imagine he was referring to people who are legally blind. To access Web sites, they must use screen-magnifiers, text-to-speech software, and/or Web site widgets.
Notes
- JAWS is only one of many tools my team has used to test Web site accessibility. Most importantly, people with disabilities have always been hired to vet the accessibility of our Web sites as much as possible.
- Reason 5 may mean I should place more emphasis on my experiments with text-size enlargement and incorporation of text-to-speech features.
- The quotes attributed to Kevin Carey were provided to me by a person who attended the seminar.
- I am interested in feedback. Please comment.
[Editor’s Note: Readers may be interested in a follow-up post, “First Experiment with MAGic for Web Accessibility Testing“.]
1. Testing web sites with screen readers should preferrably be done by experienced screen reader users, e.g. blind people. Exactly because screen reader users do use web sites in a different way from sighted people.
2. Making a site accessible with a screen reader does not mean a site is accesssible for all. There are many more kinds of disabilities an accessible web site should account for.
3. If a develloper is willing to use a screen reader for testing, there are a couple of free alternatives:
3.1 Jaws comes with a full featured free demo version, the only restriction beeing: demo runs for 40 minutes, after that period of time a reboot is required, to gain access to another 40 minutes session.
3.2 The free / open source screen reader NVDA: NVDA doesn’t need any installation, and requires much less resources compared with Jaws. NVDA site: http://www.nvda-project.org/
Thank you very much for your comments.
Clarifications:
I took his point re screen reader uptake being more that the majority of ‘legally blind’ people, 70-80%, are elderly folk who lived most of their life sighted and seldom access the Internet at all. Its a group for whom AT with the complexity (or functionality) of JAWS, coupled with the additional skills and knowledge required to operate it effectively, are unfathomable. The benefit for them just isn’t there.
There’s a common, and kind of arrogant, perception in accessibility circles that when someone fails to access a site which supports AT through WCAG compliance, or whatever, that its their fault for not understanding – rather than evidence of a far more fundamental failure of the whole package of technology and standards surrounding Web usability.
BTW Kevin is Vice-Chair and Chair-Elect of RNIB, but was speaking at the time as Director of HumanITy…
Thank you for the clarifications, Simon.
I agree with your point that often the perception is people with disabilities are to blame if they have trouble with a site that has attempted to be accessible.
Ooh – I demoted him, he is RNIB Chair now!
I would challenge the statement that using the JAWS forty minute demo for accessibility testing is a violation of the JAWS license agreement. In fact, I have often heard Freedom Scientific representatives suggest this behavior for developers who need to check their sites. As JAWS is currently the most widely used screen reader by users who are blind, it makes sense to test with this software to ensure compatibility and usability. It is my sincere hope that the next several years will change this environment and the low cost/free sscreen reader (VoiceOver/NVDA/System Access) will become the market leader, but this is not currently the case. Thanks for this thought provoking discussion.
Thank you for your comment. As a person who works for Perkins, you certainly would know better than I the common practices of people who use JAWS and/or who represent Freedom Scientific. Upon reading your challenge to my statement that “… it is a violation of the JAWS license to test Web sites with the 40-minute demo version,” I just now downloaded and installed the most recent JAWS evaluation version. Its license agreement says,
This policy was the focus of a related blog post by Jared Smith, of WebAIM, in January, 2008. See “JAWS license not developer friendly” and its accompanying discussion.
Two notes:
Hi. I like several of the reasons you’ve given for looking elsewhere for accessibility testing. 🙂 JAWS is indeed expensive and takes time to master. I imagine it would be difficult for a sighted person to get comfortable with it while testing a site as well. All of these reasons make sense to me.
Developers are indeed allowed to use the 40-minute demo of JAWS for testing. Magic with speech enabled would work just as well.
Blind people do use sites very differently from people with sight. We may skim over content, but it’s not the same content you might skip. Our focus may end up on something other than what you want us to notice. Bold text may or may not get our attention. We usually completely miss helpful visual cues like arrows, graduated navigation strips, and spacing. So while you can tell how JAWS or Magic speaks, you don’t see how a blind user moves around on your site or what he or she notices.
Many companies have found it to be helpful to ask a blind user or two to serve as site testers in a similar way that beta testers test the rest of the product. An NDA document can protect a company who is concerned about someone learning about a project in development.
What really prompted me to comment is that the number given in reason five is not accurate and is somewhat misleading. It may apply to the clientele of the RNIB. That agency doesn’t serve blind users globally, and the numbers may be very different for blind people in other countries where vision related medical care isn’t as widely available.
It is true that many legally blind people are capable of reading with magnification only. However, this group isn’t anywhere near 90 percent of blind people. It also isn’t a stable group because visual acuity often worsens with age, fatigue, illness, and time of day. Often people in this group can read print fine on Monday but may not be able to read well on Tuesday because they’re tired or have an ocular migraine.
There are far more people who use a combination of speech and magnification to access the web. This does involve use of a screenreader, though it may not be JAWS. Magic or Zoomtext are more likely in fact. This group turns speech on and off as needed.
I know this can see like a morass. Accessibility can’t be a one-size-fits-all solution. Self-voicing applications are very popular as well. However, they tend to lock out people who have hearing impairments who use a screenreader to provide Braille support. A sizable number of blind people have a hearing loss to some degree, and they are often left behind when content is only made available as audio. A screenreader renders everything in Braille text for these people.
While I don’t mind self-voicing applications in general, I’m not sure I’d like self-voicing web elements. I think they would mess up my screenreader’s speech and confuse me. I could be wrong about that though since I’ve never used such a thing. I’ll work to keep my mind open on that score.
Since I am both blind and have a learning disability, it is important to me to have a way to read text at my own speed and with the ability to look at the spelling of words using the say character feature in my screenreader. As I imagine them, I think self-voicing web pages would be almost as frustrating to me as pages with heavy flash content or Ajax elements that don’t speak. Without my screenreader, I wouldn’t even know how to spell your name.
Thank you for your thoughtful response. I understand your points about people who are legally blind. I appreciate the ones you made about the different ways people who are blind use and experience Web sites. I would like to be clear that the Web sites my team designs are indeed tested by blind users of screen readers.
What Mr. Carey referred to as “self-voice”, I understood to mean text-to-speech (TTS) features or widgets built into Web sites. I do not believe they are incompatible with screen readers. Indeed they cannot be if a Web site is designed to be accessible to all. All I have seen are Flash based. My review of one, Cognable Speeka, includes a link to a test page that incorporates it. Speeka does not speak without activation (invoking its play button), so it will not automatically interfere auditorily with your screen reader. Perhaps that will mean you will not find a page designed with TTS or “self-voice” to be frustrating.
I don’t follow the point of this post. Jaws is the only way that a developer has to surf the web as a visually-impaired user does. Other tools cannot mimic a real experience, the experience of listening to your content being read aloud by a syntethic voice. No online service can do this. I think that the reason should be found elsewhere. First, sighted people generally don’t take care too much of what other people experience, just because they see and they can’t imagine a world without colors and images. That’s a problem of sensitivity and need to experience (or try to experience) what other people feel when colors and images don’t exist. Second, the overwhelming majority of company websites don’t care about accessibility issues, just because accessibility doesn’t fall in their marketing strategy. We want an easy-going way to say “oh yes, I know what accessibility problems are and I’ve tested them!”. Be honest: accessibility arise problems that very few people want to face. First and over all, accessibility means looking at the world with the eyes of people who suffer from disabilities, so it’s a matter of how much we care about the problems of other persons. Are they important to us or are we forced to cope with them just because a law wants so? I’m not criticizing this post, but I’m simply saying that our motivations should be clear to ourselves. Everything else comes second.
Thank you for your commentary. I agree with everything you said.
The point of the post is simply to describe the reasons I may stop using JAWS in particular for accessibility testing. I apologize for not emphasizing enough that I will be investigating accessibility testing using alternatives to JAWS. Such tools include MAGic Professional with Speech or NVDA / other free screen readers. I plan also to test the usefulness of augmenting such accessibility testing with screen-reader emulators. I list many of these options in my post, “Screen Readers, Web Site TTS Plug-ins, Etc.“.
Also, in my other responses to the comments on this post, I discuss wanting to incorporate text-to-speech (TTS) into Web sites. I intend this to be useful for people with cognitive disabilities, not for people who use screen readers.
The trouble with suggesting that self voicing websites can benefit blind and partially sighted people, is that it’s restricted only to the website itself. People needing the website to speak, are likely to need an access technology to reach the website in the first place. At that point, the self voicing seems a bit redundant.
Such self voicing tools can be useful for people with other disabilities of course, including cognitive and learning/reading disabilities. They’re also helpful for people who speak a foreign language, but I’m just not convinced they’re much help to screen reader users.
Perhaps you should talk with Apple. At first the company didn’t care much for accessibility, but when threatened with a lawsuit, it changed its ways. Now visually impaired users can purchase Apple computers and Iphones without having to buy expensive software to attain the same accessibility as sighted users. Also, I would say that millions of users are being blocked from certain features of applications like Facebook. Groups with physical or cognitive impairments are steadily finding more and more belonging and opportunity for self actualization, which means that certain web sites that aren’t fully accessible won’t be able to compete.