What it is
A single collapsible section — a header a reader clicks to reveal or hide the content beneath it, in place, without leaving or replacing the surrounding page. Several Accordions stacked together form the familiar list-of-expandable-sections pattern, but each one is independent: nothing in source couples one Accordion’s expanded state to another’s.Live example
Exports
Hand-confirmed from source — no prop emitter has run for this component yet.AccordionSummary (the clickable header) and AccordionDetails (the revealed content) are
separate exports from the same package. Accordion does not wrap or re-type them — they are
styled by the same theme override that styles Accordion itself (see Tokens), but
carry no Titan-specific prop interface of their own to hand-confirm here.
Vocabulary
Choose Accordion when
- A section of content is optional reading — a reader can get what they need from the page without opening it.
- Several such sections sit in a list and a reader may want more than one open, or none, at a time.
- The content belongs in place, on the same page, not on a different screen or view.
Choose something else when
Anatomy
Variants, sizes, and states
No size prop exists — an Accordion fills the width of its container. Confirmed states, from the published stories:- Collapsed (default) and expanded — either uncontrolled (
defaultExpanded) or controlled (expanded+onChange). - Disabled — a published story renders a disabled Accordion carrying only a header, no body.
Edge and failure states
- A disabled Accordion with an
AccordionDetailsbody is not demonstrated anywhere. The one published disabled story omits the body entirely, so what a disabled-but-still-expanded Accordion looks like is unconfirmed. - Multiple Accordions with no shared group state is the only pattern in source. Nothing in this component enforces “only one open at a time” — that behavior, if wanted, is the caller’s own state to manage across sibling Accordions.
Tokens
Hand-confirmed fromAccordion.overrides.ts — no per-component token emitter exists yet for
this concept, so this table is hand-confirmed rather than generated. These are theme
registrations keyed to the underlying primitive’s own component names, so they apply regardless
of which export renders it.
Composition
An Accordion is a standalone region — it does not compose intoForm or any other field
pattern. Several stacked in a list is the common composition; nothing in source names or
provides a “group” wrapper for that list, so spacing and grouping between them is left to the
caller.
Content
No copy rules are recorded in source for header or body text.Accessibility
- Confirmed only at the level of what the underlying elements provide natively (a button-like header toggling a revealed region) — no test in source asserts specific ARIA attributes for Accordion itself.
- The published example wires
aria-controlsandidby hand on eachAccordionSummary(panel1a-header/panel1a-content) — nothing in the component does this pairing automatically, so a caller who omits it ships an Accordion with no programmatic link between header and body.
Constraints
Known issues
Accordion: open issues
Divergences, open decisions, and undocumented gaps for Accordion.
Why it works this way
Accordion is a near-zero-value wrapper by design. The component itself is a one-line passthrough; the real Titan-specific behavior — border, spacing, color — lives entirely in the theme override, which is keyed to the underlying primitive’s own component name rather than to this wrapper. That means the styling applies whether or not a caller imports Accordion from this package, which is also why there is no anti-pattern story here the way Dialog has one: there is no competing raw import that would visibly lose styling by bypassing it.Status
No lifecycle metadata exists. There is no
status, since, deprecated, or
replacedBy field on a Titan component, so this table cannot report when an export arrived or
whether it is on the way out.Related
Hand-confirmed fromutilization.md — no utilization emitter has run for this component yet.
12 usages across 5 applications: interaction-details (5), developer-tools (3),
manage-invoca-tags (2), reporting-thoughtspot (1), call-review-flow (1).