Pattern Status
|
Status |
Validating. Add your feedback here. |
|---|---|
|
Owner |
Product Design Team |
|
Last Updated |
12.12.2025 |
Overview
This pattern redefines the old “disabled” concept as one of several ways to handle unavailable actions. It helps teams decide when to hide elements, display them as read-only, or mark them as disabled, distinguishing between temporarily locked actions and unavailable ones.
The goal is to set clear expectations: inform users why something isn’t available and, if they can enable it, show them how.
Principles
- Be predictable: Users should never wonder why something disappeared. Hide actions that are truly irrelevant or would not be valid anymore.
- Be clear: If an action is disabled, users should understand why and what’s required to enable it.
- Reduce cognitive load: Hide actions that are inherently impossible in the given context and disable only when it helps understanding.
- Support spatial memory: Keep actions in consistent locations so users always know where to find them.
- Avoid frustration: Don’t use disabled or dead-end actions for upsell. Offer clear upgrade cues instead, where appropriate.
- Design for accessibility: Balance hiding vs. disabling thoughtfully. Disabled states communicate state; hiding reduces tabbing burden. Provide clear, accessible explanations for inactive actions.
Types
We distinguish between five main types of availability.
Hidden
The user will never be able to perform the action in this context. (e.g., restricted by role, tier, or system configuration).
What to do: Remove the element entirely.
Prioritize showing available options only
Do not show unavailable options, unless they are relevant for the context
Locked (temporarily disabled)
The action is temporarily disabled because prerequisites are unmet, but can be resolved by the user (e.g., completing a required step, gaining permission, or selecting an item).
What to do: Keep the item visible with a lock icon or disabled state, and provide a short explanation of how to unlock it, with a direct link to the prerequisite task, if applicable.
Disabled
The action is disabled because it is invalid in the current context, typically due to system rules, time-based constraints, or business logic (e.g., a sold-out date). There’s no user path to enable it.
What to do: Show the option in the disabled state to indicate it cannot be selected. Optionally, include inline help explaining why, or, if needed, add a tooltip, ensuring the item remains focusable for keyboard users.
Read‑only
Users can view the content but cannot modify it (e.g., system-managed, inherited, or pre-defined values).
What to do: Present the information using non‑interactive styles, like static lists, non-interactive chips, or read-only fields.
Loading
The action is processing, and the interface provides feedback to indicate progress, helping prevent accidental re-submission or duplicate interactions.
What to do: Keep the button visible and enable the loading state. A spinner will appear to indicate progress.
Decision Flow
Use disabled states for temporarily unavailable actions, and reserve “hidden” for actions that truly don’t apply.
Ask: Will the user be able to interact with the element in the given context?
- No → Hide it
- Yes → Determine why it’s not currently available
- Prerequisite needed → Lock it
- The option is invalid in context → Unavailable
- User can view but not edit → Read-only
- The action is currently processing → Loading state
- It's a form submit button → Keep it enabled (validate on submit)
Examples
Availability states can vary depending on context. Here are examples and recommendations on how they can be applied in real UI scenarios.
Row actions menu
Scenario: Some tables present actions inside a row‑level dropdown menu, such as “Delete”. Certain out‑of‑the‑box items cannot perform one of the actions.
Recommendation: If the user can delete other rows, keep the menu structure consistent and show the “Delete” option as disabled, with an optional tooltip explaining why the action cannot be performed (e.g., "System-generated items cannot be deleted").
A Short Stay is a pre-configured, out-of-the-box service that cannot be deleted. Keep the same menu structure across rows to ensure discoverability is not affected in other rows.
Permission-based
Scenario: An action is restricted by user role or access level and will never be available in this context.
Recommendation: If the user will never be allowed to perform the action, hide it completely, or display tailored alternatives based on that role.
If a user does not have permission to perform an action or is restricted by their tier, explicitly explain the reason or hide the action entirely.
Allowing users to attempt actions that in theory they can't due to permission, leads to frustration, particularly when they only discover the limitation after trying to complete the task.
Provide upgrade paths or contextual messages when appropriate, but avoid displaying disabled actions simply as upsell prompts. Ensure that users never reach dead ends in the interface.
Bulk actions
Scenario: The user selects multiple rows for a bulk operation, but not all of them support the same actions (e.g., some items cannot be deleted).
Recommendation: Disable the action when one of the selected items cannot perform it, and add an explanation like an accessible tooltip. Enable the action only once all selected items support the operation.
Provide real‑time feedback and visual cues. If users select an ineligible row, immediately disable the action and display a concise explanation.
Don’t hide the bulk action entirely. If non‑actionable items are selected, the bulk control must communicate why.
Save button
Scenario: An open form or editable fields with a Save button, but without new changes to save.
Recommendation: Display the Save button in a disabled state. This indicates that saving is possible in this context, but is only available once the necessary conditions are met.
Keep position consistent to avoid layout shifts.
Don’t hide the Save button. Keep it discoverable.
Inline row actions
Scenario: A table displays a stand-alone action button at the end of each row (for example, “Accept price” or “Delete”), rather than placing the action inside a dropdown menu. These actions are exposed directly in the row layout.
Recommendation: Hide the button if the action is completed, not applicable, or no longer available. If applicable, use the row’s status or other contextual indicators to communicate the state or completion.
Show the Accept Price button only when a valid recommendation exists.
Keeping the button disabled could mislead users into believing they can somehow enable it, when in reality, its availability depends on the system.
Display the stand‑alone action button only for rows where the action is relevant and available.
Don’t leave a disabled action button on rows where the task can’t be performed. Instead, remove the button entirely.
Task dependencies
Scenario: A user sees a list of tasks that must be completed in a specific order or an action that is blocked until a prerequisite is met.
Recommendation: Show the upcoming step with a lock icon or disabled button, and deactivate the click option. Make the required prior step clear and/or actionable (e.g., "Go to task").
Explain why something is locked and include a link or action to resolve the step, if possible.
Clearly explain why a button is disabled or how to enable it.
Inactive actions
Scenario: Certain elements may not be interactive due to system, time, or business constraints.
Recommendation: Display elements as disabled.
Indicate a date is not available by using the disabled state.
If possible, add a brief inline message or an accessible tooltip to explain why the option is unavailable.
Accessibility Considerations
- Prefer validate-on-submit instead of disabling submit buttons.
- If disabling is unavoidable:
- Use aria-disabled="true" for keyboard and screen reader accessibility.
- Avoid pointer-events: none
- Disabled states often fail color contrast. Don’t rely on their visual appearance alone. Always provide an alternative accessible message explaining why the action isn’t available.
- Add an aria-label for custom components without a native disabled state.
- Disabled elements won’t be readable by screen readers as default, they are skipped. When using tooltips, wrap the element to an additional div, to ensure it’s readable.
Best Practices
- Don’t show controls that the user will never be allowed to use.
- Keep submit buttons enabled, for validation-on-submit.
- Only disable actions that users can unlock by completing a step or meeting a condition.
- Explain why an action is disabled and, when applicable, how to enable it. Prioritize inline help and use accessible tooltips sparingly.
- Avoid disabled buttons for upsell. Use clear upgrade cues tailored to the user’s role, or hide them entirely.
- Disable a specific bulk action when some selected items don’t support the action, and communicate why.
- Show only what’s relevant to keep the UI focused and clear, hide what is not.
- Use the Disabled helper for compositions or elements that don’t provide a native disabled state in code. It applies a muted visual style so the element is clearly perceived as inactive.
Related Patterns
Some topics related to this pattern are not yet fully formalized, but some teams are exploring solutions in these areas. If you encounter these situations or are working on something similar, reach out. We’d love to hear from you and coordinate on how we can formalize them.
Examples include:
- Upgrades / Tiered Access: When to show upgrade buttons, how to communicate tier restrictions, and how to guide users effectively.
- Dependency States: New approaches to visually locking elements when prerequisites or dependencies exist (e.g., tasks blocked until prior steps are complete).