[atestu]

I agree. Hamburger buttons were popularized with smartphones so they are still relatively new. Here's a good breakdown on why they suck https://www.nngroup.com/articles/hamburger-menus/

tl;dr "Discoverability is cut almost in half by hiding a website’s main navigation. Also, task time is longer and perceived task difficulty increases."

[robinsonb5]

> I agree. Hamburger buttons were popularized with smartphones so they are still relatively new.

I have an (admittedly ancient) Android smartphone in my pocket which has dedicated physical menu and back buttons. I don't recall seeing hamburger menus until phone manufacturers started being too cheap to include that menu button.

Now they're everywhere, even (especially) when they're not remotely appropriate. What could be more ridiculous than a touchscreen-oriented menu button in a text editor (looking at you, Gedit) or a VCD waveform viewer (looking at you, GtkWave)?

[at-fates-hands]

I'm an accessibility engineer and hamburger menus on mobile are almost always completely inaccessible. A majority of the time they need to be fixed in order to accommodate visually impaired users or users who depend on VoiceOver or other screen reading technologies. Its practically a default issue at this point.

[frereubu]

Is this improved with the use of attributes like aria-controls and aria-expanded, or is there a deeper issue?

[at-fates-hands]

Yes, using aria attributes does help, but most of the older sites we're trying to make accessible don't have these. Most of the time its a simple coding fix to add these though.

The other issue is the placement of the menu in the upper right or left hand corner is nearly impossible to find with TalkBack or VoiceOver controls. Sometimes even with aria attributes, you really have to search with your finger to find the menu and interact with it.

[frereubu]

Thanks for that. We take care to build with aria attributes, but the search for the menu icon is something I hadn't considered. Is top right / left corner not enough of a convention for a menu hamburger that it's difficult to find, or is is more about the size of that button?

[at-fates-hands]

Its mostly about the size.

When you use VoiceOver for example, an easy test is dragging your finger down the middle of the screen, you should be able to access the majority of the content - when the menu is tucked too far up in the corner, or too small, it gets obscured by the logo, CTA or anything else that's in the area and gets bypassed by VoiceOver.

Making it large enough to find by simply dragging your finger down the middle of the screen is a good enough test to determine if its big enough, too small or located somewhere it would be skipped by those screen reader tools.

Hope that helps.

[frereubu]

Yes, thanks, that's really helpful.

[mixmastamyk]

What is the preferred design?

[deltarholamda]

I prefer an actual menu. Not one of the deeply nesting, expands on rollover sorts of menus (about half of them disappear if you mis-mouse out), but just a handful of clickable text buttons or whatever that hit the major navigation points.

BigCorps Inc. don't like these, because each menu choice has 3 departments and 14 sub-departments that mate-guard their particular menu area, so designers just give up on mobile and hide it all behind the hamburger icon.

It's absolutely daft. Your Web site should be an extra employee, never-tiring, always at work, facilitating the customer or visitor's needs. It's really weird, but depressingly predictable.

[micahdeath]

Simplify the navigation. Do you really need a "Start Menu" on a web page? (Sorry, I think Hamburger menus are start menus.)

[at-fates-hands]

I don't think the org that I work for has really found it.

Enlarging the menu so its easier to find with screen reader tools like TalkBack and VoiceOver has been somewhat effective. However, if you have split menu's, login, search and other features, you start running into complex design issues with where to put all of those and whether you want to stuff them all in the mobile menu, outside the menu or a combination of the two. When you start putting features like search and login into the mobile menu, that also creates more accessibility issues as well.

Designing for accessibility can get really complex, really fast and I'm not sure there's really a solid design pattern yet that addresses all of the issues we're seeing now.

I know that's not a great answer, but it just highlights the complexity of designing for accessibility.

[layer8]

Look at the top of this very page. That design works quite well.