Disabled Controls

11 min read

·

19 hours ago

In a previous article, I discussed the problems with disabling buttons.
Namely, that disabled buttons:

• Are inaccessible for assistive technology (AT) users
• Do not communicate why the button is disabled
• Incorrectly assume the user understands that the button is disabled and why
• Do not sufficiently communicate to the user what they must do to enable the button

When I started writing this article, it included possible alternatives along with what you’ll read below, but it became too long. So, I’ll have to save the actual alternatives for a future submission (my sincere apologies — I’m wordy; it’s a problem).

Hopefully, once we go over the requirements, you’ll likely be able to infer an alternative yourself. The clues are all there.

The reason behind a disabled button

We’ll go over why a developer would want to disable a button in the first place. This will give us our first requirement.

What the user needs to know

If the user can’t perform the action the button would perform, what should we communicate to the user. We’ll discuss how disabled buttons fail to communicate and act out a conversation between the user and the web page. This will give us our next two requirements.

Providing the information in an accessible way

We’ll discuss what will work, generally speaking. This will give us our final requirement. Then, we’ll go over what won’t work, specifically bad implementations for communicating information to the user.

Conclusion

Links

Let’s dig into what a developer is attempting to accomplish by disabling a button. To state it simply, developers typically disable buttons to prevent user error, data corruption, or unauthorized access.

Is disabling a button the only way to do that? Of course not! But it’s easy and it’s been such…