UI component states: the checklist every interactive element needs
Every interactive component needs more than its resting look. At minimum: default, hover, keyboard focus, pressed and disabled, and for many components also loading, selected, error and visited. Design them together as a set, with one rule for what each state changes, so a visitor learns the pattern once and recognises it on every button, link and field.
Why states get missed
Mock-ups show components at rest. Hover is usually added during build, focus often never, and disabled or loading states appear only when a developer meets the case and improvises. The result is a site where one button darkens on hover, another fades, a third does nothing, and keyboard users can't see where they are. Designing states as a deliberate set, at the same time as the resting style, prevents that.
The interactive states checklist
| State | What it tells the visitor | Applies to |
|---|---|---|
| Default | This can be used | Everything interactive |
| Hover | The pointer is over something you can use | Buttons, links, cards that link, rows |
| Focus | This is where the keyboard is | Everything that can receive focus |
| Active (pressed) | Your press registered | Buttons, links, toggles |
| Disabled | This exists but can't be used yet | Buttons, fields, options |
| Loading | Your action is being processed | Buttons that send, fetch or save |
| Selected or current | This is the chosen option or the page you're on | Tabs, navigation, time slots, filters |
| Error | This needs fixing | Fields, groups of options |
| Visited | You've been here | Text links in long content |
Designing hover, focus, active and disabled as a set
Pick one change per state and apply it everywhere. A workable set for a site with one action colour:
- Hover: a clear change of fill or underline. A filled button gets a slightly darker or lighter fill; a text link gains or thickens its underline; a card's title takes the action colour. Avoid fading to lower opacity, which reads as disabled.
- Focus: a solid outline, offset from the element by two or three pixels, in a colour with at least 3:1 contrast against the background. Use
:focus-visibleso it shows for keyboard users and not on every mouse click; MDN's focus-visible reference explains the browser's heuristics. Never remove focus without replacing it. - Active: a brief, small response, such as a slight press inwards or a darker fill, so the press feels physical.
- Disabled: lower contrast and no pointer change, but still readable. Better still, explain why something is unavailable, or leave the button enabled and say what's missing when it's pressed.
- Loading: keep the button's width, swap the label for a short phrase such as "Sending", and prevent a second press.
Hover and focus should look different. If they're identical, a keyboard user who also moves the mouse can't tell which element will respond to Enter. Focus state design and hover effects for websites go deeper on each.
Accessibility rules for states
- Focus must be visible. WCAG's Focus Visible criterion, at level AA, requires a mode where keyboard focus can be seen.
- State changes need contrast. WCAG's Non-text Contrast asks for 3:1 for the visual cues that show a component's state, such as selected or focused. Hover itself doesn't need to reach 3:1, but it mustn't reduce contrast below what the component needs.
- Not colour alone. A selected tab that differs only by hue fails people who can't see that hue. Add weight, an underline, a fill or a check mark.
- Expose state in code.
aria-current="page"for the current page,aria-pressedfor toggle buttons,aria-invalidfor fields in error, the nativedisabledattribute for unavailable controls. - Touch has no hover. Anything revealed on hover needs another route on phones and tablets.
Motion between states
Short transitions make state changes easier to follow, as long as they're quick: around 100 to 200 milliseconds for colour and fill. Use a purposeful curve rather than the browser's default ease, and turn transitions off for visitors who ask their device for reduced motion. UI animation duration gives fuller timings.
Component states in Anticode
Anticode's design systems define focus and hover states as part of each system. Every page shows a visible keyboard focus ring in the action colour, offset from the element, and since 23 October 2026 the design gate blocks publishing any page that has no focus styles at all. Booking time slots have a distinct selected state and their own focus ring.
The Critic checks two common state habits on every build: hover states that do nothing but fade the opacity, and cards that all lift upwards on hover. It also flags transitions that use the default ease curve, and every design system turns animation and transitions off under reduced-motion settings.
Questions people ask
What states does a button need?
Default, hover, focus, pressed and disabled at minimum, and a loading state if pressing it sends or saves something.
What's the difference between focus and focus-visible?
:focus matches any focused element; :focus-visible matches only when the browser judges a visible indicator is needed, such as during keyboard navigation.
Should disabled buttons be greyed out?
They're usually shown with lower contrast, but keep the label readable and, where possible, explain what's needed to enable the action.