Using a footer as a replacement for a nav bar is ridiculous. Which requires more interaction? Clicking a button to see available actions or scrolling all the way to the bottom of the page (and making the bold assumption that you happen to know that the menu is at the bottom)?
If you’ve got sufficient space at the top of your page to show your nav items, especially for larger window sizes, just show them instead of hiding them away behind a menu. But if you have limited space, like on mobile, a hamburger menu is a fine solution.
Assuming the bottom is even accesible! I believe it's somewhere in the Amazon ios app where I see a promise of a useful footer that is always pushed off the page by infinitely scrolling things they're pushing at me instead.
That's their mobile layout in general. In their view they must have improved UX immensely since no mobile person has needed help/support since introduction of infinite scrolling
My favorite thing is when a website or app places a bunch of icons at the extreme bottom edge, and my tap there is confused by iOS as me interacting with the app switcher bar.
There are scads of articles like this, either from the accessibility > all or the page size > all tribes, that obnoxiously "solve" problems by sticking their fingers in their ears and ignoring all objections. Throw in a snarky tone and sanctimonious justifications and bam: you got a black text white background web dev blog.
Sorry, but for 99% of websites, businesses, and individual browsers, the harm of moving all your navigation a flat hierarchy in your footer VASTLY outweighs the harm of a hamburger menu.
I agree. Part of what sucks about websites is that everyone is trying to things differently. When I see a hamburger menu, I know what it does. It would take me a long while to figure out your site's navigation sits at the bottom of the page.
When you look at a website with a burger menu, you know what the burger menu does. When you look at a website without a burger menu, you know what the website does.
I wonder about using this with a hamburger menu as a form of progressive enhancement?
You would still use a hamburger menu that requires CSS and/or JS (it can be done in just CSS). You'd have that same content in the footer of the page. For the JS disabled people, you'd have a `<noscrip><a href="#footerburger"></noscript>` at the top of the page where the hamburger would be. So if a user clicks on it, it will jump to the footer that contains the exact same content as the hamburger.
What exactly is this constituency of jscript-disabled people? It sounds a bit nuts to me. I can't imagine why I should be catering to them. Asking because I sincerely don't know.
You're misrepresenting the recommendation. You did not include the instructions "link directly to [the footer navigation options] from your header" or "Be sure to also include some form of "Top of the page" link for quick access back to the initial scroll view."
Why put a link to the footer in the header which contains links to other pages when you can just put your links directly in the header?
I know the reason why, because it makes the page cluttered, whereas having it at the footer does a better job of hiding it. But isn't that the exact problem that the hamburger menu was made to fix?
> Using a footer as a replacement for a nav bar is ridiculous. Which requires more interaction? Clicking a button to see available actions or scrolling all the way to the bottom of the page (and making the bold assumption that you happen to know that the menu is at the bottom)?
Why are you (and most of the commenters!) ignoring "...and link directly to them [the footer links] from your header"? You're arguing against a claim nobody made.
In this scheme, you still click a button right up at the top to see a menu; it's just that the menu is at the bottom of the page instead of in a pop-out, avoiding all the listed problems with JavaScript, screen readers, keyboard navigation, etc.
It’s not ridiculous. Look at how it’s done on the page itself: a link to the footer in the header. I’d argue that the word “sitemap” isn’t a great choice for the link text, but the interaction itself works ok.
If we're using this page as an example, they could have fit the entire navigation menu at the top of the page just fine. If it's pointless even at this small scale, what good is this going to do implementing on larger platforms like Amazon?
I agree with the "stop resorting to hamburger menus so fast" take however.
> Which requires more interaction? Clicking a button to see available actions or scrolling all the way to the bottom of the page
I mean honestly clicking the sitemap button on the OP is faster than than any SPA opening a menu.
Your average site already has a bunch of links in the footer, if the argument is that footers are useless and should be eliminated then sure. But otherwise embracing their existing purpose is a good thing.
To be fair, the only reason they exist in otherwise minimalist apps is because they need to be there for crawlability. A hamburger menu that isn't visible until someone clicks on it is an SEO problem that is (sadly) easily mitigated with a footer, which has bled into the problem of the big footer, wherein people hamfistedly use the footer to solve the entirety of their crosslinking strategies, which (at least for me, but maybe I'm the weirdo) makes it impossible to scroll to the bottom of the page to get to the meat of it without having to usually scroll almost all the way back up.
I see footers working as a usable nav bar only if the number of navigation elements is small enough and the footer is sticky (always visible and at the bottom).
You could always put a link at the top that will scroll you down to the footer menu. If you do it the simplest way possible the back button will bring you back to where you were if you change your mind.
> I see this argument pop-up frequently when taking to design leaders or developers. I call bullshit on this excuse. You absolutely have the choice to avoid implementing bad designs - that's your job! Either you're not fighting hard enough against those pushing for it, or you're just trying to build a "pretty" portfolio.
sigh I'm so tired of this absolutist, ranty way of thinking. Its indicative of Twitter-brain or social media outrage brain. Design is almost always a collaborative process. You literally have no controlling choice on the outcome, because the choice itself is being made by multiple stakeholders, be it your customers, your coworkers, your clients, etc.
Also, the author lists himself as the "UX Designer & Front-End Engineer @ Donorbox." Their web site at https://donorbox.org appears to be using a hamburger menu on mobile. I hope he isn't beating himself up over it.
It's hard to move away from established UI patterns like a hamburger menu because stakeholders expect it, and I suspect users look for that little hamburger icon as well.
when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
im old. i expect buttons with words on them.
now i have to spend a significant amount of my time, hours per year, explaining to users to click the "thing with the three lines, then scroll down, there should be a menu that says XYZ, no, you have to go down farther, its between PDQ and ABC. no its not categorized very well i agree. i agree nobody would know what three lines mean. ".
>It's hard to move away from established UI patterns like a hamburger menu
>when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
That's why it's really not established, nobody really wanted a hamburger to begin with when websites used to be able to afford to serve steak.
The appearance of such a non-satisfying menu item has always lacked the flavor that attracts patrons the most.
> You absolutely have the choice to avoid implementing bad designs - that's your job!
Ha, seems like this someone doesn't know when and where to pick their battles. Yes, sometimes you can really push for change when you come up with a real, convincing argument. Or, A/B test the crap out of it.
When I was on the front-end of the stack, it really taught me "disagree and commit" often with product and design. Unless it's something existential, there's almost no reason to accept "good enough", move forward, measure, and iterate.
yeah this is an odd article. hamburger menus are not perfect, but they do the job and they’re expected by the user, which is important in UI
this article’s main justification for them being poor is that they don’t work well without a mouse and/or when you have javascript turned off. okay there are times and places and people for whom javascript will be off, that’s understandable, but still rare. who is browsing the internet with just a keyboard though?
they’re fixing an issue for the vanishingly few by worsening the experience of overwhelming majority, and acting as if this is an obvious solution that developers are too blighted to see
There are people that can't use a mouse and have to use keyboard navigation.
The negative attitude against towards accessibility vexes me greatly. Are wheelchair ramps a pointless waste of money because the vast majority of people can walk just fine? Should we not care about making cities safer for blind people because they are just a small minority?
These kinds of attitude wouldn't be socially acceptable in the "real world" but the web still likes to pretend that it is the Wilde West. And yes, actively excluding people from being able to use your services is a bigger problem than you site being slightly less pretty.
People with disabilities (mostly vision impaired) browse the internet with "just a keyboard" or a screen reader. It's quite cumbersome, but for some people, that's the best they can do.
At a previous job, we had to follow their extensive rules for making everything accessible. A few things that I can remember:
* minimum contrast ratio
* support for the high-contrast mode that some browsers have
* screen reader support for every UI element - this requires a ton of different things
* everything must be usable without a mouse
There were tools to check for a lot of this. There was a separate team of accessibility people who would check the result and create tickets for things that were not good enough.
It was annoying when the designers specified low-contrast colors, then we'd build it with the colors specified by the designers, and then the tool tells us the colors are unacceptable. Why can't the designers check the contrast ratio of their colors?
Testing with a screen reader was extremely annoying (because it reads a description of the currently focused item), but it gave me a lot of empathy for the poor people for whom this is the only way to use a web UI.
I think the main thing is that hamburger menus are stupid on desktop.
It's a symptom of attempting to build hybrid interfaces for both mobile/touch and computer screen/mouse+keyboard by basically ignoring the affordances of the latter altogether. When pixels aren't scarce, [𐄒] is a menu but strictly worse.
Desktop interfaces don't have a pixel shortage. Like at all. Replacing text+icon buttons with cryptic line icons in general means your users have to learn to decode Linear B to use the interface like it's a Myst puzzle.
The design choice is strictly a bad trade-off on desktop. If you're on mobile, where pixels actually are scarce and input precision is low, it makes sense though.
Agreed, but fortunately you rarely see them on desktop, or else it's a hamburger icon that actually toggles a whole sidebar (e.g. Gmail, but I wish they would use a different icon).
I think most designers are developers are aware that hamburger menus are a mobile thing.
Of course sometimes there aren't enough dev resources to do both mobile and desktop and the desktop site is just an embiggened mobile version, with hamburger. But that's resource constraints.
Unfortunately I see them all the time on desktop. Ubuntu/Gnome apps are literally littered with them, because someone thought regular menus are "evil" or something like that. So now most of the apps have a single entry in the regular/global menu (Quit), and all other actions are crammed under the hamburger in the app window.
> When pixels aren't scarce, [𐄒] is a menu but strictly worse.
The character in the square brackets is "AEGEAN NUMBER THIRTY", U+010112. It doesn't display in my browser (Chrome on Windows). Oddly, it does display in my xterm, though that's likely to depend on which fonts you're using. (It's three horizontal lines.)
Exactly this. I kind of understand if you want a design that works the same on mobile and desktop. And very occasionally I think it might make sense, e.g. in browsers.
The real head scratcher is Gnome. Why are they moving from normal menus which work very well to hamburger menus for apps which have plenty of space and are desktop only?
I guess it wouldn't be the first time the Gnome people have made inexplicable UX decisions. Maybe it's just too boring doing the thing that we know works and they want to try new worse things?
"Mobile first design" calls for designing for mobile first, then adopting for desktop second, if there's time anyway.
>Desktop interfaces don't have a pixel shortage.
Combined with designers adding more and more padding, attempting to fit 2 web sites on desktop on a 1080p monitor ends up triggering mobile design anyway.
In 2015 I might have agreed. But they clearly caught on. We now have enough data that shows users know how to use them, and in many cases prefer them. There's even one built into the Xbox controller for crying out loud.
I won't begrudge the purists out there who find creative ways to avoid assimilating. But, uhhhh, I don't think this confusing footer link trick would actually win out in a UX test in 2023.
I know how to use them, but I still hate them. They're a symptom of a larger issue with modern web (and application) UI design: discovery seems to be no longer considered important.
Precisely, this article is part of a timeline. And has no "Next" or "Previous" links. Which are far more useful, especially if they were at the top of the article. You have to figure out that "Home" actually takes you to other articles--most definitely non-standard.
In addition, whatever happened to the general UX advice "Users don't scroll"?
Finally, on my monitor, it also has a gigantic amount of useless whitespace to the left and right no matter how wide you make it so the bottom links always manage to stay hidden.
I'm no fan of hamburger menus, but there are far more fundamental UX mistakes being made here.
Given the context here, however, I should note that the Menu key is purely equivalent to right clicking on what’s focused or selected or where the caret is in a text box, to open the context menu, which sounds fairly different from the Xbox controller’s Menu button (though I’ve never used it). As for the context menu, web pages should never touch it, and web apps shouldn’t often. I’m still sad about the death of <menu type="context"> which let you add to the native context menu. Now your only options as a web app are to leave the native context menu alone, or completely replace it, neither of which are great options, a lot of the time.
Tbh the keyboards at the time when the hamburger menu first showed up had symbols quite different from the symbol of the hamburger menu. And at the moment that symbol still looks different in the same way. Perhaps eventually keyboards will begin to use the hamburger menu symbol on the menu key. Probably a few do already. But I mean most keyboards.
And also the hamburger menu symbol is not so much different from all of the other “mystery meatballs” (as Lynda Weinmann called them, many many years ago) that we all know and love. Today I expect that most people will be able to recognise and know how to use the hamburger menu.
Aren’t we just rediscovering the pertinence of standardized actions?
Windows 95 was the peak of usability (standardized menus, top bars, buttons, toolbars, bottom bar, keyboard shortcuts for everything), but it seems we’ve broken it down because… ? because it was boring? perfect uniformity made it look strict-minded? gray made people afraid of software?
Or perhaps the power of machines meant that every large company could afford their own design?
Anyway, yes the hamburger menu should become a standard, and the standard should be broken again because we don’t want life to be boring.
> The biggest headache when coming across these menus on the web is the complete disregard for accessibility.
Just because most websites / frontend frameworks fail to implement hamburger menus in an accessible way (including Bootstrap 5), does not mean that hamburger menus in general are bad when it comes to accessibility.
With that logic, images / img elements are a core problem per se and should be prohibited, because most pages don't use them correctly from an accessibility standpoint (e.g. forgetting to provide an explicit "alt" attribute).
WCAG / WAI has pretty good recommendations in how to achieve it. Here is their hamburger menu pattern example:
My natural inclination was to say “so hamburger menus can be implemented badly, but they can also be implemented properly so this is no reason to advise against hamburger menus as a whole”.
But I think it’s also worth remembering that patterns matter, and if almost everyone gets something wrong, it’s small consolation that it was an unforced error. If a different pattern is similarly acceptable and done badly far less often, pragmatism suggests pushing the alternative, because the average result will be better.
When I use hamburger menus on regular web pages, I implement them so that they’re entirely adequately accessible, and work with no JavaScript. (Depending on the situation, I’ll either use <details> or a checkbox hack with reasonable labels and such, and I may enhance things with a small snippet of JavaScript.) But I lack faith in almost anyone else’s implementations.
I would note also that the ARIA example you link to fails one of the criteria of this article: JavaScript-free operation. It’s also only suitable for some sorts of hamburger menus; it’s unlikely to be a suitable pattern for website header navigation menus, which are really more a navigation palette than a menu (to use very fuzzy terms!), and which are the main focus of this article.
I'm not sure* that the "just put everything the footer and link to the footer" is a solution I'd present seriously to the business stakeholders.
The thing I really want to kill with fire is the "junk drawer" method of UI design. This has infested almost all apps, with a three-dot (••• or vertical ⋮ ) scattered literally everywhere in every UI. It says "We couldn't be bothered to build a thoughtful UI, or even to classify the types of actions you might want to perform into a few categories. Even with a full-screen window on a 5K monitor, we'd rather have a sea of whitespace everywhere than to just put the actions where they are visible, discoverable, and can develop muscle memory.
I used to think about 15 years ago that a big problem was that developers and designers all used expensive high-res, large monitors and forgot that most users were on 1280x800 or (eek) 1280x720 laptop screens. Today it's the opposite direction with everything being optimized for tiny screens and minimal information visibility.
I know "mobile-first" is important but (A) phone users want things to be visible just as much as desktop users do, and (B) the right design for a phone is almost never the right choice on a massive screen.
*for an "application" - sure, it works great for a 8-page blog like the article. By all means. I just don't think it'll work for Expedia, Facebook, etc.
It should not be based on what YOU (the developer or designer) feels, it should be based on user research. User research shows hamburger menus are bad.
One of the companies I own (rather smallish one) creates commercial websites. Hamburger menus work just fine according to our research and a/b testing, sometimes superior to other navigation methods, sometimes not. YMMV.
User research doesn't show that anything is good or bad, full stop. User research shows that things are good or bad for a particular use case or audience. That's why companies have user research teams - because there are few universal principles, and it's important to understand what's best for your users in your context to achieve your objectives.
I don't understand this take at all. Why would you bury your navigation on your (hypothetical) marketing site in the footer on mobile? Most users don't even scroll far enough to make it to the footer and they certainly wouldn't expect the navigation there.
>Why would you bury your navigation on your (hypothetical) marketing site in the footer on mobile?
I've been on some sites where the hamburger menu was atrocious and/or unhelpful.
When I encounter this, I will often just scroll to the bottom, where a lot of templates will put the "sitemap" stuff, usually with more descriptive text, so I can then find what I'm looking for.
It's not ideal, but people design mobile sites as if they're applying for a graphic designer job. Mobile design has become "smoosh it till it fits," and it just doesn't work well. It's a small screen, operated by a meatsack with a single giant thumb, who is probably driving 127 mph through a suburban neighborhood. It's a lot more than just "flow the three columns into one" kind of problem.
It works like setting up a yard sale with nothing actually in your yard but a sign that says "the good stuff's around back ;)"
Yes, the necessary information is technically conveyed, but what's improved by this over headers or hamburgers? You'd be better off just having a fat header with all your links.
Which by the way is horrible accessibility wise (by default) because if there are other links on the page, it scrolls right back up to them when you navigate them with the keyboard, negating the entire point of the shortcut.
I think it doesn’t, and it’s not even necessary. The name “sitemap” is very unintuitive. For this site specifically, all the links could comfortably fit in the header: https://i.imgur.com/7VH4UJ6.png
A button that scrolls you to the bottom where all the links are really isn’t that different from a button that shows all the links in an overlay is it?
placing the links at the bottom is very bizzare and not a great improvement to accessibility because nobody in the world expects those links there and its hard to even scroll there. If one is worried about accessibility maybe have both, why not, because I found the footer to be less intuitive and convenient.
I read that part, but I don't think trading off massive amounts of usability for the majority of people to slightly increase the usability for the minority is the right decision in almost any case.
Readit News
If you’ve got sufficient space at the top of your page to show your nav items, especially for larger window sizes, just show them instead of hiding them away behind a menu. But if you have limited space, like on mobile, a hamburger menu is a fine solution.
That's always fun.
Sorry, but for 99% of websites, businesses, and individual browsers, the harm of moving all your navigation a flat hierarchy in your footer VASTLY outweighs the harm of a hamburger menu.
Hamburgher menus, albeit fancy, where really confusing at the start. Personally I still think overusing them is design laziness.
It contains some mystery meat, that's for sure.
You would still use a hamburger menu that requires CSS and/or JS (it can be done in just CSS). You'd have that same content in the footer of the page. For the JS disabled people, you'd have a `<noscrip><a href="#footerburger"></noscript>` at the top of the page where the hamburger would be. So if a user clicks on it, it will jump to the footer that contains the exact same content as the hamburger.
I know the reason why, because it makes the page cluttered, whereas having it at the footer does a better job of hiding it. But isn't that the exact problem that the hamburger menu was made to fix?
Why are you (and most of the commenters!) ignoring "...and link directly to them [the footer links] from your header"? You're arguing against a claim nobody made.
In this scheme, you still click a button right up at the top to see a menu; it's just that the menu is at the bottom of the page instead of in a pop-out, avoiding all the listed problems with JavaScript, screen readers, keyboard navigation, etc.
I think anyone doing "Down with X" ought to define X...
And I think I like them, anyway :)
I agree with the "stop resorting to hamburger menus so fast" take however.
I mean honestly clicking the sitemap button on the OP is faster than than any SPA opening a menu.
Your average site already has a bunch of links in the footer, if the argument is that footers are useless and should be eliminated then sure. But otherwise embracing their existing purpose is a good thing.
It isn't a bad secondary navigation, but kinda odd to say.
Deleted Comment
> I see this argument pop-up frequently when taking to design leaders or developers. I call bullshit on this excuse. You absolutely have the choice to avoid implementing bad designs - that's your job! Either you're not fighting hard enough against those pushing for it, or you're just trying to build a "pretty" portfolio.
sigh I'm so tired of this absolutist, ranty way of thinking. Its indicative of Twitter-brain or social media outrage brain. Design is almost always a collaborative process. You literally have no controlling choice on the outcome, because the choice itself is being made by multiple stakeholders, be it your customers, your coworkers, your clients, etc.
Also, the author lists himself as the "UX Designer & Front-End Engineer @ Donorbox." Their web site at https://donorbox.org appears to be using a hamburger menu on mobile. I hope he isn't beating himself up over it.
It's hard to move away from established UI patterns like a hamburger menu because stakeholders expect it, and I suspect users look for that little hamburger icon as well.
im old. i expect buttons with words on them.
now i have to spend a significant amount of my time, hours per year, explaining to users to click the "thing with the three lines, then scroll down, there should be a menu that says XYZ, no, you have to go down farther, its between PDQ and ABC. no its not categorized very well i agree. i agree nobody would know what three lines mean. ".
>when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
That's why it's really not established, nobody really wanted a hamburger to begin with when websites used to be able to afford to serve steak.
The appearance of such a non-satisfying menu item has always lacked the flavor that attracts patrons the most.
It's probably related to the rise in popularity of Bootstrap
Ha, seems like this someone doesn't know when and where to pick their battles. Yes, sometimes you can really push for change when you come up with a real, convincing argument. Or, A/B test the crap out of it.
When I was on the front-end of the stack, it really taught me "disagree and commit" often with product and design. Unless it's something existential, there's almost no reason to accept "good enough", move forward, measure, and iterate.
this article’s main justification for them being poor is that they don’t work well without a mouse and/or when you have javascript turned off. okay there are times and places and people for whom javascript will be off, that’s understandable, but still rare. who is browsing the internet with just a keyboard though?
they’re fixing an issue for the vanishingly few by worsening the experience of overwhelming majority, and acting as if this is an obvious solution that developers are too blighted to see
The negative attitude against towards accessibility vexes me greatly. Are wheelchair ramps a pointless waste of money because the vast majority of people can walk just fine? Should we not care about making cities safer for blind people because they are just a small minority?
These kinds of attitude wouldn't be socially acceptable in the "real world" but the web still likes to pretend that it is the Wilde West. And yes, actively excluding people from being able to use your services is a bigger problem than you site being slightly less pretty.
At a previous job, we had to follow their extensive rules for making everything accessible. A few things that I can remember:
* minimum contrast ratio
* support for the high-contrast mode that some browsers have
* screen reader support for every UI element - this requires a ton of different things
* everything must be usable without a mouse
There were tools to check for a lot of this. There was a separate team of accessibility people who would check the result and create tickets for things that were not good enough.
It was annoying when the designers specified low-contrast colors, then we'd build it with the colors specified by the designers, and then the tool tells us the colors are unacceptable. Why can't the designers check the contrast ratio of their colors?
Testing with a screen reader was extremely annoying (because it reads a description of the currently focused item), but it gave me a lot of empathy for the poor people for whom this is the only way to use a web UI.
It's a symptom of attempting to build hybrid interfaces for both mobile/touch and computer screen/mouse+keyboard by basically ignoring the affordances of the latter altogether. When pixels aren't scarce, [𐄒] is a menu but strictly worse.
Desktop interfaces don't have a pixel shortage. Like at all. Replacing text+icon buttons with cryptic line icons in general means your users have to learn to decode Linear B to use the interface like it's a Myst puzzle.
The design choice is strictly a bad trade-off on desktop. If you're on mobile, where pixels actually are scarce and input precision is low, it makes sense though.
That's probably why I hate hamburger menus. I use a desktop for 95% of my computer use.
I think most designers are developers are aware that hamburger menus are a mobile thing.
Of course sometimes there aren't enough dev resources to do both mobile and desktop and the desktop site is just an embiggened mobile version, with hamburger. But that's resource constraints.
The character in the square brackets is "AEGEAN NUMBER THIRTY", U+010112. It doesn't display in my browser (Chrome on Windows). Oddly, it does display in my xterm, though that's likely to depend on which fonts you're using. (It's three horizontal lines.)
I presume most hamburger menus use an image.
The real head scratcher is Gnome. Why are they moving from normal menus which work very well to hamburger menus for apps which have plenty of space and are desktop only?
I guess it wouldn't be the first time the Gnome people have made inexplicable UX decisions. Maybe it's just too boring doing the thing that we know works and they want to try new worse things?
In 2015 I might have agreed. But they clearly caught on. We now have enough data that shows users know how to use them, and in many cases prefer them. There's even one built into the Xbox controller for crying out loud.
I won't begrudge the purists out there who find creative ways to avoid assimilating. But, uhhhh, I don't think this confusing footer link trick would actually win out in a UX test in 2023.
In addition, whatever happened to the general UX advice "Users don't scroll"?
Finally, on my monitor, it also has a gigantic amount of useless whitespace to the left and right no matter how wide you make it so the bottom links always manage to stay hidden.
I'm no fan of hamburger menus, but there are far more fundamental UX mistakes being made here.
And also the hamburger menu symbol is not so much different from all of the other “mystery meatballs” (as Lynda Weinmann called them, many many years ago) that we all know and love. Today I expect that most people will be able to recognise and know how to use the hamburger menu.
Windows 95 was the peak of usability (standardized menus, top bars, buttons, toolbars, bottom bar, keyboard shortcuts for everything), but it seems we’ve broken it down because… ? because it was boring? perfect uniformity made it look strict-minded? gray made people afraid of software?
Or perhaps the power of machines meant that every large company could afford their own design?
Anyway, yes the hamburger menu should become a standard, and the standard should be broken again because we don’t want life to be boring.
Just because most websites / frontend frameworks fail to implement hamburger menus in an accessible way (including Bootstrap 5), does not mean that hamburger menus in general are bad when it comes to accessibility.
With that logic, images / img elements are a core problem per se and should be prohibited, because most pages don't use them correctly from an accessibility standpoint (e.g. forgetting to provide an explicit "alt" attribute).
WCAG / WAI has pretty good recommendations in how to achieve it. Here is their hamburger menu pattern example:
https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/example...
But I think it’s also worth remembering that patterns matter, and if almost everyone gets something wrong, it’s small consolation that it was an unforced error. If a different pattern is similarly acceptable and done badly far less often, pragmatism suggests pushing the alternative, because the average result will be better.
When I use hamburger menus on regular web pages, I implement them so that they’re entirely adequately accessible, and work with no JavaScript. (Depending on the situation, I’ll either use <details> or a checkbox hack with reasonable labels and such, and I may enhance things with a small snippet of JavaScript.) But I lack faith in almost anyone else’s implementations.
I would note also that the ARIA example you link to fails one of the criteria of this article: JavaScript-free operation. It’s also only suitable for some sorts of hamburger menus; it’s unlikely to be a suitable pattern for website header navigation menus, which are really more a navigation palette than a menu (to use very fuzzy terms!), and which are the main focus of this article.
There are so many great properties waiting to be implemented properly.
The thing I really want to kill with fire is the "junk drawer" method of UI design. This has infested almost all apps, with a three-dot (••• or vertical ⋮ ) scattered literally everywhere in every UI. It says "We couldn't be bothered to build a thoughtful UI, or even to classify the types of actions you might want to perform into a few categories. Even with a full-screen window on a 5K monitor, we'd rather have a sea of whitespace everywhere than to just put the actions where they are visible, discoverable, and can develop muscle memory.
I used to think about 15 years ago that a big problem was that developers and designers all used expensive high-res, large monitors and forgot that most users were on 1280x800 or (eek) 1280x720 laptop screens. Today it's the opposite direction with everything being optimized for tiny screens and minimal information visibility.
I know "mobile-first" is important but (A) phone users want things to be visible just as much as desktop users do, and (B) the right design for a phone is almost never the right choice on a massive screen.
*for an "application" - sure, it works great for a 8-page blog like the article. By all means. I just don't think it'll work for Expedia, Facebook, etc.
What research shows that hamburger menus are bad? Why the conclusion is this one? What makes them bad?
If you are to advocate for data oriented decisions, you'd better present the data!
(citation needed)
I've been on some sites where the hamburger menu was atrocious and/or unhelpful.
When I encounter this, I will often just scroll to the bottom, where a lot of templates will put the "sitemap" stuff, usually with more descriptive text, so I can then find what I'm looking for.
It's not ideal, but people design mobile sites as if they're applying for a graphic designer job. Mobile design has become "smoosh it till it fits," and it just doesn't work well. It's a small screen, operated by a meatsack with a single giant thumb, who is probably driving 127 mph through a suburban neighborhood. It's a lot more than just "flow the three columns into one" kind of problem.
There's a link in the header to the nav element at the bottom. I think it works.
Yes, the necessary information is technically conveyed, but what's improved by this over headers or hamburgers? You'd be better off just having a fat header with all your links.