Not all Standard Roles/Traits supported

[amarlette]

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]

@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]

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.