Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accessible hamburger buttons without JavaScript

pausly.app

Post reply on HN
Print view View original

71–80 of 154 posts

Re: Accessible hamburger buttons without JavaScript

#71

Post by PoignardAzur »

reaperducer wrote: post #28
dvh wrote: post #14

Earlier quoted context omitted.

The only intuitive user interface is a nipple. Everything else has to be learned.

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.

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.

Re: Accessible hamburger buttons without JavaScript

#72

Post by mixmastamyk »

detritus wrote: post #25
enyo wrote: post #15

Earlier quoted context omitted.

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 h…

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

Re: Accessible hamburger buttons without JavaScript

#73

Post by exogen »

warp wrote: post #46
enyo wrote: post #21

Earlier quoted context omitted.

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 can do this: menu Or maybe: menu 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.

Re: Accessible hamburger buttons without JavaScript

#74

Post by nimish »

myfonj wrote: post #61
mariusor wrote: post #56

Earlier quoted context omitted.

You should still wrap the list in a 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.

Re: Accessible hamburger buttons without JavaScript

#75

Post by frereubu »

at-fates-hands wrote: post #65
atestu wrote: post #60

Earlier quoted context omitted.

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'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?

Re: Accessible hamburger buttons without JavaScript

#76

Post by frereubu »

enyo wrote: post #15
detritus wrote: post #12

> "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 u…

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 h…

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.

Re: Accessible hamburger buttons without JavaScript

#77

Post by irrational »

at-fates-hands wrote: post #63
irrational wrote: post #36

Earlier quoted context omitted.

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 porti…

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.

Re: Accessible hamburger buttons without JavaScript

#78

Post by frereubu »

enyo wrote: post #52
jameshart wrote: post #32

Earlier quoted context omitted.

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 ne…

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?

Re: Accessible hamburger buttons without JavaScript

#79

Post by neon_electro »

shakna wrote: post #62
enyo wrote: post #59

Earlier quoted context omitted.

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!

Re: Accessible hamburger buttons without JavaScript

#80

Post by at-fates-hands »

frereubu wrote: post #75
at-fates-hands wrote: post #65

Earlier quoted context omitted.

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.

Post reply on HN