New roles listview and listviewitem needed

[stes-acc]

In ARIA we have currently roles for

1-dimensional Lists

• Non-interactive Lists (structure): (Hierarchical) list + listitem
• Interactive Lists (widget): listbox + option, (Hierarchical) tree + treeitem, menu + menuitem

2-dimensional Lists

• Non-Interactive Tables (structure): (Hierarchical) table + cell
• Interactive Tables (widget): grid + gridcell, (Hierarchical) treegrid + gridcell

What we don't have (and this is a severe gap) is are Interactive Table-like Lists represented by roles who allow for item grouping with items organized in rows with cells of individual items referenced by special separate headers.

Those remain lists and not tables for an entire row represents a single item. As an example, the Microsoft ListView control centrally used in Windows Explorer has display modes who exactly reflect this.

This an established pattern many developers try to mimic using grids or tables but these are NOT the exact pattern to do this because of the following reasons:

• In a List view, an entire row IS the item object with properties exposed as different configurable additional labelled subitems organized in columns
• Arrowing up and down will always move to a different object by focusing the entire row and selecting the item by default
• Arrowing left and right in rows will ALWAYS scrutinize individual row/object properties by focusing respective individual subitems (cells) in the row
• Single/Multiselection ALWAYS works on entire row level NOT for individual subitems, as opposite to grid
• Actions like Enter or double click ALWAYS work by default on entire row level NOT for individual subitems as opposite to grid
• You can do grouping (similar to optgroups in HTML select) to group items by certain categories
• There are other item visualizations possible to be switched to on the fly (like MS ListView item thumbnail view as a flat list where the row objects are presented as single list items), try this with a table or grid role without sudden role change - not possible

The list could easily be extended but you get the general idea.

As consequence, new roles, listview = the entity, listviewheader = the (column) headers, listviewitem = the row with respective property subitems of role textbox etc. labelled by the listviewheader would close this gap.

Roles could be derived from base roles ARIA already has. In addition, API mapping schemes for ListViews are already present in many OS so the role mapping needs not to be re-invented. For instance, in UIA, MS Listview list and items are mapped to respective platform roles, whereas the grid and gridcell role mapping is entirely different (DataGrid, DataItem). The MS Listview subitems are also mapped to standard roles like textbox labelled by their headers, as proposed above.

[JAWS-test]

That sounds good on the one hand, because I know many corresponding implementations in web and desktop applications. On the other hand, they all have the disadvantage that usually the whole list entry serves as a label for a row (sometimes together with the column headers). This leads to a very long output in the screen reader. Often it is not even possible to navigate on cell level, so that the visual table structure is not perceptible with screen reader. I do not know how to fix this problem.

By the way, the ARIA treegrid example (Mode "Rows are focused first, but cells can be focused") is very similar to the described function of a ListView

[mcking65]

@stes-acc

If you break this down and look at what would be required for authors to implement the listview, it would precisely match a grid where the rows are focusable in addition to the cells being focusable. And, if you consider what would be needed for screen readers to support listview use cases, it also exactly matches what is needed to make such a grid work well for users.

Hmm, and it seems like the gmail inbox has done something very close to this. It is worth exploring the possibilities for making that work even better.

I bet it would be relatively straightforward to enhance the grid pattern in APG to accommodate the listview use case. After implementing and then developing screen reader tests in aria-at, we would have the data we need to close any remaining gaps.

[aleventhal]

The Chrome location bar and Google search are an examples of having interactive list items with occasional buttons. However, it's also the popup list for an autocomplete. These are the suggestions, and they have buttons like "Remove suggestion" or "Open in existing tab"

The user has to navigate to them with tab, because right arrow is currently taken up by the edit box that they're helping to autocomplete.

[jnurthen]

@stes-acc would aria-actions cover this too? #1440

[stes-acc]

@stes-acc would aria-actions cover this too? #1440

There is an intersection in the topics but it also affects grid role with selectable rows as en entity representing an Object with attributes.