One of the first things I check when evaluating a site’s accessibility is whether it has visible focus states. You’d be surprised how many don’t. Designers often remove the browser’s default outline without replacing it with anything usable. The result is a completely disorienting experience for anyone who navigates by keyboard or assistive technology.
Let’s talk about why visible focus indicators are so important, who they help, how to implement them well, and how to test whether yours are working.
What is focus state, and why does it matter?
When you navigate a website using the keyboard, one element at a time receives focus. This means it’s ready for interaction, like typing into a field, activating a button, or following a link with the Enter key. A visible focus indicator shows which element is currently active.
Without this indicator, keyboard users are flying blind.
Focus state is especially important for:
-
Keyboard-only users who can’t or don’t use a mouse
-
People using assistive tech like screen readers or voice navigation
-
People with motor impairments who rely on switches or other input devices
-
Power users who prefer keyboard navigation to speed up their workflow
The Web Content Accessibility Guidelines (WCAG) recognize how essential this is. Success Criterion 2.4.7: Focus Visible stipulates that any keyboard-operable interface must have a visible indication of focus.
Which elements receive keyboard focus?
By default, native HTML interactive elements are focusable. This includes:
-
<a>links (with anhref) -
<button>elements -
<input>,<select>, and<textarea>form fields -
<details>and<summary>
Custom components can also receive focus if you use tabindex="0", but it’s always better to use semantic HTML when possible.
If you’re building something interactive and it doesn’t receive keyboard focus, that’s a problem. If it does receive focus but gives no visual indication, that’s also a problem. Both violate WCAG 2.4.7.
Aparna Pasi from Deque Systems puts it well:
"A rule of thumb…if you can interact with an element with the mouse, you should also be able to use the keyboard to perform the same actions. And if you’re using a keyboard, anything you interact with should have visible focus."
What makes a good focus indicator?
The browser’s default outline might not win any design awards, but at least it does the job. If you decide to override it, make sure your custom styles are just as effective or better.
A good focus indicator is:
-
Clearly visible (meets at least a 3:1 contrast ratio)
-
Unmistakable (not a faint 1px dotted outline)
-
Consistent across the site — you might need multiple focus indicator styles to account for different contexts (i.e. dark mode)
-
Not easily confused with hover-only effects
Deque recommends a 2px solid outline offset from the element, in a highly visible color. You might use something like this:
*:focus {
outline: 2px solid #f90; /* bright orange */
outline-offset: 3px;
}
You can get creative here. Some websites use glowing shadows, thick underlines, or background fills. Just make sure the result is obvious and not hidden under other elements. Also, avoid using color alone to indicate focus state as users with colorblindness may not be able to differentiate it.
Focus vs. hover: keep it consistent
A nice design touch is to align your focus styles with your hover styles. If hovering over a button turns it blue with an outline, consider making that same change when the button is focused. This helps create a unified experience across input methods.
Just be careful: color changes alone can exclude users with colorblindness and may not meet contrast requirements. Combine them with outlines or underlines.
Use :focus instead of :focus-visible
Here’s a common misstep: some developers only style :focus-visible and ignore :focus.
On the surface, :focus-visible seems like a good idea. It applies focus styles only when the browser thinks the user is navigating with a keyboard. But the keyword there is "thinks." That logic varies across browsers, and it can suppress focus indicators for mouse users. In addition, older browser versions don’t support :focus-visible.
As Easy A11y Guide points out, :focus is the more reliable option. It always applies, regardless of how the element was focused. That’s what you want. Sighted users who tap or click into a form field still benefit from a visible indicator. So do people using voice control or other assistive tech that do not easily simulate pressing the Tab key.
My advice is to use :focus for your default styles. If you want to layer on enhancements for keyboard-only users, you can add :focus-visible as a bonus—but don’t rely on it alone.
How to test focus state
Want to know how your site is doing? Put your mouse aside and press Tab.
Here’s a simple checklist:
-
Tab through the page: Can you reach every interactive element? (Links, buttons, menus, forms?)
-
Watch for the indicator: Does something change when you land on each element? Can you always tell where you are?
-
Check the contrast: Is the focus indicator easy to see against the background?
-
Mind the order: Does the focus move in a logical, visual sequence? Top to bottom, left to right (for Western languages)?
-
Check popups/modals: If a modal opens, does focus move into it? Does it stay there until closed?
-
No keyboard traps: Can you always
Tabforward andShift+Tabbackward through everything?
You can also test using browser dev tools or accessibility inspection tools to follow the focus outline and check styles.
Final Thought
Focus indicators are one of the most vital pieces of accessible design. Don’t make your users guess where they are. Let them see it.
