Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Clickable property requires "button" to be set as accessibilityRole #31033

Closed
kacieb opened this issue Feb 22, 2021 · 6 comments
Closed

Clickable property requires "button" to be set as accessibilityRole #31033

kacieb opened this issue Feb 22, 2021 · 6 comments
Assignees
Labels
Accessibility Platform: Android Android applications. Stale There has been a lack of activity on this issue and it may be closed soon.

Comments

@kacieb
Copy link
Contributor

kacieb commented Feb 22, 2021

Description

When a component has an onPress property, it should be clickable by TalkBack even if it is not set to be a button. This was discovered here.

This may require native changes on Android. It may also require an API change. From this comment, it is common on iOS for anything clickable to be called a "button" according to accessibility. This is not true on Android, when only things that look and feel like buttons should be labeled a button.

React Native version:

0.63

Steps To Reproduce

<Text onPress={() => {console.log("hello!")}} />
<Text accessibilityRole="button" onPress={() => {console.log("hello!")}} />

NOTE: More triage is needed to verify what happens on Android/iOS with these two cases.

Expected Results

Desired behavior on Android - Text node is clickable even if accessibilityRole is not "button"
Desired behavior on iOS - ?

@blavalla
Copy link
Contributor

From a technical perspective on the Android side, the onPress prop should set view.setClickable(true) if it's not already. Usually, by calling view.setOnClickListener() this will happen automatically, but maybe we're using a touch listener or some other mechanism to detect the click.

@chrisglein chrisglein added the Platform: Android Android applications. label Feb 23, 2021
@chrisglein
Copy link

This may require native changes on Android. It may also require an API change.

NOTE: More triage is needed to verify what happens on Android/iOS with these two cases.

There's still some ambiguity here. I'm not sure what the right solution would be based on what you've said here. Can you do some background research and turn this into a more concrete proposal?

@kacieb
Copy link
Contributor Author

kacieb commented Feb 24, 2021

Claiming this for now so I can update the issue with more research.

@kacieb kacieb self-assigned this Feb 24, 2021
@github-actions github-actions bot added Needs: Attention Issues where the author has responded to feedback. and removed Needs: Author Feedback labels Feb 24, 2021
@chrisglein chrisglein removed Needs: Attention Issues where the author has responded to feedback. Needs: Author Feedback labels Apr 20, 2021
@fabOnReact
Copy link
Contributor

fabOnReact commented Oct 3, 2021

Thanks a lot. I start investigating the issue, this are my notes.

From a technical perspective on the Android side, the onPress prop should set view.setClickable(true) if it's not already. Usually, by calling view.setOnClickListener() this will happen automatically, but maybe we're using a touch listener or some other mechanism to detect the click.

the accessibilityRole="button" triggers setClickable(true)

} else if (role.equals(AccessibilityRole.BUTTON)) {
nodeInfo.setClickable(true);

adding accessible=true prop to a component triggers setFocusable

public void setAccessible(ReactViewGroup view, boolean accessible) {
view.setFocusable(accessible);
}

@ReactProp(name = "focusable")
public void setFocusable(final ReactViewGroup view, boolean focusable) {
if (focusable) {
view.setOnClickListener(
new View.OnClickListener() {
@Override
public void onClick(View v) {
final EventDispatcher mEventDispatcher =
UIManagerHelper.getEventDispatcherForReactTag(
(ReactContext) view.getContext(), view.getId());
if (mEventDispatcher == null) {
return;
}
mEventDispatcher.dispatchEvent(
new ViewGroupClickEvent(
UIManagerHelper.getSurfaceId(view.getContext()), view.getId()));
}
});
// Clickable elements are focusable. On API 26, this is taken care by setClickable.
// Explicitly calling setFocusable here for backward compatibility.
view.setFocusable(true /*isFocusable*/);
} else {
view.setOnClickListener(null);
view.setClickable(false);
// Don't set view.setFocusable(false) because we might still want it to be focusable for
// accessibility reasons
}
}

#30935 (comment)

@stale
Copy link

stale bot commented Jan 9, 2022

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open. Thank you for your contributions.

@stale stale bot added the Stale There has been a lack of activity on this issue and it may be closed soon. label Jan 9, 2022
@github-actions
Copy link

github-actions bot commented Feb 3, 2022

This issue was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this as completed Feb 3, 2022
@facebook facebook locked as resolved and limited conversation to collaborators Feb 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Accessibility Platform: Android Android applications. Stale There has been a lack of activity on this issue and it may be closed soon.
Projects
None yet
Development

No branches or pull requests

4 participants