Open jmuheim opened 7 years ago
jmuheim
commented
7 years ago The cool thing about a custom feature for this in NVDA would be that one could display additional infos, e.g. whether the currently pressed key is captured by NVDA (in browse mode) or whether it is sent to the OS. Also, in browse mode, one could display the name of the functionality that was triggered using the current key stroke (e.g. when pressing "h", one could display "Jump to next heading").
feerrenrut
commented
7 years ago @jmuheim Thanks for raising this issue. I can understand why this would be useful to you, however it's hard to prioritise this over the other issues that will help to support users more directly. I'll set this as a priority 3 for now. Perhaps @jcsteh would care to comment on this issue?
jmuheim
commented
7 years ago The interesting question is: where does NVDA (and also JAWS) interfere with those displayer-tools? Both of them intercept key strokes, but while the displayer-tools seem to send the key strokes further to the system, NVDA doesn't when in browse mode (which absolutely makes sense).
Maybe there is something like a "key strokes interception pipeline" in the OS (I'm speaking as a total amateur in this respect), and NVDA would need to intercept after those displayer-tools...?
jcsteh
commented
7 years ago Which tool are you starting first: the display tool or NVDA? Keyboard hooks execute from newest to oldest. In other words, if you start the display tool after NVDA, this might work. Note that we can't change this; it's just how Windows hooks work.
I also don't quite understand why speak command keys, speak typed characters and speech viewer aren't suitable here. That would give you exactly what you want: all key presses would be output to the speech viewer along with other spoken messages.
jmuheim
commented
7 years ago In other words, if you start the display tool after NVDA, this might work.
Sadly doesn't work either.
I also don't quite understand why speak command keys, speak typed characters and speech viewer aren't suitable here.
To spectators new to screen readers, the output of a screen reader is already pretty complicated, and it would be another layer of complexity to need to differentiate between output that is generated from the read content, and output generated by key strokes.
Also, the audio output needs much more time than visual output. It just feels much more intuitive to see pressed keys visually instead of hearing them, intermixed with all the other output of the screen reader.
As daily screen reader users, one may forget pretty fast about the fact that the audio output is pretty complex for a new user who has no prior experience on how screen reader output should be like.
jcsteh
commented
7 years ago I get that the audio output is complex, but presumably, if you're using Speech Piewer, sighted users would be primarily reading the visual output rather than the audio.
jmuheim
commented
7 years ago I already have the Speech Viewer open, which is a very cool thing. Still, the output is very complex for new users. I'm not talking about experienced developers here who are used to learn new computer things every day, but about e.g. secretaries of small companies who were assigned to test websites on accessibility (which happens pretty often). ;-)
mrazzari
commented
7 years ago @jmuheim I've had success with this tool by starting it after NVDA has started.
I've tested all other tools you mentioned in your initial comment, and also one called "ShowOff". Most won't work well, for example some would not display the Tab keypress, or NVDA commands, or are just ugly.
The PxKeystrokes I linked to above works great, though. QiPress is not too bad either, but you need to get the Pro version for it to look decent.
Both fail to capture NVDA+key combinations. Both don't work on NVDA dialogs (ie, NVDA+F7). PxKeystrokes also fails to display a single "Ctrl" press (stop speech). QiPress displays it, but only for as long as you're pressing it.
derekriemer
commented
7 years ago My guess is that wx has its own keyhook it's installing in these dialogs and it's stopping the keys from hitting you.
On Sun, May 21, 2017 at 9:35 PM, Manuel Razzari notifications@github.com wrote:
@jmuheim https://github.com/jmuheim I've had success with this tool https://github.com/Phaiax/PxKeystrokesForScreencasts by starting it after NVDA has started.
I've tested all other tools you mentioned in your initial comment, and also one called "ShowOff". Most won't work well, for example some would not display the Tab keypress, or NVDA commands, or are just ugly.
The PxKeystrokes I linked to above works great, though. QiPress is not too bad either, but you need to get the Pro version for it to look decent.
Both fail to capture NVDA+key combinations. Both don't work on NVDA dialogs (ie, NVDA+F7). PxKeystrokes also fails to display a single "Ctrl" press (stop speech). QiPress displays it, but only for as long as you're pressing it.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/6565#issuecomment-302991536, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGivfFIBVnXmlyyUJIrV_CbgaWsjWMuks5r8QKIgaJpZM4KySVX .
--
Derek Riemer: Improving the world one byte at a time!
Personal website http://derekriemer.com
jmuheim
commented
7 years ago Thanks for commenting, guys!
I want to point this out once again: if you really need one of these tools to work 100% like expected, you can install a virtual machine using VMware, VirtualBox or similar. Then run the tool displaying keystrokes in your host OS ("outside" the virtual machine), and NVDA (or any other screen reader) in the guest OS ("inside" the virtual machine).
This works very well.
Adriani90
commented
5 years ago It is really interesting that it works when using a virtual environment. @jmuheim the issue is still occuring with NVDA 2019.1 RC1. Right?
Adriani90
commented
5 years ago @leonardder is this something related to injected events similar to mouse events when using teamviewer or so?
Adriani90
commented
4 years ago I think this feature should be provided by a third party tool, i.e. the tools mentioned by @jmuheim and @mrazzari. Otherwise we end up in long discussions about security and vulnerabilities cause by NVDA displaying the keys. I know that technically this security problem exists anyway, but most people in corporate environments would become even more reluctant to NVDA, especially if they don't have much technical knowledge. Maybe an addon for this would be more suitable.
Adriani90
commented
3 months ago So what I understand is requested here basically, is to have the input help mode be displayed visually, while the function of the key press is still perfomred. Currently, when you enable input help mode, the keyboard is locked. So I suggest something like:
I'm an accessibility consultant, and I do a lot of demos with NVDA and other screen readers to non-impaired people (developers, content editors, etc.).
I'd like to use a tool that displays the key strokes visually on screen, so spectators can better follow me. There are different ones, e.g.:
Sadly, none of them works when NVDA is in browse mode (where key strokes are captured by NVDA). This is also true for JAWS.
Is there a way to fix this? If not, then at least I think NVDA should offer a functionality like this. I know that I can enable options like "Speak characters/system keys", but this is pretty cumbersome.
At the time being, as I'm usually on a Mac and run NVDA through a virtual machine (VMware Fusion), I can run Mousepose on Mac (which also displays key strokes), and this works pretty well, as the keys are only intercepted by NVDA within the virtual machine. But as I'm not always on a Mac, I'd like to have a method working natively on Windows.