0
votes

I'm developing a JavaScript web application that features a text editor component. One of our most active users is blind and uses the JAWS screen reader to use our application. He often highlights multiple lines of text from the text editor to copy and paste them into another program (Word, Outlook, etc) and is complaining that the screen reader is repeating text when he is selecting multiple lines. He presses shift and the down arrow to select lines.

He expects that the screen reader will only read the newly-highlighted text every time he highlights a new line. For example, if the line "The quick brown fox jumped over the lazy dog" were split across two lines after the word "jumped," he'd expect it to read "The quick brown fox jumped" when he selected the first line and then only "over the lazy dog" when he pressed the down arrow again to select the second line. This is how it works in Microsoft Word and other programs that he uses heavily.

After some research, I've found that JAWS is reading everything as expected within a single paragraph, but the problem seems to occur when he selects lines that include an empty <p> tag or a <p> tag with just a <br> inside (which is common in our application). As an example, here is what the content of our text editor might realistically look like:

<p>This is a long line of text that will wrap
around after the first occurrence of the word "wrap"</p>
<p><br></p>
<p>And then there might be another long line of text
here that wraps around after the first occurrence of the word "text"</p>

If he starts highlighting at the top, JAWS will read the first line correctly and then the second line correctly after he highlights the second line. When he highlights the paragraph with the break in it, JAWS will read the first two lines again. When he highlights the first line of the second paragraph, JAWS will read the first two lines again, followed by the first line of the second paragraph. Interestingly, if he highlights the last line, it behaves as expected and only reads that line.

Can anyone help me understand what's wrong with the structure of the content of my text editor that's causing the screen reader to repeat lines in this situation? Any guidance would be appreciated.

1
I'm not sure exactly why it works, but it seems that changing the <p><br></p> to <p>&nbsp;<br></p> makes JAWS read things correctly. I should also mention this behavior was only observed in Firefox.Brian

1 Answers

2
votes

It's difficult to answer without a practical example, but my theory is the following: jaws repeats text when you aren't highlighting new text content. So it works with <p>&nbsp;</p> because the unbreakable space is some text content, while <p><br /></p> doesn't contain any text content.

Jaws does so probably because it doesn't know what to say for the new text that has been selected. Nothing isn't good because you don't know; "empty" isn't correct because <br /> isn't empty; and there isn't any other thing to say because there's no text content. So Jaws developers chose to repeat the previously selected text or at least some of the ending part as a last ressort. The sisue isn't present with <p>&nbsp;</p> because Jaws can safely and correctly say "space" in that case.

This is more a jaws-specific issue than something else, so there's not much to do unfortunately. The best would be of course to avoid usless codes such as <p><br /></p> in the editor, and more generally <br /> at the beginning or end of an element, or other strange things like that, but I know that it isn't easy. Different browsers have different ways of adding empty paragraphs, depending on how you edit, move or place the cursor, and it's again the same thing for lists, headings, table celles etc. In short, it's quite hard to filter out the bad code generated by browsers. You may try to do it with the most obvious and frequent ones, though. A possible track would be to override the default behavior of the enter key, so that you insert what you want and not what the browser wants, but it's quite hard to get it right in all cases.