Live data from Hacker News

Accessible hamburger buttons without JavaScript

pausly.app

61–70 of 154 posts

Re: Accessible hamburger buttons without JavaScript

#61
post #40

Except modern HTML actually has a builtin which is accessible, and works far better with screenreaders and other assistant technologies. The details element. Menu Home Thing 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; }

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...

Re: Accessible hamburger buttons without JavaScript

#62
post #59
post #40

Except modern HTML actually has a builtin which is accessible, and works far better with screenreaders and other assistant technologies. The details element. Menu Home Thing 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; }

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.

Re: Accessible hamburger buttons without JavaScript

#63

Earlier quoted context omitted.

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.

Re: Accessible hamburger buttons without JavaScript

#64
post #33
post #27

Earlier quoted context omitted.

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

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

The use of this symbol in the article is a placeholder. Obviously nobody would actually use this on their website...

Re: Accessible hamburger buttons without JavaScript

#65
post #60

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

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.

Re: Accessible hamburger buttons without JavaScript

#66

Earlier quoted context omitted.

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…

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.

Re: Accessible hamburger buttons without JavaScript

#67

Earlier quoted context omitted.

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…

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.

Also many times they “know” what to do but can’t quite succeed for whatever reason. Or perhaps the milk is not ready.

Re: Accessible hamburger buttons without JavaScript

#68

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

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…

> 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 ...

Re: Accessible hamburger buttons without JavaScript

#69
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.

What is the preferred design?

Re: Accessible hamburger buttons without JavaScript

#70
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 `` works for you, fine. If it doesn't, you might want to look up ARIA attributes.

Post reply on HN