Hacker News Reader

Comment by iammrpayments | Hacker News Reader

Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.

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/

For tabs, see: https://lyra.horse/blog/2025/08/you-dont-need-js/#lyres-and-...

As far as I can tell, my implementation there fits the guidelines.

this article is quite good. Thanks!

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!)

It won’t have the necessary keyboard shortcuts.

Yes, the tabs in a tabs pattern should be keyboard navigated using arrow keys (ironically not the Tab key).

Also, the summary for the currently open details element will have the wrong state, 'expanded' instead of 'selected'. And while a set of details can now have a maximum of one open at a time, you can't ensure exactly one is always open (without JavaScript) as the tabs pattern requires.

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

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!)

https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for accessibility requirements of components.

And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.

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

It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year.

We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.

Because JS isn’t a big mess?

Yes. But first lets reduce the mess from 3 big mess technologies to 1 and then we can working on replacing JS.

thanks. I was honestly asking, because I'm trying to catch up on CSS progress and am kind of surprised at stuff it can do now.

Reply on news.ycombinator.com