I do this too if I’m trying to play JS payload golf and the stakes are low for users, but I always feel guilty because I know it harms accessibility. JS is actually required to make an expandable/collapsible menu accessible, even if your clever pure-CSS solution seems bulletproof. It’s a shame, there really should be native controls for this kind of thing that don’t require arbitrary executable code.

This is precisely what <details> <summary> is for. No javascript required. It gives the correct semantics for assistive technology, correct interactions with the keyboard, focusability, etc. I recommend you use it over the old checkbox hacks or javascripts.

Yes! This example is a control that toggles the visibility of part of the page. It is neither a link nor a button

And, you know, if you think about this from an assistive technology point of view, does a screenreader user actually need to worry about interacting with a control to make something visible? Isn't it better from their point of view to skip the interaction entirely and just put the list of theme options semantically under a navigable page heading?

In this specific example, is the visual theme of the page even relevant to a screenreader user at all?

A lot of screen reader users are partially blind, in the process of losing their site, or sharing a screen with someone else. So it’s better to give both experiences at the same time

It’s kinda cool but apparently you can’t really be accessible AND script-free because they say you should change some aria attributes and potentially some focus when you open modals like menu and dropdowns.

A #menu href coupled with :target style is technically more accessible because the focus naturally shifts to it. Then the exit button should point to #menu-toggle so that closing the menu brings the focus back to the origin.