| UI or UX | UI + UX - Blocked-control anti-pattern | UI + UX - Blocked action anti-pattern | UI + UX - Field-level validation feedback | UI + UX - Form recovery summary | UI + UX - Guided workflow for regaining or routing around missing access | UI + UX - User-directed alternate route when the primary path cannot complete |
| UI guidance | Pair unavailable controls with visible requirement maps, state messages, owner routes, and recovery actions that can be reached without interacting with the disabled element. | 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. | Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task. | Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence. |
| UX guidance | Model disabled controls as a lifecycle: unavailable with cause, recoverable, pending, available, processing, completed, or honestly stopped. | 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. | Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial. | Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task. |
| Good UI | An Invite teammate panel shows missing billing setup, owner approval, and team domain checks, with Open billing, Request owner approval, Save draft, and Contact admin actions. | 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. | A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval. | An address lookup says We could not find this address, keeps postcode SW1A 1AA visible, and offers Enter address manually, Try another postcode, and Get help with reference APP-2048. |
| Bad UI | Invite teammate is greyed out with no visible requirement, owner route, or alternate way to keep the draft. | 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. | A blocked report only has Retry, so the user repeats the same denied request. | A lookup returns No matches and only shows Search again, even though manual address entry is supported. |
| Good UX | A user sees which prerequisites are complete, opens billing setup for the missing prerequisite, saves the invite draft, requests owner approval, and returns to send once eligibility changes. | 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. | A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report. | A user whose address is missing from the lookup switches to manual entry with the postcode and application reference retained, completes the same application, and can return to lookup without losing typed fields. |
| Bad UX | A user repeatedly edits random fields because the disabled Continue control never names the remaining condition. | Users change random fields because the unavailable action never states the missing condition. | Showing errors before users type. | Only showing errors below the fold. | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | A user tries the same failed lookup five times because the manual route is hidden until after repeated failure. |
| Best fit | Auditing disabled primary actions, toolbar commands, menu items, toggles, form controls, checkout actions, invite flows, publish controls, exports, destructive actions, and workflow steps. | 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. | A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue. | A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish. |
| Avoid when | The control is briefly disabled only to prevent duplicate submission and visible progress explains the temporary state. | 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. | The product only needs to state that access is denied and no recovery path exists. | The only honest next step is retrying the same operation after a transient failure. |
| Required state | Prerequisite map state that shows each requirement and whether it is met. | Unavailable action state with visible reason and affected requirement. | Neutral field with label, hint, and no error. | Neutral form before submit with no summary. | Recovery start state with original blocked task and current account. | Primary path available state. |
| Accessibility burden | Do not make recovery depend on focusing or hovering a disabled element that may not be focusable or may suppress pointer events. | 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. | Move focus to the recovery heading when the workflow opens from a denial. | Make the fallback option visible near the blocked control or step, not only in help text or after mouse hover. |
| Common misuse | A Continue button remains disabled until all fields are valid but no field or checklist names the missing work. | 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. | Offering Retry for an unchanged authorization denial. | Hiding manual entry or support until users repeatedly fail. |