Proposal: Interactive Lists
This article tries to consolidate in one place all the thoughts about interactive lists and to propose some new roles as a possible solution.
The text is based in first place on the issues and comments of Sarah Higley and Stefan Schnabel but of course also on the results of group discussions in the ARIA WG.
In the current state of ARIA different objects that contain and display more than one textual value can only be presented in tabular form, i.e. in the gridcells of a grid. For simple values there is an ARIA equivalent for the HTML select element - the role listbox with its child role option.
The basic idea would be that interactive lists are to static lists as grids are to tables -- they can still contain mixed and interactive content, but support managed focus between items. The punnett square of lists, interactive lists, grids, and tables could be visualized as follows:
| - | 1-dimensional | 2-dimensional |
|---|---|---|
| Static | List | Table |
| Interactive | Interactive List | Grid |
Right now, the listbox role is the closest web analog to a desktop interactive list. There are a couple reasons listboxes do not fill the need for the desktop-app-like interactive list pattern:
- Listboxes are primarily form selection controls, with browser-inferred default selection based on focus. It's impossible to have a listbox without selection.
- Listbox options do not support the same flexible content model that list items do
Interactive lists can contain a wide variety of objects, such as files, emails, messages, charts, other lists, etc. The problem that calls for a new role is the fact that these objects are often displayed in a non-grid view: as thumbnails, icons, maps, ... and the grid role is simply not suitable for presenting all of these views.
All of these objects can not only be selectable as list entry, but can also contain various simplier widgets such as buttons, text boxes, check boxes, etc. None of these is allowed in the option role, which makes listbox unsuitable for our purposes.
Furthermore, some listview items can contain further lists of objects, or the complete listview can be grouped according to one or more properties. This calls for the necessity to have a subclass tree-like listview - I would recommend the name treelistview.
Files can be arranged in different views for a better overview, preview of content or to expose different properties.
Unfortunately, Microsoft uses the same listview role in the AAPI for the grid view. In this view the listed objects reveal more than their name properties and the keyboard navigation corresponds exactly to the keyboard navigation in the ARIA grid role.
The functionalities covered by the finder are comparable to the ones offered by Microsoft's file explorer.
- The Teams app store, with multiple groups of "cards", where each card contains mixed content and each group of cards is a single tab stop.
- Office online welcome/recent files screen, with files displayed as cards
- A list of participants in a current meeting, where each participant has mutliple secondary actions but no single main action (or one single non-selection main action)
As an example for an online platform, in which objects can be arranged in different views, is the Fabasoft Cloud:
Currently Fabasoft uses the grid role for its detail view.
In the Fabasoft Cloud it is possible to group a list of objects according to one or more properties. In the details view we use the correct treegrid role. We also offer the possibility to change the list view to content or thumbnails. For these purposes ARIA does not offer a corresponding role.
Here you can see a grouped object list first in the thumbnails and then in the content view:
A composite widget containing a collection of zero or more list items (listviewitem) in which some or all items in the listview are focusable by using the proper navigational method, such as directional arrow keys. The correct navigational method is defined by the value of the aria-orientation property on the listview.
The listview role is a collection of objects of the same or different type. Each of these objects can be a simple widget or only one property of an object, such as the name of a file in a file list or the subject of a mail. In these cases, this simple widget is the only content of a listviewitem. In other cases, a listviewitem can consist of a composite role or one or more user interface elements, such as tiles collection for a dashboard.
To be keyboard accessible, authors SHOULD manage focus of descendants of a listview as described in Managing Focus.
When a user is navigating the listview content with a keyboard, authors SHOULD set focus as follows: • Authors MAY set focus on a single interactive widget in the listviewitem, if the interactive widget does not require any arrow key presses when it receives focus. Single interactive widget elements include for example a checkbox, button, or link. This allows the contained widget to be directly operable.
• Otherwise, authors SHOULD ensure the element that receives focus is a listviewitem itself.
Authors SHOULD provide a mechanism for changing to an interaction or edit mode that allows users to navigate and interact with content contained inside a focusable listviewitem if that listviewitem contains any of the following:
• a widget that requires arrow keys to operate, e.g. a combobox or radiogroup
• multiple interactive elements
• editable content
For example, the Enter key might be used to activate a listviewitem interaction or editing mode when the element receives focus, so the directional arrow keys can be used to operate the contained textbox. Depending on the implementation, pressing Enter again, Tab, Escape, or another key may switch the application back to the listview navigation mode.
The key mapping used for navigating a listview depends on its view type. The author MUST set the proper keyboard navigation type by setting the appropriate value for the aria-orientation property of the listview.
If aria-readonly is set on an element with role listview, user agents MUST propagate the value to all listviewitem elements owned by the listview and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual listviewitem element. In a listview that provides item content editing functions, if the content of a focusable listviewitem element is not editable, authors MAY set aria-readonly to true on this element. However, the value of aria-readonly, whether specified for a listview or individual listviewitem, only indicates whether the content contained in items is editable. It does not represent availability of functions for navigating or manipulating the listview itself.
An unspecified value for aria-readonly does not imply that a listview** or a listviewitem contains editable content. For example, if a listview presents a collection of elements that are not editable, such as a collection of link elements, it is not necessary for the author to specify a value for aria-readonly.
Authors MAY indicate that a focusable listviewitem is selectable as the object of an action with the aria-selected attribute. If the listview allows multiple listviewitems to be selected, the author SHOULD set aria-multiselectable to true on the element with role listview. Since WAI-ARIA can augment an element of the host language, a listview can reuse the elements and attributes of a native unordered list, such as an HTML ul element. For example, if an author applies the listview role to an HTML ul element, the author does not need to apply the listviewitem roles to the descendant HTML li elements because the user agent will automatically make the appropriate translations.
| Characteristic | Value |
|---|---|
| Superclass Role: | ? |
| Subclass Role: | treeliestview |
| Base Concept: | ul in HTML? |
| Allowed Accessibility Child Role: | listviewitem |
| Supported States and Properties: | aria-multiselectable, aria-orientation, aria-readonly |
| Name From: | Author |
| Accessible Name Required: | true |
| Implicit Value for Role: | Default for aria-orientation is vertical. |
The aria-orientation property should be extended by a new value:
- aria-orientation="grid"
means: The entries that can be navigated by arrow keys are in grid style, but can be of different size and their arrangement is often a grid with some grid cells put together through rowspan and/or colspan. Some arrangement rows contain more, the other less entries. The same is valid for column arrangement. According to this fact, the arrow key navigation is based on visual estimation for the adjacent item positions.
An entry in a listview or treelistview.
A listviewitem may be focusable, editable, and selectable. A listviewitem may have relationships such as aria-controls to address the application of functional relationships.
In a treelistview, authors MAY define a listviewitem as expandable by using the aria-expanded attribute.
| Characteristic | Value |
|---|---|
| Superclass Role: | ? |
| Base Concept: | li element in HTML |
| Required Context Roles: | listview, treelistview |
| Supported States and Properties: | aria-disabled, aria-errormessage, aria-expanded, aria-haspopup, aria-invalid, aria-readonly, aria-selected |
| Name From: | contents, author |
A listview whose listviewitems can be expanded and collapsed in the same manner like a tree.
If aria-readonly is set on an element with role treelistview, user agents MUST propagate the value to all listviewitem elements owned by the treelistview and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual listviewitem element.
When the aria-readonly attribute is applied to a focusable listviewitem, it indicates whether the content contained in the listviewitem is editable. The aria-readonly attribute does not represent availability of functions for navigating or manipulating the treelistview itself.
In a treelistview that provides content editing functions, if the content of a focusable listviewitem element is not editable, authors MAY set aria-readonly to true on the listviewitem element. However, if a treelistview presents a collection of elements that do not support aria-readonly, such as a collection of link elements, it is not necessary for the author to specify a value for aria-readonly.
To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.
| Characteristic | Value |
|---|---|
| Superclass Role: | listview, tree |
| Allowed Accessibility Child Role: | listviewitem |
| Supported States and Properties: | aria-multiselectable, aria-orientation, aria-readonly |
| Name From: | author |
| Accessible Name Required: | true |
| Implicit Value for Role: | Default for aria-orientation is vertical. |
The aria-orientation property should be extended by a new value:
- aria-orientation="grid"
means: The entries that can be navigated by arrow keys are in grid style, but can be of different size and their arrangement is often a grid with some grid cells put together through rowspan and/or colspan. Some arrangement rows contain more, the other less entries. The same is valid for column arrangement. According to this fact, the arrow key navigation is based on visual estimation for the adjacent item positions.
- Keyboard definition for the listview and treelistview in different view types (values of the aria-orientation). (note: we don't really have this figured out for grid either).
- Determine all platform mappings. Control type for listview exists on Windows, macOS, iOS, Android, ... Check the others.
- Interactive lists have to support selection. If so, how do we differentiate from listbox?
- Insertion into CORE-AAM
- Browser implementation
- APG examples
- WPT tests
This article is based on the following issues and discussions: