[iOS][Accessibility][Critical?] #35774: accessibility state race condition by maxencehenneron · Pull Request #54131 · react/react-native

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

maxencehenneron · 2025-10-10T23:26:30Z

Refactor accessibility actions to fix a race condition on iOS. Fixes#35774

Summary:

I know you will most likely not like my fix, but there currently is a race condition that creates issues for our most vulnerable users.

Any accessibility action performed on an element on iOS are out of sync, from custom actions, taps, magic taps, increment, decrement or escape.

This is because the VoiceOver on iOS will immediately read the text once an action is called as it expects the function to update accessibilityValue / accessibilityState. The problem is we're emitting an asynchronous event to update this value so there is currently no easy way to fix this.

What I found is working is using this experimental_flushSync function to update the state synchronously. This is obviously bad for performance but i'd argue that for the current context (vision impairment) having 60fps when running an action (that doesn't happen often) is less important than having wrong vocal directions.

Changelog:

[iOS] [Fixed] - Updated accessibilityIncrement, accessibilityDecrement, accessibilityActivate, accessibilityPerformEscape, accessibilityPerformMagicTap to synchronously update the state when the action is run
[iOS] [Fixed] - Add missing accessibility props to TouchableOpacity

Test Plan:

Before:

ScreenRecording_10-10-2025.16-23-24_1.mov

After:
https://github.com/user-attachments/assets/5e31e2de-63e9-4234-bb4c-d46dfe1cabcf

Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

meta-cla · 2025-10-10T23:26:35Z

Hi @maxencehenneron!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

meta-cla · 2025-10-10T23:34:15Z

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

maxencehenneron · 2025-10-14T18:19:19Z

This is actually worse than I thought:

We have the same issue with custom actions (my last commit fixes it). Meaning running a custom action that updates the accessibilityState (for example "selected", "expanded") will announce the previous state so any vision-impaired user would think the action was not performed and run it again. That time it would announce "selected" when it's actually not selected anymore.

I want to stress that accessibility is a legal requirement in Europe and the US and required by many legal frameworks.

…bilityPerformEscape

maxencehenneron · 2025-10-14T19:12:24Z

This PR can now be reviewed

efoken · 2025-10-15T04:55:26Z

Great, finally 👍

I wonder why this was never fixed before, because we have this issue at IBM iX for many of our clients apps and as a11y is a legal requirement in the EU we getting more and more trouble with this issue 😅

Even if this uses experimental code, it seems to be the easiest fix.

maxencehenneron · 2025-10-15T16:40:14Z

Small note on my PR:

You have to implement onAccessibilityTap for the standard action (double tap) to work. Only implementing "onPress" will result in the wrong state being announced.
I think this is fine. We do not want to synchronously flush onPress and explicitly adding onAccessibilityTap makes sense.

maxencehenneron · 2025-10-27T18:47:49Z

If anyone wants to reliably reproduce this issue, add the following code to the rn-tester playground:

functionPlayground(){const[counter,setCounter]=React.useState(0);// Simulate some heavy computationfor(leti=0;i<10000000;i++);return(<Viewstyle={styles.container}><PressableaccessibleaccessibilityValue={{text: `Counter is ${counter}`}}onAccessibilityTap={()=>setCounter(counter+1)}><RNTesterTextaccessible={false}>The counter is: {counter}</RNTesterText></Pressable></View>);}

Without my fix, it reads the wrong value. With my fix, the correct value is read.

maxencehenneron · 2025-11-05T16:22:51Z

@javache Sorry for the ping but I believe my accessibility PRs got overlooked and this bug is kinda critical for any production app. Would you be able to forward my PRs to the appropriate person at Meta? Thank you

javache · 2025-11-19T22:00:15Z

Thanks for the detailed write-up here.

You're right that using experimental_flushSync raises some eyebrows. Not only can it hurt performance, it currently can be unpredictable to when it will actually get executed (we've seen React code not using transitions or a badly configured FlatList taking 1s+), which will make the user believe the app is unresponsive. Worse, if the JS thread is currently trying to synchronously access the UI thread, the app will deadlock (see feature flag enableMainQueueCoordinatorOnIOS)

One thing which would help reduce the risk here is that we first add a feature flag for this so we can do a test of this internally at Meta before changing this behaviour by default.

cc @lunaleaps @yungsters @sammy-SC on using experimental_flushSync here.

javache · 2025-11-19T21:42:50Z

+ onAccessibilityTap={this.props.onAccessibilityTap}
+ onAccessibilityEscape={this.props.onAccessibilityEscape}
+ onMagicTap={this.props.onMagicTap}


Is this related to these changes? Can it be a separate PR?

javache · 2025-11-19T21:53:23Z

 {
 if (_eventEmitter && _props->onAccessibilityTap) {
- _eventEmitter->onAccessibilityTap();
+ auto emitter = std::static_pointer_cast<const ViewEventEmitter>(_eventEmitter);


nit: prefer a static_cast of *_eventEmitter

Summary: This is my PR 2 out of 3 to improve accessibility on iOS. If you're reading this, please also have a look at #54131, this is a critical race condition bug that basically makes accessibility extremely hard to handle on large apps. Fix for #53496: on the new architecture, any accessibility label is ignored and only the "name" is read by VoiceOver. We want to use name as an "action id", and label as the translatable value. While android has a id/label system for actions, iOS doesn't so my implementation, inspired by the old paper architecture, maps labels to name. Native iOS will only see the labels but the JS side will properly receive names when an action is executed. I believe this is the correct way of handling this. Another thing we could do is just deprecate "label" and expect name to be in the correct language, but I do not like that. ## Changelog: [IOS][FIXED] - Accessibility actions labels are not read by VoiceOver Pull Request resolved: #54286 Test Plan: Open RN-Tester, go to Accessibility -> Accessibility Action Examples, enable VoiceOver and select "This view supports many actions". Now scroll up fast to select the actions. On the current implementation you will hear VoiceOver say "copy", then "cut", then "paste". It now says "cut label", "copy label", "paste label". As a reference, here's how this view is implemented: ```jsx <View accessible={true} accessibilityActions={[ {name: 'cut', label: 'cut label'}, {name: 'copy', label: 'copy label'}, {name: 'paste', label: 'paste label'}, ]} onAccessibilityAction={event => { switch (event.nativeEvent.actionName) { case 'cut': Alert.alert('Alert', 'cut action success'); break; case 'copy': Alert.alert('Alert', 'copy action success'); break; case 'paste': Alert.alert('Alert', 'paste action success'); break; } }}> <RNTesterText>This view supports many actions.</RNTesterText> </View> ``` Reviewed By: cipolleschi Differential Revision: D87766483 Pulled By: javache fbshipit-source-id: a979f0126efce4b87c6d823519d512229fb4118e

maxencehenneron · 2026-01-05T19:32:19Z

I have some time to dedicate to this PR this month, what can I do to unblock it? Should I update the code to add a feature-flag?
Do you have any other idea on how this problem could be resolved? I understand it would significantly slow down the app on huge lists but I doubt there's a way around it. It might be something we have to accept. This would only affect the app while using the a11y controls, which are meant to be used by vision-impaired users that will likely not perceive stuttering.

react-native-bot · 2026-07-05T06:16:26Z

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Fixreact#35774: adjustable increment/decrement race condition
c1d7750
Refactor accessibilityIncrement and accessibilityDecrement to fix a race condition on iOS.

maxencehenneron changed the title ~~Fix #35774: adjustable increment/decrement race condition~~Fix #35774: a11y "adjustable" increment/decrement action race conditionOct 10, 2025

meta-claBot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Oct 10, 2025

facebook-github-bot added the Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team. label Oct 10, 2025

Also fix custom actions
be8b9ef

Also fix accessibilityActivate, accessibilityPerformMagicTap, accessi…
a6bf90d
…bilityPerformEscape

maxencehenneron changed the title ~~Fix #35774: a11y "adjustable" increment/decrement action race condition~~#35774: accessibility state race condition Oct 14, 2025

maxencehenneron changed the title ~~#35774: accessibility state race condition~~ [iOS][Accessibility][Critical?] #35774: accessibility state race condition Oct 14, 2025

bonus: add missing accessibility props to TouchableOpacity
78d6038

maxencehenneron mentioned this pull request Oct 27, 2025
[ios][accessibility] Fix action labels on iOS, fixes #53496 #54286
Closed

javache reviewed Nov 19, 2025
View reviewed changes

react-native-bot added Stale There has been a lack of activity on this issue and it may be closed soon. and removed Stale There has been a lack of activity on this issue and it may be closed soon. labels Jul 5, 2026

Uh oh!

Conversation

maxencehenneron commented Oct 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary:

Changelog:

Test Plan:

Uh oh!

meta-claBot commented Oct 10, 2025

Action Required

Process

Uh oh!

meta-claBot commented Oct 10, 2025

Uh oh!

maxencehenneron commented Oct 14, 2025

Uh oh!

maxencehenneron commented Oct 14, 2025

Uh oh!

efoken commented Oct 15, 2025

Uh oh!

maxencehenneron commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maxencehenneron commented Oct 27, 2025

Uh oh!

maxencehenneron commented Nov 5, 2025

Uh oh!

javache commented Nov 19, 2025

Uh oh!

javacheNov 19, 2025

Choose a reason for hiding this comment

Uh oh!

javacheNov 19, 2025

Choose a reason for hiding this comment

Uh oh!

maxencehenneron commented Jan 5, 2026

Uh oh!

react-native-bot commented Jul 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

maxencehenneron commented Oct 10, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary:

Changelog:

Test Plan:

Uh oh!

meta-claBot commented Oct 10, 2025

Action Required

Process

Uh oh!

meta-claBot commented Oct 10, 2025

Uh oh!

maxencehenneron commented Oct 14, 2025

Uh oh!

maxencehenneron commented Oct 14, 2025

Uh oh!

efoken commented Oct 15, 2025

Uh oh!

maxencehenneron commented Oct 15, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maxencehenneron commented Oct 27, 2025

Uh oh!

maxencehenneron commented Nov 5, 2025

Uh oh!

javache commented Nov 19, 2025

Uh oh!

javacheNov 19, 2025

Choose a reason for hiding this comment

Uh oh!

javacheNov 19, 2025

maxencehenneron commented Oct 10, 2025•
edited
Loading

maxencehenneron commented Oct 15, 2025•
edited
Loading

maxencehenneron commented Oct 10, 2025•
edited
Loading

maxencehenneron commented Oct 15, 2025•
edited
Loading

maxencehenneron commented Oct 10, 2025•
edited
Loading

maxencehenneron commented Oct 15, 2025•
edited
Loading