Don’t Disable Form Controls

Just another usability and accessibility pro telling authors not to do the thing they continue to do.

It’s Ok to Disable Buttons

Telling authors not to disable buttons is too broad. There are cases where it’s appropriate to disable something controlled by a button. Buttons can do lots of things — expand disclosures, pop dialogs, play videos, toggle themes, slide views, download files, and so on — and disabling the button may be a least-bad method of signaling a feature is not currently available but may be later for reasons that you have made clear to the user.

Whether or not you want to do that is a function of context, audience, expectations, and more. Often there are better ways to handle making a feature inactive, but a blanket ban is not ideal.

Don’t Disable Submits

The place where buttons should not be disabled is within the context of submitting a form. Or, more specifically, within the context of gathering information from a user that may need to go through validation, review, corrections, and so on. This includes platforms that rely on asynchronous connections to move data around instead of HTML forms.

When you hear a usability, user experience, accessibility, research, or interface design professional warn you not to disable buttons, they are generally talking about submit buttons.

I don’t need to make that case. Plenty of folks have written about it (in my opinion they aren’t aggressive enough):

• Disabled buttons suck by Hampus Sethfors, 7 July 2017.
• Why you shouldn’t include disabled interaction elements in your design system by Chris Atherton, 12 February, 2019 (ugh, Medium).
• Why heuristics are only rules of thumb: the case of the disabled button by Matthew Standage, 9 May 2020.
• Making Disabled Buttons More Inclusive by Sandrina Pereira, 12 May 2021 (doesn’t go far enough, and I reviewed it).
• Usability Pitfalls of Disabled Buttons, and How To Avoid Them by Vitaly Friedman, 5 August 2021 (lets Wise off the hook on other bad patterns).
• Disabled Buttons in User Interface by Nick Babich, 2 October 2021 (doesn’t go far enough, also ugh Medium).
• The problem with disabled buttons and what to do instead by Adam Silver, 14 May 2023.

When a self-professed UX expert argued that submits could be disabled, his comments filled up asking for evidence why the author chose to contravene a well-known usability principle (for which he offered only combativeness). Those comments reinforce why disabling submits is bad.

Don’t Disable Form Fields

Telling authors not to disable submit buttons is too narrow. Authors should not disable any form fields.

Default styles are a terrible signal a field is disabled. Authors trying to make obvious disabled styles often leave users unable to either see a field at all or distinguish it from the other fields on the page. Rarely do authors explain why users cannot interact with a disabled field.

Disabling fields is no replacement for good instructions and error messages. Having a “clean” page is pointless if users cannot figure out how to get past it. You might as well lock them in a padded white room and paint a door on the wall.

Never mind cases where a form field isn’t even necessary, let alone a disabled one that demonstrates how little experience the development team has with humans around the world.

Those of us who have worked with users already know from experience that authors often do a poor job of conveying why a a user cannot submit, that styles rarely convey this well, that users get confused, and that WCAG is less useful because disabled controls exempt contrast requirements.

Disabling Decision Tree

I made a quick decision tree to help evaluate when it’s acceptable to disable interactive controls:

1. Is the control part of a form?
   1. No.
      • Maybe don’t disable it, but test with your users.
   2. Yes.
      • Don’t disable it.
2. See Step 1.

Wiggle Room?

I have an absolutist take on this. Not because it should never happen, but because the barrier for an author doing it should be sufficiently high as to warrant exploring all other options first. Only after those are all exhausted, to then consider rebuilding the thing so a disabled control is not the only option. If that is still the case, then user testing and evidence and signatures and blood pacts should come into play.

This burden should always be on the author, not the user. If you find yourself blaming the user for the pattern you built, you might be bad at your job.

Read-Only Is Not a Solution

Buttons are read-only controls. There is no good reason to make a submit button read-only. That’s just acknowledging they should not be disabled. Let’s not pave a cow path that results in so much confusion.

As for other form controls being read-only, well, that’s a topic for another ranty post.

Update: 3 April 2024

Kitty Giraudel has posted On disabled and aria-disabled attributes where they explain where each is more appropriate. Go read it.

One thing Kitty’s post doesn’t note is that disabled is not allowed on non-interactive elements that have been roled-up into interactive elements, so aria-disabled is your only choice for ARIA-only controls. As such, you may still want to add all the functional disabling whose absence Kitty identifies as a benefit. This is not a shot at Kitty’s words, which are all true (well, maybe not the readonly bit).

Alternatively, don’t disable form controls.