On each web page, can additional content that appears on hover, focus or activation of an interface component be reached with the keyboard, where necessary?
A user navigating by keyboard activates a button and sees a panel appear containing a link. If they cannot reach this link with Tab, this content does not exist for them. This is exactly what criterion 12.11 verifies.
The criterion applies to all additional content — tooltips, dropdowns, panels, popovers — that appear on hover, focus, or activation of a component. However, it only applies if this additional content contains interactive components: links, buttons, form fields. Purely informational content creates no reachability obligation under this criterion.
Two situations systematically cause non-compliance. First situation: the additional content appears, but focus remains trapped on the trigger without ever entering the panel. Second situation: the tab sequence skips over the additional content, invisible in the keyboard reading order.
Two approaches fix the problem. Either move focus programmatically to the first interactive element of the panel on opening, via .focus(). Or insert the additional content into the DOM immediately after the trigger element, so Tab reaches it naturally without additional JavaScript management.
Un test to ensure that additional content remains reachable by keyboard
Keyboard reachability of components in additional content
- List all additional content on the page: tooltips, dropdowns, panels, popovers, custom tooltips — anything that appears on hover, focus, or activation of an interface component.
- For each additional content, check whether it contains interactive elements (links, buttons, input fields, etc.). If the content is purely textual, skip it — this test does not apply.
- For each additional content containing interactive elements: navigate exclusively by keyboard (Tab and Shift+Tab, without mouse) and attempt to reach these interactive elements.
- Result: the test is validated if every interactive element in every additional content is reachable by keyboard. It fails as soon as a single interactive element remains inaccessible.
Examples
❌ Non-compliant : Tooltip with link inaccessible by keyboard
<div class="tooltip-wrapper">
<button aria-describedby="tip1">Learn more</button>
<div id="tip1" role="tooltip" class="tooltip">
See our <a href="/help">complete guide</a> for more details.
</div>
</div>
<style>
.tooltip { display: none; }
.tooltip-wrapper:hover .tooltip,
.tooltip-wrapper:focus-within .tooltip {
display: block;
}
</style>The tooltip displays on button focus thanks to :focus-within, but role="tooltip" tells the browser this is passive description. Focus cannot enter this content via Tab. The keyboard user sees the tooltip appear, but the link "complete guide" is unreachable. The non-compliance is invisible to visual inspection.
✅ Compliant : Interactive panel with proper focus management
<div class="popover-wrapper">
<button
id="trigger-btn"
aria-expanded="false"
aria-controls="popover1"
onclick="openPopover()"
>Learn more</button>
<div
id="popover1"
role="dialog"
aria-labelledby="popover-title"
hidden
>
<h3 id="popover-title">Additional resources</h3>
<a href="/help">View the complete guide</a>
<button onclick="closePopover()">Close</button>
</div>
</div>
<script>
function openPopover() {
const popover = document.getElementById('popover1');
const btn = document.getElementById('trigger-btn');
popover.hidden = false;
btn.setAttribute('aria-expanded', 'true');
popover.querySelector('a, button').focus();
}
function closePopover() {
const popover = document.getElementById('popover1');
const btn = document.getElementById('trigger-btn');
popover.hidden = true;
btn.setAttribute('aria-expanded', 'false');
btn.focus();
}
</script>When the button is activated, focus is automatically moved into the panel via .focus(). The keyboard user can reach the link and the "Close" button. role="dialog" is appropriate because the content is interactive. Returning focus to the trigger button on closing completes the keyboard experience.
Tips and pitfalls
⚠️ role="tooltip" blocks keyboard access to interactive elements
This is the most common pitfall in auditing this criterion. When a developer uses role="tooltip" on additional content containing a link, browsers exclude this content from the tab order — this is the intended behavior for a purely descriptive tooltip. If your "tooltip" contains interactive elements, it must not have role="tooltip". Use role="dialog" or leave the container without a specific ARIA role.
⚠️ Additional content without interactive element: criterion not applicable
A tooltip that displays only descriptive text (a definition, contextual explanation) is not subject to criterion 12.11. The phrase "if necessary" in the criterion title refers precisely to this condition. However, criterion 10.13 remains applicable: this same content must be controllable (dismissible, hoverable, persistent) even if it contains no interactive elements.
💡 Insert additional content just after the trigger in the DOM
If additional content is inserted into the DOM immediately after the trigger button, the natural tab order allows reaching it without JavaScript focus management. Problems arise when content is injected at the end of <body> or in a React or Vue portal disconnected from the logical DOM tree.
⚠️ Dropdown triggered only on mouse hover
A menu that displays exclusively on mouseover — without a keyboard focus equivalent — compounds two non-compliance issues: criterion 12.11 (menu links are unreachable) and potentially criterion 12.9 if focus becomes trapped during navigation. The fix involves :focus-within in CSS or a keydown handler in JavaScript to trigger opening via keyboard as well.
⚠️ Native HTML components: compliant by default
Native elements like <select> or <details>/<summary> handle keyboard navigation natively and satisfy the criterion without intervention. Criterion 12.11 targets primarily custom JavaScript components: custom dropdowns, popovers, dropdowns built with <div> and JavaScript.
Frequently asked questions
How do you audit RGAA criterion 12.11 on additional content without a pointing device?
Navigate with Tab only. When additional content appears following focus on a trigger, continue pressing Tab and observe whether focus enters this content. If Tab jumps over it to reach the next element on the page, the criterion is non-compliant. For content that only appears on mouse hover, first activate the trigger via keyboard (Enter or Space) and check whether the content displays and becomes reachable.
What is the difference between criterion 12.11 and criterion 10.13?
12.11 verifies that interactive elements inside additional content are reachable by keyboard. 10.13 verifies that the user can control the display of the additional content itself (close it without moving the pointer, keep content visible on hover, etc.). Both criteria can apply simultaneously to the same component. 10.13 corresponds to WCAG 1.4.13 (level AA); 12.11 corresponds to WCAG 2.1.1 (level A).
Which keyboard keys allow reaching a navigation dropdown compliant with RGAA criterion 12.11?
Both approaches are valid depending on the ARIA pattern implemented. For a menu with role="menu" and role="menuitem", the ARIA pattern recommends arrow keys (up/down) to navigate between items, and Tab to exit the menu — this is the "composite widget" pattern. For simple links in a panel without role="menu", Tab is the natural method. The essential point: every interactive element must be reachable somehow via keyboard.
How can a React or Vue portal injecting content at the end of <body> comply with criterion 12.11?
Not automatically. When content is injected far in the DOM from the trigger, the natural tab order does not allow reaching it. In this case, focus must be moved programmatically on opening with .focus() and returned to the trigger on closing. Modals and panels managed via portals require this explicit focus management to satisfy this criterion.
When does additional content visible only on mouse hover become non-compliant under criterion 12.11?
Yes, for criterion 12.11, if the content does not also display during keyboard navigation. A keyboard user cannot trigger a mouse hover. If the content never appears on focus or keyboard activation, its interactive elements are inaccessible by definition. The fix: trigger display on :focus or :focus-within in CSS, or via a focusin listener in JavaScript.