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 CO²; 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.

Posted by Emma Sax

November 30, 2006

Uncategorized