React-Native Accessibility Focus Order Issues

[KishoreKumar186]

Description

We are performing Accessibility testing in our React native app in iOS using Xcode Accessibility Inspector. We found few issues in focus order during the testing.

The components are read from left to right and top to bottom by default. We are not able to change the focus order as the components are not read in meaningful order. It could be better if there is a prop to configure the focus order by default and also, it should work across multiple components shown in the same screen.
In the video, it should traverse Text 1, Text 2, Text 3, etc instead of the current flow.

Focus is not staying on the triggered elements when a Modal/Keyboard/Drodown is closed. Instead, it is moving to the top of the screen. Ideally, the focus should stay and continue from the same element.
In the video, it should return to 'Button' instead of reading from the top.

Steps to reproduce

Open Xcode accessibility inspector and try to inspect any RN iOS app.
The components are traversed left to right and top to bottom.
Open a modal using a button. Once the modal is closed, the focus is not returning to the triggered button. But it is reading from the first element of the screen.

React Native Version

0.77.1

Affected Platforms

Runtime - iOS

Output of npx @react-native-community/cli info

System:
  OS: macOS 15.3.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 130.42 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 20.9.0
    path: ~/.nvm/versions/node/v20.9.0/bin/node
  Yarn: Not Found
  npm:
    version: 10.9.0
    path: ~/.nvm/versions/node/v20.9.0/bin/npm
  Watchman:
    version: 2024.05.06.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK:
    Android NDK: 22.1.7171670
IDEs:
  Android Studio: Not Found
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.11
    path: /opt/homebrew/opt/openjdk@17/bin/javac
  Ruby:
    version: 2.7.6
    path: /Users/kikumarm/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.77.1
    wanted: 0.77.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

N/A

Reproducer

https://github.com/KishoreKumar186/rn-awesome-project/

Screenshots and Videos

React.native.focus.order.issue.mp4

[JoaoMosmann]

I'm facing the same problem. On iOS, once the Modal is closed, the accessibility focus is not returned to the last element focused before the modal was opened. It works fine on Android.

As a workaround, I've used the followed code to force the accessibility focus to return to the button that triggers the modal opening.

Once the Modal is closed, I run:

import { AccessibilityInfo, findNodeHandle } from "react-native";
// ...
const reactTag = findNodeHandle(pressableRef.current);
if (reactTag) {
  AccessibilityInfo.setAccessibilityFocus(reactTag);
}

[DylanWard14]

+1
Honestly, I'm surprised that this is an issue.
Accessibility is super important for the application that I am working on and we could very likely not use React Native because of this

[joevilches]

Hello! I am working on a prop for screen reader focus ordering called experimental_accessibilityOrder. The prop exists but the effects are gated behind a feature flag, as it is not stable at the moment (iOS had some crashes, Android impl is changing to fix edge cases). I hope to get this out in the next few months, albeit still marked as experimental. Just came across this issue and wanted to let you know folks are working on this capability

[ArturKalach]

Hello everyone,

I believe this is a well-known issue, and you can check these references for more details: #30888, #28299, and possibly others in different places.

I think experimental_accessibilityOrder should resolve all these problems, but it seems like it will need some time to be fully ready.

In the meantime, you could try my package: react-native-a11y-order.

Here’s a potential fix that could work:

import { A11y } from 'react-native-a11y-order';

// ...

export default function App() {
  return (
    <ScrollView
      style={styles.slider}
      contentContainerStyle={styles.sliderContainer}
      horizontal
    >
      <A11y.Group style={styles.slide}>
        <View>
          <Text>Text: 1</Text>
        </View>
        <View>
          <Text>Text: 2</Text>
        </View>
       <View>
          <Text>Text: 3</Text>
        </View>
      </A11y.Group>
      <A11y.Group style={styles.slide}>
        <View>
          <Text>Text: 4</Text>
        </View>
        <View>
          <Text>Text: 5</Text>
        </View>
       <View>
          <Text>Text: 6</Text>
        </View>
      </A11y.Group>
    </ScrollView>
  );

Additionally, you can check out the features like <A11y.Order> and <A11y.Index index={1}> that the package provides.

Regards
Artur Kalach

[joevilches]

Hi y'all its me again. experimental_accessibilityOrder is ready for OSS feedback!

The documentation can be found here: https://reactnative.dev/docs/view#experimental_accessibilityorder

This is an experimental API, meaning its not enabled in React Native by default (even though the types are exposed). You need to enable it by following the instructions in this page: https://reactnative.dev/docs/next/releases/release-levels. Note that this is not production ready (but closer than it was in my previous comment), as we are ensuring it is stable and the API design makes sense. So you should not commit these changes, rather just test them locally and provide feedback on any issues you see. Any feedback you provide should help accelerate our confidence here so we can get this in prod as soon as can! cc @KishoreKumar186 @DylanWard14 @JoaoMosmann

[Bharat-1306]

Hey everyone, thanks for all the suggestions and updates so far!

Just wanted to give a quick update on our end. We've tried out all the suggested methods and workarounds in this thread, but we're still running into a couple of focus management issues when things get closed:

When a modal is closed, the focus isn't moving to the first interactive element or returning correctly.

Similarly, when the keyboard is dismissed or a dropdown is closed, the focus isn't staying on the triggered element. Instead, it resets and jumps all the way back to the top of the page.

Has anyone had any luck fully resolving these specific closing behaviours, or is there another patch in the works that might address this?

Any help is super appreciated!