Live data from Hacker News

Accessible hamburger buttons without JavaScript

pausly.app

101–110 of 154 posts

Re: Accessible hamburger buttons without JavaScript

#101
post #21

Anchor elements aren't buttons! Stop using them as buttons!! Anchors navigate. Buttons have effects.

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.

Some of the most annoying StackOverflow threads are with people urging to use a when I've triple checked that it isn't sufficient for my use-case.

Re: Accessible hamburger buttons without JavaScript

#102

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

Re: Accessible hamburger buttons without JavaScript

#103

Earlier quoted context omitted.

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

Yes, thanks, that's really helpful.

Re: Accessible hamburger buttons without JavaScript

#104

Earlier quoted context omitted.

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…

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.

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

Re: Accessible hamburger buttons without JavaScript

#105

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…

> the logo is now just an SVG, with no link.

Why not both? Genuine question.

Re: Accessible hamburger buttons without JavaScript

#106
post #52

Earlier quoted context omitted.

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?

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.

Re: Accessible hamburger buttons without JavaScript

#107

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

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

Re: Accessible hamburger buttons without JavaScript

#108
> 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 / 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.

Re: Accessible hamburger buttons without JavaScript

#109

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

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

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.

Re: Accessible hamburger buttons without JavaScript

#110

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

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

Post reply on HN