On each web page, can additional content that appears when an interface component receives focus or is hovered over be controlled by the user (except in special cases)?
A visually impaired user navigates at 300% zoom. A tooltip appears on hover of a button. They move the cursor toward this content to read it: the tooltip fades away. They try again, same result. Three lines of poorly written JavaScript, and there's exclusion.
Criterion 10.13 imposes three cumulative conditions on any additional content appearing on hover or focus. First: it must be "dismissable", that is, a keyboard mechanism (typically Escape) must allow closing it if it obscures other information. Second: it must be "hoverable", the pointer can move toward this content without it disappearing. Third: it must be "persistent", it remains visible until explicit user action.
Affected: custom tooltips, popovers, hover menus, contextual infobulles. Not affected: infobulles from the title attribute, native form validation, and modal windows conforming to the WAI-ARIA dialog pattern. These special cases are handled by the browser or by other dedicated design patterns.
3 tests to check the behavior of content on hover and focus
Keyboard closure of hover/focus content
- List all content that appears on hover or focus (tooltips, popovers, dropdowns, etc.).
- Exclude content managed by the browser (
titleattribute, native form validation) and content triggered by click or key press. - For each remaining content, verify one of the following two conditions: a. The content does not obscure any useful information, including at high zoom (200% and 400%). b. A keyboard mechanism (ex.: Escape key) allows closing it without moving focus or the pointer.
- If at least one of the two conditions is met for each content: test validated.
Hover additional content without disappearance
- List all content appearing on hover (except native browser content and click-triggered activation).
- For each content, trigger its appearance, then slowly move the cursor from the trigger toward the additional content.
- Verify that the content does not disappear during this movement, nor when the cursor is positioned over it.
- If the content remains visible in all these situations: test validated.
Persistence of hover/focus content
- List all additional content appearing on hover or focus (except native browser content and click-triggered activation).
- For each content, verify that it remains visible in all the following situations: a. The user maintains the pointer or focus on the content or its trigger. b. The user has not yet activated the closing mechanism (ex.: Escape key). c. The information remains valid (ex.: an error message persists until the error is corrected).
- If the content automatically disappears after a delay, without user action: test failed.
- If the content remains visible in all these situations: test validated.
Examples
❌ Non-compliant : Tooltip that disappears as soon as the cursor hovers over it
<button
id="btn-aide"
onmouseenter="document.getElementById('tip').style.display='block'"
onmouseleave="document.getElementById('tip').style.display='none'">
Help
</button>
<div
id="tip"
role="tooltip"
style="display:none; position:absolute; background:#333; color:#fff; padding:8px;">
Enter your 8-digit customer number.
</div>The onmouseleave event is attached to the button. As soon as the cursor leaves the button to move toward the tooltip, the event fires and the content disappears. A low-vision user with high zoom will need to move the mouse to read the content: they will never be able to reach it. Fails test 10.13.2.
✅ Compliant : Accessible tooltip: extended hover zone and keyboard closing
<div
class="tooltip-container"
style="position:relative; display:inline-block;">
<button
id="btn-aide"
aria-describedby="tip-aide">
Help
</button>
<div
id="tip-aide"
role="tooltip"
style="display:none; position:absolute; top:calc(100% + 4px); left:0; background:#333; color:#fff; padding:8px; width:220px;">
Enter your 8-digit customer number.
</div>
</div>
<script>
const container = document.querySelector('.tooltip-container');
const tooltip = document.getElementById('tip-aide');
const btn = document.getElementById('btn-aide');
const show = () => { tooltip.style.display = 'block'; };
const hide = () => { tooltip.style.display = 'none'; };
container.addEventListener('mouseenter', show);
container.addEventListener('mouseleave', hide);
btn.addEventListener('focus', show);
btn.addEventListener('blur', hide);
document.addEventListener('keydown', (e) => {
if (e.key === 'Escape') hide();
});
</script>The mouseleave is attached to the parent container, not the button. The cursor can move freely toward the tooltip without it disappearing. The Escape key closes the tooltip from the keyboard. aria-describedby associates the tooltip with the button for screen readers. Tests 10.13.1, 10.13.2, and 10.13.3 are validated.
Tips and pitfalls
⚠️ onmouseleave on the trigger rather than the container
This is the #1 error found in audits on this criterion. Attaching onmouseleave to the trigger button makes the additional content disappear as soon as the cursor hovers over it. The fix is simple: wrap the trigger and the content in a common container, and attach mouseleave to that container. Also verify that CSS :hover follows the same logic.
⚠️ Automatic timeout fails test 10.13.3
Closing a tooltip after 3 or 5 seconds, regardless of user action, violates test 10.13.3. The content must remain visible until the user moves their pointer, removes their focus, or activates the intended closing mechanism. An arbitrary timeout does not count as a closing mechanism.
⚠️ The title attribute and native validation are out of scope
Infobulles from the title attribute and native form validation messages are entirely managed by the browser. Criterion 10.13 does not apply to them. Another issue: these native tooltips do not display on keyboard focus on most browsers. This is therefore not a reliable accessibility solution as a replacement for a custom tooltip.
⚠️ Modal windows conforming to the WAI-ARIA dialog pattern are excluded
A component implementing the WAI-ARIA dialog design pattern — with role="dialog", focus trapping and Escape key closing — is not subject to criterion 10.13. This pattern natively integrates the expected behaviors. If your modal does not follow this pattern, it remains within the audit scope.
⚠️ Tooltip that obscures nothing: test 10.13.1 becomes non-applicable
If additional content is positioned so as never to overlap other informational content, even at high zoom, test 10.13.1 is non-applicable. Tests 10.13.2 and 10.13.3 remain mandatory. A tooltip exempt from the keyboard closing requirement must still be hoverable and persistent.
💡 Always test at high zoom, not just at 100%
At 100%, a tooltip positioned below its trigger may appear to obscure no content. At 400%, that same tooltip may cover multiple text blocks. Verify conformance to test 10.13.1 by navigating at 200% and 400% with browser zoom — not CSS zoom or page zoom.
Frequently asked questions
What obligations does RGAA criterion 10.13 impose on tooltips generated via the title attribute?
None. Infobulles from the title attribute are managed by the browser: criterion 10.13 does not apply to them. Caution however: these native tooltips do not display on keyboard focus on most browsers and are not reliably read by screen readers. They therefore do not constitute a valid text alternative within the meaning of RGAA criteria 1.1 and 1.2.
How do you verify that hover content complies with RGAA test 10.13.2?
Trigger the additional content by hovering over its trigger, then slowly move the cursor toward this content. If it disappears before you can reach it, the test fails. Then remain positioned on the content for a few seconds to verify it does not close by itself. Repeat at 200% zoom to reproduce the real conditions of a low-vision user.
How does RGAA criterion 10.13 apply to dropdown menus that open on hover?
Yes, if it opens only on hover without explicit activation (click or Enter key). This menu is additional content within the meaning of the criterion. It must be hoverable (the cursor can move to its items without the menu closing), persistent, and — if it obscures other content — closable from the keyboard. This is also why accessible menus systematically recommend click activation in addition to hover.
What mechanisms allow closing additional content under RGAA criterion 10.13?
No. The RGAA requires "a keyboard mechanism" without specifying its nature. The Escape key is the convention recommended by WAI-ARIA patterns, but a focusable "Close" button inside the additional content is also valid. The essential point: the user should not have to move their pointer or focus to close the content.
How does RGAA criterion 10.13 apply to error messages displayed in a popover in a form?
Yes, if it appears on focus and is not managed by the browser's native validation. This content must remain visible until the error is corrected (test 10.13.3). If it is positioned below the field without overlapping any other content, even at high zoom, test 10.13.1 is non-applicable. Tests 10.13.2 and 10.13.3 remain mandatory.