Using a hover/dropdown menu on a touch screen can be problematic. A mouse pointer lets you mouseover/hover a link without activating it, but when tapping a touch screen with your finger both the hover and click actions are fired. Consider the following example (based on the classic Suckerfish dropdown menu):
Tapping the top level link opens the submenu as if you hovered it with a mouse, but it also loads the top level link's URL as if you clicked it with a mouse --usually before you have time to tap any link in the submenu (depending on Internet connection speed). The result is a submenu that's inaccessible to touch screen users, but may still confuse them by opening briefly before the tapped top level link's URL is loaded.
Besides not using hover menus at all, what can you do about this problem? Here are two ideas for workarounds:
If the submenu is inaccessible to touch screen users, why not remove it permanently so they won't be disturbed by it? Instead they can follow the top level link to its destination page, where a fallback menu should be provided. This is currently my preferred solution, at least if most visitors use mouse pointers.
When a touch screen user taps the example menu, the javascript ontouchstart event calls a script that removes the submenu. Since ontouchstart does not fire for those using a mouse, they can still use the submenu.
Keyboard navigation only works on the top level link in most desktop browsers, but if the submenu is hidden with position: absolute; left: -999em; or opacity: 0; the browser still tabs through all the hidden submenu links, which is confusing and annoying. Here are two different ways to prevent that:
display: none; instead of positioning offsets. Note that display: none; is said to make content inaccessible in screen readers like JAWS, but if the top level link's destination page contains a fallback menu that shouldn't be a big issue.In this version all real links are placed in the submenu, which is opened by hovering/tapping the top level LI element or checking its checkbox. This way the submenu can be opened by mouse pointer, touch screen and keyboard.
If the text is very small in a touch screen browser, it's possible to accidentally tap the first link in the submenu by mistake at the same time as you open the menu.
Keyboard navigation is supported thanks to the checkbox, which combined with the CSS :checked pseudo-class opens the submenu. The checkbox' LABEL element is given a CSS outline styling, to make it appear as a focusable element (but in reality it's the checkbox that has focus).
Both the above workarounds should work in desktop browsers, but I've only tested with a few mobile browsers, and not with any touch screen laptop. The CSS used for keyboard navigation in the second dropdown may not work in older Webkit (Safari and Chrome) browsers.
Don't test if the browser supports touch events in general, since some computers (like laptops) may feature both a touchpad and a touch screen. The user of such a computer may prefer to open a dropdown's submenu with his touchpad instead of being forced to use the more limited touch screen version of the menu.
Don't sniff for small screens (with e.g. media queries), assuming that touch screens are always small. They can be large as well, such as on laptops.
published: Dec 3, 2015
last modified: Jan 26, 2017