interaction design
Interactive states (hover, focus, active)
Why do hover, focus and active states matter?
Every interactive element has several states - default, hover, focus, active, disabled - and each gives feedback. They show users what’s interactive, where they are, and that the thing heard them. Designing only the default state leaves an interface that looks dead, loses keyboard users, and never confirms a tap.
Also known as: hover focus active, interactive states, button states, focus state
Prefer to watch?
Watch the recap 0:51
The demo
One button, many states. Hover it, tab to it with the keyboard, press and hold - and watch the label name the state each interaction puts it in.
State: default
Tip: press Tab to move focus here with the keyboard - note the focus ring.
What this demo shows (text version)
A sample button reports its current state as you interact: "default" at rest, "hover" when the pointer is over it, "focus" when you reach it with the keyboard (Tab), and "active" while it's being pressed. Below, a panel shows all the states side by side, including a disabled one.
Each state is feedback answering a silent question: is this interactive (hover), am I on it (focus), did my press land (active), can I use it yet (disabled). Hover works only with a mouse and never on touch, so it can't carry essential meaning; the focus indicator is essential for anyone navigating by keyboard, so it must never be removed for looks. Design every state, not just the resting one.
Hover, focus, active and disabled aren’t decoration - each is feedback: hover says 'this reacts', focus says 'you’re here' (the one keyboard users depend on, so never remove the outline without replacing it), active confirms the press, disabled signals 'not yet'. Hover doesn’t exist on touch, so it can never be the only cue. Design every state, not just the resting one.
Resting, the control just sat there. Hover lifted it - "this reacts". Tab to it and a clear focus ring said "you're here now". Press and it pushed back, confirming the hit. Each state was a tiny answer to a question you were silently asking - and a button with only its default state answers none of them.
Each state carries distinct information. Hover hints "this is interactive" (mouse only). Focus shows where keyboard or assistive-tech users currently are - which is why a visible focus indicator is non-negotiable: strip the outline and you don't tidy the design, you blind everyone not using a mouse. Active confirms the press landed; disabled says "not available yet, and here's why".
The classic mistakes are removing focus styles for looks, and relying on hover for anything essential. Hover doesn't exist on touchscreens and is invisible to keyboard users, so a meaning that only appears on hover is a meaning many people never get. Use :focus-visible to give keyboard users a clear ring without splashing it on every mouse click.
Disabled states need special care. A greyed-out control should look unmistakably inactive and, ideally, hint at how to enable it - a disabled button with no explanation is a dead end. And keep contrast adequate even when muted: "disabled" must not mean "invisible to anyone with low vision".
Active states confirm user actions and are essential for accessibility - try the demo to see how active states work in real time. Designing only default states leaves interfaces dead and unresponsive to keyboard users; active states make interactions feel alive and intentional.
Active states like hover, focus, and active confirm user actions and make interfaces usable for everyone - try the demo to see them work in real time. Designing only the default state leaves interfaces silent - active states give feedback, reassure keyboard users, and prevent confusion.
Active states confirm user actions and make interfaces accessible - try our demo to see how each state guides interaction. Designing only default states leaves interfaces inert; active states are essential feedback for keyboard users and touch devices.
Hover, focus, and active states aren’t optional - they’re feedback that tells users what’s interactive and where they are. Try the interactive demo to see how each state responds to input. Designing only the default state leaves interfaces cold and inaccessible; hover doesn’t work on touch, so never rely on it alone.
Hover states show users what’s interactive, but they’re not enough on touch devices - design focus, active, and disabled states too. You can test hover states and all other interactive states in the live demo on this page - no screenshots, no external tools, just real interaction.