Focus State

A focus state is the visual cue that tells you which interactive element on a page currently has keyboard focus. Think of it as your cursor's spotlight, but for someone navigating with a keyboard or assistive technology. Without it, users are flying blind, unable to tell where they are or what they are about to activate. It is a non-negotiable requirement for WCAG 2.2, specifically Success Criterion 2.4.7 Focus Visible. This isn't some optional design flourish, a mere suggestion for "good" UX. It is a foundational pillar of web accessibility, ensuring that anyone who cannot use a mouse, or prefers not to, can still operate your interface effectively. Ignore it at your peril, both ethically and legally. It is the visual handshake between your interface and every keyboard user.

Do not confuse a focus state with a hover state. A hover state appears when a mouse cursor glides over an element, signaling potential interaction for pointer users. It is a transient visual hint. A focus state, by contrast, appears when an element receives keyboard input, often via the Tab key, or programmatically through JavaScript. It is a persistent indicator of the current interaction point. They are distinct interactions, serving different user groups and input methods. While their visual treatments might share some characteristics, their triggers and fundamental purpose are entirely separate.

Many designers mistakenly apply the same subtle visual treatment to both, or worse, remove the focus state entirely because it "looks clunky" or "interferes with the aesthetic." This is a critical accessibility failure, often driven by a lack of understanding or a misplaced priority on visual minimalism over functional usability. The argument that a default browser outline is "ugly" is not a valid excuse to disable a core accessibility feature. An active state, which indicates an element is currently being pressed or activated, is also a separate beast. Focus is about *potential* interaction, the "where am I now?" question, not current or completed action. Removing the focus state is like removing the steering wheel from a car because it obstructs the dashboard. It is a fundamental betrayal of user trust.

Consider the ubiquitous search bar on Google.com. When you tab into it, a distinct blue outline appears around the input field. That is its focus state. It clearly signals, "You are here, type now." This is a simple, effective, and expected interaction that has been a standard for decades. Similarly, on Amazon.com, every interactive element, from product links to "Add to Cart" buttons, receives a clear focus ring when navigated by keyboard. This ensures keyboard users can confidently browse, select, and purchase items without guesswork, a critical factor for a site processing billions in transactions annually.

Contrast this with many custom-built components on smaller sites, or even some larger ones, where developers often use `outline: none;` in CSS to remove the default browser focus ring. They do this for aesthetic reasons, usually because the browser's default dotted outline clashes with their sleek, custom design. This single line of CSS effectively breaks keyboard navigation for millions of users, including those with motor impairments, visual impairments, or simply those who prefer keyboard navigation for efficiency. Think of a complex government benefits application from 2020, where tabbing through dozens of fields gives no visual feedback. Users are left guessing which field is active, leading to immense frustration, errors, and potentially preventing access to vital services. This isn't just bad design; it's a barrier to entry.

System-level conventions also set expectations. Apple's macOS, for instance, uses a subtle blue glow around focused elements in its system UI, a consistent visual language users rely on for muscle memory and predictability. Microsoft Windows uses a dashed line or a solid border, depending on the control, a pattern established since Windows 95. These are not arbitrary design choices; they are fundamental cues that users internalize and depend on for navigating complex interfaces. Your web application should respect and build upon these established mental models, not discard them in pursuit of a fleeting aesthetic.

You must implement a distinct, high-contrast focus state for every interactive element on your page: buttons, links, form fields, checkboxes, radio buttons, custom controls, and any element that can receive keyboard input. There is no "when not to use" for interactive elements. The tradeoff is always between a "clean" visual design and fundamental usability for a significant portion of your audience. If your design team argues that the default browser outline is ugly, then design a better one that aligns with your brand. Do not simply remove it. Your design system should explicitly define focus states for all interactive components.

A well-designed focus state integrates seamlessly with your brand's visual language while meeting WCAG 2.2 contrast requirements for both the focused element itself and the focus indicator against its background. This means not just a subtle color change, which might fail contrast, but potentially a thicker border, a subtle shadow, a different background fill, or even a slight animation. It is an opportunity to extend your design system, defining a consistent and accessible interaction pattern across all your components. Prioritize clarity and discoverability over perceived visual clutter. Your users deserve to know where they are.

A missing focus state is not a design choice, it is a broken experience for half the internet.