# Disabled states

| **Platform** | **Status** |
| :----------- | :--------- |
| Web Mobile   | Ready      |

This pattern involves how we disable, show, or hide actions based on different
criteria. It becomes a balance in explaining the interface and not overwhelming
users with choice. Below are a few of the common examples and accompanying
guidelines for handling those situations.

## Goal

Avoid placing the user in a frustrating state where actions are unavailable and
they do not know how to enable.

## Use when…

There's absolutely no other way to avoid a disabled state. This should be a last
resort. This flowchart can help you find alternatives:

## Solution

### Avoid disabled states

Your first goal should be to avoid disabled states entirely. If there is a
condition required for the user to take an action, present the opportunity to
set the required condition before the user is blocked by a disabled state. An
example of this is on our “work objects” which all require a client to be saved.
If the user makes it to the bottom of the form and has not added a client, the
primary CTA is “Select Client“.

#### Permissions-related unavailability

When functionality or a feature isn't available because of a user's permissions,
hide the action altogether.

#### Account-tier-related unavailability

If functionality is unavailable because of a user’s subscription tier, but we
want to introduce the functionality to encourage them to upgrade, use an inline
element near where the unavailable UI would exist, or a
`Button variation="learning"` in place of the UI to nudge the user to learn
more.

### Why

Avoiding disabled states is an accessibility best practice and also generally
helpful from a usability perspective. The more time a user spends trying to
understand why they can’t take an action, the less time they spend getting sh\*t
done.

Disabling elements is often the easiest path for a development team to manage
conditional states of an interface to design and build, but results in a
less-friendly interface for the user.

### Implementation

While you should avoid disabled states, many Atlantis components do offer a
`disabled` boolean property for absolutely necessary cases. If you use the
disabled state, you must ensure that the user can understand *why* the element
is disabled.

### Web

A [Tooltip](../Tooltip/Tooltip.md) may help explain to the user why they
can’t select an element. Make sure the Tooltip can be triggered both by
focus and hover.

### Mobile

[Text](../Text/Text.md) (level="supportingText") is more helpful for users
in the mobile app as it does not require an additional interaction to
uncover. If an input element (such as a Select or InputText) has “assistive
text” built in, do not use the assistive text in a disabled state, but
provide the supporting Text as a separate element.

## Related

* [Interaction](../interaction/interaction.md)
* [Empty states](../empty-states/empty-states.md)

## Principles

* [Visibility of system status](https://www.nngroup.com/articles/visibility-system-status/)
* [Recognition over recall](https://www.nngroup.com/articles/recognition-and-recall/)