Why Focus Outlines Keep Getting Removed From Buttons and Links

Open the developer tools on a surprising number of modern, well designed looking websites, search the stylesheet for the word outline, and you will find a line that sets it to none on every button and link, usually inside a CSS reset copied in during the project's very first week. That one line quietly breaks keyboard navigation for anyone who does not use a mouse, and it almost never gets written with any intention of harming accessibility. It gets written because the default browser outline looks unpolished, and removing it is the fastest way to make a design screenshot look clean.

The outline is not decoration, it is the only signal some users get

A mouse user always has a visible pointer telling them exactly where their next click will land. A keyboard user tabbing through a page has no cursor at all, and the focus outline is the entire mechanism that tells them which element is currently active and would respond if they pressed enter or space. Remove that outline, and a keyboard user is tabbing through an invisible sequence of elements with no way to know where they are, which is functionally the same as removing the mouse cursor from the screen for everyone else. This is one of the clearest, most testable accessibility failures that exists, and it is also one of the easiest to introduce by accident, which is exactly why it shows up so often, a pattern covered from the testing side in keyboard navigation is the accessibility test most sites fail.

Why default outlines get removed in the first place

Browser default focus outlines vary between browsers, often appear as a chunky blue ring that clashes with a carefully chosen colour palette, and sometimes trigger on a mouse click too, not just a keyboard tab, which some designers find visually distracting. A global reset stylesheet, copied from a template or a boilerplate project, frequently includes outline none applied to every interactive element as a blanket fix for all of this at once. The intention is almost always purely visual tidiness, and the accessibility cost is simply never considered at the moment that line gets pasted in, because it does not visibly break anything if you are testing with a mouse.

The fix is not bringing back the ugly default, it is styling your own

Removing the default outline is not actually the sin here. The sin is removing it and replacing it with nothing. A custom focus style, a coloured border, a background change, a shadow, or a combination of these, can look exactly as polished as the rest of a carefully designed interface while still giving keyboard users a clear, visible signal of where they are. This is normally only a few lines of CSS targeting the focus state specifically, and it resolves the entire problem without forcing anyone to live with a mismatched blue ring.

Only showing the outline for keyboard users is now genuinely possible

For years, one real complaint behind removing outlines was that clicking a button with a mouse also triggered the same outline, which did feel unnecessary for a sighted mouse user who already saw their own click land. Modern CSS has a selector built specifically to solve this, which shows a focus style only when an element was reached through keyboard navigation and stays invisible for an ordinary mouse click. Reaching for this selector resolves the original visual complaint entirely, without the blanket removal that breaks keyboard access for everyone else, and it is a far better fix than the global outline none reset that caused the problem.

This failure is invisible to almost everyone who could catch it

A developer testing their own work with a mouse will never notice this bug, because a mouse never depends on the focus outline to work. A designer reviewing a static screenshot will never notice it either, since the outline only appears during actual keyboard interaction, not in a static image. This is exactly the kind of issue that automated scanning tools frequently flag as present without any context on severity, and it is also exactly the kind of issue that a thirty second manual tab-through test catches immediately and definitively, a gap between automated and manual testing covered more broadly in why automated accessibility scanners miss most real problems.

A quick test you can run on any site right now

Load any page, click once on the address bar to make sure focus is away from the page content, then press the tab key repeatedly without touching the mouse at all. On a well built site, a visible marker moves clearly from element to element with every press. On a site with this bug, nothing visible happens at all, even though focus is technically moving invisibly underneath, which means a keyboard user genuinely cannot tell what they are about to activate before they press enter.

A short checklist for fixing this properly

1. Search your stylesheet for any rule setting outline to none, especially inside a copied CSS reset.
2. Never remove a focus style without immediately replacing it with a custom one.
3. Use the keyboard-only focus selector to avoid an unwanted outline on ordinary mouse clicks.
4. Run the tab-key test yourself on your own site before assuming it is fine.
5. Check custom components too, not just native buttons and links, since custom elements often skip focus styling entirely.

A visible focus state costs almost nothing to design well and costs a keyboard user everything when it is missing entirely. More on building interfaces that work for every input method in our Accessibility section, and more front-end craft in Front-End.