chore(accordion): full fidelity feature update

[miwha-adobe]

Description

Completes full-fidelity rendering, styling, and Storybook documentation for <swc-accordion> and <swc-accordion-item>.

Changes:

• accordion-item.css — new file with all Spectrum 2 token-driven item styles: header layout, chevron, panel, sizes (s/m/l/xl), and forced-colors support
• accordion.css — density overrides (compact/spacious) and quiet variant (transparent dividers, rounded header corners) cascaded to child items via custom properties
• AccordionItem.ts — fix incorrect CSS import (accordion.css → accordion-item.css)
• accordion.stories.ts — Storybook stories: Anatomy, Options (sizes, density, quiet, allow-multiple, heading level), States (disabled, item-disabled), Behaviors (toggle event, exclusive open), and Accessibility.

Note: Storybook stories are for testing for full fidelity review. Storybook docs will be further refined in following tickets.

Motivation and context

Phase 5 (styling) of the accordion 2nd-gen migration. This PR adds the visual layer and Storybook coverage on top.

Related issue(s)

• SWC-1860

Screenshots (if appropriate)

---

Author's checklist

• I have read the CONTRIBUTING and PULL_REQUESTS documents.
• I have reviewed the Accessibility Practices for this feature, see: Aria Practices
• I have added automated tests to cover my changes.
• I have included a well-written changeset if my change needs to be published.
• I have included updated documentation if my change required it.

---

Reviewer's checklist

• Includes a Github Issue with appropriate flag or Jira ticket number without a link
• Includes thoughtfully written changeset if changes suggested include patch, minor, or major features
• Automated tests cover all use cases and follow best practices for writing
• Validated on all supported browsers
• All VRTs are approved before the author can update Golden Hash

Manual review test cases

[changeset-bot]

⚠️ No Changeset found

Latest commit: ae634d4

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

📚 Branch Preview Links

• Documentation Site (first-gen)
• Storybook (first-gen)
• Storybook (second-gen)

🔍 First Generation Visual Regression Test Results

When a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:

• Spectrum | Light | Medium | LTR
• Spectrum | Dark | Large | RTL
• Express | Light | Medium | LTR
• Express | Dark | Large | RTL
• Spectrum-two | Light | Medium | LTR
• Spectrum-two | Dark | Large | RTL
• High Contrast Mode | Medium | LTR

Deployed to Azure Blob Storage: pr-6319

If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.

[rise-erpelding]

This is looking really nice overall and could use some polish in a few places! My big takeaway right now is that I realize that the previous PR definitely should have set selectors up a bit better--I'll address that ASAP

[rise-erpelding]

This isn't very well documented in the spec for accordion as far as I've seen, but my understanding is that block padding uses different tokens than the token spec or Spectrum-CSS because we changed our font to Adobe Clean VF - maybe the styling skill missed it?

So we'll want to change these for all densities/sizes, it does look like the design data repo recommends a new value, so for instance this one would use token("base-padding-vertical-large") for both top and bottom instead, might be worth pointing Claude to the repo to dig up all the correct replacement values.

[5t3ph]

head's up that we don't yet have the latest version of the tokens data so ones like base- aren't there yet

[rise-erpelding]

Oop now I remember you mentioning that before! What's the best way to handle that, would it be better to hard-code the spacing values for now rather than using separate top/bottom tokens?

[5t3ph]

I think you can still switch to something like component-padding-vertical-100 if those match up? That's what we're using for now in like button and badge

[miwha-adobe]

They generally match up, but spacious large and extra-large hit the ceiling. component-padding-vertical-300 (13px) is the highest available scale and the design value goes to 16px. I could use calc(token("component-padding-vertical-300") + 3px) as a stopgap with a comment to replace it once a higher-scale token lands in the token set?

[5t3ph]

Hmm, do we have a spacing token that is a better match? Since the idea is that those are used for uniform padding, at least it would be tokenized. You could add an inline comment though to explain the need to switch token type.

[miwha-adobe]

It seems both options have trade offs:

• calc(token("component-padding-vertical-300") + 3px) - partially theme-aware (the base scales, but the +3px is fixed)
• spacing-300 - fully fixed, no theme-responsiveness at all

Whats the process for getting new tokens added? I wonder if that's something we want to entertain.

[5t3ph]

See Josh's Slack thread re: platform scale but essentially the theme responsiveness is less of a concern going forward.

[miwha-adobe]

I only changed the ceiling value because the other values aren't supported in a 1:1 comparison

[5t3ph]

A few areas for improvements!

I would suggest pointing your agent at these custom property contributor docs (local path) to try to help sort out private vs public properties. We can huddle on that too, if needed!