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.

I've seen this loads when editing text, but I've never noticed it happen elsewhere before... until just now. I was in the menu bar (VO+M) and hit W for Window, then down and it moved right (I think or left, but certainly didn't expand the menu). Confused the hell out of me.

But considering how often I notice this when editing text it has never done this elsewhere before. It even happened when trying to type this comment in, which is sadly not unusual.

Hi. I suspect that when this happens to me, it's because I had immediately beforehand pressed one key too many. I suspect that what happens is that I accidentally triggered screen rotation, so the next time it happens to you in any context, you might want to have someone sighted take a look at your screen. I have a Mac Studio and don't use a screen. If it is screen rotation, then the proper key command will rotate the screen back the way it's supposed to be, and the problem will be gone. What I'd love to learn is a key command that locks screen orientation so it never happens again.

I don't think you can rotate your screen with a shortcut on mac like you can on windows.

I think you may be on to something there though. I've experienced the same thing where I have to use the Vo keys to drill down into the apple menu.

It's just another example of voiceover being broken.

SNR has been really bad for me over the last week or so. Got the usual response from apple accessibility saying they're working on it. Obviously they're not very good at doing so.

Oh yes I remember that one on WiNdows when I could still see. The total panic you get when the screen suddenly turns on its side and you've no idea how it happened.

With the menu, can't remember how I fixed it if it was with the usual left+right combination or if I just cmd+tabbed back and forth.

This kind of bug is the thing that pushes me over the edge with the Mac if I'm having a bad day or am needing to do something quickly. Using a screen reader is hard enough if you are used to a visual world without also having to also be constantly fighting random behaviours that don't make sense. I have zero confidence that Apple will ever fix it either.