In a design system, why is a disabled submit button that hides the reason a problem, and what should an e-signature app's 'Finish signing' do instead?
answer
- silence is not feedback
- inactive means no contrast rule
- often skipped by focus
- enabled, then point to what's missing
- reason next to the control
basics
~20 sA silently disabled button gives no feedback: users cannot tell what is missing, and it may be faint and skipped by focus. Prefer an enabled button that, when pressed, names what is missing and leads there, or a visible reason.
solid answer
~50 sA disabled "Finish signing" with no explanation leaves a signer stuck: they press it, nothing happens, and they cannot tell that two required fields on page nine are empty. It also tends to fail people twice over. WCAG 2.2 exempts inactive components from the contrast criteria, so the button is often faint, and common implementations remove disabled controls from the focus order; the Authoring Practices note that screen-reader users are far less likely to discover disabled elements that are not focusable. The better pattern keeps the button **enabled**: on activation it identifies each missing field in text, as WCAG 2.2's 3.3.1 Error Identification expects, and takes the signer to the first one. A visible progress line such as "2 required fields left" helps before they press. Disabling stays reasonable when the reason is obvious from context, or when an adjacent visible message explains it.
go deeper
Recall why a silently disabled button frustrates users and name the main alternative: keep it enabled and explain what is missing when pressed.
Explain the mechanics beneath: the contrast exemption for inactive components, disabled controls leaving the focus order, and how error identification replaces silence.
Walk through diagnosing a drop-off at a disabled submit in a real flow, and how you chose between enabled validation, progress and a visible reason.
Consider how the system's guidance and component defaults steer teams away from silent disabling without banning a state that is sometimes right.
## The scenario An e-signature product sends a signer a twelve-page agreement with six required fields: two signatures, three initials and a date. The design shows a **Finish signing** button that stays **disabled** until every required field is complete. A signer completes what they see, presses Finish, and nothing happens. The button is pale, there is no message, and the two missing initials are on page nine. Some signers give up; others contact the sender or support; a few assume the product is broken. This is the classic *disabled submit button that hides why*. ## Why it fails users - **No feedback.** Pressing a disabled control does nothing, so the user learns neither what is wrong nor where. - **Hidden requirements.** The rule that enables the button lives in the product's logic, not on the screen. - **Low legibility is allowed.** WCAG 2.2's **1.4.3 Contrast (Minimum)** exempts text in an *inactive user interface component*, and **1.4.11 Non-text Contrast** exempts inactive components too. Disabled buttons are therefore usually faint, and users with low vision may not even read the label. - **Hard to discover without sight.** Many implementations remove disabled controls from the keyboard focus order. The WAI-ARIA Authoring Practices point out that screen-reader users are "far less likely to discover disabled elements that are not focusable", because moving focus is one of their main ways of exploring. - **Blame shifts to the product.** A silent control reads as a bug, generating support contacts that a sentence of text would have prevented. ## Better patterns | Pattern | How it works | Fits when | Cost | |---|---|---|---| | **Enabled, validate on press** | Press identifies what is missing and moves to it | Requirements can be checked instantly | Users may press early and see errors | | **Visible progress** | "2 required fields left" with a jump-to-next control near the button | Long documents with scattered fields | Needs space and live updates | | **Disabled with a visible reason** | Disabled, with adjacent text explaining why and how to fix it | Action is truly unavailable, e.g. the sender voided the agreement | Reason text must stay current | | **Disabled, reason obvious** | No explanation needed | Context makes it self-evident, such as "Previous" on the first page | Only works when inference is really easy | The **enabled, validate on press** pattern connects to WCAG 2.2 **3.3.1 Error Identification** (Level A): when an input error is automatically detected, the item in error is identified and the error is described to the user in text. For the signer, that means naming the two missing initials and taking them to page nine, rather than keeping the button inert. ## Deciding case by case 1. **Can the user fix it?** If yes, keep the button enabled and guide them to the fix. 2. **Is the action unavailable for a reason the user cannot change** (permissions, a voided agreement, a locked document)? Then disabling is honest, but the reason must be visible next to the button. 3. **Is the reason obvious from context?** A disabled "Previous" on page one needs no explanation; the Authoring Practices use a similar example. 4. **Does the disabled button need to stay discoverable?** If so, keep it focusable in its disabled state so screen-reader users find it and hear its reason. ## What the reason text should say - **What is missing or blocking**, in the user's terms: "2 initials missing on page 9", not "Validation failed". - **How to fix it**, or who can: "Only the sender can reopen a voided agreement". - **Where it lives**: next to the button and exposed as the button's description, so it is heard as well as seen. ## A related but different case Disabling a button for a moment **during submission**, to prevent a second press, is a loading state, not the anti-pattern above. It has its own contract: keep focus, keep the width, and announce the outcome. ## The same on native mobile Native platforms have the same disabled state with the same consequences: a dimmed control that ignores taps and may be skipped by the screen reader. The remedy is identical: prefer an active control that explains, or place the reason beside the disabled one.
- Isn't an enabled button that produces errors worse than preventing the error?Only if the errors are unhelpful. A press that names each missing field and moves the signer to the first one is faster than hunting for why a button is inert. Prevention still helps as a complement: a visible count of remaining required fields tells signers before they press, without hiding the action.
- When would you keep a disabled button focusable?When it must stay discoverable, for example a disabled 'Finish signing' whose reason is shown next to it. Keeping it in the focus order lets screen-reader users find the button and hear the reason. When the disabled state is easy to infer from nearby controls, removing it from focus saves keystrokes; the Authoring Practices describe both conventions.
saying these in an interview costs you the question
- Disabling the submit button until everything is valid prevents all errors.
- Disabled buttons must still meet the 4.5:1 text contrast requirement.
- Users will work out why a button is disabled by themselves.
- Screen-reader users discover disabled buttons as easily as enabled ones.
- A disabled state tells users what to fix without any extra text.