Skim reading: prevent character and word navigation from interrupting say all

[bhavyashah]

Steps to reproduce:

1. Ensure that the Allow skim reading in Say All Keyboard Settings check box is checked.
2. On any document (web, Word, etc.) with multiple lines and paragraphs of text, initiate a say all.
3. Press the line and paragraph (and sentence too if testing on a supported application) navigation commands and observe that say all does not get interrupted.
4. Press the standard character or word navigation commands, i.e. left/right or Ctrl+left/right arrow keys, while the say all is still taking place.

Expected behavior:

• Say all should jump in the direction and amount instructed by the navigation commands, but should not be interrupted and halted.

Actual behavior:

• The desired navigation occurs but stops the say all then and there.

System configuration:

NVDA version: 2017.4 stable
NVDA Installed or portable: believe that this issue is universally applicable.
Windows version: - Windows 8.1

Notes

• This bug or discrepancy was noticed by some users on the NVDA Users International e-mail list. Therefore, apart from me, there are several other users who find the exclusion of character and word navigation from skim reading buggy and unusual.
• I have successfully tested and reproduced this in Microsoft Word focus mode and Firefox browse mode, and am thus led to believe that this issue is universally applicable.

[LeonarddeR]

Did you initiate a caret say all or review cursor say all? Does this make any difference in the behaviour you observe?

[bhavyashah]

Review cursor is set to follow system caret in my NVDA configuration. Even if I uncheck this Review Cursor Settings check box and stop review cursor from following system caret, testing with the provided STR yields the same result. Just to clarify, I am issuing a standard say all using NVDA+A (laptop keyboard layout).

…

On 12/27/17, Leonard de Ruijter ***@***.***> wrote: Did you initiate a caret say all or review cursor say all? Does this make any difference in the behaviour you observe? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #7879 (comment)

-- Best Regards Bhavya Shah Blogger at Hiking Across Horizons: https://bhavyashah125.wordpress.com/ Contacting Me E-mail Address: [email protected] Follow me on Twitter @BhavyaShah125 or www.twitter.com/BhavyaShah125 Mobile Number: +91 7506221750

[LeonarddeR]

I looked at the code briefly and it actually seems to me that the author of this function intentionally did not include word or character navigation gestures in those that resume say all. cc @michaelDCurran @jcsteh

[jcsteh]

This wasn't my work, but IMO, word/character navigation during skim reading doesn't make sense. Characters and words are just too short. By the time you've pressed the command to move by character/word, say all is probably already several words ahead. Say all can only position the cursor at the start of lines, not words or characters. Even if we accept that words might be useful, I'm not sure why you would want to move by character at all. All that's going to do is cause a partial word to be read when you resume say all. What's the point of that?

[bhavyashah]

@jcsteh That’s a fair point, but only since you and I are users of ESpeak at speech rates that are incredible relative to the average user. While there are users using NVDA with ESpeak at speeds such as 45% and 55% with rate boost enabled, we must recognize the prominent presence of those using slower and more human-sounding synthesizers as well as those employing ESpeak at 30% without rate boost enabled. Character and word navigation during say all seem far more useful for such users.

[derekriemer]

This isn't actually a quick fix since the reading starts at the beginning of lines. Removing quickfix and good for new dev.

[derekriemer]

oh, quickfix is not on there anyway.

[Brian1Gaff]

Might I also say that I have never been able to run the rates often considered as'normal' by many programmers and techy folk, I am a native English speaker and find very high rates quite stressful if used for a prolonged periiod. On vearious forms of skim reading on different screenreaders this makes it far worse in fact as your brain does not hav the time to reprocess the bits you need to add! Just saying, that is all. Brian

[LeonarddeR]

@derekriemer: These labels were actually bad estimations on my end.

I wonder whether speech refactor changes anything to say all behaviour with regard to this?

[bhavyashah]

Even if we accept that words might be useful, I'm not sure why you would want to move by character at all. All that's going to do is cause a partial word to be read when you resume say all. What's the point of that?

My views have evolved on this. I agree with @jcsteh in that Character navigation doesn't make sense in the context of skim reading. I'll still push for word navigation though. There is definitely uncertainty here, but I think I can probably see myself using word navigation when reading Spanish or Math at a slower rate and possibly see myself using word navigation when reading English text deeply and at a slower-than-usual rate.

[Adriani90]

I agree with @jcsteh word navigation in skim reading doesn't really make sense, this will rather cause many repetitions of one word. If you want to read a text area word by word, then it is comfortable enough to do the word by word navigation and start the say all again after you explored the relevant part you wish.
I am closing as won't fix.
If you still have any argument for this, please comment and we can reopen.