Hiding content behind hovers

Raise your hand if you’ve ever seen something like this while you’re cruising through the web on your mouse-equipped laptop or desktop computer:

Pretty funny, right? Unless you’re using a smart phone, a tablet, or one of those two-in-one laptop/tablet hybrids without a mouse and don’t realize you’re the butt of the joke.

On a mouse-equipped device, hovering over the above box will reveal the text: Touch-only devices are for LOSERS. I, of course, disagree with that statement. But I’m not sure I can say the same for web developers who utilize hover-revealed content and functionality.

Why is this a problem?

It’s downright neglect of touch-only device users.

Some sites take the awfulness a step further, and hide other essential functionality behind a hover.

In this case, a touch-device user would not just be deprived of the content, they would have no way of clicking through the link. Perhaps the only place the link is located on the site.

This is doubly unacceptable.

Update: Trisha Salas, a member of the WordPress Accessibility Team, points out the lack of accessibility for low-vision users.

This is also true for accessibility. It is terrible UI for low-vision users! https://t.co/UVGXubPrR2

— Trisha Salas ??‍?♿️???? (@trishacodes) April 13, 2016

Low-vision users routinely use zooming capabilities in order to better see content. Note the difficulty trying to read hover-revealed content while zooming in the video below. As you can see, it’s a usability nightmare.

Why do web developers do this?

Admittedly, it looks pretty cool. Content can fade in, pop out, flip over, and be revealed through all sorts of other crazy animation effects.

Mouse-equipped-device users are in the habit of meandering their cursor around the page and hovering over things, so it’s reasonable to assume a user interested in seeing content revealed by mouseover will get to see it. It’s not a guarantee, but it’s at least a possibility.

On a touch-only device, on a website developed with little regard for mobile usability, it’s much less likely, if not impossible.

What if it’s revealed on click too?

It’s certainly an improvement for a touch screen user who previously had no way of revealing the content at all.

When adding click-reveal support it’s no longer a question of ability, but it’s still a question of awareness. If I didn’t outright say “please click me,” would the user have any idea they’re missing out on anything?

Unless they’re like me and randomly tap all over the screen just to see what hidden content I can uncover.

In most practical applications of click-revealed content, there’s no indication that clicking will do much of anything.

Can I detect a touch device and serve an alternative design?

Yes and no and no and yes and yes and no.

It’s not that simple these days, especially with the advent of hybrid laptop/tablet devices.

The article You Can’t Detect a Touchscreen explains the technical reasons as to why touch device detection is not reliable.

You can use a touch screen detection method, just understand that the touch-friendly design may be enabled on a laptop/tablet hybrid, even if there is a mouse functionality available on the computer.

From here, style touch-friendly designs using the .no-touch class. Hopefully your markup is flexible enough to not rely on any further DOM manipulation beyond that.

Can’t I just use a max-width media query to check for touch devices?

Don’t even think about it.

You might have been able to get away with this back when the iPhone was first released. And every touch screen device out there was less than 480 pixels wide.

But those days are long gone.

According to mydevice.io, the Surface Pro and the iPad Pro have device widths of 1024 pixels.

These are pretty desktop-y widths as it is, and it’s not future-proof development to assume that these numbers won’t get bigger as demand for larger tablets grows.

Better yet, just don’t rely on hovers or clicks to reveal content

After all that, you have to ask yourself, is it really worth it?

If you’re going to spend time styling an alternative touch-friendly design, why not just make that the default?

To use the author of the You Can’t Detect a Touchscreen article’s words:

It’s probably just best to avoid relying on hover states in the first place – use them for embellishments.

I couldn’t agree more.

Concluding Rant

While researching this blog post, I found a sparing amount of articles backing up my main point. The only specific references I found were on Microsoft’s website, like in their guidelines for building touch-friendly sites where one of the headings is DO NOT Hide Content Behind Hover.

This is alarming. And it’s a practice that runs rampant on ThemeForest themes to this day. Seriously, just pick out any random ThemeForest theme, start hovering over things, and you’ll see what I mean.

Here’s one, for example. Notice how you need to hover over one of the “Latest Projects” before you can see the project title and link?

Cheap tricks like fancy content-revealing hover effects should never be prioritized over basic usability needs. Touch device users should not be neglected.

If you sell themes with hover-revealed content with no touch-friendly design alternative, and advertise them as “responsive” you should really put an asterisk next to every reference.

Responsive design is more than surface-level adjustments conditional on device width, but also adjustments based on device functionality.