WCAG 1.4.13: Content on Hover or Focus
When extra content appears because a user hovers over or keyboard-focuses an element — a tooltip, a hover menu, a popover — that content must be Dismissible, Hoverable, and Persistent. In plain terms: the user can clear it away, move the pointer onto it, and keep it open long enough to read. Get these three rules wrong and tooltips become a trap for anyone who magnifies the screen or cannot hold a pointer perfectly still.
The success criterion, in full
Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true: the content is Dismissible, Hoverable, and Persistent — except where the visual presentation of the additional content is controlled by the user agent and is not modified by the author.
Why hover and focus content matters
Tooltips and hover popups look harmless, but they are one of the most common ways to accidentally lock people out of information. Picture someone using screen magnification at 400%. Only a small slice of the page is visible at once, and moving the mouse toward a tooltip means moving across the screen. If the tooltip disappears the moment the pointer leaves the trigger, the user can never reach it — the content is visible in theory and unreachable in practice.
The same problem hits people with tremors or limited fine motor control, who cannot hold the pointer perfectly still on a tiny trigger, and people who read slowly and need the content to stay on screen. A tooltip that vanishes on a timer, jumps away as the pointer moves, or covers the paragraph the user was reading with no way to clear it turns a small convenience into a real barrier.
1.4.13 fixes this with three narrow, testable rules. Meet them and your tooltips, hover menus, and popovers stay usable for everyone — not just people using a precise mouse on a full-size screen.
The three conditions
Whenever hover or focus reveals author-styled content, that content must satisfy all three of the following. (Content whose entire appearance is controlled by the browser — like the native focus ring — is exempt.)
1. Dismissible
The user can make the extra content go away without moving the pointer or focus.
If pointing to or focusing an element reveals additional content, a mechanism must let the user dismiss it without moving hover or focus — pressing Escape is the standard. This matters most when the popup overlaps content the user was reading: a magnifier user zoomed into a paragraph should be able to clear a tooltip that landed on top of it without losing their place. The exception: the additional content does not need a dismiss mechanism if it communicates an input error, or if it does not obscure or replace any other content.
2. Hoverable
The pointer can move onto the popup without it vanishing.
If hover triggers the extra content, the user must be able to move the mouse pointer over that content without it disappearing. People who magnify the screen, or who have tremors and cannot hold the pointer perfectly still, need to travel across a gap to reach the popup — to read all of it, scroll it, or click a link inside. A tooltip that hides the instant the pointer leaves the trigger fails, because the user can never reach it.
3. Persistent
The content stays visible until the user is done with it.
The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid. In other words: do not auto-hide a tooltip on a timer. People who read slowly, use magnification, or are distracted mid-read need the content to stay put for as long as they keep hovering or keep focus on the trigger.
Rule of thumb: reveal the popup on both hover and focus, let Escape close it, keep it open while the pointer is over either the trigger or the popup, and never hide it on a timer. That single pattern satisfies Dismissible, Hoverable, and Persistent at once.
The title attribute trap
The quickest way to add a "tooltip" in HTML is the native title attribute — and it is almost always the wrong choice. The browser-drawn title tooltip fails users in several ways at once:
- It is not Dismissible — there is no way to press Escape and clear it while keeping the pointer where it is.
- It is not Hoverable — try to move the pointer toward the title tooltip and it disappears.
- It appears only on mouse hover, so keyboard users and many screen reader users never see it at all.
- It is invisible to touch users — there is no hover on a touchscreen.
- Its timing and appearance are uncontrollable — it often auto-hides after a few seconds and cannot be styled for contrast or size.
If a control only needs an accessible name, use aria-label or visible text, not title. If you genuinely need a tooltip that appears on hover and focus, build a custom one you can make Dismissible, Hoverable, and Persistent, and connect it to its trigger with aria-describedby.
Code examples
An accessible tooltip: markup
Give the trigger and the tooltip a shared relationship with aria-describedby, mark the popup with role="tooltip", and wrap both in a container so the pointer can travel from one to the other without leaving the hover zone.
<span class="tooltip-wrapper">
<button
type="button"
class="tooltip-trigger"
aria-describedby="pw-tip"
>
Password requirements
</button>
<!-- Persistent + Hoverable: lives next to the trigger,
inside the same hover container -->
<span role="tooltip" id="pw-tip" class="tooltip" hidden>
At least 12 characters, including a number and a symbol.
</span>
</span>Hoverable and Persistent with CSS
Show the tooltip when either the trigger or the tooltip itself is hovered or focused. Because the wrapper covers both, the pointer can move onto the tooltip without it closing, and it stays visible for as long as the user keeps hovering.
.tooltip {
position: absolute;
/* small overlap so there is no dead gap to cross */
margin-top: 4px;
}
/* Hoverable: staying within the wrapper keeps it open.
Persistent: no timer hides it — only leaving does. */
.tooltip-wrapper:hover .tooltip,
.tooltip-wrapper:focus-within .tooltip {
display: block;
}
/* Focus support: the tooltip must also appear for
keyboard users, not just on mouse hover. */
.tooltip-trigger:focus-visible + .tooltip {
display: block;
}Dismissible with the Escape key
When the tooltip could overlap other content, let the user clear it with Escape without moving hover or focus. A tiny script toggles a data-dismissed flag that your CSS respects.
const wrapper = document.querySelector(".tooltip-wrapper");
// Dismissible: Escape hides the popup without moving
// the pointer or focus off the trigger.
wrapper.addEventListener("keydown", (event) => {
if (event.key === "Escape") {
wrapper.setAttribute("data-dismissed", "true");
}
});
// Re-enable next time hover/focus leaves and returns.
wrapper.addEventListener("mouseleave", () =>
wrapper.removeAttribute("data-dismissed"),
);
wrapper.addEventListener("focusout", () =>
wrapper.removeAttribute("data-dismissed"),
);/* Respect the dismissed state */
.tooltip-wrapper[data-dismissed="true"] .tooltip {
display: none;
}Common mistakes
- Using the native title attribute as a tooltip — it fails Dismissible and Hoverable, and never appears for keyboard or touch users.
- A tooltip that hides the instant the pointer leaves the trigger, so a magnifier user can never move onto it (fails Hoverable).
- Auto-hiding the popup on a timer after a few seconds, before a slow reader has finished (fails Persistent).
- Revealing content on hover only, with no keyboard-focus equivalent, so keyboard users never get it at all.
- A large hover popup that covers the text the user was reading, with no Escape or dismiss mechanism (fails Dismissible).
- A gap between the trigger and the popup that closes the tooltip mid-travel — leave a small overlap so the hover zone is continuous.
- Putting interactive content (links, buttons) in a tooltip the user can never reach because it disappears on the way there.
- Trapping keyboard focus inside a hover menu, or opening it with no way to close it via the keyboard.
How to test for 1.4.13
- 1
Find every hover or focus popup
Move the mouse across the page and Tab through it, watching for anything that appears — tooltips, hover menus, definition popups, icon labels. Each one you find needs to pass all three conditions.
- 2
Test Hoverable: move onto the popup
Hover the trigger, then move the pointer slowly onto the popup content. It must stay open the whole way. If it disappears as soon as the pointer leaves the trigger, it fails Hoverable.
- 3
Test Persistent: wait and read
Hover a trigger and leave the pointer there. The content must remain visible — it should not vanish on a timer. It should only close when you move hover or focus away, or dismiss it.
- 4
Test Dismissible: press Escape
With a popup showing (especially one that overlaps other content), press Escape without moving the mouse or focus. The popup should hide. If it cannot be dismissed and it obscures content, it fails Dismissible.
- 5
Test with the keyboard and magnification
Tab to the trigger and confirm the same content appears on focus, not just hover. Then zoom the browser to 400% and repeat — magnifier users are exactly who this criterion protects.
Content on Hover or Focus is a manual check — automated tools cannot tell whether a popup is reachable or dismissible. Pair a keyboard and magnification walkthrough with the Keyboard Accessibility Guide and scan a live page with the URL Accessibility Auditor.
Related success criteria
2.4.7 Focus Visible — AA
Because 1.4.13 content must appear on focus too, the trigger needs a visible focus indicator so keyboard users know where the popup will come from.
2.4.11 Focus Not Obscured (Minimum) — AA
A partner low-vision criterion: 2.4.11 keeps the focused element from being hidden by other content, while 1.4.13 keeps hover and focus popups reachable and dismissible.
1.4.10 Reflow — AA
Reflow protects the same magnifier users. A popup that reflows poorly or scrolls off-screen at 400% zoom undermines both this and 1.4.13.
4.1.2 Name, Role, Value — A
A custom tooltip or popover needs the right role and an association (such as aria-describedby) so assistive technology announces it — the semantic side of the same widget.
Browse every criterion in the WCAG Success Criteria hub or work through the full WCAG 2.2 checklist.
Frequently asked questions
What does WCAG 1.4.13 Content on Hover or Focus require?
It governs additional content that appears when the user hovers over or keyboard-focuses an element — tooltips, hover-triggered menus, custom popovers, and definition popups. When that content appears and is not controlled by the browser itself, it must meet three conditions: it must be Dismissible (removable without moving the pointer or focus, usually with the Escape key), Hoverable (the pointer can move onto the popup without it disappearing), and Persistent (it stays visible until the trigger is removed, the user dismisses it, or the information is no longer valid). It is a Level AA success criterion introduced in WCAG 2.1 and carried into WCAG 2.2.
Does the HTML title attribute satisfy 1.4.13?
No. The native title attribute tooltip is one of the worst options for accessibility. It is not Dismissible (you cannot press Escape to remove it), it is not Hoverable (moving the pointer toward it makes it vanish), it appears only on mouse hover so it never shows for keyboard users, it is invisible to most touch users, and its styling and timing are entirely uncontrollable. Use a custom tooltip that you can make Dismissible, Hoverable, and Persistent instead, and reference it with aria-describedby.
What is the difference between hover content and a tooltip role?
1.4.13 is about the behaviour of any content that appears on hover or focus, regardless of what ARIA role it uses. A true ARIA tooltip (role="tooltip", referenced by aria-describedby) is one common case, but hover-triggered navigation menus, rich popovers with links, and definition cards are all covered too. The role tells assistive technology what the popup is; 1.4.13 makes sure that, once it appears, sighted users — especially those who magnify the screen — can actually reach, read, and dismiss it.
Do I need a dismiss mechanism for every tooltip?
Not always. The Dismissible condition has an exception: content that does not obscure or replace other content does not need a separate dismiss mechanism, and neither does content that communicates an input error. If your tooltip is small and floats in whitespace where it covers nothing the user needs, you can skip the Escape handler — though adding one is still good practice and costs almost nothing. Hoverable and Persistent, however, still apply.
Does 1.4.13 apply to content triggered by a click instead of hover?
No. 1.4.13 only covers content triggered by pointer hover or keyboard focus. Content that appears on click, tap, or Enter/Space activation is out of scope for this criterion — though it still has to meet other requirements such as 2.1.1 Keyboard and 4.1.2 Name, Role, Value. The trap to avoid is a control that shows content on hover only, with no click or focus equivalent, which also risks failing keyboard operability.
How is 1.4.13 different from 1.4.10 Reflow and 2.4.11 Focus Not Obscured?
They are related low-vision and focus criteria but test different things. 1.4.10 Reflow is about content adapting to a 320px viewport without two-dimensional scrolling. 2.4.11 Focus Not Obscured is about the focused element not being hidden behind sticky content. 1.4.13 is specifically about the behaviour of content that pops up on hover or focus — that a magnifier user can reach it, keep it open, and clear it away. A robust design considers all three together.