Now I'm very curious why <summary> is a button. Off to read more.

That second link is great, and this sentence caught my attention: "At the risk of being a broken record; HTML really needs <accordion> , <tabs>, <dialog>, <dropdown>, and <tooltip> elements." At first glance, that sure would simplify a lot of the work I've done in the past.

> Now I'm very curious why <summary> is a button.

I’m fairly certain it’s a shadow DOM implementation detail. While it technically toggles a binary state and is probably more semantically similar to a checkbox, I think the way it’s exposed to web APIs makes that either impractical or non-obvious.

"Toggle buttons" are a thing in ARIA: https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Conceptually the summary is a toggle button: you click it to toggle the display state of the details element.

That’s true and what I assumed of summary. Although toggle buttons are fairly useless in plain HTML without JS, which is why checkbox is the more obvious semantic analogue outside the shadow DOM.

those, and some additional form elements/implementing the spec for existing ones (e.g. range) more fully would be great. There's a lot of widgets that get built over and over again that could really benefit from being in the browser (especially for accessibility's sake)

Came here to mention this too. It’s even worse than the tl;dr, if I recall correctly those semantics can’t be reinstated with more semantics.

There are some other cases where certain newer features like display: contents also hide content from assistive tools. I’m pretty sure some of these are being worked on, but don’t have great recall of whether that includes details/summary.