Don’t get bitten by JAWS – it deserves respect

Update in 2026: I wrote this post in 2004 and at that time there were few screen readers available. JAWS was the premier product, and the fact that it’s still available (and widely used) today says something about its usefuless and value, even though it’s a paid-for product. As I write this, they offer a free version of JAWS that you can use for 40 minutes at a time.

22 years later, people starting on accessibility work are more likely to try one of the more widely available tools that can be used for free. The UK Department for Work and Pensions Accessibility Guide has a page on screen reader testing that describes JAWS and three free tools: Narrator, VoiceOver, and NVDA. This post applies to testing with any screen reader. Now back to 2004…

A question came up recently on a usability list: how best to test a web application for accessibility.

The questioner was new to the field and asked about various points, but the one that resonated with me was this:

Finally, since the application is domain-specific, it might be hard for us to find appropriate users for testing (knowledgeable in the domain and blind or have low vision). I was thinking one of our UI people could learn the basics of JAWS and do a spot check for the primary tasks, in addition to using automated tools for a thorough check. (I saw that you can get a 60-Day Timed Evaluation of JAWS for $40, which is a great deal!)” 

Ah, that took me back. I’ve been there. And I can recall exactly the same thought processes. “Hmm, $40 for a 60-day evaluation of JAWS. OK, I’ll get it, learn it, and then I’ll be able to test for accessibility by people with poor vision.”

Wrong. Very, very wrong. As a sighted person, I found it exceptionally difficult to make any sense at all of web pages using JAWS, even those that had been thoughtfully designed for accessibility. There was just too much information coming at me.

JAWS has a steep learning curve

JAWS is a powerful, complicated product with a steep learning curve. Let me pick an isolated example, a feature that was new in JAWS 4.1:

For several years now, JAWS has provided a way to skip ahead during Say All. While this has been a great feature, we have had many requests to provide a rewind also. The wait is over!

During a Say All, INSERT+DOWN ARROW, you can now skip forward by line with the RIGHT SHIFT and then skip back just as easily with the LEFT SHIFT. Tap the SHIFT key 5 or 6 times and jump back 5 or 6 lines without interrupting the reading.

Set your Text Processing to Sentence or Paragraph and the SHIFT key will move you forward or back by those increments as well. Not only does JAWS let you increase or decrease your speech rate on the fly while reading, it is the first screen reader to let you Fast Forward or Rewind in all applications.”

OK. But what’s a “Say All”? Why would I want to skip ahead? Why is it so useful to rewind as well? Will I be able to remember ‘INSERT+DOWN ARROW’ followed by RIGHT SHIFT? And that’s just a single keystroke sequence in a product that has zillions of them.

I’ve since realised that I needed some training from an experienced JAWS trainer before trying it on my own, so that I could learn which of the many control-key sequences are the most helpful to a beginner.

Many experienced JAWS users rely on “speed hearing”

People who use JAWS jack the speech rate up really, really high. They ‘speed hear’, and get very good at picking out the salient features of what they hear from the morass of sound that comes at them. This is rather like the process of a sighted person viewing a web page: we don’t look at every detail, we focus on the parts that seem interesting.

I made the mistake of trying to use JAWS with the screen turned on, so I had two conflicting interpretations of the screen hitting me at the same time. I’ve since found out that if you do want to learn JAWS, or any screen reader, it is essential to switch the screen OFF.

Using JAWS gives you a triple burden: website, browser and screen reader

A person using a JAWS is actually using three applications at once: the website or web application, the browser, and the screen reader. If you’ve tried to teach a complete web novice such as an older relative then you may be familiar with the issues this creates, trying to help them understand when they should be looking at the grey bar at the top and when to concentrate on the meat of the page. Now add in a third thing to concentrate on, and remember that you can’t see any of it.

And, JAWS is modal on top of that. If you want to type data you’re swapping in and out of EDIT mode.

The temptation when looking at JAWS for the first time is to go directly to the website that you’re interested in. That gives you the triple burden right off. I never progressed to being able to use it successfully, but I speculate that it would be better to try to use it on something really simple, like Notepad, and then gradually work up to the triple burden.

Low vision isn’t the same as blindness

Low vision covers a very wide range of different issues with seeing. Most people with low vision can read, although possibly with difficulty. In general, people who are able to read even a little bit will read even though reading may be a tiring and difficult process.

There’s a huge range of different problems but you can get a bit of insight into some of them by moving your monitor 3 metres (10 feet) away from you. Those of us who wear contacts or glasses can also get some effect of low vision by trying to see without them.

Does that seem somewhat artificial? Of course it is. It’s not nearly as good this simple recipe:

• Find someone with a visual disability
• Get them to try it for you
• Pay attention to what they say.

Try it but also get it tested

So, my bottom line is: by all means try the screen reader software for yourself. It’s an interesting thing to do.

But don’t think that it will substitute for getting people with disabilities to test your product, website or web application for you.