VirtualList selection API and list/listbox semantics

[rolfsmeds]

Description

VirtualList items can be (single or multi) selected similarly to those in ListBox or Grid, and provide appropriate ARIA semantics.

Acceptance criteria

• API for setting enabling/disabling selection, and choosing between single or multi-select
• API for getting and setting the selected item(s)
• Selection event APIs
• VirtualList must be focusable (in order to satisfy ARIA for role="listbox") (actual focus is delegated to the first item in the list)
• An aria-label provider function API may be needed to provide an explicit accessible name to complex list items that may otherwise get an awkwardly long and complex name based on their text contents.
• Selection interactions (when selection is enabled)
  • Pointer: By default, items are selected and deslected by clicking them.
  • Keyboard: up/down arrow keys move between items, space selects/deselects.
• ARIA semantics:
  • VirtualList needs an aria-label(ledby) API in order to provide an accessible name
  • When selection is disabled, VirtualList has ARIA role="list" and item wrappers have role="listitem"
  • When selection is enabled, VirtualList has ARIA role="listbox" and item wrappers have role="option" and aria-selected (set to false by default)
  • Multi-selection is indicated with aria-multiselectable="true"
  • Selected item wrappers have aria-selected="true"

Possible later enhancement

• An API enables developers to switch the component to "grid mode" in which
  • VirtualList has ARIA role="grid" and item wrappers have role="row"
  • Up/down arrow keys navigate between rows, left/right arrow keys navigate between elements with role="gridcell"
  • There is no automatic selection mechanism with space/enter
  • It is up to the developer to structure the contents of each item according to ARIA grid semantics, i.e.
    • Wrapping each distinct element (text, interactive elements) in a role="gridcell" or role="rowheader"
    • Providing a selection toggle on each selectable list item and updating the component's selection programmatically

Open questions

Is listbox role appropriate?

Is the `listbox` ARIA role the best choice for selectable lists? The main caveat with it is that the list items (which then have `role="option"`) are announced as plain text (essentially a concatenation of their text content), and don't expose the presence of interactive or semantically meaningful elements inside them to screen readers. (Interactive elements in them can still be used by tabbing focus to them, but their discoverability and relation to the item itself may be challenge for non-sighted users.)

An alternative would be to use the grid role instead, which provides a more suitable accessibility model for selectable items with interactive content. Downsides to this are e.g.

• More complex accessibility model that in many cases will be completely unnecessary;
• Each interactive element must be wrapped in its own cell, somehow, to reap the benefits;
• Sighted keyboard users may end up confused by the interaction model required by the grid role;
• Feels like a misuse of the grid role.

Should the list root have role="feed"?

Maybe the root should have [`role="feed"`](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/feed_role) to help ATs parse and announce it as an inifinite-scrolling container? (If so, it seems it can't be a list at all – instead, items should be `role="article"`)

Comments welcome.

General criteria

• APIs reviewed

• Design

• Performance

• UX/DX tests in Alpha

• Documentation: to be added to https://vaadin.com/docs/latest/components/virtual-list

• How to test?

• Limitations:

Security

• Security implications have been taken into account (elaborate or link to product security requirement specification if there are implications)

[knoobie]

Open question

Did you check out GitHubs Issue list for a repo with administration rights? This looks intriguing like your vision. Might be worth to check out - I would hope they have added great care about a11y as well. (Haven't checked the mark-up myself... Currently on mobile)

[rolfsmeds]

Hey @knoobie, I checked it out and... it's a bunch of plan divs?

As for the listbox/grid dilemma, I think we might go with listbox as default when selection is enabled, but provide an API for switching to grid for use cases with lots of interactive/semantically meaningful content in the items.

[knoobie]

it's a bunch of plan divs?

Oh.. that's sad to hear 🙁

[knoobie]

Looks like I got trapped into believing this blog post from months ago is already in motion. https://github.blog/engineering/user-experience/how-were-building-more-inclusive-and-accessible-components-at-github/ Using listbox might be the best option to begin with - better than a huge amount of divs :)

[rolfsmeds]

@knoobie do you have any experience with role="feed"? (See paragraph I added to the Open Questions section above.)

[knoobie]

I've heard about it.. even tho it's "old-ish".. just checking https://www.digitala11y.com/ok-aria-rolefeed-is-here-its-not-ready-for-prime-time/ and https://www.w3.org/WAI/ARIA/apg/patterns/feed/examples/feed/ (+ the linked issue).. it looks like it's still too "fresh" and not really adopted in the wild