fix: update picker item and picker list roles

[KingOfTac]

🐛 Bug Report

With Picker presenting a list of selectable items selected using aria-selected, the roles for the picker list and the options should be listbox and option rather than list and listitem respectively.

💻 Repro or Code Sample

🤔 Expected Behavior

The roles for the list and items should use appropriate roles for using aria-selected

😯 Current Behavior

The current roles used are list and listitem which tend to be more appropriate for static lists.

💁 Possible Solution

The roles that should be used are listbox and option.

🔦 Context

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-selected

🌍 Your Environment

• OS & Device: [e.g. MacOS, iOS, Windows, Linux] on [iPhone 7, PC]
• Browser [e.g. Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox]
• Version [e.g. 1.8.0]

[scomea]

This would be just the flyout list and not the "selected items" list?

[KingOfTac]

This would be just the flyout list and not the "selected items" list?

I believe any lists and items that are using aria-selected should have their roles updated to listbox and option. Pinging @chrisdholt and @radium-v to maybe clarify but based on what I have read on the different roles on MDN and ARIA-APG, this is the approach we should use.

[scomea]

I believe any lists and items that are using aria-selected should have their roles updated to listbox and option.

The selected items list does not currently use "aria-selected" if that's the criteria.

[chrisdholt]

This would be just the flyout list and not the "selected items" list?

I believe any lists and items that are using aria-selected should have their roles updated to listbox and option. Pinging @chrisdholt and @radium-v to maybe clarify but based on what I have read on the different roles on MDN and ARIA-APG, this is the approach we should use.

What is the accessible role for the element itself?

[KingOfTac]

What is the accessible role for the element itself?

The Picker itself doesn't have a role explicitly mapped to it.

[scomea]

The Picker itself doesn't have a role explicitly mapped to it. Picker wraps a list (can be described by setting aria attributes on the top-level component) which contains selected list items, and is followed in the tab order by a combobox that has the flyout with options. The combobox is currently a child of the 'list' which probably isn't ideal.

[scomea]

I don't think option/listbox works for the base list of already selected items because those items aren't technically "a list from which a user may select one or more static items". I looked at outlook to see what they do with mail recipients in an e-mail which is essentially the kind of interaction picker is designed for and they use a "textbox" role wrapping "buttons" for the individual recipients. That seems odd to me but if it works better than a list with list-items that could be the solution.

I note that list-item supports "aria-shortcuts" which implies they can be interacted with as is the case in picker's list where the focused item can be deleted.

[scomea]

Note - we could quickly merge a fix which addresses the roles in the flyout menu, which clearly should be "listbox/option" and continue discussing how to handle roles in the selected items list.

[scomea]

I'm wondering if those roles shouldn't be configurable by authors. Maybe in some scenarios picker is being used to edit something that is contextually a "textbox" and in other cases a "list"?

[janechu]

Unfortunately @microsoft/fast-foundation is being deprecated, refer to #6955. I see this was mentioned in a PR, we will be addressing open PRs and merging what we can before we snap an archive branch to preserve the latest state of Foundation, however to bring us up to date I am closing out issues.