Disabled Controls

This is the third and final article on why you should not disable buttons and what to do instead.

Skip to the solutions

Introduction

We’ll review the previous articles and go over who I’m writing these articles for and why.

Solution 1: Hide the button

Yes, you can just hide the button. I’ll show you various ways to do that and how some render differently.

Solution 2: The validation method

Use your already-existing client-side validation to inform the user they cannot perform the button’s action and how they can address it.

Solution 3: The help text method

Inform the user with help text. It’s certainly not a flashy solution, but it can fit the bill. I include a variant that somewhat addresses the user’s tendency not to read important text.

Solution 4: The modal method

Give the user the needed information in a modal. It’s not my favorite solution, but as I’ll show you, it can be extended to give the user a much better experience.

Lesser recommended solutions

I’ll provide options that are more accessible than disabling buttons, but I’m not comfortable giving my full recommendation. Requirements are king — and sometimes the requirements call for disabled buttons. I’ll show a few solutions for such a case.

Conclusion

Links

Review

Below is a quick recap of the previous articles.
Feel free to skip to the solutions.

Part 1: Why not?

In this entry, I laid out the case for never disabling buttons. It caused far more controversy than I anticipated, but debate is healthy.

Part 2: Requirement for an accessible solution

In this article, I gathered requirements so that we can determine if the solutions are viable. And here they are: