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

91–100 of 154 posts

Re: Accessible hamburger buttons without JavaScript

#91

Post by robinsonb5 »

atestu wrote: post #60
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…

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

Re: Accessible hamburger buttons without JavaScript

#92

Post by toastal »

LocalPCGuy wrote: post #50
mkoryak wrote: post #22

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…

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.

Re: Accessible hamburger buttons without JavaScript

#93

Post by toastal »

LocalPCGuy wrote: post #51
enyo wrote: post #2

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

Re: Accessible hamburger buttons without JavaScript

#95

Post by toastal »

enyo wrote: post #59
shakna wrote: 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.

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.

Re: Accessible hamburger buttons without JavaScript

#96

Post by divbzero »

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…

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

Re: Accessible hamburger buttons without JavaScript

#97

Post by clairity »

jameshart wrote: post #32
enyo wrote: 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…

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…

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 element (probably should be aria-labeled too) and the link list.

it's neat but a little convoluted. i'd also vote for using a 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.

Re: Accessible hamburger buttons without JavaScript

#98

Post by at-fates-hands »

frereubu wrote: post #84
at-fates-hands wrote: post #80

Earlier quoted context omitted.

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…

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.

Re: Accessible hamburger buttons without JavaScript

#99

Post by wolpoli »

mgkimsal wrote: post #17
marginalia_nu wrote: post #16

Earlier quoted context omitted.

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.

Re: Accessible hamburger buttons without JavaScript

#100

Post by davchana »

shakna wrote: 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; }

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)

Post reply on HN