Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NVDA Browse Mode Fails to Navigate role="option" Items within role="listbox" #17569

Closed
khsbory opened this issue Dec 29, 2024 · 5 comments
Closed

Comments

@khsbory
Copy link

khsbory commented Dec 29, 2024

Steps to reproduce:

  1. Visit the following test page: https://khsruru.com/listbox/
  2. The page contains two listboxes. Note that these listboxes are intentionally not focusable via Tab key and do not respond to up/down arrow keys to demonstrate the issue (I acknowledge this is incorrect markup but it is helpful for testing).
  3. Attempt to navigate through the items within each listbox using NVDA's browse mode.

Actual behavior:

NVDA can only read the first role="option" item within the role="listbox". Subsequent items are inaccessible in browse mode. I activated "Speak Command Keys" and Speech Viewer, but when I tried to navigate in browse mode, nothing was captured in the Speech Viewer. Because the up/down arrow keys are also not implemented on the test page, there is no way to navigate the options in either browse or focus mode.

Expected behavior:

NVDA should provide a mechanism to navigate and read all role="option" items within a role="listbox" even when the listbox is not properly implemented for standard keyboard navigation (i.e., no tabindex or focus handling, and no up/down arrow key support). This should be available in browse mode. NVDA users should have a way to access these listbox options even when they are not implemented accessibly.

NVDA logs, crash dumps and other attachments:

There are no specific NVDA logs to provide for this issue, as it does not result in errors or crashes.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2024.1

Windows version:

Windows 11 latest version

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

Chrome Version 131.0.6778.205 (Official Build) (64-bit) (cohort: Stable)

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:

I cannot test with other version at this time because I only have one PC.

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

Yes. I have disabled all add-ons and restarted NVDA, but the issue persists.

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

Yes. The issue still occurs after running the COM Registration Fixing Tool.

@michaelDCurran
Copy link
Member

This is deliberate behavior for browse mode. role=listbox is interactive, and it is expected that focus / arrow keys is implemented correctly. It is equivalent to a select tag with size>1. Even in the contrived case where the author has not done this, the user can use NvDA's object navigation to move inside the listbox and access the items.

@michaelDCurran michaelDCurran closed this as not planned Won't fix, can't repro, duplicate, stale Dec 30, 2024
@khsbory
Copy link
Author

khsbory commented Dec 31, 2024

@michaelDCurran
You were mistaken about one of the points you mentioned. I was going to argue that lower-level items can be navigated using the NVDA object navigator. However, if you had thought about it a bit further, you would have realized that this presents a problem as well. This might be feasible if there are only around 5 or 10 options. But if there are over 50 items, such as in a birth year input field, clicking won't work even if you try to navigate and click using the NVDA object navigator. Why? Because it won't scroll. What are your thoughts on this?

@michaelDCurran
Copy link
Member

michaelDCurran commented Dec 31, 2024 via email

@khsbory
Copy link
Author

khsbory commented Dec 31, 2024

@michaelDCurran
I understand the fundamental principles of the role="listbox" attribute. I have thoroughly explained this point when raising issues in the past. However, in reality, there are numerous developers who do not adhere to these principles. To clarify, I am not suggesting that I will omit keyboard accessibility when implementing a listbox with this role. The problem is that many websites use the role attribute without implementing proper keyboard accessibility, ultimately harming users. Given this situation, can we truly insist on solely adhering to the ideal principles? I want to emphasize again: I am more than familiar with the attributes and implementation principles of role="listbox". My argument is that, in the face of this reality where these principles are often disregarded, we need to find ways to assist screen reader users in navigating these poorly constructed elements. Thank you.

@khsbory
Copy link
Author

khsbory commented Dec 31, 2024

@michaelDCurran
However, there's one aspect of your argument that I don't quite understand. If we follow your logic, shouldn't elements within a role="application" be inaccessible in browse mode as well? Let's delve into this logically. What is the purpose of the role="application" attribute? It's used to make a part of the web page behave like a desktop application, preventing browse mode from automatically activating. Therefore, following your reasoning, shouldn't it also be impossible to activate browse mode within an application role? The same principle applies to role="listbox". When the dropdown is expanded, the options are child elements intended to be selectable using the up and down arrow keys. But at the very least, when browse mode is enabled, users should be able to navigate these options using browse mode commands, just like menu items. What are your thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants