WCAG 1.4.13 Content on Hover or Focus

What it asks

Tooltips, hover menus, previews and popovers appear on hover or focus and disappear when it ends. For someone using a screen magnifier, the pop-up may cover the thing they were reading, and they may need to move the pointer onto it to read it at all. This rule sets three conditions on such content.

Dismissible: there is a way to close it without moving the pointer or the focus, usually the Escape key. The exception is content that reports an input error, or that does not cover or replace anything, so it never gets in the way. Hoverable: if hovering triggered it, the pointer can be moved onto it without it disappearing. Persistent: it stays until the hover or focus ends, the person dismisses it, or the information is no longer valid. It must not vanish on a timer.

Content whose look is controlled by the browser and not changed by the author is exempt. The W3C’s example is the tooltip a browser draws from the HTML title attribute. Custom tooltips, sub-menus and other non-modal pop-ups built by the site are covered. Content that appears on focus but adds nothing new, such as a skip link that is hidden until focused, is not covered, because it is the component itself rather than additional content.

The three conditions have different fixes, so a good report says which one failed. A missing Escape handler, a gap between the trigger and the tooltip, and a timer that closes a menu are three different bugs.

Its official name is success criterion 1.4.13 Content on Hover or Focus, at Level AA. It was added in WCAG 2.2, under guideline 1.4 Distinguishable and the principle Perceivable. The W3C’s normative text says, in part:

“Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:”

From WCAG 2.2, W3C. Full explanation: Understanding 1.4.13 Content on Hover or Focus.

Who it helps

People using screen magnification, who see only part of the page. A tooltip that appears outside their view has to be reached with the pointer, and one that covers the text they were reading has to be closable without losing their place.

People with low vision who need time to read a pop-up, people with tremors who cannot keep a pointer perfectly still, and keyboard users who need the pop-up to close with a key.

What passes and what fails

These pass

• A custom tooltip that stays while the pointer is over it or its trigger, and closes with Escape.
• A hover menu that stays open while the pointer travels from the heading into the items, with no gap between them.
• A browser tooltip from the title attribute. The browser controls it, so it is exempt.
• A field hint that appears on focus beside the field, covers nothing, and so needs no dismiss mechanism.

These fail

• A tooltip that disappears as soon as the pointer leaves the trigger, so it cannot be reached or read.
• A tooltip with a gap between it and its trigger, which closes as the pointer crosses the gap.
• A dropdown menu that closes by itself after a few seconds.
• A popover that covers the text beneath it and has no Escape handler, so the only way to close it is to move away.
• A custom tooltip that closes when the pointer moves towards it, before it arrives.

How to test it by hand

1. Find everything that appears on hover or focus: tooltips, hover menus, preview cards, popovers and hints. Hover over controls and icons, and tab through the page watching for new content.
2. For each, hover to open it and press Escape without moving. It should close. If it covers nothing and replaces nothing, or it reports an input error, it need not.
3. Open it again and move the pointer slowly from the trigger onto the content. It should stay open while the pointer is over it.
4. Open it and wait. It should not close on its own.
5. Tab to the trigger with the keyboard and repeat the Escape check.
6. Note each item that failed, and which of the three conditions it failed, because each has a different fix.

What automated testing can decide

What a machine can decide

All three conditions are yes or no questions, so automated testing can try them. A tool can open a tooltip or hover menu the way a person would, press Escape and see whether it closed, move onto it and see whether it stayed, and wait to see whether it closed by itself. It can also see whether the content covers anything, which decides whether the dismiss condition applies.

What it cannot

A tool only knows about the pop-ups it managed to open, and only in the states it reached. A tooltip inside a menu it never opened is untested. A timer longer than the tool waits looks like persistence. And whether content "communicates an input error", one of the exceptions to the dismiss condition, is about what the words say.

How Dreven handles it

Dreven finds the tooltips, hover menus and popovers on your pages and shows you how each one behaved, with the element, the page and a picture of the content open. A reviewer decides each result and signs the report.

The report lists the pop-ups that were tested, so a pass covers those and nothing more; a pop-up that was not reached is never counted as a pass.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.1.1 Keyboard (Level A). The pop-up and its trigger must work from the keyboard.
• 2.4.11 Focus Not Obscured (Minimum) (Level AA). A pop-up must not completely hide the control that has focus.
• 3.2.1 On Focus (Level A). Focus alone must not cause a change of context, such as opening a new page.
• 4.1.2 Name, Role, Value (Level A). A tooltip or menu needs the right name, role and state in code.

Questions people ask

All WCAG 2.2 criteria, in plain words