3 ms·

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

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-insert-control-here.html#Tab https://adrianroselli.com/2019/04/details-summary-are-not-in...

tapirl 10mo ago
The pure-css effects I mentioned both don't use <detail>/<summary>.
- jakelazaroff 10mo ago
  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!)
  - tapirl 10mo ago
    for "accessible", do you mean getting focused when pressing TAB key?
    - jakelazaroff 10mo ago
      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/ARIA/Reference/Roles/tab_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/summary#technical_summary https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [3] https://w3c.github.io/aria/#tab https://w3c.github.io/aria/#tab [4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
      - tapirl 10mo ago
        > 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 10mo ago
        typo: s/with/without/
  - nextaccountic 10mo ago
    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 10mo ago
      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.
Permik 10mo ago
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 10mo ago
  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 https://news.ycombinator.com/item?id=46415271

tapirl 10mo ago

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

jakelazaroff 10mo ago
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!)
- tapirl 10mo ago
  for "accessible", do you mean getting focused when pressing TAB key?
  - jakelazaroff 10mo ago
    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/ARIA/Reference/Roles/tab_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/summary#technical_summary https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [3] https://w3c.github.io/aria/#tab https://w3c.github.io/aria/#tab [4] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/ https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
    - tapirl 10mo ago
      > 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 10mo ago
        typo: s/with/without/
- nextaccountic 10mo ago
  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 10mo ago
    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.

Permik 10mo ago

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 10mo ago
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 https://news.ycombinator.com/item?id=46415271