If we've concluded that's it's okay to have elements that change/morph, as we seem to with the introduction of things like details, a native tab-like element feels like a glaring omission. Tabs have been a long-standing UI pattern and forcing every site to implement their own is a nightmare for accessibility. (The page you're reading is maybe already in a browser tab.)

I wouldn't be surprised if it turned out less than half of the custom tab interfaces on the web failed from an accessibility standpoint. When considering ARIA guidance, I don't even think it's possible to build an accessible version in HTML alone.

Other people have recognized it's missing. Open UI has a draft spec for it[0] and CSS Tricks has an article from 2001 about Open UI's experiments with sections for tabs[1]. I have no idea what happened on this front, though.

[0] https://open-ui.org/components/tabs/

[1] https://css-tricks.com/newsletter/281-tabs-and-spicy-drama/

Accordion behavior is discussed in the article in the "Accordions / Expanding Content Panels" section:

> Use the same name attribute on all related details (like radio buttons) to restrict only one open panel at a time

And tabs can be a <details>-based accordion with some creative CSS to adjust the layout (left as an exercise for the reader, but I could write up an example if that would be helpful!)

Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers.

We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere.

But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements.

(I wish the HTML spec would move faster on these common patterns!)

All of those can be done with pure html/css, eg. https://codepen.io/mikestreety/pen/yVNNNm