-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add support for the accessibilityState prop on Fabric #13327
Copy link
Copy link
Closed
Labels
Area: AccessibilityArea: FabricSupport Facebook FabricSupport Facebook FabricNew ArchitectureBroad category for issues that apply to the RN "new" architecture of Turbo Modules + FabricBroad category for issues that apply to the RN "new" architecture of Turbo Modules + FabricWorkstream: AccessibilityEnsure RNW Fabric apps are properly accessible.Ensure RNW Fabric apps are properly accessible.enhancement
Milestone
Metadata
Metadata
Assignees
Labels
Area: AccessibilityArea: FabricSupport Facebook FabricSupport Facebook FabricNew ArchitectureBroad category for issues that apply to the RN "new" architecture of Turbo Modules + FabricBroad category for issues that apply to the RN "new" architecture of Turbo Modules + FabricWorkstream: AccessibilityEnsure RNW Fabric apps are properly accessible.Ensure RNW Fabric apps are properly accessible.enhancement
Type
Fields
Give feedbackNo fields configured for issues without a type.
Projects
StatusShow more project fields
Done
Documentation
accessibilityState Documentation: https://reactnative.dev/docs/accessibility#accessibilitystate
Behavior Explanation
From the documentation
"Describes the current state of a component to the assistive technology user.
accessibilityState is an object. It contains the following fields:
To use, set the accessibilityState to an object with a specific definition."
For example a developer will define the following control:
This state information should be passed into the native accessibility code which should call upon the correct UIA APIs (i.e. ISelectionProvider and IsEnabled property) to set the component's UIA data to be selected and disabled.
Note some of this implementation will need to change based on the component type. Not all controls have UIA providers to support all accessibilityStates
Implementation Plan
In our native implementation of accessibilityState we must:
Note: Implementation should also cover case where control has gone from a specified state to a no specification.
Past Implementation
#11792
#4617
#4624
#9871
#11756
Notes
To Be Clarified
It is unclear in documentation what the behavior should be if a control is set to 'true' for an accessibilityState it shouldn't support. For example, if a plain view was set to
{checked: true}, should we add the IToggleProvider to the View and set the toggle state to true? Or if the control does not support checked behavior, should we ignore the specified state?