adobe-spectrum-web-components

Adobe Spectrum Web Components — operations

Research snapshot: 2026-07-30. Scope: the public Spectrum Web Components (SWC) implementation and its contributor documentation. SWC implements Adobe Spectrum; it is not the entirety of Spectrum governance.

1. Governance

• SWC is developed by a core team in Adobe Design Engineering, primarily for Adobe product teams, while accepting internal and external contributions. The contributor documentation distinguishes core-team maintainers from other contributors. (Contributor documentation)
• Public planning is organized around objectives and strategy, cross-cutting workstreams, per-component plans, and milestones. Repository reviews, maintainer documentation, and issue tracking are the operational decision surfaces. (Contributor documentation)
• Major global-style changes are expected to begin with a team discussion and agreed plan rather than an isolated code change. (Styling components)

2. Component lifecycle

• SWC does not publish a single general proposed/draft/beta/stable status ladder for individual components. Its release contract distinguishes stable SemVer releases, a beta tag for the next minor release, deprecation warning levels, and removal in a later major release. (Support and compatibility, deprecation guide)
• New components are scaffolded as packages with source, generated and override styles, Storybook stories, tests, package metadata, and a changelog. Names must align with the Spectrum core component name. (Generating components)
• Deprecation follows identify → announce → warn and document → migration period → removal. Yellow means still functional but migration is encouraged; red means removal is near. Removal is normally considered for the next major release, with exceptions receiving at least two releases or six months, whichever is smaller. (Deprecation guide)
• The project is publicly tracking a first-generation to second-generation transition through workstreams, component roadmaps, and milestones rather than relabeling all components with one maturity vocabulary. (Contributor documentation)

3. Contribution process

• Contributors use the issue tracker, repository setup guide, pull requests, and PR reviews. The public contributor documentation contains dedicated guides for getting involved, issue use, repository work, pull requests, review participation, accessibility testing, migration guides, and changelog strategy. (Contributor documentation)
• A generated component receives a standard package structure, then is developed and exercised in Storybook. Documentation is authored in the package README and rendered into the public site. (Generating components, developing a component)
• Contributors are expected to follow project-wide TypeScript, CSS, linting, testing, documentation, accessibility-testing, and review conventions. Core maintainers retain review and release responsibility. (Contributor documentation)

4. Versioning and release cadence

• Since 1.0.0, SWC follows Semantic Versioning. Patch versions are released regularly without breaking changes; breaking changes are reserved for major versions, announced in advance, and accompanied by migration guides. A beta dist tag previews the next minor version. (Support and compatibility)
• Changes are communicated through per-package changelogs, GitHub releases, release notes, deprecation notices, and migration guides. Public package pages display changelog entries that identify pull requests and affected dependencies. (SWC releases, styles changelog, deprecation guide)
• The public policy promises regular patch releases but does not state a fixed day or interval. Major releases are event-driven by breaking changes. (Support and compatibility)

5. Documentation structure/templates

• Component README files drive public component documentation. The prescribed structure is Overview → Usage → Anatomy → Options → States → Behaviors → Accessibility. Headings must be predictable and examples must include enough context to demonstrate accessible composition. (Developing a component)
• The public package pages combine an Overview and Changelog, while component pages render live examples and usage details from source documentation. Storybook supports development and configuration testing. (Styles package, developing a component)
• The repository includes authoring rules and validation for component README structure, accessible examples, heading hierarchy, links, and contributor-document navigation. (Developing a component, Contributor documentation)

6. Naming and token conventions

• Component package names are kebab case and should match Spectrum core naming; registered custom elements use the sp- prefix. Generated files follow predictable package, class, story, test, and sp-[component-name] registration patterns. (Generating components)
• Spectrum design tokens are exposed as --spectrum- CSS custom properties. The styles package separates fixed/global values, semantic aliases, semantic component tokens, color options, scales, and system variants; examples include numbered base scales and purpose-named aliases. (Styles package)
• Older Spectrum Vars token files and naming are deprecated in favor of Spectrum Core tokens, with a published migration path. Component styling separates generated Spectrum structure, system overrides, and SWC-specific styles. (Styles package, styling components)

7. Accessibility criteria and enforcement

• SWC describes components as accessible by default for screen-reader, keyboard, and customized-contrast use. Component documentation must include accessibility considerations and every example must demonstrate accessible use in context. (SWC overview, developing a component)
• Accessibility testing has a dedicated contributor guide and is described as including automated tests, snapshots, and manual expectations for pull requests. Testing and accessibility conventions are part of the contributor documentation used by maintainers and external contributors. (Contributor documentation)
• Development-mode checks surface accessibility, API, deprecation, and performance problems while components are being developed. Accessibility is therefore enforced both in component code/tests and in authoring examples and usage guidance. (Dev mode, developing a component)

8. Audit/review cycle

• Continuous controls include pull-request accessibility expectations, automated tests and snapshots, Storybook configuration testing, development-mode warnings, and maintainer review. (Contributor documentation, developing a component, Dev mode)
• Component and feature deprecations can be identified through internal review or community feedback. Notices are then added to release notes, the site, runtime warnings, and package metadata, with migration guidance before removal. (Deprecation guide)
• Workstreams, component plans, and milestones expose the state of the ongoing generation transition. The cited public sources do not establish one fixed periodic audit interval for the full library. (Contributor documentation)