I thought we had previously discussed that the button mapping for summary is broken because summary can have interactive children in HTML

i mean yes... there's very much that as well. but is that a spec issue and HTML should update to not allow interactive elements within? Or is that a potential implementation or mapping issue and we address this that way?

I don't see HTML changing that. There are far too many implementations which meet the spec today which would become non-conformant. I think we need to work out how we should map summary in a useful way before adding an ARIA mapping for it.

yeh, re: HTML... I understand that, but it just seems very unfortunate to not want to break something (by changing allowances) which, by current functionality, is already broken because of those permissive allowances.

agenda or deep dive topic, @jnurthen ?

Perhaps it would be useful to point out the problem in the "Comment" row of the summary table.

This seems to make sense to me, because the HTML specification refers to HTML-AAM via the link "For implementers"

I don't see HTML changing that. There are far too many implementations which meet the spec today which would become non-conformant. I think we need to work out how we should map summary in a useful way before adding an ARIA mapping for it.

It doesn't appear that there is 0 support for changing the HTML spec.

This is the classic nested interactives debate. It is hard to imagine a solution that doesn't either:

1. Disallow the nested interactives
   Or 2) Force browsers to add a sibling interactive that controls the details whenever there is a nested interactive (which seems kinda crazy)
   Or 3) Changes all accessibility APIs and assistive tech to support some kind of new construct that allows buttons and links to have descendant buttons and links. Whenever I try to imagine a way to solve all the problems associated with that, my brain feels like it falls into a bottomless hurt pit.

I'm keen to see what people can come up with that solves the AX issues without disallowing interactives inside summary.

summary can have interactive children in HTML

Wild. In addition to causing accessibility issues, this sure makes keyboard usage weird for both sighted keyboard users and screen reader users. For example, below I have a summary that contains a link. Focusing the summary allows space and enter to expand/collapse the details. Focusing the the link and typing enter follows the link, but space on the link does nothing in Firefox and expands/collapses the details in Chrome (heh, in Chrome there's a bug where space does a page scroll as well, i.e. the event needs stopPropagation()/preventDefault() ). So the sighted keyboard behavior is not terrible, I suppose.

But it gets weirder when using a screen reader. NVDA/Chrome/FF always follows the link on space and enter even when the summary has focus. JAWS/Chrome always expands/collapses on space and enter no matter what has focus. I had to use the context menu (Shift+F10) to follow the link. JAWS/FF works similar to regular keyboard, where focusing summary expands/collapses on space/enter and focusing link and typing enter follows link (space does nothing).

(Sorry about the accidental comments and closing - I somehow managed to do that while testing space in JAWS/Edge).

removing the agenda label for now so this stops coming up on the agenda item list. will add it back on when i think we have new ground to cover.

From the ARIA WG deep dive today, there are presently two directions we could take this issue.

1. We create a new role (name pending) to represent a 'disclosure' control. This control would be similar to, for instance, tab and push/expand button roles - in that it's activation would toggle the display of other associated content. However, it would need to be different than those roles to account for the fact it would need to allow its own instances of structural elements (headings) or interactive elements (links / text fields, etc.).

2. We do not create a new role, but instead look to have browsers revise the shadow DOM of the summary element to be exposed to users as a button element with the arbitrary content that can be added to a summary element as a separate element which would provide the accessible name for the persistent button element. I created a codepen to demonstrate how this "could" be structured (again as far as the end user is concerned) - https://codepen.io/scottohara/pen/RwqQgML

3. We could go with another direction that someone could propose.

Thank you everyone for your participation / input in today's meeting.

adding agenda so that this can be mentioned during the next wg meeting, to ensure people are aware of the choices / can comment on the issue.

THEN, we can give people some time to make a decision, and in a couple/few weeks time we can take an action on the choice that we make.

2¢ I feel like perhaps we need both 1 and 2. 1 because the role mapping for summary element is currently a mess across AT and browsers. 2 to solve the issue with interactive content inside of summary. And lastly, (perhaps the least prioritized?) with regards to the accordion proposal potentially adding the name attribute, something else might be added/considered to resolve the accname for the shadow button element.