In Praise of the Unambiguous Click Menu

Do you remember the excitement when you first built a hover triggered submenu with pure CSS? (That might have been after reading this article on A List Apart in 2003.) At the time, this was a real CSS trick. To be honest, that was a crazy era .

It's probably like this:

<code></code>

• Page A
  • Page B
  • Page C
  • Page D

 <code>/* 将子菜单相对于父列表项定位*/ .my-menu li { position: relative; } .my-menu ul { /* 默认隐藏子菜单*/ display: none; /* 打开时定位子菜单*/ position: absolute; left: 0; top: 100%; } /* 看，妈妈！不需要onclick处理程序！*/ .my-menu li:hover > ul { display: block; }</code>

Today, we can use an updated technique to improve accessibility of pure CSS menus! With :focus-within , the menu can be turned on and off while navigating with the keyboard.

 <code>/* 不支持IE11 */ .my-menu li:focus-within > ul { display: block; }</code>

Try moving the mouse and Tab keys in the demo.

But since I first learned these techniques, times have changed and so have I. Since then, I have built many websites and learned more about usability, accessibility, and content strategies. Now, I've found that the hover trigger menu is inadequate in all of these aspects. So, a few years ago, I stopped building the hover trigger submenu and instead used the click trigger submenu. (From here, I'll call them "Hoom Menu" and "Click Menu" respectively.)

I think you should stop building the hover menu, too. I'll tell you why.

Hover menu inconsistent

Check out the real menu on a website I built:

Very simple, right? The arrow icon shows us that each item has a submenu except "Home". However, if these submenu appear on hover, there are at least four possible ways for the menu to work, and you may have experienced all four of them.

1. The "parent" menu item at the top is linked to one page and each submenu item is linked to another page. For the example above, Services will be a unique page, and so will each link in the Services submenu.

But before I knew it, a second very common pattern emerged.

2. The parent has href="#" — not even href at all? — and the only valid link is in the submenu. In our example, "service" is still a link, but nothing happens when you click on it.

This inconsistency - is the parent linked or isn't it? ——When I observe people using websites, it causes a lot of confusion. Some people skip the useful top-level pages directly, assuming that these items are not links. Others, however, think that top links are pages and try to click on them.

This leads to the third and fourth modes you will encounter. I guess these patterns evolved from trying to make up for the confusion caused by the first two settings.

3. The parent and the first child menu item are linked to the same page. Worse, the parent and the first child menu link have different link text, violating the WCAG 2.1 AA level accessibility standard.
4. Parents link to pages that contain useless fill content or only links in the submenu. The page itself has no practical purpose for anyone who visits it.

The last two configurations waste time for those who know that the parent is a link because they contain redundant or useless content.

Here is a chart showing all four possible hover menu settings.

It is reasonable for visitors to be confused about the hover menu

Regardless of how we implement the hover menu, our visitors may reasonably want to know:

1. Can I click on the parent?
2. Will the parent link to the same page as the first submenu link?
3. Even if the parent is a unique link, is it worth checking for me?

This leaves us with no good choice. It makes it impossible to satisfy Jacob's law of usability, that is, "users want your website to work the same way as all other sites they already know". There is no standard implementation on the hover menu, so we need to do something different to provide a consistent user experience.

How about the "Split Button" menu?

The least common menu type I've seen might be designed using the "Split Button" where the parent is a link, a separate drop-down icon to open and close the menu. Twenty Fifteen's default WordPress theme uses this mode. Because it's very uncommon, I found that visitors often ignore top page links, and research shows that users don't think tags and icons are individually clickable.

So, what is the better option? Click to trigger the submenu!

Click the menu to rescue

Instead of relying on hover interactions or other "creative" (and confusing) solutions, build a menu with parent-item buttons that show and hide submenu when clicked. This immediately resolves the hover menu issue, as the click menu works clearly .

• Website visitors must click on the parent to view their child menus.
• All links are included in the submenu except for top items that do not have submenu (such as "Home"). We'll handle these top pages later.

When you think about it, click menu is actually what we already expect in most other situations:

• Using a touch device? Hovering there isn't really something.
• Use the application menu (e.g. "File", "Edit", etc.)? These are almost never displayed on hover!
• Use anything other than the mouse? Pressing the ENTER key or activating a link with any type of switch control is more like clicking, rather than :focus similar to :hover .

Regardless of your device or input mode, "click" is a more general and reliable way to interact. Let's use it to make our website menu great!

Switch to the click menu

My intuition tells me that many websites have recently switched to the click menu. Join the party! As more and more websites make changes, people will once again develop simple and useful expectations about "how the website works" (and thus satisfy Jacob's law).

When you make this change for the first time, it does have some visitors that may still expect the hover menu. If you ask them, they might even say they prefer the hover menu. However, I can tell you based on how people observe people use click menus that everyone can figure it out and adapt quickly.

And don't just listen to me! The navigation mode of the United States Network Design System (USWDS) uses the click menu. Here are their statements:

Avoid using hover to expand the drop-down list. Hovering is difficult for some users and does not work on the touch screen. The drop-down menu should be expanded when clicked or used to navigate using the keyboard.

Bootstrap also uses the click menu for the same reason:

It really boils down to user intentions . The purpose of the hover state is to indicate that something is clickable (underlined text)… The purpose of the click is to actually perform certain operations, taking clear actions. Opening the drop-down menu is an explicit action and should only happen when clicked.

From the same post, here is a good point:

The caret in the drop-down link is equivalent to the underscore of the link: it provides some tips on what happens when clicking on this element. But don't mistakenly think that it provides enough information to pop up the drop-down menu when hovering.

So, this is not to say that we are exploring unknown areas. And, there is another good reminder for the UK government design system: maybe you don’t need a submenu at all! Their menu is just a series of links, using the link grid and accordion on the page to help visitors navigate. Heck, you won't even find a submenu on CSS-Tricks!

Clicking on the menu has the added benefit!

The more you use the click menu, the more benefits you will find:

• You can decide whether you need a category/overview/login page…or not! Instead of forcing content to match the menu structure, where links are the parent of other links, let your content strategy and information architecture determine what types of pages you need and how to tag them. If an overview of your services is helpful to your visitors, please use Service Overview or All Services as the first item in the Services submenu.
• The submenu remains open until closed. There is a nasty way to hover menus that disappear when people move the cursor or even just try to click on the submenu link. This is especially true for "Fly Out" rather than a child menu located under the parent. The persistence of click menus makes the experience more "stable", so users trust the interface and don't feel frustrated.
• Persistent submenu behavior is more important for large menus. When visitors need more time to view submenu content, they cannot afford to accidentally close the menu.
• JavaScript is the same for the Mobile and Desktop menus. Whether the menu is hidden behind a hamburger or visible on a mobile device, the interaction is always the same. I just need to change my CSS to make a responsive click menu.

Build a click menu

When I set out to build my own accessible click menu script, I found that there wasn't a single standard to do this. My own ideas and code are mainly affected by the following:

• Adrian Roselli's "Link Disclosure Widget Navigation"
• "Title Demo" for American Web Design Services
• "Menu Design: A List of 15 UX Guides to Help Users" by Nielsen Norman Group
• "Sample Disclosure Navigation Menu" in ARIA Creative Practice

Key points in my research on implementation:

• The element you click to display the submenu should be<button></button> , because it does not link to the page.
• Use aria-expanded (in<button></button> ) to convey the open and close status of the submenu.
• Use display: none or visibility: hidden so that keyboard users cannot access them when the submenu is closed.
• aria-controls are bad, but you'd better add it.
• Do not use role="menu" (and the entire ARIA menu mode) or aria-haspopup . These feel relevant, but they are not suitable for building navigation menus.
• Close the open submenu when:
  • Another submenu opens
  • User click outside the menu
  • When the focus is in the open submenu, the user presses the ESC key. (Not all users expect this, but I think it's a nice feature.)

Since clicking on the menu requires JavaScript, we should consider how to step up this menu if JavaScript fails for any reason. After all, our classic hover CSS tricks are still useful for certain things!

I first built the click menu as a pure CSS hover menu which uses li:hover > ul and li:focus-within > ul to display the submenu. Then I create using JavaScript<button></button> Element, set the aria attribute, and add event handlers. This means that the menus are still mostly valid without JavaScript and work well with the pure link menu built in my preferred CMS WordPress.

You can check out the scripts I'm using, but I'll first admit there may be better scripts. Importantly, you should test it with real users…and stop using the hover menu. ?

The above is the detailed content of In Praise of the Unambiguous Click Menu. For more information, please follow other related articles on the PHP Chinese website!