I was on the checkout page of an e-commerce platform today, and for some reason, the payment button was disabled. A few quick scans of the page did not make it obvious why. After a more deliberate scan, I realised they do not ship to my location.
That moment sent me down a rabbit hole about the UX of disabled buttons.
A lot has been written about this topic. The common theme is clear. While disabled buttons are intended to prevent user errors, they often lead to poor usability and exclusion, especially for users with disabilities.
When buttons fail silently
Disabled buttons often fail because they provide little to no feedback. Most of the time, it is not obvious why a button is disabled. This was exactly my experience on the e-commerce site.
The issue was not highlighted, and it was not placed where my attention naturally went. As a result, I was confused. I even switched payment methods, assuming that was the problem.
When this happens, users are forced to scan the entire page, trying to guess what went wrong. That confusion leads to frustration and, very often, abandonment.
The accessibility problem beneath the surface
Beyond general usability, disabled buttons introduce serious accessibility issues.
They are usually low contrast and greyed out, making them difficult or even impossible to see for users with low vision. Screen readers and assistive technologies often skip disabled buttons entirely because they are not focusable. When that happens, users may not even be aware that an action exists.
To make matters worse, WCAG does not require contrast ratios for inactive components, which leaves a large accessibility gap in many interfaces.
Thinking back on my own work, I have made these mistakes too.
Better patterns than disabling
There are better design patterns we can use.
One option is to keep the button active and provide clear, specific error messages after the user clicks it. This creates a kind of dialogue between the user and the interface.
Another approach is real time feedback. Showing validation as a user fills out a form helps them correct errors long before they reach the submit button.
In cases where a user will never need to use an action, the button should not exist in the UI at all. And when a button must be shown but needs to be disabled, helper text or a tooltip explaining why should be placed right next to it.
When disabling does make sense
Disabled buttons are not always wrong.
They can be useful when preventing double submissions after a form is sent. They also make sense during short system state changes while information is being processed. Another valid example is e-commerce, where an item may be unavailable but still needs to be visible, such as a disabled Add to Cart button.
Making disabled buttons more accessible
When disabling is unavoidable, there are ways to reduce the harm.
Using the aria-disabled attribute instead of the HTML disabled attribute allows the button to remain focusable and detectable by screen readers. Changing the cursor:not-allowed provides a clear visual cue. And instead of fully greying out a button, slightly reducing opacity can help the button feel muted while still maintaining contrast.
Disabled buttons are not inherently bad. But without context, feedback, and accessibility in mind, they quietly become a UX trap.
Here is an interesting read on improving accessibility of disabled controls
Sources:
Disabled Buttons UX - Usability Issues and How to Avoid Them
Disabled Buttons UX: User Experience Best Practices for Disabled Buttons
Disabled Buttons in User Interface
Making disabled button without compromising on accessibility : r/UXDesign
Should unavailable buttons be disabled or hidden? : r/UXDesign
The User Experience (UX) Of Disabled Form Buttons
The problem with disabled buttons and what to do instead
Usability Pitfalls of Disabled Buttons, and How To Avoid Them
What should be the contrast level of inactive buttons?
forms - Should disabled buttons give feedback when clicked? - User Experience Stack Exchange