A disabled state must explain why it is unavailable and how to make it available

What it is

A disabled state commonly uses visual, behavioral, or assistive-technology state to indicate that a control cannot execute now. An effective explainable disabled state does not only say “cannot click.” When needed, it also explains why it is unavailable, which condition is unmet, who or when can change that condition, and what next action is possible. A gray appearance communicates restriction alone, not understanding or recovery.

Why it happens

Seeing an unavailable control, people try to infer a reason: missing input, insufficient permission, network issue, wrong state, or system defect. If reason and recovery condition are absent, they cannot decide whether to complete entry, wait, contact someone, or abandon. Local explanation connects a limit to actionable conditions and shortens diagnosis. Keeping the control visible also communicates that the capability exists, though not currently available.

Studying it

With different reasons for unavailability, ask people to achieve a goal and measure whether they explain the limit correctly, find condition-satisfying steps, estimate availability time, and resume work. Compare gray-only, hover explanation, local message, error summary, and proactive guidance. Test keyboard and screen-reader access: visual gray may not convey state or reason, and a disabled element may not receive focus at all.

Where it stops holding

Not every brief obvious disabled state needs a lengthy explanation; repeated text becomes noise. When people cannot change a condition themselves, such as service maintenance or another person's approval, the system should provide reasonable waiting, notification, or an alternative rather than implying they can solve it. For permanently unsupported capability, a useless disabled control may confuse more than a clear statement of boundary.

Applying it

• Map each reason for unavailability to a concise user-understandable explanation and corresponding next step: add information, change choice, wait, request access, or use an alternative.
• Make reason and activation condition accessible through touch, mouse, keyboard, and screen reader, not color, hover, or an unfocusable control alone.
• Track stuck behavior and help seeking at frequent or critical disabled states, improving condition expression, flow order, or capability instead of endlessly adding prompts.

Related

• Same group: B2.17.1 Anti-affordance actively prevents an action, unlike simply not offering it · B2.17.2 Unexpressed anti-affordance makes users repeatedly try impossible actions · B2.17.4 Hiding to prevent action also damages discoverability of the function
• Nearby: B2.06 Feedback · B2.07 Feedforward
• Search terms: disabled state · activation condition · explainable constraint