[jakelazaroff]

Note that pure HTML and CSS implementations of tabs using <details> and <summary> fail to meet several important accessibility criteria [1].

While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript.

[1] https://adrianroselli.com/2019/04/details-summary-are-not-in...

[Permik]

This is false, recently the details element has gotten support for grouping them: the [name] attribute. This effectively enforces tab-like semantics where only one of the grouped details elements can be open at a time.

This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)

Yay for progress and for JavaScript free solutions!

[jakelazaroff]

No, it's still true. I'm aware of that hack, but unfortunately it doesn't solve the problems with pure HTML and CSS tabs.

Crucially, the `name` attribute does not semantically turn a group of <details> elements into a set of tabs. All it does is introduce the (visual) behavior where opening one <details> element closes the others.

I posted a list of accessibility issues with the <details> hack in another comment: https://news.ycombinator.com/item?id=46415271

[tapirl]

The pure-css effects I mentioned both don't use <detail>/<summary>.

[jakelazaroff]

Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript.

(That first example could be created semantically and accessibly with <details> / <summary> though!)

[nextaccountic]

what about, make it work in pure html and css, and enrich it with js to make it accessible?

rather than not working at all with js disabled

[jakelazaroff]

That's actually a common strategy called "progressive enhancement". The only thing is that your order is backwards: you should first make it accessible in pure HTML and CSS, and then use JavaScript to layer your fancy interactions on top.

So, for the tabs example, your baseline pure HTML and CSS solution might involve showing the all tab panels simultaneously, stacked vertically. Once the JavaScript loads, it would rearrange the DOM to hide all but one and add the tab-like behavior.

[tapirl]

for "accessible", do you mean getting focused when pressing TAB key?

[jakelazaroff]

Here is a non-exhaustive list of issues you'll run into with various pure HTML and CSS implementations:

- Tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles [2].

- Focusing a tab must activate the corresponding tab panel [3], which requires JavaScript.

- Tabs should be navigable by arrow keys [4], which also requires JavaScript.

I want to be clear that I'm not trying to tear down your work. Your project looks cool and eliminating JavaScript is a noble goal. But unfortunately, as of today, it's still required to correctly build most complex controls on the web.

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[3] https://w3c.github.io/aria/#tab

[4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

[tapirl]

> Tabs should be navigable by arrow keys [4], which also requires JavaScript.

It supports this now (with JavaScript). If not, try to refresh the page.

[tapirl]

typo: s/with/without/