Style interaction states

Variants prefix a utility:

<button class="bg-blue-600 hover:bg-blue-700 focus-visible:outline-2 active:translate-y-px disabled:opacity-50">Save</button>

Each prefix adds a condition to the generated CSS. The base background is always present, hover: responds when hover is available and active, focus-visible: exposes keyboard-like focus, active: covers activation, and disabled: matches a disabled control.

The HTML state must be real:

<button disabled class="disabled:cursor-not-allowed disabled:opacity-50">
  Saving…
</button>

Styling something to look disabled does not prevent clicks or communicate the state to assistive technology. Likewise, a <div> with hover styles does not become a button; use the native interactive element first.

Hover is an enhancement. Touch users may never hover, and some devices emulate hover in surprising ways. Essential instructions and actions must remain visible or available through focus and activation.

Use focus-visible for a clear keyboard indicator without necessarily showing it after every pointer click. Never remove focus just because the hover style looks cleaner. Test the outline against every background and at high zoom.

State combinations matter. A disabled button should not appear to lift on hover. A pressed button may need aria-pressed and an aria-pressed: variant so the visual state follows the accessibility state rather than separate JavaScript styling.

Keep transitions short and optional. A state must be understandable even when animation is disabled.

Your action is to build a button with default, hover, focus-visible, active, disabled, and pressed states. Test with keyboard, mouse, and touch emulation, then verify DOM attributes and visual classes never disagree.