F95: When Hover Popups Disappear Before You Can Read Them

The W3C failure catalog entry for F95 (opens in new window) contains no code block. That's worth pausing on. Most WCAG technique documents lead with markup — the bad pattern, the good pattern, the diff. F95 leads with a scenario instead: a user tries to move their pointer toward a popup to read it, and the popup closes before they get there. The failure isn't a syntax error. It's a design decision that eliminates an entire class of users from the interaction.

This is one of the more quietly harmful patterns in modern UI development, and it's widespread.

THE FAILURE

WCAG 2.1 Success Criterion 1.4.13 — Content on Hover or Focus (opens in new window) requires that when additional content appears on hover, that content must be hoverable. Meaning: a user must be able to move their pointer off the trigger and onto the new content without the content disappearing. F95 defines the failure of that requirement.

The W3C document describes two specific scenarios:

Scenario one: A popup opens on hover. The user's screen is magnified, so the popup is only partially visible. They move their pointer toward the popup to read it. The popup closes.

Scenario two: A data visualization with tooltips. Hovering over a data point opens a tooltip, offset from the point itself. When the user moves toward the tooltip, their pointer crosses other data points, triggering replacement tooltips. The tooltip they wanted is gone.

Neither of these requires unusual behavior from the user. Moving a pointer toward content you want to read is the most natural thing in the world. F95 fails when that natural action destroys the content.

WHY THIS MATTERS

For users without magnification software, hover tooltips often work fine — the trigger and the popup fit comfortably within the visible viewport, and the gap between them is trivial to cross. The failure is invisible in standard testing.

For users of screen magnification software — ZoomText, Windows Magnifier, macOS Zoom — the experience is fundamentally different. At 4x or 8x magnification, a tooltip that appears 200 pixels from its trigger may be entirely off-screen. Reading it requires physically moving the pointer across the screen to reposition the magnified viewport. That journey crosses the gap between trigger and popup. If that gap isn't hoverable, the popup is gone before they arrive.

This isn't an edge case. The National Institute on Disability, Independent Living, and Rehabilitation Research estimates that roughly 8 million Americans have significant visual impairments. Screen magnification is among the most commonly used assistive technologies in that population — often preferred over screen readers by people with low vision who retain useful functional sight. F95 failures systematically exclude them from hover-dependent content: data visualizations, tooltip-based help text, navigation flyouts, pricing tables, interactive charts.

The data visualization scenario described in F95 is particularly instructive. Dashboard interfaces — used across healthcare, finance, government, and enterprise software — routinely implement chart tooltips this way. A user with low vision trying to read a tooltip on a bar chart may trigger five or six replacement tooltips before giving up. The information is technically "present" in the interface. It is functionally inaccessible.

THE FIX

The W3C document doesn't include code examples — the failure is behavioral, not syntactic. But the corrected pattern is well-established.

The core requirement: the popup must remain visible when the pointer moves from trigger to popup. A simple CSS approach uses a hover bridge — an invisible element that fills the space between trigger and popup, keeping the hover state active during pointer transit.

/* Failure pattern — popup closes the moment pointer leaves trigger */
.trigger:hover .popup {
  display: block;
}
/* Better pattern — popup itself maintains hover state */
.trigger:hover .popup,
.popup:hover {
  display: block;
}

For more complex implementations, a small delay before dismissal (typically 300–500ms) gives users time to move the pointer to the popup before it closes:

.popup {
  visibility: hidden;
  transition-delay: ;
}
.trigger:hover .popup,
.popup:hover {
  visibility: visible;
}
/* On pointer leave, delay the hide */
.trigger .popup {
  transition: visibility  linear ;
}
.trigger:hover .popup,
.popup:hover {
  transition-delay: ;
}

For JavaScript-managed tooltips, the same logic applies: listen for mouseenter and mouseleave on both the trigger and the popup element, and only dismiss when neither is hovered.

The success criterion being addressed is 1.4.13 Content on Hover or Focus (opens in new window), which has three requirements for hover content: it must be dismissible, hoverable, and persistent. F95 addresses the hoverable requirement specifically.

APPLYING THIS

This failure is largely invisible to automated testing tools. As our research on testing methodology documents, automated tools detect at most 37% of real accessibility barriers — and behavioral interaction failures like F95 fall squarely in the undetected majority. You will not catch this with axe-core or Lighthouse.

Practical detection strategies:

• Manual test protocol: For every hover-triggered element, move the pointer slowly from trigger toward the popup. If the popup closes during transit, you have an F95 failure. Test at multiple viewport zoom levels, not just 100%.
• Browser zoom testing: Test all hover interactions at 200% and 400% browser zoom. This simulates the viewport displacement that magnification users experience and surfaces failures that are invisible at standard zoom.
• Code review checklist: Flag any CSS that uses only .trigger:hover .popup without also handling .popup:hover. Flag JavaScript tooltip libraries that don't attach mouseenter/mouseleave to the popup element itself.
• Design review: Data visualizations with offset tooltips are high-risk. Ask in design review: can the user reach this tooltip without crossing another trigger?

For teams using third-party charting libraries (Chart.js, D3, Highcharts, Recharts), tooltip hoverability is often a configuration option, not a default. Check library documentation for "tooltip persistence" or "tooltip sticky" options before building custom workarounds.

The Methodology Paradox research makes a point directly relevant here: behavioral failures require behavioral testing. F95 cannot be found by reading code in isolation — it requires a human tester moving a pointer across a screen and observing what happens.

CORS PERSPECTIVE

From a risk and legal priority standpoint, F95 sits in a deceptive middle zone. It's unlikely to appear in an automated scan, which means organizations relying solely on automated tooling carry this failure unknowingly — and carry the legal exposure that comes with it. SC 1.4.13 is part of WCAG 2.1 Level AA, the standard incorporated by reference into Section 508 (opens in new window) and increasingly cited in DOJ enforcement guidance under Title II and Title III of the ADA (opens in new window). Data visualization interfaces — precisely where F95 is most common — are embedded in government dashboards, public health portals, and agency reporting tools that carry Title II obligations. The failure is quiet, the exposure is real, and the fix is genuinely simple once someone looks for it.