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.
Accessible hamburger buttons without JavaScript
101–110 of 154 posts
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…
But the front page just has empty space there?!!??
Re: Accessible hamburger buttons without JavaScript
#103Earlier 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…
Re: Accessible hamburger buttons without JavaScript
#104Earlier 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.
(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
#105Earlier 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…
Why not both? Genuine question.
Re: Accessible hamburger buttons without JavaScript
#106Earlier 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?
Re: Accessible hamburger buttons without JavaScript
#107Proof 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…
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
#108I 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…
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…
> 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.