Making public statements based on limited knowledge of an assistive technology and with little understanding of how it is used, can lead to incorrect conclusions and poor implementations. For example, a blog post about the JAWS screen reader (amongst other things) and how poorly it supports the reading of paragraph’s in HTML, is being cited to re-inforce arguments in an opinion piece about web accessibility, which in turn is being cited in other debates. In attempt to introduce a little perspective, here is some information about how JAWS reads text.
JAWS support for the HTML p element.
Users can navigate content via the p element in HTML, by using the P (move to next p element) and Shift-P (move to the previous p element) keys. When these commands are used, JAWS will move to the next or previous p element and read the text contained in that p element and then stop reading. The user can then move to and start reading the next paragraph by pressing the P key. Using this command, JAWS will stop reading at the end of each paragraph independent of style or punctuation. This was tested with JAWS 8.0 and 9.0 on Windows XP using a test page.
The “Say All” command
The “Say all” command INS+DWN ARROW, is a more general command that applies to desktop applications and other situations where text can be read as well as HTML documents. Using this command JAWS will simply start reading from the top of the document, without pausing, until it reaches the end of the document.
For example when a page first loads in a browser JAWS will start reading from the top of the page automatically or the user may invoke the “Say All” command. It will then read all text and text alternatives found on the page. The user can modify the progess of the reading by using the right and left SHIFT keys . Depending on the preference the user has set in the “Say All By” verbosity options, pressing the SHIFT keys will have different effects:
- Line with Pauses: This option reads by line, pausing slightly at the end of each line.
- Line without Pauses: This option allows for smoother reading.
- Sentence: Select this option for applications in which SayAll sounds choppy. This moves the pauses between elements to the ends of sentences, and makes the reading sound smoother.
- Paragraph: This option is very useful in large documents as you can press the right SHIFT key to quickly move through the paragraphs without needing to interrupt SayAll.
The user can stop the “Say All” at anytime (by pressing the CTRL key) and navigate the content using the many other methods available.
Addendum
As a further test of JAWS support for the p element in HTML documents, the JAWS ‘Skim Reading’ feature was tested. When the CTRL+INS+DWN ARROW command is used, JAWS should read the first sentence of each paragraph (other preferences also available). Using the test page, it was found that JAWS announced the first sentence of each paragragh regardless of punctuation (for the last sentence in each paragraph) or visual formatting.
Comments
What I referred to in my blog post was actually a bug in JAWS. I haven’t been able to reliably reproduce it (though I haven’t tried very hard), but in certain cases I had JAWS reading text that looks like this:
bla bla bla
foo foo foo
quux quux
…in a way that sounded like “bla bla. (pause) bla foo foo. (pause) foo quux quux.” which is clearly wrong given the markup.
Hi Ian,
This is what you wrote in your blog, which is quite different from what you have detailed in your comment.
Steve, I’m glad that you’ve written something that shows how good modern screen readers actually are. I felt the same urge to speak out when I first read Ian’s post about his bad experience with JAWS. Part of me sympathises with the frustration of finding screen readers that don’t behave as you’d expect, but another part of me screams out when I see semi-informed judgements. I personally think that screen reader software could be better for the amount it costs, but I also realise that a) assistive technology software is quite niche compared to other software, and b) screen reader software is actually very usable, but you need to take the time to learn how to use it; they’re complex pieces of kit!
I’ve observed one of those bugs that Ian mentioned: disjointed reading of sentences in JAWS. I can’t actually replicate this problem in a test page. However, as an example, see my abbreviations test page. You can try this in JAWS 7 through 9 in IE 6, IE 7 or Firefox (I’m on Windows XP). If you use the down arrow to navigate through the page, the first sentence in the first paragraph under the heading “Notes” gets read out in full but with the first word of the next sentence included as well. The result is disjointed sentences, like this, “…the ‘aural’ and ‘speech’ CSS media types. [pause] The [JAWS stops] [pressing DOWN ARROW to continue]tests follow a related discussion…”
However, this is only observed when slowly reading through the page using the down arrow, which commands JAWS to read the “next line”, whatever that means; it usually reads out the next “bit” of the page, whether that’s part of a sentence, a heading, a link, etc. In other words, it will read a chunk but stop for links in the middle of a sentence and that kind of thing. An important thing to realise though is this: (I think I’m right in saying) that regular screen reader users will typically control JAWS with other commands, such as the ones mentioned in this article, particularly INS+DOWN ARROW to get JAWS to read continuously until you tell it to stop. This is where taking time to learn how to use a screen reader is important.
So, there may be problems here that need addressing, but I just wish there was a way, in this vocal age of the blogosphere, that people with such passion about accessibility could better work together to teach each other and push accessibility forward.
Since when does it make sense to accommodate any user agent or its myriad pyramid of complex user settings and ignore a pragmatic basis of both good grammar and use of the
pelement? It, also, includes, from a design perspective, of using a CSS ‘Black Hole’ technique to hide punctuation marks, as needed. The use of proper punctuation is not limited solely topelement but should extend to all content based tags. If not mistaken, JAWS ignores the use of a semi-colon within grammar, for example. To let the assistive technology user agent and its bizarre complexity wag the tail of the communication dog is foolish.What Hikson is pointing out is to use good grammar. If a user agent cannot interpret and utilize grammar, the onus falls upon the user agent and not upon the designer/developer.
thacker wrote:
Nothing in this post indicates that grammar does not matter thacker or that some special structures need to be used just for JAWS, or that CSS be used to hide punctuation???. Nobody has disputed the use the
pelement except Ian Hikson (on his blog):note: emphasis added
As is clear from the results of the tests I conducted, JAWS supports the
pelement regardless of visual formatting, for it to be useful to JAWS users, it is not required that authors do anything apart from mark up their code correctly. So your comments are misguided and do nothing to further or inform this debate.What Hikson, I believe, intended to state is that punctuation is a more fundamental point to accessibility then is, for example, use
longdescoraltelements. Faulkner, you however, attempt to prove, with reference to one assistive technology user agent, on how Hikson’s statement serves to misinform. Granted, Hikson may have soley referenced JAWS but that does not dilute the importance of his statement — use proper punctuation. That fact that JAWS does intermittently run-on paragraphs enforces his statement. My observations with JAWS has been and continues to be that it will do this intermittently with or without proper punctuation, albeit more so when punctuation is omitted within a paragraph tag.While you have pointed out your
ptest cases, care to expand upon them and how assistive technology user agents handle all grammatically correct punctuation. Possibly, also, expand upon how JAWS, for example, renders lists. After you have prepared and conducted these test cases, would you care to still debunk the prudence behind use of punctuation and Hikson’s intent. If any error occurred, it was that punctuation should not be omitted from any content tag not just the paragraph element.If someone takes the view that accessibility is broad based and applies to it interoperality of Internet communication regardless of device, explain, please, why use of punctuation is not a best practice for let’s say, simple text to speech engines. Wouldn’t this impact the future of Internet communication and its ability to transcend visual display technologies for anyone. From that basis, how does Hikson’s statement misinform. It does exactly the opposite.
Finally, if someone takes exception to an exception, wouldn’t it be advisable to give it some consideration rather than to discount it as merely being ‘misguided’ or is not germane.
I stand behind Hikson’s spirit that proper punctuation is a fundamental prerequisite for accessible content. Misinformation generally occurs when too much is taken out of context.
Thacker,
What happened to your CSS argument?, what happened to your argument that the post advocated to ‘hide’ punctuation or not to use the p element to accommodate JAWS? You were and are misguided because you misread or didn’t bother to read the post or related material.
Hi Jon, thanks for your comments, I have no doubt that JAWS is buggy and very complex. I don’t envy users who actually need to use it to use a computer. I think part of the reason why it is buggy, is that it (and other AT) have a very difficult task trying to make an operating system and the software that runs on it usable by people with disabilities. Software which for the most part has not been developed to be accessible.
I think what Ian observed is in fact a rather minor issue. For many users of screen reader technology this punctuation output misnomer will not have any major negative impact on the usability/accessibility of a webpage. The important thing is that content is marked up well, using the correct semantics, etc.
This ‘problem’ is more to do with how the UA renders the content. You should only accomodate it in the sense that you do any other user agent by serving them well marked up content. Anything else is opening up the door to a world of hacks. In this instance, the output is maybe not ‘perfect’ or how Ian expected it should be but it is not a show stopper that will have the user tearing their hair out either!
There are worse crimes in the wild.
Screen readers are complex and powerful applications that help improve the quality of life, employment opportunities and many other good things for people with disabilities – that are an important part of an inclusive society. They are not perfect, but neither are most browsers, and certainly not most web pages.
thacker wrote:
I don’t think that anyone would argue that use of good grammar and appropriate punctuation is important when it comes to accessibility and, of course, comprehension in general. However, grammar evolves and is different across languages. Also, not everyone’s idea of what entails proper grammatical constructs or appropriate use of punctuation are the same in any given language.
Semantic markup, written to published standards, provides structure that is language agnostic, so it’s also important to work to technical standards that accommodate accessibility.
Whatever Ian meant in his blog entry, he should mean what he says. Many people read blogs and base their own opinions and practices on what they read. Ian says “forget longdesc or even alt, or even markup of any kind, just make sure you’re using full punctuation!” That’s not constructive.