The case against hover

Hover-only interactions have been the wrong default for over a decade. Most sites still ship them.

The pattern is familiar. The designer adds a tooltip on hover. A reveal on hover. A submenu that opens on hover. A control that only appears on hover. The interactions look fine on the designer’s MacBook. They are absent or broken on every touch device, which is now the majority of web traffic.

Touch devices do not have hover. They have tap, which is the equivalent of a click, and they have long-press, which is the equivalent of a right-click. They do not have a separate “the cursor is over this thing but not pressing” state. The hover-only interactions, on a touch device, either do not happen at all or fire on the first tap and then fire the actual click target on the second tap, which is worse.

The pattern of fixes that does not work.

Detect touch and hide the hover affordance. This sounds reasonable and breaks on the increasing number of devices that have both touch and a mouse, like a Surface or an iPad with a Magic Keyboard. The user might be using either input method, and the device cannot tell which.

Use a media query for hover (@media (hover: hover)). Better, because it asks the right question, but still not enough on its own. The hover affordance is now correct for the input method, but the touch user is left without an equivalent affordance for whatever the hover was meant to reveal.

The pattern that does work.

Treat hover as a progressive enhancement on top of an interaction that already works without it. The user can tap a button to open a menu. The hover, if hover is available, is a quicker way to do the same thing. The functionality does not depend on it. The visual affordance does not depend on it. Tested on every project the studio has shipped in the last two years.

Specifically.

Tooltips that contain essential information are not tooltips. They are part of the page. Show them by default, or behind an explicit click-to-reveal, or in a modal. Hover-only tooltips are wishful thinking on devices that do not have hover.

Submenus on hover should also be submenus on click. The hover is a shortcut. The click is the contract.

Controls that only appear on hover should also appear on focus, and should also be reachable on touch via a small explicit “more options” affordance, like a kebab menu icon. The hover is a courtesy. The accessibility is in the explicit affordance.

The CSS pattern, for what it is worth.

/* Show by default, on touch */
.menu-trigger:not(:hover) .submenu { display: block; }

/* Hide by default on devices with hover, reveal on hover */
@media (hover: hover) {
  .menu-trigger:not(:hover) .submenu { display: none; }
  .menu-trigger:hover .submenu { display: block; }
}

The principle is older than touch devices. Sites have always been used in contexts the designer did not anticipate. Hover is one of the first interactions a designer learns and one of the easiest to over-rely on. The studios that ship sites that work in the actual conditions the audience uses tend to treat hover as a shortcut, not a contract. The studios that ship hover-only interactions tend to also ship sites that the audience finds harder to use than the designer realises.

For the canonical reference on the input-method matter, the MDN entry on @media (hover) is the clearest treatment. Ahmad Shadeed’s writing on hover and Eric Bailey on input modalities are both worth reading on the subject. Caniuse for hover shows the support matrix at any given time.

If you are designing in 2024 and your interaction depends on hover, the interaction is broken. Ship something else.