The details element.
<details>
<summary>Menu</summary>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/thing">Thing</a></li>
</ul>
</details>
details {
padding: 0.5em;
border-style: solid;
border-width: 1px;
border-radius: 0.25em;
cursor: pointer;
}Hopefully this will change soon. I’ll amend the article when this will be the case.
Which says JavaScript is required and simplest solution for building this menu. It also states to try to avoid them when possible.
https://adrianroselli.com/2019/04/details-summary-are-not-in...
Now, I found details,& I keep the main page visible all times in a div, & then horizontal accordion styles as Details underneath it for History, Logs & other stuff e.g. https://spa.bydav.in/odo.html (type foo in the box to see page)
"Last Few Decades"? Eh? A decade.. perhaps?
"Every User Immediately"? This is not at all my experience. Perhaps with younger users, but I've seen plenty of people younger than I even stumble over sites where the nav was hidden behind a hamburger menu icon.
This sounds like it was written by someone very much in their own bubble
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 it through the hamburger menu, or use the URL bar. I can't even remember the last time I went back to the ToC when reading a Wikipedia article and this change is utterly incomprehensible to me.
I can't remember going purposely back to the ToC myself, however I often enough scroll over pages to find a section again and there it helps to have the structure visible.
However the nice thing: In your preferences you can pick the style you like. So if you want the old one pick it.
You can also leave feedback with them that "random page" is important (I like that one too!) so they find a better place ...
But the front page just has empty space there?!!??
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 everyone was happy.
I think it's becoming even more confusing now that Google is pushing the ⋮ vertical ellipsis as a hamburger replacement. The last thing the web needs is inconsistent icons.
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.
Google uses a horizontally-scrolling menu bar for Images, News, etc., just above the search results when viewed on mobile: https://www.google.com/search?q=test
The horizontally-scrolling menu bar seems to be:
– Discoverable for typical visual browsers
– Discoverable for screen readers, especially when used with attributes like role="menu" and role="menuitem"
– Fully functional without JavaScript
> 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 <insert unnecessary framework of choice>. 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.
I also use 1440x900 on 24 inch monitors (I'm on the screen for 14 hours a day and don't like eye fatigue.) (1280x720 on 15 inch laptops -- most sites think I'm on mobile so even more clicks)
It’s used by Microsoft, Apple, Youtube... the list goes on. I think it’s not too much of a stretch to say that it is ubiquitous and familiar to users.
That being said, it's not the point of the article. There are definitely reasons not to use a hamburger button. But this article helps you build one if you want it.
I don't recollect ever having seen it on any of the 'small screens' (ie LCDs, etc) I used prior to smartphones.
"Designed and introduced" on the Xerox Star, which almost nobody used. It was quickly forgotten for 30 years, and only came back into use in 2009, according to Wikipedia.
It’s the old ‘three dots signify some sort of button’ pattern. Except these dots hide crucial functionality — think activate your campaign — and just kinda float in the middle of the row, surrounded by other actual buttons, and they don’t even have a border!
My parter figured it out eventually and when she said, hey, I found where that option is … that was a real head-slapping can it be this bad sort of moment.
From LI’s perspective this was days of income they didn’t get from us because we couldn’t figure out how to turn the damned thing on!
Hard to believe how this got through user testing.
But in trying to figure out when they became prominent, I discovered that some dude at Xerox invented them in 1981.
tl;dr "Discoverability is cut almost in half by hiding a website’s main navigation. Also, task time is longer and perceived task difficulty increases."
I have an (admittedly ancient) Android smartphone in my pocket which has dedicated physical menu and back buttons. I don't recall seeing hamburger menus until phone manufacturers started being too cheap to include that menu button.
Now they're everywhere, even (especially) when they're not remotely appropriate. What could be more ridiculous than a touchscreen-oriented menu button in a text editor (looking at you, Gedit) or a VCD waveform viewer (looking at you, GtkWave)?
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 under a navigable heading that they can skip to when they need to access those options.
Meanwhile, non screen reader users are forced to guess what will be behind the ≡ button this time.
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 users are forced to guess what will be behind the ≡ button this time.
The main menu? Which is behind the same ≡ button on most pages on the internet?
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.
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.
So is the ≡ the main navigation menu?
The account options menu?
The preferences menu?
The menu of the application platform that's wrapping the page you're on, rather than the page itself?
The menu showing all the sister companies of the site you're on?
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.
https://adrianroselli.com/2019/04/details-summary-are-not-in...
Anchors navigate. Buttons have effects.
<a href="#something"><button>menu</button></a>
<form action="#something"><button type="submit">menu</button></form>
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 button, insert it into the DOM. Some menus are too big, but most are not and the kinds of sites that need big menus often require interactivity with JavaScript anyways.
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, which removes the awkward general sibling combinator.
Using a checkbox is a hack in that you are using a <input> 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.
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 a custom interactive element. If `<details>` works for you, fine. If it doesn't, you might want to look up ARIA attributes.
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 <details>/<summary> 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.
The error in the console is:
> Cannot destructure property 'supabaseUrl' of 'Re(...)' as it is undefined.
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.
However, it's actually okay to introduce JS for the progressive enhancement to accessibility because ARIA is by definition dependent on RIAs.
In regards to the overall construction of these I also rather like the form:valid hack, rather than the checkbox hack depicted, since the former is more general (in particular, the selectors can be ancestors instead of siblings).