Hidden vs disabled states

when should you use hidden/disabled states?

Oct 25, 2021

A disabled state is applied to a component when the user is not allowed to interact with it due to either permissions, dependencies, or pre-requisites. When a control is disabled, it usually appears as slightly transparent or lower contrast than the default state, and it stops receiving input (read-only state). When a control is hidden, it is no longer in the interface. In both cases, disabled states completely remove the interactive function of a component.

Disabled state

Advantages of showing the button in a disabled state:

Discoverability: many users learn to use an application by exploring and reading labels. By including disabled elements we show users what an application is capable of even when the button requires further action to enable.
Learnability: the user can learn where controls and buttons live within the user interface.

Enable and Disabled state buttons from Material Design

Disadvantages of showing the button in a disabled state:

Increases cognitive load: Including disabled buttons gives users extra to think about. Seeing a disabled button will make users wonder why it is not available and how to enable it. According to Steve Krug’s “Don’t make me think” we should remove elements that make the user think.
It appears clickable to some users: If not implemented correctly disabled buttons can confuse users. For example, some users can mistake greyed-out buttons for secondary actions.
Accessibility: They’re hard to see — the Web Content Accessibility Guidelines (WCAG) do not require sufficient contrast ratios for disabled buttons. They also don’t give users any feedback.

examples of enabled and disabled states by Carbon Design System — Example from Carbon Design System

Hidden state

Advantages of hiding the button:

Reduces cognitive load: users can focus more on the task in hand. By showing them what is needed only we remove distractions.
Simplicity: Not including disabled buttons saves space and allows us to change the controls, using the same space for different states.

examples of enabled and hidden states — Example from Carbon Design System

Disadvantages of hiding the button:

If overused it can be distracting; constantly hiding and showing buttons may distract because the view changes constantly.
Poor discoverability: Users might search for the hidden option.

Which one to use?

Before deciding which state to use, we should try answering the following questions:

What does the user need to know at this point?
What does the user need to do at this point?
Will the user know about that feature?
Will the user spend a lot of time hunting for it?

The answers to the above questions can help us figure out which state to use.

Suggestions

Choose disabled when:

If the button is temporarily disabled or requires a specific action from the user to change its status. In this case, it would be useful to provide a hover bubble/tooltip/detail disclosure buttons explaining the criteria for use and informing users what actions they can take to enable them.
If you want the user to know that the control exists, but that it is disabled.
If the user could see this feature somewhere that then not be able to find it again if it is now hidden. And there would be no indication why they can’t find it again.

Choose hidden when:

If the user is not authorized to use the control which means it is never available to the user.
If it is a control that is only active in very rare situations. Don’t show the user a button that can’t be used or enabled to be used.
If a page has a lot of disabled functionality. For instance, a whole extra block of form inputs.

Note: Using the disabled state isn’t the only way to deal with temporarily disabled actions. Rather than using disabled buttons, it is possible to keep the button in its default state and display an error message letting the user know why they can’t proceed.

Other considerations

When using disabled states we need to make sure they adhere to accessibility guidelines. There needs to be a clear distinction between disabled and enabled button styles. Colour contrast is a big thing for web accessibility.

It is best to communicate a disabled state button by changing its transparency instead of greying the button out. Users are less likely to confuse a transparent button with other buttons. Grey can lead to ambiguity as it is sometimes used to communicate a low priority button in a group (e.g., cancel buttons) and can be mistaken for a call to action.

To minimize cognitive load it is useful to give explanations to users. For example, if a button changes into its disabled state, consider using helper text or a way to explain to users why this has occurred.

Conclusion

If the control is available sometimes but isn’t available right now, it should be disabled. In these cases, you can improve the user experience by explaining to the user why that is and how the action can be enabled)
If the user is not authorized to use the control (therefore, it will never become available to that person) it should be hidden.