Why you shouldn't disable input and how to do it correctly

@ User Experience

Introduction

This article discusses the built-in disabled attribute on HTML elements. You can add it to buttons or various input controls (text inputs, checkboxes, range selectors) to make an element unavailable. As a result, you often see disabled used in situations like:

  • Avoid duplicate actions? Disable it!
  • Conditions not met? Disable it!

Directly “removing options” to “prevent users from making wrong choices” seems like a straightforward and effective solution, but in practice this approach can negatively affect the user experience. In most cases, we should avoid using the disabled attribute for the following reasons.

Reason 1: Disabled elements are inherently hard to perceive/read

Bootstrap Disabled Demo
Disabled styles are inherently hard to distinguish

Most buttons don’t have styles to distinguish “enabled” from “disabled” states. The common convention is that gray or faded buttons mean “disabled,” and this choice has been adopted into many browsers’ and even operating systems’ default button styles. I recommend visiting whocanuse🔗 to experience how different users with visual impairments perceive interfaces.

  • Not friendly for users with vision impairments: Fading and gray-on-gray convey “disabled” but also reduce readability.
  • Not friendly for unfamiliar users: When seen in isolation it’s hard to tell if the appearance is the button’s default style or a disabled state.

Reason 2: Disabled elements only block behavior, they don’t tell the reason

While disabling can achieve the goal of “preventing users from making the wrong choice,” it provides no communication about the conditions for re-enabling. This design leaves users confused — they don’t know why the button is disabled or how to enable it.

Imagine filling out a form carefully and being unable to submit because some fields don’t meet the submission criteria. It’s like telling the user “the form cannot be submitted yet — you need to figure out why yourself.” Such a design doesn’t help users solve the problem and leaves them bewildered.

Reason 3: Dynamically disabling elements is unfriendly to accessibility

Dynamically disabling the element that currently has focus can make users lose the current focus, which is unfriendly to keyboard users. For example, when a user presses a submit button and the button is disabled to prevent duplicate submissions, the button loses focus and focus shifts to the document element — like being forced back to the first page while reading.

Summary

The web used to be static; dynamic state changes are now common. Arbitrarily using the disabled attribute is like placing a boulder in the user’s path — it doesn’t help users solve problems and instead causes confusion.

Of course, completely preventing users from proceeding is sometimes reasonable, for example:

  • Communicate that an action exists but is unavailable: such as “only one coupon can be selected” or “item sold out.”
  • Indicate an action has been executed to avoid duplicate triggers: e.g., during form submission while loading, disabling the cancel button to prevent repeat triggers.

We should strive to tell users why something is disabled, not just “prevent users’ mistakes.” Possible approaches include:

  • Add explanatory messages: Let users know why the element is disabled.
  • Change the cursor when hovering over the button: for example cursor: not-allowed;.
  • Use the aria-disabled🔗 attribute: it keeps the element focusable while conveying that it’s disabled semantically.

Further reading