What Is a Focus State?
A focus state is the visible indicator showing which element currently has keyboard focus, most often a ring or outline around a link, button, or form field. As a user moves through a page with the Tab key, the focus state marks where they are, so they can see what they are about to activate. It is essential for anyone navigating without a mouse, including keyboard-only and assistive-technology users. Removing the focus outline for looks makes a site unusable for these visitors and breaks accessibility guidelines.
- What it is
- The visible marker showing which element has keyboard focus right now
- Who relies on it
- Keyboard-only users, switch users, and many assistive-technology users
- CSS mechanism
- Styled with the :focus and :focus-visible pseudo-classes (MDN Web Docs)
- Requirement
- A visible focus indicator is required by WCAG 2.2 Success Criterion 2.4.7 (WCAG 2.2)
- Common mistake
- Setting outline:none for aesthetics, which strips the indicator and breaks accessibility
What a focus state actually is #
A focus state is the visible sign that a particular element is currently focused, meaning it is the element the keyboard will act on next. When a user presses Tab to move through a page, focus jumps from one interactive element to the next, links, buttons, form fields, and the focus state, typically an outline or ring, shows exactly where they have landed. Without it, a keyboard user is effectively navigating blind, pressing keys with no idea which control they are on or what pressing Enter will do. The focus state is therefore not decoration; it is the keyboard equivalent of a mouse cursor, the single cue that makes non-mouse navigation possible. Browsers provide a default focus outline for this reason, and it exists to keep the web usable for everyone. Ensuring that indicator stays clear and visible is a foundational part of the accessibility work covered on our /services/ada-compliance page, where keyboard operability is treated as a baseline, not an extra.
Who depends on focus states #
Focus states matter most to people who do not or cannot use a mouse, and that is a larger group than many site owners assume. Keyboard-only users include people with motor disabilities who find a mouse difficult, people using switch devices or other adaptive hardware, and plenty of power users who simply navigate faster with the Tab key. Many screen-reader users also rely on visible focus to coordinate what they hear with where they are, and people with low vision or cognitive differences use it to keep their place on a busy page. For all of them, the focus indicator is the thread that keeps navigation coherent. Remove it and the page becomes a maze with no you-are-here marker. Because accessible keyboard navigation is both a legal expectation and a basic courtesy, designing it in from the start is central to every build our team delivers on our /services/web-design page, not a fix bolted on afterward.
Why removing the focus outline breaks accessibility #
One of the most common and damaging mistakes in web design is deleting the focus outline because a designer thinks the browser's default ring looks untidy. A single line of CSS, outline: none, wipes out the only cue keyboard users have, and suddenly they cannot tell which element is focused as they tab through the page. The site may look cleaner to a mouse user who never sees the outline, but for keyboard and switch users it is now unusable. This is not a minor style preference; a visible focus indicator is explicitly required by WCAG 2.2 Success Criterion 2.4.7, so removing it fails a recognized accessibility standard and can carry legal risk under laws like the ADA (WCAG 2.2). The correct response is never to remove the outline, but to restyle it into something that fits your brand while remaining clearly visible. That balance of aesthetics and compliance is exactly what our /services/ada-compliance page addresses.
Styling focus states in CSS #
Instead of removing focus outlines, style them. The modern approach uses :focus-visible, which shows a focus ring for keyboard users but suppresses it for mouse clicks, giving you clean visuals without sacrificing accessibility. Here is a practical example.
/* Never do this alone: */
/* button:focus { outline: none; } <-- breaks accessibility */
/* Do this instead: a clear, on-brand focus ring */
.btn:focus-visible,
a:focus-visible,
input:focus-visible {
outline: 3px solid #1a56db;
outline-offset: 2px;
border-radius: 4px;
}
/* Ensure the ring is visible on dark backgrounds too */
.btn-dark:focus-visible {
outline-color: #ffffff;
}Focus states versus hover states #
Focus and hover are related but serve different input methods, and confusing them causes real accessibility gaps. A hover state responds to a mouse pointer moving over an element, while a focus state responds to keyboard navigation landing on it. Because keyboard users never hover, any feedback attached only to :hover is invisible to them; likewise, a focus state serves people who cannot use a pointer at all. The mistake many sites make is styling a rich hover effect but leaving focus unstyled or, worse, removed, so mouse users get polished feedback and keyboard users get nothing. The rule is simple: every interactive element should have both a hover state and a matching, clearly visible focus state, so the interface responds equally whether someone uses a mouse or a keyboard. Building that parity into components from the start is part of the interface discipline our team applies on our /services/ui-ux-design page, where no group of users is left without feedback.
Making focus indicators visible enough #
A focus state only helps if people can actually see it, and WCAG 2.2 tightened expectations here. The indicator needs sufficient contrast against both the element and its background, and it should be large enough not to be missed, guidance reflected in the newer Focus Appearance criterion. A thin, pale outline that blends into the page is nearly as bad as no outline at all. Give the ring a solid width, use an offset so it does not crowd the element's edge, and choose a colour that stands out on every background it may appear over, including dark sections where a dark outline would vanish. Test by tabbing through the entire page and confirming you can always spot where focus is. Do not rely on a faint colour change alone. Getting these visibility details right is exactly the kind of hands-on accessibility work our team performs, and it is central to the audits offered on our /services/ada-compliance page.
Common focus-state mistakes #
The single most common mistake is removing the focus outline with outline: none and never replacing it, leaving keyboard users stranded. A close relative is styling focus so faintly that it is effectively invisible. Others include applying a focus style to hover but not to actual focus, or building custom widgets, dropdowns, modals, tab panels, that trap or lose focus so the indicator disappears entirely. Some sites manage focus poorly when content changes, so after opening a dialog the focus stays on the hidden page behind it. Skipping the :focus-visible approach and showing focus rings on every mouse click can also push designers to strip outlines out of frustration, when the right tool would have solved it cleanly. Each of these breaks keyboard navigation in ways a mouse-using tester never notices. Catching them requires tabbing through the whole site, which is part of the practical accessibility review you can start free at /free-website-audit.
Focus order and managing focus #
A visible focus indicator is only half the job; the order in which focus moves also has to make sense. As a user presses Tab, focus should travel through interactive elements in a logical sequence that matches the visual layout, usually top to bottom and left to right, so navigation feels predictable. Problems arise when the document order does not match the visual order, or when CSS repositions elements so the tab sequence jumps around unexpectedly, leaving keyboard users disoriented. Custom components add another layer: when a modal dialog opens, focus should move into it and stay trapped there until it closes, then return to the element that triggered it, so keyboard users are never stranded on hidden content behind the overlay. Skip links that jump straight to the main content also help people bypass repetitive navigation. Managing focus order and movement correctly is what makes keyboard navigation genuinely usable rather than merely visible, and it is a core part of the accessibility engineering covered on our /services/ada-compliance page.
Best practices and our recommendation #
Never remove the focus outline for the sake of appearance. Instead, design a focus state that fits your brand and is unmistakably visible: a solid ring with good contrast, a sensible offset, and colours that hold up on light and dark backgrounds alike. Use :focus-visible so keyboard users see the ring while mouse users are not distracted by it on click. Make sure every interactive element, links, buttons, inputs, and custom components, has both a hover state and a matching focus state, and manage focus correctly when dialogs open and close so the indicator never gets lost. Test the entire site with the keyboard alone, tabbing from top to bottom, to confirm you can always see where focus is. Meeting WCAG 2.2 here is not just about compliance; it is what makes your site usable for real people who navigate without a mouse. Our /services/ada-compliance and /services/web-design teams build this in from the first line of CSS.
FAQ
What is a focus state in web design?
A focus state is the visible indicator, usually an outline or ring, showing which element currently has keyboard focus. As users press Tab to move through a page, the focus state marks where they are, so they can see which link, button, or field they are about to activate. It is essential for keyboard navigation.
Why should I never remove the focus outline?
Removing the focus outline with outline: none strips away the only cue keyboard users have for where they are on a page, making the site unusable for them. It also fails WCAG 2.2, a recognized accessibility standard, and can create legal risk. Restyle the outline to fit your brand instead of deleting it.
What is the difference between :focus and :focus-visible?
The :focus pseudo-class matches any focused element, including after a mouse click, which can show rings where they are not needed. The :focus-visible pseudo-class shows the focus indicator mainly for keyboard navigation and suppresses it for mouse clicks, giving clean visuals for mouse users while preserving clear feedback for keyboard users.
Do focus states matter for SEO or just accessibility?
Focus states are primarily an accessibility feature, ensuring keyboard and assistive-technology users can navigate. While they are not a direct ranking factor, accessible, well-built sites tend to align with the usability signals search engines value, and meeting standards like WCAG 2.2 reduces legal risk under laws such as the ADA.
How visible does a focus indicator need to be?
It needs enough contrast against the element and background to be easily spotted, and enough size not to be missed, in line with WCAG 2.2 guidance. A thin, pale outline that blends in is nearly as bad as none. Use a solid width, an offset, and colours that work on every background.
Who benefits from visible focus states?
Anyone navigating without a mouse benefits, including keyboard-only users, people using switch devices or adaptive hardware, many screen-reader users, and people with low vision or cognitive differences who need to keep their place. Plenty of power users also tab through pages quickly, so visible focus helps a broad range of real visitors.
How Local Web Advisor checks this for you
Is your own website getting accessibility right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for accessibility and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?