Skip to content

Accessibility

Chiara Mooney edited this page Mar 11, 2025 · 6 revisions

This Wiki page holds the documentation for the Accessibility feature area for React Native for Windows. This document focuses on the new Fabric architecture.

Tracking Items

Canonical GitHub issue for Accessibility support on Fabric: #11898 Accessibility Workstream: https://github.com/microsoft/react-native-windows/issues?q=state%3Aopen%20label%3A%22Workstream%3A%20Accessibility%22

Relevant Directories/Files

Most of our accessibility implementation on the new architecture is housed withing CompositionDynamicAutomationProvider.h/cpp.

Additional helper methods can be found within UiaHelpers.h/cpp.

If accessibility work needs additional helper methods that must be implemented on a per component basis or if a method requires information from a component that is not available through its original public API surface, additional methods can be added to *ComponentView.h/cpp files. For example, the DefaultControlType() method.

Accessibility Architecture

On Paper (old architecture) we relied on WinUI for supporting native Windows controls. These WinUI controls already had built-in accessibility support, so React Native didn't need to do much additional accessibility work to ensure the platform's controls were accessibility compliant. On Fabric, we are now building controls from scratch using Windows Composition. As a result, we now need to add accessibility support for the new native controls we have created.

To implement accessibility support for a particular control the control must support a few things:

  1. The control should implement the IRawElementProviderFragment interface which contains methods for navigation, bounding rectangles, and focus.
  2. The control should implement the IRawElementProviderSimple2 interface which contains methods for property values and provider information (more explanation on providers below).
  3. The control should implement the relevant provider interfaces given the control's functionality. For example, clickable controls should implement the IInvokeProvider or scrollable controls should implement the IScrollProvider. For more information on providers and under what conditions to implement them visit the following resources:

Most of the implementation of the above interfaces can be found within CompositionDynamicAutomationProvider.h/cpp. ITextProvider and ITextRangeProvider are implemented in separate files, CompositionTextProvider.h/cpp and CompositionTextRangeProvider.h/cpp respectively. ITextProvider was implemented in a separate file because some of its APIs are identical to other provider interfaces; the interface implementation was separated to avoid conflicts. ITextRangeProvider was implemented in a separate file because this provider is a child provider of ITextProvider; its instantiation is different from other providers like ITextProvider or IScrollProvider.

Any action method from an accessibility provider (i.e. a method which does have a get_* name) should include a call to DispatchAccessibilityAction(m_view, "methodName"). This call is used for the accessibilityAction prop. The implementation of the method can be found here.

Every *ComponentView has an instance of CompositionDynamicAutomationProvider. This instance is created during calls to the EnsureUiaProvider method.

Testing

We currently have automated validation for most of our accessibility support on Fabric. We use snapshots tests to catch accessibility regressions in the platform. For more information on how snapshot tests work, visit the E2E Testing (Fabric) Wiki page.

Snapshot information for accessibility is dumped within the DumpUIATreeHelper method.

Clone this wiki locally