Design Systems
Accessibility
Focus is not a state: A better way to model accessibility in design systems
Jan 5, 2026
Where the problem first appeared
I encountered this problem while working on an enterprise-scale Figma design system, specifically while defining component architecture. At the time, we were modeling selected and focus as states. That decision felt reasonable and aligned with how most systems work.
For a while, it held up.
"State: Focus" works, until it doesn't
The cracks appeared once we moved beyond simple components.
Certain components relied on visual affordances like strokes, outlines, or borders to indicate selection. Focus relied on similar treatments. When both needed to exist at the same time, the model broke down.
This came up most often in controls (swatches, selectors, buttons), selectable cards, and other selection-based components. The system had no clear way to represent what should happen when an element was both selected and focused since our model treated focus as any other state.
The insight: Focus is not a state
This led to the core realization:
Focus is a fundamentally additive layer, rather than a mutually exclusive state.
It can exist alongside selected, pressed, or active states without replacing them. This is how browsers behave, how assistive technologies work, and how developers already understand the distinction.
A better model: Focus as a boolean
Once focus is understood as additive, the modeling problem becomes much simpler.
Instead of treating focus as a mutually exclusive variant, it works better as a conditional boolean. The component has its respective state, whether that is default, selected, or pressed, and focus is turned on (or layered on top) when relevant.
This mirrors how focus works in browsers and clarifies how focus behaves across states. It also avoids forcing designers to invent artificial state combinations like “selected + focus” and reduces unnecessary variants.
Most importantly, it aligns the design system with reality rather than fighting it.
The hidden costs of treating focus as a state
At first, the issue looked like a documentation gap. We weren’t showing selected + focus combinations, even though they mattered for accessibility and development.
But the deeper problem was conceptual.
When focus is treated as a mutually exclusive state, it stops being something designers reason about in combination with other states. The system implies that focus replaces what came before, rather than layering on top of it.
As a result, focus is often designed in isolation. Its interaction with selected, pressed, or active states is left unspecified, even when those combinations are likely to occur in real use.
This creates gaps in documentation, forces developers to infer behavior, and increases the risk of accessibility issues making it into production. Variant count may increase as a side effect, but the more serious cost is that the system fails to model how focus actually works.
The objection: "Focus and hover do not coexist"
When I raised this with my team, the main pushback centered on focus and hover.
The argument was reasonable: hover implies mouse input, focus usually implies keyboard input. In real interfaces, one tends to replace the other. Why model them together?
The answer is that focus and hover serve a similar purpose. They both indicate that a user is interacting with an actionable element. They are triggered differently and styled differently, but functionally they belong to the same category.
Because of that, their coexistence is not something a design system needs to represent.
TL; DR
Focus is an additive accessibility layer, not a mutually exclusive state
Focus should not be modeled as a state variant
Focus works best as a conditional layer boolean
This represents state and focus combinations, avoids artificial state variants, reduces variant count, and reflects how focus truly works in browsers and assistive tech