Kbridge/main/update for winappsdk winui accessibility (#6552)

* Freshness update: accessibility folder for WinUI/Windows App SDK

Update all 15 articles in hub/apps/design/accessibility/:

- Update ms.date to 03/17/2026 (14 files)
- Add windows 11, winui, winapp sdk to keywords (all files)
- Add WinUI 3 / Windows App SDK applicability notes (checklist, custom-automation-peers)
- Add Microsoft.UI.Xaml.Automation namespace reference (overview)
- Replace UWP-specific language with platform-neutral wording (overview, accessible-text-requirements, developing-inclusive-windows-apps, system-button-narration)
- Mark archived MSDN Code Gallery sample links as (archived) (overview, accessible-text-requirements, basic-accessibility-information, high-contrast-themes)

Co-authored-by: Copilot <[email protected]>

* more ai suggestions and human refinements

* more ai suggestions and human refinements

* more ai suggestions and human refinements

* more ai suggestions and human refinements

* more ai suggestions and human refinements

* more ai suggestions and human refinements

* update for winappsdk/winui with help from Claude Opus 4.6 and GPT-5.3-Codex

* update for winappsdk/winui with help from Claude Opus 4.6 and GPT-5.3-Codex

* update for winappsdk/winui with help from Claude Opus 4.6 and GPT-5.3-Codex

* build warnings

---------

Co-authored-by: Copilot <[email protected]>

Author: Karl-Bridge-Microsoft

hub/apps/design/accessibility/accessibility-checklist.md

@@ -4,70 +4,78 @@ ms.assetid: BB8399E2-7013-4F77-AF2C-C1A0E5412856
 title: Accessibility checklist
 label: Accessibility checklist
 template: detail.hbs
-ms.date: 09/24/2020
+ms.date: 03/17/2026
 ms.topic: checklist
-keywords: windows 10, uwp
+keywords: windows 11, winui, winappsdk, windows app sdk
 ms.localizationpriority: medium
 ---
+
 # Accessibility checklist
 
-Provides a checklist to help you ensure that your Windows app is accessible .
+This topic provides recommendations for making your Windows app accessible and discoverable to customers looking for accessible apps in the Microsoft Store.
+
+> [!NOTE]
+> This guidance is written for WinUI 3 / Windows App SDK apps. If you are maintaining a legacy UWP app, equivalent APIs are available in the `Windows.UI.Xaml` namespaces.
 
-Here we provide a checklist you can use to ensure that your app is accessible.
+Use the following recommendations during design, implementation, and testing. Together, they cover core accessibility expectations for keyboard use, readable content, assistive technology compatibility, and Microsoft Store discoverability.
 
 1. Set the accessible name (required) and description (optional) for content and interactive UI elements in your app.
 
-    An accessible name is a short, descriptive text string that a screen reader uses to announce a UI element. Some UI elements such as [**TextBlock**](/uwp/api/Windows.UI.Xaml.Controls.TextBlock) and [**TextBox**](/uwp/api/Windows.UI.Xaml.Controls.TextBox) promote their text content as the default accessible name; see [Basic accessibility information](basic-accessibility-information.md#name_from_inner_text).
+    An accessible name is a short, descriptive text string that a screen reader uses to announce a UI element. Some UI elements such as [TextBlock](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.textblock) and [TextBox](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.textbox) promote their text content as the default accessible name; see [Name from inner text](basic-accessibility-information.md#name-from-inner-text).
 
-    You should set the accessible name explicitly for images or other controls that do not promote inner text content as an implicit accessible name. You should use labels for form elements so that the label text can be used as a [**LabeledBy**](/previous-versions/windows/silverlight/dotnet-windows-silverlight/ms591292(v=vs.95)) target in the Microsoft UI Automation model for correlating labels and inputs. If you want to provide more UI guidance for users than is typically included in the accessible name, accessible descriptions and tooltips help users understand the UI.
+    You should set the accessible name explicitly for images or other controls that do not promote inner text content as an implicit accessible name. You should use labels for form elements so that the label text can be used as a [LabeledBy](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.automation.automationproperties.labeledby) target in the Microsoft UI Automation model for correlating labels and inputs. If you want to provide more UI guidance for users than is typically included in the accessible name, accessible descriptions and tooltips help users understand the UI.
 
-    For more info, see [Accessible name](basic-accessibility-information.md#accessible_name) and [Accessible description](basic-accessibility-information.md).
+    For more info, see [Accessible name](basic-accessibility-information.md#accessible-name) and [Accessible description](basic-accessibility-information.md).
 
 2. Implement keyboard accessibility:
 
-    * Test the default tab index order for a UI. Adjust the tab index order if necessary, which may require enabling or disabling certain controls, or changing the default values of [**TabIndex**](/uwp/api/windows.ui.xaml.controls.control.tabindex) on some of the UI elements.
-    * Use controls that support arrow-key navigation for composite elements. For default controls, the arrow-key navigation is typically already implemented.
-    * Use controls that support keyboard activation. For default controls, particularly those that support the UI Automation [**Invoke**](/uwp/api/Windows.UI.Xaml.Automation.Provider.IInvokeProvider) pattern, keyboard activation is typically available; check the documentation for that control.
-    * Set access keys or implement accelerator keys for specific parts of the UI that support interaction.
-    * For any custom controls that you use in your UI, verify that you have implemented these controls with correct [**AutomationPeer**](/uwp/api/Windows.UI.Xaml.Automation.Peers.AutomationPeer) support for activation, and defined overrides for key handling as needed to support activation, traversal and access or accelerator keys.
+    - Test the default tab index order for a UI. Adjust the tab index order if necessary, which may require enabling or disabling certain controls, or changing the default values of [TabIndex](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.uielement.tabindex) on some of the UI elements.
+    - Use controls that support arrow-key navigation for composite elements. For default controls, the arrow-key navigation is typically already implemented.
+    - Use controls that support keyboard activation. For default controls, particularly those that support the UI Automation [Invoke](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.automation.provider.iinvokeprovider.invoke) pattern, keyboard activation is typically available; check the documentation for that control.
+    - Set access keys or implement accelerator keys for specific parts of the UI that support interaction.
+    - For any custom controls that you use in your UI, verify that you have implemented these controls with correct [AutomationPeer](/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.automation.peers.automationpeer) support for activation, and defined overrides for key handling as needed to support activation, traversal and access or accelerator keys.
 
     For more info, see [Keyboard interactions](../input/keyboard-interactions.md).
 
 3. Ensure text is a readable size
 
-    * Windows includes various accessibility tools and settings that users can take advantage of and adjust to their own needs and preferences for reading text. These include:
-        * The Magnifier tool, which enlarges a selected area of the UI. You should ensure the layout of text in your app doesn't make it difficult to use Magnifier for reading.
-        * Global scale and resolution settings in **Settings->System->Display->Scale and layout**. Exactly which sizing options are available can vary as this depends on the capabilities of the display device.
-        * Text size settings in **Settings->Ease of access->Display**. Adjust the **Make text bigger** setting to specify only the size of text in supporting controls across all applications and screens (all UWP text controls support the text scaling experience without any customization or templating).
+    - Windows includes various accessibility tools and settings that users can take advantage of and adjust to their own needs and preferences for reading text. These include:
+        - The Magnifier tool, which enlarges a selected area of the UI. You should ensure the layout of text in your app doesn't make it difficult to use Magnifier for reading.
+        - Global scale and resolution settings in **Settings->System->Display->Scale and layout**. Exactly which sizing options are available can vary as this depends on the capabilities of the display device.
+        - Text size settings in **Settings->Ease of access->Display**. Adjust the **Make text bigger*- setting to specify only the size of text in supporting controls across all applications and screens (XAML text controls support text scaling without additional customization in standard scenarios).
         > [!NOTE]
-        > The **Make everything bigger** setting lets a user specify their preferred size for text and apps in general on their primary screen only.
+        > The **Make everything bigger*- setting lets a user specify their preferred size for text and apps in general on their primary screen only.
 
 4. Visually verify your UI to ensure that the text contrast is adequate, elements render correctly in the high-contrast themes, and colors are used correctly.
 
-    * Use a color analyzer tool to verify that the visual text contrast ratio is at least 4.5:1.
-    * Switch to a high contrast theme and verify that the UI for your app is readable and usable.
-    * Ensure that your UI doesn’t use color as the only way to convey information.
+    - Use a color analyzer tool to verify that the visual text contrast ratio is at least 4.5:1.
+    - Switch to a high contrast theme and verify that the UI for your app is readable and usable.
+    - Ensure that your UI doesn't use color as the only way to convey information.
 
     For more info, see [High-contrast themes](high-contrast-themes.md) and [Accessible text requirements](accessible-text-requirements.md).
 
 5. Run accessibility tools, address reported issues, and verify the screen reading experience.
 
-    Use tools such as [**Inspect**](/windows/desktop/WinAuto/inspect-objects) to verify programmatic access, run diagnostic tools such as [**AccChecker**](/windows/desktop/WinAuto/ui-accessibility-checker) to discover common errors, and verify the screen reading experience with Narrator.
+    Use tools such as [Inspect](/windows/desktop/WinAuto/inspect-objects) to verify programmatic access, run diagnostic tools such as [AccChecker](/windows/desktop/WinAuto/ui-accessibility-checker) to discover common errors, and verify the screen reading experience with Narrator.
 
     For more info, see [Accessibility testing](accessibility-testing.md).
 
-6. Make sure your app manifest settings follow accessibility guidelines.
+6. Add automated accessibility regression checks to your CI pipeline.
+
+    Run automated checks for critical screens and flows in pull requests and continuous integration. Configure your pipeline to block merges or releases when critical accessibility regressions are detected.
+
+7. Make sure your app manifest settings follow accessibility guidelines, see [Security Considerations for Assistive Technologies](/windows/win32/winauto/uiauto-securityoverview).
 
-7. Declare your app as accessible in the Microsoft Store.
+8. Declare your app as accessible in the Microsoft Store.
 
-    If you implemented the baseline accessibility support, declaring your app as accessible in the Microsoft Store can help reach more customers and get some additional good ratings.
+    If you implemented the baseline accessibility support, declaring your app as accessible in the Microsoft Store can help reach more customers and potentially improve ratings.
 
     For more info, see [Accessibility in the Store](accessibility-in-the-store.md).
 
 ## Related topics  
 
-* [Accessible text requirements](accessible-text-requirements.md)
-* [Text scaling](../input/text-scaling.md)
-* [Accessibility](accessibility.md)
-* [Design for accessibility](./accessibility-overview.md)
-* [Practices to avoid](practices-to-avoid.md)
+- [Accessible text requirements](accessible-text-requirements.md)
+- [Text scaling](../input/text-scaling.md)
+- [Accessibility](accessibility.md)
+- [Design for accessibility](./accessibility-overview.md)
+- [Practices to avoid](practices-to-avoid.md)

hub/apps/design/accessibility/accessibility-in-the-store.md

@@ -4,42 +4,40 @@ ms.assetid: 59FA3B87-75A6-4B30-BA7C-A0E769D68050
 title: Accessibility in the Store
 label: Accessibility in the Store
 template: detail.hbs
-ms.date: 09/24/2020
+ms.date: 03/17/2026
 ms.topic: article
-keywords: windows 10, uwp
+keywords: windows 11, winui, winappsdk, windows app sdk
 ms.localizationpriority: medium
 ---
-# Accessibility in the Store  
 
+# Accessibility in the Store
 
+This topic describes the requirements for declaring your Windows app as accessible in the Microsoft Store.
 
-Describes the requirements for declaring your Windows app as accessible in the Microsoft Store.
-
-While submitting your app to the Microsoft Store for certification, you can declare your app as accessible. Declaring your app as accessible makes it easier to discover for users who are interested in accessible apps, such as users who have visual impairments. Users discover accessible apps by using the **Accessible** filter while searching the Microsoft Store. Declaring your app as accessible also adds the **Accessible** tag to your app’s description.
+While submitting your app to the Microsoft Store for certification, you can declare your app as accessible. Declaring your app as accessible makes it easier to discover for users who are interested in accessible apps, such as users who have visual impairments. Users discover accessible apps by using the **Accessible** filter while searching the Microsoft Store. Declaring your app as accessible also adds the **Accessible** tag to your app's description.
 
 By declaring your app as accessible, you state that it has the [basic accessibility information](basic-accessibility-information.md) that users need for primary scenarios using one or more of the following:
 
-* The keyboard.
-* A high contrast theme.
-* A variable dots per inch (dpi) setting.
-* Common assistive technology such as the Windows accessibility features, including Narrator, Magnifier, and On-Screen Keyboard.
+- The keyboard.
+- A high contrast theme.
+- A variable dots per inch (dpi) setting.
+- Common assistive technology such as the Windows accessibility features, including Narrator, Magnifier, and On-Screen Keyboard.
 
 You should declare your app as accessible if you built and tested it for accessibility. This means that you did the following:
 
-* Set all the relevant accessibility information for UI elements, including name, role, value, and so on.
-* Implemented full keyboard accessibility, enabling the user to:
-    * Accomplish primary app scenarios by using only the keyboard.
-    * Tab among UI elements in a logical order.
-    * Navigate among UI elements within a control by using the arrow keys.
-    * Use keyboard shortcuts to reach primary app functionality.
-    * Use Narrator touch gestures for Tab and arrow equivalency for devices with no keyboard.
-* Ensured that your app UI is visually accessible: has a minimum text contrast ratio of 4.5:1, does not rely on color alone to convey information, and so on.
-* Used accessibility testing tools such as [**Inspect**](/windows/desktop/WinAuto/inspect-objects) and [**UIAVerify**](/windows/desktop/WinAuto/ui-automation-verify) to verify your accessibility implementation, and resolved all priority 1 errors reported by such tools.
-* Verified your app’s primary scenarios from end to end by using Narrator, Magnifier, On-Screen Keyboard, a high contrast theme, and adjusted dpi settings.
+- Set all the relevant accessibility information for UI elements, including name, role, value, and so on.
+- Implemented full keyboard accessibility, enabling the user to:
+  - Accomplish primary app scenarios by using only the keyboard.
+  - Tab among UI elements in a logical order.
+  - Navigate among UI elements within a control by using the arrow keys.
+  - Use keyboard shortcuts to reach primary app functionality.
+  - Use Narrator touch gestures for Tab and arrow equivalency for devices with no keyboard.
+- Ensured that your app UI is visually accessible: has a minimum text contrast ratio of 4.5:1, does not rely on color alone to convey information, and so on.
+- Used accessibility testing tools such as [**Inspect**](/windows/desktop/WinAuto/inspect-objects) and [**UIAVerify**](/windows/desktop/WinAuto/ui-automation-verify) to verify your accessibility implementation, and resolved all priority 1 errors reported by such tools.
+- Verified your app's primary scenarios from end to end by using Narrator, Magnifier, On-Screen Keyboard, a high contrast theme, and adjusted dpi settings.
 
-See the [Accessibility checklist](accessibility-checklist.md) for a review of these procedures and links to resources that will help you accomplish them.
+See the [Accessibility checklist](accessibility-checklist.md) for more detail on these procedures and links to resources.
 
-<span id="related_topics"></span>
+## Related topics
 
-## Related topics    
-* [Accessibility](accessibility.md)
+- [Accessibility](accessibility.md)