Native details: one open item, keyboard access, and a no-script fallback

Collapsing a row of experience cards does make the page shorter. Readers still need to know what each entry is, how to open it, and whether the previous entry will disappear when they open the next one. Those decisions come before the opening animation.

The site’s About page uses native details and summary, with a small amount of script for animation and scrolling. On October 25, 2026, I checked the behavior separately with scripts enabled, with page scripts disabled, and with reduced-motion emulated. I wanted to see whether readers could still reach the content without the animation layer.

The summary should make clear what will open

details is suited to supplementary information that readers can expand to view; its first summary child provides a summary or label for that content. This disclosure control is part of HTML itself. There is no need to turn a div into a custom button first.[1]

The experience cards’ summaries contained dates, company names, and job titles. Readers could identify an entry while it was closed, without opening it just to find out what was inside. The arrow on the right only indicated the open or closed state. It had aria-hidden so that a decorative icon would not become another part of the control’s name.

Entries with visual work to view also had a separate work link. In the DOM, that link was a sibling of details, outside it, rather than nested inside summary. Expanding an experience entry and opening the work serve different purposes. They can sit close together visually while remaining separate controls with separate responsibilities.

The same distinction applies to other cards. If the title expands content but the adjacent icon goes to another page, putting them on the same visual row is not a reason to combine both actions into one control.

One open item is a reading trade-off, not an accordion requirement

The details elements for these experience entries shared name="career". HTML keeps at most one item open in a group with the same name. When another item opens, the browser closes the previous one. There is no need to loop through the other cards and remove open from each one.[1]

“At most one” also allows every item to be closed. The site’s initial HTML had only one item open by default, but readers could close it too. There was no requirement to leave an item selected.

This arrangement suits reading entries one at a time, but not every kind of content. The HTML specification also warns that mutually exclusive opening can hinder people who need to compare several pieces of information at once.[1] For plans, specifications, or changes over time, I would reassess whether to allow several items to stay open at once. I would not adopt exclusive opening simply because the native element provides it.

Another easy mistake concerns open: it is a Boolean attribute. What matters is whether the attribute is present, not whether its string looks like true or false. To output a closed state, omit it rather than leaving open="false" in the markup.[1]

Preserve keyboard access before adding animation

During the local check, I first focused the second summary and pressed Enter. It opened and the previous item closed. Pressing Space on an open summary closed it, leaving every item closed. Clicking a different item with the mouse also left only the clicked item open.

These interactions used browser input events rather than setting open to true directly in code. Changing the state directly can help check the layout, but it does not establish that readers can actually use the keyboard to reach and operate the control.

The summaries had no extra button wrapped around them, and there was no separate control for moving between items with the arrow keys. They provided native expand/collapse behavior. Looking like an accordion is not grounds for claiming that they also offer a composite widget’s keyboard behavior.

The page retained the shared focus-visible styles. A focus style being present is different from complete assistive-technology support, though. The Enter, Space, and mouse observations did not cover screen readers, all focus sequences, or testing across browsers.

Scripts add transitions and viewport positioning

The About page script did not take over all opening and closing. When an open card was closed normally, it first intercepted the default action and added is-closing, allowing the content to fade out and shift slightly before completing the close. The code also had a 200-millisecond timer as another completion path. That was an implementation setting, not a measured interaction delay.

After another item opened, the script scheduled scrolling to bring it just below the navigation bar. This adjusted the viewport position. It did not move keyboard focus into the content, and it was not the source of the one-open-item rule.

When assessing this interaction, I look at two things separately: whether the details element is actually open, and whether the visual transition has finished. A momentary fade-out does not by itself mean that the open/closed state has failed. Seeing a fade-out is not enough either; the close still needs to remove open in the end.

When reduced-motion was active, the closing branch left the native action intact, and the CSS removed the opening animation for this content. After emulating that media condition, I confirmed that cards could close without leaving is-closing behind. This was media emulation in the browser, not a test of every operating system setting or device.

Expanded content remains readable without JavaScript

I also disabled page-script execution and reloaded the About page, then used Enter and Space to open different items. The same-name group still kept only one item open at a time, and the content was still part of the page’s original HTML.

This fallback worked because the summaries and experience text were present from the start, rather than generated by a script after a click. Without scripts, the custom closing transition and scrolling after opening were absent. Readers could still reach the content.

Scenario	Behavior confirmed in the check
Enter in normal mode	The targeted item opened and the previous item closed
Space in normal mode	The open item closed, allowing all items to be closed
Mouse click on summary	The corresponding item opened, with at most one open
Page scripts disabled	Enter, Space, and native exclusive opening still worked
Emulated reduced-motion	Cards closed normally, with no closing-state class left behind

This was a local functional observation in Edge. It did not cover the back/forward cache (BFCache), assistive technology, or a subjective assessment of mobile reading comfort. Native elements provide a usable starting point, but they do not make all the content, focus, and reading-design decisions for the author.

Looking like a button does not mean it should be a <button> discusses the same choice: let HTML express the purpose of an action first. These cards disclose supplementary experience details, so details handles opening and closing before any decision about which animations are worth adding.

Sources

[1] https://html.spec.whatwg.org/multipage/interactive-elements.html