Hi.  I just discovered by accident that if you use the NVDA table navigation commands while in focus mode such as the list of messages in the Gmail standard view, the screen orientation flips.  I just checked the archive for the Windows Access with screen readers list, and it looks like there's a conflict between the windows flip screen orientation commands and the NVDA table navigation commands.  I won't cross-post the message.  I know JAWS uses the same table navigation commands, so JAWS users would have the same problem.  Since I use NVDA to navigate the Internet, I figured this observation would be appropriate to this list.  I'm using NVDA 2021.3.1 with Windows 10.  I don't know the exact version, since I'm accessing the interface remotely at the moment.

Louise

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

Hi

I’m not sure this hierarchy is correct. the NVDA passthrough command exists so that you can pass a NVDA command through without it being processed by NVDA.  Control+alt+LeftRightUpDown arrows all alter screen orientation but if you issue one and you are in a document but not in a table, NVDA says “not in a table” and it is in that situation you use passthrough followed by the appropriate command to affect the screen orientation.intercepted ,

 

Cheers

Chris

 

Sent from Mail for Windows

 

From: Brian Vogel
Sent: 07 January 2022 22:52
To: nvda@nvda.groups.io
Subject: Re: [nvda] Using table navigation commands in focus mode flips Windows screen orientation

 

The hierarchy of command key processing in any operating system will be:

1. Operating system itself.  Windows in this case.
2. Accessibility Software.
3. Application Software.

And as soon as one of the above has processed a command, that's where it stops.  The next member of the command processing bucket brigade is not passed "the bucket."

I'm guessing that the command that changes screen orientation is not a toggle, or else NVDA should never have access to that keystroke.  My guess is that it's strictly a "flip sideways" command that only gets processed by Windows (for the display adapter/driver) if the screen is not already in the flipped state.  If it is, it will then not be processed and continue down the chain.

Just curious, but what's the exact sequence to make this happen?  I'd love to try it out myself for the fun of it .

I am confused as to why one would have to use the NVDA pass-through command to make the correction since if CTRL + ALT + Up Arrow is a OS level command it should never be handed to NVDA to begin with.

On my laptop, without any screen reader running, CTRL + ALT + Left/Right/Up/Down Arrow has no effect.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The instinctive need to be the member of a closely-knit group fighting for common ideals may grow so strong that it becomes inessential what these ideals are.

       ~ Konrad Lorenz (1903-1989)

 

 

Hi all,

First, to answer the original question, Control+Alt+arrow keys is typically used by Intel display drivers to set screen orientation. I believe you can turn off a setting in Intel graphics utility to prevent this in the future.

To answer the subsequent discussion: the picture described by Gene is a simplified version of what is actually happening. In fact, it is a bit more complicated, but it goes something like this:

There is a family of features and commands specifically designed to work with edit fields, collectively grouped under "editable text". Editable text support consists of:

1. A way to detect text ranges inside an edit field. Through a concept called text infos, NVDA can ask the app or accessibility API for the text of a control. For edit fields, it includes the text content, and if defined, the label (name) of the edit field. For simplicity, text infos in edit fields will deal with field content (internally, NVDA sees it as value of the control; ask me offlist as to why this is the case as it requires explaining accessibility API properties, something well beyond the scope of this list).
2. A way to determine where the cursor (caret) is at, along with cursor movement commands. Cursor movement commands, in turn, rely on a concept of "movement unit" such as character, word, line, sentence, or paragraph.
3. The actual cursor movement gestures such as arrow keys.
4. Customizations for specific edit fields such as ones requiring screen scraping, different accessibility API's, and in an extreme case, browse mode documents. Browse mode documents is quite a complicated case because NVDA must obtain the entire web document (some developers call this "eating or swallowing the document") to present something that is navigable and presentable.

To use Gene's example, here is what NVDA does when you press down arrow key from Notepad:

1. NVDA first determines the source of the just performed command. If located on an edit field (like this case), NVDA knows that down arrow key is assigned to cursor movement command, so it invokes line movement script. The source of this script is not the application itself, but rather, the control that NVDA recognizes as an edit field. I may come back to the "magic" behind it upon request.
2. From the line movement script, a helper function is invoked whose job is to coordinate caret movement and new position announcement if possible. One of the parameters of this helper function is the movement unit, and since down arrow moves to the next line, the movement unit will be set to "line". The gesture (down arrow) is also pased in.
3. The helper function tries to locate where the caret is at. This involves locating the text info associated with the open Notepad document and getting the caret posistion if possible.
4. If the caret could not be located, down arrow is "pressed" by NVDA and the helper function ends, and so does the down arrow command behavior. How a screen reader can "press" keyboard keys is beyond the scope of this thread, but suffice to say that this technique is employed in several add-ons.
5. By now the helper function knows where the caret is (NVDA calls this "bookmark"), so down arrow key is "pressed". This allows Notepad to update the cursor position.
6. NVDA waits up to 10 milliseconds for the new caret position, and if the cursor did not move (when the timeout elapses), NVDA gives up.
7. If NVDA determines that the caret did move, it announces the movement unit associated with the just performed movement command, which in our case is announcing the line where the caret is located.

Hope this helps.

Cheers,

Joseph