Make TextInput "clear text" button accessible

[haitaoli]

Motivation

This PR makes TextInput "clear text" button accessible. UITextField is wrapped inside a RCTUITextField control which has isAccessibleElement set to TRUE. This prevents iOS accessibility interface from enumerating child elements. This change makes the RCTextField not accessible, but allows child elements to be enumerated if the accessible prop is set to true.

Issue

#16989

Test Plan

Manually tested with RNTester sample app and accessibility explorer.

Release Notes

[IOS] [BUGFIX] [TextInput] - Made "clear text" button accessible

[pull-bot]

Attention: @shergin

Generated by 🚫 dangerJS

[shergin]

How does this affect the accessibility of UITextView's content?

[haitaoli]

The UITextView is exposed to accessibility interface as a child element. accessibilityLabel and accessibilityValue are not affected on TextInput in my tests.

[shergin]

@haitaoli Ooops, I meant UITextField.
So, I actually I have two Q:

• Should we apply same changes for RCTUITextView? Why?
• Have you tested this? Does it work exactly like it worked especially for text content?

[shergin]

Thank you for tackling this, BTW! This is really valuable!

[haitaoli]

Is UITextView used when TextInput is multi-line? UITextView doesn't have a clear button so it doesn't need this fix. Here are the screenshots of accessibility explorer output on the TextInput component and it's "clear text" button:

[haitaoli]

accessibilityLabel on TextInput shows up in accessibility explorer correctly with this PR.

[facebook-github-bot]

@shergin is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

[facebook-github-bot]

I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification.

[shergin]

@haitaoli Well, actually RCTUITextField does not wrap it, it subclasses UITextField. So, the text input should behave very well in terms of accessibility. And I am afraid that this changes can interfere with built-in logic. 🤔

Why do you/we need to make "clear" button accessible in the first place?

[haitaoli]

@shergin On iOS, an element can either be accessible, or contain accessible children, but not both: https://developer.apple.com/documentation/uikit/accessibility/uiaccessibilitycontainer. If the TextInput has a button, then we want it accessible, because it's a button and people with disabilities will find it useful. In React Native, the accessible prop is applied the to view directly by default so it cannot contain accessible children elements. The UITextView internally contains a text box implementation. But returning the child elements, accessibility tools such as Voice Over can see both text box and clear button.

[shergin]

@haitaoli So, how does the current default behaviour of different from default UITextView/UITextField? If it's not, we have to be really really careful because this component is really really important and must be perfect from an accessibility perspective. And it must be not RN specific issue, so we have to try to find how other products address it.

I am not an accessible expert, so I don't know for sure, but... do you people with disabilities really need this button? Maybe there is a special gesture for cleaning the text input so they simply don't need a button?

[haitaoli]

@shergin the current behavior of RCTUITextField overrides isAccessibilityElement (via one of the base classes) to return a value based on accessible prop, which disables enumerating child elements. This is the correct behavior for most elements that don't have accessible child elements. But TextInput is different. This is RN specific. I believe this button is important. Without it the user can only use the "backspace" key, and it takes 2 taps to remove one character. Imagine doing this while you cannot see the screen.

[shergin]

Yes, I tested on a real device and in standard apps clear button is accessible. So, if in RN it does not by default, we have to fix it. But first of all, we have to understand why it is happening now.
@haitaoli DId you tried to override setIsAccessibilityElement method and test which component calls it?

[haitaoli]

I didn't. But it should be called on any component with accessible prop set to true.

[janicduplessis]

Seems like it is marked accessible because of the native TextInput component is wrapped with TouchableWithoutFeedback

react-native/Libraries/Components/TextInput/TextInput.js

Lines 825 to 835 in 2cf50e8

	<TouchableWithoutFeedback
	onLayout={props.onLayout}
	onPress={this._onPress}
	rejectResponderTermination={true}
	accessible={props.accessible}
	accessibilityLabel={props.accessibilityLabel}
	accessibilityTraits={props.accessibilityTraits}
	nativeID={this.props.nativeID}
	testID={props.testID}>
	{textContainer}
	</TouchableWithoutFeedback>

which is accessible by default

react-native/Libraries/Components/Touchable/TouchableWithoutFeedback.js

Line 188 in 2cf50e8

accessible: this.props.accessible !== false,

Maybe this could just be fixed in js land?

cc @shergin

[haitaoli]

I don't think there is a workaround on JS side. The native view cannot be set to be accessible without hiding that clear button.

[cpojer]

Seems like this is an RN in open source issue, and @janicduplessis is right that we can probably fix this with a JS only fix. I'm gonna close this PR for now but happy to reopen if I'm wrong.