List: refactor so items inside groups

[wkeese]

Currently, the List widget ends up generating DOM like below:

<d-list-category>Category A:</d-list-category>
<d-list-item>Category A Item 1</d-list-item>
<d-list-item>Category A Item 2</d-list-item>
<d-list-category>Category B:</d-list-category>
<d-list-item>Category B Item 1</d-list-item>
<d-list-item>Category B Item 2</d-list-item>

But according to the aria spec and in particular the definitions for list and group, a group's listitems need to be inside of the group. So something like:

<d-list-group role=group aria-labelledby=foo>
    <d-list-category id=foo>Category A:</d-list-category>
    <d-list-item role=listitem>Category A Item 1</d-list-item>
    <d-list-item role=listitem>Category A Item 2</d-list-item>
</d-list-group>
<d-list-group role=group aria-labelledby=bar>
    <d-list-category id=bar>Category B:</d-list-category>
    <d-list-item role=listitem>Category B Item 1</d-list-item>
    <d-list-item role=listitem>Category B Item 2</d-list-item>
</d-list-group>

@sbrunot is working on this, but I'm adding a ticket so it's not forgotten.

[sbrunot]

I've worked on this design proposal, but seeing the results I'm affraid it makes little sense in the context of the List widget:

1) One of the primary concern is performances (in the limit that the List widget must be accessible), and using an extra container for grouping items prevents the list to use a document fragment to create list items when using paging (see the upcoming deliteful/list/Pageable mixin that provides paging for long lists);

2) According to accessibility experts, the group role is currently ignored by the assistive technologies we supports so using it doesn't change the accessibility of the widget at the time.

[cjolif]

Someone (@wkeese I suppose?) has set blocker priority on that one. Honestly based on the fact that even accessibility guys are saying this is not really "supported" by assistive technologies and that 1.x list has not implementing this and nobody complained about it I would tend to downgrade the priority of this to "high". If there is a proof that this can't be done in a performing manner then we might as well ending up closing this but if we can do it with good performance I think this might worth doing it.

(btw this is really to bad github does not gives us history on tickets priorities (labels...))

[wkeese]

According to accessibility experts, the group role is currently ignored by the assistive technologies

Well, according to trivial testing, it is supported. See http://wkeese.github.io/list.html and the "Selection list (role=listbox) with single active element" example, which has two groups. JAWS reads the group names.

PS: Also see the first example on the page, "Navigation list with single active element. No javascript (navigate via tabbing)". JAWS will also read the groups in this example.

[sbrunot]

Even is it is supported when using a fieldset instead of a div, I'm affraid it doesn't solve the main potential issue: performances. Because of the potential performances impact, I think the best time to create a POC with this design is when the Pageable mixin will be available.

[sbrunot]

As the List is using the grid role, the rowgroup role could be used to group items of the same category.

The aria-owns property could be leveraged to avoid nesting the item dom nodes in the group dom node, avoiding the performance issue described in my previous comments:

<list role="grid">
    <category role="rowgroup" aria-owns="item1,item2,item3">...</category>
    <item id="item1" role="row">...</item>
    <item id="item2" role="row">...</item>
    <item id="item3" role="row">...</item>
    <category role="rowgroup" aria-owns="...">...</category>
    ...
</list>

Note, however, that maintaining the list of owned items ids comes itself with a cost (at least the cost of developing the feature...).

[sbrunot]

It appears that JAWS 15 does not supports the aria-owns property, so I don't see any solution to this problem that wouldn't break performances of pageable lists.

I guess that the best solution at this point is to make sure that Category nodes are focused during keyboard navigation, and that their category header "role" is clearly announced.

[wkeese]

What's the link to your benchmark showing this performance problem?

[pruzand]

@sbrunot in your Pageable work, have you tested the possible implementation of using 2 doc fragments as we discussed in case of a new page includes new items in existing category + new categories ?

[sbrunot]

@pruzand I didn't, but I definitely will give it a try.