On each web page, can additional content that appears via CSS styles alone be made visible with the keyboard and any pointing device?
A keyboard user has no pointer. If your tooltip or submenu only appears on CSS hover (:hover), it remains invisible to anyone not using a mouse. This is the most silent error in modern interfaces: visually everything works, but on keyboard, the content disappears.
This criterion covers all additional content triggered exclusively by CSS pseudo-classes :hover or :focus. Tooltips, dropdown menus, context panels, help bubbles: as soon as content becomes visible only through a CSS selector, it must also be accessible by keyboard (via :focus) and any other pointing device.
Concretely, two directions: if you use :hover, add :focus and :focus-within to the same element so keyboard users see the same content. If you use :focus, verify that the content also displays on hover. Both pseudo-classes must always go together.
Practical test: tabulation only, without mouse. Any content that appears on hover must appear on focus.
2 tests to verify that content generated by CSS is accessible
CSS :hover content accessible on focus
- Identify all content that appears only via
:hoveron an interface component (tooltip, submenu, context panel, etc.). - For each one, verify that the same additional content is visible in at least one of these situations :
- Activation of the component by keyboard (Enter or Space key) or via another pointing device.
- Focus on the component (Tab or Shift+Tab).
- Activation or focus on another trigger component.
- Test using only the keyboard and navigate by tabulation.
- If the additional content remains accessible in at least one of these scenarios for each instance, the test is validated. If a single piece of content remains invisible on keyboard, the test fails.
CSS :focus content accessible on hover
- Identify all content that appears only via
:focuson an interface component. - For each one, verify that the same additional content is visible in at least one of these situations :
- Activation of the component by keyboard or via another pointing device.
- Hover of the component with the mouse (
:hover). - Activation or hover of another trigger component.
- Test using only the mouse to confirm that the content remains accessible without keyboard.
- If the additional content is accessible in at least one of these scenarios for each instance, the test is validated. Otherwise, the test fails.
Examples
❌ Non-compliant : Tooltip visible only on CSS hover
<style>
.tooltip-text {
display: none;
}
.tooltip:hover .tooltip-text {
display: block;
}
</style>
<span class="tooltip">
Learn more
<span class="tooltip-text">This field accepts only professional email addresses.</span>
</span>The .tooltip-text content is only revealed on CSS hover. A keyboard user who reaches this element by tabulation will never see the information about professional email addresses. Criterion 10.14.1 fails.
✅ Compliant : Tooltip accessible on hover and focus
<style>
.tooltip-text {
display: none;
}
.tooltip:hover .tooltip-text,
.tooltip:focus .tooltip-text,
.tooltip:focus-within .tooltip-text {
display: block;
}
</style>
<span class="tooltip" tabindex="0">
Learn more
<span class="tooltip-text">This field accepts only professional email addresses.</span>
</span>By adding :focus and :focus-within to the same CSS rules, the tooltip also displays when navigating by keyboard. The tabindex="0" attribute makes the element focusable. A keyboard user receives exactly the same information as a mouse user.
✅ Compliant : Keyboard-accessible dropdown submenu
<style>
.submenu {
display: none;
}
.nav-item:hover .submenu,
.nav-item:focus-within .submenu {
display: block;
}
</style>
<nav>
<ul>
<li class="nav-item">
<a href="/products">Products</a>
<ul class="submenu">
<li><a href="/products/software">Software</a></li>
<li><a href="/products/services">Services</a></li>
</ul>
</li>
</ul>
</nav>:focus-within on the parent container is key: when any child (the parent link or a submenu link) receives focus, the submenu stays open. Without :focus-within, the submenu closes as soon as focus moves from the trigger to child links.
Tips and pitfalls
⚠️ Forgetting :focus-within on dropdown menus
Adding :focus on the trigger is not enough for multi-level menus. As soon as focus moves to the first child link, the trigger element loses focus and the menu closes. This is the number one error in audits: the menu seems accessible because it opens on focus, then closes immediately. Use :focus-within on the parent container.
⚠️ Additional CSS content generated by ::before or ::after
This criterion only covers content that carries information. A ::before pseudo-element that displays a decorative icon on hover is not affected. However, if ::after displays informational text (a label, a status, a counter), it must also be visible on keyboard. In practice, ::before/::after content is rarely focusable — prefer a hidden <span> with the .sr-only technique for this type of content.
💡 Prefer selector combinations over JavaScript
For most cases (tooltips, simple menus), the pure CSS solution with :hover, :focus, :focus-within is sufficient and more robust than JavaScript. It works without JS enabled and generates no events to manage. Reserve JavaScript for complex interactions that require state management (aria-expanded, aria-hidden).
⚠️ Pointing devices other than mouse
The criterion mentions 'any pointing device': stylus, touchscreen, trackpad. On mobile, there is no native hover. Content conditioned only to :hover will be invisible on tablet and smartphone. The :focus and :focus-within pseudo-classes cover these devices during direct interaction.
⚠️ This criterion does not apply to decorative content
A background color, drop shadow, or opacity change triggered by :hover are not 'additional content carrying information'. Criterion 10.14 targets elements that provide new information to the user: text, image, panel, submenu. A simple style effect is not affected.
Frequently asked questions
How to quickly audit RGAA criterion 10.14 on additional CSS content?
Unplug the mouse. Navigate by tabulation and verify that each piece of content that normally appears on hover is also visible on focus. Then, navigate using only the mouse to verify the opposite (test 10.14.2). A tool like DevTools 'Force element state' also allows you to simulate :hover and :focus simultaneously to compare CSS states.
When does the :hover, :focus combination in CSS satisfy RGAA criterion 10.14?
For simple tooltips on a single focusable element, yes. For dropdown menus with multiple child links, no. You must add :focus-within to the parent container, otherwise the menu closes as soon as focus leaves the trigger to go to internal links. This is the most frequently missed scenario in production.
How does RGAA criterion 10.14 apply to JavaScript menus with aria-expanded?
No, this criterion specifically targets content made visible 'via CSS styles only'. If visibility is controlled by JavaScript (class change, aria-hidden modification, etc.), criterion 10.14 does not apply. It is then WCAG criterion 2.1.1 and RGAA criteria on interactive components (theme 7) that come into play.
In which cases does a non-focusable element satisfy the RGAA 10.14.1 test?
None. If the trigger is not in the tab order (no tabindex, not a native interactive element), it cannot receive focus and the additional content remains inaccessible on keyboard. You must either make the element focusable with tabindex="0", or find another component on the page that triggers the display on its activation or focus.
How to distinguish between RGAA criteria 10.13 and 10.14 on additional CSS content?
Criterion 10.13 verifies that additional content is controllable by the user (ability to close it, move it, keep it visible). Criterion 10.14 only verifies that it appears on keyboard and pointing devices. Both cumulate: a tooltip can satisfy 10.14 (it displays on focus) but fail 10.13 if it disappears as soon as the user moves the pointer to read it.