Explain missing capabilities rather than hiding them silently

What it is

An explainable unavailable state tells a person who could reasonably expect a capability that it cannot currently be used, what is affected, what they can do next, and which alternative remains, instead of making an entry point or existing content disappear. Explanation does not require publishing every policy, risk, or compliance rule. The interface maps internal server reason codes to minimally sufficient public categories such as “not supported by this account,” “this resource is read-only,” or “cannot be completed right now,” without confirming sanctions status, moderation matches, account existence, geolocation methods, or security thresholds.

Why it happens

Silent hiding disguises a policy decision as an information-architecture change. People may conclude that they forgot the path, lost permission, lost data, or encountered a broken product. Showing every disabled control creates noise and can reveal an unrequestable capability to irrelevant users. The choice depends on expectation and actionability. A capability can be hidden when someone has never qualified, cannot request it, and naming it creates disclosure risk. It should remain visible with explanation when it was previously used, mentioned by a collaborator, attached to an existing object, or recoverable through settings or an administrator. Reason codes separate changing policy from stable copy and let clients offer a consistent path without receiving sensitive details.

Studying it

Test combinations of user expectation, actionability, and disclosure risk for new and existing users, roles, shared-link entry, recent policy changes, and temporary outages. Ask participants what happened, whether content still exists, who can resolve it, and what to do next; measure false attribution, repeated attempts, support contact, abandonment, and successful recovery. Security review should model account enumeration, regional probing, rule discovery, and differential responses, comparing copy, status codes, object existence, timing, and retry behavior. Accessibility testing verifies that keyboard and assistive-technology users can discover the disabled state, reason, and alternative action.

Where it stops holding

“Do not hide silently” does not require every unavailable item to remain in navigation. A control with no actionable value adds burden, while a sensitive capability name or precise denial reason may aid an attacker. Generic security wording must not become a dead end: a legitimate person still needs to know whether to retry, contact an administrator, change a setting, copy or export, or accept that the action is unavailable in the current context. Network failure, insufficient permission, regional policy, and deleted resources remain separate internal codes even when public messages merge them for safety, so controlled logs and support tools can diagnose the case.

Applying it

• Define a stable public model for capability states: title, minimal reason category, affected object, temporary/permanent/unknown status, actionable next step, alternative, and support entry. Separate internal reason codes from public copy and put policy details only in controlled, redacted logs.
• Hide an entry when a person has never seen and cannot request it, or when naming it would disclose sensitive information. If a capability just disappeared, has existing objects, arrived through a shared link, or can be restored, preserve context and show a read-only or disabled state with a next step.
• Preserve unsent input and accessible content after denial, offering a safe draft, copy, export, or alternative flow. If the reason is unknown, say that the action cannot currently be completed and availability cannot yet be determined. Permit safe retry without guessing a region or promising whether or when access will return.
• Check state consistency end to end across web, mobile, notifications, deep links, and API. Test enumeration and differential responses so copy, status codes, timing, and object existence do not reveal sensitive rules, while legitimate recovery remains possible.

Related

• Same group: S3.07.1 Some capabilities are unavailable in particular regions · S3.07.3 Regional restrictions affect cross-region collaboration
• Adjacent: E5.18.1 Unauthorized items may be hidden or shown disabled with a reason · H4.03.2 Explain the degraded path
• Search terms: unavailable state · reason code · secure error disclosure