VirtualList 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"

Open questions

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.

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

• [x] 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 :)