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

81–90 of 154 posts

Re: Accessible hamburger buttons without JavaScript

#81

Post by at-fates-hands »

mixmastamyk wrote: post #69
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.

What is the preferred design?

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.

Re: Accessible hamburger buttons without JavaScript

#82

Post by intrasight »

dvh wrote: post #14
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 only intuitive user interface is a nipple. Everything else has to be learned.

The original "3-D user-friendly input device" ;)

Re: Accessible hamburger buttons without JavaScript

#83

Post by enyo »

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

You didn't actually say anything other than that it's bad and not to use on production. Care to elaborate?

Re: Accessible hamburger buttons without JavaScript

#84

Post by frereubu »

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

Earlier quoted context omitted.

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…

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?

Re: Accessible hamburger buttons without JavaScript

#85

Post by [deleted] »

PoignardAzur wrote: post #71
reaperducer wrote: post #28

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.

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]

Re: Accessible hamburger buttons without JavaScript

#86

Post by snow_mac »

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; }

This is really cool, thanks for pointing it out!

Re: Accessible hamburger buttons without JavaScript

#87

Post by deltarholamda »

mixmastamyk wrote: post #69
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.

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.

Re: Accessible hamburger buttons without JavaScript

#88

Post by toastal »

enyo wrote: post #9
toastal wrote: post #8

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

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

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 without async/defer or so it's executed before the body and CSS are even rendered. Doing this is useful for styling other other related situations as well.

Using a checkbox is a hack in that you are using a 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.

Re: Accessible hamburger buttons without JavaScript

#89

Post by layer8 »

dwringer wrote: post #13
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…

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…

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.

Re: Accessible hamburger buttons without JavaScript

#90

Post by layer8 »

mixmastamyk wrote: post #69
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.

What is the preferred design?

Look at the top of this very page. That design works quite well.
Post reply on HN