Interaction States

Make the interactive components’ behavior predictable and explicit.

Interaction states



FYQ2 target


Related content

Our principles in practice

Our identity principles guide how we define our foundations to create a better experience for everyone. Here’s how they apply to interaction states:

  1. Coherent: They follow universal patterns that are applied consistently to all interactive elements. Multiple states can co-exist within the same interactive component. For example, an element can be selected and hovered simultaneously.
  2. Empowering: Their goal is to help people progress throughout the experience.
  3. Clear: The transition between states is explicit but kind and elegant. We achieve it by applying gradual changes that enable visual continuity.
  4. Inclusive: All our states pass the following WCAG 2.1 standards.



Interaction states combine signifiers and signifieds (people’s mental models). Signifiers are tangible elements like color or graphics that are essential to creating meaningful results:

Color shades

Color shades

Interaction states shift gradually on the raw color scale while triggered. This shift helps users to understand the state change and reinforce the action.

Graphic elements

Graphic elements

Interaction states combine meaningful graphic elements such as shapes or iconography.

Related content

Elevation effects

We combine a series of shadow effects that provide depth to our interactive elements, highlighting them above the rest of the interface in an elegant way.

These effects are available in Figma and code for quick and easy application and holistic iteration through design tokens.

Related content


Combining signifiers defines the interaction state output. See the examples below:



The starting point of an interactive component



Is one step darker than the default state on the raw scale



Is one step darker than the hover scale on the raw scale



Wraps the component within a focus ring



Uses graphic elements to reinforce the action



Maintains the Pressed emphasis level and uses iconography to reinforce the intended usage



Uses a combination of low-emphasis colors that indicate the non-interactive state


To create rich states that cover the whole interaction spectrum, we need to understand their different types first:

  1. Resting state
  2. User-triggered states
  3. State properties

Resting state

Represents the visual appearance of an element in its resting state or after being deselected.

Resting - example

User-triggered states

They require a user action, such as holding a mouse pointer over the interactive element target area.


Represents any element a user interacts with (for example, with a pointing device) but not yet activated. It's usually triggered when a user hovers the cursor (mouse pointer) over the element.

Hovered - example


Represents any focused element. It’s usually triggered when a user selects it with the Tab key.

Focused - example


Represents any active element while pressed. It’s usually triggered when a user hits the interactive target area.

Pressed - example


Represents any element that is being pressed and moved simultaneously.

Dragged  - example

State properties

The state of a component can depend on properties set before the user can interact with it. Similarly, their attributes can change before and after the user interaction. Thus, we should be able to combine these state properties with user-triggered states, for example, in an invalid form or a selected navigation item, as they can also be hovered or focused.


Represents any element with invalid content.

Error - example


Represents any element that is loading or retrieving data. It’s usually triggered by hitting a button or landing on a new screen whose contents are not yet loaded.

Waiting - example


Represents any disabled element. An element is disabled if it can't be activated (selected, clicked on, typed into, etc.) or accept focus.

Disabled - example


Represents an element that holds content but can’t be editable by a user. It can’t be focused or activated (selected, clicked on, typed into, etc.).

Read only - example


Represents elements such as navigation items or toggles that can be preselected by default or toggled by a user.

Selected - example


Represents any radio, checkbox, or option element that is being checked or toggled.

Checked - example


Represents any form element whose state is indeterminate, such as checkboxes and radio buttons that are members of a group in which all radio buttons are unchecked.

Indeterminate - example

Quality checklist

This element passes the following requirements described in our Component lifecycle.



α · Design tokens

It uses Ariane design tokens.

α · Accessible use of color

Its color contrast ratio is at least 4.5:1 for text and interactive areas.

α · Target areas

Its interactive target areas are large enough for users to accurately select them, following the Fitts law.

α · Naming agreement

Its name is agreed upon and shared between design and development.

α · User-triggered states

If the component is interactive, all its possible user-triggered interactive states are defined.

β · Docs L1

It has essential documentation with at least primary usage.

β · Use cases

All the uses are audited and refined.

RC · Definition agreement

Its naming and properties are audited and aligned in design and code.

RC · Accessible L1

Its accessibility is manually audited, and any significant issues are fixed.

RC · Docs L2

The documentation covers the most common use cases and is expected to be iterated during the Release Candidate phase.

Accessibility details

This element passes the following WCAG 2.1 standards.



Success criterion




1.4.1 Use of Color

Color is not the sole method of conveying information or distinguishing visual elements



1.4.1 Use of Color

Link color contrast is at least 3:1 and has an additional non-color effect when hovered or in focus