BBC News has a hamburger menu for news topics that, with JavaScript disabled, at least on Android, is simply a fragment link to an unhidden list of topics in the page footer, which I find to work very well, at least for me. (More generally, I appreciate how lightweight the BBC News website feels, at least with JavaScript off.) They also have another hamburger menu for navigating to departments other than News (Sport, Weather, …, Food), which appears to work as a normal hamburger menu even without JavaScript.
<details> and <summary> are better suited for hamburger menus than using form elements for things that they haven’t been designed for. Please, please stop assuming you’re qualified to give advice if you don’t know the basics.
I am aware and considered using the details tag, but it didn’t suit the use case. In case you are in a big screen, it will not “disappear” into a full list of links to occupy all the available space. The solution solves a problem, which does not have an ideal technical solution that satisfies the UI/UX requirements, so please don’t look down in other people’s work because you disagree on the implementation details.
They are both bad options for accessibility–and the detail/summary isn’t designed for this use case either. You need ARIA and this is all handled better/easier with JavaScript. What I do for small viewports with JavaScript disabled is just show all the links stacked and let the user scroll over them (because like this example, many navigation lists aren’t very long).
It’s time for a change — hotdog menus shall be the next big thing. ;)
Serious answer: I believe that hamburger menus is a navigation anti-pattern in the majority of cases, if not all cases. You make a good point there about stacked navigation lists.
However, I wonder if there are any catalogs of navigation patterns that work well on small screens with imprecise pointing devices.
If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
So, maybe there isn’t a <menu> (yet), but there is <nav> that can do the semantic lifting for the list of menu items.
There’s a lot of keyboard considerations, expanded, label, etc. This example is more robust than a “simple hamburger” but a lot of the rules still apply.
The checkbox hack solution also dirties the markup for TUI browsers which render an input and it’s confusing when you see it and it’s not interactable.
I knew that link, but the constraint for the post was “CSS only” menu. As far as I remember most of the information about ARIA is provided with HTML attributes, JavaScript is used for creating the sub-menus and effecting the actual changes each item represents. So, for a simple menu, with only one level, I consider my method better.
Also both an ordered/unordered list of links and the mechanism of expanding a <details> element are perfectly accessible for keyboard access, without needing extra aria properties. I assume (though I might be wrong about this) that for visual impaired accessibility is also better, having less contrived markup to deal with.
You gotta let go of striving too hard to be CSS-only. JavaScript doesn’t always have to be bad or malicious (especially hosted first-party) and is often the better tool for the job in these cases. And I say this as someone that browses with JavaScript disabled by default because a lot of JavaScript code is harmful or useless. The best approach is design something sensible for <noscript> and optimize/enhance it with JavaScript (which is why I mentioned just showing all the menu items when scripts are disabled).
Your solution also doesn’t “disappear” into a full list either without the help of CSS. Similar CSS can be used to keep the details element open for wide screens, and the summary hidden.
It’s kind of funny to read about a CSS-only technique on Medium—my browser had to load almost 9 MB of stuff for me to read the article. Interesting technique though! I’m inclined to say that using an <input> for this is too much of a hack, that you’re sacrificing semantics in the name of avoiding JavaScript.
This is an old and well known trick, but nowadays, you can probably use https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog instead or one of whatever new elements comes down the pike next.
BBC News has a hamburger menu for news topics that, with JavaScript disabled, at least on Android, is simply a fragment link to an unhidden list of topics in the page footer, which I find to work very well, at least for me. (More generally, I appreciate how lightweight the BBC News website feels, at least with JavaScript off.) They also have another hamburger menu for navigating to departments other than News (Sport, Weather, …, Food), which appears to work as a normal hamburger menu even without JavaScript.
That’s a good solution
Meanwhile, https://www.ponylang.io has a more normal Material-style hamburger menu that works without JavaScript.
I like this. I derived something similar when trying to toggle elements’ visibility without Javascript.
<details>and<summary>are better suited for hamburger menus than using form elements for things that they haven’t been designed for. Please, please stop assuming you’re qualified to give advice if you don’t know the basics.I am aware and considered using the details tag, but it didn’t suit the use case. In case you are in a big screen, it will not “disappear” into a full list of links to occupy all the available space. The solution solves a problem, which does not have an ideal technical solution that satisfies the UI/UX requirements, so please don’t look down in other people’s work because you disagree on the implementation details.
They are both bad options for accessibility–and the detail/summary isn’t designed for this use case either. You need ARIA and this is all handled better/easier with JavaScript. What I do for small viewports with JavaScript disabled is just show all the links stacked and let the user scroll over them (because like this example, many navigation lists aren’t very long).
Better yet, can we stop making hamburger menus altogether? ;)
In all seriousness, how would you address a list of links in a nav on mobile without a hamburger menu?
Why? You hungry?
It’s time for a change — hotdog menus shall be the next big thing. ;)
Serious answer: I believe that hamburger menus is a navigation anti-pattern in the majority of cases, if not all cases. You make a good point there about stacked navigation lists.
However, I wonder if there are any catalogs of navigation patterns that work well on small screens with imprecise pointing devices.
I believe there are still use cases, but it’s often unnecessary if there’s only 1–8 items.
Which bits of ARIA would one need to use to make accessible a menu, that are not available with HTML attributes?
However the first rule of ARIA is:
So, maybe there isn’t a
<menu>(yet), but there is<nav>that can do the semantic lifting for the list of menu items.https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-navigation/
There’s a lot of keyboard considerations, expanded, label, etc. This example is more robust than a “simple hamburger” but a lot of the rules still apply.
The checkbox hack solution also dirties the markup for TUI browsers which render an input and it’s confusing when you see it and it’s not interactable.
I knew that link, but the constraint for the post was “CSS only” menu. As far as I remember most of the information about ARIA is provided with HTML attributes, JavaScript is used for creating the sub-menus and effecting the actual changes each item represents. So, for a simple menu, with only one level, I consider my method better.
Also both an ordered/unordered list of links and the mechanism of expanding a
<details>element are perfectly accessible for keyboard access, without needing extra aria properties. I assume (though I might be wrong about this) that for visual impaired accessibility is also better, having less contrived markup to deal with.https://adrianroselli.com/2019/04/details-summary-are-not-insert-control-here.html#Navigation
You gotta let go of striving too hard to be CSS-only. JavaScript doesn’t always have to be bad or malicious (especially hosted first-party) and is often the better tool for the job in these cases. And I say this as someone that browses with JavaScript disabled by default because a lot of JavaScript code is harmful or useless. The best approach is design something sensible for
<noscript>and optimize/enhance it with JavaScript (which is why I mentioned just showing all the menu items when scripts are disabled).Your solution also doesn’t “disappear” into a full list either without the help of CSS. Similar CSS can be used to keep the details element open for wide screens, and the summary hidden.
It’s kind of funny to read about a CSS-only technique on Medium—my browser had to load almost 9 MB of stuff for me to read the article. Interesting technique though! I’m inclined to say that using an
<input>for this is too much of a hack, that you’re sacrificing semantics in the name of avoiding JavaScript.