Summer '26: Build a Zero-JavaScript Accordion in LWC with details name

Accordions show up often in Salesforce implementations. They appear on record pages, internal admin tools, support consoles, onboarding panels, and configuration screens.

The usual Lightning Web Component approach is familiar. Keep track of the open section in JavaScript, attach click handlers, update component state, and render the right content.

That works, but it is often more code than the requirement warrants. If the goal is simply “show these sections, but keep only one open at a time,” Summer ’26 gives LWC developers a smaller option: native HTML <details> elements grouped with the name attribute.

The problem

A simple accordion can become noisy in LWC.

Imagine a component on an Account record page that needs to show three sections:

Account summary
Open work
Governance notes

A common implementation stores the active section in JavaScript:

import { LightningElement } from 'lwc';

export default class AccountReviewPanel extends LightningElement {
    activeSection = 'summary';

    handleSectionClick(event) {
        this.activeSection = event.currentTarget.dataset.section;
    }

    get isSummaryOpen() {
        return this.activeSection === 'summary';
    }

    get isWorkOpen() {
        return this.activeSection === 'work';
    }

    get isGovernanceOpen() {
        return this.activeSection === 'governance';
    }
}

For a complex UI, this can be reasonable. For a basic disclosure pattern, it adds state that the browser can already manage.

This is easy to miss because the first version usually feels harmless. One section becomes three, styling is added, tests are added, and the component now has JavaScript whose only job is to open one panel and close another.

The risk is not that this code is broken. The risk is maintenance cost. In larger Salesforce orgs, the same pattern can repeat across component libraries, admin-facing tools, managed packages, and multi-team delivery pipelines.

Every extra handler and state property becomes something to review, test, and preserve during refactoring. For small UI behavior, less code is often the better design.

The solution

In Summer ’26, LWC API 67.0 supports grouping native <details> elements with the name attribute.

The <details> element creates a built-in disclosure widget. The user opens or closes it through its <summary> element.

When multiple <details> elements share the same name, the browser treats them as an exclusive group. Only one section in that group remains open at a time.

That means a simple accordion can be written without JavaScript state:

<details name="account-review" open>
    <summary>Account summary</summary>
    <p>Show the key Account details here.</p>
</details>

<details name="account-review">
    <summary>Open work</summary>
    <p>Show related tasks, cases, or follow-up items here.</p>
</details>

<details name="account-review">
    <summary>Governance notes</summary>
    <p>Show data quality or ownership guidance here.</p>
</details>

The important part is the repeated value:

name="account-review"

That shared name connects the sections. The browser handles the open and close behavior. The LWC class does not need a click handler just to track which panel is active.

This does not replace lightning-accordion for every use case. Salesforce base components are still useful when you need Salesforce styling, richer component APIs, or a component that follows established Lightning Design System patterns. The native <details> pattern is useful when the requirement is simple and the HTML element is enough.

Prerequisites

• Salesforce Summer ’26

• LWC component API version 67.0 or later

• A sandbox, scratch org, preview org, or upgraded org where API 67.0 is available

• VS Code with Salesforce Extension Pack

• Salesforce CLI

• Permission to deploy Lightning Web Components

• Lightning App Builder access if you want to place the component on a Lightning page

If your org is not yet on Summer ’26 or your component is still on an older API version, confirm availability in the release notes before relying on this behavior.

Step-by-step guide

Create the LWC component

Create a component named accountReviewPanel.

sf lightning generate component --name accountReviewPanel --type lwc --output-dir force-app/main/default/lwc

This gives you a small component bundle where the accordion can live.

Add the native details accordion

Update accountReviewPanel.html:

<template>
    <article class="panel">
        <h2>Account review</h2>

        <details name="account-review" open>
            <summary>Account summary</summary>
            <div class="section-body">
                <p>
                    Review the account status, ownership, and priority before taking action.
                </p>
            </div>
        </details>

        <details name="account-review">
            <summary>Open work</summary>
            <div class="section-body">
                <p>
                    Check related tasks, cases, and follow-up items that may need attention.
                </p>
            </div>
        </details>

        <details name="account-review">
            <summary>Governance notes</summary>
            <div class="section-body">
                <p>
                    Confirm that required fields, ownership rules, and data quality expectations are met.
                </p>
            </div>
        </details>
    </article>
</template>

The first section uses the open attribute so it is expanded by default.

<details name="account-review" open>

The other sections use the same name value. That is what makes them part of the same exclusive group.

Keep the JavaScript file minimal

For this example, accountReviewPanel.js does not need accordion state or click handlers.

import { LightningElement } from 'lwc';

export default class AccountReviewPanel extends LightningElement {}

This is the main benefit of the pattern. The component still behaves like an accordion, but the component class does not own the accordion state.

Add simple styling

Update accountReviewPanel.css:

.panel {
    border: 1px solid #d8dde6;
    border-radius: 0.25rem;
    background: #ffffff;
    padding: 1rem;
}

.panel h2 {
    font-size: 1rem;
    margin: 0 0 0.75rem;
}

details {
    border-top: 1px solid #d8dde6;
    padding: 0.75rem 0;
}

details:first-of-type {
    border-top: none;
}

summary {
    cursor: pointer;
    font-weight: 600;
}

.section-body {
    margin-top: 0.75rem;
}

The CSS is only responsible for spacing and visual structure. The browser still controls the open and close behavior.

Set the component API version

Update accountReviewPanel.js-meta.xml:

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>67.0</apiVersion>
    <isExposed>true</isExposed>
    <masterLabel>Account Review Panel</masterLabel>
    <targets>
        <target>lightning__RecordPage</target>
        <target>lightning__AppPage</target>
        <target>lightning__HomePage</target>
    </targets>
</LightningComponentBundle>

The API version matters. Set the component bundle to 67.0 when testing this Summer ’26 feature.

Deploy the component

Deploy the component to your org.

sf project deploy start --source-dir force-app/main/default/lwc/accountReviewPanel --target-org my-org

After deployment, add the component to a Lightning page from Lightning App Builder and test the behavior. Opening “Open work” should close “Account summary” automatically because both sections use the same name.

Project structure

force-app/
└── main/
    └── default/
        └── lwc/
            └── accountReviewPanel/
                ├── accountReviewPanel.html
                ├── accountReviewPanel.js
                ├── accountReviewPanel.css
                └── accountReviewPanel.js-meta.xml

Component	Role
accountReviewPanel.html	Defines the native <details> accordion
accountReviewPanel.js	Contains no accordion state for this example
accountReviewPanel.css	Adds simple spacing and visual structure
accountReviewPanel.js-meta.xml	Sets API 67.0 and exposes the component

Real-world impact

This pattern is useful for small Salesforce UI components where the interaction is simple. If the only requirement is to let users expand one section at a time, native HTML is easier to maintain than custom JavaScript state.

It also reduces test surface area. You do not need to test custom click handlers just to prove that one section closes when another opens. The browser owns that behavior.

In CI/CD pipelines, smaller components are easier to review. They are also less likely to fail because of unrelated state changes or minor refactoring.

In enterprise orgs, this helps when multiple teams share LWC patterns. A native HTML solution is easier to explain, easier to copy correctly, and easier to keep consistent across internal tools.

This is not the right pattern for every accordion. If the UI needs programmatic control, analytics events, dynamic section rules, custom validation, or close alignment with Salesforce base component behavior, use JavaScript or lightning-accordion.

Key takeaways

• Summer ’26 / API 67.0 supports grouping <details> elements with the name attribute in LWC.

• Shared name values create an exclusive accordion group.

• Simple accordions no longer require JavaScript state just to track the open section.

• Use this pattern when native HTML behavior matches the requirement.

• Use lightning-accordion or custom JavaScript for richer Salesforce-specific UI behavior.

• Set the LWC bundle API version to 67.0 when testing this release feature.

Resources

• Get the Latest LWC Changes with LWC API Version 67.0

• The Salesforce Developer’s Guide to the Summer ’26 Release

• MDN: The HTML details element

• MDN: Exclusive accordions using the HTML details element

Small platform updates like this are easy to overlook, but they can remove unnecessary code from everyday Salesforce components. Where would you still choose lightning-accordion or custom JavaScript instead of native <details name="…">?