Proposal to add accessibility APIs for lists

[harinikmsft]

This proposal adds new accessibility roles for supporting lists as well as new APIs for describing size of lists,nth item in the list etc.,

This addresses Issues 2578 and 2579 from react-native-windows. An initial implementation of the same in react-native-windows can be tracked through this PR.

We would like to bring this to react-native as it benefits all cross-platform apps.

[necolas]

LGTM. Just a nit about not camel-casing values of accessibilityRole

[blavalla]

While this is a good idea, there are some caveats as to how it could be implemented on iOS and Android.

I think it would be useful to know if the idea here was to allow non-lists to be treated like lists, or if the idea here is to polyfill aria behavior (such as adding pos-in-set) to native platforms? I think making non-lists act like lists should be doable, and would be a good addition, but polyfilling aria behavior will be problematic as this goes against the way that native platforms like iOS and Android function by default.

On Android the only list functionality built into Talkback is the announcement of all on-screen elements in the list (e.g. "Items 5-10 of 20") upon first focus into the list. It specifically does not make additional announcements on each focus change, and does not announce the index of the focused element. This behavior was a conscious choice made by Google, and not a consequence of the API not providing enough information. These announcements are also user configurable, and users can choose to turn them off if they choose.

On Android we can easily make non-list elements provide this same information to Talkback and be treated like lists by the system (including not making these announcements if a user disables this functionality), but any added functionality beyond this will be going against the platform norms, and will not be able to be disabled by users.

On iOS it's a similar story, where by default VoiceOver computes how many "pages" a list has, and announces what page you are on, but not which specific element in that list. It announces this information when you do the next/previous page gesture on a list. We can override the exact number of pages, and which page you are on, but not easily change when/how this announcement happens. It is possible to make a non-list act this way, but is considerably more work than on Android (@ikenwoo can speak to the specifics here).

[necolas]

The roles of heading and listitem can also make use of aria-level. As with many other ARIA attributes, the aria-level attribute only works with a limited subset of ARIA roles. We can keep adding new accessibility* props, and leave developers to piece how everything fits together even though a lot of prop combinations don't have any effect together. This is one of the downsides of ARIA too.

I've been thinking about how we might be able to incorporate and enforce the inter-relationships by default. This could help us prevent anti-pattern combinations of attributes as well as type the system. For example, what if accessibilityRole could also be an array [ role, { level, posInSet, setSize } ]. While keeping in mind which values can change frequently and would be better off not creating new objects each render. Any thoughts from Microsoft's side?

[necolas]

As props these would still be camelcase: accessibilitySetSize

[TheSavior]

That is this repo, isn't it? 😀