react-native: Keyboard focus (from a physical keyboard) won't enter TextInput fields on Tab/Shift+Tab in Android

Description

On Android devices, when other focusable controls (such as Buttons) are adjacent to a TextInput component, and a physical keyboard is used to interact with the app (e.g. via bluetooth or USB connection), keyboard focus will stop at the focusable element before the TextInput when tabbing or at the one after the TextInput when shift-tabbing.

React Native version:

System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
    Memory: 13.44 GB / 31.94 GB
  Binaries:
    Node: 12.16.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.19.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowAllTrustedApps: Enabled
  IDEs:
    Android Studio: Version  4.0.0.0 AI-193.6911.18.40.6626763
    Visual Studio: 15.9.28307.518 (Visual Studio Enterprise 2017)
  Languages:
    Java: Not Found
    Python: 2.7.11 - C:\Python27\python.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: https://github.com/expo/react-native/archive/sdk-39.0.4.tar.gz => 0.63.2
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps To Reproduce

Using the Snack below under Android (tested on Pixel 3 with Android 11)

  1. Connect a physical keyboard to the Android device, either using USB or Bluetooth. If using an emulator, you may need to configure it to send keyboard shortcuts to the virtual device; I’ve had better luck reproing on physical devices, though.
  2. Press Tab and Shift+Tab to move the focus between the Buttons and TextInput
  3. Observe that pressing Tab when focused on the element before the TextInput or Shift+Tab on the element after the TextInput does not move the focus to the TextInput. Additionally, if you tap to activate the TextInput, you cannot press Tab/Shift+Tab to leave the TextInput.

Expected Results

The TextInput should participate in the keyboard tab order. Users may use a physical keyboard for accessibility reasons.

Snack, code example, screenshot, or link to a repository:

https://snack.expo.io/dg2qxBBue

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 2
  • Comments: 17 (1 by maintainers)

Commits related to this issue

Most upvoted comments

@fabriziobertoglio1987 the workaround does not seem to work. Wrapping the TextInput in a Touchable and then tabbing never fires the onFocus of the touchable. Tried this a couple of times but it didn’t work. onPress of the TouchableHighlight and TouchableNativeFeedback is fired but never onFocus. Also, I have a button below the text input, if the current keyboard focus is on the button - doing shift + tab does not take it back to the input (touchable wrapped input did not work here). Are you aware of any other workarounds?

Hi @RyanCommits, have you tested how this translates for users dependent on screen readers?

Hi @pandu-supriyono

I’ve tested the recommended workaround (wrap the text input in a <Pressable> and then set focus on it) with TalkBack.

When using TalkBack, navigating by swiping left and right, there is no real difference from navigating a native android text field. So all good there, it works as expected.

However, for external keyboard users, who also use a screen reader there is a problem, in that focus moves to the <Pressable> and nothing is announced.

To address this, we had to add an accessibilityLabel as well as the value and associated accessibilityHint text to the pressable, so that it mirrors the announcement of the <TextInput>. This way, external keyboard users who also screen reader can navigate the fields and hear equivalent information.

When you add the accessibilityLabel to the pressable it makes it discoverable to screen reader users. So each field effectively receives focus twice when swiping with TalkBack. It’s an annoying trade off, but we felt the additional focus points were a less critical issue than the label and value of the field not being announced at all.

@pandu-supriyono I’m no longer working on the application that had this issue, and haven’t looked at it for a while. Best of luck, this is a tough one.

I was moved to a different project before I could revisit this, so unfortunately I don’t know where this ended up, sorry.