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 6 days ago | parent | next [-]

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 5 days ago \| parent [-]
		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 3 days ago | parent | prev | next [-]

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 2 days ago \| parent [-]
		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.

▲

5 days ago | parent | prev | next [-]

[deleted]

▲

japanuspus 6 days ago | parent | prev | next [-]

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 5 days ago | parent | prev [-]

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 5 days ago | parent [-]

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

▲

zipy124 3 days ago | parent [-]

This is not my dislike of the background colour (blue is actually my favourite colour, well teal), nothing in that comment was an opinion. The WCAG (Web Content Accessibility Guidelines) have standards for colour contrast [1]. If you turn on developer tools in your browser and go to accesbility you will see how many elements do not conform to these standards. The site falls astray of this in the most common way, which is blue links on a blue background, making link text very hard to read.

You can also view these issues using googles hosted version of lighthouse (chromes checking tools for speed and accessibility) at https://pagespeed.web.dev/analysis/https-lyra-horse-blog-202...

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

ps. I love the post in general, I'm a big fan of css over javascript!

	▲	rebane2001 3 days ago \| parent [-]
		thank you for the response! i am aware that the link color specifically is not ideal and i have been playing around with designs that feel similar while having better contrast - but your comment seemed to call the entire site un-accessible, so i was wondering if there's anything else that stood out and that could be improved