Improve screen reader, keyboard, and High Contrast accessibility

[jbgrimsby]

Summary

This change corrects screen-reader and keyboard interaction in the Start Menu, Classic Explorer, and Classic IE settings dialogs while preserving the existing visual workflow.

It also makes the new-application indicator respect the Windows High Contrast palette, addressing the color conflict described in #2054.

What changed

• Expose settings-tree checkboxes and radio buttons with their correct MSAA roles and checked states.
• Include the selected choice in a parent setting's accessible name.
• Announce modified only when a setting differs from its default, matching the existing bold visual treatment.
• Give settings trees, edit controls, the search field, pages, and the tab strip meaningful accessible names.
• Restore standard tree navigation: Left returns to a parent or collapses it; Right expands a parent or enters its first child.
• Correct dialog tab order, Ctrl+Tab wrapping, and focus behavior when switching between basic and advanced settings.
• Keep focus on Show all settings when it is toggled and omit a one-page tab strip from keyboard navigation.
• Preserve the visible bold-setting guidance while preventing screen readers from announcing irrelevant visual-only instructions.
• Expose Start Menu folder expanded/collapsed states and concise menu names/actions.
• Use system highlight and highlight-text colors for new-item variants while High Contrast is active. Normal themed rendering is unchanged.
• Initialize COM in the Classic Explorer and Classic IE settings launchers so accessibility annotations can be applied reliably.

Root cause

The settings interface visually represented checkbox, radio-button, selected, default, and modified states through custom tree images and bold text, but exposed the items to assistive technology as generic outline items. Some keyboard behavior was also implemented differently from standard Windows tree and property-page interaction.

The new-application indicator could additionally use a skin foreground color as a background under High Contrast, producing unreadable adjacent items.

Validation

• Built the x64 Start Menu target with Visual Studio 2022 Build Tools.
• Built the Classic Explorer settings launcher.
• Built the x64 Classic IE settings launcher.
• Installed and tested the patched build with NVDA 2026.1.1.
• Captured before/after Microsoft Active Accessibility data for Start Menu, Classic Explorer, and Classic IE settings.
• Verified checkbox role 44, radio-button role 45, checked state, selected-choice names, modified state, control names, and tab order.
• Verified all four standard Left/Right Arrow tree-navigation cases.
• Repeated the dialog scenario from NVDA screen reader freezes on dialogs launched from Open-Shell Start menu after recent Windows update #2476 with NVDA debug logging and add-ons disabled. The warning dialog and focused Cancel button were announced promptly; no watchdog freeze or CallCancelled exception occurred during that run. This single run is positive evidence but does not claim that the separate intermittent report is conclusively resolved.

User impact

Screen-reader users can determine which settings are selected or modified, navigate the trees using standard Windows conventions, and move through the dialogs in a predictable order. Sighted users retain the existing layout, bold modified-setting indication, and normal theme rendering.

[jbgrimsby]

Hi, just following up on this PR now that it has been ready for review for a few weeks. It corrects long-standing screen-reader and keyboard accessibility problems in the Open-Shell settings dialogs and includes tested changes for NVDA, standard Windows tree navigation, control roles and states, focus handling, and High Contrast support.

I would appreciate a review when someone has time. I’m happy to answer questions, provide the inspection evidence, or revise and split the changes if that would make review easier.

[ge0rdi]

Hello and thank you for your effort.

I'm sorry, I didn't have much time to look at these changes :(
It is rather big amount of changes (and I guess they look fine), so I guess I will just do some testing and merge this.

Please, try to install build from this PR and double-check everything works for you as well.

[jbgrimsby]

Hello,

Thank you for taking the time to review and test these changes. I did not intend to overwhelm you with such a large pull request. My goal was to address the long-standing screen-reader and keyboard usability problems while preserving the existing experience for sighted users.

I have installed and tested the build from the pull-request commit, and everything is working correctly for me. My before-and-after accessibility inspection also confirms that the changes expose the correct control roles, names, states, and keyboard behavior to screen readers.

I sincerely appreciate your willingness to spend the time and effort reviewing this work. Please let me know if you have any questions or would like any additional testing information.

Best regards,
Jim

[ge0rdi]

I can see several issues with the build from this PR (testing in Win11 Sandbox):

• When in Settings -> Start menu style tab, I click on Show all settings checkbox, the page is not refreshed
• Focused on tab headers in settings, Ctrl+Tab switches to next tab, but the content of tab is not refreshed (note that changing tabs using arrow keys works properly)
• Searching for settings won't refresh page content (it gets blank)

In general, it seems there is an issue with content refresh.

[jbgrimsby]

Thank you for catching this, and apologies for the regression. In short, I fixed the dialog for nonvisual users and accidentally broke its refresh for visual users—oops.\n\nThe cause was the accessibility tab-order change also modifying the sibling window order. That could place the active settings page behind the tab control, leaving the page blank or apparently stale even though its accessible objects were still present.\n\nI removed that runtime window reordering and now handle keyboard traversal separately, leaving the page's drawing order intact. I reproduced all three reported cases and visually verified the corrected installed build in the Start Menu, Classic Explorer, and Classic IE settings dialogs:\n\n- Show all settings refreshes correctly in both directions.\n- Ctrl+Tab changes tabs and displays the new page contents.\n- Search displays the matching settings instead of a blank page.\n\nThe correction is in commit e36056c. Thank you again for the careful review.

[ge0rdi]

@jbgrimsby
Thank you.
Now it seems to work properly.
And I can confirm that keyboard navigation in settings now work much better than before.