Pressing numlock while in input help mode may confuse beginner users

[nvaccessAuto]

Reported by mdcurran on 2014-06-26 11:15
A. If you turn on numlock while in input help mode, it is impossible to exit input help mode unless you turn off numlock first. Obviously this makes sense to the advanced user, but for a beginner user, they would be under the assumption that while in input help mode they can press any key or key combinations they like, and still be able to then press NVDA+1 to exit input help mode. But if they happen to tap numlock, this will not be true.

B. Pressing numlock while in input help mode, NVDA only announces "numlock" but not its new state (on or off). Again this leads to the confusion about what the key press actually did.

C. The Windows internal key state seems to get confused if you perform the following actions:

1. Press NVDA+1 to enter input help.
2. Press numlock to turn it on.
   sighted person reports that the numlock light does not come on
3. Press numpad6 to prove that its on.
   says numlock+numpad6
4. Turn off input help (but using the extended insert key on the 6 pack as numpad insert will not work due to numlock being on).
5. Press numpad6 to prove that numlock is still on.
   says 6
6. Press numlock to turn it off.
   says numlock on
7. Press numpad6.
   says 6
   1. Press numlock again.
      says numlock off
   2. Press numpad6.
      announces the next word

In short, following those steps shows that NVDA is badly screwing up Windows' idea of numlock toggling.

The problem is even worse if you're using Mouse keys. It is impossible to turn off numlock at all while in input help once it is on.

Possible solutions:
I think the best one would be to simply block numlock from passing to the Operating System while in input help if at all possible. It is possible to assign scripts to keys requiring numlock, so I can see the argument that you may want numlock to work. But based on the above rather serious issues, I think it best that we don't worry about that usecase. Or at least remember that you can turn on numlock first and then turn on input help with extended insert if you really must do that.

Some other options:

• Allowing the user to press esape to exit input help. This would give them a fail safe way as numlock would not affect this.
• Ensuring that NVDA announces the numlock state when it changes while in input help mode. This will make it more clearer. But as shown above, the state is getting mucked up some how anyway.

[nvaccessAuto]

Comment 1 by jteh on 2014-06-26 11:20
Unless there's a specific exception (and I don't think there is), I'm pretty sure we already do block numlock from getting to the OS in input help, as we block everything else. I suspect the keyboard driver (or maybe even the keyboard controller) actually handles numlock specially somehow.

[nvaccessAuto]

Comment 2 by nvdakor on 2014-06-26 11:21
Hi,
What about treating numlock and scoll lock the same way as caps lock (with caps lock set as NvDA key): pressing once would announce what the key is, pressing twice quickly would toggle the locks?
Thanks.

[nvaccessAuto]

Comment 3 by mdcurran (in reply to comment 1) on 2014-06-26 11:34
Replying to jteh:
If that is the case I guess the best option then is to ensure we don't block it at all, and make sure we announce the key state. This would solve a bit of confusion, and I guess the key state and light problem. This would provide the same experience as Jaws.

[nvaccessAuto]

Comment 4 by briang1 on 2014-06-26 15:46
Also while in this strange mode, using control and nump lock says pause, control and scroll lock and pause both say control break.
Its enough to make you go mad. I assume there is logic here, even if we cannot actually see it. Some bits are not masked correctly somewhere.

[nvaccessAuto]

Comment 5 by jteh on 2014-06-26 23:54
Solution:

• Add an InputGesture.bypassInputHelp property.
• In in InputManager._inputHelpCaptor, handle this new property exactly the way we handle bypassInputHelp on scripts.
• Implement this property on KeyboardInputGesture, returning True for numlock.

[nvaccessAuto]

Comment 6 by Michael Curran <mick@... on 2014-06-27 05:04
In [10faad5]:

Merge branch 't4226' into next. Incubates #4226

Changes:
Added labels: incubating

[nvaccessAuto]

Comment 7 by Michael Curran <mick@... on 2014-07-11 23:39
In [ec7c307]:

Merge branch 't4226'. Fixes #4226

Changes:
Removed labels: incubating
State: closed

[nvaccessAuto]

Comment 8 by mdcurran on 2014-07-11 23:39
Changes:
Milestone changed from None to 2014.3