The visual indicator that shows which interactive element currently has keyboard focus, enabling users who navigate without a mouse to track their position on the page. Visible focus states are a fundamental accessibility requirement, not a cosmetic detail — removing them makes keyboard navigation effectively unusable.
Common contexts
- Designing a custom component library and ensuring every interactive element has a styled focus state that replaces the browser default
- Auditing a form flow to confirm that tab order matches visual reading order and focus is always visible
- Reviewing a design handoff where a developer has suppressed the default outline without providing a custom replacement
Use when
On every interactive element in every interface — no exceptions. Custom focus states should be designed as part of the component spec, not retrofitted after accessibility audits flag their absence.
Avoid when
There is no legitimate design context in which removing visible focus states entirely is acceptable — suppressing them with 'outline: none' without a replacement is a WCAG 2.4.7 failure that excludes keyboard-only users completely.
Focus states are removed far more often by designers who find them 'ugly' than by developers who don't know they're needed — own the visual design of your focus states before someone else removes them for aesthetic reasons.
Real-world examples
- GOV.UK's design system uses a high-contrast yellow focus indicator that meets WCAG accessibility standards and has become a widely cited example of prioritizing keyboard navigation usability.
- Firefox has a strong default focus ring that respects user accessibility settings, making it easier for keyboard-only users to track their position when tabbing through interactive elements.
- Microsoft's Fluent Design System defines explicit focus states for all interactive components, ensuring Windows and Office products remain fully navigable for users who rely on keyboards or assistive technology.