Disabled (unavailable) GUI items should not be skipped during object navigation

[CyrilleB79]

Steps to reproduce:

1. Open braille settings
2. Uncheck braille cursor
3. Move navigator to next object

Actual behavior:

Nav object moves to "Show messages" checkbox which is the next GUI item that is not greyed out.

Expected behavior:

Nav object should move to the next GUI object ("Blinking cursor"), whether it is greyed out or not should not matter.

Greyed items are visible to sighted users. So unless there is a good reason, blind people should be able to see them too. Greyed items convey meaning in a GUI and not being able to see them causes people to miss information conveyed by the GUI.

Taking again the example of braille panel:
If a user has unchecked show cursor by mistake, he may not find "Blinking cursor" option while tabbing in the dialog. Using an object navigation that does not skip greyed items would allow to see the item and see that it is unavailable.

If however a good reason not to include unavailable GUI items in obj navigation is exhibited, at least they should be included in object navigation with when simple review mode is disabled.

Additional notes

• With current NVDA it is still possible to set nav object on an unavailable (greyed out) GUI item; for this, put the mouse cursor on the unavailable object and route nav obj to mouse cursor.
• Another way to see unavailable GUI item is to use screen review mode instead of object review mode and use review commands.
• The issue also occurs elsewhere. For exemple in folder property dialogs of windows Explorer, for standard Windows folders such as download, the name is greyed out. It cannot be reached with object navigation commands, no matter if simple review mode is enabled or disabled.
• On the opposite, there are other places where the issue does not occur with simple review mode disabled. Example in standard Windows application windows (e.g. Notepad): press alt+space and use object navigation to move in the menu; "Restore" is reachable with simple review mode off, but not with simple review mode on.

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

2023.3beta2

Windows version:

Windows 10 21H2 (AMD64) build 19044.3324

Name and version of other software in use when reproducing the issue:

N/A

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

NVDA 2023.2 and all many other older versions had the same behaviour; not retested it just now however.

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

Not tested now but this issue has always been there in spite of NVDA updates.

[seanbudd]

as far as I can tell this is an unavoidable implementation issue with native Windows form components, which wxWidgets relies on. Windows prevents focus by force to disabled form controls.

[CyrilleB79]

as far as I can tell this is an unavoidable implementation issue with native Windows form components, which wxWidgets relies on. Windows prevents focus by force to disabled form controls.

@seanbudd are we sure to understand each other?
My request is about being able to move the navigator object on disabled items, not about moving the focus there.

[seanbudd]

My mistake. We have code that intentionally skips over these items during object navigation. Does toggling "simple review mode" allow you to workaround this issue?

[CyrilleB79]

No, for the examples given in the initial description these objects are unreachable. As already indicated in the initial description, it does not change anything if simple review mode is enabled or disabled.

In the meantime, I have found that the disabled items of Notepad's context menu (Windows 10) are reachable through object navigation, but only when simple review mode is disabled.

I think that all unavailable objects should be reachable by object navigation when simple review mode is off. The fact that some object are not reachable when simple review is off is a bug IMO.

Additionally, I think that the simple review shouldn't skip unavailable object either, for the reasons I have described in my first comment: although greyed, an unavailable control still conveys meaning in a GUI and the user should be aware of it.

[CyrilleB79]

@seanbudd, I can see that you have added the "triaged" label, which means that you accept disabled object to be reported during object navigation.

Could you clarify the following questions:

1. Should disabled objects be reachable also in simple review mode or in both review mode? As written before, my opinion is that it should be reachable in both modes, but I would like to know NV Access opinion.

2. You write:

We have code that intentionally skips over these items during object navigation.
Are you thinking to isUsableWindow function in NVDAObjects\window\__init__.py? Or/and something else?

3. I guess that such a modification, that would change the behaviour of .next/.previous methods would be considered API-breaking. Do you confirm this?

[XLTechie]

Should disabled objects be reachable also in simple review mode or in both review mode? As written before, my opinion is that it should be reachable in both modes, but I would like to know NV Access opinion.

For what it's worth, I think Cyrille is right. Simple mode is not intended, as far as I understand it, to conceal or reveal more or less "real" screen elements--it is only intended to compress the number of useless containers the user has to walk through while accessing objects. Unless I'm wrong about its purpose.

[seanbudd]

Should disabled objects be reachable also in simple review mode or in both review mode? As written before, my opinion is that it should be reachable in both modes, but I would like to know NV Access opinion.

It should be reachable in both modes.

Are you thinking to isUsableWindow function in NVDAObjects\window_init_.py? Or/and something else?

I'm not sure, I think so. I have not investigated the code. The information stated was provided by Mick.

I guess that such a modification, that would change the behaviour of .next/.previous methods would be considered API-breaking. Do you confirm this?

I'm not sure, I think so. I have not investigated the code.