Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Text Component does not announce disabled and disables click functionality when disabled #33076

Closed

Conversation

fabOnReact
Copy link
Contributor

@fabOnReact fabOnReact commented Feb 9, 2022

Summary

This issue fixes #30937 fixes #30947 fixes #30840 (Test Case 7.1, Test Case 7.3, Test Case 7.5) .
The issue is caused by:

  1. The missing javascript logic on the accessibilityState in the Text component fabOnReact@6ab7ab3 (as previously implemented in Button).
  2. The missing setter for prop accessible in ReactTextAnchorViewManager fabOnReact@17095c6 (More information in previous PR [Accessibility] Fix Image does not announce "disabled" #31252)

Related PR #33070 PR callstack/react-native-slider#354

Changelog

[Android] [Fixed] - Text Component does not announce disabled and disables click functionality when disabled

Test Plan

1. Text has disabled and accessibilityState={{disabled: false}} (link)
2. Text has disabled (link)
3. Text has accessibilityState={{disabled: true}} (link)
4. Text has accessibilityState={{disabled:false}} (link)
5. Text has disabled={false} and accessibilityState={{disabled:true}} (link)
6. Text has accessibilityState={{disabled:true}} and method setAccessible in ReactTextAnchorViewManager (tested on commit b4cd8) (link)
7. Test Cases on the main branch
7.1. Text has disabled and accessibilityState={{disabled: false}} (link)
7.3 Text has accessibilityState={{disabled: true}} (link)
7.5 Text has disabled={false} and accessibilityState={{disabled:true}} (link)
7.6 Text has onPress callback and accessibilityState={{disabled: true}} (link)
7.7 Text has accessibilityState={{disabled:true}} and no method setAccessible in ReactTextAnchorViewManager (tested on commit c4f98dd) (link)

Adding the prop `accessible` to `ReactTextAnchorViewManager` fixes the problem for this component.
The same solution from my previous pr facebook#30935 (comment).

See test case at fabOnReact/react-native-notes#1 (comment)
Adding the prop `accessible` to `ReactTextAnchorViewManager` fixes the problem for this component.
The same solution from my previous pr facebook#30935 (comment).

See test case at fabOnReact/react-native-notes#1 (comment)
666647e
@facebook-github-bot facebook-github-bot 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 Feb 9, 2022
@react-native-bot react-native-bot added Bug Platform: Android Android applications. labels Feb 9, 2022
@analysis-bot
Copy link

Platform Engine Arch Size (bytes) Diff
ios - universal n/a --

Base commit: 97064ae
Branch: main

@analysis-bot
Copy link

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 8,120,598 -401
android hermes armeabi-v7a 7,721,963 -539
android hermes x86 8,491,382 -364
android hermes x86_64 8,443,204 -333
android jsc arm64-v8a 9,787,227 -638
android jsc armeabi-v7a 8,773,462 -782
android jsc x86 9,754,605 -590
android jsc x86_64 10,350,527 -564

Base commit: 97064ae
Branch: main

@fabOnReact fabOnReact marked this pull request as ready for review February 11, 2022 06:30
@facebook-github-bot 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 Feb 11, 2022
Copy link
Contributor

@blavalla blavalla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code and test cases look good to me.

I'm curious why the change in ReactTextAnchorViewManager was needed. What would happen without this change? It doesn't seem like it should've made a difference, since the "disabled" attribute in Android shouldn't affect focusability of an element, although it does seem weird that it was missing, so maybe it was just fixing another bug.

@fabOnReact
Copy link
Contributor Author

fabOnReact commented Feb 14, 2022

Thanks @blavalla

What would happen without this change?

The Text component would not announce disabled.

DOES NOT ANNOUNCE DISABLED

notAnnounceDisabled.mp4

ANNOUNCES DISABLED

announcesDisabled.mp4

The change was already introduced in the Image Component with my PR #31252.

I added two additional tests cases to the Pull Request Summary (test case 6 and test case 7.7).

@facebook-github-bot
Copy link
Contributor

@ShikaSD has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @fabriziobertoglio1987 in 7b2d817.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Feb 15, 2022
facebook-github-bot pushed a commit that referenced this pull request Jun 9, 2022
…cus to true

Summary:
[A recent fix](#33076) to Android to set focusable to true when accessible is true, and this caused several components not to work correctly.

This JS change essentially reverts the default back to Text not being focusable unless it is explicitly set. Android's "auto" behavior is better than setting `accessible=true`, and it's also the behavior React Native has had since accessibility on Android was implemented.

# Wall of Text Explanation

Explanation From Brett's comment [here](https://www.internalfb.com/diff/D35908559?dst_version_fbid=700876567897063&transaction_fbid=477905564133412)

blavalla

Generally speaking, "accessible" in react native maps to "focusable" in Android views, and the default value for "focusabe" for a TextView (and actually all views) is "auto" not "false".  The difference here is that "false" is telling the system to explicitly disallow focus on this element, where as "auto" is telling the system that it's up to whatever service is trying to focus to determine if it should or not.

In the case of text, Talkback generally does default to focusing on Text when it's set to "auto", though it also does try to combine this text together with other not-explicitly focusable siblings and roll the focus up to some common ancestor element.

In the case of TetraButton here, I would expect the default behavior would be that the text is "auto" focusable, so Talkback would combine the text here with the parent <TetraPressable> (which is explicitly focusable via accessible="true").

...

[This diff](#33076) was to fix the issue with "disabled" not properly announcing on text views, which was commonly occuring due to the description-combining feature described above. Basically, when Talkback decides to combine not-explicitly-focusable elements together, it ignores properties like "disabled", "selected", etc. so when combined only the text is transferred.

The "fix" here was to make sure that if disabled was set, that an element was always explicitly focusable so that it wouldn't be eligible to be combined with others. I think that as a general concept makes sense, but the fix actually surfaced an issue that is likely a much older bug.

This line in <Text>
```
accessible={accessible !== false}
```

Is basically always setting accessible="true" unless it's explicitly set to false, and has been in there for years. It was likely added to force text to be accessible by default for iOS.  But until [this diff](#33076) this line was basically a no-op for Android, since setting accessible="true" on text would do nothing at all.

[This diff](#33076)  changed this so that setting accessible="true" worked how you'd expect, by making the view explicitly focusable, which was necessary for the disabled behavior to work properly. But that means that now by default all text views are explicitly focusable on both iOS and Android, and this there is likely many components that were built that don't expect this to be the case.

It doesn't seem like the right fix here is to revert this behavior to its previous state, as it wasn't working how anyone would expect it to if they looked at the code, and it seems like we were relying on some fairly undocumented behavior of Talkback to get it to work how we wanted. If we truly only wanted accessible="true" to be set on all TextViews for iOS, we should be explicit about it and do a platform check before setting that property. If we didn't want this to be iOS-specific, then everything is now actually working as originally intended.

For reference, this is the diff that introduced the default-accessible text - https://www.internalfb.com/diff/D1561326, and the description makes it clear that this was only tested on iOS, and the behavior was explicitly trying to map to iOS norms such as not allowing nested accessible elements.

Changelog:
[Android][Fixed] Make Text not focusable by default

Reviewed By: ryancat

Differential Revision: D36991394

fbshipit-source-id: c45d2ada72bb2d6ffeee6947d676a07fb8899449
Saadnajmi pushed a commit to Saadnajmi/react-native-macos that referenced this pull request Jan 15, 2023
…ality when disabled (facebook#33076)

Summary:
This issue fixes facebook#30937 fixes facebook#30947 fixes facebook#30840 ([Test Case 7.1][7.1], [Test Case 7.3][7.3], [Test Case 7.5][7.5]) .
The issue is caused by:

1) The missing javascript logic on the `accessibilityState` in the Text component fabOnReact@6ab7ab3 (as previously implemented in [Button][20]).
2) The missing setter for prop `accessible` in `ReactTextAnchorViewManager` fabOnReact@17095c6 (More information in previous PR facebook#31252)

Related PR facebook#33070 PR callstack/react-native-slider#354

[20]: https://github.com/facebook/react-native/pull/31001/files#diff-4f225d043edf4cf5b8288285b6a957e2187fc0242f240bde396e41c4c25e4124R281-R289

[Android] [Fixed] - Text Component does not announce disabled and disables click functionality when disabled

Pull Request resolved: facebook#33076

Test Plan:
[1]. Text has `disabled` and `accessibilityState={{disabled: false}}` ([link][1])
[2]. Text has `disabled` ([link][2])
[3]. Text has `accessibilityState={{disabled: true}}` ([link][3])
[4]. Text has `accessibilityState={{disabled:false}}` ([link][4])
[5]. Text has `disabled={false}`  and `accessibilityState={{disabled:true}}` ([link][5])
[6]. Text has `accessibilityState={{disabled:true}}` and method `setAccessible` in `ReactTextAnchorViewManager` (tested on commit [b4cd8][10]) ([link][6])
7. Test Cases on the main branch
[7.1]. Text has `disabled` and `accessibilityState={{disabled: false}}` ([link][7.1])
[7.3] Text has `accessibilityState={{disabled: true}}` ([link][7.3])
[7.5] Text has `disabled={false}`  and `accessibilityState={{disabled:true}}` ([link][7.5])
[7.6] Text has `onPress callback` and `accessibilityState={{disabled: true}}` ([link][7.6])
[7.7] Text has `accessibilityState={{disabled:true}}` and no method `setAccessible` in `ReactTextAnchorViewManager` (tested on commit [c4f98dd][11]) ([link][7.7])

[1]: fabOnReact/react-native-notes#1 (comment)
[2]: fabOnReact/react-native-notes#1 (comment)
[3]: fabOnReact/react-native-notes#1 (comment)
[4]: fabOnReact/react-native-notes#1 (comment)
[5]: fabOnReact/react-native-notes#1 (comment)
[6]: fabOnReact/react-native-notes#1 (comment)
[7.1]: fabOnReact/react-native-notes#1 (comment)
[7.3]: fabOnReact/react-native-notes#1 (comment)
[7.5]: fabOnReact/react-native-notes#1 (comment)
[7.6]: fabOnReact/react-native-notes#1 (comment)
[7.7]: fabOnReact/react-native-notes#1 (comment)

[10]: facebook@17095c6
[11]: facebook@6ab7ab3

Reviewed By: blavalla

Differential Revision: D34211793

Pulled By: ShikaSD

fbshipit-source-id: e153fb48c194f5884e30beb9172e66aca7ce1a41
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Accessibility Bug CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. Platform: Android Android applications. Shared with Meta Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
Projects
None yet
5 participants