Debunking the myth that mobile viewports do not require a hover state

Hover states are essential on a desktop computer because they provide clear visual feedback to the user, indicating that an element is interactive and can be clicked. They are a core part of the user experience.

However, on a mobile device, a traditional hover state doesn't exist. There is no mouse cursor; the primary interaction is a tap or a touch. A user's finger is either on the screen or it isn't, so there's no direct equivalent to "hovering" over an element.

Given this, and the fact that WCAG doesn't single out hover states, you might wonder why they're needed on mobile devices at all.

The answer lies in reframing the issue. Let's consider WCAG Success Criterion 1.4.10: Reflow, a Level AA criterion that's required for most accessibility standards. The concept of "reflow" is all about ensuring that content can adapt to different screen sizes without creating an accessibility barrier.

Specifically, it states that:

• Content must be able to scale or "reflow" to a width equivalent to 320 CSS pixels.
• The user should not be forced to scroll in two dimensions (both horizontally and vertically) to access all of the content.

Think about how people, especially users with low vision, use websites. When a user with low vision zooms in on a page to 200% or more, their effective "viewport" becomes much smaller. The screen area for a user at 200% zoom is equivalent to 320 CSS pixels.

This means a user with a desktop computer is presented with a mobile layout. Since they're likely navigating with a mouse, the lack of hover states means no visual feedback and a poor user experience.

This is a great example of the unexpected benefits of meeting accessibility guidelines (also known as the Curb Cut Effect). You aren't adding hover states for mobile users; you're doing it for other users who weren't on your radar, like those with low vision who rely on zooming. By making your website more accessible, you improve the experience for everyone.