As someone who actually uses screenreaders and voice control on a daily basis, most of that is not a huge deal. The "a" element has similar accessibility ratings and holes in implementation.
Would you mind contacting me at the email address in my profile? I’m about to release an open source thing and I would like to understand some accessibility issues.
You missed the point then. You're probably going to need to use ARIA to attach and toggle the appropriate states in real time and that is only going to work with JavaScript.
I'd be interested in a similar review of client-specific gaps w.r.t the dialog element (which is even newer to the mainstream, i.e. likely the assistive tech has similar/worse implementation lag).
Also, while details/summary support in browsers and other user agents and tools is improving over time, it is still not perfect for ... nearly anything. Sadly.
FWIW This article is almost 4 years old. When it was written 3 years hadn’t passed since Firefox had full support in Firefox 48. Meaning that more time has passed since this article was published then the time between Firefox support and the publication.
Yes, yet last update was last year and coincidentally mentions article "A details element as a burger menu is not accessible" Published on September 20th, 2022:
I don’t think we should take this article at face value. Putting a heading <h2> inside the <summary> is weird and the aforementioned article recommends against it (most experienced web devs know not to put headings inside interactive elements other then <a>).
On top of that we have people in this threat that use screen readers and claim that they have no problems with <details>/<summary> which aren’t present in other elements[1].
I used to use a combination of checkbox & divs to show main part, the logs & data tabs on mobile page e.g. https://hukamnama.bydav.in
Now, I found details,& I keep the main page visible all times in a div, & then horizontal accordion styles as Details underneath it for History, Logs & other stuff e.g. https://spa.bydav.in/odo.html (type foo in the box to see page)
There is probably one of hundreds of markdown dialects, that supports it. Besides, markdown supports directly putting HTML into the markdown text, so it kind of supports all of HTML. How it is rendered depends on the tool you use for that, rather than on markdown as a format.
> "Over the last few decades hamburger buttons have become the de facto standard to expand larger menus on smaller devices. They are so ubiquitous that every user immediately knows what they are when seen in the top left or right corner, which makes them a good user interface element choice."
"Last Few Decades"? Eh? A decade.. perhaps?
"Every User Immediately"? This is not at all my experience. Perhaps with younger users, but I've seen plenty of people younger than I even stumble over sites where the nav was hidden behind a hamburger menu icon.
This sounds like it was written by someone very much in their own bubble
This immediately made me think of Wikipedia's latest change that moves their main menu behind just such a hamburger button on desktop, and replaces it with a table of contents down the left side.
Now instead of lazily clicking from one random article to the next (or to a different language, or to "current events", or the "main page" of headline articles), one has to move the mouse twice and make two clicks to get to it through the hamburger menu, or use the URL bar. I can't even remember the last time I went back to the ToC when reading a Wikipedia article and this change is utterly incomprehensible to me.
My experience with this is literally the opposite, I almost never clicked the buttons on the left side (except for the language switcher but that isn't in the hamburger menu now) but I always found long tables of contents very annoying on bigger articles, I find the new design generally more comfortable to read with. The only complaint I have is that it doesn't remember the state of the fullscreen button.
Yeah on desktop it's particularly bizarre design choice. Hamburger buttons are designed to conserve pixels on cramped horizontal screens. They make zero sense on a 4k ultrawide monitor.
Unfortunately for power users, "one design to fit all devices" is done by designing for mobile first. Desktop is treated as a giant tablet. Hence the large buttons and huge distance between elements.
It’s greatly complicated by how widely variable modern monitors are. Web designers can no longer target px or vw for width and space between elements unless the set a maximum width for the content.
I don’t share OP’s gripes with the changes to Wikipedia’s UI, but there are approaches to responsive design (which one might phrase “one design to fit all devices”) that don’t arbitrarily hide useful stuff in a menu where there’s space to accommodate it. And those approaches have only gotten more capable in recent years.
The problem, if there is one, is information hierarchy and deciding whether/how/where to disclose a given information at a given level in that hierarchy and how it’s disclosed. It’s very situationally dependent and probably impossible to please everyone. Optimizing it for the best outcomes for most users is what most good designs do, and they very seldom do the things a lot of vocal HN complaints want (shove everything on screen close together with small text, ie optimize for desktop power users; or make everything infinitely configurable, ie optimize for… idk even what the optimization serves, the same users complain about the web being overly complicated).
Thanks for that great perspective, I can absolutely see the benefit of the new design in a cramped display or at lower resolutions. OTOH, the comparison at 4k is strikingly different.
The old wikipedia design predates consumer access to 4K monitors though.
The reason the text wasn't wider is because long lines of text are hard to read. It's why newspapers typically arrange their text into columns, rather than having one article being 2-3 lines long stretching across the entire page.
> I can't even remember the last time I went back to the ToC when reading a Wikipedia article
I can't remember going purposely back to the ToC myself, however I often enough scroll over pages to find a section again and there it helps to have the structure visible.
However the nice thing: In your preferences you can pick the style you like. So if you want the old one pick it.
You can also leave feedback with them that "random page" is important (I like that one too!) so they find a better place ...
Another thing I dislike about the new design is the visual distraction of the current section being highlighted in the TOC. When you scroll through an article, you have like a blinking light moving through the TOC.
"Every User Immediately"? This is not at all my experience. Perhaps with younger users
I agree.
I put a hamburger menu in an in-house tool I built last year. Everyone in that department is between 22 and 30, with one guy over 50. I always stand with the users when my new products are deployed, so I was in the room when nobody recognized what the hamburger menu was.
I ended up changing it to the word "Menu" and everyone was happy.
I think it's becoming even more confusing now that Google is pushing the ⋮ vertical ellipsis as a hamburger replacement. The last thing the web needs is inconsistent icons.
Iconography is both art and science, just like typography, and works hand in hand with usability. The right icon in the right context will convey its meaning to the users, if it doesn’t then it is not the right icon or the context is missing (or both). What makes the right icon has to do with both universality and internal consistency, but neither is required.
Universally consistent icons only exist in rare cases, most of the time it is because a certain industry sits down and agrees on a standard (the power buttons are a good example; or the radioactivity and bio-hazard symbols), so inconsistent icons across the web is simply a reality that we have to live with as web designers. This makes our work both harder, but also more interesting.
I think you made the right choice removing the icon with text. Sometimes there is no icon which fits the context to provide meaning to it. In those cases, text is the correct choice.
I don't care much for hamburger menus but the vertical ellipsis drives me nuts.
The standard icon represents a list of lines of text. What the hell is a list of dots supposed to signify?
Every time I think something is obvious and ubiquitously understood someone on my client's team looks directly at it and insists it doesn't exist, or if it exists then it doesn't do anything, or if it does something then what it does isn't the thing they thought it would do.
I remember a business manager having zero idea that clicking the logo at the top of a webpage would often take you to the home page. I had assumed this was ubiquitously understood, but clearly not.
>> I had assumed this was ubiquitously understood, but clearly not.
Some anecdotal evidence to support this.
I work for a very large health care company. We recently redesigned one of our portals. During the UX research phase, one of the tasks was to go back to the home page via the logo - one of the researchers had an idea we were assuming all of our users should/would know this since but we still have a large portion of our users are older, retirees or aging Gen Xers. It was a hunch at the time - nothing more.
The research showed a large enough percentage of people couldn't complete the task in a timely manner whereas on the new design, the logo is now just an SVG, with no link. We have a dedicated "Home" link now on the main navigation which in testing, 100% of the people were now able to complete the task in a timely manner.
I think it really stunned quite a few people since this has seemingly been a standard design pattern for so long. I was pretty stunned hearing the research team talking about it.
Frankly, I would think the Gen X people would be the most familiar with the pattern. I'm Gen X and I grew up with computers from the Commodore 64 to modern computers. I learned about the clicking the logo to go to the home page back in the mid-90s, even before I became a web developer myself. It was my generation that came up with that design pattern.
Mobile platforms are the worst when it comes to having any understanding at all over where a link (or linked element) will take you and I don't think that's unintentional.
I presume you're being down-voted for the use of the word "nipple," by people who don't know that this is an axiom that has been used in the design industry for a very long time.
It's a fun little meme, but it's not all that accurate. Something like half of mothers report latching or other nipple-baby interface problems in some studies [0]. What's more, suckling is a hardwired reflex, not something that's intuited, so the quote also misunderstands the nature of intuition.
FWIW I also used to use that quote, until I had a child and saw firsthand [well, second-hand as it was my wife doing the work] how much effort breastfeeding a newborn could take; I don't really blame anyone for quoting it (it's pithy after all).
Surprisingly good further discussion on the UX SE [1].
> The fact that suckling is a hardwired reflex is what makes using the nipple intuitive. You use it by doing the same thing you think you should do.
In this case it gets used automatically without choice or thought. Anything shoved into a baby's mouth triggers it. It's not intuition, just reflex. Intuition implies understanding.
It's the difference between "I know that what this is for and how to use it" vs "I have no idea what this is and I have no control over doing it, this is just something that is happening to me"
No, if anything it's the opposite. If you understand something, you'll find it easy to use. Intuition is what you rely on in the absence of understanding.
Ironically in your haste to be contrarian to me, you failed to read the statistics. Billions of babies do know intuitively and billions more don’t. The meme is actually pretty harmful for new parents, who may think their child must be defective if they can’t figure out “the only intuitive interface”, when the reality is that it’s extremely common.
But beyond that (and this is covered in the stack overflow thread) is that it confuses intuition and reflex. Reflex is hard-wired and the stimulus often doesn’t even hit the brain - think a doctor tapping a kneecap. Suckling is like this, which is why a baby will root if you stroke its cheek - obviously there’s no nipple on the finger, yet the baby’s reflex kicks in nonetheless.
Intuition/intuitive on the other hand, in the context of UI design, means the user can without thinking or with very little conscious thought understand how to use the interface.
Nope, I downvoted because I don't like it when HN users quote platitudes with no additional context or elaboration to shut down a discussion which is more interesting than the one-line platitude.
It's like quoting Einstein's bit about infinite stupidity, or the Dunning Kruger effect. It's dismissive without being insightful.
Could we popularize an alternative to hamburger buttons that is more discoverable for users?
Google uses a horizontally-scrolling menu bar for Images, News, etc., just above the search results when viewed on mobile: https://www.google.com/search?q=test
The horizontally-scrolling menu bar seems to be:
– Discoverable for typical visual browsers
– Discoverable for screen readers, especially when used with attributes like role="menu" and role="menuitem"
> Put yourself in the shoes of a visually impaired person and think how frustrating it must be to get on a page that doesn’t allow you to open the main menu!
I just have to laugh at that kind of level of delusion. As if a screen reader will be able to figure out what the menu button is when the ids, classes and tags are all filled up with generated garbage by <insert unnecessary framework of choice>. It's not like the icon is labelled in any way that matters.
Any actually accessible or even good UX would have the menu buttons expanded by default, with text and not just icons. Mobile UIs have brought on this epidemic of hiding all features behind multiple superfluous clicks of icons hidden somewhere to the side and it just makes me feel like throwing up seeing it on desktop UIs. Even Wikipedia did it recently, despite the community backlash.
I also use 1440x900 on 24 inch monitors (I'm on the screen for 14 hours a day and don't like eye fatigue.)
(1280x720 on 15 inch laptops -- most sites think I'm on mobile so even more clicks)
The icon was designed and introduced in 1981. The popularity dramatically increased in the last decade due to smartphones that’s for sure.
It’s used by Microsoft, Apple, Youtube... the list goes on. I think it’s not too much of a stretch to say that it is ubiquitous and familiar to users.
That being said, it's not the point of the article. There are definitely reasons not to use a hamburger button. But this article helps you build one if you want it.
I know it was originally invented way back when (in Xerox Parc?), but it did not become 'de facto' on small screens decades ago, that's just a mangling of perspective.
I don't recollect ever having seen it on any of the 'small screens' (ie LCDs, etc) I used prior to smartphones.
This might seem like I'm simply being contrarian or wanting stamp my rightitude on the matter, but your framing of the icon's absolute comprehension by everyone else seems to me to be ... ill-advised. Someone not doing their homework might just take your schpiel at face value and propagate problems obliviously.
I've 'beta'd' hamburger icons a few times over the years and have always come away not relying on them precisely because they don't seem to have the blanket comprehension amongst users you seem to think they do.
> "but it did not become 'de facto' on small screens decades ago”
To me saying that something becomes something over a few decades doesn’t imply that it has been that way from the beginning. It has become a de facto standard over two decades doesn’t mean that it was a de facto standard two decades ago.
I feel like this is really not important, and I’ll change it to the last decade because it doesn’t matter. It’s definitely true that the adoption was most relevant in the last decade. I remember building hamburger menus over 20 years ago though.
What is more important is your second point that I sort of endorse hamburger buttons as a good UI element choice with this introduction. To me, this introduction was not meant to be controversial in any way. I believe that hamburger buttons are one of the most recognisable UI elements, and I don’t think that companies like Apple would use them without doing their homework.
That being said, it was not my intent to promote them as such. I didn’t do any profound research on the topic, and this article is not meant for user interface designers, but for developers that want or need to implement such a button because it either fits their use case or because the designers made the decision.
I’ll amend the intro to be more careful in the wording.
You came in a bit hot with your initial comment, but thanks for your feedback :)
"Designed and introduced" on the Xerox Star, which almost nobody used. It was quickly forgotten for 30 years, and only came back into use in 2009, according to Wikipedia.
This. These younger users thinking the 00's and the 90's where like their child years are pretty much deluded.
And it's odd because you can emulate W98, W2k, WXP and old GNU/Linux distros with damn ease in order to understand that no wm or desktop environment offerred a hamburger menu. And, trust me, lots of people tried zillions on WM's, tons of FVWM2 setups with bizarre configs highly divergent between themselves and no hamburguer button could be found in any of them.
And I can say the FVWM2 and fluxbox/blackbox guys were pioneers on lots of modern GUI trends and current minimalism or paradigm breaking shifts. If you were an UI designer for sure you tweaked FVWM2 and GTK2/QT3 themes to create weird and crazy things such as a dock composed of minified thumbnails created from windows, later done on Windows' Aero taskbar.
I think the (OS name here) start menu is the hamburger menu.
Except on mac, they have several icons that are hamburger menus =/
It's common, just different icon.
No, not all. The start menu is a launcher icon with the most common software. Fvwm had a similar root menu, but with no icon for it, you just clicked anywhere. The hamburguer menu today it's used as a application menu replacement.
Back in the day it wasn't used, period. Any software, either Win32, Motif, Delphi, Athena or such used a menu to access the most common items, the settings and a toolbar for functions. There was no icon replacing all of it.
The same with Macs. Mac OS 8, 9, and then, X. No hamburguer menu. The uberknown Mac menu and a set of Cocoa icons. That it.
That depends very much on your demographic. Over 60s? Over 70s? From personal expereince helping older people with devices I doubt that it's familiar to quite a few people around that kind of threshold.
Speaking of which (loosely), if anyone from LinkedIn is reading this your Campaign Manager has one of the dumbest pieces of UI I’ve seen in a long time.
It’s the old ‘three dots signify some sort of button’ pattern. Except these dots hide crucial functionality — think activate your campaign — and just kinda float in the middle of the row, surrounded by other actual buttons, and they don’t even have a border!
My parter figured it out eventually and when she said, hey, I found where that option is … that was a real head-slapping can it be this bad sort of moment.
From LI’s perspective this was days of income they didn’t get from us because we couldn’t figure out how to turn the damned thing on!
Hard to believe how this got through user testing.
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."
> 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)?
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.
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.
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?
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.
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.
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.
Proof that accessibility and usability are entirely orthogonal.
For screen reader users only, this provides them with the information that activating this link will open or close a menu.
Screen reader users do not need to open or close menus. Menus do not take up space or sit in front of other content. Closing a menu offers no usability benefit to a screen reader user.
All they need is the options to be present under a navigable heading that they can skip to when they need to access those options.
Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
> Screen reader users do not need to open or close menus.
Agreed, but you don’t want keyboard accessible menu items available for users that aren’t visually impaired. Offering a “show menu” button to screen readers is not less accessible to them than skipping the navigation section.
If you’re building a page that is only meant to be used by screen readers, then you are absolutely right.
> Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
The main menu? Which is behind the same ≡ button on most pages on the internet?
Offering a show menu button to screenreader users is accessible but poorly usable. They can’t see the menu. ‘Showing’ and ‘hiding’ mean nothing to them.
And for your keyboard navigators using the visual interface, perhaps this hints that you could afford them a similar opportunity - where, from being focused on the menu, they could either descend into the menu, expanding it, or skip the menu and move focus to the next control. That’s how most OS/application keyboard accessible menus work - they don’t have ‘expand’ and ‘collapse’ affordances at all.
blind folks aren't dumb. they can analogize what 'show' and 'hide' mean in context (not to say that this shouldn't be made better).
in any case, i agree that there's a lot going on to add affordances for keyboard users that screenreader users don't need. screenreaders would just need the <nav> element (probably should be aria-labeled too) and the <ul> link list.
it's neat but a little convoluted. i'd also vote for using a <button> rather than a checkbox plus anchors, but buttons do have technical limitations (as noted elsewhere) that browser engines should fix (similar to how dialog elements are now nearly javascript-less, only requiring a `showModal()` call to open), rather than having to have authors work around them.
It's an interesting distinction for sure. Perhaps "Activate menu" and "Deactivate menu" would work too, particularly as there's no reference to visual things - what would "expanding" on the screen mean in the context of a blind user?
Not all screen reader users are blind though. There are plenty of people with enough vision to see the screen, but cannot easily read the text on the screen. And on mobile where users interact with the screen reader via the touch screen, expand/collapse or show/hide fit the bill perfectly.
> The main menu? Which is behind the same ≡ button on most pages on the internet?
This triple dash thingy (≡) is in this case "identical to" Unicode character, so this is what you'd most probably hear from the screen reader. Other pages (mis)use similar characters, for example "Trigram for heaven". Not very helpful.
Truly accessible active elements must communicate their function through meaningful text, not cryptic astral Unicode from exotic blocks.
No, they did not, they present both "accessible hidden link" and "inaccessible visible label", at least I see no `aria-hidden="true"` in the code [1] on the label right now, I see just:
> Screen reader users do not need to open or close menus.
Are you sure about that? I’m not an expert but I was under the impression that many screen reader users use the screen reader (among other tools) to interact with the visual representation of the user interface. Not all screen reader users are 100% blind (or at least that’s what I’ve been told), and actually use a variety of zooming, high contrast, magnifying glass, etc. and a screen reader.
If my impression is correct, then many screen reader user indeed open or close menus, and they are in the way (especially when zoom levels are pumped way up), and visually hiding them by default does offer a ton of usability benefits.
I believe the details/summary tag has most of the builtin behaviour one would expect of a hamburger menu, but those are usually unfortunately not well supported by common browser accessibility tools.
That’s why the anchor gets the role=“button”. Unfortunately you can’t set the target of the page with a button (without JavaScript), that’s why an anchor link is used.
You could actually skip the button altogether and just make the checkbox input keyboard focus-able but visually hidden. You also avoid the issues with the hash also, as the user is then directly interacting with the element that toggles the menu. With some massaging (ensuring what is read for screen readers is set and that the visual focus state still appears to be on the hamburger when the checkbox is focused), it works quite well both for screen reader users and for non-mouse users. I don't have a current example (looks like it's been redesigned since I worked on it), but I've done something similar to this in the past on extremely large websites (thousands of views an hour in at least one instance) with much success.
The latter would probably work, but the first is invalid HTML – you can't nest interactive elements. Will browsers allow it? Yes. But it's still invalid per the spec.
Some of the most annoying StackOverflow threads are with people urging to use a <button> when I've triple checked that it isn't sufficient for my use-case.
I don't know how I feel about using a CSS hack for this. This isn't a semantic element and a lot of other browsers like TUI browsers aren't sure what to do with this sort of element.
In my experience in many cases, just showing all of the menu items when JS is disabled is an easier, safer solution with cleaner markup and no hacks. After JS is detected, toggle a class on the document to hide the menu, build your button, insert it into the DOM. Some menus are too big, but most are not and the kinds of sites that need big menus often require interactivity with JavaScript anyways.
That is a terrible user experience for SSR though and will lead to a layout shift every time the page is loaded.
I wouldn’t really call this a CSS “hack” either. There is a checkbox that defines whether the menu is open, and CSS that styles the menu accordingly. I think that this is rather elegant really.
As soon as the :has pseudo class has widespread support, the checkbox can also just live inside the nav element, which removes the awkward general sibling combinator.
Correct me if I'm wrong but it doesn't lead to layout shift if you attach that "has-js" or remove the "no-js" class from the document if the script is in the <head> without async/defer or so it's executed before the body and CSS are even rendered. Doing this is useful for styling other <noscript> other related situations as well.
Using a checkbox is a hack in that you are using a <input> but not as a part of a form. The vestigial element gets rendered in all sorts of contexts where the CSS isn't downloaded or used. And even still, to get the ARIA you need for this menu to be accessible, you'll need to invoke JavaScript for to set the element attribute states anyhow. The anchor is a hack as well because it's not being used to link to any ID on in the document.
I also just gave this author's site a go. If I checked the box by using the keyboard, I can't close it with the mouse (or vise versa). It's a little funny as well since the menu items fit on the site without needing to make a menu button and at a small enough breakpoints it doesn't even break the items into multiple lines. Perhaps this is the anchor that's getting hit in the other case. ...And if the author had concerns about JavaScript, they would have done the syntax highlighting on the server side as well.
I wish there was an existing element for developers to just use though since it's a common pattern at this point. Then we wouldn't need to use said hacks or involve JavaScript that many users disable by default for security/privacy.
Also known as the “app junk drawer”. Terrible design pattern in my opinion, particularly when they’re used in place of a proper menubar in a desktop app.
Those "toggle buttons without JavaScript" are one of my pet peeves. It's always the same thing:
1. Someone finds out that you can use `:checked`.
2. They add some JavaScript to "enhance" their idea.
3. It's still less accessible than a proper implementation.
This example is a CSS hack and not something you would actually want to use in a production environment. JavaScript is absolutely necessary if you are developing a custom interactive element. If `<details>` works for you, fine. If it doesn't, you might want to look up ARIA attributes.
> But even if accessibility is not required in your particular case (you might be building an internal site where there are no visually impaired people) you want people to be able to navigate your page with the keyboard.
I feel like this is a fundamental misunderstanding of accessibility:
First of all, in many case the default choice provides accessibility for free. In this case it is the <details>/<summary> elements that other posts have highlighted.
Secondly, accessibility is not just about accommodating current visually impaired users, or providing power-users with mouse free experience. There are all sorts of impairments where accessibility will help. Your mouse might decide to die all of a sudden in a middle of a form, and they just need to click that submit button, the company might hire a visually impaired developer, a developer might get sick, or have an accident and return to work needing assistive technology, etc. The cases are numerous.
And finally, there are no excuses for not making your site accessible. If you are a front end developer, you know the industrial standard and you apply it. If you are not and are simply making a UI around an internal tool, you are probably either just using a rudimentary UI and browser native element (why do you need the hamburger menu in that case) or you use some UI framework that implements accessibility anyway.
On my site we have a "menu" link styled as a button. Before JS loads it'll link to a page we have that lists out all the menu options (literally navigating to oursite.com/menu). After JS kicks in the link gets hidden and an identical button gets shown that does the fancy side menu opening thing. TFA's approach seems nice enough but mine feels way simpler...
Not sure if you're the author, but I'm having an issue signing up for Pausly. After connecting an auth provider, there's a screen that asks for your name, and it's not possible to check the ToS checkbox.
The error in the console is:
> Cannot destructure property 'supabaseUrl' of 'Re(...)' as it is undefined.
Thanks! Could you please tell me if this is still happening (make sure to reload first) and if so, would you mind sending me the email address you used for signup to support@pausly.app?
Definitely - there's a whole class of stuff related to Progressive Enhancement that is being re-learned (and re-shared) every couple years, it seems like. There was whether CSS was expected to be available. In 2011, it was still being argued whether or not JS could be reliably be expected to be on. Now it's probably more about specific features of CSS/JS depending on browser support, but it's still all basically the same stuff, just maybe different techniques.
I don't know if it's still true as I heard this state a few years ago, but at one point the growth rate of new web devs meant that at any given year, more than 50% of all web devs had less than 2 years of experience.
2013 was the Snowden Leaks which ended up sparking a lot of folks interest and awareness in both security and privacy. This is the time when I and many others started keeping JavaScript off by default and enabling it iff needed. So, yes, please keep your site usable without JS if its purpose is to deliver content+information and not be a web application.
Eh, "many others"? It's about 2% generally, and it's folks who are generally very well aware of how to re-enable it if needed. IMO, JavaScript is a building block of the web and there is no need in 2023 to build without it, even for progressive enhancement. You may have been able to argue that in 2011 +/- but now the average site should be able to assume it will be available if they have some reason to want to use it.
I'm not saying you need to enable it, but that is a choice you are making, and you have the skill to turn it on/off as needed, and realize that there may be sites you won't be able to use without it. I don't think it's a reasonable expectation today that JS may not be available, except maybe to display a nice warning page stating that.
Not really super important, but thoughts on using an SVG when the same hamburger button affect can be generated with just a tiny bit of HTML/CSS? As little as one element with :before/:after for the top/bottom bars, although sometimes it needs a wrapping element for best styling.
Except it doesn't actually perform well with keyboard navigation. Focus states are inconsistent and the spacebar doesn't work. And where are the aria attributes?
The goal of a pure CSS hamburger is a noble one that I applaud and share.
However, it's actually okay to introduce JS for the progressive enhancement to accessibility because ARIA is by definition dependent on RIAs.
In regards to the overall construction of these I also rather like the form:valid hack, rather than the checkbox hack depicted, since the former is more general (in particular, the selectors can be ancestors instead of siblings).
Oh, that explains why Wikipedia hamburger button works with Javascript disabled. I disabled all Javascript for wikipedia long ago when it brought back the abusive popup culture that disrupts reading by mere presence of pointer on a hyperlink.
Honestly at this point I just make sure to include all relevant links in the footer so if people can’t use the hamburger they can just use the footer links
Except modern HTML actually has a builtin which is accessible, and works far better with screenreaders and other assistant technologies.
The details element.
You may want to add a tiny bit of CSS, like adding a border, and setting the cursor to a pointer, for your sighted users:Unfortunately there are still plenty of issues with the details element, especially around accessibility. Read more here: https://cloudfour.com/thinks/a-details-element-as-a-burger-m...
Hopefully this will change soon. I’ll amend the article when this will be the case.
As someone who actually uses screenreaders and voice control on a daily basis, most of that is not a huge deal. The "a" element has similar accessibility ratings and holes in implementation.
Appreciate you sharing your direct experience!
Would you mind contacting me at the email address in my profile? I’m about to release an open source thing and I would like to understand some accessibility issues.
Referenced in that article is: https://adrianroselli.com/2019/04/details-summary-are-not-in...
Which says JavaScript is required and simplest solution for building this menu. It also states to try to avoid them when possible.
> Which says JavaScript is required
Only if you want to polyfill for pre-2019 browsers
https://caniuse.com/?search=details
You missed the point then. You're probably going to need to use ARIA to attach and toggle the appropriate states in real time and that is only going to work with JavaScript.
I'd be interested in a similar review of client-specific gaps w.r.t the dialog element (which is even newer to the mainstream, i.e. likely the assistive tech has similar/worse implementation lag).
You should still wrap the list in a <nav> element to give the browser the context about what the menu represents.
Also, while details/summary support in browsers and other user agents and tools is improving over time, it is still not perfect for ... nearly anything. Sadly.
https://adrianroselli.com/2019/04/details-summary-are-not-in...
Perfect is the enemy of the good. It's a reasonable general purpose choice. Of course don't use it if you have stricter requirements.
worth pointing out that the link is almost 4 years old - which is an age, for browsers. Things might be better now (I've not tried).
FWIW This article is almost 4 years old. When it was written 3 years hadn’t passed since Firefox had full support in Firefox 48. Meaning that more time has passed since this article was published then the time between Firefox support and the publication.
Yes, yet last update was last year and coincidentally mentions article "A details element as a burger menu is not accessible" Published on September 20th, 2022:
https://cloudfour.com/thinks/a-details-element-as-a-burger-m...
I don’t think we should take this article at face value. Putting a heading <h2> inside the <summary> is weird and the aforementioned article recommends against it (most experienced web devs know not to put headings inside interactive elements other then <a>).
On top of that we have people in this threat that use screen readers and claim that they have no problems with <details>/<summary> which aren’t present in other elements[1].
1: https://news.ycombinator.com/item?id=34547915
I used to use a combination of checkbox & divs to show main part, the logs & data tabs on mobile page e.g. https://hukamnama.bydav.in
Now, I found details,& I keep the main page visible all times in a div, & then horizontal accordion styles as Details underneath it for History, Logs & other stuff e.g. https://spa.bydav.in/odo.html (type foo in the box to see page)
Really wish there were a Markdown equivalent for this.
There is probably one of hundreds of markdown dialects, that supports it. Besides, markdown supports directly putting HTML into the markdown text, so it kind of supports all of HTML. How it is rendered depends on the tool you use for that, rather than on markdown as a format.
This is really cool, thanks for pointing it out!
> "Over the last few decades hamburger buttons have become the de facto standard to expand larger menus on smaller devices. They are so ubiquitous that every user immediately knows what they are when seen in the top left or right corner, which makes them a good user interface element choice."
"Last Few Decades"? Eh? A decade.. perhaps?
"Every User Immediately"? This is not at all my experience. Perhaps with younger users, but I've seen plenty of people younger than I even stumble over sites where the nav was hidden behind a hamburger menu icon.
This sounds like it was written by someone very much in their own bubble
This immediately made me think of Wikipedia's latest change that moves their main menu behind just such a hamburger button on desktop, and replaces it with a table of contents down the left side.
Now instead of lazily clicking from one random article to the next (or to a different language, or to "current events", or the "main page" of headline articles), one has to move the mouse twice and make two clicks to get to it through the hamburger menu, or use the URL bar. I can't even remember the last time I went back to the ToC when reading a Wikipedia article and this change is utterly incomprehensible to me.
My experience with this is literally the opposite, I almost never clicked the buttons on the left side (except for the language switcher but that isn't in the hamburger menu now) but I always found long tables of contents very annoying on bigger articles, I find the new design generally more comfortable to read with. The only complaint I have is that it doesn't remember the state of the fullscreen button.
Yeah on desktop it's particularly bizarre design choice. Hamburger buttons are designed to conserve pixels on cramped horizontal screens. They make zero sense on a 4k ultrawide monitor.
likely a case of wanting "one design to fit all devices".
Unfortunately for power users, "one design to fit all devices" is done by designing for mobile first. Desktop is treated as a giant tablet. Hence the large buttons and huge distance between elements.
It’s greatly complicated by how widely variable modern monitors are. Web designers can no longer target px or vw for width and space between elements unless the set a maximum width for the content.
I don’t share OP’s gripes with the changes to Wikipedia’s UI, but there are approaches to responsive design (which one might phrase “one design to fit all devices”) that don’t arbitrarily hide useful stuff in a menu where there’s space to accommodate it. And those approaches have only gotten more capable in recent years.
The problem, if there is one, is information hierarchy and deciding whether/how/where to disclose a given information at a given level in that hierarchy and how it’s disclosed. It’s very situationally dependent and probably impossible to please everyone. Optimizing it for the best outcomes for most users is what most good designs do, and they very seldom do the things a lot of vocal HN complaints want (shove everything on screen close together with small text, ie optimize for desktop power users; or make everything infinitely configurable, ie optimize for… idk even what the optimization serves, the same users complain about the web being overly complicated).
That's a pipe dream if I ever saw one. Desktop and mobile inputs have entirely different properties and constraints.
And "one design to fit not maximized windows on not high-dpi screens."
The new design vs the old design.
https://imgur.com/a/rV1UXc4
Thanks for that great perspective, I can absolutely see the benefit of the new design in a cramped display or at lower resolutions. OTOH, the comparison at 4k is strikingly different.
The old wikipedia design predates consumer access to 4K monitors though.
The reason the text wasn't wider is because long lines of text are hard to read. It's why newspapers typically arrange their text into columns, rather than having one article being 2-3 lines long stretching across the entire page.
And yet it feels like all designers are doing this. Some Rust docs, rendered by mdBook, was annoying me just yesterday with this.
(It's perhaps worse in that way, since it's the tooling generating the HTML, of course, so this is just going to propagate…)
Wikipedia has support for different skins, including the old one: https://news.ycombinator.com/item?id=34431533
> I can't even remember the last time I went back to the ToC when reading a Wikipedia article
I can't remember going purposely back to the ToC myself, however I often enough scroll over pages to find a section again and there it helps to have the structure visible.
However the nice thing: In your preferences you can pick the style you like. So if you want the old one pick it.
You can also leave feedback with them that "random page" is important (I like that one too!) so they find a better place ...
Another thing I dislike about the new design is the visual distraction of the current section being highlighted in the TOC. When you scroll through an article, you have like a blinking light moving through the TOC.
I'm fine with it on articles, where as you say there's a table of contents.
But the front page just has empty space there?!!??
"Every User Immediately"? This is not at all my experience. Perhaps with younger users
I agree.
I put a hamburger menu in an in-house tool I built last year. Everyone in that department is between 22 and 30, with one guy over 50. I always stand with the users when my new products are deployed, so I was in the room when nobody recognized what the hamburger menu was.
I ended up changing it to the word "Menu" and everyone was happy.
I think it's becoming even more confusing now that Google is pushing the ⋮ vertical ellipsis as a hamburger replacement. The last thing the web needs is inconsistent icons.
Iconography is both art and science, just like typography, and works hand in hand with usability. The right icon in the right context will convey its meaning to the users, if it doesn’t then it is not the right icon or the context is missing (or both). What makes the right icon has to do with both universality and internal consistency, but neither is required.
Universally consistent icons only exist in rare cases, most of the time it is because a certain industry sits down and agrees on a standard (the power buttons are a good example; or the radioactivity and bio-hazard symbols), so inconsistent icons across the web is simply a reality that we have to live with as web designers. This makes our work both harder, but also more interesting.
I think you made the right choice removing the icon with text. Sometimes there is no icon which fits the context to provide meaning to it. In those cases, text is the correct choice.
I don't care much for hamburger menus but the vertical ellipsis drives me nuts. The standard icon represents a list of lines of text. What the hell is a list of dots supposed to signify?
Every time I think something is obvious and ubiquitously understood someone on my client's team looks directly at it and insists it doesn't exist, or if it exists then it doesn't do anything, or if it does something then what it does isn't the thing they thought it would do.
I remember a business manager having zero idea that clicking the logo at the top of a webpage would often take you to the home page. I had assumed this was ubiquitously understood, but clearly not.
>> I had assumed this was ubiquitously understood, but clearly not.
Some anecdotal evidence to support this.
I work for a very large health care company. We recently redesigned one of our portals. During the UX research phase, one of the tasks was to go back to the home page via the logo - one of the researchers had an idea we were assuming all of our users should/would know this since but we still have a large portion of our users are older, retirees or aging Gen Xers. It was a hunch at the time - nothing more.
The research showed a large enough percentage of people couldn't complete the task in a timely manner whereas on the new design, the logo is now just an SVG, with no link. We have a dedicated "Home" link now on the main navigation which in testing, 100% of the people were now able to complete the task in a timely manner.
I think it really stunned quite a few people since this has seemingly been a standard design pattern for so long. I was pretty stunned hearing the research team talking about it.
Frankly, I would think the Gen X people would be the most familiar with the pattern. I'm Gen X and I grew up with computers from the Commodore 64 to modern computers. I learned about the clicking the logo to go to the home page back in the mid-90s, even before I became a web developer myself. It was my generation that came up with that design pattern.
> the logo is now just an SVG, with no link.
Why not both? Genuine question.
It seems people don't explore at all. There's no "I wonder what would happen if" impulse, or there's an "I'd better not just in case" worry.
And the lack of tooltips on hover. WTF, it's missing on loads of big properties.
Mobile platforms are the worst when it comes to having any understanding at all over where a link (or linked element) will take you and I don't think that's unintentional.
Jef Raskin: "Intuitive" == familiar.
User never used/discovered it before == not familiar.
The only intuitive user interface is a nipple. Everything else has to be learned.
The original "3-D user-friendly input device" ;)
I presume you're being down-voted for the use of the word "nipple," by people who don't know that this is an axiom that has been used in the design industry for a very long time.
It's a fun little meme, but it's not all that accurate. Something like half of mothers report latching or other nipple-baby interface problems in some studies [0]. What's more, suckling is a hardwired reflex, not something that's intuited, so the quote also misunderstands the nature of intuition.
FWIW I also used to use that quote, until I had a child and saw firsthand [well, second-hand as it was my wife doing the work] how much effort breastfeeding a newborn could take; I don't really blame anyone for quoting it (it's pithy after all).
Surprisingly good further discussion on the UX SE [1].
0: https://www.npr.org/sections/health-shots/2013/09/23/2253491...
1: https://ux.stackexchange.com/questions/5150/is-it-true-that-...
> What's more, suckling is a hardwired reflex, not something that's intuited
The fact that suckling is a hardwired reflex is what makes using the nipple intuitive. You use it by doing the same thing you think you should do.
> The fact that suckling is a hardwired reflex is what makes using the nipple intuitive. You use it by doing the same thing you think you should do.
In this case it gets used automatically without choice or thought. Anything shoved into a baby's mouth triggers it. It's not intuition, just reflex. Intuition implies understanding.
It's the difference between "I know that what this is for and how to use it" vs "I have no idea what this is and I have no control over doing it, this is just something that is happening to me"
> Intuition implies understanding.
No, if anything it's the opposite. If you understand something, you'll find it easy to use. Intuition is what you rely on in the absence of understanding.
I'd say intuition is understanding in the absence of instruction or prior experience. Something intuitive should be something you find easy to use.
Because not every baby figures it out the first time does not mean it is not intuitive for the other babies that do figure it out immediately.
It's become more of a meme to be needlessly contrarian, and ignore the fact that billions of babies actually do know this interface intuitively.
Ironically in your haste to be contrarian to me, you failed to read the statistics. Billions of babies do know intuitively and billions more don’t. The meme is actually pretty harmful for new parents, who may think their child must be defective if they can’t figure out “the only intuitive interface”, when the reality is that it’s extremely common.
But beyond that (and this is covered in the stack overflow thread) is that it confuses intuition and reflex. Reflex is hard-wired and the stimulus often doesn’t even hit the brain - think a doctor tapping a kneecap. Suckling is like this, which is why a baby will root if you stroke its cheek - obviously there’s no nipple on the finger, yet the baby’s reflex kicks in nonetheless.
Intuition/intuitive on the other hand, in the context of UI design, means the user can without thinking or with very little conscious thought understand how to use the interface.
Also many times they “know” what to do but can’t quite succeed for whatever reason. Or perhaps the milk is not ready.
Nope, I downvoted because I don't like it when HN users quote platitudes with no additional context or elaboration to shut down a discussion which is more interesting than the one-line platitude.
It's like quoting Einstein's bit about infinite stupidity, or the Dunning Kruger effect. It's dismissive without being insightful.
I like the platitude but I upvoted you anyway because I agree with you that it shouldn’t be used to curtail discussion.
Could we popularize an alternative to hamburger buttons that is more discoverable for users?
Google uses a horizontally-scrolling menu bar for Images, News, etc., just above the search results when viewed on mobile: https://www.google.com/search?q=test
The horizontally-scrolling menu bar seems to be:
– Discoverable for typical visual browsers
– Discoverable for screen readers, especially when used with attributes like role="menu" and role="menuitem"
– Fully functional without JavaScript
They even wrote the following:
> Put yourself in the shoes of a visually impaired person and think how frustrating it must be to get on a page that doesn’t allow you to open the main menu!
I just have to laugh at that kind of level of delusion. As if a screen reader will be able to figure out what the menu button is when the ids, classes and tags are all filled up with generated garbage by <insert unnecessary framework of choice>. It's not like the icon is labelled in any way that matters.
Any actually accessible or even good UX would have the menu buttons expanded by default, with text and not just icons. Mobile UIs have brought on this epidemic of hiding all features behind multiple superfluous clicks of icons hidden somewhere to the side and it just makes me feel like throwing up seeing it on desktop UIs. Even Wikipedia did it recently, despite the community backlash.
As someone with less dexterity, I agree.
I also use 1440x900 on 24 inch monitors (I'm on the screen for 14 hours a day and don't like eye fatigue.) (1280x720 on 15 inch laptops -- most sites think I'm on mobile so even more clicks)
The icon was designed and introduced in 1981. The popularity dramatically increased in the last decade due to smartphones that’s for sure.
It’s used by Microsoft, Apple, Youtube... the list goes on. I think it’s not too much of a stretch to say that it is ubiquitous and familiar to users.
That being said, it's not the point of the article. There are definitely reasons not to use a hamburger button. But this article helps you build one if you want it.
I know it was originally invented way back when (in Xerox Parc?), but it did not become 'de facto' on small screens decades ago, that's just a mangling of perspective.
I don't recollect ever having seen it on any of the 'small screens' (ie LCDs, etc) I used prior to smartphones.
PDAs and the Nokia phone, mp3 player generation had icons. 90s-2010s
PDA's where niche. No one used hamburger buttons prior to 2007-2010. No. One. Period.
The wikipedia article linked elsewhere disproves that.
However I misread the thread in my previous post.
Our actual experience say otherwise instead of your review of 90's history on Wikipedia and alikes.
PDA's where a CEO/mid-boss/rich guy tools and nothing more, ditto with cell phones until late 90's.
The 99% of the people using software was doing that thru PC's and with a mouse and menu based WIMP interfaces, and not a smartphone based UI.
I never said that it did.
Except in the bit I quoted above, no.
Wait, what?
This might seem like I'm simply being contrarian or wanting stamp my rightitude on the matter, but your framing of the icon's absolute comprehension by everyone else seems to me to be ... ill-advised. Someone not doing their homework might just take your schpiel at face value and propagate problems obliviously.
I've 'beta'd' hamburger icons a few times over the years and have always come away not relying on them precisely because they don't seem to have the blanket comprehension amongst users you seem to think they do.
> "but it did not become 'de facto' on small screens decades ago”
To me saying that something becomes something over a few decades doesn’t imply that it has been that way from the beginning. It has become a de facto standard over two decades doesn’t mean that it was a de facto standard two decades ago.
I feel like this is really not important, and I’ll change it to the last decade because it doesn’t matter. It’s definitely true that the adoption was most relevant in the last decade. I remember building hamburger menus over 20 years ago though.
What is more important is your second point that I sort of endorse hamburger buttons as a good UI element choice with this introduction. To me, this introduction was not meant to be controversial in any way. I believe that hamburger buttons are one of the most recognisable UI elements, and I don’t think that companies like Apple would use them without doing their homework.
That being said, it was not my intent to promote them as such. I didn’t do any profound research on the topic, and this article is not meant for user interface designers, but for developers that want or need to implement such a button because it either fits their use case or because the designers made the decision.
I’ll amend the intro to be more careful in the wording.
You came in a bit hot with your initial comment, but thanks for your feedback :)
The icon was designed and introduced in 1981.
"Designed and introduced" on the Xerox Star, which almost nobody used. It was quickly forgotten for 30 years, and only came back into use in 2009, according to Wikipedia.
https://en.wikipedia.org/wiki/Hamburger_button
This. These younger users thinking the 00's and the 90's where like their child years are pretty much deluded.
And it's odd because you can emulate W98, W2k, WXP and old GNU/Linux distros with damn ease in order to understand that no wm or desktop environment offerred a hamburger menu. And, trust me, lots of people tried zillions on WM's, tons of FVWM2 setups with bizarre configs highly divergent between themselves and no hamburguer button could be found in any of them.
And I can say the FVWM2 and fluxbox/blackbox guys were pioneers on lots of modern GUI trends and current minimalism or paradigm breaking shifts. If you were an UI designer for sure you tweaked FVWM2 and GTK2/QT3 themes to create weird and crazy things such as a dock composed of minified thumbnails created from windows, later done on Windows' Aero taskbar.
Like this:
https://fvwm.sourceforge.net/screenshots/desktops/
2003:
https://fvwm.sourceforge.net/screenshots/desktops/Nuno_Alexa...
2001:
https://fvwm.sourceforge.net/screenshots/desktops/Tavis_Orma...
I think the (OS name here) start menu is the hamburger menu. Except on mac, they have several icons that are hamburger menus =/ It's common, just different icon.
No, not all. The start menu is a launcher icon with the most common software. Fvwm had a similar root menu, but with no icon for it, you just clicked anywhere. The hamburguer menu today it's used as a application menu replacement.
Back in the day it wasn't used, period. Any software, either Win32, Motif, Delphi, Athena or such used a menu to access the most common items, the settings and a toolbar for functions. There was no icon replacing all of it.
The same with Macs. Mac OS 8, 9, and then, X. No hamburguer menu. The uberknown Mac menu and a set of Cocoa icons. That it.
That depends very much on your demographic. Over 60s? Over 70s? From personal expereince helping older people with devices I doubt that it's familiar to quite a few people around that kind of threshold.
Speaking of which (loosely), if anyone from LinkedIn is reading this your Campaign Manager has one of the dumbest pieces of UI I’ve seen in a long time.
It’s the old ‘three dots signify some sort of button’ pattern. Except these dots hide crucial functionality — think activate your campaign — and just kinda float in the middle of the row, surrounded by other actual buttons, and they don’t even have a border!
My parter figured it out eventually and when she said, hey, I found where that option is … that was a real head-slapping can it be this bad sort of moment.
From LI’s perspective this was days of income they didn’t get from us because we couldn’t figure out how to turn the damned thing on!
Hard to believe how this got through user testing.
I'm pretty sure Hamburgers started becoming common around 2008-9, so that's three decades we've been using them even though it's only 14 years.
But in trying to figure out when they became prominent, I discovered that some dude at Xerox invented them in 1981.
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."
> 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)?
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.
Is this improved with the use of attributes like aria-controls and aria-expanded, or is there a deeper issue?
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.
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?
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.
Yes, thanks, that's really helpful.
What is the preferred design?
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.
A good brief https://arounda.agency/blog/design-brief-example-how-it-shou... should have a number of key sections that will help you outline the project from beginning to end. Some of these include:
Simplify the navigation. Do you really need a "Start Menu" on a web page? (Sorry, I think Hamburger menus are start menus.)
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.
Look at the top of this very page. That design works quite well.
Proof that accessibility and usability are entirely orthogonal.
For screen reader users only, this provides them with the information that activating this link will open or close a menu.
Screen reader users do not need to open or close menus. Menus do not take up space or sit in front of other content. Closing a menu offers no usability benefit to a screen reader user.
All they need is the options to be present under a navigable heading that they can skip to when they need to access those options.
Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
> Screen reader users do not need to open or close menus.
Agreed, but you don’t want keyboard accessible menu items available for users that aren’t visually impaired. Offering a “show menu” button to screen readers is not less accessible to them than skipping the navigation section.
If you’re building a page that is only meant to be used by screen readers, then you are absolutely right.
> Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
The main menu? Which is behind the same ≡ button on most pages on the internet?
Offering a show menu button to screenreader users is accessible but poorly usable. They can’t see the menu. ‘Showing’ and ‘hiding’ mean nothing to them.
And for your keyboard navigators using the visual interface, perhaps this hints that you could afford them a similar opportunity - where, from being focused on the menu, they could either descend into the menu, expanding it, or skip the menu and move focus to the next control. That’s how most OS/application keyboard accessible menus work - they don’t have ‘expand’ and ‘collapse’ affordances at all.
blind folks aren't dumb. they can analogize what 'show' and 'hide' mean in context (not to say that this shouldn't be made better).
in any case, i agree that there's a lot going on to add affordances for keyboard users that screenreader users don't need. screenreaders would just need the <nav> element (probably should be aria-labeled too) and the <ul> link list.
it's neat but a little convoluted. i'd also vote for using a <button> rather than a checkbox plus anchors, but buttons do have technical limitations (as noted elsewhere) that browser engines should fix (similar to how dialog elements are now nearly javascript-less, only requiring a `showModal()` call to open), rather than having to have authors work around them.
Mh.. yes I agree. "Expand menu" and “Collapse menu" is probably a better wording.
It's an interesting distinction for sure. Perhaps "Activate menu" and "Deactivate menu" would work too, particularly as there's no reference to visual things - what would "expanding" on the screen mean in the context of a blind user?
Not all screen reader users are blind though. There are plenty of people with enough vision to see the screen, but cannot easily read the text on the screen. And on mobile where users interact with the screen reader via the touch screen, expand/collapse or show/hide fit the bill perfectly.
> The main menu? Which is behind the same ≡ button on most pages on the internet?
This triple dash thingy (≡) is in this case "identical to" Unicode character, so this is what you'd most probably hear from the screen reader. Other pages (mis)use similar characters, for example "Trigram for heaven". Not very helpful.
Truly accessible active elements must communicate their function through meaningful text, not cryptic astral Unicode from exotic blocks.
The use of this symbol in the article is a placeholder. Obviously nobody would actually use this on their website...
To be fair the OP hides the trigram from screen readers and provides them with the ‘open menu’ label.
No, they did not, they present both "accessible hidden link" and "inaccessible visible label", at least I see no `aria-hidden="true"` in the code [1] on the label right now, I see just:
So there still remains "readable" structure loosely identical to (With active CSS, only one half would be presented to SR, since the other has `display: none`, but still…)BTW Fact that wording of the link in the article pointing to the codepen is "this codepen" is also … not right.
[1] https://codepen.io/enyo/pen/yLqjrOR
Oh you’re right, I forgot to add this in the article + codepen. (It’s how the button on the site itself is implemented and I forgot to integrate it)
You're right - I guess I assumed they'd added that in the full codepen.
The 'main' menu? Implying, there are other menus.
So is the ≡ the main navigation menu?
The account options menu?
The preferences menu?
The menu of the application platform that's wrapping the page you're on, rather than the page itself?
The menu showing all the sister companies of the site you're on?
> Screen reader users do not need to open or close menus.
Are you sure about that? I’m not an expert but I was under the impression that many screen reader users use the screen reader (among other tools) to interact with the visual representation of the user interface. Not all screen reader users are 100% blind (or at least that’s what I’ve been told), and actually use a variety of zooming, high contrast, magnifying glass, etc. and a screen reader.
If my impression is correct, then many screen reader user indeed open or close menus, and they are in the way (especially when zoom levels are pumped way up), and visually hiding them by default does offer a ton of usability benefits.
I believe the details/summary tag has most of the builtin behaviour one would expect of a hamburger menu, but those are usually unfortunately not well supported by common browser accessibility tools.
https://adrianroselli.com/2019/04/details-summary-are-not-in...
Anchor elements aren't buttons! Stop using them as buttons!!
Anchors navigate. Buttons have effects.
That’s why the anchor gets the role=“button”. Unfortunately you can’t set the target of the page with a button (without JavaScript), that’s why an anchor link is used.
You could actually skip the button altogether and just make the checkbox input keyboard focus-able but visually hidden. You also avoid the issues with the hash also, as the user is then directly interacting with the element that toggles the menu. With some massaging (ensuring what is read for screen readers is set and that the visual focus state still appears to be on the hamburger when the checkbox is focused), it works quite well both for screen reader users and for non-mouse users. I don't have a current example (looks like it's been redesigned since I worked on it), but I've done something similar to this in the past on extremely large websites (thousands of views an hour in at least one instance) with much success.
You can do this:
Or maybe: Not sure either of those options are better than the original post though :)The latter would probably work, but the first is invalid HTML – you can't nest interactive elements. Will browsers allow it? Yes. But it's still invalid per the spec.
Some of the most annoying StackOverflow threads are with people urging to use a <button> when I've triple checked that it isn't sufficient for my use-case.
I don't know how I feel about using a CSS hack for this. This isn't a semantic element and a lot of other browsers like TUI browsers aren't sure what to do with this sort of element.
In my experience in many cases, just showing all of the menu items when JS is disabled is an easier, safer solution with cleaner markup and no hacks. After JS is detected, toggle a class on the document to hide the menu, build your button, insert it into the DOM. Some menus are too big, but most are not and the kinds of sites that need big menus often require interactivity with JavaScript anyways.
That is a terrible user experience for SSR though and will lead to a layout shift every time the page is loaded.
I wouldn’t really call this a CSS “hack” either. There is a checkbox that defines whether the menu is open, and CSS that styles the menu accordingly. I think that this is rather elegant really.
As soon as the :has pseudo class has widespread support, the checkbox can also just live inside the nav element, which removes the awkward general sibling combinator.
Correct me if I'm wrong but it doesn't lead to layout shift if you attach that "has-js" or remove the "no-js" class from the document if the script is in the <head> without async/defer or so it's executed before the body and CSS are even rendered. Doing this is useful for styling other <noscript> other related situations as well.
Using a checkbox is a hack in that you are using a <input> but not as a part of a form. The vestigial element gets rendered in all sorts of contexts where the CSS isn't downloaded or used. And even still, to get the ARIA you need for this menu to be accessible, you'll need to invoke JavaScript for to set the element attribute states anyhow. The anchor is a hack as well because it's not being used to link to any ID on in the document.
I also just gave this author's site a go. If I checked the box by using the keyboard, I can't close it with the mouse (or vise versa). It's a little funny as well since the menu items fit on the site without needing to make a menu button and at a small enough breakpoints it doesn't even break the items into multiple lines. Perhaps this is the anchor that's getting hit in the other case. ...And if the author had concerns about JavaScript, they would have done the syntax highlighting on the server side as well.
I wish there was an existing element for developers to just use though since it's a common pattern at this point. Then we wouldn't need to use said hacks or involve JavaScript that many users disable by default for security/privacy.
The good old "hamburger menu". That menu that stores everything designers never knew how to organize it.
Also known as the “app junk drawer”. Terrible design pattern in my opinion, particularly when they’re used in place of a proper menubar in a desktop app.
Those "toggle buttons without JavaScript" are one of my pet peeves. It's always the same thing:
1. Someone finds out that you can use `:checked`.
2. They add some JavaScript to "enhance" their idea.
3. It's still less accessible than a proper implementation.
This example is a CSS hack and not something you would actually want to use in a production environment. JavaScript is absolutely necessary if you are developing a custom interactive element. If `<details>` works for you, fine. If it doesn't, you might want to look up ARIA attributes.
You didn't actually say anything other than that it's bad and not to use on production. Care to elaborate?
> But even if accessibility is not required in your particular case (you might be building an internal site where there are no visually impaired people) you want people to be able to navigate your page with the keyboard.
I feel like this is a fundamental misunderstanding of accessibility:
First of all, in many case the default choice provides accessibility for free. In this case it is the <details>/<summary> elements that other posts have highlighted.
Secondly, accessibility is not just about accommodating current visually impaired users, or providing power-users with mouse free experience. There are all sorts of impairments where accessibility will help. Your mouse might decide to die all of a sudden in a middle of a form, and they just need to click that submit button, the company might hire a visually impaired developer, a developer might get sick, or have an accident and return to work needing assistive technology, etc. The cases are numerous.
And finally, there are no excuses for not making your site accessible. If you are a front end developer, you know the industrial standard and you apply it. If you are not and are simply making a UI around an internal tool, you are probably either just using a rudimentary UI and browser native element (why do you need the hamburger menu in that case) or you use some UI framework that implements accessibility anyway.
Neat solution. Also interesting about `:target:`, I had not encountered that before.
Wouldn't only visually hide the checkbox solve the accessibility issue?
On my site we have a "menu" link styled as a button. Before JS loads it'll link to a page we have that lists out all the menu options (literally navigating to oursite.com/menu). After JS kicks in the link gets hidden and an identical button gets shown that does the fancy side menu opening thing. TFA's approach seems nice enough but mine feels way simpler...
This would be way too frustrating to me :)
Not sure if you're the author, but I'm having an issue signing up for Pausly. After connecting an auth provider, there's a screen that asks for your name, and it's not possible to check the ToS checkbox.
The error in the console is:
> Cannot destructure property 'supabaseUrl' of 'Re(...)' as it is undefined.
Thanks! Could you please tell me if this is still happening (make sure to reload first) and if so, would you mind sending me the email address you used for signup to support@pausly.app?
I'm not the author, but I know him personally. I will make sure he reads this message.
everything old is new again. We were doing this crap in 2011
Definitely - there's a whole class of stuff related to Progressive Enhancement that is being re-learned (and re-shared) every couple years, it seems like. There was whether CSS was expected to be available. In 2011, it was still being argued whether or not JS could be reliably be expected to be on. Now it's probably more about specific features of CSS/JS depending on browser support, but it's still all basically the same stuff, just maybe different techniques.
I don't know if it's still true as I heard this state a few years ago, but at one point the growth rate of new web devs meant that at any given year, more than 50% of all web devs had less than 2 years of experience.
2013 was the Snowden Leaks which ended up sparking a lot of folks interest and awareness in both security and privacy. This is the time when I and many others started keeping JavaScript off by default and enabling it iff needed. So, yes, please keep your site usable without JS if its purpose is to deliver content+information and not be a web application.
Eh, "many others"? It's about 2% generally, and it's folks who are generally very well aware of how to re-enable it if needed. IMO, JavaScript is a building block of the web and there is no need in 2023 to build without it, even for progressive enhancement. You may have been able to argue that in 2011 +/- but now the average site should be able to assume it will be available if they have some reason to want to use it.
I'm not saying you need to enable it, but that is a choice you are making, and you have the skill to turn it on/off as needed, and realize that there may be sites you won't be able to use without it. I don't think it's a reasonable expectation today that JS may not be available, except maybe to display a nice warning page stating that.
Learn how to create an accessible hamburger button with pure HTML and CSS and why that is important.
Not really super important, but thoughts on using an SVG when the same hamburger button affect can be generated with just a tiny bit of HTML/CSS? As little as one element with :before/:after for the top/bottom bars, although sometimes it needs a wrapping element for best styling.
BTW, it's been ::before/::after (pseudo-element, not pseudo-class) since IE9 (2011).
Oh sure, I am aware, just mis-typed it in the comment.
Unrelated: the image on the home page has a low resolution and doesn't look good ...
Which image (and which browser)?
The CTA one, looks fuzzy to me (both firefox and chrome) https://i.imgur.com/xVXWiGn.png Resolution: 2k and 1080p
Thanks for letting me know! Seems to happen because it’s not a high dpi screen. I’ll get on it.
Second one(the guy on his pc), vanadium
providing complete copy pastable code with good default styling would help improve the article
Except it doesn't actually perform well with keyboard navigation. Focus states are inconsistent and the spacebar doesn't work. And where are the aria attributes?
The goal of a pure CSS hamburger is a noble one that I applaud and share.
However, it's actually okay to introduce JS for the progressive enhancement to accessibility because ARIA is by definition dependent on RIAs.
In regards to the overall construction of these I also rather like the form:valid hack, rather than the checkbox hack depicted, since the former is more general (in particular, the selectors can be ancestors instead of siblings).
Oh, that explains why Wikipedia hamburger button works with Javascript disabled. I disabled all Javascript for wikipedia long ago when it brought back the abusive popup culture that disrupts reading by mere presence of pointer on a hyperlink.
Honestly at this point I just make sure to include all relevant links in the footer so if people can’t use the hamburger they can just use the footer links
I just noticed that the hamburger button on my (Windows) keyboard doesn't activate the hamburger menu in my browser.
There’s an issue: The Space key does not open the menu.