describe grouping (and naming of the group) for exclusive accordions <details name>

[dbaron]

Exclusive accordion (see explainer and HTML PR) is a small new HTML feature that adds a name attribute to the details element. Details elements with the same name form a group of related details elements, at most one of which can be open at the same time.

There has been some discussion (see particularly https://github.com/whatwg/html/pull/9400#issuecomment-1719357672 and the 1 comment following, https://github.com/whatwg/html/pull/9400#issuecomment-1736783760 and 1 comment following, https://github.com/whatwg/html/pull/9400#issuecomment-1739953579, https://github.com/whatwg/html/pull/9400#issuecomment-1741727657, and https://github.com/whatwg/html/pull/9400#issuecomment-1743748014; cc @aardrian and @GrahamTheDevRel) about an accessible name and grouping context for such groups. My understanding is that some of the suggestions made in those comments are things that should be described in html-aam (and thus I'm filing this issue to prompt the discussion to do so). Depending on what exactly html-aam defines for this case, it's likely that the authoring advice in the HTML specification could be added to or made more specific.

Note: The current authoring advice in the HTML spec that's relevant is the sentence:

Documents that use the name attribute to group multiple related details elements should keep those related elements together in a containing element (such as a section element).

[scottaohara]

@dbaron hmm...

Is it expected there's still work to do in the HTML spec per this topic?

At the very least, it seems improved author guidance is needed. What's there doesn't do much to give a clear picture on how someone would make a 'grouping' that would be exposed in the accessibility tree (for authors or the purpose of what this spec defines).

At most, some of the suggestions from the linked comments would need some authors 'must' use specific HTML elements (or a new HTML element - since that was a proposal) to specifically create this programmatically exposed grouping - and then HTML AAM could be updated to call out the mappings for the HTML elements/features that would be required for authors to use.

It's unclear to me if there is anything HTML AAM can do with what's currently in the spec. Maybe others in the ARIA wg have an opinion on whether enumeration would be helpful for the programmatically 'linked' details/summary elements? e.g., if focusing on a summary element, hearing they're interacting with x of y?

[scottaohara]

some random thoughts:

how feasible would it be for browsers to expose a grouping 'container' based on descendant details being 'grouped' via the name attribute? how deep would the nesting go in determining such a grouping container?
e.g., if a section is used as the wrapper, do other intervening section/grouping elements get ignored or prevent an automatic grouping from being created? is it a group that should be created with a section? or would the region be expected per how that element already maps? Neither of these roles are commonly/consistently exposed without a name - so what's the expectation there? name from title or again lean on ARIA to provide this feature HTML lacks? Name from heading? If there's no heading / no name, then no grouping gets exposed?

In lieu of doing any of that work, is this a job for fieldset/legend? As the element is specified (strong emphasis mine):

The fieldset element represents a set of form controls (or other content) grouped together,...

[aardrian]

@dbaron Been traveling the last few weeks (and the next few weeks), so my responses have been slow.

@scottaohara

It's unclear to me if there is anything HTML AAM can do with what's currently in the spec.

Agreed. It is not specified clearly enough to provide any mappings.

To wade into Scott's quick list of questions if only to give wrong answers to move this along...

how feasible would it be for browsers to expose a grouping 'container' based on descendant details being 'grouped' via the name attribute?

Indeed, all the engines have to be on board with this and rolling it out without that agreement feels risky.

how deep would the nesting go in determining such a grouping container?

I expect it is an all or nothing approach, since progressively nested accordions are about as useful to users as progressively nested details/summary.

e.g., if a section is used as the wrapper, do other intervening section/grouping elements get ignored or prevent an automatic grouping from being created?

IMO, ignored. As in, write the spec to limit it to no intervening elements -- non-details/summary children of the <section> would be disallowed and treated as if they come after the container.

is it a group that should be created with a section? or would the region be expected per how that element already maps?

My thought is group so it behaves similar to other interactive controls in a grouping context with an accName. I am probably over-simplifying a lot.

Neither of these roles are commonly/consistently exposed without a name - so what's the expectation there?

Name required.

name from title or again lean on ARIA to provide this feature HTML lacks?

Not a fan of title as it is not visually exposed; not a fan of relying on ARIA to bolt on features HTML can add while it is creating this new thing.

Name from heading?

Yes.

If there's no heading / no name, then no grouping gets exposed?

In my absolutist mind, correct. However, first summary could provide it? Confusing, but if counts/enumeration are included then less risky?

In lieu of doing any of that work, is this a job for fieldset/legend?

Yes, with the caveat that authors already avoid that element owing to their inability to style as they see fit. While it might be the correctest element here, it is also going to require more effort from authors (and so they may not use it at all).

[dbaron]

It sounds like at least the two of you agree that there should be a grouping element wrapping the related details elements.

There's then the question (which you've discussed some above) of whether that element should be based on something explicit in the markup, something implicit (e.g., nearest common ancestor meeting certain criteria), or some combination of the two.

Having the grouping element determined implicitly is less work for authors. But it could be insufficient or at least confusing/opaque if they need to add ARIA properties or similar to the grouping element. Having a combination might be a nice compromise if there's a reasonable way to do it (for example, without a need to search too far for the explicit container before determining that the implicit one is the right one), but that also seems a little weird. I'd probably lean towards something that authors write explicitly.

I'd like to avoid requiring the author to provide a heading, since I think that doesn't match many of the things on the web that should be exclusive accordions. (The first four such examples in the explainer, the first two do not have a heading and then the next two do). That does mean that the name for the group would (at least in some cases) not be visually exposed, which I agree isn't great, but I think a mechanism that actually requires a visible heading would just discourage authors from using the feature.

I'd also like to avoid forbidding intermediate elements that are descendants of the grouping container but ancestors of the details elements -- although forbidding specific elements might be reasonable.

[scottaohara]

linking ARIA issue i opened awhile ago that is related - https://github.com/w3c/aria/issues/1721

[aardrian]

I was going to suggest leaning on guidance for how HTML-AAM leans on an accName as a signal for <section>, but then Scott rolled in and gave me more to read...

[stevefaulkner]

I am probably missing something, but couldn't the use of the name attribute with the same value work as it does for input type=radio ?

i.e. all details with same name are exposed with a setsize and has a posinset value?

or probably more of practical use is the setsize and posinset values being exposed on the summary element

[scottaohara]

Yes @stevefaulkner that’s probably the only reasonable thing that could be done to imply a grouping relationship in lieu of an explicit grouping which is what was being advocated for in the original html discussions.

I’ve written a much longer response to this with how I see this breaking down. But wanted to respond to your comment first to emphasize that, unless someone can think of something we haven’t, it’s probably the best thing the browser could “automatically do” to imply the relationship…

[dbaron]

So let's suppose we add a requirement to the HTML spec that content group the details elements inside of a container. What requirements does that container need to meet?

I think it's worth noting, in this context, that some uses of accordions don't feel like they're particularly semantic. The underlying semantic is essentially a set of sections with headings, but they're presented in a way that involves mutually exclusive display in an accordion, and they have the interaction behavior to match that presentation. Maybe we need to accept that the semantics of HTML markup are at the level of interaction behavior rather than higher level concepts like headings and sections -- but I think this underlying tension does make it difficult in some cases to "describe" a group that may not have a clear description other than "a set of sections within this page that have a particular interaction behavior".

So this makes me nervous about things like requiring an additional heading to group the existing details elements (whose summaries are essentially like a set of headings already).

For example, in content like the Pixel 8 product page (which I think you'll get redirected away from if you're not in the US, sorry), we see this accordion (screenshot since I suspect some folks won't be able to access the page):

I don't think the heading above the accordion is really a description of the group -- although maybe it is -- but I also don't think the author of this content would want to add a visible heading such as "Examples" above the four items in the accordion.

I think I'd probably say something similar about the four sets of configuration options for this furniture ordering page.

I think I'm even less likely to be able to come up with a coherent heading or group name for the four sections ("Overview", "Responsibly Made", "Dimensions & Care", and "Shipping & Returns" in this furniture description. In that case I think it's even more strongly a presentational thing that has interaction behavior.

I'd like any developer requirements that we add to the HTML spec to be able to provide advice for these sorts of cases that is both (a) good from an accessibility perspective and (b) acceptable to the designers of the pages.

[scottaohara]

It sounds like at least the two of you agree that there should be a grouping element wrapping the related details elements.

we have overlapping but not complete agreement. 'my random thoughts' comment was meant as things to consider about the topic. I personally think that an explicit grouping element will be helpful at times, and may not be necessary in others.

Per what I mentioned before about possibly enumerating the associated details elements / Steve again raised in his comment above - i think that's probably the best way forward to provide some level of association, outside of an explicit grouping by an author. That is so long as extending aria-setsize / posinset to work with the details/summary elements is feasible across browsers, due to the fragmentation of their mappings.

Having the grouping element determined implicitly is less work for authors. ... I'd probably lean towards something that authors write explicitly.

I'd agree that for defining a grouping, especially one that will be properly exposed to AT, this needs to be an author task. What that element should be though is nebulous. Section is a tricky one - since it's already mapped to be a region or a generic element (when it has no name). This is different than the requrested 'group' role. The ability to name this without headings or use of ARIA means people would need to rely on the title attribute... that is less than ideal. There are a few open issues on HTML about how one can name sections of content using native features, here's but one of them: https://github.com/whatwg/html/issues/5812

I'd like to avoid requiring the author to provide a heading, since I think that doesn't match many of the things on the web that should be exclusive accordions. (The first four such examples in the explainer, the first two do not have a heading and then the next two do). That does mean that the name for the group would (at least in some cases) not be visually exposed, which I agree isn't great, but I think a mechanism that actually requires a visible heading would just discourage authors from using the feature.

I'm confused by some of this. All the examples in the explainer have preceding headings save for the pottery barn example. Maybe they've since updated? The zacharys site reuses the heading of the page for the accordions (an example of where i wouldn't think the explicit grouping/naming would be needed, since the accordion is the only contnet of the page). But of the remaining examples, they all have headings and could all have been nested a container element rather easily, from the looks of it / wouldn't have altered the design.

So while I do agree that a visible heading (or an extra/duplicate heading to an already existing heading on the page) shouldn't be required in all cases, I don't see why it shouldn't be recommended that authors provide one for many (most) cases.

[dbaron]

Quick reply to this point:

I'm confused by some of this. All the examples in the explainer have preceding headings save for the pottery barn example. Maybe they've since updated?

See also my previous comment (I think we were replying at the same time), but:

• I think for the Room and Board page, the heading preceding the accordion is the heading for the entire page, not for the accordion.
• On the Pixel product page, I suppose I can accept that the heading before the accordion is its heading, given that the items in the accordion are examples of it. But does that heading make sense as a description of the group from for users of assistive technology?

[scottaohara]

i don't know what you mean by the room and board page. I would assume that means the Fairfield by Marriot - but the instance there is not for the entire page, but the 'property details' at the bottom. Unless we're looking at this in different ways?

I don't think it's too much to accept that the heading before the accordion is its heading - if that cotnetn wasn't in an accordion, then it would be the heading for all those sub-sections which have been made into an accordion.

But does that heading make sense as a description of the group from for users of assistive technology?

It's as useful as a name for the grouping as it is as a heading in general.

Regardless of the above, again I will repeat that I don't think that groups always need to be explicitly made, and that the guidance should be to advocte for visible labels (headings) for such groupings to help users find the content / understand the relationship, so long as the design calls for it - and for many of these examples, the designs already do.

I think this could be covered in the issue I created today, https://github.com/whatwg/html/issues/9899

I'd be happy to work on that / work on it with you.

But again, per what's possible without further updates to HTML now, the only thing that comes to mind is what I alluded to and Steve specifically mentioned about exposing the setsize and position in set for the associated details. So if someone were to focus a summary element, they'd hear X of Y to communicate they're interacting with one of a number of related elements of that type.

[dbaron]

Oops, I meant this Room and Board page.

[scottaohara]

gotcha, thanks. i can see your point to that one. Though a counter point would be that the design of that page is not particularly great for someone using a screen reader - having the h1 come after all the content to the left of it (on large screen).

So yes, for the current design the h1 represents the page title - but also it's a flawed document structure/layout... so is that really a good example then? (the small viewport view is more coherent in the structure, as the site hides content with display none, so the h1 actually comes first - that specific version is more like the zachary pizza faq page, where i'd agree an explicit grouping is less necessary)

[aardrian]

@scottaohara

But again, per what's possible without further updates to HTML now, the only thing that comes to mind is what I alluded to and Steve specifically mentioned about exposing the setsize and position in set for the associated details. So if someone were to focus a summary element, they'd hear X of Y to communicate they're interacting with one of a number of related elements of that type.

Broadly speaking, I am on board with skipping automagic group name/context when enumeration is provided. An announcement "1 of 5" is functionally equivalent to a group, without extra noise nor shoe-horning HTML structure that will almost definitely confuse authors (waves arm at entirety of web as evidence).

I also am swayed to agree that a name is not necessary but should be encouraged.

[scottaohara]

from the aria wg call today, general agreement to update html aam to add mappings for aria-setsize and aria-posinset for details/summary elements that are associated via the name attribute.

[spectranaut]

Notes from today's meeting: https://www.w3.org/2023/12/07-aria-minutes.html#t04