[Windows Terminal>Settings] Screen reader is not announcing the 'Open/Close' state on activating the 'Open/Close' navigation button. #23914

Open
opened 2026-01-31 08:55:57 +00:00 by claunia · 2 comments
Owner

Originally created by @Saurabh220304 on GitHub (Dec 29, 2025).

Windows Terminal version

1.25.3571.0

Windows build number

Windows 11 Version 26H1 (OS Build 28000.1340)

Other Software

No response

Steps to reproduce

Repro Steps:
1.Launch the Window terminal app.
2.Navigate to the 'New Open Tab' and select the 'Settings' menu item.
3.Settings page will open.
4.Now turn on the narrator using 'CTRL+Win+Enter' keys.
4.Now navigate to the 'Open/Close' navigation button and press enter.
5.Observe the issue here.

User Experience:
Screen reader users cannot determine whether the navigation panel is open or closed, leading to confusion and difficulty in navigating the interface. This impacts efficiency and independence.

WCAG Reference Link:
https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

Attachements:
https://microsoftapc-my.sharepoint.com/:u:/g/personal/v-heparihar_microsoft_com/IQDLd9wWKN2AQ5st84Yv_lwwAXMfAiE1AuV8JoNjoRTKxW0?e=pQZpOf

Expected Behavior

The 'Open/Close' navigation button should programmatically expose its state (open or closed) using appropriate ARIA attributes (e.g., aria-expanded="true" or aria-expanded="false") so that assistive technologies announce the state change when the button is activated.

Actual Behavior

When the user activates the 'Open/Close' navigation button, the screen reader remains silent. It does not announce whether the navigation panel is open or closed. The button label is announced only when it receives keyboard focus for the first time.

Originally created by @Saurabh220304 on GitHub (Dec 29, 2025). ### Windows Terminal version 1.25.3571.0 ### Windows build number Windows 11 Version 26H1 (OS Build 28000.1340) ### Other Software _No response_ ### Steps to reproduce **Repro Steps:** 1.Launch the Window terminal app. 2.Navigate to the 'New Open Tab' and select the 'Settings' menu item. 3.Settings page will open. 4.Now turn on the narrator using 'CTRL+Win+Enter' keys. 4.Now navigate to the 'Open/Close' navigation button and press enter. 5.Observe the issue here. **User Experience:** Screen reader users cannot determine whether the navigation panel is open or closed, leading to confusion and difficulty in navigating the interface. This impacts efficiency and independence. **WCAG Reference Link:** https://www.w3.org/WAI/WCAG21/Understanding/name-role-value **Attachements:** https://microsoftapc-my.sharepoint.com/:u:/g/personal/v-heparihar_microsoft_com/IQDLd9wWKN2AQ5st84Yv_lwwAXMfAiE1AuV8JoNjoRTKxW0?e=pQZpOf ### Expected Behavior The 'Open/Close' navigation button should programmatically expose its state (open or closed) using appropriate ARIA attributes (e.g., aria-expanded="true" or aria-expanded="false") so that assistive technologies announce the state change when the button is activated. ### Actual Behavior When the user activates the 'Open/Close' navigation button, the screen reader remains silent. It does not announce whether the navigation panel is open or closed. The button label is announced only when it receives keyboard focus for the first time.
Author
Owner

@carlos-zamora commented on GitHub (Jan 6, 2026):

Surprisingly, in the WinUI 2 Gallery, I hear "Close Navigation, Navigation Landmark" and "Open Navigation, Navigation Landmark". It's different functionality and it's a bit different from what is desired, but I assume it's good enough because the new state is read out, so the user should know that the state changed.

I should still test this on the version of WinUI we're using. I still suspect this is a WinUI issue, but I'll dig deeper.

EDIT: Does not repro on a standalone WinUI 2.8.4 project (the same version we're using in Terminal). Investigating XAML Islands.

@carlos-zamora commented on GitHub (Jan 6, 2026): Surprisingly, in the WinUI 2 Gallery, I hear "Close Navigation, Navigation Landmark" and "Open Navigation, Navigation Landmark". It's different functionality and it's a bit different from what is desired, but I assume it's good enough because the new state is read out, so the user should know that the state changed. I should still test this on the version of WinUI we're using. I still suspect this is a WinUI issue, but I'll dig deeper. EDIT: Does not repro on a standalone WinUI 2.8.4 project (the same version we're using in Terminal). Investigating XAML Islands.
Author
Owner

@carlos-zamora commented on GitHub (Jan 14, 2026):

Ok! I did some investigation and I managed to not get a repro on WinUI 3 and the WinUI 2 Gallery. Problem occurs in XAML Islands apps (confirmed by testing on Scratch.slnx, which is a pretty simple XAML Islands app).

I filed a bug upstream to XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/10958

@carlos-zamora commented on GitHub (Jan 14, 2026): Ok! I did some investigation and I managed to not get a repro on WinUI 3 and the WinUI 2 Gallery. Problem occurs in XAML Islands apps (confirmed by testing on Scratch.slnx, which is a pretty simple XAML Islands app). I filed a bug upstream to XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/10958
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23914