[Settings> Open/Close Navigation]: Neither name is descriptive nor changing name is announced by Screen reader for 'Open/Close Navigation' button.

[ghost]

Windows Terminal version (or Windows build number)

1.10.2383.0

Other Software

Test Environment:
OS: Windows 11 Version 21H2 (OS Build 22000.168)
Screen Reader: Narrator
Tool: Accessibility Insight for Windows

Steps to reproduce

Repro Steps:

1. Open Windows Terminal.
2. Open Settings page using "Ctrl + ',' ".
3. Open Narrator using 'Win + Ctrl + Enter' key.
4. Navigate to 'Open/Close Navigation', Observe the issue.
5. Then activate 'Open/Close Navigation' button and observe the issue.

User Experience:
Screen Reader user are impacted here as they will not be able to know whether navigation is open or close as changing name is not announced to them in addition to that name of the control is confusing when compared to visual view.

Guideline Reference:
https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships

Attachments:
Neither name is descriptive nor changing name.zip

Expected Behavior

Screen Reader should announce 'Expand/Collapse Navigation View' as name for control and when user activate it Screen Reader should announce the changing name of the button.

Actual Behavior

Neither name is descriptive nor changing name is announced by Screen reader for 'Open/Close Navigation' button. Screen Reader is announcing 'Open/Close Navigation' which is incorrect and When user activate 'Open/Close navigation' button Screen Reader remain Silent.

Observation: Same issue repro with NVDA Screen Reader.

[DHowett]

This looks like the upstream issue microsoft/microsoft-ui-xaml#3494, which they have accepted into their backlog.

[ghost]

We are tracking this bug here microsoft/microsoft-ui-xaml#3494 so closing this bug as External

[ghost]

Issue is still repro on below environment.

Test Environment:
OS: Windows 11 Version 21H2 (OS Build 22598.200)
Application: Window Terminal Preview
App Version: 1.13.10984.0
Screen Reader: Narrator

[carlos-zamora]

@v-rpundir
I'm a bit confused here. The bug is caused by microsoft/microsoft-ui-xaml#3494.
Since the XAML team has accepted the bug, can't we close this bug?

[ghost]

@carlos-zamora Here is summary of our current External process we follow in this case:

1. Your team can Resolve/Close the bug if the bug has external dependency by mentioning the External team's name or contact.
2. Then we will contact the external testing team to get Tracking bug ID (we prefer VSO Tracking ID instead of GitHub as it has Proper Tracking and External team should have to fix it to maintain its Product Compliance) which is XAML in this case.
3. After we get Tracking ID, we will mention it in this bug.
4. When External bug gets closed with A11yTTValidated, we will check this bug and in case it repro's we will reactivate/reopen it and if external bug closed with reason By Design/Won't Fix, we will close this bug.

A11yTTValidated: When the bug has this tag it means it is closed now from Testing team and no further action is needed in the bug so even if the Product team close the bug for their reference, it will not be considered as closed from testing team side.

I hope this helps in clearing the bug external Process.

Thanks :):

[ghost]

As now XAML team is tracking bugs in VSO we will get VSO tracking ID for this bug.

[ghost]

XAML VSO Tracking ID: Bug 41570653: [WinUI Accessibility-> Left Navigation Pane]: No success information announced by screen reader, when user invokes open/close navigation button.