Make every menu, detail and button work by tapping, with hover as an extra for mouse users only. Open menus on tap, show important information without hovering, and make targets large enough for a finger.

Designed for a pointer

Many sites were designed on a desktop computer with a mouse, by people who checked them on the same machine. It shows in small ways.

The menu opens when the pointer rests on it. A photograph reveals its caption when the pointer passes over.

A price appears in a small box under the pointer. The close button on a pop-up is the size of a full stop.

None of that works the same way under a finger, which cannot rest above the screen. It touches or it does not.

More than half of web traffic now comes from phones, with tablets and touchscreen laptops adding more.

Where hover breaks

The first is the one that hides whole pages. When a top menu item is both a link and its submenu's trigger, a tap may follow the link, leaving the pages beneath unreachable from the menu.

What a touch screen does with hover

Browsers on touch screens try to help. Safari on the iPhone often treats the first tap on something with a hover effect as the hover, and only the second as the click, so visitors must tap twice without being told.

That rescue is inconsistent. It depends on how the hover was built, and different browsers guess differently, so the same menu may open on one phone and follow the link on another.

A design that relies on the browser guessing correctly is not finished.

Touch is not only phones

A separate mobile menu does not solve it.

Tablets show the wider layout, and so do touchscreen laptops, including the ones that fold into tablets. Their owners switch between trackpad and finger in the same visit.

Apple has also said that iPads will ask for the desktop version of websites by default this fall, bringing the wide layout, hover menus and all, onto screens with no mouse at all.

Screen width says nothing reliable about whether there is a mouse. The wide layout has to work with fingers too.

Menus that open on tap

The reliable pattern is simple. A menu item with a submenu opens it when tapped or clicked, and its own page, if it has one, appears as the first item inside.

Hover can still open it for mouse users as a convenience, as long as nothing depends on hover.

A small arrow beside each such item shows there is more beneath it, and the menu should close when the visitor taps elsewhere.

A worked example

A community theatre company staging five shows a season had a site designed on a large screen three years ago.

Its season page showed the five show posters in a grid. Moving the pointer over a poster revealed the dates, the venue and a Buy tickets button.

The main menu opened on hover. Its Tickets item was itself a link to a general box office page, with subscriptions and gift certificates in the submenu beneath it.

On phones and tablets the posters were just posters; some taps revealed the dates and some did nothing. The box office took a steady run of calls asking when shows were on.

The subscriptions page could be reached from the menu only by visitors who happened to tap twice.

The fix kept the grid, printed the dates and venue under each poster, and made the ticket button permanent. Tickets became a button that opens its submenu, with Box office listed first.

Information that hides until you hover

If a caption, a date or a price matters, show it. Hidden until a pointer arrives, it is invisible to touch users, to keyboard users and to anyone scanning quickly.

Product grids should show the price and the main button without hovering. Hover can add a second photograph for mouse users; it should not hold back what is needed to buy.

Tooltips usually mean a label is unclear. Rewrite the label, or put the explanation under the field where everyone can read it.

Keyboard users meet the same wall, since a keyboard cannot hover either, and WCAG 2.1 added guidance on content that appears on hover.

Targets sized for a finger

A fingertip covers far more of the screen than a pointer. Apple's design guidelines suggest touch targets at least 44 points square, and Google's suggest 48 density-independent pixels: roughly the same size on screen.

The usual offenders: tightly stacked footer links, social icons, pop-up close buttons, slideshow dots and booking calendar days.

Spacing matters as much as size. Two small links side by side get tapped by mistake, and the visitor lands on the page they did not want.

Testing without a mouse

Put the mouse away for ten minutes. Use the site on a phone, on a tablet held sideways, and on a touchscreen laptop if anyone in the office has one.

Try every menu, product and form, and the close button on anything that pops up. Then use only the keyboard, pressing Tab to move between links.

Write down everything that needed a second tap, a guess or a zoom. That list is the work.

The counter-case

Hover is not the enemy.

On a desktop with a mouse it gives useful feedback: a button that changes colour under the pointer confirms it can be clicked. Keep that.

Tools used almost entirely at a desk, such as a trade ordering portal, can put mouse users first, if nothing breaks under a finger.

For any page customers use, though, treat hover as decoration and touch as the normal case: menus that open on tap, important information shown, targets a finger can hit.

The mouse-free test

  1. Use the site without a mouse for ten minutes.
  2. Open every menu by tapping it.
  3. Show captions, dates and prices without hovering.
  4. Make top menu items open their submenus.
  5. Enlarge small targets and space them apart.
  6. Replace tooltips with clearer labels.
  7. Test with the keyboard using the Tab key.

Step four is the one that restores missing pages. A menu whose top items act as links on touch screens hides everything beneath them, and nobody editing the site notices, because they all use a mouse.

The other half of making pages work on a phone is covered in pages that make visitors pinch and zoom.

Frequently asked questions

Why do hover menus fail on touch screens?

A finger cannot hover; it touches or it does not. Browsers guess what a tap should mean, and when a menu item is also a link, the guess often follows the link.

Is this only a problem on phones?

No. Tablets and touchscreen laptops show the wider layout too, and iPads will soon ask for desktop sites by default. Screen width does not tell you whether there is a mouse.

How should a dropdown menu work?

Tapping or clicking an item with a submenu opens it, with that item's own page listed first inside. Hover can open it too, as a convenience for mouse users.

What information should never depend on hover?

Anything a visitor needs to decide: dates, prices, captions, and buttons such as add to cart or buy tickets. Show them, and let hover add extras.

How large should touch targets be?

Apple suggests at least 44 points square and Google 48 density-independent pixels, roughly the same size on screen, with space between neighbouring links.

Does hover-only content affect accessibility?

Yes. Keyboard users cannot hover either, and WCAG 2.1 added guidance on content that appears on hover or focus. Having less of it is the simplest answer.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Menus that only open under a mouse?

Send us the address. We will test your site with fingers and a keyboard and list what needs changing.

Start a Conversation