Disabled controls

In this article, I’ll explain why you shouldn’t disable buttons and answer the inevitable objections. In a subsequent article, I’ll provide more accessible approaches.

Problems with disabling buttons

In this section, we’ll talk about why disabling buttons is a bad solution for your users, including the lack of communication it promotes and how it cannot be perceived by certain users.

Answering objections

We’ll discuss the more common objections to barring disabled buttons, including WCAG’s stance, special use cases, error prevention, and others.

Conclusion

Links

User: “Why is it disabled?” Devs: “That’s your problem.”

There certainly are accessibility issues with disabling buttons (which we’ll get to), but even for those that don’t rely on assistive technology (AT), you’re telling them to take a flyin’ leap.

When you disable a button, what are you actually communicating to the user?

Dear user:

• “This button doesn’t work now, but you should be able to figure out why.”
• “This button doesn’t work now, and I’m not going to bother telling you if it ever will.”
• “Whatever the reason is for this button being disabled is your problem.”

You might not explicitly have these thoughts, but that’s what you’re communicating — or, at least, that’s what the customer thinks you’re communicating. And that’s really what matters.

You’re also forcing the user to think, guess, and (eventually) ask for help. And as I’ve stated in a previous article, that’s a no-no.

Here’s what Hampus Sethfors writes in his article “Disabled buttons suck”:

Disabled buttons usually have call to action words on them, like “Send”, “Order” or “Add friend”. Because of that, they often…