@adobe/spectrum-design-data 3.3.0-beta.2 → 3.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (136) hide show
  1. package/components/accordion.json +67 -15
  2. package/components/action-bar.json +30 -9
  3. package/components/action-button.json +92 -39
  4. package/components/action-group.json +137 -18
  5. package/components/alert-banner.json +27 -8
  6. package/components/alert-dialog.json +55 -34
  7. package/components/avatar-group.json +35 -9
  8. package/components/avatar.json +105 -29
  9. package/components/badge.json +163 -56
  10. package/components/breadcrumbs.json +107 -26
  11. package/components/button-group.json +63 -19
  12. package/components/button.json +105 -61
  13. package/components/calendar.json +74 -8
  14. package/components/card.json +13 -0
  15. package/components/cards.json +46 -31
  16. package/components/checkbox-group.json +85 -16
  17. package/components/checkbox.json +97 -27
  18. package/components/close-button.json +75 -20
  19. package/components/coach-indicator.json +44 -14
  20. package/components/coach-mark.json +26 -8
  21. package/components/color-area.json +100 -20
  22. package/components/color-handle.json +46 -25
  23. package/components/color-loupe.json +14 -2
  24. package/components/color-slider.json +129 -26
  25. package/components/color-wheel.json +91 -17
  26. package/components/combo-box.json +189 -50
  27. package/components/contextual-help.json +126 -80
  28. package/components/date-field.json +7 -0
  29. package/components/date-picker.json +127 -24
  30. package/components/divider.json +38 -12
  31. package/components/drop-zone.json +37 -18
  32. package/components/field-label.json +62 -21
  33. package/components/heading.json +7 -0
  34. package/components/help-text.json +53 -16
  35. package/components/illustrated-message.json +85 -21
  36. package/components/in-line-alert.json +53 -13
  37. package/components/link.json +63 -24
  38. package/components/list-view.json +80 -15
  39. package/components/menu.json +181 -45
  40. package/components/meter.json +78 -24
  41. package/components/number-field.json +175 -34
  42. package/components/picker.json +188 -42
  43. package/components/popover.json +126 -37
  44. package/components/progress-bar.json +108 -23
  45. package/components/progress-circle.json +55 -12
  46. package/components/radio-button.json +67 -14
  47. package/components/radio-group.json +132 -28
  48. package/components/rating.json +38 -9
  49. package/components/search-field.json +126 -34
  50. package/components/segmented-control.json +70 -21
  51. package/components/select-box.json +103 -29
  52. package/components/side-navigation.json +69 -28
  53. package/components/slider.json +155 -39
  54. package/components/standard-dialog.json +88 -16
  55. package/components/status-light.json +136 -41
  56. package/components/steplist.json +24 -5
  57. package/components/swatch-group.json +55 -19
  58. package/components/swatch.json +79 -24
  59. package/components/switch.json +79 -31
  60. package/components/table.json +73 -26
  61. package/components/tabs.json +52 -22
  62. package/components/tag-field.json +60 -14
  63. package/components/tag-group.json +56 -16
  64. package/components/tag.json +78 -21
  65. package/components/takeover-dialog.json +61 -10
  66. package/components/text-area.json +205 -49
  67. package/components/text-field.json +170 -42
  68. package/components/thumbnail.json +63 -22
  69. package/components/time-field.json +7 -0
  70. package/components/toast.json +50 -29
  71. package/components/tooltip.json +87 -27
  72. package/components/tree-view.json +147 -45
  73. package/components/user-card.json +7 -0
  74. package/guidelines/app-frame-overview.json +44 -46
  75. package/guidelines/attention-hierarchy.json +22 -13
  76. package/guidelines/background-layers.json +10 -80
  77. package/guidelines/brand.json +12 -32
  78. package/guidelines/colors.json +17 -47
  79. package/guidelines/developer-overview.json +9 -25
  80. package/guidelines/faqs.json +9 -96
  81. package/guidelines/fonts.json +14 -29
  82. package/guidelines/grays.json +44 -17
  83. package/guidelines/icon-fundamentals.json +18 -7
  84. package/guidelines/manifest.json +15 -367
  85. package/guidelines/motion.json +16 -17
  86. package/guidelines/principles.json +8 -7
  87. package/guidelines/resources.json +15 -21
  88. package/guidelines/states.json +11 -16
  89. package/guidelines/using-icons.json +44 -33
  90. package/package.json +2 -2
  91. package/registry/platform-implementations.json +30 -0
  92. package/guidelines/ai-resource-guide.json +0 -50
  93. package/guidelines/applying-the-type-system.json +0 -67
  94. package/guidelines/bi-directionality.json +0 -57
  95. package/guidelines/border-width.json +0 -58
  96. package/guidelines/cognitive.json +0 -197
  97. package/guidelines/component-spacing.json +0 -61
  98. package/guidelines/contact-us.json +0 -67
  99. package/guidelines/content-area-browsing-context.json +0 -65
  100. package/guidelines/content-design-grammar-and-mechanics.json +0 -241
  101. package/guidelines/content-design-voice-and-tone.json +0 -37
  102. package/guidelines/content-grammar-and-mechanics.json +0 -252
  103. package/guidelines/content-language-and-inclusivity-writing-about-people.json +0 -103
  104. package/guidelines/content-language-and-inclusivity-writing-with-visuals.json +0 -70
  105. package/guidelines/content-voice-and-tone.json +0 -47
  106. package/guidelines/creating-bluelines-browsing-context.json +0 -91
  107. package/guidelines/design-tokens.json +0 -158
  108. package/guidelines/drop-shadow.json +0 -68
  109. package/guidelines/grammar-and-mechanics.json +0 -252
  110. package/guidelines/header-browsing-context.json +0 -40
  111. package/guidelines/illustration.json +0 -105
  112. package/guidelines/in-product-word-list.json +0 -29
  113. package/guidelines/inclusive-design.json +0 -101
  114. package/guidelines/inclusive-ux-writing.json +0 -30
  115. package/guidelines/internationalization.json +0 -87
  116. package/guidelines/language-and-inclusivity-writing-about-people.json +0 -85
  117. package/guidelines/language-and-inclusivity-writing-with-visuals.json +0 -61
  118. package/guidelines/layout-and-structure-containers.json +0 -47
  119. package/guidelines/layout-and-structure-spacing-overview.json +0 -66
  120. package/guidelines/layout-spacing.json +0 -39
  121. package/guidelines/object-styles-overview.json +0 -17
  122. package/guidelines/rounding.json +0 -73
  123. package/guidelines/side-navigation-browsing-context.json +0 -74
  124. package/guidelines/spacing-overview.json +0 -45
  125. package/guidelines/support.json +0 -113
  126. package/guidelines/typography-overview.json +0 -43
  127. package/guidelines/typography-system.json +0 -208
  128. package/guidelines/visual-language-containers.json +0 -36
  129. package/guidelines/voice-and-tone.json +0 -47
  130. package/guidelines/whats-new.json +0 -32
  131. package/guidelines/writing-about-people.json +0 -103
  132. package/guidelines/writing-for-errors.json +0 -120
  133. package/guidelines/writing-for-onboarding.json +0 -119
  134. package/guidelines/writing-for-readability.json +0 -54
  135. package/guidelines/writing-with-visuals.json +0 -70
  136. package/registry/platform-extensions/web-components-states.json +0 -58
@@ -1,91 +0,0 @@
1
- {
2
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
- "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/creating-bluelines-browsing-context.json",
4
- "name": "creating-bluelines-browsing-context",
5
- "title": "Creating bluelines",
6
- "category": "designing",
7
- "documentBlocks": [
8
- { "type": "purpose", "content": "Creating bluelines" },
9
- {
10
- "type": "guideline",
11
- "content": "The accessible name is the text that software uses to identify a component, and communicates it to the user. Assistive technologies like screen readers and voice control require an accessible name to read aloud content to screen reader users, or to accept speech input from voice control users to interact with digital content. Learn more about accessible names. Accessible names vary depending on the content. Accessible names must be defined for controls that don’t have visible text labels."
12
- },
13
- {
14
- "type": "guideline",
15
- "content": "A. Side navigation state control.\n\nThe default accessible name are Show menu labels and Hide menu labels. In general, the names should be as specific as possible and are up to individual product teams to define, based on the content inside. View more details about side navigation state control."
16
- },
17
- {
18
- "type": "guideline",
19
- "content": "B. Product lock-up.\n\nWhen an interactive control has a visible text label, there is no requirement to specify an accessible name. The visible text label will be accessible and the graphic will be ignored by a screen reader."
20
- },
21
- {
22
- "type": "guideline",
23
- "content": "C. Side navigation labels.\n\nWhen the side navigation is partially minimized (icon-only), the labels on the tooltips and when the side navigation is expanded should match the accessible names. Because a text label is available in both expanded and minimized states, app frame side navigation buttons do not require additional annotation."
24
- },
25
- {
26
- "type": "guideline",
27
- "content": "D. Adobe-wide actions.\n\nIf using the universal navigation pattern, follow guidance defined in the design and implementation for continuity across products. Here are some guidelines to keep in mind as you define accessible names in the app frame:"
28
- },
29
- {
30
- "type": "guideline",
31
- "content": "D. Adobe-wide actions.\n\nIf using the universal navigation pattern, follow guidance defined in the design and implementation for continuity across products."
32
- },
33
- {
34
- "type": "guideline",
35
- "content": "Landmark regions create a programmatic identification of the visual areas or sections of web applications, which represent the spatial layout of the user interface. The purpose of annotating landmark regions is to ensure developers code the page structure correctly, include the correct content in the defined grouping, and apply an accessible name to the landmark regions that require them. Learn more about landmark regions. Any non-text element in a digital interface with a text label must have a text alternative. Here’s an example of how you might name landmark regions in an app frame:"
36
- },
37
- {
38
- "type": "guideline",
39
- "content": "Landmark regions create a programmatic identification of the visual areas or sections of web applications, which represent the spatial layout of the user interface. The purpose of annotating landmark regions is to ensure developers code the page structure correctly, include the correct content in the defined grouping, and apply an accessible name to the landmark regions that require them. Any non-text element in a digital interface with a text label must have a text alternative. Here’s an example of how you might name landmark regions in an app frame: Image: Diagram showing landmark regions of the app frame, including Navigation (Global), Banner, Navigation (Side), and Region, in which the name is descriptive of the content. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1eef1503193f9c071e33d7e4dcc7364d3fc831e1a.png?width=750&format=png&optimize=medium) Note that you may also want to include additional landmark regions for content within each area. A. The navigation areas require accessible names, because there is more than one area on the page. Depending on your content, the accessible names might be different for your product. B. Regions always require accessible names, and should be named based on the content of the region. If using content areas split into additional areas, make sure to name those regions as well. Note: In some cases, landmarks might be better defined as a complementary landmark instead of a region landmark. For example, the AI assistant in Digital Experience products is separate from the main content (not contained within another landmark), but is still supportive of the main content. In that case, the AI assistant would be a complementary landmark instead of a region landmark."
40
- },
41
- {
42
- "type": "guideline",
43
- "content": "Heading annotations describe the heading structure of a digital interface and are helpful for all users. Screen reader users in particular rely on them to navigate an interface. They organize information, help create an information hierarchy, and build a mental map of the content available. Learn more about heading annotations. There must be one <h1> heading, and any text that serves the purpose of a heading must be marked accordingly from <h1> to <h6>. Because headings rely greatly on structure and content, they will likely vary depending on the page. As a general rule, the <h1> should live in the main landmark region. Here’s an example of how you might structure heading annotations for this screen:"
44
- },
45
- {
46
- "type": "guideline",
47
- "content": "Heading annotations describe the heading structure of a digital interface and are helpful for all users. Screen reader users in particular rely on them to navigate an interface. They organize information, help create an information hierarchy, and build a mental map of the content available. There must be one <h1> heading, and any text that serves the purpose of a heading must be marked accordingly from <h1> to <h6>. Because headings rely greatly on structure and content, they will likely vary depending on the page. As a general rule, the <h1> should live in the main landmark region. Here’s an example of how you might structure heading annotations for this screen: Image: Example of heading annotations for Photoshop. H1, Welcome to Photoshop content area. H2, Start something new content area. H3, cards with marketing and user-customized content suggestions. H4, Favorites section in side navigation. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1f1c24c6a47078ee2e72f275cf116314df0e31178.png?width=750&format=png&optimize=medium)"
48
- },
49
- {
50
- "type": "guideline",
51
- "content": "The keyboard focus order describes how someone who uses a keyboard to operate the interface (instead of a pointing device like a mouse), would interact with an interface. Learn more about keyboard focus order. Keyboard focus order will depend on what controls are available on the page. Here’s an example of how you might define the order in the app frame:"
52
- },
53
- {
54
- "type": "guideline",
55
- "content": "The keyboard focus order describes how someone who uses a keyboard to operate the interface (instead of a pointing device like a mouse), would interact with an interface. Keyboard focus order will depend on what controls are available on the page. Here’s an example of how you might define the order in the app frame: Image: Example of a keyboard focus order for Photoshop, with an order from 1 as the side navigation show/hide affordance, and 22 as the filter for recent files. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_16b5e54f6ed6dd1b100303107eaeddc8409567f03.png?width=750&format=png&optimize=medium)"
56
- },
57
- {
58
- "type": "guideline",
59
- "content": "Support keyboard focus for resizing the side navigation.\n\nExample of correct usage, support for keyboard focus for size navigation. The side navigation width is focusable and resizable by using the left and right arrow keys. Image: Unlabeled image (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_15add197e527eb49a7a8f89286b990a582769f5f3.png?width=750&format=png&optimize=medium)"
60
- },
61
- {
62
- "type": "guideline",
63
- "content": "Include a “Skip to main content” button.\n\nExample of correct usage, inclusion of a Skip to main content button within the app frame header. Image: Example of correct usage, inclusion of a Skip to main content button within the app frame header. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1727ff3b9a578166d4a5e3067f54d9ff2b404b80c.png?width=750&format=png&optimize=medium)"
64
- },
65
- {
66
- "type": "guideline",
67
- "content": "Support F6 key navigation.\n\nWhen properly supported, the F6 key allows keyboard users to navigate through different regions of an application efficiently. Without this support, keyboard-only users have no means to jump to specific areas of the application, resulting in an excessive number of keystrokes to reach their desired goal. Here are some key quality factors to consider: A keyboard focus indicator should be present to show keyboard-only users their current location within the interface. Ideally, the focus of the F6 key should move in accordance with the landmark regions defined in the HTML of the application. Major sections of the app should be accessible through the F6 key, including main navigation, toolbars, contextual toolbars, and the canvas. Each of these regions must have an accessible name assigned to them, allowing screen reader users to understand which area of the user interface they are currently navigating. For more information about F6 key navigation, please refer to the Digital Accessibility Guide: Design a11y checklist. Image: Example of correct usage, support for F6 key navigation. This helps users traverse through different regions of an application efficiently. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1d708d40a17766cb37e6d7ff737079982577b079b.png?width=750&format=png&optimize=medium)"
68
- },
69
- {
70
- "type": "guideline",
71
- "content": "Support F6 key navigation.\n\nWhen properly supported, the F6 key allows keyboard users to navigate through different regions of an application efficiently. Without this support, keyboard-only users have no means to jump to specific areas of the application, resulting in an excessive number of keystrokes to reach their desired goal. Here are some key quality factors to consider: A keyboard focus indicator should be present to show keyboard-only users their current location within the interface. Ideally, the focus of the F6 key should move in accordance with the landmark regions defined in the HTML of the application. Major sections of the app should be accessible through the F6 key, including main navigation, toolbars, contextual toolbars, and the canvas. Each of these regions must have an accessible name assigned to them, allowing screen reader users to understand which area of the user interface they are currently navigating. Image: Example of correct usage, support for F6 key navigation. This helps users traverse through different regions of an application efficiently. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1d708d40a17766cb37e6d7ff737079982577b079b.png?width=750&format=png&optimize=medium)"
72
- },
73
- {
74
- "type": "guideline",
75
- "content": "Mobile overlay guidance: Keyboard focus.\n\nFor mobile breakpoints, a tray is used to open and close the app frame side navigation. In this example, the keyboard focus order starts at the “Create” button and ends at the close button. Clicking on esc should also close the tray. Image: Example of a keyboard focus order for the mobile overlay, with an order from 1 as the create button, 2 as the side navigation items, and 3 the close button. Note that the `esc` should also close the tray. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1c0739f2368c9914995fd166d727db38aa907b244.png?width=750&format=png&optimize=medium)"
76
- }
77
- ],
78
- "sourceUrl": "https://preview.spectrum.adobe.com/foundations/app-frame/creating-bluelines-browsing-context",
79
- "lastUpdated": "2026-09-04",
80
- "status": "published",
81
- "tags": [
82
- "app frame",
83
- "bluelines",
84
- "accessible names",
85
- "landmark regions",
86
- "heading annotations",
87
- "side navigation",
88
- "universal navigation",
89
- "complementary landmark"
90
- ]
91
- }
@@ -1,158 +0,0 @@
1
- {
2
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
- "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/design-tokens.json",
4
- "name": "design-tokens",
5
- "title": "Design tokens",
6
- "category": "designing",
7
- "documentBlocks": [
8
- { "type": "purpose", "content": "Design tokens" },
9
- {
10
- "type": "guideline",
11
- "content": "Design tokens enable alignment, automation, learnability, and multi-platform fidelity, resulting in high-quality experiences and efficient system management. By defining design decisions once and reusing them consistently, tokens create a shared foundation that helps maintain a common design language across teams, tools, products, and platforms. This allows experiences to adapt to different implementation needs while preserving the intent of the design language."
12
- },
13
- {
14
- "type": "guideline",
15
- "content": "Clear.\n\nDesign tokens are created within a well-defined scope, purpose, and meaning so they remain understandable and accurately represent the design language."
16
- },
17
- {
18
- "type": "guideline",
19
- "content": "Systematic.\n\nDesign tokens are defined and managed through a structured system that spans design and development resources."
20
- },
21
- {
22
- "type": "guideline",
23
- "content": "Learnable.\n\nDesign tokens are supported through documentation, guidance, and educational resources that help people identify, understand, and use them effectively."
24
- },
25
- {
26
- "type": "guideline",
27
- "content": "Spectrum uses tokens as a shared foundation for expressing and reusing design decisions throughout the design system. Rather than representing every possible design scenario, the token system focuses on reusable decisions that support many structures, components, products, and experiences Spectrum also prioritizes semantic design decisions over direct values whenever possible. By expressing intent rather than implementation details, tokens become easier to understand, easier to reuse, and more resilient to change over time. Design tokens work together with component libraries, implementation frameworks, documentation, and other Spectrum resources to help maintain a cohesive design language across products and platforms. While tokens capture many design decisions, they are only one part of the broader system used to design, document, and implement Spectrum experiences. Image: Nested concentric semicircle diagram illustrating a design system hierarchy, with \"Products\" as the outermost layer, \"Platform components\" in the middle, and \"Tokens\" at the innermost core, rendered in purple gradient tones. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1c3063afa864ec179a458d95d51558937b4bc43ed.png?width=750&format=png&optimize=medium)"
28
- },
29
- {
30
- "type": "guideline",
31
- "content": "Token.\n\nA reusable design decision represented as structured data. A token consists of a name and a value. Together, these define both the purpose of a design decision and the data used to implement it."
32
- },
33
- {
34
- "type": "guideline",
35
- "content": "Image: Code snippet showing a JSON token definition for \"accent-content-color-default,\" including its schema reference, a value pointing to \"{accent-color-900},\" and a UUID. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_180c6be1720908c84590aced0e4ea46ec42d8c386.png?width=750&format=png&optimize=medium)"
36
- },
37
- {
38
- "type": "guideline",
39
- "content": "Token name.\n\nThe structured classification of a design use case. Token names are created using Spectrum's token taxonomy, which defines the categories, terminology, and ordering used to describe design decisions. This helps ensure that names remain predictable, scalable, and understandable across teams, tools, products, and platforms. Token names form a shared language that helps people and systems understand and apply design decisions consistently across tools, products, and platforms."
40
- },
41
- {
42
- "type": "guideline",
43
- "content": "Image: Three example design tokens labeled \"Token name,\" each pointing to a specific token: a blue color swatch named \"blue-900\" with value rgb(59, 99, 251); a ruler icon for \"base-padding-vertical-large\" with value 10px; and a font icon for \"sans-serif-font-family\" with value \"Adobe Clean Spectrum VF.\" (source: https://preview.spectrum.adobe.com/foundations/design-data/media_16849d171f58f0ed54185afd8a10028da399cd46c.png?width=750&format=png&optimize=medium)"
44
- },
45
- {
46
- "type": "guideline",
47
- "content": "Value.\n\nThe data associated with a token. A value may be a final implementation value such as a color, dimension, percentage, or duration. A value can be dependent on context, such as light or dark color themes. It may also be a reference to another token through aliasing."
48
- },
49
- {
50
- "type": "guideline",
51
- "content": "Image: Three tokens—\"blue-900\" (rgb(59, 99, 251)), \"base-padding-vertical-large\" (10px), and \"sans-serif-font-family\" (Adobe Clean Spectrum VF)—each with their resolved output highlighted and labeled \"Value.\" (source: https://preview.spectrum.adobe.com/foundations/design-data/media_18b43d82026c0f02530b5ce62978951a800a60d4c.png?width=750&format=png&optimize=medium).\n\nToken nameValue blue-900 rgb(59, 99, 251) spacing-100 8px container-padding-medium spacing-300"
52
- },
53
- {
54
- "type": "guideline",
55
- "content": "Alias.\n\nA token that references another token instead of a final value. Aliasing allows broad design decisions to be refined into more specific contexts and use cases while preserving consistency and reducing duplication. Each layer adds additional context without redefining the underlying value."
56
- },
57
- {
58
- "type": "guideline",
59
- "content": "Image: Diagram showing a token aliasing chain: the base color token \"blue-900\" ( #3B63FB) flows down through an alias called \"accent-color-900,\" which in turn flows into a further alias called \"accent-content-color-default.\" (source: https://preview.spectrum.adobe.com/foundations/design-data/media_11cea602f9ef5940fc07648edb357982ec8e90c5f.png?width=750&format=png&optimize=medium).\n\nToken nameValue (alias) accent-content-color-default accent-color-900"
60
- },
61
- {
62
- "type": "guideline",
63
- "content": "Primitive (aka Global) tokens.\n\nPrimitive tokens define the available values in the design language. They represent raw design values and generally communicate little or no information about how those values should be used. Examples: blue-800 gray-100 corner-radius-75 Primitive tokens provide the foundation for higher-level design decisions. Because they communicate values with no intent, they are typically used indirectly through semantic tokens as an alias."
64
- },
65
- {
66
- "type": "guideline",
67
- "content": "Image: Two token scales side by side: a vertical blue color ramp from light to dark labeled \"blue-900\" at its mid-dark point, and a vertical spacing scale of gray squares increasing in size labeled \"spacing-400\" at a mid-sized square. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_179482299e81daea4dfee0b8609e53447561d4bbb.png?width=750&format=png&optimize=medium)"
68
- },
69
- {
70
- "type": "guideline",
71
- "content": "Semantic tokens define how design decisions are used throughout the system. Rather than describing values directly, they communicate purpose, intent, structure, or application. Examples: accent-background-color-default negative-content-color-default container-padding-medium group-gap-small Semantic tokens help people understand: Why a decision exists Where it should be used How it relates to other design decisions Semantic tokens are the primary way consumers interact with Spectrum design tokens."
72
- },
73
- {
74
- "type": "guideline",
75
- "content": "Image: Diagram showing the token \"accent-content-color-default\" branching out to five UI examples that use it: a radio button label, a checkbox label, a toggle switch label, a hyperlink, and a menu item checkmark—all rendered in the same blue. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1dc05f4cd2a0071e6256b9da67fd14f92340485e7.png?width=750&format=png&optimize=medium)"
76
- },
77
- {
78
- "type": "guideline",
79
- "content": "Component-specific tokens.\n\nComponent-specific tokens represent design decisions that apply to a specific component or implementation. Examples: tooltip-maximum-width divider-thickness-small Spectrum prioritizes reusable semantic decisions whenever possible, which reduces the need for component-specific tokens. However, some implementation-specific needs may still require decisions that are scoped to a particular component. For this reason, component-specific tokens may exist within Spectrum or individual platform implementations, but they play a much smaller role than reusable semantic tokens."
80
- },
81
- {
82
- "type": "guideline",
83
- "content": "Image: Diagram showing the token \"tab-gap-horizontal-medium\" pointing to the pink-highlighted gap between two radio button labels in a UI example. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1de0d50e78fdc61dfc5ba6ac5e78ab4db2ea9bbdf.png?width=750&format=png&optimize=medium)"
84
- },
85
- {
86
- "type": "guideline",
87
- "content": "Meaning.\n\nEvery design decision serves a purpose. Some decisions communicate meaning, helping users understand status, emphasis, importance, or feedback. Examples include: accent-background-color-default negative-border-color-default negative-content-color-default positive-background-color-default These decisions describe what a design choice is intended to communicate."
88
- },
89
- {
90
- "type": "guideline",
91
- "content": "Image: Diagram grouping UI examples by feedback type: \"Positive\" links to a green \"Approved\" tag and a password field with a matching-passwords confirmation; \"Negative\" links to a red \"Rejected\" tag and a password field showing a \"Passwords do not match\" error with a red tooltip; \"Informative\" links to a blue \"Active\" tag and a blue tooltip. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1492d46785f384e217b76912d774fa3f5b96d6b28.png?width=750&format=png&optimize=medium).\n\nMeaning helps people understand not only how an interface looks, but what it is trying to convey. By expressing meaning directly in token names, decisions become easier to understand, reuse, and apply consistently across products and platforms."
92
- },
93
- {
94
- "type": "guideline",
95
- "content": "Reusable structures.\n\nWhile some design decisions communicate meaning, others help define how components are organized and constructed. Examples include: container-padding-medium group-gap-small base-padding-vertical-large banner-gap-horizontal These decisions describe how interfaces are built."
96
- },
97
- {
98
- "type": "guideline",
99
- "content": "Image: Diagram grouping UI components by structure type: \"Base\" links to individual elements like an \"Approved\" tag, a value field, a delete button, a list item, and a stepper; \"Group\" links to sets of related elements like paired radio buttons, toggles, and stacked checkboxes. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_129333dbe5f3c9919f4aa947c23a26c2453169a48.png?width=750&format=png&optimize=medium).\n\nTo improve reuse and consistency, Spectrum organizes many of these decisions around recurring interface structures. These reusable structures are abstract concepts that describe common UI patterns. They are not specific components or implementation types. Instead, they provide a shared framework for organizing design decisions that can be reused across many different components, products, and technologies. Because these structures represent patterns rather than implementations, they help create design decisions that are more reusable, predictable, and easier to understand. Some structures may closely resemble familiar interface concepts, but they remain independent of any specific platform or implementation. These structures help answer “Where does this design decision apply?” Common structures include: Structure Description BaseThe primary functional element within a structureAccessoryA supporting element associated with another structureGroupA collection of related elementsListA sequence of repeated itemsContainerA structure that organizes contentBannerA structure used for prominent messagingThese structures help answer “Where does this design decision apply?”"
100
- },
101
- {
102
- "type": "guideline",
103
- "content": "Components are often composed from one or more reusable structures. Rather than creating unique design decisions for every component, Spectrum reuses decisions across common patterns that appear throughout the system. This approach allows many components to share the same underlying design language while adapting to different contexts and use cases. Platform implementations combine these reusable structures with platform-specific requirements, interaction patterns, accessibility considerations, and implementation constraints to create complete component experiences. By reusing tokens, structures, and components, teams can build cohesive experiences without redefining the same decisions in every implementation. As a result, decisions become more reusable, components become more modular, and the system becomes easier to learn, maintain, and evolve. Image: Diagram showing how reusable structures combine into compositions and then components: a \"Base\" structure and a \"List item\" structure each flow into composition examples with labels, descriptions, and toggles, which then combine into a finished \"Menu item\" component with a value and toggle. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_19eceefe7f3c359ba6f591936e3bf009582d70ea1.png?width=750&format=png&optimize=medium)"
104
- },
105
- {
106
- "type": "guideline",
107
- "content": "Positive color 600.\n\nThe name identifies: what’s being communicated (positive) which option is used (600) Together they represent a specific color decision. Image: Diagram breaking down the token name \"accent-background-color-hover,\" with callouts showing that \"accent\" indicates what's communicated, \"background-color\" indicates what it affects, and \"hover\" indicates when it applies, next to a blue color swatch. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_138f950047d55d3e1a89f6f1cbd0b22558cab1ca2.png?width=750&format=png&optimize=medium)"
108
- },
109
- {
110
- "type": "guideline",
111
- "content": "Accent background color hover.\n\nThe name identifies: what’s being communicated (accent) what it affects (background-color) when it applies (hover) Together they describe the background color used when an accentuated interface element is hovered. Image: Diagram breaking down the token name \"base-padding-vertical-small,\" with callouts showing that \"base\" indicates where it applies, \"padding-vertical\" indicates what it affects, and \"small\" indicates which option is used. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1a19e41620a76ada5ceae2dbb74a4778609a34e35.png?width=750&format=png&optimize=medium)"
112
- },
113
- {
114
- "type": "guideline",
115
- "content": "Base padding vertical small.\n\nThe name identifies: where it’s applied (base) what it affects (padding) how it’s applied (vertical) which option is used (small) Together they describe a specific spacing decision used by base structures (Action button, Text field, List item contents, etc)."
116
- },
117
- {
118
- "type": "guideline",
119
- "content": "Start with Spectrum components.\n\nWhenever possible, use your platform's Spectrum components before working directly with design tokens. Components bring together design decisions, behavior, accessibility, and implementation guidance into reusable solutions that are already aligned with the Spectrum design language. Design tokens provide the foundation that supports those solutions. When existing components don't meet your needs, tokens can help you extend, compose, or create experiences that remain consistent with Spectrum. Image: Diagram tracing the token \"Spectrum Button\" to a purple-to-blue gradient \"Upgrade\" button with a crown icon, and further down to a plain rounded rectangle in the same gradient with no label. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1fe9a6362a1479a1f5959aced7df1ca13884e86b1.png?width=750&format=png&optimize=medium)"
120
- },
121
- {
122
- "type": "guideline",
123
- "content": "Prioritize semantic tokens.\n\nStart with semantic tokens whenever possible. They communicate intent and context, making design decisions easier to understand, reuse, and maintain over time. Image: Diagram connecting the token \"background-layer-2-color\" to the light gray toolbar background of a Photoshop-style document window, showing a hamburger menu, the Photoshop app icon, \"Document\" text, and a cloud icon. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1b62af86b141ebe7a61e41687f36c25c542915749.png?width=750&format=png&optimize=medium)Image: Diagram connecting the token \"gray-25\" to the light gray toolbar background of a Photoshop-style document window, showing a hamburger menu, the Photoshop app icon, \"Document\" text, and a cloud icon. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1c851b0861fdf571ce6a19a98cbca1ef0be7c5f48.png?width=750&format=png&optimize=medium)"
124
- },
125
- {
126
- "type": "guideline",
127
- "content": "Use primitive tokens only when necessary.\n\nPrimitive tokens define important building blocks of the design language but contain less contextual meaning. Use them only when no appropriate semantic decision exists. Image: Diagram connecting the token \"static-fuchsia-900,\" shown as a purple circle swatch, to a purple-to-blue gradient \"Upgrade\" button with a crown icon. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1ddaad670f23bdc8178d3642bf345d2c4bb13737a.png?width=750&format=png&optimize=medium)"
128
- },
129
- {
130
- "type": "guideline",
131
- "content": "Use component-specific tokens only for their intended component.\n\nComponent-specific tokens are intentionally limited. Use them only for their intended component or implementation and avoid reusing them as general-purpose design decisions. Image: Diagram showing the token \"tab-gap-horizontal-medium\" pointing to the pink-highlighted gap between two radio button labels in a UI example. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1de0d50e78fdc61dfc5ba6ac5e78ab4db2ea9bbdf.png?width=750&format=png&optimize=medium)Image: Diagram showing the token \"tab-gap-horizontal-medium\" pointing to the pink-highlighted gap between two colorful gradient card components, each with a card title and description. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_111549edcd66a118c25888112eb46457758a1d42d.png?width=750&format=png&optimize=medium)"
132
- },
133
- {
134
- "type": "guideline",
135
- "content": "Foundational tokens are shared design decisions that form the common language of Spectrum. They serve as the source of truth across products, platforms, and implementations."
136
- },
137
- {
138
- "type": "guideline",
139
- "content": "Platform tokens support the unique requirements of a specific platform implementation. They allow platforms to adapt shared design decisions to their own needs while remaining connected to the broader Spectrum design language."
140
- },
141
- {
142
- "type": "guideline",
143
- "content": "Shared language, flexible implementation.\n\nNot every platform needs every foundational token, and token values may differ between platforms to support differences in sizing, density, theming, or platform capabilities. Even when implementations differ, they remain rooted in the same taxonomy, terminology, and design language. Image: Diagram illustrating a design system's flexible structure: a purple diamond labeled \"Spectrum Foundations\" and a green pentagon labeled \"Platform\" combine under \"Flexible implementation,\" where the shapes overlap with dashed red gaps highlighted, resulting in \"Spectrum Platform\" — a purple pentagon that fully fills the green pentagon's shape. (source: https://preview.spectrum.adobe.com/foundations/design-data/media_1098f8070212b263e4d2aaeae48257cb8a3c74623.png?width=750&format=png&optimize=medium)Design data can be re-shaped to fit platform needs while maintaining system cohesion."
144
- }
145
- ],
146
- "sourceUrl": "https://preview.spectrum.adobe.com/foundations/design-data/design-tokens",
147
- "lastUpdated": "2026-08-14",
148
- "status": "published",
149
- "tags": [
150
- "design tokens",
151
- "token taxonomy",
152
- "aliasing",
153
- "semantic design",
154
- "color",
155
- "spacing",
156
- "typography"
157
- ]
158
- }
@@ -1,68 +0,0 @@
1
- {
2
- "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
- "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/drop-shadow.json",
4
- "name": "drop-shadow",
5
- "title": "Drop shadow",
6
- "category": "designing",
7
- "documentBlocks": [
8
- { "type": "purpose", "content": "Drop shadow" },
9
- {
10
- "type": "guideline",
11
- "content": "Create elevation.\n\nUse drop shadows to indicate when content appears above other content. Shadows help establish spatial relationships between interface elements and reinforce the visual hierarchy of the interface."
12
- },
13
- {
14
- "type": "guideline",
15
- "content": "Support emphasis.\n\nDrop shadows can also be used to emphasize important interface elements. When applied sparingly, they help guide attention while maintaining a clear and consistent visual hierarchy."
16
- },
17
- { "type": "guideline", "content": "Drop shadow details" },
18
- {
19
- "type": "guideline",
20
- "content": "Image: A stack of three rounded diamond shapes labeled 1, 2, and 3, illustrating the layered composition of a drop shadow effect. (source: https://preview.spectrum.adobe.com/foundations/styles/object-styles/media_1e55ad9fc6b8cfceff097a32b46183149d33d9353.png?width=750&format=png&optimize=medium)"
21
- },
22
- {
23
- "type": "guideline",
24
- "content": "Composition.\n\nSpectrum drop shadows are composed of three layers that work together to create a natural sense of depth while preserving the shape of the component. Key shadow Defines the edge of the component against the background. Transition shadow Softens the transition between the key and ambient shadows to create a smoother appearance. Ambient shadow Creates the overall sense of depth and determines the total size of the shadow."
25
- },
26
- {
27
- "type": "guideline",
28
- "content": "Image: A dark-theme context menu titled \"Publish and export\" with options for Quick export, Open a copy, and Share link, showing a submenu with Illustrator for iPad and Illustrator desktop, each panel using shadow to convey layering. (source: https://preview.spectrum.adobe.com/foundations/styles/object-styles/media_1a3fef3a1425a17547ec0a976a66ac1b4fbf475bd.png?width=750&format=png&optimize=medium)"
29
- },
30
- {
31
- "type": "guideline",
32
- "content": "Dark theme.\n\nDrop shadows continue to communicate elevation in dark theme, but their appearance is adjusted to maintain sufficient contrast against darker surfaces. Dark theme shadows use three times the opacity of their light theme equivalents. Components that appear above other content, such as popovers, also use a border in dark theme to provide additional separation from the background."
33
- },
34
- {
35
- "type": "guideline",
36
- "content": "Image: A card UI with an image header and placeholder text lines, shown with a drop shadow against a gray background to illustrate shadow overlay on a light surface. (source: https://preview.spectrum.adobe.com/foundations/styles/object-styles/media_16e79c0908d8d8b02aeb26adfa231019beaac6661.png?width=750&format=png&optimize=medium)"
37
- },
38
- {
39
- "type": "guideline",
40
- "content": "Overlay.\n\nAn overlay communicates elevation by visually separating foreground content from the rest of the interface. When an overlay is used, such as behind a dialog, an additional drop shadow isn't needed because the overlay already establishes the elevated relationship."
41
- },
42
- {
43
- "type": "guideline",
44
- "content": "Platform availability.\n\nThese tokens are currently available on web. Guidance for additional platforms will be added in a future release."
45
- },
46
- {
47
- "type": "guideline",
48
- "content": "Shadow styles.\n\nEach shadow style is represented by a single composite token that defines the key, transition, and ambient shadow layers used to create the final drop shadow. The table below lists the values for each shadow layer: X: Horizontal offset. 0 px for all layers. Y: Vertical offset. The ambient shadow uses the largest offset. Blur: Blur radius. Each layer uses a different value to create a smooth transition between the shadow layers. Spread: Spread value. 0 px for all layers. Shadow styleTokenKey valuesTransition valuesAmbient valuesEmphasized, defaultdrop-shadow-emphasizedX = 0 Y = 0 Blur = 1 Spread = 0X = 0 Y = 1 Blur = 4 Spread = 0X = 0 Y = 2 Blur = 8 Spread = 0Emphasized, hoverdrop-shadow-emphasized-hoverX = 0 Y = 0 Blur = 2 Spread = 0X = 0 Y = 2 Blur = 6 Spread = 0X = 0 Y = 4 Blur = 12 Spread = 0Elevateddrop-shadow-elevatedX = 0 Y = 0 Blur = 2 Spread = 0X = 0 Y = 2 Blur = 6 Spread = 0X = 0 Y = 4 Blur = 12 Spread = 0Draggeddrop-shadow-draggedX = 0 Y = 0 Blur = 6 Spread = 0X = 0 Y = 6 Blur = 8 Spread = 0X = 0 Y = 12 Blur = 16 Spread = 0"
49
- },
50
- {
51
- "type": "guideline",
52
- "content": "Shadow colors.\n\nSpectrum drop shadows use black (#000000) as their base color. The perceived appearance of each shadow is created by varying its opacity and layering. In dark theme, the opacity value is 3× the opacity value of light theme. Shadow colorTokenOpacity valuesEmphasized (Key shadow) drop-shadow-emphasized-key-color 8% (light) 24% (dark)Emphasized, hover (Key shadow) drop-shadow-emphasized-hover-key-color 12% (light) 36% (dark)Elevated (Key shadow) drop-shadow-elevated-key-color 12% (light) 36% (dark)Dragged (Key shadow) drop-shadow-dragged-key-color 16% (light) 48% (dark)All styles (Ambient shadow) drop-shadow-ambient-color 8% (light) 24% (dark)All styles (Transition shadow) drop-shadow-transition-color 4% (light) 12% (dark)"
53
- }
54
- ],
55
- "sourceUrl": "https://preview.spectrum.adobe.com/foundations/styles/object-styles/drop-shadow",
56
- "lastUpdated": "2026-08-14",
57
- "status": "published",
58
- "tags": [
59
- "drop shadow",
60
- "elevation",
61
- "ambient shadow",
62
- "transition shadow",
63
- "key shadow",
64
- "dark theme",
65
- "overlay",
66
- "shadow tokens"
67
- ]
68
- }