When the keyboard focus moves to the "select subscription" list, JAWS/NVDA announces 'type to narrow down result' and the list name: A11y_VS code_Appling filter on subscription_Screen reader

[kapilvaishna]

Please do not close this bug. This bug should only be closed by Trusted Tester after verification.
"Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier."

GitHub Tags

#A11yMAS; #A11yTCS; #Win32; #DesktopApp; #A11ySev3; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Jan2024; #WCAG1.3.1; #FTP; #Screen Reader; #NVDA; #JAWS; #Element:List; #STP;

Environment Details:

Application: VS Code
Visual studio code version: 1.96.3
OS: Windows 11 Enterprise 24H2
Build: 26100.2605
Screen reader
JAWS Version: 2024.2312.53
NVDA Version: 2024.4.1

Repro Steps

1. Turn on Jaws/NVDA screen reader
2. Launch the VS Code.
3. Install the Azure Machine Learning extension and sign in.
4. Tab until the left toolbar (list of icons). This toolbar has a file icon, search icon, settings, etc.
5. Use the up/down arrow keys to navigate to the "Azure" icon and press enter
6. The Azure panel will now be active next to the toolbar.
7. Tab until the Machine Learning dropdown.
8. Tab till any subscription for example AML V1 Personal subscription.
9. Tab until the "Filter" button and press Enter. It will be a button with a funnel icon.
10. TAB till "Select subscriptions" combo box.
11. TAB till "Select subscriptions" list.
12. Observer that when the keyboard focus moves to the select subscription list, JAWS/NVDA announces, 'type to narrow down result' and the list name.

Actual Experience

When the keyboard focus moves to the select subscription list, JAWS/NVDA announces, 'type to narrow down result' and the list name. and if we type it will not filter the list. This will miss lead the screen reader user because keyboard focus is on list not on any edit filter.

Similar issue observed with following scenarios:

Scenario1: Creating a job Select an Azure ML job Schema

1. TAB till create job button and press ENTER key
2. TAB till list and observe the issue.

Scenario2: Setting Default Workspace

1. Open the Command Palette via the keyboard command Ctrl + Shift + P
2. Type "Set default workspace" and select the option from the dropdown list called "Azure ML: Set Default Workspace") and press enter
3. A list should appear that says "Select a subscription"
4. Use the up/down arrows to navigate the list until "AML V1 Personal 2" is selected, and press enter
5. A list should appear that says "Select a workspace"
6. TAB till list and observe the issue.

Expected Experience

When the keyboard focus moves to the select subscription list, JAWS/NVDA should announce the list name only.

User Impact:

Screen reader user will miss lead as focus is not on any edit filter, but JAWS/NVDA announces, 'type to narrow down result'.

Attachment

NVDA:

245220_NVDA2.mp4

JAWS:

245220_JAWS.mp4

Code snippet

Similar issue of scenario 1 and 2

[meganrogge]

@TylerLeonhardt looks like that aria label is getting applied to the wrong element?

vscode/src/vs/platform/quickinput/browser/quickInput.ts

Line 535 in 20934dd

private static readonly DEFAULT_ARIA_LABEL = localize('quickInputBox.ariaLabel', "Type to narrow down results.");

[TylerLeonhardt]

No that's intentional. The aria-label needs to be on the list because the input has aria-activedescendant and so any aria-label value on the input would otherwise be ignored.

Unless you have any idea how I could get the input to read something out and still have aria-activedescendant, I'm not sure how I'd fix this.

In a perfect world, I could attach aria info to the input box and it would be read in addition to the aria-activedescendant value... but that doesn't seem to be true.

[meganrogge]

Got it—thanks for explaining! That makes sense given how aria-activedescendant overrides the input’s aria-label. I don’t know of a way to have both read out simultaneously either, unfortunately.

One possible workaround might be to use aria-describedby on the input pointing to an offscreen element that includes the static label or context you want read. That can be read in addition to aria-activedescendant, depending on the screen reader, though it's definitely inconsistent across those AFAICT and we don't really want a hack here.

@kapilvaishna pls either downgrade or close this in light of this explanation.

[rperez030]

I have just reviewed the updated video. This bug highlights a genuine issue, in my opinion, but it involves more than just the aria-label. Users are expected to press the down arrow after entering text in the input field. When they do this, the widget functions as intended: it updates aria-activedescendant so that screen reader users have the impression that they are navigating the list and that focus follows the selected item.

However, if a user presses the Tab key instead and moves keyboard focus to the list, typing no longer filters the list—even if the accessible name suggests otherwise. I believe this scenario is unlikely to affect experienced customers, but it could impact beginners. Based on my own experience teaching VS Code and the fact that we have not received such feedback from customers, there may be grounds to downgrade this issue to sev3.

Ideally, the solution would be to ensure that typing on the list moves focus back to the input field, or to prevent the Tab key from focusing on the list directly.
@scottaohara