The only way to achieve this function without NVDA interrupting while holding down keys such as your arrow keys is by using the builtin sleep mode. NVDA shift Z. This doesn't stop NVDA from speaking, however, makes all key response stop within the app. It's a toggle function.

No, you cannot do it programmatically, the think you might try however is installing a low level keyhook through Win32 API to stop nVDA from receiving input, bare in mind, though that using this function will make you unable to stop any speech, until your game has a function which will send a null value to the screenreader

Sam is right. It is the repeat keys that are silencing NVDA.
There is no way to fix it through the NVDA controller client, though that would be awesome.
The sleep mode that others suggested, (accessed with NVDA shift Z on the laptop keyboard layout and NVDA shift S on the desktop keyboard layout) seem to solve it nicely, though people have to remember to press those each time they launch your game.
NVDA in sleep mode still speaks any messages you send to it through the NVDA controller.
You can enable sleep mode programmatically for your game through an NVDA app module or addon, but that would require people to install that app module / addon.

Sam's low level keyboard hook will probably solve it too, once it is finished.

In A Hero's Call I solved it by changing the "Windows Filter Keys" settings to disable repeat keys.
I would first save your filter key settings to a file when AHC launched, so I could restore them.
Then whenever the game window was active I disabled repeat keys, and when you alt tabbed away, closed the game, or the game detected itself crashing, I restored the original filter key settings.
I would rather not adjust the filter key settings and then be responsible for setting them back, but I want gamers to have a good experience, and the alternatives are not great.

Aprone mostly avoided the issue in Swamp by making the right mouse button be the only valid move forward key.
Since that was the key you held the most, and mouse buttons don't cancel speech, it solved it most of the time.

Mouse and gamepad buttons don't cause the issue, but they give you a new issue.
Namely NVDA has been cancelling speech for you whenever it detects a key press, so when you enable sleep mode, or use mouse or gamepad buttons, now speech never gets cancelled automatically.
Players actually do want speech cancelled when pressing most keys, such as quickly arrowing through a menu. They want to hear the item they just moved to, not the 5 they quickly moved passed.
This is easier to solve though, since the NVDA controller client provides a method for cancelling speech, so you can just call it whenever your game detects a mouse or gamepad button.
Or even when it detects a key press, assuming sleep mode is on, since sleep mode will stop even normal key presses from cancelling speech.

Then you get the issue that players also like repeat keys in some circumstances, such as holding an arrow key on a grid based map.
Players tend to like to move around the grid map very quickly by holding an arrow key, which acts like it is repeating the key.
You can solve this by just keeping track of which keys are held and triggering your own sort of repeat keys internal to your game.
NVDA will never see those since they are just within your own code, not running through the whole Windows input system.

I have spent a lot of time on input for my next project, especially around the use of gamepads.
Maybe it is just nostalgia, but I think a game just feels better when I'm playing with a gamepad.

Instead of using NVDA controller client directly, you can use Tolk, which will also handle output to other screen readers; JAWS being the other most important one.

I assume you are using C# if you are using XNA.
If you are interested in the C# code for adjusting filter key settings, email me at [email protected] and I'll be happy to pass it along.

Hope some of that is helpful.

Yeah, sorry about that.
Most of the time AHC is able to detect a crash and switch filter keys back to the original settings before closing, but some crashes, or as you say, killing the process, are not detected by it.
When you launch it again it is able to detect that it did not restore the filter key settings previously, and so it fixes them the next time you close it.
It is certainly a downside to that approach, but on the other hand it solves the problem pretty specifically by just disabling repeat keys at the source.
I made a small repeat keys fixer program that restores Windows default filter key settings, because when developing the game there were a lot more cases when I would break my own filter key settings.
Though I think the final game does a pretty good job of not breaking them.

Maybe the low level keyboard hook would be safer, assuming Windows removes it cleanly when a crash occurs.
I wonder if it will work though, because I assume NVDA has to install a low level key hook to detect the key presses that cancel speech in the first place.
So will a new keyboard hook be able to intercept and cancel repeat keys before NVDA's key hook sees them?

This page says the key down message does tell you if it is a repeat key or not:
https://docs.microsoft.com/en-us/window … wm-keydown
quote: The previous key state (bit 30) can be used to determine whether the WM_KEYDOWN message indicates the first down transition or a repeated down transition.