Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Support for accessibiliyActions #13316

Closed
7 tasks done
Tracked by #11901
chiaramooney opened this issue Jun 7, 2024 · 1 comment
Closed
7 tasks done
Tracked by #11901

Add Support for accessibiliyActions #13316

chiaramooney opened this issue Jun 7, 2024 · 1 comment
Assignees
Labels
Area: Accessibility Area: Fabric Support Facebook Fabric enhancement New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric Parity: Fabric vs. Paper RNW Fabric does not look or behave like RNW Paper Workstream: Accessibility Ensure RNW Fabric apps are properly accessible.
Milestone

Comments

@chiaramooney
Copy link
Contributor

chiaramooney commented Jun 7, 2024

Documentation

accessibilityActions Documentation: https://reactnative.dev/docs/accessibility#accessibility-actions

Behavior Explanation

From documentation:
"To support accessibility actions, a component must do two things:

Define the list of actions it supports via the accessibilityActions property.
Implement an onAccessibilityAction function to handle action requests."

For example a developer will define the following control:

<View
      accessible={true}
      accessibilityActions={[
          { name: 'toggle', label: 'toggle' },
          { name: 'invoke', label: 'invoke' },
          { name: 'expand', label: 'expand' },
          { name: 'collapse', label: 'collapseIt' },
      ]}
      onAccessibilityAction={(event: { nativeEvent: { actionName: any; }; }) => {
          switch (event.nativeEvent.actionName) {
              case 'toggle':
                  console.log('toggle action success');
                  break;
              case 'invoke':
                  console.log('invoke action success');
                  break;
              case 'expand':
                  console.log('expand action success');
                  break;
              case 'collapseIt':
                  console.log('collapseIt action success');
                  break;
          }
      }}
/>

They have defined a set of accessibilityActions they expect to occur for this control, and they have defined an onAccessibilityAction function which should be called after one of the defined accessibilityActions takes place.

On the native side, our platform must store the information that this View control wants to know when Toggle, Invoke, Expand, and Collapse UIA events occur. The native code should monitor when a Toggle, Invoke, Expand, or Collapse UIA event is fired and call the onAccessibilityAction event handler the developer defined with the event information.

Implementation Plan

In our native implementation of accessibilityActions we must:

  1. Store the registered accessibilityActions event names (most likely via CompositionDynamicAutomationProvider)
  2. Store a new AccessibilityActionsEventHandler property with a name parameter
  3. When a UIA action occurs, check the registered accessibilityActions names and if there's a match, then fire the AccessibilityActionsEventHandler

Note this prop will not need to be implemented per component. One implementation in the accessibility source will serve all component types. (i.e. per component issues linked below can all be closed at once after prop behavior is implemented)

Past Implementation

Implementation on Paper: #3475
Issue on Paper: #2765

Notes

Implementing accessibilityActions should not implement our native handling of UIA events. For example, toggling a Switch control when a UIA Toggle event is fired should not be handled by this feature work. That is a separate task. See #11903

To Be Clarified

It is unclear in the documentation if specification accessibilityActions and the onAccessibilityAction handler should override default accessibility event behavior. For example, our native code will handle Invoke events for the Button control by calling the controls onPress function. If a developer was to create a Button control and specify the accessibilityActions prop to be { name: 'invoke', label: 'invoke' } and the onAccessibilityAction handler to be

 onAccessibilityAction={(event: { nativeEvent: { actionName: any; }; }) => {
          switch (event.nativeEvent.actionName) {
              case 'invoke':
                  console.log('invoke action success');
                  break;
          }
      }}

should the onAccessibilityAction call replace the default handling of the Invoke event within our native code or be in addition to?

Completed

Tasks

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) label Jun 7, 2024
@chiaramooney chiaramooney changed the title Add support for accessibiliyActions Add Support for accessibiliyActions Jun 7, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric label Jun 7, 2024
@chrisglein chrisglein added the Parity: Fabric vs. Paper RNW Fabric does not look or behave like RNW Paper label Jun 10, 2024
@chrisglein
Copy link
Member

@chiaramooney Can you add the right interlinking with these issues: https://github.com/microsoft/react-native-windows/issues?q=is%3Aopen+accessibilityActions

@chrisglein chrisglein added enhancement and removed Needs: Triage 🔍 New issue that needs to be reviewed by the issue management team (label applied by bot) labels Jun 10, 2024
@chrisglein chrisglein added this to the Backlog milestone Jun 10, 2024
@chiaramooney chiaramooney self-assigned this Sep 12, 2024
@chiaramooney chiaramooney modified the milestones: Backlog, Next Sep 12, 2024
@chiaramooney chiaramooney added Workstream: Component Parity Close the parity gap between RNW and RN for core RN components and their supporting APIs. Workstream: Accessibility Ensure RNW Fabric apps are properly accessible. and removed Workstream: Component Parity Close the parity gap between RNW and RN for core RN components and their supporting APIs. labels Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Accessibility Area: Fabric Support Facebook Fabric enhancement New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric Parity: Fabric vs. Paper RNW Fabric does not look or behave like RNW Paper Workstream: Accessibility Ensure RNW Fabric apps are properly accessible.
Projects
Status: Done
Development

No branches or pull requests

2 participants