There's a lot more to this than just "a little delay" to avoid accidental triggers.
Good menus are complex. In desktop toolkits, there is a lot of logic to ensure they are accessible and don't behave in annoying ways. For example, a high quality menu will have a certain leeway to trigger into and out of submenus so that you don't accidentally drift into the incorrect submenu should you make an error of a couple of pixels while navigating them. They will have various delays and margins in place so that you are able to move your mouse in straight lines rather than make awkward 90 degree turns.
A good menu system will also be navigable with a keyboard-only and will have access keys to quickly jump to items within it.
Everybody who is reinventing the wheel because they see a menu as a mere "styled list of links that shows on hover" is missing out on the decades of learned UX that desktop systems have gone through. I sigh whenever I read, as I have many times in these comments, about making menus in CSS so that it's accessible to the 0.001% that doesn't use JS, while shutting off the much more real percentage of users that can't use a mouse (users that don't generally have a choice in the matter - unlike those turning JS off).
1.1% of users don't see JavaScript enhancements. Most because it doesn't load, not because they've disabled it. Also, some people use browsers that don't support JavaScript, or their ISP filters JavaScript, or a whole bunch of other things.
I'm not endorsing making menus in CSS. I'm just saying that it isn't "accessibility vs. people who turn JS off".
As the link says: progressive enhancement is the solution to this.
That article is very nice but you're not reading it correctly if your takeaway is that "1.1% of users would benefit more from a CSS menu than from a JS menu". GDS is the UK government - a large portion of that 1.1% is likely not loading the CSS either. Bots, crawlers, rss readers, etc. The 0.2% number is much closer to what you're looking for.
And to repeat: Those that disable javascript have a choice in the matter. Accessibility isn't a matter of choice.
I didn't take that from it. See "I'm not endorsing making menus in CSS." I'm endorsing progressive enhancement.
Those that disable JavaScript do have a choice in it, but those who don't have JavaScript because it has been disabled for them, or because they are using a device that doesn't support JavaScript, don't have a choice in the matter.
Good points, but surely all that knowledge could be encoded once into some CSS attributes, rather then rewritten every time for every JavaScript framework on every site?
A "correct" fix would be to build stylable core UI elements from the chrome itself. Leave the accessibility to the browsers (and by extension their UI toolkit). For this, you need a standard `<menu>` element, which is in HTML5.1:
Could be. And polyfilled for the monstrosity that is IE. That's a huge pie in the sky - whereas with JS, that's something which has already been here for at least a decade.
