Member-only story

Disabled Controls

Never, ever disable buttons — Requirements for an accessible solution

Daniel Berryhill
UX Collective
Published in
11 min readNov 13, 2023

An excavator gathering dirt
Photo by Bermix Studio on Unsplash

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.

Contents

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

Create an account to read the full story.

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

Responses (16)

Write a response

IMO hiding buttons is a terrible design choice, much worse than disabling them, because it goes against spacial memory.

When there is a hidden button, users will remember it was there last time, and search for it. They may just think it's some kind…

I love teaching almost as much as I like learning. Let me help you out here…

> Are inaccessible for assistive technology (AT) users.

aria-disabled="true"

> Do not communicate why the button is disabled.

This assumes a need for more information…

A fresh take on an old, but still contentious, topic. Thanks for this.