On my site we have a "menu" link styled as a button. Before JS loads it'll link to a page we have that lists out all the menu options (literally navigating to oursite.com/menu). After JS kicks in the link gets hidden and an identical button gets shown that does the fancy side menu opening thing. TFA's approach seems nice enough but mine feels way simpler...
Accessible hamburger buttons without JavaScript
41–50 of 154 posts
Re: Accessible hamburger buttons without JavaScript
#42Earlier quoted context omitted.
I never said that it did.
Except in the bit I quoted above, no. Wait, what? This might seem like I'm simply being contrarian or wanting stamp my rightitude on the matter, but your framing of the icon's absolute comprehension by everyone else seems to me to be ... ill-advised. Someone not doing their homework might just take your schpiel at face value and propagate problems obliviously. I've 'beta'd' hamburger icons a few times over the years…
> "but it did not become 'de facto' on small screens decades ago”
To me saying that something becomes something over a few decades doesn’t imply that it has been that way from the beginning. It has become a de facto standard over two decades doesn’t mean that it was a de facto standard two decades ago.
I feel like this is really not important, and I’ll change it to the last decade because it doesn’t matter. It’s definitely true that the adoption was most relevant in the last decade. I remember building hamburger menus over 20 years ago though.
What is more important is your second point that I sort of endorse hamburger buttons as a good UI element choice with this introduction. To me, this introduction was not meant to be controversial in any way. I believe that hamburger buttons are one of the most recognisable UI elements, and I don’t think that companies like Apple would use them without doing their homework.
That being said, it was not my intent to promote them as such. I didn’t do any profound research on the topic, and this article is not meant for user interface designers, but for developers that want or need to implement such a button because it either fits their use case or because the designers made the decision.
I’ll amend the intro to be more careful in the wording.
You came in a bit hot with your initial comment, but thanks for your feedback :)
Re: Accessible hamburger buttons without JavaScript
#43The good old "hamburger menu". That menu that stores everything designers never knew how to organize it.
Also known as the “app junk drawer”. Terrible design pattern in my opinion, particularly when they’re used in place of a proper menubar in a desktop app.
Re: Accessible hamburger buttons without JavaScript
#44Anchor 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.
You could actually skip the button altogether and just make the checkbox input keyboard focus-able but visually hidden. You also avoid the issues with the hash also, as the user is then directly interacting with the element that toggles the menu. With some massaging (ensuring what is read for screen readers is set and that the visual focus state still appears to be on the hamburger when the checkbox is focused), it works quite well both for screen reader users and for non-mouse users. I don't have a current example (looks like it's been redesigned since I worked on it), but I've done something similar to this in the past on extremely large websites (thousands of views an hour in at least one instance) with much success.
Re: Accessible hamburger buttons without JavaScript
#45Earlier quoted context omitted.
To be fair the OP hides the trigram from screen readers and provides them with the ‘open menu’ label.
No, they did not, they present both "accessible hidden link" and "inaccessible visible label", at least I see no `aria-hidden="true"` in the code [1] on the label right now, I see just: ≡ × So there still remains "readable" structure loosely identical to identical to multiplication sign (With active CSS, only one half would be presented to SR, since the other has `display: none`, but still…) BTW Fact that wording of…
You're right - I guess I assumed they'd added that in the full codepen.
Re: Accessible hamburger buttons without JavaScript
#46Anchor 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.
You can do this:
menu
menu
Re: Accessible hamburger buttons without JavaScript
#47> "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…
Wikipedia has support for different skins, including the old one: https://news.ycombinator.com/item?id=34431533
Re: Accessible hamburger buttons without JavaScript
#48Earlier quoted context omitted.
To be fair the OP hides the trigram from screen readers and provides them with the ‘open menu’ label.
No, they did not, they present both "accessible hidden link" and "inaccessible visible label", at least I see no `aria-hidden="true"` in the code [1] on the label right now, I see just: ≡ × So there still remains "readable" structure loosely identical to identical to multiplication sign (With active CSS, only one half would be presented to SR, since the other has `display: none`, but still…) BTW Fact that wording of…
Oh you’re right, I forgot to add this in the article + codepen. (It’s how the button on the site itself is implemented and I forgot to integrate it)
Re: Accessible hamburger buttons without JavaScript
#49Earlier 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".
And "one design to fit not maximized windows on not high-dpi screens."
The new design vs the old design.
Re: Accessible hamburger buttons without JavaScript
#50everything 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 same stuff, just maybe different techniques.
I don't know if it's still true as I heard this state a few years ago, but at one point the growth rate of new web devs meant that at any given year, more than 50% of all web devs had less than 2 years of experience.