1.4.13 Content on Hover or Focus

Level AA
Perceivable
Since WCAG 2.1

Summary

Tooltips, hover-triggered dropdown menus, and preview cards can be unusable for people who need to inspect them closely. Screen magnification users see only a small slice of the page at a time: to read a tooltip they must move the magnified viewport (and often the pointer) towards it, and if the popup vanishes the moment the pointer leaves its trigger, the content is unreadable. Users with low vision, tremor, or large zoom levels are similarly caught out, and anyone can accidentally trigger a popup that then blocks the text they were reading with no way to get rid of it.

New in WCAG 2.1 at Level AA, the criterion applies wherever hovering or focusing something makes additional content appear and un-hovering or un-focusing makes it disappear. The auditor's mental model is three tests on every such popup. Dismissible: can it be closed (typically with Escape) without moving pointer or focus, unless it communicates an input error or obscures nothing? Hoverable: if hover triggered it, can the pointer travel onto the popup without it disappearing? Persistent: does it stay until the trigger ends, the user dismisses it, or the information becomes stale, rather than vanishing on a timer? Plain browser tooltips rendered from the title attribute are exempt: their presentation is the user agent's, not the author's.

Official wording

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

Success Criterion 1.4.13 Content on Hover or Focus, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.1.4.13
Software and native apps: Clause 11.1.4.13

Clauses 9.1.4.13 (web) and 11.1.4.13 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Inventory every hover and focus surface first: tooltips on icons and truncated text, navigation menus that open on hover, user or link preview cards, custom form hints that appear on focus. Then run the three tests on each. Hover the trigger and, without moving the mouse, press Escape: the popup should close (dismissible). Trigger it again and move the pointer from the trigger onto the popup itself: it must stay visible while the pointer is over it (hoverable). Leave the pointer resting: the popup must remain until you move off or dismiss it, not disappear after a few seconds (persistent). Repeat the dismissible and persistent tests with keyboard focus where focus also triggers the content.

Browser devtools help you catch the mechanics. Forcing the :hover state on the element (element state toggles in the styles panel) reveals CSS-only tooltips, which almost always fail dismissible because nothing listens for Escape. Watch the DOM while moving the pointer towards the popup: menus that close when the pointer crosses a gap between trigger and panel are hoverable failures. To feel the real impact, test at 400 percent browser zoom or with the operating system magnifier: if you cannot bring the popup content into view before it disappears, a magnification user cannot read it.

The exception is narrow. A bare title attribute tooltip is exempt (user agent presentation), but the moment the author replaces or restyles it with a custom tooltip component, all three tests apply. The dismissible test also has its own carve-outs: an inline validation message, or a hint that appears in whitespace and obscures nothing, does not need a dismiss mechanism.

iOS

The criterion applies to software unchanged under the European standard, but on touch-only usage there is usually nothing to grade: a fingertip has no hover state, so screens with no hover or focus triggered content are not applicable for this criterion. Two situations bring it into scope. First, pointer input: an iPad with a trackpad or mouse gets a genuine hover pointer, and any tooltips or hover effects the app itself draws must pass the same three tests (dismissible without moving the pointer, hoverable, persistent). Second, hardware keyboards: with Full Keyboard Access enabled in accessibility settings, moving focus through controls can trigger author-drawn popovers or hints, and those must be dismissible (Escape) and persistent.

Test with a trackpad paired to an iPad where the app supports it, hover anything that shows extra content, then try Escape and try steering the pointer onto the popup. Where the app shows nothing on hover or focus, record the criterion as not applicable for that screen rather than inventing a pass.

Android

The same applies on Android: touch has no hover, so most phone screens yield not applicable results, but a connected mouse (or desktop-style environments running Android apps) produces real hover events, and hardware keyboard focus can trigger tooltips and hints. Android's own tooltip APIs display briefly and are largely platform-rendered; author-built popups that appear on mouse hover or on keyboard focus are the audit targets.

Test with a USB or Bluetooth mouse and keyboard attached. Hover icons, truncated labels, and menu triggers; where extra content appears, check it can be dismissed with Escape without moving the pointer, that the pointer can move onto it, and that it stays until dismissed rather than timing out. Layout Inspector in Android Studio can confirm whether a transient view is the platform's tooltip or an author-drawn popup, which decides whether the user agent exception applies. Keep findings honest: grade only surfaces that actually respond to hover or focus.

Pass and fail examples

Passes:

A custom tooltip on an icon button that appears on hover and focus, closes on Escape without the pointer moving, stays put while the pointer is over the tooltip itself, and remains until the user moves away.
A plain title attribute tooltip with no author styling or scripting: user agent exception.
A password requirements hint that appears below the field on focus, in empty space, obscuring nothing: no dismiss mechanism is required because it does not obscure or replace other content.
A hover preview card for a link that the pointer can travel onto, with links inside it that can then be clicked.

Fails:

A CSS-only tooltip that covers the paragraph beneath it and offers no way to dismiss it while the pointer stays on the trigger: dismissible failure.
A navigation dropdown that closes when the pointer crosses the small gap between the menu button and the panel: hoverable failure.
A tooltip that automatically disappears three seconds after appearing, while the pointer is still on the trigger: persistent failure.
A profile preview card that vanishes as soon as the pointer leaves the username, making its contents unreachable: hoverable failure.

Not a fail under this criterion:

Content that appears on click or tap (a popover opened by pressing a button): this criterion covers hover and focus triggers only; grade click-triggered popovers under focus management and dialog patterns instead.
A hover menu that keyboard users cannot open at all: that is a keyboard operability finding under SC 2.1.1 Keyboard, not a 1.4.13 finding.
A focused control hidden behind a sticky header or an unrelated overlay: grade under SC 2.4.11 Focus Not Obscured (Minimum).
A screen with no hover or focus triggered content: record not applicable, not a pass by default.

Commonly confused with

Click-triggered content. The most common misfiling. If the extra content appears on activation (click, tap, Enter) rather than on hover or focus, 1.4.13 does not apply; assess the popover or dialog under focus management and the relevant dialog pattern instead.
SC 2.4.11 Focus Not Obscured (Minimum). Related but opposite in direction: 1.4.13 governs the popup the focused element creates; 2.4.11 asks whether the focused element itself remains visible. A focus-triggered popup that covers the very control that opened it is a 2.4.11 concern.
SC 2.1.1 Keyboard. A hover-only menu that a keyboard user cannot reach is a keyboard failure, not a hover-content failure. 1.4.13 only takes over once hover or focus does trigger content and that content misbehaves.
SC 3.2.1 On Focus. If focusing a control does more than reveal content nearby (it moves focus, opens a new window, or otherwise changes context), that is an On Focus finding. 1.4.13 assumes the reveal itself is legitimate and grades how the revealed content behaves.
The user agent exception. Auditors sometimes exempt every tooltip because "browsers show tooltips". Only unmodified user agent presentation (a bare title attribute) is exempt; any author-built or author-styled tooltip is fully in scope.

How AUDITSU tests this

AUDITSU's audit walkthrough surfaces this criterion on every screen that shows content on hover or focus. The per-screen questions prompt you to list tooltips, hover menus, and preview cards, then run the three tests in order: Escape to dismiss without moving the pointer, pointer travel onto the popup, and persistence until dismissal. Screens with no hover or focus triggered content are recorded as not applicable, so your report reflects real coverage rather than blanket passes. Each answer is stored as a pass, fail, or not applicable result with evidence attached, tying the finding to the exact screen and component.

Because the requirement applies unchanged to web and software under the European standard, the walkthrough asks the same questions in web and app audits, with the app-side questions scoped to pointer and hardware keyboard input where the platform supports them.

For the full guided workflow, see the audit platform.