A form asks for a VAT identification number. Next to the field sits a small question mark, and anyone using a mouse sees the expected format on hover. Anyone working with a keyboard sees nothing. Anyone moving the pointer from the question mark towards the revealed box, in order to read it with screen magnification, loses it halfway. And anyone who leaves the box open finds it covering the very field they were about to fill in. All four situations are described by a single success criterion of the Web Content Accessibility Guidelines: 1.4.13, Content on Hover or Focus. This article takes the wording apart, sorts the references in standard and test procedure, walks the test path and shows a pattern that meets the three conditions.
Key takeaways
- Additional content has to be dismissible, hoverable and persistent at the same time. If one of the three conditions fails, the criterion is not met (W3C).
- The criterion is not new in version 2.2: the wording already appears in WCAG 2.1, whose first Recommendation is dated 5 June 2018 (W3C).
- EN 301 549 carries the requirement three times over: for web pages, for documents and for software with a user interface (EN 301 549).
- Content whose presentation is controlled by the browser, such as the tooltip produced by the title attribute, is excepted (W3C). The HTML standard nevertheless discourages relying on it (WHATWG).
- The hoverable condition only concerns content triggered by the pointer. Where keyboard focus triggers the content, it is not required (BIK BITV-Test).
- Testing is done by hand: EN 301 549 names inspection as the type of assessment for this criterion, not automated measurement (EN 301 549).
Three conditions, one criterion
Success Criterion 1.4.13 is called Content on Hover or Focus and sits at conformance level AA. It applies wherever receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden again (W3C). The trigger can be an icon, an underlined word, a menu item, a data point in a chart or an input field. The additional content can be field help, a submenu, a profile preview, a glossary entry or a value readout. What matters is neither the name of the component nor the technology behind it, but the behaviour: if something appears in addition to the trigger and disappears again once contact ends, the criterion applies. German test practice files it under the heading of operable revealed content (BIK BITV-Test).
The standard then places three conditions side by side that have to hold at the same time. Dismissible means a mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus (W3C). Hoverable means that if pointer hover can trigger the content, then the pointer can be moved over that content without it disappearing (W3C). Persistent means the content remains visible until the hover or focus trigger is removed, until the user dismisses it, or until its information is no longer valid (W3C). Three conditions, one outcome: if one of them fails, the criterion is not met. Anyone planning revealed content is therefore working at the same seam as with accessible modals and overlays and with navigation carrying submenus, only without a focus trap and without a forced decision.
What additional rules out
Not new in version 2.2: the wording has stood since 2018
In project meetings 1.4.13 regularly turns up as one of the new criteria. That is not accurate. The wording already appears in WCAG 2.1, whose Recommendation is dated 5 June 2018; the version published today is a revision of 6 May 2025 (W3C). WCAG 2.2 was published as a Recommendation on 12 December 2024 (W3C) and carries the wording of the requirement over unchanged; what was added there is a third note that explicitly excludes elements without additional content, such as skip links (W3C). Anyone working through the new criteria in version 2.2 will consequently not find 1.4.13 there. In practical terms: anyone who built an interface to WCAG 2.1 over the past years already owes this criterion. A finding on it is not the consequence of a new version but an outstanding bill.
For the German legal framework the reference matters more than the version number. EN 301 549 points in clause 9.1.4.13 for web pages at Success Criterion 1.4.13 of WCAG 2.1 (EN 301 549) and repeats the same requirement in clause 10.1.4.13 for non-web documents and in clause 11.1.4.13 for non-web software providing a user interface (EN 301 549). A form PDF and a desktop application are therefore subject to the same test as a web page. How that standard connects to the law is described in detail elsewhere: EN 301 549 as the standard behind the BFSG and the BFSG requirements derived from it. The ordinance accompanying the German accessibility act additionally requires the state of the art to be observed when meeting its requirements, while allowing a departure from it where the requirements are met to the same extent by other means (Bundesministerium der Justiz). It therefore does not fix any particular version of the standard.
| Reference | What it says | What follows from it |
|---|---|---|
| WCAG 2.1, criterion 1.4.13 | The full wording with three conditions and an exception | The requirement has existed since the 2018 Recommendation |
| WCAG 2.2, criterion 1.4.13 | The same wording of the requirement, plus a third note on skip links | Moving to 2.2 changes nothing about the requirement itself |
| EN 301 549, clause 9.1.4.13 | Reference to WCAG 2.1 for web pages | The yardstick for the website |
| EN 301 549, clause 10.1.4.13 | The same reference for non-web documents | Field help inside a form PDF is in scope |
| EN 301 549, clause 11.1.4.13 | The same reference for software with an interface | Line-of-business applications and apps are in scope |
| EN 301 549, annex C.9.1.4.13 | Type of assessment: inspection | Evidence is produced by hand, not by a scanner |
| BITV test, test step 9.1.4.13 | Two checks: pointer hover and keyboard focus | Two passes per trigger type in the report |
The table also explains why the topic is so often underestimated in tenders. Anyone agreeing on the website as the scope of testing has not bought in the line-of-business application or the document output, although the standard sets the same requirement for both. And anyone hoping to produce evidence through an automated tool runs into the limit of the procedure: the standard itself assigns inspection to this criterion (EN 301 549), meaning a check carried out by a person with pointer, keyboard and an eye on what actually happens.
The three gates read one by one
The first gate, dismissible, carries an exception that is frequently overlooked: the mechanism for dismissing is not required where the additional content communicates an input error, or where it neither obscures nor replaces other content (W3C). An error message appearing below the field and covering nothing therefore needs no dismiss control. An explanatory box lying over the next field does need one. The BITV test names the two customary routes explicitly: pressing the Escape key, or activating again the element whose focus reveals the content (BIK BITV-Test). Both satisfy the condition; what is asked for is a mechanism, not a particular key.
The second gate, hoverable, is tied to the pointer. It applies where the pointer can trigger the content, and then requires that the pointer can be moved over the revealed content without it disappearing (W3C). For content revealed by keyboard focus it is not required that the mouse pointer can be moved over it (BIK BITV-Test). The third gate, persistent, in practice rules out one thing above all: the timer. A box vanishing on its own after three seconds breaks the condition, because the reveal may only end when the trigger is left, when the user dismisses it, or when the information is no longer valid (W3C). Anyone reworking focus handling anyway will find the adjacent questions under focus management in single-page applications; the markup side belongs to accessible development.
Gate 1: dismissible
A mechanism closes the content without pointer or focus being moved. The Escape key and re-activating the trigger are the usual routes. Only waived for error messages and for content that obscures nothing.
Gate 2: hoverable
The pointer travels from trigger into the revealed box without it closing. That calls for an unbroken surface or a short grace period. Applies only where the pointer can trigger the content.
Gate 3: persistent
No timer that ends the reveal by itself. It ends when the trigger is left, when the user dismisses it, or when the information is no longer valid.
Exception: browser tooltip
Where the visual presentation is controlled by the user agent and not modified by the author, the criterion does not apply. The tooltip from the title attribute is the example the standard names itself.
Exception: input error
Where the revealed content communicates an input error, the dismiss mechanism is not required. The other two conditions remain in force, error messages included.
Boundary: modal dialog
A modal dialog traps focus and expects a decision. It is tested under other criteria. 1.4.13 targets non-modal reveals such as tooltips, submenus and preview cards.
The condition that only concerns the pointer
The title attribute: exception and dead end
The standard sets out an exception: where the visual presentation of the additional content is controlled by the user agent and is not modified by the author, the criterion does not apply (W3C). As an example it explicitly names browser tooltips created through use of the HTML title attribute (W3C). The BITV test has a corresponding exception, but does not word it identically: it turns on the behaviour of revealed content being determined by the user agent, and does not carry the condition that the presentation be left unmodified by the author (BIK BITV-Test). Formally, the native tooltip is therefore the most comfortable route through 1.4.13: it is not tested at all.
Only that route does not lead far. The HTML standard itself discourages relying on the attribute, because many user agents do not expose it in an accessible manner and the tooltip as a rule requires a pointing device, which excludes people working with the keyboard alone as well as anyone on a modern phone or tablet (WHATWG). Buying an exception from 1.4.13 at the price of the content simply not existing for part of the audience means the criterion has been circumvented and the requirement missed. How that plays out in speech output is shown in the article on screen reader optimisation; it can be measured in a screen reader test.
- Where information sits in the title attribute alone, it is as a rule out of reach for keyboard and touch operation (WHATWG). It belongs in the visible text as well, or in a reveal of its own.
- As soon as the browser tooltip's presentation is altered through CSS or JavaScript, the exception falls away, since it presumes a presentation left unmodified by the author (W3C).
- An icon button without a label needs an accessible name, regardless of whether it additionally reveals a tooltip.
- The share of pages passing the check for an accessible name on ARIA tooltips stood at 87 percent in 2025, against 29 percent in 2021 (Web Almanac, 2025) — the direction is right, the remainder is test material.
- Home pages carried more than 133 ARIA attributes on average in 2026, 27 percent more than the year before (WebAIM Million, 2026). Every added attribute is a state that has to match the behaviour.
- Using title as a supplement costs nothing; using it as the only carrier moves the problem into speech output.
A tooltip is not a place for information you need. It is a place for information that helps. Everything required to fill in a field belongs in the visible text beside it — then the reveal decides about convenience, not about access.
The test path: how an audit measures 1.4.13
The BITV test splits the test step into two passes. In the first, the reveal is triggered with the pointer and it is checked whether the pointer can be moved into the revealed content, whether that content stays put and whether it can be dismissed without moving the pointer. In the second, the same component is focused with the keyboard and the check is repeated, leaving out the hoverable condition (BIK BITV-Test). Both passes belong in the report, even where only one of them produces a finding: the second documents that the keyboard side was looked at in the first place. The corresponding technique in the WCAG materials describes the same thought from the development side: the additional content must remain visible to allow users time to read and interact with it, and the user must be able to move the pointer over that content (W3C).
Two practical questions decide the effort. First: what counts as a test case? Testing typically runs per trigger type, not per occurrence. Field help using the same component across forty forms yields one test case; where a variant behaves differently, say a value tooltip in a chart against field help in a form, it counts separately. Second: where does the finding belong? The report carries the component, not the page on which it happened to surface first. How such a list of findings becomes a workable plan is shown in the article on turning an audit report into a remediation plan. The keyboard side is a topic in its own right, set out in the article on keyboard navigation in web development.
- Approach the trigger with the pointer and wait for the reveal. If it appears only after a click and then stays put, this is as a rule not a case for the criterion.
- Leave the pointer in place and watch for twenty seconds. If the content disappears on its own, condition three is broken.
- Press Escape without moving the pointer. If nothing closes, activate the trigger again; if that does not help either, condition one is broken, unless an exception applies.
- Trigger the reveal again and move the pointer into the box on a direct path. If it disappears on the way, condition two is broken.
- Check whether the revealed content obscures or replaces other content, and whether it communicates an input error. That decides the exception to condition one.
- Focus the same component with the tab key and repeat steps two, three and five. Condition two stays out of it here.
- Assign the result to the component, name the trigger type and record both passes in the report, including the one without a finding.
Why the scanner reports nothing here
Typical failure patterns in components
The WCAG materials carry a failure description of their own for this criterion. It describes the situation where users find it difficult or impossible to move the pointer over additional content that appears on hover (W3C). In practice that situation rarely arises on purpose. It arises through a gap of a few pixels between trigger and box, through an immediate hide as soon as the trigger is left, or through positioning that recalculates the box on every small pointer movement. All three causes sit in the component, not in the content — which is precisely why they repeat across every page that uses the component. An accessible design system is the cheapest repair at this point, because one correction reaches every occurrence.
A second pattern concerns state reporting. Where the box becomes visible without anything changing at the trigger, assistive technology learns nothing about it. WAI-ARIA defines the tooltip role as a contextual popup that displays a description for an element, and authors should reference elements carrying that role through aria-describedby before or at the time the tooltip is displayed (W3C). The interplay of role, state and announcement is described in the article on ARIA roles, states and live regions. For field help in forms there is the added question of whether the text is help or an error message; that distinction leads to different requirements and is set out in the article on accessible forms and validation.
- Gap between trigger and box: the pointer leaves both surfaces and the reveal closes before it is reached. The remedy is an unbroken surface or a short grace period before closing.
- Timer instead of trigger binding: the box hides itself after a few seconds. That breaks the persistent condition, however generous the interval.
- Missing dismiss mechanism: neither Escape nor re-activating ends the reveal, although it obscures other content.
- Obscured mandatory field: the box lies over the next field or over an error message. That makes the dismiss mechanism obligatory and additionally disrupts operation with magnification.
- Mouse only: the reveal responds to mouseover but not to keyboard focus. That is not a finding under 1.4.13, but one under the requirement to be operable without a mouse (BIK BITV-Test).
- Submenu with a jump gap: the path from menu item to the expanded area crosses a surface belonging to neither of them.
- Value tooltip in a chart: it follows the pointer and therefore cannot be hovered; here an additional, resting presentation of the values helps, such as a table below the chart.
A pattern that passes all three gates
A workable pattern starts at the trigger. A button is keyboard operable, carries an accessible name and can report a state; an icon without a role can do none of that. The revealed content gets a fixed identifier, is tied to the field through aria-describedby and carries the tooltip role, which WAI-ARIA defines as the contextual display of a description (W3C). One note on classification: the design pattern for tooltips in the ARIA Authoring Practices itself carries the remark that it is work in progress and does not yet have task force consensus (W3C). It is therefore guidance, not a standard — the standard is the three conditions in 1.4.13.
<div class="field-help">
<label for="vatid">VAT identification number</label>
<input id="vatid" name="vatid" type="text"
aria-describedby="vatid-hint" />
<!-- Trigger: a button, not an icon without a role -->
<button type="button" class="field-help__button"
aria-expanded="false" aria-controls="vatid-hint">
<span class="visually-hidden">Show format hint</span>
<svg aria-hidden="true" focusable="false" width="16" height="16">
<use href="#icon-hint" />
</svg>
</button>
<!-- No gap to the button: the pointer can travel across -->
<div id="vatid-hint" class="field-help__box" role="tooltip" hidden>
Format: country code and nine digits, for example DE123456789.
</div>
</div>The identifier vatid-hint ties two things together at once: it describes the input field permanently through aria-describedby and names the region the button controls through aria-controls. The class name field-help__box carries the decisive property in the stylesheet: the box sits flush against the button so the pointer path has no gap. Where the design calls for visible spacing, an invisible but hoverable bridge made of padding takes over that job. The second half of the pattern lies in the behaviour.
const group = document.querySelector(".field-help");
const button = group.querySelector(".field-help__button");
const box = group.querySelector("[role='tooltip']");
let pointerInBox = false;
const show = () => {
box.hidden = false;
button.setAttribute("aria-expanded", "true");
};
const hide = () => {
if (pointerInBox) return;
box.hidden = true;
button.setAttribute("aria-expanded", "false");
};
// Condition 1: dismiss without moving pointer or focus
document.addEventListener("keydown", (event) => {
if (event.key === "Escape" && !box.hidden) {
pointerInBox = false;
hide();
}
});
button.addEventListener("click", () => {
pointerInBox = false;
box.hidden ? show() : hide();
});
// Condition 2: the pointer may travel into the box
box.addEventListener("pointerenter", () => { pointerInBox = true; });
box.addEventListener("pointerleave", () => {
pointerInBox = false;
hide();
});
// Condition 3: no timer that ends the reveal by itself
button.addEventListener("pointerenter", show);
button.addEventListener("focus", show);
button.addEventListener("pointerleave", () => {
window.setTimeout(hide, 0);
});
button.addEventListener("blur", () => {
pointerInBox = false;
hide();
});Three places carry the three conditions: the Escape branch and the click on the button carry the first gate, the two pointer events on the box carry the second, and the absence of any timer carries the third. The deferred call on leaving the button is not a hide timer; it postpones the decision by one turn so that the pointer arriving in the box is registered first. One task remains that no code solves: the pattern should be tested once and then moved into the component library, so that every field help in the house behaves the same way. Teams looking for that grounding will find it in our training; anyone wanting the existing estate measured will find it in the WCAG audit. Related questions on delivering additional content are covered in the article on integrating sign language videos.
Sources and studies
Related Articles
Accessible Appointment Booking Without Barriers
Self-built date pickers fail on keyboard, focus and target size. How to make appointment booking operable under WCAG 2.2 for screen reader and keyboard users.
Forced Colors: Supporting High Contrast Mode Properly
What forced colors mode does to your design, which properties fall away in the process and how to set up forced-colors, system colours and focus styles cleanly.
Accessible Maps: Store Locators Without Dead Ends
Map widgets fail audits with striking regularity. How a location search still works without a mouse, without colour perception and with a screen reader: list.