← Back to Catalog

Don't use disabled buttons

dont-use-disabled-buttons

Don’t use disabled buttons on public/question flows — keep the button enabled and explain on press (GOV.UK). Settings Save MAY disable until requireds are complete ONLY if the disabled reason is visible and the label stays perceivable (Fluent). Dual-cite; not a global never/always.

Description

On public question flows, keep the button enabled and explain why the press failed when input is incomplete or invalid. Settings Save may disable until required fields are complete only if the disabled reason is visible and the label stays perceivable. There is no global never-disable or always-disable rule across both contexts. Fail for a disabled control with no explanation, or a single policy that ignores the question-versus-settings split.

When to use

Deciding whether submit or Save stays enabled on incomplete public or settings forms.

Not when

Not for unrelated non-submit controls outside question and settings Save patterns.

Agent hint

Keep public submit enabled and explain on press; disable settings Save only with a visible reason.

Pass

Public/question: submit stays enabled; pressing it with incomplete/invalid input explains why. Settings Save: either the same enabled+explain pattern, or disabled until requireds are complete with the reason visible and the label still perceivable.

Fail

Disabled with no explanation; or a single global never-disable / always-disable that ignores question vs settings.

Citations

GOV.UK Design System — Button; Fluent 2 — Field usage (disabled control; label/helper stay perceivable)

https://design-system.service.gov.uk/components/button/

Open UX · cited UX rules agents audit against

Privacy · Sources ·