Progressive disclosure
======================

Spec: descriptive guidance, not a checkable rule.
It carries no forbidden and instead pair, and no `jig check` detector applies to it directly.
Section: Components and layout

Reveal information as it is needed rather than all at once. Costs an interaction; buys a large reduction in cognitive load. Use it where most users need only part of the content.

**Anatomy:** visible summary → labelled control → disclosed content, adjacent and in flow.

**Rules**
- The control is **descriptively labelled**. "Benefits of a custom domain", not "Read more". It must make sense read aloud out of context, because screen readers announce links and buttons in isolation.
- Disclosed content appears **next to its trigger**, not elsewhere on the page. Content that opens where the user is not looking has not been disclosed.
- State is visible: the control shows whether the content is open or closed.
- Use `<details>`/`<summary>` unless you need behaviour they cannot express (`H-48`). Keyboard, screen-reader and no-JS support come free.
- **Conditional fields are opt-in, not optional.** A "Mobile number" field revealed by ticking "Receive updates by text" is simpler than a permanently visible optional field — people who do not want it never see it, and people who do get a required field with an obvious reason.
- **Never hide with it what `E-63` requires visible.** Progressive disclosure is for depth, not for labels, selected states or primary actions.

**Mode variance:** `operator` discloses least. For daily users, one dense visible view beats a tidy one that hides what they came for.