SaaS Accordion & Collapsible UX: Real Screenshots & UX Patterns (2026)
The accordion is the pattern a SaaS product reaches for when a screen has more than a person needs to see at once — a settings page with a dozen sections, a pricing FAQ, a sidebar of nested groups, a table row hiding its detail — and it is one of the most quietly abused patterns in the interface. Used well, an accordion is progressive disclosure done right: it shows the shape of everything available while keeping the detail folded away until asked for, so a long page reads as a short, scannable list of choices. Used badly, it hides things people needed to see, buries the one setting they came for behind an unlabelled twisty, animates so slowly that opening three sections feels like a chore, forgets which sections were open the moment you navigate away, and collapses content that should never have been collapsible in the first place. This guide separates the jobs an accordion is actually asked to do and walks the patterns that make each one usable: when to collapse content at all versus leave it visible, single-open versus multi-open behaviour, honest expand/collapse affordances, preserving state, animating with restraint, deep-linking into a section, and the accessibility a disclosure widget owes keyboard and screen-reader users — each shown with real SaaS screenshots instead of mockups.
The accordion is the pattern a product reaches for the moment a screen has more on it than a person needs to hold at once. A settings page with a dozen sections, a pricing page with twenty FAQs, a sidebar grouping projects inside teams inside workspaces, a table row that hides a payload of detail — behind each is more content than belongs in a single scroll, and the accordion is the interface saying "here is the shape of everything; open what you need." Done with care, a collapsible section list is progressive disclosure at its best: the person sees every option as a scannable heading, understands the full scope of the page at a glance, and pulls detail into view only when a heading is relevant to them. A forty-field settings page becomes a tidy list of eight nameable groups. That is the promise. Accordions are worth studying precisely because the same fold that tames a long page can, applied carelessly, hide the one thing someone came for and turn a simple lookup into a hunt.
Microsoft Teams — a real settings screen from the SaaSUI library.
The failure modes are specific and everywhere. Content collapsed that should have stayed visible — a critical warning, a primary action, a field most people edit every visit — now costs a click and a guess to reach. A twisty with no label, or a chevron pointing an ambiguous direction, so the person cannot tell what is inside or whether it is currently open. An accordion that only allows one section open at a time on a page where people genuinely need to compare two, so opening the second silently slams the first. State that resets on every visit, forcing the same person to re-open the same three sections every single time. Animation so slow or bouncy that expanding a few sections feels like waiting on a slideshow. And the deep-linked or searched-for setting that lives inside a collapsed section the page never bothers to open, so the person lands on the right page and still cannot see the thing. This guide walks the patterns mature products use to keep collapsible interfaces honest, fast, and genuinely helpful — starting with the decision that prevents most accordion problems, and each shown with real SaaS screenshots so you can see how shipped tools actually handle them.
First, decide whether it should collapse at all
The decision that prevents most accordion problems happens before any twisty exists: does this content actually benefit from being folded away, or are you hiding something people need? Collapsing is worth it when a page has many peer sections a given person only cares about a few of at a time — settings groups, a long FAQ, nested navigation, optional advanced options — so that showing everything expanded would read as an overwhelming wall and force endless scrolling. It is the wrong move when the content is something most visitors came to see or act on: a primary action, a critical status or warning, the one field people edit on nearly every visit, or a short amount of content that would have fit comfortably on screen anyway. Hiding those behind a fold does not reduce cognitive load; it adds a click and a memory test ("which section was billing under?"). A good heuristic: collapse content that is optional, secondary, or only relevant to some people, and keep visible the content that is primary, urgent, or near-universal. When a page is genuinely long and sectioned, the accordion earns its place; when it is merely a bit longer than average, folding it usually costs more than it saves. Get this decision right and most of the other accordion pitfalls never arise.
Single-open vs multi-open: match the behaviour to the task
Once you commit to collapsible sections, the next decision shapes how the whole thing feels: can several sections be open at once, or does opening one close the others? Single-open (classic accordion) behaviour — where expanding a section auto-collapses the previously open one — suits content where people genuinely look at one thing at a time and comparing across sections is not the point: a linear FAQ, a set of mutually exclusive choices, a compact space where two open panels would overflow. Its virtue is tidiness; its cost is that it fights anyone who wanted to see two sections together, silently collapsing work or context the moment they open the next. Multi-open (independent collapsibles) — where each section toggles on its own and any number can be open together — suits the far more common case where people compare, cross-reference, or work across sections: a settings page where you tweak billing and notifications in one sitting, a long document outline, nested navigation you want expanded down two branches at once. The trap is choosing single-open by reflex (it is the "accordion" default in many component libraries) on content that is really multi-open in spirit, then frustrating people whose first collapsed section vanishes when they open the second. Decide by asking whether people will ever want two sections open at the same time; if the honest answer is yes, make sections independent. When in doubt, multi-open is the safer default — it never destroys the state the person is looking at.
Make the affordance honest: is it collapsible, and is it open?
An accordion only works if people can tell, at a glance, that a heading can be expanded and whether it currently is — and this is where cheap implementations quietly fail. Every collapsible header needs a clear, consistent affordance that it is interactive: a chevron or plus/minus, a header styled as a control rather than plain text, a whole-row hit target that is obviously clickable, not a tiny icon people have to aim at. The state must be equally legible: the same control should change to signal open versus closed — a chevron that rotates from pointing-right (closed) to pointing-down (open), a plus that becomes a minus — following the convention people already expect rather than inventing a private one. The anti-patterns are common: a twisty whose direction is ambiguous so nobody can tell if the section is open, a header that looks like static text so people never realise it expands, an icon-only toggle with a hit target so small it is a game of darts, or inconsistent affordances across the same page so one section uses a chevron and another a link. Labelling matters too: the header should name what is inside ("Billing & invoices", "Advanced options") so the person can decide whether to open it without opening it — an accordion of vague or generic headers forces the very click-hunting it was meant to prevent. A good collapsible header answers two questions before it is touched: what is in here, and is it open right now.
Preserve state — remember what the person opened
People open the sections that matter to them, and a collapsible interface that forgets those choices makes them redo the same work on every visit. The pattern that respects their effort is persistence: when someone expands the sections they care about, those sections should stay expanded as they interact with the page, and ideally remain remembered across visits so a person who always works in "Notifications" and "API keys" is not re-opening them daily. Within a session this is non-negotiable — an accordion that collapses a section the moment you click something inside it, or resets when the page re-renders, feels broken. Across sessions it is a strong courtesy for pages people return to often (settings, dashboards with collapsible panels, navigation trees): remember the last state so the interface greets them the way they left it. Related is the question of sensible defaults on first arrival: decide deliberately what is open when a new person lands — often the first or most important section, or the section a deep-link or search pointed at — rather than defaulting everything closed and dropping the person onto a page of unlabelled folds with no starting point. The failure mode to avoid is the amnesiac accordion: it offers control over what is visible, then throws that control away on every navigation, so the person never feels the page is theirs. State is memory, and memory is respect for the fact that they already told you what they wanted to see.
Animate the expand and collapse with restraint
The motion of opening and closing a section is small, but it is felt on every single interaction, so getting it wrong taxes people constantly. A short, smooth height transition helps: it shows the person which section changed and where the new content came from, so the page does not appear to teleport. But the emphasis is on short and smooth — a slow expand that makes people wait to read what they just asked for, an exaggerated bounce or spring, or a jarring content-reflow that shoves everything below it makes a routine toggle feel heavy and unserious. The guidance mirrors a broader animation principle: motion should clarify a change, not perform for attention, and animating everything at maximum drama makes an interface feel slower than one that moves quickly and gets out of the way. Keep the duration tight, ease it naturally, and make sure opening several sections in a row never turns into a queue of animations the person is waiting on. Respect reduced-motion preferences by toning the transition down or removing it for people who have asked for less animation. And beware layout jank: when a section expands, the content below should move predictably rather than jumping, and the header the person just clicked should stay where they can see it rather than scrolling out of view. The best accordion animation is one people barely notice — it confirms the fold opened and then disappears, leaving them reading the content, not watching the transition.
PandaDoc — a real settings screen from the SaaSUI library.
Let people link, search, and scroll straight to a section
An accordion that hides content behind a fold has a special obligation: when someone is sent to a specific section — by a deep link, an in-page search, an anchor, a "jump to" from elsewhere — the interface must open that section and bring it into view, not just quietly rank the right page while leaving the answer collapsed. The most common broken experience is landing on the correct settings or FAQ page from a search result or a support link and still not seeing the thing, because it lives inside a section the page left closed. Mature products handle this: a URL anchor or deep link expands the target section and scrolls to it; an in-page find or filter opens any collapsed section that contains a match rather than hiding matches inside folds; and a "search settings" box that surfaces a result reveals it in context. This matters for SEO and answer engines too — content permanently hidden behind an unexpanded accordion is content people (and sometimes crawlers) struggle to reach, so the fold should be a convenience for scanning, never a vault that swallows the very answer someone navigated to find. The rule is simple: if a person can be pointed at a section, the section must open itself when they arrive. An accordion that cannot be deep-linked, searched into, or scrolled to turns a helpful fold into a dead end at exactly the moment the person is closest to what they wanted.
Make the disclosure accessible to everyone
A collapsible section is a disclosure control, and treating it as one for people who do not use a mouse is where a lot of otherwise-tidy accordions fall down. The header that toggles a section must be a real, focusable control — a button, reachable and operable by keyboard (Enter/Space to toggle), not a bare div that only responds to a click. Its expanded-or-collapsed state must be conveyed to assistive technology, not signalled by the chevron rotation alone, so a screen-reader user knows whether the section is open before deciding to enter it, and the control and the region it controls should be associated so the relationship is announced rather than left visual. Focus order should be sensible: tabbing moves through headers predictably, and expanding a section should not trap focus or fling it somewhere surprising. Never rely on colour or icon alone to convey open state — pair it with a programmatic state and, ideally, a text or shape change. And remember that content hidden in a collapsed section should be genuinely inert to assistive tech and keyboard tabbing while closed, so people are not tabbing into invisible fields. The through-line of every pattern in this guide is respect for the person’s effort — their time, their attention, their intent to reach a specific thing — and accessibility is that respect extended to everyone, including the people for whom a mislabeled twisty or a non-focusable header is not a minor annoyance but a locked door.
The details that separate a helpful accordion from a hiding place
Each decision above is simple on its own; a collapsible interface feels trustworthy when they are handled together. These are the behaviours mature SaaS settings pages, FAQs, navigation trees, and expandable tables share.
- Content is collapsed only when it is optional, secondary, or relevant to some people — primary actions, urgent status, and near-universal fields stay visible rather than folded behind a click.
- Open behaviour matches the task: single-open where people look at one thing at a time, multi-open (independent sections) wherever they might want two sections open together — with multi-open as the safe default because it never destroys visible state.
- Every collapsible header reads as an interactive control with a generous hit target, a clear open/closed affordance (rotating chevron, plus/minus), and a label that names what is inside so people can decide without opening.
- State is preserved: expanded sections stay open through interaction (and ideally across visits), first-arrival defaults are chosen deliberately, and the accordion never collapses a section out from under the person.
- Expand/collapse animation is short, smooth, and unobtrusive, honours reduced-motion, and avoids bounce, slowness, and layout jank that shoves content or scrolls the clicked header out of view.
- Sections are reachable directly: deep links, anchors, and in-page search open and scroll to the target section rather than leaving the answer collapsed on the correct page.
- The disclosure is accessible: headers are real focusable buttons operable by keyboard, open/closed state is exposed to assistive tech, focus order is sensible, and collapsed content is inert to tab and screen reader.
Common SaaS accordion & collapsible mistakes
- Collapsing content people actually came for — a primary action, a critical warning, or a field edited on nearly every visit — so a routine task now costs a click and a guess.
- Ambiguous affordances: a header that looks like static text, a chevron whose direction does not clearly signal open vs closed, or an icon-only toggle with a hit target too small to aim at.
- Forcing single-open behaviour on content people need to compare, so opening a second section silently slams the first shut and loses their place.
- An amnesiac accordion that resets to all-closed (or re-collapses) on every visit or re-render, making people re-open the same sections endlessly.
- Slow, bouncy, or janky expand/collapse animation that makes a small, frequent interaction feel heavy — and ignoring reduced-motion preferences.
- Deep links, anchors, or in-page search that point at a section the page then leaves collapsed, so the person lands on the right page and still cannot see the answer.
- Generic or unlabelled headers ("Section 1", "More") that force the very click-hunting the accordion was meant to prevent.
- Headers that are not real focusable controls, open state that is signalled only by a rotating icon, and collapsed content that keyboard and screen-reader users can still tab into.
Frequently asked questions
When should you use an accordion instead of showing everything?
Use an accordion when a page has many peer sections a given person only cares about a few of at a time — settings groups, a long FAQ, nested navigation, optional advanced options — so that showing it all expanded would read as an overwhelming wall and force endless scrolling. The accordion lets people see the shape of everything as scannable headings and pull only the relevant detail into view. Do not collapse content that is primary, urgent, or near-universal: a main action, a critical status or warning, or the one field most people edit every visit belongs on screen, because hiding it adds a click and a memory test rather than reducing load. A useful test: collapse the optional, secondary, or only-relevant-to-some content, and keep visible the primary, urgent, or nearly-everyone content. And if a page is only a little longer than average — a handful of fields that would have fit on screen — folding it usually costs more than it saves. The accordion earns its place on genuinely long, sectioned pages; it is a poor reflex for merely tidy-looking ones.
Should an accordion allow one section open at a time or several?
Match the behaviour to whether people ever want two sections open together. Single-open (opening one auto-collapses the last) suits content viewed one item at a time — a linear FAQ, mutually exclusive choices, or a cramped space where two open panels would overflow — and its virtue is tidiness. But it actively fights anyone comparing or cross-referencing, silently collapsing context the moment they open the next section. Multi-open (each section toggles independently, any number open at once) suits the far more common case: a settings page you tweak across several groups in one sitting, a document outline, nested navigation expanded down two branches. The frequent mistake is choosing single-open by reflex because it is the library default, then frustrating people whose first section disappears when they open a second. Decide by asking whether anyone will realistically want two sections open at the same time; if yes, make sections independent. When unsure, prefer multi-open — it is the safer default because it never destroys the state the person is currently looking at.
How do you keep content in an accordion findable for search and deep links?
Make sure any way of pointing at a section also opens it. When a deep link, URL anchor, in-page search, or "jump to" targets a specific section, the interface must expand that section and scroll it into view rather than leaving the answer collapsed on an otherwise-correct page — the classic broken experience is landing on the right settings or FAQ page from a search result and still not seeing the thing because its fold stayed closed. Practically: URL anchors should expand and scroll to their target; an in-page find or a "search settings" box should reveal matches by opening any collapsed section that contains them, not hide results inside folds; and defaults on first arrival should open the most relevant section rather than dumping the person onto all-closed folds. This also matters for SEO and answer engines, since content permanently buried behind an unexpanded accordion is hard for people and sometimes crawlers to reach — so treat the fold as a convenience for scanning, never a vault that swallows the answer. The rule: if a person can be pointed at a section, the section must open itself when they arrive.
Study real SaaS accordions & collapsible UI in the SaaSUI library
Every pattern above is easier to apply when you can see how real products solved it. Browse real settings pages, pricing FAQs, nested navigation trees, and expandable table rows — honest expand/collapse affordances, multi-open sections that preserve state, deep-linkable folds, restrained animation, and accessible disclosure controls — from shipped SaaS applications like Linear, Notion, Stripe, Asana and other settings- and content-heavy tools in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products turn a long, dense page into a short, scannable list of choices without hiding the things people actually came for.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →