Free JAWS Demonstration

Job Access With Speech

On Monday I went to a demonstration of JAWS screen-reader, that I had heard about through The Web Standards Group discussion list a few weeks ago. It was presented by Steve Green, the director of Test Partners who provide manual testing services (functionality, compatibility and accessibility). Steve had enlisted the help of John (registered blind), who I believe is usually involved in the testing of their clients’ websites/applications, to be the “screen-reader user”.

I found the session extremely interesting and learnt a lot from it. The main thing I wanted to come away with was how to use JAWS myself and to understand how a vision-impaired user would go about browsing a website.

Using JAWS

JAWS is estimated to have a 50% of share of the screen-reader market. Version 8.0 was released last week, but due to the cost of upgrading most users will skip a version. I’d expect the most common versions to be 7.0 and 7.10 and which are available at the Freedom Scientific website.

John started browsing by using Ctrl-O to type a URL into the “Open” dialogue box. Once Enter is pressed, you hear JAWS giving updates on how far through the page is loading “10, 50 percent, 100 percent”. Then it will announce how many, if any, headings and links are found “Page has 10 headings and 64 links”.

He said the first thing he will do, on an unknown site, is to move through the headings to see if he can get closer to the information he requires – step through headings by pressing H.

If this doesn’t help then he would have to go back and read through the site from the top – press Ctrl-Home to return to top and then the down arrow is used to step through the elements one-by-one.

I found even this was enough to enable me to use my version of JAWS more effectively.

Interesting Findings

The title attribute: On an anchor element, the title attribute is used to add extra information to ambiguous link text. For example a link text of “Read more…”, it’s title attribute might contain “Read more about our company”.

I think most in the room were suprised to hear that JAWS doesn’t read the title attribute as default. Rather, if the user is so confused about a link that they don’t want to click until they’re sure, then a keyboard shortcut can be used to find this out. The majority of users won’t bother with it because, more often than not, it isn’t specified and it is easier just to click the link and hope.

Abbr and Acronym elements: While useful for sighted and mouse users who can view/access tooltips, the abbr and acronym elements are not identified any differently than plain text. The geeky reason for this is that JAWS runs from the IE rendering of the page and something to do with node placement (not quite sure myself, see this article about incorrect DOM structure of abbr in IE).

An example shown was CO2; JAWS read this out as a whole word, rather than as individual letters – “Co-two”. A solution to this would be to write out the abbreviation/acronym in full the first time it is come across so the user would hear “Carbon Dioxide, Co-two” and know from then on what co-two meant.

JavaScript: JAWS has partial support for JavaScript so it will not have access to any content between the “noscript” tags. I used to think that by putting in a text equivalent between these tags that this would be read by a screen-reader, so I was glad to have another bad work process corrected (of course noscript is still necessary for those without JavaScript!)

Multiple words, no spaces: There seems to be a trend that started with the web, where multiple words are pushed together without spaces, such as homepage. This is read out as “hom-ee-page” and will be difficult for users to understand and will be worse for less common examples. To makes JAWS read this correctly, Test Partners have found that you can use camel-case, so “homepage” becomes “homePage”, “sitemap” becomes “siteMap”, etc.

Punctuation: As default, verbosity is set to read most of the punctuation such as “left quote” and “dash”. Test Partners found that the parenthesis symbols caused the most intrusion to the flow of text – JAWS reads “pare-ren” for each open and each close parenthesis. Most sentences can be restructured to remove these – the best example is probably on field labels; “First name (required)” – “First name, pare-ren, required, pare-ren” could become “First name, required” – “First name required”.

Future Development

I’ve heard that one attendee didn’t enjoy the demonstration because various items they (and the rest of us) had been using to apparently help the screen-reader user were in fact useless.

Another said he would continue to develop with vision-impaired users in mind, but was simply disheartened to realise that there was not a lot that could be done to improve the user experience.

For me, it reinforced the fact that the decisions you make, such as to add title attributes, use complex nested lists, must be made on a per site/per application basis. As with the WCAG guidelines you can’t apply various rules in a blanket fashion or as a checklist, but they must be thought about in relation to the project. The bottom line is that testing with a screen-reader is very important.

The page where I signed up for this has not been updated yet and so I’m not sure another session is going to be provided. You can register your interest on the site and I highly recommend that web developers, designers and also higher managers attend.

Tags: , , ,

6 Responses to “Free JAWS Demonstration”

  1. Thanks for posting this, Emma – I would have liked to have gone, but I’m just too busy at the moment. It definitely reinforces the message that real-world testing is the only way to understand these things.

    The problem with ABBR may be to do with the fact that IE, at least up to version 6, doesn’t understand it, and turns it into a very weird DOM structure, as I describe at

    I hope the good people of Test Partners repeat this in the New Year, when I might have time to get there :-)

  2. Emma says:

    Thanks Nick, I’ve updated the article with a link to your description of the IE abbr bug.

  3. Steve Green says:

    Thanks for the write-up Emma. We will be running more demos next year and I have updated the website to show this. In fact we will keep running them as long as people keep coming, but I am aware there is a finite number of people who will be interested so they won’t run forever.

    The next date has not been set but you can pre-register at and we will notify you when the date is set. Some time in mid-January looks likely.

    I am disappointed to hear the comment about being “disheartened to realise that there was not a lot that could be done to improve the user experience” because there is plenty that can be done. Conveying the structure of the document by means of semantic markup is the most important, and consistency of design is a great benefit too.

    You’re dead right about making decisions on a site-by-site basis. There may be a few things you should always do and a few things you should never do, but most decisions require you to use your judgement to balance the needs of this user group against the needs of all the other users and stakeholders. The purpose of the demo is not to say “do it this way because it always works” but to help people understand the implications of their decisions so they can make better, more informed decisions.

  4. Wild Ted says:

    Thanks for this interesting and informative post. Your readers might also be interested in the article “Observing users who work with screen readers” which can be seen at

  5. Thanks to this post I will be at the 15 January session.

  6. Emma says:

    Johan: Glad to be of help. Make sure you submit a website you’ve developed/helped with – that part of the session was invaluable.

Leave a Reply