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

Proposal to add accessibility APIs for lists #146

Open
wants to merge 7 commits into
base: master
from

Conversation

@harinikmsft
Copy link

harinikmsft commented Jul 17, 2019

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.

harinikmsft added 5 commits Jun 12, 2019
Proposal for accessibility APIs for lists
Copy link

necolas left a comment

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

proposals/0000-accessibilityapis-lists.md Outdated Show resolved Hide resolved
@blavalla

This comment has been minimized.

Copy link

blavalla commented Jul 18, 2019

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

This comment has been minimized.

Copy link

necolas commented Jul 22, 2019

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?


FlatList, SectionList, VirtualizedList components will have `accessibilityRole = list` set by default.

### P2 APIs:
The following new properties will be introduced to customize and describe details of the list/list items:
- **accessibilitySetSize**
- **accessibilityPosInSet**
- **accessibilitysetsize**

This comment has been minimized.

Copy link
@necolas

necolas Jul 22, 2019

As props these would still be camelcase: accessibilitySetSize

Reverting the update to change camel casing in the props and making edits in the example code to reflect the change to "lisitem" role.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.