-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Please document correct usage of accessibilityRole "link" #3215
Comments
👋 Hey there, it looks like there has been no activity on this issue in the last 90 days. Has the issue been fixed, or does it still require the community attention? This issue will be closed in the next 7 days if no further activity occurs. Thank you for your contributions. |
No it's not fixed, stay open please. |
👋 Hey there, it looks like there has been no activity on this issue in the last 90 days. Has the issue been fixed, or does it still require the community attention? This issue will be closed in the next 7 days if no further activity occurs. Thank you for your contributions. |
No it's not fixed, stay open please. |
👋 Hey there, it looks like there has been no activity on this issue in the last 90 days. Has the issue been fixed, or does it still require the community attention? This issue will be closed in the next 7 days if no further activity occurs. Thank you for your contributions. |
No it's not fixed, stay open please. |
Description
Here's the current documentation for
accessibilityRole="link"
:This... could be more helpful. It's arguably a tautology: it says the link role should be used in those cases where the link role should be used.
There are many examples (some given below) of inconsistent and sometimes contradictory ways this has been interpreted.
What is the problem?
This is a problem because people fill in their own common-sense opinion on how link roles should be used (possibly influenced by non-equivalent experience of links on websites).
For example, I've encountered three different interpretations on how the link role should be used, all from seemingly authoritative sources:
useLinkProps
that applyaccessiblityRole="link"
to any element that navigates between screens - every element using these utilities that would do internal routing in a web context will get the "link" role in Android and iOS.Text
element with anonPress
handler to have the role "link", regardless of what the press does. This appears to be interpreting "link" by presentation (interactive inline text) rather than the nature of the action.How can we address it?
There is one right answer as to how React Native's link accessibilityRole is intended to be used, based on the appropriate iOS and Android guidance for the underlying properties and traits that React Native applies internally to the native Android and iOS elements it controls.
The React Native accessibility docs should state it clearly. For example (assuming this one is correct):
Why is it important?
There's clearly already diverging interpretations of how this role should be used, and it's a very commonly used role, so there is almost certainly already a lot of inconsistency on when elements are described as a "Link" in React Native apps in production.
Who needs this?
Ideally all React Native developers should be applying this accessibilityRole consistently and correctly.
When should this happen (use version numbers if needed)?
As soon as there's a clear consensus on what the correct usage is.
The text was updated successfully, but these errors were encountered: