Option to disable interruption of speech for typed characters

[nvaccessAuto]

Reported by oriolgs58 on 2010-06-13 06:47
Reading interrupt is useful in certain applications like MIrc or miranda. If we are typing a message, and someone sends a message to us, NVDA will begin reading it, but as soon as we type another key it's going to interruptit. I think adding the ability to not interrupt speech when we type would be useful.

[nvaccessAuto]

Comment 1 by jteh on 2010-06-14 02:01
This is not specific enough to be useful. Please provide an exact description of what you are requesting, perhaps including a step by step, example scenario where it would be used.

[nvaccessAuto]

Comment 2 by oriolgs58 (in reply to comment description) on 2010-06-15 08:35
Replying to oriolgs58:

Hi.

We should have reading interrupt for certain apps, like mushclient and miranda

[nvaccessAuto]

Comment 3 by jteh on 2010-11-23 03:42
Changes:
Changed title from "Reading interrupt" to "Option to disable interruption of speech for typed characters"

[nvaccessAuto]

Comment 4 by drein on 2011-08-29 07:17
Another possible example is a webchat, built with accessibility in mind and with aria live region.
When I write a message, I lost what other people writes to me, because NVDA stops speaking incoming message as I type a letter, and I must take the cursor to review the text.
I'd like to have a checkbox option, perhaps in keyboard settings, like: "writing interrupt".
I'm sure, only for example, that Jfw has this feature, but I am not able to tell you where it is, since they have changed their menu option in the last version and I don't use it anymore.
If this feature can be temporaly be made with a simple plugin, please give me some hints.
Thank you.

[nvaccessAuto]

Comment 5 by katsutoshi on 2011-08-29 07:42
How about pressing NVDA+2 to disable speak typed characters?
If "Speak typed characters" are "off", I think NVDA doesn't interapt when your are typing something during it reads incoming messages.

[nvaccessAuto]

Comment 6 by drein on 2011-08-29 07:45
Unfortunately it isn't so.
Try to read something and press a key.
NVDA will stop.
It doesn't matter if you are reading a book, a message, a system alert.
anyway thanks for your answer.

[nvaccessAuto]

Comment 7 by camlorn on 2012-12-18 21:03
I would love to see this, too, and can provide a better description of the functionality, as it is functionality found in jaws.
Primarily, I would like this for mudding: playing a mud is challenging without this. I just tried for the first time, and it is very very difficult, so I looked and found this.
Anyhow. The proposed functionality would work as follows: an option somewhere in the program, probably most useful as a hotkey that toggles it, that makes it such that (1) pressing any key or key combination does not interrupt anything speaking or queued to be spoken and (2) makes an exception for a single tap of the control (or some other) key so that the speech buffer can be flushed, and exceptions for certain other keys (note 1).
Primarily, this is useful for everything above, but let's add mudding to that list: typing combat related commands and the like becomes possible without losing the messages. This is basically an extension of the chat program thing as applied to muds, but the functionality covers all of these cases and more.

note 1: It makes sense, for example, to have the object review and the navigation keys, i.e. flat review and text navigation, interrupt speech as the user is providing a request for information at that point. It probably makes sense to (1) have an option to control whether nvda keys interrupt speech or (2) to just assume that some or all nvda keystrokes should.

[nvaccessAuto]

Comment 8 by stewie on 2012-12-18 21:08
This would be especially useful in a number of situations as mentioned above. I have also found that when a help baloon pops up I'll be typing and it'll just stop what it was saying, and some help balloons can't be viewed by going to the system tray. This would also be useful if using a program such as skype talking, where the received message gets interrupted.

[nvaccessAuto]

Comment 10 by dallasobrien on 2012-12-24 15:50
yes, i to would find this useful, as many times i've missed important messages, both in chats, and from the system, and can't find out what it was trying to tell me.
i also agree, that probably all nvda commands should be exempt from the non interupt. in fact, really, the only thing we need non interupting, is the actually letter keys on there own. as in, only for typing. not for commands. as this would still let nvda be very responsive to input.

[nvaccessAuto]

Comment 11 by camlorn on 2012-12-24 16:00
Here's a more detailed list of the functionality I, personally, would like to see, so that others can add or remove from it.

When typing interrupt is enabled:

-the alphanumeric keys, the enter key, the shift key, and the NVDA key do not stop speech.
-the arrow keys, the backspace key, the home key, the end key, the pgup/pgdn keys all optionally interrupt speech with the options put in (1) the keyboard options or (2) a keyboard interrupt dialog. Should no dialog be added, these keys interrupt speech.
-the control key always stops speech (maybe this should be configurable).
-any keystroke not in the above list--the function keys, commands involving the NVDA key or modifier keys do not stop speech. At this point, such keystrokes are explicit requests from the user to have NVDA say something, and jnot having NVDA say something will, in many cases, make this a frustration instead of a feature. This includes the tab key--if I have to wait through a block of messages to hear that I tabbed to the checkbox to disable typing interrupt, for example.
-finally, and this one seems silly to say as it's obvious, but I'm including it for completeness: quitting nvda immediately stops speech.

This is my last comment, at least until someone else comments, I promise.

[nvaccessAuto]

Comment 12 by jteh (in reply to comment 11) on 2012-12-26 06:09
The most logical/consistent thing to do would be to interrupt for all command keys (i.e. any key spoken by NVDA's speak command keys option, which means anything other than characters or space bar). However, your requirements below don't match this. Also, things get nasty if you have speak typed characters and/or words enabled at the same time, which is the default in NVDA. Replying inline:

Replying to camlorn:

-the alphanumeric keys, the enter key, the shift key, and the NVDA key do not stop speech.

• The enter key is currently treated as a command key, as it isn't a character and often "executes" something. To be consistent, we should interrupt for enter.
• NVDA maps the shift key to pause speech. While I understand why you want this, if we do as you suggest here, speech pausing will be lost for anyone who uses this option.
• I see no reason that the NVDA key shouldn't interrupt.

-any keystroke not in the above list--the function keys, commands involving the NVDA key or modifier keys do not stop speech.

This doesn't make sense and seems to contradict your later points. These are commands and definitely should interrupt.

[nvaccessAuto]

Comment 13 by camlorn on 2012-12-27 02:02
I see my contradiction. That's what I get for attempting to use legalese, and not proofing extra carefully.

For the shift key: it may pause speech, but the issue is this.  The point of such a feature is that it would allow someone to type while listening to incoming messages, and not being able to type capitals or special symbols like the question mark or the exclamation, etc, is a pretty major limitation and pretty much makes the feature useless.  I discuss this a bit below.
For the enter key: in the applications in which I disable typing interrupt, I am continually receiving messages, and there is a great probability that having the enter key interrupt will in fact make me miss one.  Jaws has this as a separate option, perhaps make it one here, with a typing interrupt dialog to configure this.
For the NVDA key: that's not needed.  I just said that it shouldn't interrupt based off the fact that I have been known to frequently press the key in jaws, and then hear a message.  Whereupon I wait to hear the message before finishing the command, and interrupting speech.  Not needed, no, but perhaps makes someone else besides me have an easier time.
For the backspace: definitely optional, even moreso than shift, but useful all the same.
In NVDA, Jaws, and Voiceover,  I frequently use control to "flush the speech buffer"--I'm not sure what the correct technical term for this is.  Since shift is different functionality, then perhaps only have it interrupt speech when that option is enabled.  In all honesty, in voiceover, ctrl is pause/resume speech, but the two features are the same--pausing speech and then moving over to something else or having another message come in is the same as stopping speech and doing the same--that is, pausing speech includes stopping speech, and these could easily be folded into one key--probably the control key, if this gets added.  Pausing speech is the rectangle, stopping it is the square, to use the classic analogy.
It makes sense to force typing echo off.  These are mutually exclusive settings, definitely.  This is another spot that I'd love to see application-specific settings--time to go have a look at that ticket (there was some sort of solution there).
As for the contradictions in my earlier comment: I noticed that, 95% of the time, when looking at these, the first comment is "provide a detailed specification".  Perhaps I went too far in the other direction.  Perhaps I need to let them sit for 3 days before posting if I want to try that.  My point wasn't for that to be the final specification, my point was for that to be a jumping off point for discussion.
Finally, popularity.  I know of at least one person who wants this besides myself by online name (not here, on Alter Aeon), and believe there to be more.  It would make a number of things easier--pretty much anything that calls the NVDA api for a chat-like interface, and also for realtime console apps that involve some sort of realtime chat content or something (Those of us using ssh, sometimes--this case is rare, the other isn't).  I've been trying to get people to come discuss this, and I have seen interest, but no dice yet.

[nvaccessAuto]

Comment 14 by jteh (in reply to comment 13) on 2012-12-27 05:11
Replying to camlorn:

For the shift key: it may pause speech, but the issue is this.  The point of such a feature is that it would allow someone to type while listening to incoming messages, and not being able to type capitals or special symbols like the question mark or the exclamation, etc, is a pretty major limitation and pretty much makes the feature useless. 

I understand. It's just something that needs to be documented. Pausing will not be possible if this option is enabled. More below.

For the enter key: in the applications in which I disable typing interrupt, I am continually receiving messages, and there is a great probability that having the enter key interrupt will in fact make me miss one.  Jaws has this as a separate option, perhaps make it one here, with a typing interrupt dialog to configure this.

I'd prefer to keep options to a minimum here. I guess this could go in the keyboard settings dialog if absolutely necessary.

In all honesty, in voiceover, ctrl is pause/resume speech, but the two features are the same--pausing speech and then moving over to something else or having another message come in is the same as stopping speech and doing the same--that is, pausing speech includes stopping speech, and these could easily be folded into one key--probably the control key, if this gets added.

We used to do it like this, but it caused problems when attempting to continually shut up speech when there is a lot of incoming text (6485c2d). This won't be reintroduced. If you enable typing interrupt, you will lose pausing. If users of this feature can't make that sacrifice, the feature won't get added.

As for the contradictions in my earlier comment: ... My point wasn't for that to be the final specification, my point was for that to be a jumping off point for discussion.

That's fine. Discussion is good.

Finally, popularity.  I know of at least one person who wants this besides myself by online name (not here, on Alter Aeon), and believe there to be more.

I understand the use cases, but they still cover a relatively small group of users, so this is low priority for us. Of course, this can be expedited if someone wants to contribute the code.

Another issue is that typing interrupt should possibly be more generic than just the keyboard. We may need to call it input interrupt, since it also covers input from other devices such as Braille displays.

[nvaccessAuto]

Comment 15 by camlorn on 2012-12-27 23:15
How hard is this to actually code? I do know some programming, I'm working on a computer science degree after all, and donating this code isn't off the table for me, save that I don't know NVDA architecture. Are we talking hours? Days? Weeks? I'm not sure how hard adding such a feature would be, given the NVDA architecture, and maybe this ticket is a mountain. I need to move NVDA coding up the list of things to look into yet again.
I am a power user, I won't deny that--my first recourse is the terminal for stuff, when I can, and the like--I fully understand that the concern goes towards the hundreds of users who would be benefited by the other feature over there that lets them do their job, etc. I would like to see this, though, and I have found others who would like to see this...if only I could get them to come comment. It's hard to estimate the number of users, but it's probably somewhere in the low double digits.
Sacrifice pausing? No problem. No problem at all, at least for me.
The enter key is important to me, though. I don't know how important--I've had that option on forever in jaws, and don't know how hard moving backwards to not having it would be.

[nvaccessAuto]

Comment 16 by jteh (in reply to comment 15) on 2013-01-08 12:26
Replying to camlorn:

How hard is this to actually code? ... Are we talking hours? Days? Weeks?

The code isn't particularly difficult. The input framework already supports this kind of stuff quite nicely. The big issue is getting the requirements correct and deciding how to handle edge cases such as the enter key and what to do for input from other places; e.g. button presses on a braille display. (Anything that goes into the main code needs to be polished, so it's not sufficient to just get it working for one user's particular use case.) Once the requirements are nailed, it'd probably be less than an hour of work for someone who knows Python and NVDA well.