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

Not all Standard Roles/Traits supported #30839

Closed
Tracked by #30858
amarlette opened this issue Feb 3, 2021 · 11 comments
Closed
Tracked by #30858

Not all Standard Roles/Traits supported #30839

amarlette opened this issue Feb 3, 2021 · 11 comments
Assignees
Labels

Comments

@amarlette
Copy link

amarlette commented Feb 3, 2021

Requires API Proposal

This issue may require a new API, or changes to an existing API. An API proposal should be added and discussed before proceeding with implementation. The API proposal can be added in the comments of this issue or linked as a separate issue.

Description

On Android, not all roles are currently supported, and on iOS not all traits are currently supported.

Not all Android roles map cleanly to an iOS trait, and vice versa, so we may want to consider marking some of these in the documentation as iOS-only or Android-only.

The list of missing roles/traits is below under iOS and Android Details.

Furthermore, while some components allow you to technically set a role with the accessibilityRole prop, these are not always applied. , , , , , and have this issue. While this may have been an intentional choice, it feels broken from an API perspective to allow what looks like a role override prop to exist, but have it do nothing. If we allow this prop, it should correctly override the default role of the component.

React Native version:

v0.63

#Android Details
The following Android roles are not currently supported:

  • checked_text_view
  • drop_down_list
  • edit_text
  • grid
  • list
  • pager
  • seek_control (slider)
  • toggle_button - ToggleButton accessibilityRole is not supported #31419
  • view_group
  • web_view
  • drawer_layout
  • sliding_drawer
  • icon_menu
  • toast
  • date_picker
  • date_picker_dialog
  • time_picker
  • time_picker_dialog
  • number_picker
  • scroll_view
  • horizontal_scroll_view

Out of this list many of these roles are rarely used, but many are also quite common (such as list, edit_text, toast, and seek_control).

List of all roles here:
https://github.com/google/talkback/blob/master/utils/src/main/java/Role.java

iOS Details::
The following iOS traits are not currently supported, but they don't really make sense to be added to the "accessibilityRole" prop, as they are more metadata about the element than specific element types. We may want to consider adding specific APIs for these, or adding some new API for accessibility metadata like this.

  • causesPageTurn
  • startsMediaSession
  • allowsDirectInteraction
  • playsSound
  • updatesFrequently

The list of all iOS traits can he found here:
https://developer.apple.com/documentation/objectivec/nsobject/uiaccessibility/accessibility_traits

@blavalla
Copy link
Contributor

@kacieb , @nadiia , @lunaleaps , what are your thoughts on the missing iOS traits here? All iOS traits that are "element types" and fit into the model of "accessibilityRole" have already been added, but the ones missing are really more metadata about the element itself.

Since accessibilityRole only allows you to select one, these wouldn't make sense to include there, but they also don't really fit into the concept of accessibilityState like selected or disabled as they aren't really properties that are likely to change state due to user interaction.

I think there may be room for a new accessibility property that contains these traits and possibly others such as liveRegion, accessibilityIgnoresInvertColors, and accessibilityViewIsModal. The tricky part is many of these accessibility properties are platform specific.

Thoughts?

@kacieb
Copy link
Contributor

kacieb commented Mar 3, 2021

I think there may be room for a new accessibility property that contains these traits and possibly others

There's previously been some conversation about adding new accessibility properties in a sort of "backdoor" way - basically a way to directly overwrite iOS or Android (or other platform-specific) traits, to accommodate for missing things. I believe @appden has mentioned something like this before. I'd be curious to hear your thoughts on this.

For now I've added to the description that this one should have a proposal before implementation.

@misterchlee7
Copy link

Just wanted to confirm that accessibilityRole='text' is not being read in TalkBack. Currently using react-native 0.63.4

@blavalla
Copy link
Contributor

Just wanted to confirm that accessibilityRole='text' is not being read in TalkBack. Currently using react-native 0.63.4

Talkback doesn't have an equivalent of iOS's "StaticText" trait, which is what this role maps to on that platform, so there is no expected behavior when using this role on Android.

@misterchlee7
Copy link

Just wanted to confirm that accessibilityRole='text' is not being read in TalkBack. Currently using react-native 0.63.4

Talkback doesn't have an equivalent of iOS's "StaticText" trait, which is what this role maps to on that platform, so there is no expected behavior when using this role on Android.

Thanks for that knowledge @blavalla ! I'm looking through MDN and any documentations regarding ARIA but can't seem to find a straight answer but do you know if there is any sort of text-like equivalent for Android in that case? It seems like 'header' is the only one that comes closest but wanted to know if you knew

@blavalla
Copy link
Contributor

Just wanted to confirm that accessibilityRole='text' is not being read in TalkBack. Currently using react-native 0.63.4

Talkback doesn't have an equivalent of iOS's "StaticText" trait, which is what this role maps to on that platform, so there is no expected behavior when using this role on Android.

Thanks for that knowledge @blavalla ! I'm looking through MDN and any documentations regarding ARIA but can't seem to find a straight answer but do you know if there is any sort of text-like equivalent for Android in that case? It seems like 'header' is the only one that comes closest but wanted to know if you knew

There isn't really any equivalent on Android (at least with Talkback). Talkback basically treats elements without a defined role as "text" in this regard, but there is no special functionality related to these elements. Regardless of the elements role (button, checkbox, etc.), the basic text functionality of changing the readback granularity between letters, words, and all-at-once is available.

Androids TextView class does have a lot of accessibility specific behavior around things like text selection, copy/paste, and cursor control, but all of this is handled in the TextView class in Android (outside of Talkback), and can't be emulated by simply switching roles. Under the hood, react Native's component extends Androids AppCompatTextView class, which in turn extends TextView, giving all of this accessibility-specific functionality. If you are looking for the proper way to represent text on Android, I'd say using RN's is your best bet.

@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 4, 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 4, 2022
@facebook facebook locked as resolved and limited conversation to collaborators Feb 4, 2022
@blavalla blavalla reopened this Feb 4, 2022
@blavalla blavalla removed the Stale There has been a lack of activity on this issue and it may be closed soon. label Feb 4, 2022
@facebook facebook unlocked this conversation Apr 27, 2022
@fabOnReact
Copy link
Contributor

fabOnReact commented Aug 10, 2022

Example PR da899c0
Related PR #34267 #33180

@fabOnReact
Copy link
Contributor

datepicker and timepicker are deprecated

fabOnReact added a commit to fabOnReact/react-native that referenced this issue Aug 24, 2022
@fabOnReact fabOnReact self-assigned this Aug 25, 2022
OlimpiaZurek pushed a commit to OlimpiaZurek/react-native that referenced this issue May 22, 2023
…34477)

Summary:
- adds missing roles
- adds custom roles that don't exist in TalkBack (see the [compositor.json][10] and [string.xml][11] files).
- fixes [issues with Drawer][12]
- fixes issues with ScrollView missing roles
- seek control already exist as adjustable facebook@d460d09

Relevant facebook#30839 (comment)
fixes facebook#30839

## Changelog

[Android] [Fixed]  - Adding pager, scrollview, viewgroup, webview, drawer roles

Pull Request resolved: facebook#34477

Test Plan:
Android
- Drawer Layout and ScrollView (02/09/22) facebook#34477 (comment)
- sliding drawer, drawer layout, icon menu facebook#34477 (comment)
- Horizontal and Vertical ScrollView facebook#34477 (comment)
- Toast facebook#34477 (comment)
- CheckedTextView facebook#34477 (comment)
- Spinner (dropdownlist) facebook#34477 (comment)
- EditText facebook#34477 (comment)
- WebView facebook#34477 (comment)
- Testing chime_up and chime_down sound feedback in Scrollable facebook#34477 (comment)

iOS facebook#34477 (comment)

[10]: https://github.com/google/talkback/blob/771de7cdbf55b6adb4ca4c64c27a52584f2337cc/compositor/src/main/res/raw/compositor.json#L1082-L1108
[11]: https://github.com/google/talkback/blob/771de7cdbf55b6adb4ca4c64c27a52584f2337cc/compositor/src/main/res/values/strings.xml#L223
[12]: facebook#34477 (comment)

Reviewed By: NickGerleman

Differential Revision: D39894307

Pulled By: blavalla

fbshipit-source-id: 4a8da78bae485ead0523689631d88d1031a07b74
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants