Expansion Panels in Application UI: When to Use Them and How to Make Them Accessible

Expansion panels are sections of an interface whose content can be revealed or hidden with a labeled control. They help when people need an overview first and only some details at a time. They hurt when closing a section conceals the instructions, controls, or comparisons required for the task at hand. Before we choose a component, we should decide what stays visible, whether several sections can be open together, and what happens to focus and entered data when one closes.

In a dashboard, that might mean keeping a report’s status and date visible while putting rarely used audit filters behind a panel. In a form, it might mean leaving required fields and validation feedback in view while making optional preferences collapsible. The interaction is simple to draw; making the content discoverable and the state predictable takes more care.

Table of contents

• What is an expansion panel?
• When do expansion panels improve a screen?
• When should content remain visible?
• Choose the disclosure behavior before the component
• Define the states before building the interaction
• The accessibility contract: trigger, state, and keyboard
• Native disclosure or a component library?
• Make panels work in responsive dashboards and forms
• A practical review before shipping
• Frequently asked questions
  • Are expansion panels and accordions the same thing?
  • Should all panels start closed?
  • Can a closed panel contain form fields?
• Put the decision into your next UI review

What is an expansion panel?

An expansion panel has a persistent header or trigger and a content area that appears below it when expanded. Some design systems call the same unit an accordion item. The distinction worth preserving is behavioral: a single independent show/hide control is a disclosure; a vertically stacked group of interactive section headings is typically an accordion. “Expansion panel” often describes the visual unit in either arrangement. The W3C disclosure pattern and accordion pattern document their related, but distinct, interaction contracts.

A panel is not a drawer, which usually opens a separate side surface, or a tab, which switches the displayed section without pushing the content below it down the page. A collapsible navigation sidebar is another layout pattern, not simply a group of expansion panels. These distinctions matter when we choose default states and keyboard behavior. If a user needs to compare two sections at once, for example, a single-open tab or accordion can make that work harder. The GOV.UK Design System guidance explicitly considers whether people need to view multiple sections together when selecting a pattern.

When do expansion panels improve a screen?

The best candidate is secondary, self-contained information with a recognizable label. Think of a reporting dashboard that always shows the selected date range, report status, and primary action. An “Audit options” panel can hold infrequently changed filters without obscuring the current report. A header that says only “More” would not give the same clue about what is inside.

Panels can also organize repeated entities: each customer row retains a name, status, and brief summary, while its longer history opens on demand. Temenos’s expansion-panel usage guidance describes the value of meaningful identifiers and short collapsed summaries that spare people unnecessary expansion. That is more useful than collapsing everything to an identical chevron.

The screen still needs to work before anything opens. We recommend checking that a person can identify each section, understand whether action is needed, and complete the primary task from the visible surface. If every panel must be opened to learn where to start, the interface has hidden its hierarchy instead of improving it.

When should content remain visible?

Keep information in view when hiding it would make a person miss a requirement or repeatedly interrupt their work. Examples include a form’s required fields and error summary, a warning that changes the meaning of a primary action, and two values a reviewer must inspect side by side. Collapsing the only explanation of an unfamiliar control is especially risky: the person who needs the explanation may not know where to look for it.

For forms, separate optional settings from the current required step. If a validation error occurs inside a closed panel, surface that fact in the visible header and make it possible to reveal and reach the field. Never treat a closed section as permission to discard values the user has entered. In a long review screen, expanding all sections or leaving comparison rows visible may be better than forcing a series of open-close operations.

Start by trying clear headings and tighter copy on an always-visible page. GOV.UK’s accordion guidance advises against hiding content everyone needs and recommends testing a simpler content layout before introducing an accordion. A panel earns its place by making a real task easier, not by making a mockup shorter.

Choose the disclosure behavior before the component

The choice is not “accordion or nothing.” Use the question What must the user see or compare right now? to choose the smallest behavior that fits.

A single-open accordion does not automatically mean one item must stay open. Decide separately whether all items may close. If the interface requires one open section, communicate that rule through consistent behavior; do not make an expanded header look clickable and then silently ignore it. When several sections need to remain visible for comparison, allowing multiple open items is often the more natural choice. The W3C accordion pattern describes both collapsible and required-open variants.

Define the states before building the interaction

A useful panel contract goes beyond an open Boolean. Write down what users will see and what the application will do in each state:

• Collapsed: the trigger, section label, and any essential summary or alert remain visible. Controls inside the hidden content are not reachable by Tab.
• Expanded: the header signals the open state, the content becomes available, and ordinary focus order reaches its controls.
• Unavailable: if a section genuinely cannot open, explain why. Often removing the empty section or allowing it to open with an explanation is clearer than a disabled trigger. GOV.UK’s guidance cautions against disabled accordion sections.
• Updated: if a status changes or validation fails while the content is closed, update the visible summary and provide a route to the affected content. Do not assume a visual color change alone conveys the update.
• Re-rendered: if filtering removes an open item or navigation restores a screen, define what happens to its state, focus, and unsaved form values.

These are product decisions, not magic component defaults. For a repeatable dashboard, we might remember which reporting sections were open during the current session. For a safety-critical warning, we would show the warning regardless of remembered preference. The GOV.UK accordion implementation documents both initially open sections and session-level state persistence, illustrating why an application’s default and persistence choices should be explicit.

A separate edge case is closing a panel that currently contains keyboard focus. Before hiding it, return focus to the controlling trigger or another predictable visible target. Otherwise the next keystroke may start from a location the user can no longer see. Test this in the actual application, especially when closing can happen through a form submission, filtering, or a single-open group changing state.

The accessibility contract: trigger, state, and keyboard

For a custom accordion, put a real <button type="button"> inside a heading at the appropriate level, and make the button the heading’s only child. Give it a useful visible name such as “Audit options,” not “Expand.” Connect it to the content element with aria-controls and keep aria-expanded synchronized with the content’s actual visibility. The W3C accordion authoring pattern spells out those semantics, along with the optional region and aria-labelledby pairing for content panels. Avoid adding region to every item in a large, multi-open set; too many landmarks make navigation noisy.

A native button gives us Enter and Space activation. Tab and Shift+Tab move through the normal focus sequence, including the controls of an open panel. The accordion pattern lists arrow-key movement between headers as optional, not a baseline requirement. If we add it, we need to implement and test it consistently; it does not replace Tab. When a required-open panel cannot be collapsed, the W3C pattern describes aria-disabled="true" on its header button. That is a different situation from a product section being unavailable because it has no content.

A standalone disclosure needs a button with an accurate expanded state, but it does not automatically need the full grouped-heading behavior of an accordion. The W3C disclosure guidance specifies button activation with Enter and Space and a synchronized aria-expanded value. Whatever the pattern, the visible chevron should reinforce the state, not be its only accessible signal.

For a visual walk-through of keyboard considerations, watch this independently produced demonstration of an accessible accordion, then compare its behavior against the W3C pattern rather than assuming any video is a substitute for testing.

Native disclosure or a component library?

For one simple optional section, native <details> with a descriptive <summary> may be enough. It supplies built-in disclosure behavior without custom state wiring. MDN’s <details> documentation also describes its open attribute and the shared name attribute for a one-open-at-a-time group. Test styling and assistive-technology behavior in your supported browsers rather than assuming a visually customized summary behaves identically everywhere.

Choose an application component when panels need a documented group policy, application-owned state, consistent styling hooks, or integration with complex form content. In DOM Studio, our headless Accordion reference shows a dom-accordion grouping dom-accordion-item children with header and content slots; its documented multiple attribute permits several items to remain open. The Vue Accordion component shows an items prop and a multiple option. Those references are implementation starting points, not evidence that every edge case in this guide is handled automatically. Verify your chosen build’s initial state, focus behavior, hidden content, and event integration in the screen where you use it.

If JavaScript controls a custom accordion, decide what the page displays before the component initializes. The U.S. Web Design System’s accordion guidance keeps content available when its JavaScript does not run, then lets the component manage collapsed states on initialization. Native <details> offers a different progressive baseline because disclosure works without your application script. Avoid an intermediate state where controls appear collapsed but their fields remain keyboard-reachable.

Make panels work in responsive dashboards and forms

A compact viewport changes the consequences of expansion. A long open panel can push the next task far below the fold, while two side-by-side panels that work on desktop may need to stack on mobile. Keep headers full-width enough to read and activate, let long labels wrap, and check that opening content does not clip form fields inside a fixed-height card.

In a dashboard, retain the identifying summary when cards stack; do not rely on a desktop-only hover hint to reveal what a panel contains. In a form, test whether opening one section moves the save button or the validation message away from the user’s current context. Responsive behavior should preserve the same meaning and available actions, not arbitrarily hide more information just because the viewport is smaller.

A practical review before shipping

Use this short review on the real screen, with representative content rather than placeholder copy:

1. Discoverability: With every optional panel closed, can someone locate the relevant section and spot an error or action that needs attention?
2. Keyboard: Can they reach each trigger with Tab, open it with Enter and Space, use its controls, and collapse it without losing focus? If arrow keys are offered, do they behave consistently?
3. Announcements: Does the trigger have the right name, heading context, and expanded state in a screen reader? Are closed controls actually unavailable to keyboard navigation?
4. Transitions: What happens when another panel opens, a form validates, a filtered item disappears, or the route changes? Are entered values retained as intended?
5. Viewport: At narrow widths and high zoom, do labels wrap, controls remain operable, and the next step remain findable?

These checks are not a replacement for testing with users. They are a way to catch a panel that looks polished but conceals the task. Compare the implementation against the W3C accordion pattern and the GOV.UK guidance on when not to collapse content, then test with people who actually use the dashboard or form.

Frequently asked questions

Are expansion panels and accordions the same thing?

The terms often overlap. An expansion panel is the collapsible unit; an accordion is usually a group of such units presented as interactive headings. For one isolated section, “disclosure” is the more precise interaction name. The practical question is whether the controls are independent or share a single-open rule.

Should all panels start closed?

Not necessarily. Start with what a person needs to see to begin the task. Open the active step or a section with an important error; consider collapsing optional settings. Record the default alongside the multiple-open and persistence rules, and test it with realistic screen content.

Can a closed panel contain form fields?

Yes, provided the fields are not required to understand or complete the current step while hidden, their values are retained as intended, and errors can be discovered from the visible surface. If a closed field fails validation, expose a clear header-level signal and a usable path to the field rather than leaving the user searching.

Put the decision into your next UI review

Pick one crowded dashboard or form screen. Mark what must remain visible, label the optional detail, and decide whether sections may stay open together. Then review focus, validation, and narrow-screen behavior before wiring up the component. If a grouped control fits, use our Accordion reference to evaluate the DOM Studio implementation against that contract.