6 ms·

Personally, I use a <input type="checkbox"> to do that kind of thing, like the hamburger menu.

eyelidlessness 4y ago
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.
- deleted 4y ago
  [deleted]
- runarberg 4y ago
  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.
jameshart 4y ago
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?
- tempestn 4y ago
  In this specific example, is the visual theme of the page even relevant to a screenreader user at all?
- DitheringIdiot 4y ago
  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
laundermaf 4y ago
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.

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.

deleted 4y ago
[deleted]
runarberg 4y ago
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.

jameshart 4y ago

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?

tempestn 4y ago
In this specific example, is the visual theme of the page even relevant to a screenreader user at all?
DitheringIdiot 4y ago
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

laundermaf 4y ago

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.