[RFC] Improve accessibility via support for composite widgets

[ryancogswell]

This is a continuation of the discussion started by @mbrookes in #15334 and #15421. I have not yet made any attempts at an implementation, but I wanted to go ahead and document my thoughts about the problem space.

What is a composite widget?

WAI-ARIA describes a composite widget as having the following characteristics:

• Always contains multiple focusable elements.
• Only one of the focusable elements contained by the widget is included in the page tab sequence.
• Requires the author to provide code that manages focus movement inside it.

What are examples of composite widgets?

WAI-ARIA describes the following design patterns and widgets as composite widgets:

• Combo Box: https://www.w3.org/TR/wai-aria-practices/#combobox
• Grids: https://www.w3.org/TR/wai-aria-practices/#grid
• Listbox: https://www.w3.org/TR/wai-aria-practices/#Listbox
• Menus: https://www.w3.org/TR/wai-aria-practices/#menu
• Radio Group: https://www.w3.org/TR/wai-aria-practices/#radiobutton
• Tabs: https://www.w3.org/TR/wai-aria-practices/#tabpanel
• Toolbar: https://www.w3.org/TR/wai-aria-practices/#toolbar
• Tree View: https://www.w3.org/TR/wai-aria-practices/#TreeView
• Treegrid: https://www.w3.org/TR/wai-aria-practices/#treegrid

What is the accessibility benefit of composite widgets?

Composite widgets allow keyboard users to navigate quickly between different interactive portions of the page. tab and shift+tab can be used to skip between different composite widgets and to any focusable elements that are not part of a composite, and then the arrow keys can be used to navigate within a composite widget.

What is the current state of support for composite widgets in Material-UI?

The following widgets are already treated as composites in their Material-UI counterparts:

• Combo Box: https://material-ui.com/demos/autocomplete/
• Listbox: https://material-ui.com/demos/selects/
• Menus: https://material-ui.com/demos/menus/
• Radio Group: https://material-ui.com/demos/selection-controls/#radio-buttons

The following widgets have a Material-UI counterpart that is not treated as a composite widget (i.e. tab navigates within these widgets rather than skipping to the next focusable element outside the widget):

• Grids: https://material-ui.com/demos/lists/
• Tabs: https://material-ui.com/demos/tabs/
• Toolbar: https://material-ui.com/demos/app-bar/

The Tree View and Treegrid patterns do not currently have any direct Material-UI counterpart, however nested Lists can be used to create tree widgets. The Grid pattern can also be implemented in Material-UI using components other than Lists, for instance a grouping of Cards could be considered a WAI-ARIA Grid. If each Card has multiple focusable elements, then each Card in a group of Cards would represent a row in the grid.

What should be done to improve support for composite widgets in Material-UI?

Adding composite widget support for Lists

In the pull requests by @mbrookes that preceded this issue, the main idea was to move the keyboard focus navigation from MenuList down into List so that the focus logic could be used more broadly. While I think something along these lines is possible, there are a number of challenges to address:

• In order for a composite widget to add benefit, it is not enough to simply add arrow key navigation. It is also necessary to remove all focusable elements within the composite widget from the tab sequence by specifying a tabindex of -1, so that tab and shift+tab can be used reliably to skip out of the composite widget.
• The current MenuList focus navigation assumes that the focusable elements are all direct children of the list. Lists, however, can have a much more varied structure including secondary actions and nested lists. Any solution for treating Lists as composite widgets should handle secondary actions, and ideally support nested lists as well.
• The accessibility benefits of composite widgets are most important for long lists, so virtualized lists should be supported as well (though potentially with a more complex DX than for regular lists). It may not be practical to try to support text navigation for virtualized lists, but the solution should have an approach for handling home and end within a virtualized list. I wouldn't expect the arrow keys to pose any special difficulties with virtualized lists.
• For Lists, it will be important to support a roving tabindex: https://www.w3.org/TR/wai-aria-practices/#kbd_roving_tabindex. This concept was recently removed from MenuList as part of improving performance. In MenuList it added very little value since tab generally closes the Menu, so there is no reason to retain where the focus was. For composite widgets that persist on the page, the roving tabindex is much more important. If a user tabs out of the composite widget and then uses shift+tab, they should return to the same point in the composite widget. In order to avoid the performance issues that the roving tabindex caused within MenuList, it is important to manage this without leveraging state in the parent. Focus navigation should not cause re-rendering of the List; at most only the two list items involved in the focus change should be re-rendered. This means that changing of the tabindex (such that the current focus element in the composite has a tabindex of zero) should be done via the DOM property rather than via the attribute.

Adding composite widget support for other components

I think it would be worthwhile to consider other scenarios (e.g. group of Cards, AppBar, Tabs) at the same time to explore which implementation aspects might make sense to be shared and to work towards a more general solution for composite widgets, but I'm not sure if a general solution will actually make sense in the end.

[mbrookes]

@ryancogswell Absolutely fantastic write-up! Thanks for taking the time to put it together.

[oliviertassinari]

It's related to #6955.

[ryancogswell]

Absolutely fantastic write-up! Thanks for taking the time to put it together.

@mbrookes Thanks! It was rather time-consuming for me, largely due to continually finding that I needed to do more reading. I was pretty ignorant about a lot of these accessibility resources prior to working on Material-UI.

Now to get into some of the implementation details...

Key design decisions for composite widget support for Lists

1. How should the focusable elements within the composite widget be identified?
2. What should the mechanism be for removing the focusable elements from the tab sequence?
3. Should composite widget behavior be the default for Lists or opt-in?

How should the focusable elements within the composite widget be identified?

I think the heuristic currently in MenuList is probably still sufficient: elements with an explicit tabindex attribute that are not disabled. Any elements that are inherently focusable will need to have an explicit tabindex of -1 added to them to remove them from the tab sequence, so that should then make them identifiable via this heuristic. The main difference to the current MenuList implementation would be to no longer limit this to the immediate children of the List.

What should the mechanism be for removing the focusable elements from the tab sequence?

This is the messiest part of the solution. We can probably leverage Context in some fashion to detect when we should add the tabIndex={-1} to the main Material-UI elements we expect to occur within lists (e.g. ButtonBase and Checkbox), but it is difficult to know what all elements will be used within lists. We can document the need to add tabIndex={-1} to any focusable elements for which the library doesn't take care of this (which would include any non-Material-UI focusable element), but it will be a rather error-prone area for less-standard lists. I'm interested in hearing any different ideas about how to manage this aspect.

Should composite widget behavior be the default for Lists or opt-in?

Given the messiness involved in reliably removing focusable elements from the tab sequence, I don't think this should be default behavior. If some elements within list items remain part of the tab sequence while some are removed, the result would be worse than the current behavior where everything is in the tab sequence. Perhaps we could consider making it the default in v5 after we have learned some lessons and addressed issues.

[oliviertassinari]

@ryancogswell The more I think about this composite widget, the more I realize it's a hard problem! You know how to pick your fights! You might want to review the implementation tradeoffs of Rover by @diegohaz. I'm wondering if the React hasn't started an effort on it. I know they have an upcoming focus scope component, to verify.

I'm excited about the implication for our Tab component, the upcoming Tree view and the idea we can share the same logic with the Menu and potentially the different autocomplete components. This demo looks pretty messy to get right: https://www.w3.org/TR/wai-aria-practices/examples/treeview/treeview-1/treeview-1a.html. There is a dimensionality issue to handle at the same time (up / down / right / left). The logic might be even more complex for supporting nested menu where the nodes are portal, so not under the same host node.

1.

I'm happy to reuse the same method. It has yet to be proven suboptimal.

2.

Yes, it's a hard problem! Did you consider doing it without involving React? Would the following logic works:

• We add a tabIndex={-1} to all the elements we want to include in the composite widget.
• The keyboard interactions change the tab index attributes without hitting React cycles.
• People can use the autoFocus prop to programmatically change the active item.
• We use the DOM hierarchy to handle left and right arrow keys. It would be useful for the Tree View (child/parent relation) or the nested menu (portal siblings).

Now, I believe we can't use such logic to build a combobox (should we even consider it?) as the focus needs to stay on the input. The keyboard interaction and selected states are simulated. I imagine it's not that much an issue, we could create an abstraction for the core logic and have an adapter that either interact with the DOM or rerender in a Reacy lifecycle.

3.

I would prefer to have it opt-in. It's not obvious to me when a list should be considered composite or when it shouldn't. In doubt, I would keep the default browser behavior.

[ryancogswell]

Did you consider doing it without involving React?

@oliviertassinari Yes, I have in mind something similar to what you laid out. tabIndex={-1} would be managed in React, but the actual focus navigation and the roving tabindex would just happen in the DOM (probably with the help of a ref or two). I'm picturing leveraging listItemElement.querySelectorAll('[tabindex]') to find the nodes in the DOM to include in the navigation.

I'm not sure how soon I'll actually work on this. Dropdowns are the higher priority for me (and I would assume for Material-UI as well). We actually just added some functionality to our app that would definitely be a little nicer as a dropdown. The composite widget support is a nice accessibility feature, but most people probably won't realize that they should be doing this until we add documentation about it. I'll probably mainly use it as a filler task if I have time while waiting for code review for the popup/dropdown tasks.

[mbrookes]

@oliviertassinari

it's not obvious to me when a list should be considered composite or when it shouldn't.

Could you give an example of when it shouldn't?

[ryancogswell]

Could you give an example of when it shouldn't?

I agree with @mbrookes's implied point, that all lists probably should be treated as composites. I just think it needs to be opt-in because for some lists it will require work by users to ensure that all the focusable elements are removed from the tab sequence. Once this capability reaches maturity, it should be a pretty small percentage of lists that need additional work by users, so as long as we provide sufficient guidance in the migration guide for v5, it may make sense to switch to opt-out at that point.

@oliviertassinari As far as proving out this functionality, my plan is for most of the List demos to use it, and I would also convert the left-side navigation for the docs to use it. I think the docs navigation will be a particularly good use case for demonstrating the benefits of this enhancement.

[oliviertassinari]

@mbrookes @ryancogswell I don't have a strong opinion on this. I'm not sure I understand all the implications. What happens for somebody displaying data with a list (ul > li > div), considering it has nested focusable link elements inside each list item?

Dropdowns are the higher priority for me (and I would assume for Material-UI as well)

I agree.

[ryancogswell]

What happens for somebody displaying data with a list (ul > li > div), considering it has nested focusable link elements inside each list item?

There are quite a few complex possible scenarios. The most complex involve editable content. The ARIA documentation provides guidance for toggling between grid navigation vs. editing here, but I won't even try to handle that in the initial implementation. Whether we can consider switching to opt-out in the future depends on how mature this is at that point and how rare the scenarios are that aren't handled well.

[oliviertassinari]

Is there something left to do on this issue?