Reword accessible section in Accessibility guide#4653
Conversation
|
@cortinico For a change like this one where I am just rewording things, should I push this to previous versions of the docs, and if so how many? |
✅ Deploy Preview for react-native ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
cortinico
left a comment
cortinico
left a comment
There was a problem hiding this comment.
@joevilches I'd say let's backport this down to 0.78 which is the versions we currently support
| ``` | ||
|
|
||
| In the above example, accessibility focus is only available on the parent view with the `accessible` property, and not individually for 'text one' and 'text two'. | ||
| In the above example, accessibility focus is only available on the first child view with the `accessible` property, and not individually for the other views. |
There was a problem hiding this comment.
and not individually for the other views.
This is confusing as there is only another view, and you saying "other views" is unclear what you're referring to.
|
cc @cortinico I moved this to a new pr #4656. My fork was messed up with a bunch of old commits. I got rid of those and made a new branch for this so its clearer. I also responded to the edits there |
3 participants
The current description of the
accessibleprop is misleading and confusing. The current wording implies that this prop mainly "groups its children into a single selectable component", which is a round-about way of saying it can receive focus, I think? I am not really sure what that means.Regardless, the main point is not hammered home: This prop allows the View to be discoverable by screen readers (and other things).
The example is also a bit misleading, since Text is focusable by default on iOS. It is not wrong, but the example is better for a guide on label co-opting, not basic use of
accessible.Curious how, if at all, I should change this for previous versions.