[atomicfiredoll]

Okay, but are those radio tabs accessible?

I think that if you want to follow WAI-ARIA practices, the aria-selected, tabindex and aria-controls need to be updated via JS when the active tab changes? I'd love to be wrong about that.

Accessibility is often an afterthought. And, sometimes there's an assumption that by working with HTML/CSS directly, accessibility comes built in. Just Something to keep in mind when choosing an approach.

[rebane2001]

I think so?

I am aware that people who read the blog might base parts of their websites on my examples, so I definitely want to make sure they're accessible as to not cause a negative ripple effect on the web.

I don't have a background in accessibility, but I try to do the best I can. I try out what I make with various accessibility tools (e.g. keyboard navigation, screenreaders), and also read up on how things should be handled.

For the radio tabs specifically - they are keyboard navigable, work with screenreaders, and follow the tabbing to content practice mentioned in the WAI-ARIA example[0].

[0] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/examples/tabs-...

[atomicfiredoll]

Thanks! Sorry if I came off as brash, time has been tight recently. You've already put a lot of work into a very informative article, and it's appreciated. The outlook is solid. I'd like to find an opportunity to revisit some of my own code with your writing in mind.

Part of the reason for mentioning the radio-tabs is because I was working on my own implementation for a personal project a few weeks ago. My goal was specifically using the role="tab"/role="tabpanel" pattern, but my read of the guidance left me feeling like I was trapped with using JS to set those. Since it was timeboxed, I bailed out to augmenting it with JS for and moved on.

My hope was maybe somebody on HN with more of a background on accessibility could interject some thoughts here.

[Rapzid]

I don't know about those radio tabs specifically, but your intuition is correct. Many of the ARIA APG (component)patterns require JavaScript to update tab index and ARIA properties for full implementation. Focus management and key-control are two problem spaces that are common across many patterns and require JavaScript.

Focus management:

Focus scopes and restoring focus requires JavaScript. Complex UI components like combo box, grids, and trees require dynamically adjusting tab index and focus. Combo Box requires managing accessibility tree focus separately from DOM focus. Modals implementing focus scopes and restoring focus scopes requires JavaScript.

Key controls:

The ARIA APG patterns call for differences in tab and arrow key control from what the browser would supply. Patterns that involve list of groups use tab to navigate between groups and arrows to navigate within groups.

[atomicfiredoll]

Thanks for the input. The keyboard control piece is a good call-out.

Personally, I don't have my access to my normal computer/environment at the moment, so I've just been trying to go by the spec when necessary and hope for the best until I do.

[japanuspus]

Did you read the article? The author specifically addresses accessibility in multiple places, including taking extra steps to work around browser bugs [0].

[0]: https://lyra.horse/blog/2025/08/you-dont-need-js/#fn:10

[zipy124]

Given how un-accesible this blog post is (the contrast is quite a crime against humanity, as someone who does web dev for a dsiability charity (well communcity interest company but similar)), I wouldn't go to this for a source on this.

[rebane2001]

could you give any examples of how the page's accessibility could be improved - apart from your dislike of the background color

you're calling the post un-accessible and telling people to not use it as a source - i'd like to know why you think that, and if there's any way to improve the accessibility