[Android] - accessibilityLabel ignored on TextInput when testing with TalkBack screen reader (and also placeholder overriding accessibilityLabel)

[BogdanCerovac]

Description

This is actually a combined issue:

1. TextInput and it's accessible name when we use accessibilityLabel - it works fine if field is empty. It does not announce accessibilityLabel if field has a value inside and accessibilityLabel is basically ignored - TalkBack only announces "Editing " and the input value (accessibilityLabel is then not announced at all).

2. TextInput and it's accessible name when we use both accessibilityLabel and placeholder at the same time - only placeholder value is announced to a screen reader.

Steps to reproduce

React native - tested with default clean install and minimal code (please check Expo link for the whole code, but following code is essentially it).

1. use the following code:

<TextInput
            accessibilityLabel="Your GUID (lbl2)"
            style={styles.input}
            onChangeText={onChangeText2}
            value={text2}
          />

Then test with TalkBack (this time I did not use physical keyboard (but we need to check that as well)):

1. default focus announces accessibilityLabel value - OK

2. write something in the field and move focus out of the field

3. move focus back to the same field - accessibilityLabel is not announced at all - ISSUE

4. use the following code:

<TextInput
            accessibilityLabel="Your GUID (lbl)"
            placeholder="Your GUID (plac)"
            style={styles.input}
            onChangeText={onChangeText}
            value={text}
          />

Then test with TalkBack:

1. default focus announces placeholder value and accessibilityLabel is not announced at all - ISSUE
2. write something in the field and move focus out of the field
3. move focus back to the same field - accessibilityLabel and value are announced - OK

React Native Version

0.83.1

Affected Platforms

Runtime - Android

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

System:
  OS: Windows 11 10.0.26100
  CPU: (20) x64 12th Gen Intel(R) Core(TM) i7-12700F
  Memory: 28.82 GB / 63.82 GB
Binaries:
  Node:
    version: 22.19.0
    path: C:\Program Files\nodejs\node.EXE
  Yarn: Not Found
  npm:
    version: 10.9.3
    path: C:\Program Files\nodejs\npm.CMD
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK: Not Found
IDEs:
  Android Studio: AI-242.23339.11.2421.12483815
  Visual Studio: Not Found
Languages:
  Java:
    version: 17.0.12
    path: C:\Program Files\Microsoft\jdk-17.0.12.7-hotspot\bin\javac.EXE
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.2.0
    wanted: 19.2.0
  react-native:
    installed: 0.83.1
    wanted: 0.83.1
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found

Stacktrace or Logs

N/A

MANDATORY Reproducer

https://snack.expo.dev/@bogdancerovac/2025-12-30---a11y-testing-textinput---issues

Screenshots and Videos

Made a simple short video: https://youtu.be/xQTtPUkdN9Y

[andrea-martinez-dev]

In the video I noticed that when you focus out of TextInputs the cursor keeps blinking as if they still had focus.
This could explain why when you focus out of the input and then back to it you are already in editing mode and the label is not (correctly, at this point) announced. It seems that the TextInput does not handle blur properly with talkback and external keyboards and it skips the TextInput activation step.
I verified that similar issues happen on a physical device with bluetooth kb and talkback on too, though I could test it only on RN 79.2

UPDATE:
I made some further tests with TalkBack, especially with the virtual keyboard and they confirmed that you can focus another element while the keyboard stays opened and focused on a TextInput. BUT I also tested the same scenario in other apps (not developed in RN) and it seems the behavior is the same.

So apparently the command to exit the editing mode of a TextInput is always demanded to the user before changing focus, which sort of makes sense.

At this point I suspect the behavior we are seeing is correct, or if it's not the intended behavior, I wonder if the problem is in TalkBack itself and not React Native.

Furthermore I noticed things can easily get messed up when operating with different inputs altogether: for example using the keyboard to input chars but using mouse or finger to change focus. Or even when using the keyboard only and moving between objects with arrows or tab instead of alt+arrows.

Thanks for bringing this up @BogdanCerovac

[BogdanCerovac]

@andrea-martinez-dev Thanks for testing.

I should perhaps write that I did not use external keyboard in combination with the TalkBack, sorry, added this info the OP.

Yes, keyboard focus and TalkBack focus can be out of sync, that's OK. But TalkBack should announce accessibility names of interactive elements independently - so in our case it should not matter if keyboard focus is somewhere else.

I don't have an non-React Native app that I can be certain is using the same code behind to check, but I tested with some random Edit Box-es (for example Gmail and Google Maps) that had placeholders and (seemingly) accessibilityLabels and TalkBack announced both of them when I wrote inside field, moved TalkBack focus away and then back to the field (as per example 1), so I can not think that TalkBack is the issue here. Unfortunately I have all my devices on same TalkBack version (16.0.01.0), so can't test with different versions at the moment.

I don't think that different inputs have a lot to say here - when TalkBack is on it should announce it's own focus and I think there is something wrong with the code on lower level (Android), am not an native native dev, but will try to check it if time allows, perhaps something is obvious there.

While re-testing I also stumbled upon another issue when field is filled in, with different assistive tech -will open a new issue if none exists already. They could actually be related (seems like it)...

[andrea-martinez-dev]

@BogdanCerovac TalkBack has changed many things in the last 2 years on Inputs (starting from how editing is announced.. now it says "123 has replaced 12" on every keystroke, for example, while before it only announced the pressed key), and I am sure about this because I was working on the same RN version and it changed after an Android update.

That's why I am quite prone to think TalkBack could be involved in this too. I am not excluding RN bc it keeps changing too, so it's not very easy to track down who is responsible for this. I general I think RN has still a lot to do for accessibility support, both on features and documentation.

UPDATE
Just 2 little updates:

• I see Talkback 16.2 is now available, tried to check if something has changed, but no.
• Regarding this point:

TextInput and it's accessible name when we use accessibilityLabel - it works fine if field is empty. It does not announce accessibilityLabel if field has a value inside and accessibilityLabel is basically ignored - TalkBack only announces "Editing " and the input value (accessibilityLabel is then not announced at all).

It seems that if the TextInput has secureTextEntry={true} the accessibilityLabel is correctly announced when field has value.

[BogdanCerovac]

@andrea-martinez-dev - indeed totally possible, I've seen that as well and did not had issues with Jetpack Compose components (at least not these mentioned in my OP). But React Native is not using Jetpack Compose behind the scenes, so totally possible that TalkBack have an issue, absolutely.

As a web dev, I may absolutely be wrong (somebody fluent in Android and Kotlin, please help :) ), but I tried to somehow understand the Android "native native" code used here in React and I think it is this one here https://github.com/facebook/react-native/blob/913e869c940ef2a23c27c7cf68e4d15749983d06/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.kt#L105 (?)

RN is seemingly using AppCompatEditText, so perhaps we can check it directly there, using same device, same TalkBack version.

Do you perhaps have the possibility to "isolate" native native Android code from React Native, so that we can run the same code (obviously trimmed down to just showing a single field), to test?

I guess we can then open an issue with Android / TalkBack if same "native native" code has same issues. But if it works, then I guess we have an issue in React Native.

Will try to find the time to do it myself, but I doubt I will be as efficient as an Android dev doing it for years :)

Update:

I also updated to TalkBack 16.2 and still same issue indeed.

[andrea-martinez-dev]

@BogdanCerovac - I can't make the test you suggested but I could test the scenario on iPhone + VoiceOver and the accessibilityLabel is always correctly announced independently from the value (empty or not empty) or editing mode of the field (focused or focused+editing).
Can't still state if React Native or Talkback issue, but It seems it's something Android specific.

[jwlilly]

I think this might be a TalkBack bug or they have changed how TalkBack is working. Previously, TalkBack always announced the hint property that was available in the AccessibilityNodeInfo for EditText controls. That was a reliable way to provide an accessible name for an input field since it was always announced regardless if text was entered. That doesn't seem to be the case now and the issue is present within Google's apps.

In the screenshots, TalkBack is only announcing the text property of the EditText fields even though the hint property contains what should be the accessible name of the control.

[BogdanCerovac]

I can confirm that this really is a TalkBack issue and not specific to React Native.

I've made an isolated Android-only example, with "native native" Text Fields (AppCompatEditText) and got the same result.

TalkBack 16.2 really got lots of changes and it seems that this issue is actually a regression (or related to) - https://issues.chromium.org/issues/41310591.

[BogdanCerovac]

Opened a bug there: https://issuetracker.google.com/issues/474704378

[react-native-bot]

This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.