The good old "hamburger menu". That menu that stores everything designers never knew how to organize it.
Accessible hamburger buttons without JavaScript
31–40 of 154 posts
Re: Accessible hamburger buttons without JavaScript
#32Proof 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. 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 next control. That’s how most OS/application keyboard accessible menus work - they don’t have ‘expand’ and ‘collapse’ affordances at all.
Re: Accessible hamburger buttons without JavaScript
#33Proof 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. 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 astral Unicode from exotic blocks.
Re: Accessible hamburger buttons without JavaScript
#34Earlier 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…
To be fair the OP hides the trigram from screen readers and provides them with the ‘open menu’ label.
Re: Accessible hamburger buttons without JavaScript
#35Earlier quoted context omitted.
I know it was originally invented way back when (in Xerox Parc?), but it did not become 'de facto' on small screens decades ago, that's just a mangling of perspective. I don't recollect ever having seen it on any of the 'small screens' (ie LCDs, etc) I used prior to smartphones.
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 and have always come away not relying on them precisely because they don't seem to have the blanket comprehension amongst users you seem to think they do.
Re: Accessible hamburger buttons without JavaScript
#36> "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 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.
Re: Accessible hamburger buttons without JavaScript
#37Earlier 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.
It seems people don't explore at all. There's no "I wonder what would happen if" impulse, or there's an "I'd better not just in case" worry.
Re: Accessible hamburger buttons without JavaScript
#38Learn how to create an accessible hamburger button with pure HTML and CSS and why that is important.
providing complete copy pastable code with good default styling would help improve the article
Re: Accessible hamburger buttons without JavaScript
#39Earlier quoted context omitted.
> 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…
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:
≡
×
identical to multiplication sign
BTW Fact that wording of the link in the article pointing to the codepen is "this codepen" is also … not right.
Re: Accessible hamburger buttons without JavaScript
#40Except 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
details {
padding: 0.5em;
border-style: solid;
border-width: 1px;
border-radius: 0.25em;
cursor: pointer;
}