Accessibility focus order in React Native

[louy]

Introduction

I know the accessibility focus order of components have been mentioned a few times but I couldn't really find anything helpful, so I thought I'd start a new discussion about it here.

facebook/react-native#13152
facebook/react-native#24239

The Core of It

On the web, screen readers determine the flow of which things are read by looking at the DOM tree and going from top the bottom, and this is the way accessibility is managed in React DOM.

However, on the native side (and more specifically on iOS) this doesn't seem to be the case.

I'm not really quite sure how iOS decides which views are read first, but I suspect it has to do with the timing and order in which these views were added to the screen.

iOS exposes some APIs to allow developers to control this order, but React Native doesn't seem to expose that to the Javascript side

Discussion points

Have anyone here had this issue before? What was your solution for it? Is this something that should live in a package (and are there any packages that already do that), or is it something that can/should be done in react-native?

[louy]

Actually I've just understood what iOS does thanks to this great article from Reveal App.

In short, iOS looks at how the views are laid out on the screen and reads them left to right, top to bottom.

There are two ways to change this behaviour:

• Grouping subviews of a particular view together, so that iOS would read all the subviews that group before moving on to the next view outside the group. This is achieved using the method shouldGroupAccessibilityChildren, which is a BOOL.
• Specifying an explicit order for subviews, which is done using the accessibilityFields property on UIView, which is an NSArray

I've created a custom view that allows control of both these attributes (the latter using React refs), but I feel like this might be something that makes sense to have in RN core. Wdyt?

[mjstelly]

Update for anyone else looking for a solution. The shouldGroupAccessibilityChildren property no longer exists in the RN api.

[zoharIOS]

Can you share your solution please ?

[louy]

This is what I have

https://gist.github.com/louy/6b66c45ae47bb4e3bac5a104dd0649ff

I think it should be built into RN core tbh, but this works well for now

[paolomaffei]

@louy thank you very much for this.

I'm wondering if it might be possible for you to publish a gist with an explicit BDS/GPL licence with it?
(something like this: https://opensource.org/licenses/BSD-3-Clause)

[silverchen]

@louy Do you already have a PR on react-native core for this?

[louy]

@louy Do you already have a PR on react-native core for this?

Nope just the snippet I shared above

[AdamGerthel]

I'd love to see support for shouldGroupAccessibilityChildren. I'm having trouble with two sibling (visually) views. The layout makes sense for someone with full vision, but not at all for a screenreader. It's basically two fieldsets placed next to each other. See below (I'm using the default right-swipe to navigate):

Ideally I'd like to be able to make the screenreader understand that it should traverse the first fieldset before moving to the second, i.e.

"Stats, question mark, Slot, Head..." etc. rather than "Stats, question mark, When equipped, question mark"

[VNDRN]

@AdamGerthel did you find a solution to your problem? Facing the same issue here

[louy]

You can use this snippet as a temporary solution until it's built into RN

https://gist.github.com/louy/6b66c45ae47bb4e3bac5a104dd0649ff

When you wrap your views in a <AccessibilityWrapper>, the screen reader will treat them as a group and read them in order

[VNDRN]

thanks @louy , I'm fairly new to this but do I just copy the .tsx file into my project and use it like so? Or do I have to do something in the iOS folder as well?

[louy]

Yes add the tsx files, but also make sure to drag the iOS files into Xcode (not just to the iOS folder, you have to drag them into the project tree in Xcode UI)

[VNDRN]

Thanks @louy ! Your solution solved my problem!

[lmccormick3]

Thanks so much for creating this, @louy. Does anyone know if there is any movement on RN accessibility enhancements and focus order control? Given that so many of us are having to hack together multiple workarounds, a tabIndex-type option or more accessibility options and control should definitely be prioritized.

[jsamr]

@amarlette You might want to take a look at this! Focus order support would be a huge plus for RN.

[mjstelly]

I have an iOS VO bug (works in android TB) in my current app that is of critical importance to us to resolve because it affects the Section 508 status of the app. I tried shouldGroupAccessibilityChildren, but that View property doesn't exist in RN 0.69. Attached is a brief clip demonstrating the errant behavior.

The VirtualizedList component has child components rendered horizontally. The behavior should be "swipe right, read all child component text. Swipe right again, advance to next component and read all the text". As noted in the short clip, VO "reads the first row, swipe right, advances to next component and reads first row." It skips second, third and fourth rows of text completely. I would appreciate a reply if anyone knows how to resolve this bug.

ios.incorrect.voiceover.read.order.mov

I just now confirmed that the bug exists in the VirtualizedList component. If I set its property horizontal={false}, then VoiceOver steps through the child component as intended.

ios.voiceover.vertical.ClinicListBottom.mp4

[mjstelly]

I confirmed this bug with a test app. When the horizontal prop is true, VO reads left-to-right, then top-down, which is not the expected behavior.

VirtualizedList.horizontal.prop.bug.mov

[fwielstra]

We're running into this issue with an app using bottom tab navigation; when iterating over elements, instead of going all the way down the current page, the a11y item will move on to the first tab, then a button that is currently hidden from view, then continue with the tab bar; being able to group all elements on the current page and the tab bar would resolve this.

The following demonstrates how iterating over accessible elements currently works:

Unfortunately, the accessibility inspector doesn't seem to handle native tab navigation like the Photos app very well, so I'm not sure how it's supposed to work.

[ArturKalach]

Maybe it is not you are looking for, but you can declare focus order for iOS and Android.
Had sort of similar issue, and wrote lib to share https://www.npmjs.com/package/react-native-a11y

[unyo]

Thank you @louy for the code for RNAccessibilityWrapper, I was reading the article you posted here to see if I could figure out a way to do this without a native module, and I think it might be able accomplish accessibility "grouping" by using a <ScrollView> instead of a <View>:

https://snack.expo.dev/@cmoniz/accessibilitywrapper-without-the-native-module

[matboud]

I've encountered similar challenges with accessibility in React Native, exactly on iOS. Since it has specific APIs for accessibility focus order, maybe this way could help.. the approach consist to create a native module in React Native that bridges these iOS APIs to the Typescript side. This allows more control over the focus order. To my knowledge, there isn't a pre-existing package that addresses this, so it might be an opportunity to create a lib out of it 😁. It's crucial to align accessibility features in React Native with those available natively on iOS and Android for a consistent user experience. but the approach in gen eral should go something like this:

import Foundation
import React

@objc(RNAccessibilityBridge)
class RNAccessibilityBridge: NSObject {

  @objc
  func setAccessibilityFocus(_ reactTag: NSNumber) {
    DispatchQueue.main.async {
      if let view = self.bridge.uiManager.view(forReactTag: reactTag) {
        UIAccessibility.post(notification: .screenChanged, argument: view)
      }
    }
  }
}

// to expose the module to React Native
@objc
extension RNAccessibilityBridge: RCTBridgeModule {
  static func moduleName() -> String! {
    return "RNAccessibilityBridge"
  }
}

And then in the React Mative file:

import { NativeModules } from 'react-native';

interface RNAccessibilityBridgeInterface {
  setAccessibilityFocus(reactTag: number): void;
}

const { RNAccessibilityBridge } = NativeModules as { RNAccessibilityBridge: RNAccessibilityBridgeInterface };

// method could be used as follows
RNAccessibilityBridge.setAccessibilityFocus(reactTag);

hope it helps 👌🙏

[pixel-404]

what does reactTag represent in this context please?

[matboud]

its a unique identifier for a React component react doc!

[ArturKalach]

Hello everyone,
I have finished working on an "advanced" ordering system for React Native:

• https://github.com/ArturKalach/react-native-a11y-order
• https://www.npmjs.com/package/react-native-a11y-order

Ordering	Grouping

It has some nuances, but honestly, it works really well!

API is really simple, we could control the order by web way via indexes.

 <A11y.Order>
        <A11y.Index index={1}>
          <Text style={styles.font}>
            First
          </Text>
        </A11y.Index>
        <A11y.Index index={3}>
          <Text style={styles.font}>
            Third
          </Text>
        </A11y.Index>
        <A11y.Index index={2}>
          <Text style={styles.font}>
            Second
          </Text>
        </A11y.Index>
</A11y.Order>

NO ScrollView grouping

Additionally, there's no need to group content using ScrollView for horizontal scrolls anymore. A11y.Group functions almost like a bare View, but, it achieves the same effect