Progressive Disclosure Disclosure Affordances

Progressive disclosure: choosing the affordance

Once you've decided what to tuck, the next decision is how to surface it on demand. Different disclosure affordances suit different relationships between the primary and secondary content. Picking the wrong one is a common subtle UX error.

The affordance ladder

Ordered roughly from lightest to heaviest:

Tooltip / popover         — supplementary info; doesn't disturb flow
Inline expand (accordion) — additional fields/sections within the page
Tab                       — parallel views in the same region
Side sheet / drawer       — detail beside primary content
Modal / dialog            — focused interaction, blocks primary
Separate page             — full context shift, deep-linkable

Each level adds friction; pick the lightest affordance that does the job.

Tooltip / popover

For supplementary information that the user might want but doesn't need to act on.

<button>
  Free trial
  <span tabindex="0" aria-describedby="trial-info">ⓘ</span>
</button>
<div id="trial-info" role="tooltip" hidden>
  14 days, no credit card required. Cancel anytime.
</div>

Use for:

• Definitions of jargon.
• Format hints for inputs.
• Explanations of UI labels.
• Status / metadata that isn't worth a separate field.

Don't use for:

• Required interaction (clicking inside a tooltip is fragile).
• Long-form content (tooltips are for small bits).
• Mobile-primary surfaces (no hover; touch tooltips are awkward).

Inline expand (accordion)

The classic disclosure pattern: a section header that expands to reveal its content.

<details>
  <summary>Advanced filters</summary>
  <fieldset>
    <label>Created after <input type="date" /></label>
    <label>Tags <input /></label>
  </fieldset>
</details>

Use for:

• Optional form fields.
• Settings sections that are sometimes relevant.
• FAQ-style content (question = trigger, answer = content).
• Any case where the deeper content makes sense in line with the primary.

Don't use for:

• Content that needs more space than the page can give.
• Content the user must engage with for primary task completion.
• Sequenced content (steps in a workflow — use a separate page or modal).

Tab

Parallel views within the same page region. Switching tabs preserves context (the user is still on the same page; they're just seeing a different facet).

<nav role="tablist">
  <button role="tab" aria-selected="true">Overview</button>
  <button role="tab">Activity</button>
  <button role="tab">Members</button>
  <button role="tab">Settings</button>
</nav>
<div role="tabpanel">...current tab content...</div>

Use for:

• Parallel views of the same object (overview, activity, members for a project).
• Different cuts of the same data (filter by status: All / Open / Closed).
• Configuration sections grouped by purpose.

Don't use for:

• Sequential workflows (tabs imply parallel; use a stepper for sequence).
• Tabs where one is far more important than the others (just show the primary; tuck the rest behind a different affordance).
• Mobile primary nav (mobile bottom-nav is a tab pattern at the global level, but mid-page tabs on mobile are often awkward).

Side sheet / drawer

A panel that slides in beside the primary content, leaving primary visible. Useful for detail-of-an-item interactions where the user wants to see context while they work.

<aside class="sheet" role="complementary">
  <header>
    <h2>Edit invoice #1284</h2>
    <button aria-label="Close">×</button>
  </header>
  <form>...invoice fields...</form>
  <footer>
    <button>Cancel</button>
    <button class="primary">Save</button>
  </footer>
</aside>

Use for:

• Editing a row from a table (the table stays visible; the sheet is the editor).
• Detail views in inboxes (Gmail's preview pane).
• Filters or properties for a selected object (Figma's right panel).

Don't use for:

• Standalone detail views the user might bookmark (use a separate page).
• Long forms that benefit from full-page focus.
• Modal-required interactions (use a true modal).

Modal / dialog

A focused surface that blocks the primary. The user can't continue with primary tasks until they close the modal.

<dialog role="dialog" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Confirm deletion</h2>
  <p>Permanently delete "Q4 plan"? This can't be undone.</p>
  <button>Cancel</button>
  <button class="destructive">Delete</button>
</dialog>

Use for:

• Destructive confirmations.
• Decisions that genuinely block the primary task (you can't continue until you choose).
• Brief, focused interactions (signing in, reviewing a single short form).

Don't use for:

• Long flows that would feel claustrophobic in a modal (use a separate page).
• Information the user might want to reference while continuing work (use a side sheet).
• Trivial confirmations the user will dismiss on autopilot (lean on undo instead).

Separate page

A full URL change. Used when the disclosed content is large enough or important enough to warrant its own context.

Use for:

• Deep settings (Account / Security / Billing).
• Configuration UIs that fill the screen.
• Documentation that benefits from its own URL (shareable, bookmarkable).
• Anything the user might link to or return to directly.

Don't use for:

• Quick edits that should preserve context.
• Optional fields in an existing form.
• Brief decisions / confirmations.

Picking the right affordance

A few diagnostic questions:

Does the user need to keep seeing the primary?

• Yes → tooltip, inline expand, tab, or side sheet.
• No → modal or separate page.

Will the user return to this disclosed content?

• Yes, frequently → separate page (so they can bookmark / link).
• No, just this once → modal or sheet.

Does the disclosed content have its own structure (multiple subsections)?

• Yes → separate page or full sheet.
• No → modal, accordion, or tooltip.

Is the disclosed content a parallel view (vs. a deeper level)?

• Parallel → tab.
• Deeper → accordion or modal.

Does the disclosed content involve a decision the user must make before continuing?

• Yes → modal.
• No → any other affordance.