iOS Accessibility Value Out of Sync

[samcarlinone]

Description

On iOS it seems that after an accessibility action is triggered the value of accessibility value is read an arbitrary amount of time later. This can lead to VoiceOver reading the previous value again rather than the new value.

This means that sometimes the value will be read correctly, depending on how quickly react native renders the updated accessibility action.

However in my moderately complex RN project I was unable to reliably get everything rendering quickly enough. Even when Flipper said the component in question was rendering in a few ms the bug would still sometimes occur (about 1 in 20 actions).

Note: On Android, TalkBack waits any length of time before reading the updated value. Even an artificial of delay of 500ms will still be read correctly.

Version

0.68.5

Output of npx react-native info

System:
OS: macOS 12.6
CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
Memory: 37.62 MB / 32.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
Yarn: 1.22.10 - /usr/local/bin/yarn
npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
Watchman: 2022.06.06.00 - /usr/local/bin/watchman
Managers:
CocoaPods: 1.11.3 - /usr/local/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
Android SDK:
API Levels: 30, 31
Build Tools: 30.0.2, 31.0.0, 33.0.1
System Images: android-24 | Google APIs Intel x86 Atom, android-30 | Google APIs Intel x86 Atom, android-30 | Google Play Intel x86 Atom, android-31 | Google APIs Intel x86 Atom_64, android-31 | Google Play Intel x86 Atom_64
Android NDK: Not Found
IDEs:
Android Studio: 2021.3 AI-213.7172.25.2113.9123335
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
Languages:
Java: 18.0.1 - /usr/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.68.5 => 0.68.5
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found

Steps to reproduce

Accessible components with the following properties:

• accessibleRole="adjustable"
• accessibilityActions for increment and decrement
• accessibilityValue with text property set

In an app where the component is not guaranteed to render quickly enough.

Running with VoiceOver on iOS (Reading speed didn't seem to change the issue)

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

https://snack.expo.dev/@scarlin/ios-accessibility-value-bug-demo

[samcarlinone]

This issue is still happening on iOS with React Native version 0.71.7

Also noticed it occurring on a switch component, where the announced checked state after toggling a component is incorrect.

[kseverinsen]

This issue is still happening with v0.72.6

[Magnus-V]

This issue is still happening with v0.73.2.

A change in a checked value using accessibilityState does not help and previous value is being read. On an older android device it works perfectly so could be a race-condition error or iOS error.

[davor-bauk-sh]

I'm seeing similar behavior in accessibilityRole="adjustable" components. When updating the accessibilityValue's now property from eg. 1 to 2, iOS VoiceOver incorrectly announces the new state as "one".

Similarly, when modifying the checked property in components' accessibilityState, iOS VoiceOver incorrectly announces the previous value (eg. when checked is changed from false to true, VoiceOver announces "unchecked").
I'm seeing this behavior with both custom checkbox components as well as with React Native's Switch component.

I'm currently running RN v0.73.6 (Expo SDK 50)

[hraschan]

I'm having the same issue in react native v0.73.6 (Expo SDK 50).
When I navigate to a new page with a delay of 100ms or more or opening a bottom sheet for example, the focused element gets read again.

Is there any way to prevent this?

[JHelar]

Experiencing the same issue, I have a rather small application but still the updated accessibilityState- checked value is not being respected and the old value is announced by iOS VoiceOver once you activate the button.

Same issue if you dynamically change the accessibilityLabel or the text element within the button (after a11y tap activation).
Tried with different accessibilityRole's: togglebutton, checkbox and button with same results.

Running:

{
 "expo": "51.0.15",
 "react": "18.2.0",
 "react-native": "0.74.2",
}

[ManarHussein]

any update for this issue? @samcarlinone

[efoken]

Can confirm that this issue is still happening with v0.76.2 when dynamically changing accessibilityState or accessibilityLabel

[07kushalsaini]

I’ve been facing the same issue with VoiceOver not reliably announcing state updates (e.g., checkbox or radio button changes). While this isn’t a perfect fix, I’ve found a workaround that’s working consistently for me.

Workaround:
The idea is to force a pause in VoiceOver by first announcing a long empty string, and then after a short delay (e.g., 1200ms), announce the updated accessibility label. This effectively clears the current announcement and queues a new one that is picked up properly by VoiceOver.

Here’s a simplified code snippet of what I’m doing:

import { AccessibilityInfo } from 'react-native';

updateAccessibilityState() {
	const accessibilityLabel = "Updated accessibilityLabel";

	this.setState({ accessibilityLabel: '' }, () => {
		// Step 1: Announce a long pause to interrupt current VO speech
		AccessibilityInfo.announceForAccessibility(' ');

		// Step 2: After 1200ms, set the real label and announce it
		setTimeout(() => {
			this.setState({ accessibilityLabel });
			AccessibilityInfo.announceForAccessibility(accessibilityLabel);
		}, 1200);
	});
}

Use this.state.accessibilityLabel in accessibilityLabel={this.state.accessibilityLabel} in your component.

This forces VoiceOver to "stop" and then pick up the new accessibility value reliably.

While this is definitely a hack and not an ideal solution, it seems to work well in practice until the underlying issue is resolved.

Hope this helps someone else in the meantime!

[07kushalsaini]

This issue is still happening on iOS with React Native version 0.71.7

Also noticed it occurring on a switch component, where the announced checked state after toggling a component is incorrect.

@samcarlinone @kseverinsen @Magnus-V @davor-bauk-sh Hope this will helps :- #35774 (comment)

[a-klotz-p8]

This seems to still exist in RN 0.78. Does anyone know if it is fixed in RN 0.79+? Kind of crazy that this issue has been around since Jan 2023 or even earlier and is still not fixed! Considering that after 28. June 2025 a lot of companies need to implement accessibility, this seems like something that needs to be fixed asap!

[jerone]

Just noticed it on the Switch component too. But only for iOS.

It looks like there was once a fix for Android, but but the original issue got marked as Android, so the fix was never applied to iOS.