Expandable row vs Table vs Details panel vs Accordion

Use expandable row for row-local detail inside a table or list; use table for always-visible shared columns, details panel for durable selected-object inspection, and accordion for page-section disclosure.

Expandable row live example Table live example Details panel live example Accordion live example

Learn the decision

Match the interaction to the person's task

Expandable row

Use it when: A row has supplemental detail that is useful for some records but would make the default table or list too dense.

Make this state clear: Collapsed row with row identity, key values, and a labelled expand control.

Observe the result: A reviewer expands a flagged invoice, reads the mismatch reason, copies the audit ID, sorts by amount, and the same invoice remains expanded because state is keyed by invoice ID.

Study the full pattern →

Table

Use it when: Records share comparable attributes that users need to scan in aligned columns.

Make this state clear: Default table state with caption, visible headers, row values, and result count or context.

Observe the result: A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.

Study the full pattern →

Details panel

Use it when: Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.

Make this state clear: Selected-object state with source item highlighted and panel title naming the same object.

Observe the result: A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.

Study the full pattern →

Accordion

Use it when: Section headings provide a useful overview and users can choose which details to inspect.

Make this state clear: All collapsed state with every section title visible.

Observe the result: A user opens Returns, then Warranty, scans both sections, collapses Returns, and the page keeps focus and open-state feedback stable.

Study the full pattern →

Practice the judgment: Imagine this situation: A collapsed row hides the only status reason, so users think every row is equivalent until they manually expand each one. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension	Expandable row	Table	Details panel	Accordion
UI or UX	UI + UX - Row-owned inline detail disclosure inside a table or list	UI + UX - Semantic row-and-column data comparison surface	UI + UX - Persistent selected-object inspection panel	UI + UX - Grouped show-hide sections for related page content
UI guidance	Render an expandable row as a normal data row with a labelled expand control, visible expanded or collapsed state, stable row identity, and an adjacent detail region that visually and programmatically belongs to that row.	Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.	Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.	Render each section title as a real button inside an appropriate heading, expose expanded or collapsed state, and connect the button to the panel it controls.
UX guidance	Use expandable row when users mostly need the compact row list but occasionally need row-local detail to explain, verify, triage, or act on one record in context.	Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.	Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.	Use an accordion when a page has several related sections that users may inspect selectively while still needing an overview of all section labels.
Good UI	An invoice table shows an expand button labelled Show details for INV-2048; the expanded row reveals line items, exception reason, approval history, and a View invoice link below the owning row.	A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.	A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.	A product policy page shows Shipping, Returns, Warranty, and Contact sections as heading buttons with clear expanded states and one open panel.
Bad UI	Every table row has a chevron, but some rows open nothing and others reveal unrelated page help.	Mobile stacking removes headers and turns rows into unlabeled paragraphs.	A panel titled Details shows metrics from the previously selected record after the list selection changes.	Collapsed rows look like navigation links, but clicking them only reveals hidden page text.
Good UX	A reviewer expands a flagged invoice, reads the mismatch reason, copies the audit ID, sorts by amount, and the same invoice remains expanded because state is keyed by invoice ID.	A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.	A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.	A user opens Returns, then Warranty, scans both sections, collapses Returns, and the page keeps focus and open-state feedback stable.
Bad UX	Filtering a queue keeps the third visual row open after the data changes, exposing details for a different customer.	Mobile stacking removes headers and turns rows into unlabeled paragraphs.	Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.	A user misses eligibility requirements because the only required step is hidden inside a collapsed section by default.
Best fit	A row has supplemental detail that is useful for some records but would make the default table or list too dense.	Records share comparable attributes that users need to scan in aligned columns.	Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.	Section headings provide a useful overview and users can choose which details to inspect.
Avoid when	The hidden data is a core column users must compare across rows.	The task depends on rich previews, imagery, or uneven metadata.	The content is just a short temporary preview before navigation.	There is only one revealable section and a simpler details disclosure is enough.
Required state	Collapsed row with row identity, key values, and a labelled expand control.	Default table state with caption, visible headers, row values, and result count or context.	Selected-object state with source item highlighted and panel title naming the same object.	All collapsed state with every section title visible.
Accessibility burden	Use a real button or native disclosure control for expansion and expose expanded or collapsed state.	Use native table semantics for tabular data rather than div-only rows.	Name the panel region from the selected object's title or a heading that includes the object identity.	Use native buttons for section controls and expose expanded or collapsed state.
Common misuse	Hiding primary columns or required decision data inside collapsed detail.	Using table markup to create page columns or layout spacing.	Keeping the previous ticket summary in the persistent panel after the highlighted row has moved to a different ticket.	Hiding content users must read sequentially before completing a task.

Expandable row

UI or UX: UI + UX - Row-owned inline detail disclosure inside a table or list
UI guidance: Render an expandable row as a normal data row with a labelled expand control, visible expanded or collapsed state, stable row identity, and an adjacent detail region that visually and programmatically belongs to that row.
UX guidance: Use expandable row when users mostly need the compact row list but occasionally need row-local detail to explain, verify, triage, or act on one record in context.
Good UI: An invoice table shows an expand button labelled Show details for INV-2048; the expanded row reveals line items, exception reason, approval history, and a View invoice link below the owning row.
Bad UI: Every table row has a chevron, but some rows open nothing and others reveal unrelated page help.
Good UX: A reviewer expands a flagged invoice, reads the mismatch reason, copies the audit ID, sorts by amount, and the same invoice remains expanded because state is keyed by invoice ID.
Bad UX: Filtering a queue keeps the third visual row open after the data changes, exposing details for a different customer.
Best fit: A row has supplemental detail that is useful for some records but would make the default table or list too dense.
Avoid when: The hidden data is a core column users must compare across rows.
Required state: Collapsed row with row identity, key values, and a labelled expand control.
Accessibility burden: Use a real button or native disclosure control for expansion and expose expanded or collapsed state.
Common misuse: Hiding primary columns or required decision data inside collapsed detail.

Table

UI or UX: UI + UX - Semantic row-and-column data comparison surface
UI guidance: Render a table with a specific caption or heading, visible column headers, optional row headers, aligned values, consistent row actions, and enough spacing for scanability.
UX guidance: Use tables when aligned columns help users compare records, find exceptions, audit values, or triage work faster than opening each item.
Good UI: A payment review table has the caption June vendor payments, headers Vendor, Status, Due date, Amount, and Action, right-aligned amounts, and row actions labelled by vendor.
Bad UI: Mobile stacking removes headers and turns rows into unlabeled paragraphs.
Good UX: A user sorts by Amount descending, filters to Pending, moves to page 2, and the table keeps its caption, active sort, active filter, row count, and selected payment context.
Bad UX: Mobile stacking removes headers and turns rows into unlabeled paragraphs.
Best fit: Records share comparable attributes that users need to scan in aligned columns.
Avoid when: The task depends on rich previews, imagery, or uneven metadata.
Required state: Default table state with caption, visible headers, row values, and result count or context.
Accessibility burden: Use native table semantics for tabular data rather than div-only rows.
Common misuse: Using table markup to create page columns or layout spacing.

Details panel

UI or UX: UI + UX - Persistent selected-object inspection panel
UI guidance: Render a details panel as a persistent side or adjacent region that names the currently selected object, shows high-value metadata, status, and local secondary actions, and keeps the object selection visible in the source list, table, map, board, or feed.
UX guidance: Use a details panel when users need to select and compare nearby objects while keeping a durable inspection area visible, such as reviewing records, tickets, assets, alerts, comments, files, or map locations.
Good UI: A ticket queue keeps TCK-2048 selected in the list and shows a right details panel with requester, severity, SLA, owner, activity, and Open full ticket.
Bad UI: A panel titled Details shows metrics from the previously selected record after the list selection changes.
Good UX: A keyboard user moves down a ticket list, the highlighted row and details panel update together, and focus remains in the list until the user chooses Open full ticket.
Bad UX: Sorting the list silently clears the highlighted row while the panel continues to show an old ticket.
Best fit: Users repeatedly inspect selected records, tickets, alerts, files, assets, tasks, comments, or locations while staying in a work surface.
Avoid when: The content is just a short temporary preview before navigation.
Required state: Selected-object state with source item highlighted and panel title naming the same object.
Accessibility burden: Name the panel region from the selected object's title or a heading that includes the object identity.
Common misuse: Keeping the previous ticket summary in the persistent panel after the highlighted row has moved to a different ticket.

Accordion

UI or UX: UI + UX - Grouped show-hide sections for related page content
UI guidance: Render each section title as a real button inside an appropriate heading, expose expanded or collapsed state, and connect the button to the panel it controls.
UX guidance: Use an accordion when a page has several related sections that users may inspect selectively while still needing an overview of all section labels.
Good UI: A product policy page shows Shipping, Returns, Warranty, and Contact sections as heading buttons with clear expanded states and one open panel.
Bad UI: Collapsed rows look like navigation links, but clicking them only reveals hidden page text.
Good UX: A user opens Returns, then Warranty, scans both sections, collapses Returns, and the page keeps focus and open-state feedback stable.
Bad UX: A user misses eligibility requirements because the only required step is hidden inside a collapsed section by default.
Best fit: Section headings provide a useful overview and users can choose which details to inspect.
Avoid when: There is only one revealable section and a simpler details disclosure is enough.
Required state: All collapsed state with every section title visible.
Accessibility burden: Use native buttons for section controls and expose expanded or collapsed state.
Common misuse: Hiding content users must read sequentially before completing a task.

Decision rules

Choose expandable row when each visible row already identifies a record and users need occasional row-owned details, history, exceptions, nested attributes, or secondary actions without leaving the data surface.
Choose table when the values are important enough to compare across many records and should remain visible as columns rather than hidden under each row.
Choose details panel when users repeatedly move through records and need a persistent inspector that stays visible beside the source rows instead of expanding one row at a time.
Choose accordion when the content is page-level sections or form groups, not detail owned by a specific table, list, or activity row.
Use expandable row for compact supplemental content; route to details panel, drawer, or full page when the expanded area needs long reading, deep editing, comments, history, or several unrelated panels.
Keep row expansion state keyed by stable record ID so sorting, filtering, pagination, refresh, or virtual loading does not open detail under the wrong row.
Expose a labelled row expand control with expanded state, affected row identity, and a content region that follows the owning row in reading order.
Do not put the only critical decision value, required error, destructive confirmation, or primary action inside a collapsed row unless the collapsed row summarizes it visibly.
When rows have no extra detail, omit or disable the expand control with a visible reason rather than showing a dead chevron.
On mobile, use stacked expanded detail, row-level disclosure, or a full-detail route instead of forcing a wide nested table that loses row-header meaning.

Inspect live examples

Expandable row Table Details panel Accordion

Failure modes

A collapsed row hides the only status reason, so users think every row is equivalent until they manually expand each one.
Sorting the table leaves the second visual row expanded even though the detail belongs to a different record after the sort.
Every row has an expand chevron, including rows with no extra detail, causing dead controls and false affordances.
Expanded content contains a long form, nested table, comments, attachments, and destructive actions that no longer fit a row-local disclosure.
A page-level FAQ or settings section is implemented as expandable table rows even though no row owns the content.
The expand button only says More, has no expanded state, and does not identify which record will be opened.

Expandable row vs Table vs Details panel vs Accordion

Match the interaction to the person's task

Expandable row

Table

Details panel

Accordion

Workbench Context

Decision dimensions

Expandable row

Table

Details panel

Accordion

Saved items