Every component needs a complete interactive state set

What it is

Any component a pointer, keyboard, or assistive technology can hit needs a closed interactive state set: default, hover, focus, active, disabled, selected — the subset that applies to that control, with none of those applicable cells empty. The set is a contract with input channels, not a polish checklist.

It answers how the control looks and whether it can act while the user is operating it. It does not cover content states such as data still loading, a list that is empty, or a request that failed.

Why it happens

Each input channel asks the component for a state. The pointer entering asks for hover; Tab stopping on it asks for focus; the click instant asks for active; the platform or the business turning it off asks for disabled. If design does not answer, the channel still asks: the browser paints its own focus ring, the OS greys disabled, mobile highlights press in an unknown way. Those fallbacks disagree with each other and with the rest of the product.

Closed means every applicable ask has a product-owned answer. Links have no selected, checkboxes have no sticky pressed; the subset may be shorter than a button’s, but focus cannot be deleted from it — keyboard users remain. An empty cell is not “draw later.” It hands the decision to the user agent.

Where it stops holding

Purely presentational pieces with no focus and no hit target (dividers, static badges) have no interactive set; inventing hover lies about affordance. Surfaces that are touch-only may drop hover, but focus and active stay — an external keyboard and switch control will still focus. Read-only is not disabled: read-only remains focusable and selectable; applying disabled locks the content. A custom control built from a generic container must expose the set to assistive technology, not only restyle the pixels.

Applying it

• List applicable interactive states per control type as that component’s table. Mark any empty cell as a gap; do not paper over focus and disabled with “same as default.”
• Place a frame for every cell in the design file and in code examples. The focus frame must show a ring or equivalent; do not smuggle it inside hover.
• Walk the component with keyboard and a screen reader: every interactive piece focuses, disabled cannot activate, selected is announced as selected.
• How to check: put the mouse away and light every applicable state with Tab and Space. A cell that looks like the browser default, or that gives no feedback, means the set is still open.

Related

• Same group: R1.03.2 Loading, empty, and error are the states most often left unspecified · R1.03.3 Missing states get improvised during implementation · R1.03.4 Transitions between states fail more often than the states themselves · R1.03.5 Overlapping states need an explicit priority rule · R1.03.6 States must be controllable and observable from outside the component
• Nearby: R3.09 Semantic structure and accessibility implementation · R2.03 Consistency checklists
• Search terms: interactive state set · focus visible · disabled state