Skip to content

Disabled States Research Findings 2023

Jump to bottom Edit New page
Jacline Contrino edited this page Feb 14, 2024 · 2 revisions

Background and goal

A “disabled state” is when elements such as buttons, inputs, forms, or other components are temporarily inactive or unavailable for interaction. In summer 2023, the U.S. Web Design System (USWDS) team investigated industry best practices for disabled states. We wanted to find out if the benefits of using them outweighed their disadvantages.

We reviewed the available literature from both a user experience (UX) and accessibility perspective, and here we’re documenting our recommendations.

Approach

  • Research timeframe: May to June 2023
  • Research method: landscape analysis and literature review

Summary

We found that disabled states can lead to a low-quality user experience, especially for people who use assistive technology. Disabled states often:

  • Do not pass color contrast requirements
  • Do not provide useful feedback to users
  • Do not work consistently across browsers (see previous landscape analysis)

We recommend against using disabled states. Instead, keep elements enabled and provide feedback to the user.

In a few particular situations it might be okay to use disabled states. For example, in the case of multiple form submissions, disabled states can prevent errors by telling users that a system is loading or processing. Disabled states can also show that certain controls or options exist but are currently unavailable, such as an unavailable date for appointment scheduling.

**Carefully consider **whether the benefits of using disabled states outweigh the negatives. Do usability research to find out if using disabled states improves UX in your particular implementation for your users. When you must use disabled states, follow best practices to reduce potential harm.

Detailed findings

Reasons to NOT use disabled states

Overall, disabled states can confuse and frustrate users because:

  • Disabled states don’t provide feedback about why actions are unavailable. People are left guessing why they can’t proceed. They might think, “Why does this button look so strange? What does it say? Why can’t I click it? What should I do now?”
  • Disabled states can unintentionally fool people into clicking. These states often have call-to-action words like “Submit,” which match what people want to do.
  • Disabled states make the interface feel broken. If the user thinks their input is valid, they are left wondering why they can’t proceed.
  • People may not notice the action becoming enabled or disabled. For example, a button may be off-screen when it becomes enabled (on longer forms, on a small screen, when using zoom magnification). Or, they may be too focused on filling out the field to notice the button change.
  • Disabled states create a barrier to people with disabilities:
  • People with low vision may not see them due to low contrast.
  • Screen reader users and keyboard navigators can’t tab to a disabled element (i.e., they are not focusable) and may wonder why not.
  • Disabled states tend to cause challenges for people who have difficulties filling out forms. Consider people with dyslexia, cognitive or learning impairments, motor disabilities, people who are less tech savvy, etc.

What to do instead

  • Keep the user interface (UI) element enabled and provide feedback.
  • Use contextual helper text, a tooltip, and validate user input upon submission.
  • Show a helpful error message when anyone tries to interact with a disabled element. A good error message helps people understand what caused the problem and guides them to a solution.
  • Use inline validation. Validate what people enter in each field to prevent error messages after submission in the first place.
  • Reduce cognitive load for users by following USWDS guidance for helping people progress easily through a form.

Possible appropriate reasons to use disabled states

Loading or processing: The user has initiated an action, and the system is processing. Disabling the element can prevent errors such as multiple submissions.

  • Example 1: Using the “submit” button after filling out a form. To prevent multiple submissions, the button is disabled after it is pressed and while the system processes. Disabling the button could prevent unintentional errors like submitting twice or transferring funds more than once in bank transfers.
  • Example 2: Asking the user to submit a file but not allowing submission until the file is fully uploaded. This practice prevents data loss that could happen if a file were sent before it finished uploading.

Discoverability and preventing future steps: You want the user to know that the control or option exists but that it is currently unavailable.

  • Example 1: A future date is not available in an appointment scheduling tool.
  • Example 2: Future steps in a multi-step process (such as filling out an online form) are disabled, so users do not skip ahead.

If you must use disabled states, follow best practices

Support screen readers

  • Use aria-disabled=true rather than disabled, which lets the user know that a button is present. Use aria-live to prevent accidental submission of an incomplete form.
  • You will still need to prevent the click programmatically using JavaScript.

Provide feedback to explain what just happened, what is happening now, and what will happen next.

  • Use helper text or tooltips to explain why something is disabled.
  • Use inline validation.

When to hide elements instead of disabling them

  • The user is not authorized to use the control, so it is never available to the user.
  • The control is only active in rare situations. Don’t show the user a button that can’t be used or enabled.
  • A page has a lot of disabled functionality (e.g., a whole extra block of form inputs).

Disclaimer

Links to nongovernment sources are made for educational or source citation purposes only, and do not represent an endorsement of the organizations by the General Services Administration. The General Services Administration does not assume any responsibility for the content, operation, or policies of other entities’ websites.

References list

Add a custom footer

Disabled states research findings 2023

Usability testing day checklist

Usability research findings for Q3 2023

Clone this wiki locally