First-pass proposal, not established policy. No audited Invoca screen backs this page —
Titan’s design library was not available while writing it. It is built from general
interaction-design practice and from what Accordion
already establishes. Treat every threshold below as a starting point to check against real
product screens, not as a rule already enforced.
The problem
Every screen accumulates options over time: a filter someone asked for once, an advanced field
that matters for one integration, a setting nine out of ten accounts never touch. Show all of
it and the page a new user opens looks nothing like the task they came to do. Hide too much of
it, or hide the wrong thing, and the interface has quietly removed a control people actually
need — which is worse than cluttering the page, because a hidden-but-needed setting reads as
“not supported” rather than “one click away.”
Progressive disclosure is not a single control. It is a decision about scope — how much of the
page is affected by hiding something — made three different ways depending on that scope: a
text link revealing a few more rows of the same list, a collapsible section holding a
self-contained block of secondary content, or an entirely separate area reached by its own
navigation. Treating all three as interchangeable is how a setting that deserved its own tab
ends up buried one click inside an accordion, or a two-field toggle gets promoted to a whole
settings screen nobody needed.
Decide first: how much of the page is affected?
The heuristic is testable, not a vibe. Before disclosing anything, name who uses it and how
often: “used by fewer than X% of accounts, in fewer than Y% of their sessions” is a claim
someone can check against real usage. “This feels advanced” is not.
When this applies
- The content is genuinely secondary or advanced, by the heuristic above — not merely “would
make the page shorter.”
- Hiding it does not remove the only way to discover that the capability exists at all.
When it doesn’t
Structure
Behavior
Constraints
Content
Accessibility
A collapsed section is not a hidden one — it is a keyboard- and screen-reader-operable
control that happens to be closed. The trigger must be reachable by keyboard and must state,
in its accessible name, what it reveals — not “toggle” or “expand,” which say nothing about the
content.
Accordion’s own documentation does not confirm that aria-expanded is set automatically on
the trigger. Its accessibility section states only what the underlying elements provide
natively, with no test asserting specific ARIA attributes. Verify this at the call site rather
than assuming the component supplies it — the same caution that produced
TITAN-DISCLOSE-05 for aria-controls and id.
A validation error inside a collapsed section must force it open, and must be announced.
A screen-reader user who submits a form and hears nothing, because the only invalid field is
inside a section that stayed collapsed, has no path to the problem — see
Form validation.
Variations
Anti-patterns
Disclosure as camouflage for a setting most people need. Burying a control the majority of
users touch in most sessions behind a collapsed accordion doesn’t simplify the page — it moves
the complexity from “visible” to “undiscoverable,” which is worse.
A chevron with no label. An icon-only trigger asks the reader to open something before
telling them what it is. The label is what lets them decide whether opening it is worth the
click.
A validation error hidden inside a collapsed section. A form that reports “something is
wrong” without opening the section containing the actual invalid field sends the reader hunting
through every collapsed area to find it.
Reinventing “only one open at a time” per screen. Accordion ships with no group behavior,
so every list of mutually exclusive sections either gets this built fresh or gets left without
it — a smaller version of the same duplication
TITAN-GAP-31 records for
skeleton screens.