Best practices

Visible focus: why outline: none breaks keyboard accessibility

If you remove the CSS outline for aesthetic reasons, you make the site unusable with a keyboard. This widespread practice violates two WCAG criteria: visible focus (2.4.7) and non-obscured focus (2.4.11). Modern solutions, such as :focus-visible and outline-offset, allow for a discreet, high-contrast, and compliant indicator.

The short answer

The focus indicator (often a grey or blue outline) signals that a form element, link, or button is receiving keyboard interaction. Removing this outline with `outline: none` without replacing it makes keyboard navigation invisible: a serious barrier for any user who cannot use a mouse. WCAG criterion 2.4.7 requires it; 2.4.11 specifies that it must not be hidden.

Focus does not only serve to show that an element is selected. It also helps users understand where they are in the page flow, which action will be triggered by the Enter key, and which field will receive the next input. Without a visual cue, the user must guess their position or restart navigation from the beginning.

The fix, therefore, is not to necessarily keep the browser’s native style. It is to ensure a perceptible, consistent, and sufficiently contrasted indicator on every interactive component. This indicator can align with the site’s graphic identity, provided it remains visible in all states and on all backgrounds.

Why outline: none became a habit

The default browser outline is a fairly thick grey or blue rectangle, imposed since the 1990s for accessibility security. By the 2010s, designers deemed it unaesthetic: it would “break” the clean design. CSS resets (Normalize, Reset, or native Bootstrap) began hiding it, often without replacement: “outline: none” spread as a standard pattern in frameworks and development workshops.

The problem is systemic: this suppression is almost automatic, rarely intentional. The Inclaria 2026 study shows that among the 55 French e-commerce sites analysed, the majority of critical non-conformities include at least one outline suppression without replacement. It’s a symptom: no keyboard testing, no accessibility review upstream of design.

Another common cause is the confusion between focus triggered by a click and focus triggered by the keyboard. Teams want to remove the ring that appears after a mouse click, then apply outline: none to all :focus states. This rule then also affects people who use Tab, Shift + Tab, or assistive technology. :focus-visible precisely addresses this issue by distinguishing interaction modalities.

Who is blocked?

Four profiles are directly impacted.

• Keyboard-only users: motor disabilities, tremors, paralysis, or assistive technology (pedal, adapted mouse). They see nothing happening when they tab through the form.
• Users who navigate by keyboard by preference: developers, data analysts, power users who save 15 seconds per form, blind and visually impaired users navigating with a screen reader (which often relies on the browser’s visual focus or a reader ring).
• Older users or those experiencing motor fatigue: mouse precision becomes difficult; the keyboard is easier and faster.
• Temporary disability situations: broken arm, faulty trackpad, working on a touchscreen monitor without a mouse.

The blockage can be total on a long form. A person may reach the validation button without knowing which control is active, accidentally trigger a secondary link, or modify a field that has already been filled in. On a modal window, the lack of an indicator can also give the impression that the keyboard is no longer working, while the focus continues to move to invisible elements or those located behind the window.

The WCAG criteria at stake

Two criteria pose problems:

At the legal compliance level, these two criteria are AA-level, mandatory in France under the European directive (European Accessibility Act, applicable from 28 June 2025 for new services, 28 June 2030 for existing services).

Visibility must be verified under real usage conditions, not just on an isolated component in a design library. A compliant ring on a white background may become imperceptible in a blue banner, be clipped by overflow: hidden, or disappear under a fixed-position header. Compliance therefore depends on the final rendering, the element’s position, and its visual environment.

The modern solution: :focus-visible and outline-offset

Modern browsers and assistive technologies support :focus-visible (since 2018, IE 11 is not supported, but it requires a fallback strategy: .element:focus { outline: 2px solid #0066cc; } followed by .element:focus-visible { /* refined rules */ }).

The key rule to remember: :focus-visible targets only keyboard focus, not mouse focus (on .element:focus-visible { … }). This keeps the interface clean on click while maintaining keyboard accessibility.

Example 1: Replacing the default outline

a, button, input:focus-visible { outline: 2px solid #0066cc; outline-offset: 2px; }

Here, outline-offset: 2px creates space between the element and the ring, preventing content from being obscured (criterion 2.4.11).

For consistent coverage, the same logic must be applied to other interactive components: text areas, dropdown lists, custom controls, elements with tabindex, and JavaScript widgets. Adding a rule only to links and buttons often leaves gaps in the keyboard navigation path.

Example 2: High-contrast grey outline, for dark mode too

a:focus-visible, button:focus-visible, input:focus-visible { outline: 3px solid #333; outline-offset: 4px; } @media (prefers-color-scheme: dark) { a:focus-visible, button:focus-visible, input:focus-visible { outline: 3px solid #fff; } }

The minimum 3:1 contrast (link 1.4.11, grey shade) is respected: #333 on white = 8.6:1 contrast.

Example 3: box-shadow as an indicator

What if you really want to replace the outline? box-shadow works too, but it doesn’t create an offset like outline-offset:

a:focus-visible { outline: none; box-shadow: 0 0 0 3px #0066cc; }

Caution: box-shadow consumes slightly more GPU than outline and isn’t drawn outside containers with `overflow: hidden`. outline is more robust.

If outline: none remains necessary in a specific rule, its replacement must be defined in the same block or in an immediately identifiable rule. This proximity reduces the risk that a future cascade modification removes the alternative indicator. Combined states must also be tested, particularly :hover, :active, :disabled, and :focus-visible, to ensure a more specific style doesn’t accidentally override the focus.

How to test that focus is visible

• Press the Tab key on the keyboard: each interactive element (link, button, input field) must have a visible ring around it.
• Open the browser’s DevTools (F12), go to the « Accessibility » tab (Chrome, Edge) or « Inspector → Accessibility » (Firefox), and check the focus indicator while tabbing.
• Use a screen reader (NVDA on Windows, VoiceOver on Mac/iOS): it announces the element in focus; the visual focus must follow simultaneously.

The test must cover the entire page in both directions, using Tab and then Shift + Tab. The navigation order must remain logical, the indicator must never disappear, and no element should trap the keyboard. Menus, accordions, modal windows, and dynamic components must also be tested, as their behaviour is not always visible during a simple walkthrough of the main page.

Finally, test multiple screen widths and zoom levels. At 200%, a fixed header or consent banner may cover the focused element, even if everything appears correct at 100%. The focus must remain at least partially visible when content reflows.

Detection of outline removal

The Inclaria scanner tests two things: (1) the presence of a visible focus indicator on key elements (forms, buttons, links); (2) the offset of this indicator (no masking under a fixed menu, for example). A removal of outline: none without replacement is flagged as non-compliant with WCAG 2.4.7.

The report prioritizes this defect: it often appears on hundreds of elements (CSS reset applied globally), and has a direct impact on usability.

Automated detection makes it possible to quickly identify suspicious CSS rules and components without replacement styling. However, it must be supplemented by a manual keyboard test, as actual visibility depends on contrast, graphical context, scrolling, and any overlapping elements.