[List] Add keyboard navigation

[mbrookes]

Discussion draft - applies the same logic to List as currently used in MenuList.

Not resolved:

• Sublist navigation
• Sibling list navigation

(Not that MenuList currently supports these either.)

[oliviertassinari]

@mbrookes Why should a list have keyboard support? Is the tab the correct way to navigate within a list (ul / li)?

[mbrookes]

You might be right.

I was applying the principals described here:

"A primary keyboard navigation convention common across all platforms is that the tab and shift+tab keys move focus from one UI component to another while other keys, primarily the arrow keys, move focus inside of components that include multiple focusable elements."

And in 5.6 Keyboard Navigation Inside Components
"As described in section § 5.1 Fundamental Keyboard Navigation Conventions, the tab sequence should include only one focusable element of a composite UI component. Once a composite contains focus, keys other than Tab and Shift + Tab enable the user to move focus among its focusable elements."

This allows skipping past the nav with a single Tab, and has the added benefit that the active list-item (if any) can receive focus when tabbing onto the list. (See: 5.6.1 Managing Focus Within Components Using a Roving tabindex).

The question then is, should a nav be a composite component? It certainly seems better for accessibility, and yet that very page does not treat its TOC as a composite component...

[mbrookes]

Benchmarking:

https://material-components.github.io/material-components-web-catalog/#/component/list - composite
https://material.angular.io/components/list/overview#selection-lists - composite
https://ant.design/components/list/ - broken (no keyboard support of any kind)
https://vuetifyjs.com/en/components/lists - broken (only the list with checkboxes supports keyboard navigation)
https://getbootstrap.com/docs/4.3/components/list-group/#links-and-buttons - not composite

Others?

[oliviertassinari]

Thank you for sharing relevant sections of the accessibility guidelines.

Common examples of UI components that contain multiple focusable elements are radio groups, tables, menus, and grids.

There is no mention to a ul>li structure as a popular candidate. I don't think that we should provide this feature to the list by default. Now, they mention the tab. It's something I was talking about with @nathanmarks a long time ago. Maybe we can abstract the menu focus logic, use it in the tabs and possibly make it public to be used somewhere else?

[mbrookes]

There is no mention [of] a ul>li structure

HTML lists aren't inherently navigable, so it's understandable that they're not mentioned. However, the use of an unordered list for semantic "correctness" in a composite list component that is navigable changes that.

[eps1lon]

I don't understand this either. A basic list should not be navigateable since the items don't have an associated action. It might make sense for a nav or a ToDo list but just listing things does not require keyboard navigation. It's just text in the end.

In other words: If the items are not focusable there's no need for keyboard navigation.

[oliviertassinari]

I still think that this change could help people. Take Gmail, their left side menu implements this behavior (Google keep and Google Contacts don't). It's also related to #15107.

[Pajn]

This behaviour is awesome if the list contains clickable elements, however how does the implementation handle lists without clickable elements. I don't see any special treatment for those?

[mbrookes]

@Pajn Please point me to an example in the spec of a non-interactive list item (other than a disabled list item, of course).

They are by definition "clickable":

They are composed of items containing primary and supplemental actions, which are represented by icons and text.

[eps1lon]

@Pajn Please point me to an example in the spec of a non-interactive list item (other than a disabled list item, of course).

I see we switched roles here 😉

But I did misjudge the implementation. If the list contains no interactive items then you won't get keyboard navigation anyway. So this is actually super nice behavior that emerges.

One issue is that it doesn't work for https://deploy-preview-15334--material-ui.netlify.com/demos/lists/#checkbox. Maybe due to the nested action item? Maybe just needs some adjustments in the demo.

[mbrookes]

I see we switched roles here

Well, you did at least 😉

One issue is that it doesn't work for [...] #checkbox

Good catch! I'll take a look and see if there's an easy fix.