Up/Down Arrows Sometimes Move by Character

I believe this behavior is related to a wider problem where the Mac thinks another key is being pressed. On both my MBA and MBP, quiknav sometimes is turned on simply by my pressing the right arrow key by itself. Similarly, sometimes one computer or the other will think the command key is being depressed, as evidenced by what happens or doesn't happen when I press other keys. When turning VO off on my late 2016 MBP to reboot it (which, unfortunately, I have to do frequently because of bugs), it often thinks I'm holding down the spacebar and tries to evoke SIRI, even though I've only pressed the command key. Etc. Keys would also get ghost-pressed in Boot Camp on my MBA--either alt or Win. Years back, I had at least one Dell Lattitude with the same sort of issue. In all cases, finding out which key it thinks was pressed and rapid-pressing it a time or two unsticks it, which corresponds to why turning quicknav on and then off would work (again, sometimes I've actually found quicknav on, even though I'm quite certain I was just hitting the right arrow key through a document and was nowhere near the left). I think it is happening in the membrane or butterfly mechanism beneath the keyboard. I suspect it's not particulate matter, which I've also experienced, but rather strain on the chassis from either my palm or how the machine is resting. Whatever the case, phantom keystrokes among the command and cursor keys are a problem.

This bug is still present and always as disruptive when it happens.

This frustrates and disorientates me manytimes every day and it has been doing so ever since I started using VoiceOver on the Mac. I hate it.

A similar thing is when using left and right arrows it will sometimes move by word not letter as if I am holding down option. This is even more maddening as I am never sure how to fix it. I end up holding option or option and shift for a bit until it fixes itself. I hate this one even more. Text editing is so terrible on the Mac - it is like doing battle every time you have to do it. It should not be this bad.

I have a theory that might explain why this happens thanks to my experience with Vosh.

When the text selection changes, screen-readers on MacOS are notified through the accessibility infrastructure. Unfortunately since these notifications are not sent when the user tries to move the caret out of bounds as there's no actual selection change, screen-readers have to filter the user's keystrokes, check whether the focused keyboard element has selectable text, check whether the movement is legal, and either let the event through or emit an audio cue indicating that the cursor is at a boundary. This works in the majority of cases, with Terminal being a glaring exception which implements its own special accessibility notifications,, and I believe this is also how caret browsing is even possible on Safari when VoiceOver is enable.

On MacOS, input event tapping is done through an API called Quarts Event Services from CoreGraphics which is specifically designed with accessibility in mind (IOKit can be used to sniff input events at a much lower level but to my knowledge does not support filtering them). To ensure that accessibility applications have full control over input events, these events are filtered and passed to a handler in the accessibility application, which in turn is responsible for deciding what to do with them and return a response. However, to prevent an irresponsive accessibility application from accidentally making the whole system unusable by filtering all the input, Quartz disables any taps whose handlers do not respond after a short period of time. This means that if a screen-reader gets busy and doesn't respond immediately to an input event, its tap is disabled, resulting in loss of input events until the accessibility application resumes responding and re-enables the tap.

My theory is that VoiceOver sometimes gets way too busy interacting with the blocking accessibility infrastructure trying to decide how to handle the user's arrow keys, causing Quartz to disable its input tap leading to missed input events, potentially resulting in a situation in which it thinks that a key is still being pressed when in fact it isn't because it missed its key up event.

Assuming that my theory is correct then I can think of two possible workarounds to mitigate the problem that can be implemented in accessibility applications like screen-readers:

1. Process input events on a dedicated thread;
2. Clean up the current record of pressed keys when an input tap is disabled by Quartz.

Has anyone tried the following?

1. Disable the Left Arrow plus Right Arrow shortcut to toggle QuickNav.
2. Disable Single Key QuickNav (VO plus 'q').

Just an idea. . . 😇

That doesn't fix the problem. I think it is ever so slightly less annoying to deal with if you do disable the shortcut, but it definitely doesn't fix the problem.