The web needs interactive lists | Sarah Higley

One of the priciples of creating new web platform features is "pave the cowpaths" -- figure out what cursèd UI developers and designers are already creating with third party HTML/CSS/JS, and brainstorm how to pull it into the web platform. Maybe with an exorcism or two to fix any particularly egregious accessibility problems.
When the same principle is applied to web accessibility specs, it generally means ensuring any widely used UI patterns can be marked up with an appropriate semantic pattern (i.e. roles and aria-* attributes) and documented interaction patterns that are understandable and operable across different devices, user settings, color modes, zoom levels, and assistive tech. Whether web developers actually do any of that is an entirely separate problem, but it should at least be possible.
Developers and designers will always create new innovative ways to be weird and inaccessible in their UI (intense side-eye at stuffing tabs and tables into comboboxes), and spec authors will always struggle to decide how far to support the chaos. However, every once in a while developers and designers create a perfectly normal, understandable, and theoretically accessible UI pattern that for whatever reason is not supported on the web.
One of those patterns is an interactive list.
One way to think of an interactive list is as the one-dimensional version of a data grid. Just as a data grid is the interactive version of a table (i.e. <table> or role="table"), an interactive list would be the interactive version of a static list (i.e. <ul>, <ol>, or role="list").
An interactive list, like a data grid, would be a single tab stop composite widget, where arrowing between list items would be expected. As such, it would more commonly be useful within interfaces that lean more towards web applications than content-focused websites.
Here are a few more concrete examples of UI where an interactive list role could benefit accessibility:
Normally navigation should be a simple, tabbable set of links, often in a static list. However in environments that function more like traditional desktop applications than websites (think email inboxes or Powerpoint online), it can be beneficial to have navigation be a single tab stop.
A tablist can sometimes be appropriate here, but an interactive list with child links would allow users to both arrow through items and also keep highly beneficial link functionality (e.g. using a screen reader's links dialog from anywhere in the app). Tablists also do not support static content like section/group headers, which often exists in navigation regions.
Multi-level navigation in apps like email inboxes sometimes use a tree, but nested lists of links can offer a significantly lower learning curve than a tree along with preserving virtual cursor access and use of the links dialog.
Pagination is another navigation-like component that would be a good interactive list use case, especially when there can be a large number of pages. If linking to a specific page is possible, then it could be an interactive list with nested buttons. If not, then no nested interactives would be needed.
h/t to Sylvia Villegas for bringing up pagination as a use case.
In this case, each individual chat message is usually not interactive in the sense that they do not have a single primary action and are not selectable. However, users should not need to tab through all content in a chat pane in order to reach the chat input. Most chat applications also allow users to arrow (and often use page down/page up to skip) through past messages.
Yes, everyone knows you shouldn't use a carousel. However, they continue to be built, and sometimes as in the case of streaming services, have become somewhat standard. Especially in UIs like this one from Netflix where there are many carousels in succession, users should be able to quickly tab to their desired category and then arrow through each item in that carousel.
The interactive list role wouldn't be appropriate for all carousels -- only ones similar to the pictured streaming service categories or other product carousels where each item has a primary action, and the context calls for arrowing between items. As with most accessibility choices, there is no one-size-fits-all.
This applies not just to lists of files, but any other list of items where each item does one primary action. While listbox is a tempting role to reach for here, it is not ideal for several reasons: it enforces a selected state on options, it does not robustly support virtual cursor navigation of options, and it does not support having a non-selection primary action.
Windows, macOS, iOS, and Android all have native versions of an interactive list, which matters for two reasons: assistive tech users are already familiar with the paradigm and wouldn't need to learn anything new, and from a technical/spec perspective, accessibility API mappings already exist.
Native platforms already providing this UX pattern is also compelling evidence that there are valid use cases for interactive lists.
There are three places to reference when determining semantic requirements for interactive lists:
At the most basic level, it should be possible to create a horizontal or vertical arrow-navigable set of interactive items that do some general action when pressed. This alone would be enough to create the Netflix-style carousel example from earlier.
We can also come up with a few more requirements just from referencing the examples above:
In addition to the specific requirements above, basic features of both static lists and typical composite widgets should also be supported, such as:
ARIA already has a number of one-dimensional composite widget roles, but no combination of them can cover all the existing common use cases for interactive lists. Even in cases where you can hack together something with existing roles, there are shortcomings.
The existing somewhat list-like linear composite widget roles are: listbox, menu/