Suggest alternative HTML structure for listbox example with grouped options

[backwardok]

While looking at the listbox example with grouped options, I noticed that the markup for the groups creates a flat hierarchy across the groups, with each label for the group being a list item of that containing list like so (simplified):

<div role="listbox">
  <ul role="group" aria-labelledby="groupLabel">
    <li role="presentation" id="groupLabel">
      Group label
    </li>
    <li role="option">Group item</li>
    ...
  </ul>
</div>

I wonder if it'd be worth adjusting the example markup so that the list has the same hierarchy as what's shown visually, the way that nested lists work, like so (simplified):

<ul role="listbox">
  <li role="group" aria-labelledby="groupLabel">
    <span id="groupLabel">Group label</span>
    <ul role="presentation">
      <li role="option">Group item</li>
      ...
    </ul>
  </li>
</ul>

I created a codepen fork off of the one in the example with the version I suggested at the top and the original on the bottom.

In checking the accessibility tree in Firefox, Chrome, and Safari, the accessibility nodes and hierarchy appear to be the same across the version I made and the version in the example.

[backwardok]

(if you read this before this comment was posted, I was in the middle of editing and tabbed forward to the save button by accident and hit enter. Description has since been updated)

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Issue 2800: HTML structure of listbox with grouped options.

The full IRC log of that discussion

<jugglinmike> Topic: Issue 2800: HTML structure of listbox with grouped options
<jugglinmike> github: https://github.com//issues/2800
<jugglinmike> Matt_King: Is this just another equally valid way of structuring content? Or is it better in some way? Are there any disadvantages?
<jugglinmike> jongund: The suggested approach may be semantically more accurate
<jugglinmike> Matt_King: I have some concerns about indexing, but now that I think about it, I don't know if we have a spec for this case
<jugglinmike> Matt_King: In Chrome, the way indexes are calculated, is that the entire list has 11 items.
<jugglinmike> Matt_King: But at one point in time, there were people arguing about how/when numbering restarts in groups and menus
<jugglinmike> Matt_King: Firefox is different! It says "cat" is "one of five", "reindeer" five of five, and then "dolphin" is one of three
<jugglinmike> Matt_King: We have a meaningful difference between Firefox and Chrome, and I think it shouldn't exist
<jugglinmike> Matt_King: I wonder what WebKit does, but I'm not going to try that just now
<jugglinmike> Matt_King: From my perspective, this is one list that just has some groupings within it
<jugglinmike> Matt_King: It's kind of funny because HTML doesn't actually have a semantic structure equivalent to "group" which fits within the "UL" element
<jugglinmike> Matt_King: The "select" element does, though
<jugglinmike> Matt_King: In a sense, Firefox is justified in its behavior because the HTML semantics describe three separate lists
<jugglinmike> Matt_King: That would still be the case even in this reporter's example because there are still separate lists (they're just nested)
<jugglinmike> jugglinmike: I always thought that role="presentation" applied recursively to all of an element's contents
<jugglinmike> Matt_King: It does, but authors can re-surface specific ancestor nodes by specifying an explicit role on them. This is what the proposed example does
<jugglinmike> Matt_King: My initial impression was that these were two equivalent way of coding it, that they're both valid, and authors can choose between either. I still feel that way
<jugglinmike> [all in attendence agreed that this is a matter of personal preference]

[backwardok]

Something I forgot to mention - having the outer element as a <ul> also follows the same pattern as a non-grouped listbox (where it's recommended to have a <ul>). This also means that if we were to have a mix of non-grouped items and grouped items, they'd all fit within the same markup pattern

[backwardok]

Oh also one more thing! The idea that this is one list with 11 items is more in line with using a singular outer <ul> with nested lists inside it, vs the existing APG example which has a div with 3 lists inside it

[mcking65]

@backwardok

What browsers expose in their accessibility trees ends up being identical regardless of which HTML structure you use. The differences in how posinset and setsize are calculated across browsers is due to the fact that the ARIA spec does not include normative requirements for that calculation. Nothing about how the widget is built will change that.

I remember discussing that calculation in the ARIA WG back in the 1.1 timeframe. There were strong differences of opinion. We probably decided to close the issue without resolution, which implicitly defers it to implementers. That's not great for interoperability. That said, there are far more consequential issues that need addressing, so I'm not sure that raising the setsize calculation for option groups again would change anything in the foreseeable future.

The bottom line is that you can use either HTML list structure as well as many other possible combinations of elements as well.

I'm going to close this issue. However, if you feel it needs further discussion, please feel free to re-open it.

[backwardok]

Hi @mcking65! I'm not sure I understand what your comment has to do with my comment? My thought was that using a similar structure to the simple listbox makes it easier in code to extend the concept to having subgroups, while still having top level options. And that using a single list with sublists fits more with the structure of the listbox.

I don't feel super strongly about this needing to be updated to the markup I shared, but thought I'd suggest it since it was something that came up in my own implementation.