Dropdown Menu UX for the Mouse, the Finger and the Keyboard
A dropdown menu has three kinds of visitor, one with a mouse, one with a finger and one with a keyboard, and most menus only work for the first. What I built into this site's Capabilities menu, and how to test yours in a few minutes.
Mike Lopez
Designs and builds websites and B2B software
On this page
I think dropdown menu UX comes down to three visitors at once, the one with a mouse, the one with a finger and the one with a keyboard, and most of the dropdowns which I test only work for the first of them. When I added a Capabilities menu to this website in October, a button which opens a panel of six pages, I wrote down every way that a visitor could open it, reach a link and close it again, and the list was longer than the menu.
Each item on that list is small, a wait of a fifth of a second or an invisible strip under the button, but I believe the small ones decide whether a visitor reaches the page which they came for, so this post goes through them in the order that a visitor meets them.
The gap between the button and the panel
The panel on this site opens 30px below its button, which looks right, but a pointer which leaves the button has to cross those 30px of empty space before it reaches the first link, and a simple hover menu closes the moment that the pointer leaves the button. I suppose that is the most common dropdown problem on websites, a menu which closes in the gap and has to be opened again, sometimes three or four times before the visitor gives up and scrolls through the page instead.
The fix on this site is a strip which belongs to the panel and fills the gap, so the pointer stays inside the menu all the way down, and it’s really what WCAG 2.2 criterion 1.4.13 asks of anything that appears on hover, that a visitor can move the pointer over the new content without it disappearing.
A short wait before it closes
Pointers mostly travel in a slight diagonal, so on the way from the button to a link lower down they often brush past the edge of the panel for a moment, and a menu which closes instantly punishes that small wobble. The panel here waits 200 milliseconds after the pointer leaves before it closes, which is too short for a visitor to notice when they mean to leave and long enough to forgive the wobble, and the wait is cancelled as soon as the pointer comes back.
I would keep that wait short, because the same criterion also asks that hover content can be dismissed, and a panel which lingers for a second or more keeps covering the page after the visitor has moved on to it.
A click which opens it, and a click which keeps it open
A phone or a tablet has no hover, so the button has to open the panel on a tap as well, and this site only listens for hover on devices which report that they can hover. The trap which I found while testing was the visitor with a mouse who hovers, sees the panel open and then clicks the button anyway, because a click toggles the panel, so that first click closed the menu which the hover had just opened. On this site a panel which was opened by hover stays open on that first click, so the click confirms what the visitor already sees.
The keyboard and the Escape key
A keyboard visitor reaches the menu with the Tab key, so the Capabilities control is a real button which opens the panel with Enter or Space and tells screen readers whether it is open through aria-expanded, which is the pattern that the W3C’s disclosure navigation example recommends for site menus. That example also explains why a site menu should leave out the menu role, because the role promises the arrow-key behaviour of an application menu, and a list of links works best with the Tab key which visitors already use.
Escape closes the panel and puts the focus back on the button, so the visitor carries on from where they were, and moving the focus anywhere outside the menu closes it too. The button also shows the same focus ring as every other control on the site, which I described in my post on website button hierarchy, and each link in the panel marks the page which you are on, so a visitor who opens the menu from the Web Designer page sees that page highlighted among the six.
The menu for each visitor
Put together, the menu has one way in and two ways out for each kind of visitor, and each row of this table has a failure which I have seen on a live website.
| Visitor | Opens the menu with | Closes it with | What usually breaks |
|---|---|---|---|
| Mouse | Hover, or a click | Leaving for 200ms, or a click outside | The panel closes in the gap, or the first click closes it |
| Touch | A tap on the button | A second tap, or a tap outside | The menu only listens for hover, so a tap opens nothing |
| Keyboard | Enter or Space on the button | Escape, or moving the focus away | The links are out of reach, or Escape leaves the focus nowhere |
| Phone menu | A tap on the group | A second tap on the group | A desktop panel squeezed onto a small screen |
On a phone
On a phone the same six links fold out under Capabilities inside the full-screen menu, which also holds Projects, About and Journal, so a tap opens the group in place and a second tap closes it, and everything works without hover or a panel floating over the page. I think a phone menu which simply lists its links is easier to use than a copy of the desktop dropdown, because the visitor scrolls one list with one thumb.
Where to start
I would open your own site on a laptop and move the pointer slowly from each dropdown button to the last link of its panel, then do it again quickly and on a diagonal, then open the same page on your phone and tap the button, and finally press Tab until the button is focused and try Enter and Escape. If the panel closes on the way down, ignores the tap or leaves you unsure where the focus went, that is the part of the menu to fix first, and in my experience most menus fail at least one of the four.
Frequently asked questions
Should a dropdown menu open on hover or on click?
Both, I think, because hover is quicker for a visitor with a mouse and a click is the only way in for a visitor on a touch screen or a keyboard. A menu which opens on hover should still open on a click, and a click on a menu which hover has already opened should leave it open.
How long should a dropdown stay open after the pointer leaves?
Long enough to forgive a pointer which brushes past the edge, and short enough that the panel is gone before the visitor looks back at the page, which on this site is 200 milliseconds. A strip which fills the gap between the button and the panel does more for a visitor than a longer wait.
How many links should a dropdown menu have?
As many as a visitor can scan in one look, which for a list of plain links is mostly six to eight. Past that I would split the links into labelled groups or give the section a page of its own, and the labels matter as much as the count, which is why I write them before the design, as in website copy before design.
Is a dropdown menu bad for accessibility?
A dropdown is accessible when it is a real button with aria-expanded, opens with the keyboard, closes with Escape and stays open while the pointer moves over it. The problems mostly come from menus which open only on hover, or which give a list of links the application menu role.
