[HN Gopher] Accessible hamburger buttons without JavaScript
___________________________________________________________________
Accessible hamburger buttons without JavaScript
Author : enyo
Score : 160 points
Date : 2023-01-27 13:48 UTC (9 hours ago)
(HTM) web link (www.pausly.app)
(TXT) w3m dump (www.pausly.app)
| mkoryak wrote:
| everything old is new again. We were doing this crap in 2011
| LocalPCGuy wrote:
| 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.
| toastal wrote:
| 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.
| jameshart wrote:
| 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.
| runarberg wrote:
| > 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.
| enyo wrote:
| > 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?
| jameshart wrote:
| 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.
| clairity wrote:
| 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.
| enyo wrote:
| Mh.. yes I agree. "Expand menu" and "Collapse menu" is
| probably a better wording.
| frereubu wrote:
| 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?
| frosted-flakes wrote:
| 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.
| jameshart wrote:
| 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?
| myfonj wrote:
| > 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.
| jameshart wrote:
| To be fair the OP hides the trigram from screen readers and
| provides them with the 'open menu' label.
| myfonj wrote:
| 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: <label
| for="menustate"> <span class="open">[?]</span>
| <span class="close">x</span> </label>
|
| So there still remains "readable" structure loosely
| identical to <label>identical to
| multiplication sign</label>
|
| (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
| enyo wrote:
| 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)
| jameshart wrote:
| You're right - I guess I assumed they'd added that in the
| full codepen.
| enyo wrote:
| The use of this symbol in the article is a placeholder.
| Obviously nobody would actually use this on their
| website...
| enyo wrote:
| Learn how to create an accessible hamburger button with pure HTML
| and CSS and why that is important.
| techn00 wrote:
| Unrelated: the image on the home page has a low resolution and
| doesn't look good ...
| enyo wrote:
| Which image (and which browser)?
| _n0ll wrote:
| Second one(the guy on his pc), vanadium
| techn00 wrote:
| The CTA one, looks fuzzy to me (both firefox and chrome)
| https://i.imgur.com/xVXWiGn.png Resolution: 2k and 1080p
| enyo wrote:
| Thanks for letting me know! Seems to happen because it's
| not a high dpi screen. I'll get on it.
| LocalPCGuy wrote:
| 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.
| toastal wrote:
| BTW, it's been ::before/::after (pseudo-element, not pseudo-
| class) since IE9 (2011).
| swyx wrote:
| providing complete copy pastable code with good default styling
| would help improve the article
| meerita wrote:
| The good old "hamburger menu". That menu that stores everything
| designers never knew how to organize it.
| kitsunesoba wrote:
| 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.
| shakna wrote:
| Except modern HTML actually has a builtin which is accessible,
| and works far better with screenreaders and other assistant
| technologies.
|
| The details element. <details>
| <summary>Menu</summary> <ul> <li><a
| href="/">Home</a></li> <li><a
| href="/thing">Thing</a></li> </ul> </details>
|
| 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:
| details { padding: 0.5em; border-style:
| solid; border-width: 1px; border-radius:
| 0.25em; cursor: pointer; }
| mariusor wrote:
| You should still wrap the list in a <nav> element to give the
| browser the context about what the menu represents.
| myfonj wrote:
| 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...
| nimish wrote:
| 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.
| enyo wrote:
| 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.
| toastal wrote:
| 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.
| shakna wrote:
| 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.
| tomcam wrote:
| 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.
| neon_electro wrote:
| Appreciate you sharing your direct experience!
| davchana wrote:
| 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)
| snow_mac wrote:
| This is really cool, thanks for pointing it out!
| gauddasa wrote:
| 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.
| thex10 wrote:
| 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...
| enyo wrote:
| This would be way too frustrating to me :)
| ElectricalUnion wrote:
| 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...
| chadlavi wrote:
| Anchor elements aren't buttons! Stop using them as buttons!!
|
| Anchors navigate. Buttons have effects.
| enyo wrote:
| 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.
| SebastianKra wrote:
| 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.
| LocalPCGuy wrote:
| 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.
| warp wrote:
| You can do this: <a
| href="#something"><button>menu</button></a>
|
| Or maybe: <form action="#something"><button
| type="submit">menu</button></form>
|
| Not sure either of those options are better than the original
| post though :)
| exogen wrote:
| 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.
| Semaphor wrote:
| Neat solution. Also interesting about `:target:`, I had not
| encountered that before.
| runarberg wrote:
| > 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.
| toastal wrote:
| 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.
| enyo wrote:
| 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.
| toastal wrote:
| 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.
| detritus wrote:
| > "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
| dwringer wrote:
| 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.
| marginalia_nu wrote:
| 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.
| deathanatos wrote:
| 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...)
| mgkimsal wrote:
| likely a case of wanting "one design to fit all devices".
| Spivak wrote:
| 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
| wolpoli wrote:
| 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.
| marginalia_nu wrote:
| That's a pipe dream if I ever saw one. Desktop and mobile
| inputs have entirely different properties and
| constraints.
| johannes1234321 wrote:
| > 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
| ...
| layer8 wrote:
| 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.
| xchkr1337 wrote:
| 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.
| notRobot wrote:
| Wikipedia has support for different skins, including the old
| one: https://news.ycombinator.com/item?id=34431533
| awefji wrote:
| 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?!!??
| dvh wrote:
| The only intuitive user interface is a nipple. Everything else
| has to be learned.
| reaperducer wrote:
| 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.
| Domenic_S wrote:
| 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-...
| reaperducer wrote:
| 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.
| mixmastamyk wrote:
| Also many times they "know" what to do but can't quite
| succeed for whatever reason. Or perhaps the milk is not
| ready.
| PoignardAzur wrote:
| 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.
| [deleted]
| intrasight wrote:
| The original "3-D user-friendly input device" ;)
| reaperducer wrote:
| _" 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.
| runarberg wrote:
| 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.
| divbzero wrote:
| 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
| enyo wrote:
| 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.
| detritus wrote:
| 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.
| mixmastamyk wrote:
| PDAs and the Nokia phone, mp3 player generation had icons.
| 90s-2010s
| enyo wrote:
| I never said that it did.
| detritus wrote:
| 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.
| enyo wrote:
| > "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 :)
| frereubu wrote:
| 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.
| reaperducer wrote:
| _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
| atestu wrote:
| 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."
| at-fates-hands wrote:
| 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 wrote:
| Is this improved with the use of attributes like aria-
| controls and aria-expanded, or is there a deeper issue?
| at-fates-hands wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yes, thanks, that's really helpful.
| mixmastamyk wrote:
| What is the preferred design?
| layer8 wrote:
| Look at the top of this very page. That design works
| quite well.
| at-fates-hands wrote:
| 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.
| deltarholamda wrote:
| 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.
| robinsonb5 wrote:
| > 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)?
| unsupp0rted wrote:
| 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.
| irrational wrote:
| 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.
| unsupp0rted wrote:
| 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.
| djbusby wrote:
| And the lack of tooltips on hover. WTF, it's missing on
| loads of big properties.
| at-fates-hands wrote:
| >> 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.
| irrational wrote:
| 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.
| dalmo3 wrote:
| > the logo is now just an SVG, with no link.
|
| Why not both? Genuine question.
| moffkalast wrote:
| 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.
| zichy wrote:
| 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.
| enyo wrote:
| You didn't actually say anything other than that it's bad and
| not to use on production. Care to elaborate?
| robertoandred wrote:
| 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?
___________________________________________________________________
(page generated 2023-01-27 23:00 UTC)