UX Patterns Guide
Back to compare picker

Disabled button with no explanation vs Inline validation vs Error summary

Use visible requirements or validation recovery instead of an unexplained disabled action; choose inline validation for local field repair and error summary for submitted multi-error recovery.

Disabled button with no explanation live exampleInline validation live exampleError summary live example
Learn the decision

Match the interaction to the person's task

Use visible requirements or validation recovery instead of an unexplained disabled action; choose inline validation for local field repair and error summary for submitted multi-error recovery.

Disabled button with no explanation

Use it when: Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.

Make this state clear: Unavailable action state with visible reason and affected requirement.

Observe the result: Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.

Study the full pattern →

Inline validation

Use it when: A single field has a specific correctable problem.

Make this state clear: Invalid field with preserved user value and adjacent correction text.

Observe the result: Validation appears after blur or submit when it helps correction.

Study the full pattern →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Practice the judgment: Imagine this situation: A disabled button hides field errors until users guess the missing inputs. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Disabled button with no explanationInline validationError summary
UI or UX UI + UX - Blocked action anti-patternUI + UX - Field-level validation feedbackUI + UX - Form recovery summary
UI guidance Replace a lone greyed-out action with visible requirement text, a checklist, permission message, or enabled validation submit that tells users what blocks progress.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing.Help the person reach a clear task outcome.Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI Disabled controls hide the only validation feedback from keyboard and assistive technology users.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.
Good UX Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX Disabled controls hide the only validation feedback from keyboard and assistive technology users.Showing errors before users type.Only showing errors below the fold.
Best fit Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.A single field has a specific correctable problem.Form submission can produce one or more errors.
Avoid when The action remains available and returns actionable validation after activation.The main recovery task is finding several errors across a submitted page.The message is a system failure, permission problem, or outage rather than a validation issue.
Required state Unavailable action state with visible reason and affected requirement.Invalid field with preserved user value and adjacent correction text.Failed-submit state with summary visible near the form heading.
Accessibility burden Keep requirement text in normal reading order and near the unavailable action.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.
Common misuse Using disabled state to hide permission, quota, account lock, or system dependency problems.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.

Disabled button with no explanation

UI or UX
UI + UX - Blocked action anti-pattern
UI guidance
Replace a lone greyed-out action with visible requirement text, a checklist, permission message, or enabled validation submit that tells users what blocks progress.
UX guidance
Help users understand whether the block is missing input, invalid data, permission, quota, dependency, safety policy, or temporary processing.
Good UI
Create workspace is paired with visible requirements: enter a workspace name, accept billing terms, and request owner access.
Bad UI
Disabled controls hide the only validation feedback from keyboard and assistive technology users.
Good UX
Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.
Bad UX
Disabled controls hide the only validation feedback from keyboard and assistive technology users.
Best fit
Use this anti-pattern entry to audit disabled submit, continue, create, save, delete, publish, invite, export, payment, and setup actions.
Avoid when
The action remains available and returns actionable validation after activation.
Required state
Unavailable action state with visible reason and affected requirement.
Accessibility burden
Keep requirement text in normal reading order and near the unavailable action.
Common misuse
Using disabled state to hide permission, quota, account lock, or system dependency problems.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help the person reach a clear task outcome.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Error message appears far from the field it describes.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Invalid field with preserved user value and adjacent correction text.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.
Decision rules
  • Flag disabled button with no explanation when an unavailable action does not show the missing requirement, permission limit, system lock, quota, dependency, or recovery path near the control.
  • Use visible requirement text or a checklist when users can become eligible by entering a value, accepting terms, requesting access, completing setup, or waiting for a named system state.
  • Use enabled submit with validation when blocking the button would prevent users from learning which form requirement remains unmet.
  • Use inline validation when one field has a local correctable problem such as missing value, format, range, or password requirement.
  • Use error summary after submitted validation returns multiple errors, cross-field errors, server-side validation, or errors below the current viewport.
  • For permission-gated actions, show the role or owner who can resolve the block and provide Request access, Contact admin, or read-only explanation.
  • For short processing states, disabling can prevent duplicate submit only when the button or nearby status says the action is processing and then resolves to success or failure.
  • Do not put the only explanation in a hover-only tooltip attached to a disabled control because keyboard and touch users may never reach it.
Inspect live examples
Disabled button with no explanationInline validationError summary
Failure modes
  • Users cannot tell which requirement blocks Continue.
  • A disabled button hides field errors until users guess the missing inputs.
  • A permission problem looks like invalid form data.
  • A tooltip on an inert control is the only explanation.
  • A submitted form shows only a disabled action instead of linked errors.
  • The button remains disabled after requirements change because eligibility feedback is disconnected from the form state.

Saved items