corneretageres.com

<The Case Against Disabling Buttons: Why Accessibility Matters>

Written on

The Dangers of Disabling Buttons

In this section, we will explore why disabling buttons is detrimental to user experience. This includes a lack of communication and the challenges faced by certain users.

Addressing Common Concerns

We will examine frequently raised objections regarding the practice of disabling buttons, including perspectives from WCAG, special scenarios, error prevention, and more.

Conclusion

Issues with Disabled Buttons

User: “Why is it disabled?” Developer: “That's for you to figure out.”

Disabling buttons creates accessibility problems. Even users who do not rely on assistive technology (AT) feel neglected.

When a button is disabled, what message does it convey to the user?

Dear user:

  • "This button is currently inactive, but you should understand why."
  • "This button won't work now, and I won't inform you when it might."
  • "The reason for this button's inactivity is your issue."

These thoughts may not be explicitly intended, but they reflect what users perceive — and that perception is crucial.

Users are left to ponder, guess, and ultimately seek assistance, which is counterproductive.

As Hampus Sethfors points out in his article "Disabled Buttons Suck":

> Disabled buttons often contain action-oriented phrases like "Send," "Order," or "Add Friend," aligning with users' intentions. This leads them to attempt clicking, only to face frustration when nothing happens.

This can result in a range of negative emotions, from confusion to disappointment. If you need to prevent a user from executing an action, they should be informed:

  1. They cannot perform the action.
  2. The reason for this limitation.
  3. Any steps they might take to complete the action.

Disabling a button fails to convey any of this information.

AT User: “What button?” Developer: “It’s right there. Can’t you see it?”

Disabling buttons obscures them for assistive technology users.

When a button is disabled, it is removed from the tab order, effectively hiding it. For AT users, this translates to a dysfunctional form.

Consider a form with three required fields where JavaScript only enables the Submit button when all fields are filled. If an AT user mistakenly leaves one field empty and believes they have completed the form, they may:

  • Press Tab — the disabled Submit button is skipped, potentially leading them out of the form.
  • Press “f” (the shortcut for advancing to the next control in JAWS and NVDA) — the button is read as "unavailable," leaving them confused.
  • Press Enter — nothing happens.

This is a common design flaw that neglects AT user needs.

James Carleton highlights in his article "UI Traps: Disabled Buttons and Inputs":

> This approach aims to prevent incorrect form submissions. However, it shifts the burden onto the user to adapt to the system's constraints.

Color-Blind User: “The button’s disabled?” Developer: “Yes! Can’t you tell?”

Disabling a button also negatively impacts users with color vision deficiencies. Visually, the only change is a color alteration, which may not effectively communicate that the button is inactive.

If a user attempts to click a disabled "Submit" button without realizing it is inactive, the interface fails to convey that they cannot proceed.

If you're wondering how to adequately indicate that a button is disabled, refer back to the title of this article: "Never, ever disable buttons."

Addressing Objections

Thus, my position is clear: disabling buttons should be avoided entirely.

I anticipate numerous objections, so let’s tackle some of the most common.

Objection #1: WCAG Approves This Practice

This objection likely refers to Success Criterion (SC) 1.4.3: Contrast Minimum:

> The visual presentation of text and images of text must have a contrast ratio of at least 4.5:1, with exceptions including inactive UI components.

The text regarding inactive components lacks contrast requirements. While WCAG provides guidelines, adherence does not equate to true accessibility.

Consider WCAG as the baseline; if your goal is accessibility, disabling buttons is counterproductive.

Objection #2: I Have Unique Use Cases for Disabled Buttons

In reality, there are no valid scenarios that necessitate disabling buttons. All concerns can be addressed through more accessible alternatives.

It often boils down to a reluctance to invest effort in accessible solutions or assumptions about user behavior.

Objection #3: Disabling Buttons Prevents Invalid Data Entry

That’s precisely why validation exists.

Moreover, disabling a button does not communicate the presence of invalid data. From the user's viewpoint, the form may appear faulty.

Recently, while ordering photos online, I encountered a disabled "Place Order" button despite entering all correct details. No error message was provided, and removing the disabled attribute allowed me to proceed without issue.

Don't rely on disabled buttons to prevent security breaches or data entry errors; validation should handle those concerns.

Objection #4: Can’t I Just Disable the Button and Use a Tooltip?

How would an AT user interpret that tooltip?

This brings us back to the fundamental issue: buttons that are disabled are not perceivable to all users.

If you consider using the title attribute, it only works if the user focuses on the control or hovers over it. Disabled buttons do not receive focus.

Additionally, if you place explanatory text near the button, it still suffers from the same limitation regarding AT users.

Objection #5: AT Users Can Still Access Disabled Buttons Using the "f" Key

While true, this assumes a specific method of navigation among AT users, which can vary widely.

Furthermore, color-blind users may struggle to discern if a button is disabled without repeated attempts to click it, leading to possible conclusions that it’s simply broken.

Objection #6: I Don’t Have Time for Accessible Solutions

Whose time matters here? Users' time is just as valuable.

Consider the lengths you go to achieve an aesthetically pleasing interface with smooth transitions and mobile compatibility.

Yes, creating accessible solutions may require more effort than simply adding a disabled attribute, but investing in accessibility now will simplify future endeavors.

Objection #7: An Accessible Solution Would Be Unattractive

Is an aesthetically pleasing but non-functional page truly better than an unattractive yet functional one?

Disabling buttons effectively breaks the interface for AT users, rendering the design moot.

Most UX professionals thrive on challenges. Take on this challenge: devise a usable, accessible solution that remains visually appealing.

Objection #8: Disabling Buttons is a Long-Standing Practice

Indeed, but history does not justify poor practices.

We have evolved from outdated HTML standards; it’s time to let ineffective habits fade away.

Conclusion

I recognize that I haven't provided solutions in this article, as that would extend its length significantly. This is why it's part one of a series. In the follow-up, I will discuss accessible alternatives to disabling buttons.

If you have objections not covered here, please share. To date, I have yet to encounter a compelling reason to disable buttons that outweighs the accessibility challenges they create.

We must stop designing solely for ourselves. Instead, consider the diverse range of users — from visual users to keyboard-only users, color-blind users, and screen reader users.

Disabling a button communicates different messages to various user groups:

  • Typical user: The button is disabled — why? Did I make a mistake?
  • Keyboard-only user: I can’t access the button. Is it disabled? Why?
  • Color-blind user: I'm clicking the button, but it’s unresponsive. Is it broken or just disabled?
  • Screen reader user: Where is the button?

Ultimately, disabling buttons communicates information to one group of users (sighted mouse and keyboard users) while withholding it from others (AT users).

Breaking old habits may be challenging, but we must prioritize the needs of all our users.

Here’s Part 2: Never, ever disable buttons — Requirements for an accessible solution.

Here’s Part 3: Never, ever disable buttons — More accessible alternatives.