Disabled button with no explanation

Problem Context

• A form, setup flow, permission model, quota, dependency, or safety gate controls whether an action can run.
• The primary action is greyed out, skipped by keyboard focus, or visually present but functionally unavailable.
• The reason may be a missing field, invalid format, unchecked agreement, insufficient permission, pending system state, or locked account.
• Users need to know what to change, who can grant access, or when the action will become available.

Selection Rules

• Flag this anti-pattern when an unavailable action has no visible requirement, cause, owner, or next step near the control.
• Show a requirement checklist or status message for eligibility gates such as missing name, terms acceptance, permission, quota, setup, or dependency state.
• Keep the action enabled and validate on activation when users benefit from seeing exactly which fields failed after an attempted submit.
• Use inline validation when one field has a local correctable problem and the action itself does not need to explain a wider eligibility gate.
• Use an error summary when a submitted page or step returns multiple validation errors that may be spread across the page.
• For permission or system locks, show who can resolve the block, whether the user can request access, and what data remains safe.
• Disable only during short in-progress states such as preventing duplicate submit, and pair that state with visible progress or completion feedback.

Required States

• Unavailable action state with visible reason and affected requirement.
• Partially eligible state that shows which requirements are complete and which remain.
• Actionable recovery state such as edit field, accept terms, request access, retry later, or contact owner.
• Eligible state where the action becomes available or an enabled submit can validate remaining issues.
• Submitted or completed state after the action succeeds.
• Permission-denied or system-locked state with an escalation route.

Interaction Contract

• Users can discover why the action is unavailable without hovering a disabled control or guessing from color alone.
• The explanation is adjacent to the action or requirement list, not hidden in a detached tooltip or unrelated help page.
• Keyboard and assistive technology users can reach the requirement text and any recovery controls even if the unavailable action itself cannot receive focus.
• Eligibility changes update the visible requirement state and action state in the same region.
• If submit remains enabled, failed activation preserves user input and moves focus or reading order to actionable validation.
• Permission locks distinguish missing user input from account, role, quota, dependency, or system constraints.

Implementation Checklist

• Name the exact condition blocking the action, such as Enter a workspace name, Accept billing terms, or Ask an admin for owner access.
• Place requirement text, checklist, or field errors before the action or directly beside it.
• Use enabled submit plus validation when disabling would hide field requirements or prevent users from learning what remains.
• Use aria-describedby or equivalent relationships for nearby requirement text when an unavailable control remains in the UI.
• Keep recovery links, request-access controls, edit fields, and support routes keyboard reachable.
• Avoid hover-only explanations on disabled controls because disabled elements may not receive focus or pointer events consistently.
• Update the action label or status during short processing states so users know the button is busy, not permanently unavailable.

Common Generated-UI Mistakes

• Greying out Continue until every field is valid without showing the missing or invalid answers.
• Putting the only explanation in a tooltip attached to a disabled button that keyboard and touch users cannot open.
• Using disabled state to hide permission, quota, account lock, or system dependency problems.
• Changing the button from disabled to enabled silently after a requirement changes elsewhere on the page.
• Disabling a destructive action without explaining the safety prerequisite or alternate route.
• Using low contrast disabled styling as the only signal that an action is unavailable.

Critique Questions

• Can users tell exactly which requirement blocks the action before they try random changes?
• Can keyboard and screen reader users reach the explanation and recovery path?
• Is this a field validation problem, a permission problem, a system state, or a safety lock?
• Would an enabled submit with validation teach the next step better than a disabled button?
• Does the UI distinguish temporary processing from a longer blocked state?