I suppose these CSS-only examples are interesting in that they push the limits of CSS, but they are almost always not accessible and should not be used in the “real world”. Unfortunately, most people pushing these CSS-only widgets have little or no experience with accessibility and thus are unwittingly promoting inaccessible patterns.
An accessible hamburger menu requires that the trigger be an actual HTML button, not a checkbox. And then you would need to manage the aria-expanded attribute on the button by setting it to false when the menu is not showing and true when the menu is showing (this is where JS is required). You can look at the Menu button in FCC for an example of how this works.
As to your original issue, the code you pasted looks like JSX and thus we can’t just copy/paste to test it. Please give us the actual HTML that the CSS is being applied to so we can test it for ourselves. Or give us a link to a live version.
I’m no accessibility expert, but in my opinion, if your site depends on JS it is de facto inaccessible to some users. If creating an accessible menu truly depends on JS that points to an issue with the standards, the technique used, or something else.
Yes, that is an idealized version of the world and not a very practical one, but the requirement for JS to be available is an accessibility failure in and of itself.
So that’s what progressive enhancement is all about. You would code the menu so that it is accessible without any JS. Of course that means you wouldn’t be able to hide the menu behind a trigger because there is no way to do that accessibly without JS. And then if JS is available you would modify the menu to work with the hamburger trigger accessibly.
Making things accessible doesn’t require JS. You can make an accessible menu using only HTML, or HTML and CSS. But you can’t add the additional functionality of hiding/showing the menu without JS if you want to be accessible.
Perhaps someday CSS will allow us to manage state, such as changing the values of attributes like aria-expanded on a button. But until then, CSS alone cannot be used to make these types of widgets accessible.
We just seem to be prioritizing one type of accessibility over another. Progressive enhancement as part of the accessibility requirements seems to take a backseat.
Requiring an attribute to be toggled dynamically can never be truly accessible. But that double standard is clearly not your fault.
I’m not sure I understand what you mean here. If you would be willing to give an example I’d much appreciate it.
It’s only a requirement if you want to add the ability to show/hide the menu. Otherwise, there is no requirement.
There are a lot of advanced features you can’t implement accessibly without using JS. For example, you can’t implement a tabbed interface without JS. Would you argue that that is a double standard? Nobody (except designers) are forcing the use of a tabbed interface. There are perfectly acceptable alternatives. Same goes for hamburger menus. I know they seem simple compared to tabbed interfaces, but that doesn’t mean there aren’t accessibility requirements if you want to implement them properly. Yes, CSS can mimic a lot of the functionality for a hamburger menu, but not enough to make them accessible. So if you don’t have JS available then you need to do something else for the menu, just like you would need to do something else for the tabbed interface.
Accessibility is about access. So yes, anything that limits access can be seen as a form of inaccessibility.
Relying on anything that might not be available to everyone, be it sight, sound, a fast device, a fast connection, or JavaScript, can be a form of inaccessibility.
I find it slightly ironic that to assist one type of user you have to rely on access to something a different type of user might not have access to. I realize the two are not mutually exclusive but I can’t help but see a bit of irony in it.
Relying on JS to provide accessibility sounds unreliable and error-prone. We should have better tools than that, or if we have them, we should use them instead.
I think this will be my last post because I’m not sure this discussion is going anywhere. I’ll just say again that you don’t have to rely on JS to provide accessibility. No one is required to create a page that utilizes JS. You can pretend that we are living in the mid-90s again and create a perfectly accessible page without any JS. But since that isn’t going to happen then you can also utilize progressive enhancement to make sure that all core functionality is accessible without JS and then enhance the page when JS is available. That way the page is still accessible regardless of whether JS is available. This solution does not exclusively rely on JS to provide accessibility because JS isn’t required. But if it is available and you are going to use it to create custom widgets then it must also be used to enhance the accessibility of those widgets as well. I’m not seeing the irony here. Everybody gets accessibility, those without JS and those who have it.
I guess we are kind of hijacking the thread so sorry to the OP about that.
The parts of your comment I’m focusing on are.
My point was that using client-side scripting to toggle attributes as a way of signaling to assistive technologies if something is visible (expanded, whatever) seems like a patchwork solution to something that should be a native solution that doesn’t depend on client-side scripting.
Native lazy loading images is an example of the browser observing the visibility of elements without client-side scripting (it doesn’t work without JS as an anti-tracking measure). I’m suggesting the same idea can be used for assistive technologies and visibility signaling.
You would add an attribute to the element which makes the element observable. This can be used to automatically toggle boolean attributes and provide other capabilities. It would be more reliable, be maintained by browser standards, and would not depend on any client-side scripting.
Anyway, sorry if I have annoyed you. We can stop this train of thought.
