On each web page, for each element that receives focus, is the focus indicator visible?
A user navigating by keyboard — because they cannot use a mouse, or simply prefer not to — must know at all times where they are on the page. Without a visible focus indicator, they press Tab, nothing changes visually, and they do not know which link or button is active. This is total exclusion.
Criterion 10.7 requires that every focusable element display a clear visual indicator when it receives focus. This indicator can be an outline, a background change, or both — but it must be sufficiently contrasted against the adjacent background: contrast ratio ≥ 3:1. This threshold applies to the color of the indicator itself, not the contrast of the element's text.
In practice, check all elements reachable by Tab: links, buttons, form fields, dropdowns, and any element with a tabindex attribute. Navigate through the page using only the Tab key and observe: is the focus indicator visible? Is it sufficiently contrasted?
For implementation, the CSS pseudo-class :focus-visible is the recommended approach: it displays the indicator only during keyboard navigation, without affecting the appearance on mouse click. Its browser support is now very satisfactory.
Un test to ensure that the focus indicator is always visible
Visible and contrasted focus indicator
- List all focusable elements on the page:
- Native elements: links (
<a href>), buttons (<button>), fields (<input>,<select>,<textarea>), and other form controls. - Non-native elements with a
tabindexattribute whose value is ≥ 1.
- Native elements: links (
- Navigate through the page using only the Tab key (and Shift+Tab to go back) — without touching the mouse.
- Each time focus is received, verify that a visual indicator is present: visible outline, background color change, or combination of both.
- Measure the contrast between the focus indicator (outline color or modified background color) and the adjacent background: the ratio must be ≥ 3:1.
- If all elements display a visible and sufficiently contrasted indicator, the test is validated. A single element without a compliant indicator is enough to fail it.
Examples
❌ Non-compliant : Removal of focus without alternative
<style>
/* CSS reset that erases focus across the entire page */
*:focus {
outline: none;
}
</style>
<nav>
<a href="/home">Home</a>
<a href="/services">Services</a>
<a href="/contact">Contact</a>
</nav>
<form>
<label for="email">Email address</label>
<input type="email" id="email" name="email">
<button type="submit">Sign up</button>
</form>This is the most common error in audits. The *:focus { outline: none } selector removes the focus indicator on absolutely all elements on the page. The user navigating by keyboard sees no visual indication of their position. Criterion 10.7.1 fails for the entire page in a single CSS block.
✅ Compliant : Custom and contrasted focus indicator with :focus-visible
<style>
/* `:focus-visible` : keyboard navigation only */
a:focus-visible,
button:focus-visible {
outline: 3px solid #0054AE;
outline-offset: 3px;
border-radius: 2px;
}
input[type="email"]:focus-visible,
input[type="text"]:focus-visible,
select:focus-visible,
textarea:focus-visible {
outline: 2px solid #0054AE;
outline-offset: 2px;
background-color: #EBF3FF;
}
</style>
<nav>
<a href="/home">Home</a>
<a href="/services">Services</a>
</nav>
<form>
<label for="email">Email address</label>
<input type="email" id="email" name="email">
<button type="submit">Sign up</button>
</form>:focus-visible guarantees the indicator during keyboard navigation only — mouse users do not see an outline on click. The blue #0054AE on white background achieves a contrast ratio of 4.6:1, higher than the required threshold of 3:1. The outline-offset creates visual space between the element and its outline, which improves readability even on colored backgrounds.
Tips and pitfalls
⚠️ outline: none in global CSS resets
In the majority of audits, the same cause comes back: a developer removed focus for aesthetic reasons, or a CSS reset (Normalize, Meyer Reset) erased it without anyone noticing. Check early in the audit if a *:focus { outline: none } or a:focus { outline: 0 } rule is present in global style sheets — this is often where everything hinges.
💡 Prefer :focus-visible to :focus
:focus applies as soon as an element receives focus, whether by keyboard or mouse click. :focus-visible is active only during keyboard navigation. Result: mouse users do not see an outline on click (experience preserved), and keyboard users always see the indicator (accessibility guaranteed). Browser support is now very good, and this is the recommended approach.
⚠️ A visible indicator but below the contrast threshold
The criterion does not only require that focus be visible — it requires a ratio ≥ 3:1 between the indicator and the adjacent background. A light gray outline (#aaaaaa) on a white background gives a ratio of 2.3:1: visually present, but non-compliant. Always measure with a dedicated tool like Includdy or browser DevTools before validating.
⚠️ Custom components with tabindex="0"
A <div tabindex="0"> or a <span role="button" tabindex="0"> receives focus from the keyboard like a native element, but some browsers apply no default focus style to these elements. If your interface uses custom ARIA components — dropdowns, accordions, tabs — explicitly style their :focus-visible state. Test 10.7.1 covers elements with tabindex ≥ 1, but in practice, every element reachable by keyboard should be treated.
⚠️ tabindex="-1" outside the scope of the test
An element with tabindex="-1" cannot be reached by the Tab key: it is not within the scope of test 10.7.1. This mechanism is common for managing focus by script — for example, returning focus when opening a modal. These elements do not need a visible focus indicator under this criterion.
Frequently asked questions
How to replace outline: none with box-shadow while respecting RGAA criterion 10.7?
Yes, provided that the box-shadow is sufficiently contrasted: ratio ≥ 3:1 between the shadow color and the adjacent background. Test 10.7.1 accepts any visual indicator — outline, background, drop shadow — as long as it is present and measurable. Measure the box-shadow color against the page background, not against the element's color itself.
How to audit RGAA criterion 10.7 on focus visibility?
Put your mouse down and navigate through the page only with Tab. You must see at all times where you are. If you "lose" focus visually at any point — the indicator disappears or becomes imperceptible — the criterion fails. Then complete with a contrast measurement tool to validate the ≥ 3:1 ratio on each observed indicator.
Why does RGAA 10.7 fail so often despite native browser focus?
Modern browsers display focus well by default, but project style sheets erase it regularly — CSS reset or :focus { outline: none } rule added for aesthetic reasons. This is the near-systematic cause of failure in criterion 10.7. The golden rule: never remove focus without replacing it with an indicator at least as visible.
What is the difference between RGAA 10.7 and WCAG 2.4.7?
WCAG 2.4.7 Focus Visible (level AA) requires that keyboard focus be visible, without specifying a contrast threshold. RGAA 10.7 goes further: it requires the indicator to achieve a ratio ≥ 3:1. An indicator compliant with WCAG 2.4.7 may therefore not be compliant under RGAA if its contrast is insufficient.
Why is a colored background alone not enough as a focus indicator according to RGAA 10.7?
Yes it is. Test 10.7.1 explicitly accepts a background change as the sole indicator, without a mandatory outline. The condition: that the contrast between the resting background color and the focus background color is ≥ 3:1. Combining background and outline remains best practice for low-vision users, as both signals reinforce each other.