Skip to content
UX Atlas
Plate FND·053 · UI foundationGrid D1 · Rev. 2026-08-14

Visual States

Every interactive element needs a defined appearance for every state it can be in, and most designs specify only two.

UI foundationCraft conventionFoundational

Definition

Visual states describe how a component looks in each condition: rest, hover, focus, active, selected, disabled, loading, error and read-only. Undefined states become implementation decisions, which is how inconsistency enters a product.

Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.

On this plate
  1. 1Definition
  2. 2The states to specify
  3. 3Combined states are where bugs live
  4. 4Specifying states so they are not invented later
  5. 5In practice
  6. 6Local chart
  7. 7Sources
  8. 8Continue from here

Reach for this when

  • Specifying any interactive component.
  • Reviewing keyboard accessibility.
  • Writing design system documentation.
  • Specifying a component for a design system, where the states will be implemented once and used everywhere.

Common mistakes

  • Removed focus indicators.
  • Hover as the only interactivity cue.
  • Undefined combined states.
  • Disabled styling that fails contrast and offers no explanation.
Save changesRestSave changesHoverSave changesFocusSave changesActiveSave changesDisabledSaving…Loading
A complete state matrix for a single component. Specifying it once in the design system removes the question from every future implementation.

The states to specify

StateTriggerNotes
RestDefaultMust already signal that the element is interactive.
HoverPointer overDoes not exist on touch. Never the only cue.
Focus visibleKeyboard focusMandatory. WCAG 2.4.7, with appearance requirements in 2.4.11.
Active or pressedDuring the pressBrief. Confirms the input was received.
SelectedPersistent choiceMust differ from hover and from focus.
DisabledUnavailableExplain why. Frequently fails contrast, so do not rely on it alone.
LoadingOperation in progressPrevent double submission and announce to assistive technology.
ErrorValidation failureNeeds text, not only colour.
Read-onlyViewable, not editableDifferent from disabled: content should still be selectable.

Combined states are where bugs live

  • Selected and disabled together.
  • Focused and in error together.
  • Hovered and loading together.
  • Selected and hovered, where the two treatments can cancel out.
  • Specify the precedence order explicitly, or each implementation will invent its own.

Specifying states so they are not invented later

Do

  • Specify default, hover, focus, active, disabled, loading, error and selected for every interactive component.
  • Define the combinations that can occur, such as focused and disabled, or selected and hovered.
  • Make focus visible against every surface the component can appear on.
  • Say what disabled means in words nearby, so it is not a dead end.

Do not

  • Remove the focus outline to tidy the design.
  • Use hover as the only way to reveal an action.
  • Let loading states borrow the disabled styling, so nobody can tell which is which.
  • Leave the empty and error states of a component to be discovered during build.

In practice

  1. i.

    Disabled buttons with no explanation

    Forms

    A disabled submit button tells the user nothing about what is missing. Either keep it enabled and show specific errors on submission, or state the blocking condition next to it.

  2. ii.

    Focused and disabled at once

    Where the bugs live

    A disabled button that can still receive focus, styled so that focus is invisible against the faded fill, leaves a keyboard user stranded with no indication of where they are. Combinations are where state specifications usually stop.

Local chart

FND·053 · Region II · Grid D1

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

ButtonCMP·001 · APPLIED THROUGHAffordances and SignifiersPRIN·007 · PRINCIPLES BEHIND THISConstraintsPRIN·009 · PRINCIPLES BEHIND THISFeedbackPRIN·004 · PRINCIPLES BEHIND THISProduct SpecificationTPL·011 · OFTEN USED WITHUser FlowTPL·005 · OFTEN USED WITHFigma Dev ModeTOOL·042 · OFTEN USED WITHStorybookTOOL·037 · OFTEN USED WITHAcceptance CriteriaTERM·095 · SHORT DEFINITIONDesign QATERM·113 · SHORT DEFINITIONHandoffTERM·112 · SHORT DEFINITIONMicrointeractionTERM·035 · SHORT DEFINITION

Sources

Where a source establishes something narrower than the popular reading of it, the note says so.

  1. [1]
  2. [2]

    :focus-visible

    MDN Web Docs

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applied through

Where this shows up as a concrete interface decision.

Principles behind this

The reasoning this solution is an application of.

Often used with

These usually appear in the same screen or the same decision.

Short definition

The one-paragraph version, for when that is all you need.

Related concept

Connected closely enough to change how you apply this.