UX Patterns Guide
Back to compare picker

Disabled button with no explanation vs Inline validation vs Error summary

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.

Disabled button with no explanation live exampleInline validation live exampleError summary live example

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 users correct a specific field without losing or re-entering the value they already typed.Help users recover from one or more submitted-form errors without scanning the entire page.
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 Create workspace is greyed out with no nearby text, checklist, or request-access route.Only a red border with no message.Red banner saying fix errors with no links.
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 Users change random fields because the unavailable action never states the missing condition.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.A single local field issue can be corrected before submit without page-level orientation.
Required state Unavailable action state with visible reason and affected requirement.Neutral field with label, hint, and no error.Neutral form before submit with no summary.
Accessibility burden Do not make the only explanation unreachable because the control is disabled, skipped by focus, or hidden behind hover.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 Greying out Continue until every field is valid without showing the missing or invalid answers.Showing field errors before users have interacted with the control.Showing a red banner or toast with no links to the invalid answers.

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
Create workspace is greyed out with no nearby text, checklist, or request-access route.
Good UX
Users can satisfy requirements one by one and see the action become available, or submit and receive actionable validation.
Bad UX
Users change random fields because the unavailable action never states the missing condition.
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
Do not make the only explanation unreachable because the control is disabled, skipped by focus, or hidden behind hover.
Common misuse
Greying out Continue until every field is valid without showing the missing or invalid answers.

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 users correct a specific field without losing or re-entering the value they already typed.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Only a red border with no message.
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
Neutral field with label, hint, and no error.
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
Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Red banner saying fix errors with no links.
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
A single local field issue can be corrected before submit without page-level orientation.
Required state
Neutral form before submit with no summary.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Showing a red banner or toast with no links to the invalid answers.
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.