If you’re thinking about using hover actions on a website, mobile app, or web app, make sure you’re using them in an accessible way.
Hover actions (or “mouseovers") are exactly what they sound like: Actions that are triggered when the user positions their mouse over an element. For example, a webpage may use CSS to display a glossary definition when a user’s mouse hovers over a highlighted word. That can improve experiences by giving users more ways to engage with the content.
You might also use hover actions to trigger a simple style change. Hovering over a button might change the button’s color scheme slightly, which can help the user understand that they’re meant to click the button.
The problem with using hover actions is that many people don’t use a mouse to browse the internet. People might use a keyboard alone, touchscreen, or assistive devices that don’t support hover interactions — and if a website has important functionality that can only be triggered with a mouse, that’s a violation of the Web Content Accessibility Guidelines (WCAG).
Here’s what developers should know when creating interactions that trigger on hover.
Per WCAG Success Criterion (SC) 2.1.1, all functionality of content must be operable through a keyboard interface, except where the function requires input that depends on the path of the user’s movements (for example, the drawing feature on an art app).
To simplify that a bit: For hover actions to be accessible, they must also be triggered in some other way (most commonly, when the user positions their keyboard focus over the same element).
Developers might violate this rule by accident. Hover actions are typically implemented with the CSS :hover pseudo-class, and some devs mistakenly assume that style changes triggered by :hover will also apply to keyboard focus.
You can quickly check whether hover actions comply with WCAG SC 2.1.1 by doing a keyboard accessibility test:
It’s worth noting here that if you’re simply styling buttons and other interactive elements, the :hover pseudo-class may not be the best tool for the job. Consider using the :focus pseudo-class instead — and while you’re at it, make sure that visual focus indicators meet WCAG’s requirements for color contrast.
Related: What You Need to Know About Visual Focus and Accessibility
Complex hover effects can impact page load times or cause other performance issues, particularly for mobile users. If hover notifications get in the way of content, they can also be annoying — particularly if they’re triggered by accident.
If you decide to use hover actions on a website, web app, or mobile app, make sure they follow these rules:
Web accessibility is achievable, regardless of your budget or technical skills. To learn more about the basics of WCAG conformance, download our free eBook: Developing the Accessibility Mindset. You can also test your website for common accessibility issues with AudioEye’s free Website Accessibility Checker.
And if you have a specific question about digital accessibility, we’re here to help. Send us a message to connect with a subject matter expert.