dark App Logolight App Logo
Get started
Develop
Foundations
Styles
Components
Patterns
Resources
Contact

Disabled states

Disabled states remove the interactive function

Usage

A disabled state removes the interactive function of a component when the user is not allowed to interact with the component due to pre-requisites, dependencies or permissions.

It means that the user can’t interact with that part of the because:

  • It is unavailable for some reason
  • It is irrelevant or currently not applicable

Some possible reasons for using the disabled state can be:

  • While loading a process
  • Restricted access to an area
  • Upcoming or not yet available features
  • When one part of an action relies on another
  • Helping users avoid unintentional user actions for error prevention

The important thing is always provide feedback to the users:

  • What is happening or has just happened
  • What will happen next
  • Possible next steps and benefits

In many cases, disabled components should not be used, as the user will be frustrated about what went wrong and why he can’t proceed. A disabled element gives no feedback to the user. It is a dead end.

For these reasons, Atmosphere uses two types of options:

Type Description When to use
DisabledThe component ramains but it cannot be clicked, selected or interacted with.
  • When the element can change its state based on the user’s actions or time.
  • To promote discoverability
  • For read-only situations
HiddenThe component is completely hidden from view. The user does not know the option is there.
  • When the user is never going to use the option
  • To declutter, if it doesn’t cause spatial inconsistencies

Hidden vs disabled

To disable some icon buttons in a top app bar (1), one option is to hide the elements that are not relevant in the given context (2). This declutters the UI, and removing irrelevant options might help users focus, but this also might cause spatial inconsistencies if the position of the icons, size or density of the top app bar changes, and might be confusing to users if they expect them to be there, as it doesn’t promote discoverability.

The other option (3) is to disable the feature that is not applicable in the given context. This supports discoverability and learnability, and might teach and motivate users, building anticipation . However, a disabled state might be frustrating as there is no feedback on why the given option is non-interactive at the moment.

Hidden vs disabled

Types

1. Disabled

A default disabled state is used when a component is temporarily disabled due to dependencies or pre-requisites. This scenario is a temporary state change that is most commonly activated by a user’s action or inaction.

  • The default disabled component becomes an enabled state once the dependencies are resolved and/or the pre-requisites are achieved
  • The user should still be able to see the component in a temporarily disabled state
  • Always add explanations, warnings or guidelines to help users move toward their goals. In cases where a temporarily disabled item affects multiple items or the primary action of the flow. The notification should describe how the user can enable or re-enable the disabled component.
Disabled

Disabled rows in a data table

Temporally disabled button with time guidelines

Temporally disabled button with time guidelines

Disabled weekend days in a date picker calendar

Disabled weekend days in a date picker calendar

*Exception: In big forms with several required fields, the submit button or CTA will remain enabled by default even when all the fields are empty.

Exception - large forms

Disabled state inheritance

Components can inherit a disabled state, such as radio buttons, switches, checkboxes, text fields, data tables, list/menu items, cards, chips, buttons and icon buttons.

Disabled state inheritance

Disabled states cannot be inherited by: floating action buttons, side sheets, dialogs, menus, tooltips, and snackbars, or navigational components (such as app bars, tabs, etc.).

Style

Default disabled states are most commonly styled by a decrease in opacity in the neutral color palette. Apply the correct disabled state according to each individual component.

Color Token Light Mode Dark Mode
atmosphere.interactive.primary.textandicon.disabled
  • Base token: neutral.35
  • Hex value: #525254
  • Alpha: 0.38
  • Base token: neutral.90
  • Hex value: #E2E2E4
  • Alpha: 0.38
atmosphere.interactive.primary.background.disabled
  • Base token: neutral.35
  • Hex value: #525254
  • Alpha: 0.16
  • Base token: neutral.90
  • Hex value: #E2E2E4
  • Alpha: 0.16

Behavior

  • Disabled components won't display state changes to the component or cursor when hovered over.
  • Disabled components don’t change state when tapped.
  • There may be zero, one, or multiple disabled components in a composition.

Accessibility considerations

  • The disabled component states are exempt from current accessibility contrast requirements.
  • The keyboard accessibility will use disabled or aria-disabled attributes
  • The disabled state is not read by a screen reader

1. Hidden

The hidden disabled variation is used when something or someone does not have permission to view or interact with an element of the screen. This variation completely hides the component, page, action, etc. from the user’s interface. The only way to enable the hidden element and have it resurfaced is to change the assigned permission.

For example, when a user is an admin they are allowed to share content to the organization (1). Any other users that are not an admin would not be shown the “Share” option on the page/pane (2).

Hidden

*Exception

An exception might be when you want to promote a new feature or when it is necessary to show a specific action to users who do not have permission. In this case, the default disabled state can be used.

Exception