Reaching for disabled feels safe — it prevents users from doing something wrong before they are ready. But it almost always creates more problems than it solves, and it does so at the expense of users who are already most vulnerable to inaccessible design.

Why disabled elements cause problems

They give no feedback

A disabled element signals that something is wrong without explaining what. The user has to scan the entire screen, guess which prerequisite is missing, and figure out how to fix it on their own. This is especially frustrating when the blocker is off screen or buried in an earlier step.

They make the interface feel broken

If the user believes their input is correct, a disabled button makes the UI feel unresponsive. If there are multiple problems and they fix one of them, the button stays disabled — which makes it feel like their change was ignored. The interface appears stuck for no reason they can understand.

They are hard to see

Disabled states use intentionally low contrast to communicate unavailability. But low contrast also makes them hard to read — especially for users with low vision. The visual language that signals “disabled” is the same language that renders the element nearly invisible to the people who most need clear affordances.

They are not reachable by keyboard or screen reader

Elements with the native disabled attribute are removed from the tab order entirely. Keyboard-only users and screen reader users cannot reach them, which means they cannot discover that an action exists or understand why it is unavailable. For users with motor impairments who rely on keyboard navigation, a disabled button is a silent dead end.

They can be deceptive

The disabled state is not always visually obvious. Some users will continue trying to interact with a disabled element, receiving no response and no explanation. They may assume the product is broken, or that they are doing something wrong.

Users may not notice when they become enabled

If the enabling condition depends on a field elsewhere on the page — or on a different scroll position — users focused on completing the form may never notice the button has changed state. The transition from disabled to enabled happens silently.

What to do instead

The right alternative depends on why you were reaching for disabled in the first place.

Instead of disabling a submit button: show errors on submit

The most common use case — disabling a submit button until a form is valid — is also one of the most harmful. The alternative is straightforward: keep the button enabled. When the user submits, validate all fields at once and surface errors directly next to the inputs that caused them using Field and its error state.

This gives users clear, specific, actionable feedback. They know exactly which fields need attention and what to do about them.

Live validation — checking on every keystroke — does not solve this problem. It interrupts users mid-input with errors they have not finished entering yet, and it still does not explain anything to users who cannot see the button state changing.

Instead of disabling for a missing prerequisite: explain upfront

If an action requires a precondition — such as selecting an audience before publishing — communicate that requirement before the user reaches the action. Use hint text in Field, contextual copy near the control, or a Banner earlier in the flow.

If the requirement is only discoverable by attempting the action and failing, that is an information architecture problem, not a case for disabling. When the explanation must live at the point of the action, keep the control enabled and respond to the attempt with a clear message that describes what is missing and how to resolve it.

Instead of disabling a field to show a read-only value: use readOnly

If you want to display a value the user cannot change in the current context, use the readOnly attribute on Text Field. Read-only fields remain visible, focusable, and selectable — users can read and copy them, and the value is clearly part of the interface. Disabled fields appear faded and cannot be interacted with at all, which makes the content feel inaccessible and unimportant.

Instead of disabling a permanently restricted action: remove it

If a user will never be permitted to take an action — because of their role, permissions, or the permanent state of a record — remove the element. A disabled button for something the user can never do adds visual noise without value and creates questions that the UI cannot answer. Use Empty or a Banner to explain the restriction in context instead.

Instead of disabling options in a list: rethink the structure

Disabling individual items in a menu, select, or option list is often a signal that the data model or UI structure needs rethinking. If an option is never valid, remove it. If it is only invalid for certain selections, consider filtering dynamically rather than greying items out. Greyed-out options raise questions about why they exist and whether the user is missing something.

Instead of disabling a link: just remove it

Navigation is either available or it is not. A disabled link is a contradiction — it looks like a path but leads nowhere. If the element performs a conditionally available action, use Button and apply one of the patterns above.