Working out a compromise for your site between mouse and touch controls can sometimes be tricky. Desktop users can hover their cursor, but touch device users are either touching or they’re not (save for a few motion tracking devices which aren’t yet widely adopted). A lot of mobile browsers help us by trying to handle hover interactions intelligently, sometimes interpreting a touch event as the hover equivalent. But this support isn’t universal.

Menu items with a dropdown are a great example of where this can get tricky, so I’m going to use them as an example to look at what options we have for improving user interaction and experience.


Submenu Hovers

It’s quite common to see an item in a site’s navigation that, when you hover over it, has a few extra options appear. As well as a handy way to tuck away page links and de-clutter your primary navigation, it also implies hierarchy and site structure in a visual way.

Cursor hovering over a menu item of "Articles", with a dropdown submenu showing.

For example: hovering over “Articles” in a site’s main menu and getting a submenu of “News”, “Reviews” and “Blogs” gives a simple but clear indication that they are subcategories of article that can be browsed individually.


The Problem

“Articles” also tends to be a link in this scenario. There will often be a landing page showing items from all three categories, and you can get there by ignoring the submenu and clicking the main menu item itself.

Unfortunately, on a touch-screen device this gets a bit messy. Tapping “Articles” in our example would cause some mobile browsers* to show the submenu, but then continue interpreting the tap event as a click on the link itself. The submenu would only be visible for a moment before the browser attempted to whisk the user away to the primary link item. Your touch users aren’t able to access the submenu (unless they’re quick), and even if you have other links to those pages elsewhere it’s not a great user experience.

* Tested on the stock Android 4.1 browser and latest mobile versions of Firefox and Chrome at the time of writing. Mobile Safari does handle hover and click on the same element quite well, but that only accounts for around 55% of mobile users (as of January 2014, source:


Complex Solutions

There are a number of ways you could replicate Safari’s default mobile behaviour. Detecting your user’s browser, and then changing the way the interface works with JavaScript, is one likely scenario. You could find out whether the user is on a mobile device or not, check their browser, and then add some additional functions. Some of the solutions I’ve seen online include interrupting the first touch event, or removing the link and then reapplying it after the first touch.

While this is technically “responsive”, it feels a little clunky. On mobile, using up extra resources and calling additional scripts or functions has a more noticeable impact on page speed and performance than it would on a desktop machine. It also feels like creating two different methods of interaction, and then switching between them with your script. On top of that, browser detection can prove tricky to implement reliably with the ever-increasing range of devices and versions on the market.

Here’s the good news. You don’t need all that.


The Simple Solution

You don’t need to bring out the JavaScript libraries or convoluted queries to tackle the issue. Let your hover be a hover, and your links be links.

Don’t make the menu item with the hover event a link in addition to the dropdown functionality. When tapped or hovered over, the “Articles” link can fade out a little and give prominence to the dropdown menu it reveals. These subsections are relevant – why else put them in the menu? – so let’s prompt the user to choose one.

A menu item of "Articles" that's greyed out, with a dropdown submenu showing.

Some simple hover styling can subtly guide the user from the menu item into the submenu.

Hovering over a link tends to happen when you’ve already decided you’re going to click it. Is it clear to suddenly present the user with more options right at the last moment? If our “Articles” menu item is just a hover, we can subtly guide the user in a brief transition from the main menu item to a submenu. If they’re a little hasty with the click, nothing happens. They’re not whisked off to another page before they realise there’s more options available.

The best part about this technique is that the browser on your touch device doesn’t have to figure out what it’s supposed to be doing with the menu item, because there aren’t two conflicting options. You’re simplifying the main menu item down to one interaction instead of two. At first I thought, “is this cheating?”. Then I started thinking about it in a more semantic way.



1. relating to meaning in language or logic.

Having clear, accurate naming conventions is a trend that’s becoming more popular in the development community, most recently with the introduction of semantic elements in HTML5. It helps with clarity mostly for developers, but that clear and consistent approach feeds back into UX design for users.

So, is it a hover or is it a link? Having cursors we can hover with has let us double up on clicks and hovers in the past. There’s no need to define the element as one or the other, because it can have a dual purpose. Our hardware – the computer mouse we find so familiar – has allowed us to do this. The semantics of whether or not a menu item is there to be a link, or to hover over for some other kind or interaction, hasn’t really been an issue. But should it be?

Multiple forms of interaction on an element aren’t a bad thing; often an element will primarily be a link, with hover effects purely as a secondary feature. We can perform appealing visual animations, popup hints on interactive elements, or even add an extra level of interaction on the element. But when one action (click) directly involves and overrides another independent action (hover) it’s not just a problem for touch browsers; it’s not particularly clear for users either. Both have a primary purpose, and the type of hardware where those purposes collide is becoming ever more prevalent.


Keeping the “Articles” Page

“But I still want a page for all the articles!”, I hear you cry. That’s often a perfectly reasonable idea – sometimes you may want a landing page that mixes together all three categories, for browsing a broader range of content. But you don’t need “Articles” to be a link to do that. The solution?

A menu item of "Articles" that's greyed out, with a dropdown submenu showing and "All Articles" selected.


Makes sense, doesn’t it? You’re keeping the semantic separation of hover and link between your main menu and submenu, but the awesome landing page for all three article types that you created is still accessible. It doesn’t need to be any more complicated than that.


You Can Hover Your Cake and Click It

If you really want to keep your main menu item as both a hover with a submenu and a clickable link (and you don’t mind those extra JavaScript libraries or craft complicated browser checks) there’s still room for a bit more clarity. One of the issues with a main menu item that’s both a hover and a link, is that your user might not realise there’s a submenu hiding away until it’s too late.

While it may not seem like a big deal at first, users with a slower connection may especially find this frustrating if they have to wait for the link they clicked to finish loading before they can use the submenu they saw just a moment too late. To stop your desktop users jumping the gun, a simple visual cue is a surprisingly effective UX technique.

A menu item of "Articles" with a downward arrow icon, and a submenu showing.

A little icon can go a long way.

It may not seem like much, but you’re suggesting to the user that there’s something more to a particular menu item. It may make them pause just long enough to see the full range of options you prepared for them. Sadly it won’t help touch screen users, as it doesn’t address the technical limitations, but it’s a useful way to make your navigation structure more obvious to your visitors.


Even More Options

Another alternative is to have two menus; one for desktop, and one for mobile. You’ll still need to do some kind of browser or device checking to figure out which one to display, but that can prove a bit simpler than trying to change the functionality of the same menu item from hover to touch.

A separate mobile menu is usually on page load, and displayed when a menu button is toggled. The advantage of hiding it from the start is that it can be bigger and take up more page space when you open it, as you know the user actually wants the menu and it’s not getting in the way of them reading your content.

I like this solution and think it works well for mobile, but depending on how many submenu items you have it could still get to an unwieldy size. Plus if you’re going to include links in this menu that were otherwise submenu items, depending on your CMS this might require you to make a second menu without the link hierarchy.



In the end it’s a personal preference, depending on the development you’re willing to undertake and the kind of users that visit your site. Coming at it from both a developer and a user perspective, I’ll certainly be thinking more about the hover / click interactions I use in combination with one another.

Hopefully this blog post has highlighted that there’s plenty of different ways to tackle the issue, both from a front-end and back-end perspective. If you’ve found this helpful (or even if you disagree!), comment below or get in touch. Thanks for reading!