@adobe/spectrum-design-data 3.2.3 → 3.3.0-beta.1

package/guidelines/app-frame-overview.json

@@ -8,160 +8,154 @@
     { "type": "purpose", "content": "App frame" },
     {
       "type": "guideline",
-      "content": "The app frame is the core navigation direction for Spectrum 2. It’s designed as a flexible framework that’s readily adaptable to specific product needs while still creating a shared, predictable experience across products."
+      "content": "Flexible and adaptable.\n\nThe app frame needs to be opinionated without being restrictive. It directly accounts for the needs of future Spectrum 2 products, and is also flexible enough to be readily adaptable across varying product segment needs."
     },
     {
       "type": "guideline",
-      "content": "The app frame needs to be opinionated without being restrictive. It directly accounts for the needs of future Spectrum 2 products, and is also flexible enough to be readily adaptable across varying product segment needs."
+      "content": "Cohesive and predictable.\n\nA cohesive, consistent app frame reinforces Adobe’s brand and helps users feel comfortable and familiar with our products. Predictable navigation across products is also imperative for Adobe to support users working across multiple applications — and helps people more readily learn how to use new products."
     },
     {
       "type": "guideline",
-      "content": "A cohesive, consistent app frame reinforces Adobe’s brand and helps users feel comfortable and familiar with our products. Predictable navigation across products is also imperative for Adobe to support users working across multiple applications — and helps people more readily learn how to use new products."
+      "content": "Embodies Spectrum 2.\n\nThe app frame is the main stage to showcase the Spectrum 2 style, and it reflects the core foundations and principles of the design system. It works readily with all other design system resources, is committed to complying with WCAG standards, and holds the highest standards for globalization support."
     },
     {
       "type": "guideline",
-      "content": "The app frame is the main stage to showcase the Spectrum 2 style, and it reflects the core foundations and principles of the design system. It works readily with all other design system resources, is committed to complying with WCAG standards, and holds the highest standards for globalization support."
+      "content": "Spectrum offers a high-level direction as well as a definition of which parts can be flexible and which parts need to be highly predictable. Product teams are then empowered to apply this direction in ways that make the most sense for their use cases and users. We’re designing the app frame in stages that align to the two main experiences that are shared across all Adobe products: browsing and editing. What’s currently defined here is mainly focused on the browsing context: workflows that draw attention to the content as the primary focus (examples of pages in browsing contexts include a Home or Files experience). This does overlap with the editing context, where the workflow draws attention to the canvas as the primary focus, but we’re still defining the editing context in more detail overall. This framework defines broad information architecture: the general categories of objects, and where they go in the app frame. It does not define the location or ordering of specific objects within those categories. View Spectrum Patterns for more specific information architecture by product group. For guidance on Experience Cloud products, contact the DX Unified Experience team. For guidance on Creative Cloud products, contact the CC Unified Experience team."
     },
     {
       "type": "guideline",
-      "content": "Spectrum offers a high-level direction as well as a definition of which parts can be flexible and which parts need to be highly predictable. Product teams are then empowered to apply this direction in ways that make the most sense for their use cases and users."
+      "content": "Spectrum offers a high-level direction as well as a definition of which parts can be flexible and which parts need to be highly predictable. Product teams are then empowered to apply this direction in ways that make the most sense for their use cases and users. We’re designing the app frame in stages that align to the two main experiences that are shared across all Adobe products: browsing and editing. What’s currently defined here is mainly focused on the browsing context: workflows that draw attention to the content as the primary focus (examples of pages in browsing contexts include a Home or Files experience). This does overlap with the editing context, where the workflow draws attention to the canvas as the primary focus, but we’re still defining the editing context in more detail overall. This framework defines broad information architecture: the general categories of objects, and where they go in the app frame. It does not define the location or ordering of specific objects within those categories."
     },
     {
       "type": "guideline",
-      "content": "Zones are the general areas into which certain types of actions should go. They’re not specific to components."
+      "content": "Browsing context: Zones.\n\nZones are the general areas into which certain types of actions should go. They’re not specific to components."
     },
     {
       "type": "guideline",
-      "content": "This is a general area that contains global actions, such as view actions (e.g., layout and zoom options) and supplemental features (e.g., AI Assistants). Actions here can be shown in different ways, such as using part of the content area to show actions in the header, or in a dedicated side rail. There is no single visual representation of how actions should look in this area."
+      "content": "A. Navigation zone.\n\nThis area holds the primary navigational items on a page. Navigation should be highly predictable across products. In the Spectrum 2 app frame, navigation can be shown in different ways: through the header and side navigation components, as well as through other navigational components (e.g., side navigation and tabs ) within the content area for secondary navigation."
     },
     {
       "type": "guideline",
-      "content": "This area is reserved for transient actions that are contextual to content on the page (e.g., an action bar)."
+      "content": "B. Global action zone.\n\nThis is a general area that contains global actions, such as view actions (e.g., layout and zoom options) and supplemental features (e.g., AI Assistants). Actions here can be shown in different ways, such as using part of the content area to show actions in the header, or in a dedicated side rail. There is no single visual representation of how actions should look in this area."
     },
     {
       "type": "guideline",
-      "content": "Parts of the anatomy have defined rules and behaviors. The terms used here to describe the anatomy of the app framework are for internal alignment only, and are not representative of how these parts of the app frame should be described to end users."
+      "content": "C. Contextual action zone.\n\nThis area is reserved for transient actions that are contextual to content on the page (e.g., an action bar)."
     },
     {
       "type": "guideline",
-      "content": "In the S2 app frame, gradients are only used as backgrounds in content areas — they are not used in the header (A) and navigational areas (B). This allows for greater flexibility between pages where gradients may be calling attention to different kinds of content."
+      "content": "Browsing context: Anatomy.\n\nParts of the anatomy have defined rules and behaviors. The terms used here to describe the anatomy of the app framework are for internal alignment only, and are not representative of how these parts of the app frame should be described to end users."
     },
     {
       "type": "guideline",
-      "content": "There are two variants of the side navigation state control: hamburger and panel. They should never be used at the same time."
+      "content": "A. App frame header (Navigation, required).\n\nHolds the product brand and global actions, including the universal nav. This area can include top-level navigation, and is suitable for categorizing product segments (e.g., marketing contexts) and for larger fly-outs. If there is an app frame side navigation instead, use this area for global, app-wide actions (e.g., search). View header guidelines and examples in App frame header (browsing context)."
     },
     {
       "type": "guideline",
-      "content": "Interacting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
+      "content": "B. App frame side navigation (Navigation, optional).\n\nHolds the main categories of product functionality, such as workflow-related navigational items (e.g., home, files, learn, dashboards). This navigation has specific behaviors for showing and minimizing labels. Do not use this for categorizing marketing pages. View side navigation guidelines and examples in App frame side navigation (browsing context)."
     },
     {
       "type": "guideline",
-      "content": "When hovering on the panel icon, the icon will show an animated preview of what action would be done upon interaction (either expanding or collapsing). This animation offers more context about what to expect. The placement of the panel icon is at the bottom of the app frame side navigation panel."
+      "content": "C. Content area (Required).\n\nModular space that supports multiple layout configurations. The content that goes inside this area is free and not defined by the app frame. More specific guidelines will be defined in Spectrum Patterns. Gradients, when used in this space, are applied with clear intent and strategic purpose. They should contribute to the visual hierarchy, not distract from it. And, their colors are directly tied to product brand color palettes. In the S2 app frame, gradients are only used as backgrounds in content areas — they are not used in the header (A) and navigational areas (B). This allows for greater flexibility between pages where gradients may be calling attention to different kinds of content. View side navigation guidelines and examples in App frame content area (browsing context)."
     },
+    { "type": "guideline", "content": "Anatomy examples" },
     {
       "type": "guideline",
-      "content": "To activate or deactivate the TAB, select the 9-grid icon. Once clicked on, the TAB will appear above the header. On a screen reader, if there is an alert banner present, then the visual placement from top to bottom would be alert banner, TAB, then header."
+      "content": "C. Content area (Required).\n\nModular space that supports multiple layout configurations. The content that goes inside this area is free and not defined by the app frame. Gradients, when used in this space, are applied with clear intent and strategic purpose. They should contribute to the visual hierarchy, not distract from it. And, their colors are directly tied to product brand color palettes. In the S2 app frame, gradients are only used as backgrounds in content areas — they are not used in the header (A) and navigational areas (B). This allows for greater flexibility between pages where gradients may be calling attention to different kinds of content. View side navigation guidelines and examples in App frame content area (browsing context)."
     },
     {
       "type": "guideline",
-      "content": "The placement and appearance of the TAB icon may differ across Adobe products. Not all products will utilize the TAB. The currently supported products are Adobe Home, Firefly, Express, Photoshop, Lightroom, and Acrobat."
+      "content": "Hamburger.\n\nInteracting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
     },
     {
       "type": "guideline",
-      "content": "For products that use the TAB, the side navigation state control (panel icon) will be at the bottom of the side navigation. For mobile experiences, the side navigation state control (hamburger icon) and product switcher will be in the header."
+      "content": "Panel.\n\nWhen hovering on the panel icon, the icon will show an animated preview of what action would be done upon interaction (either expanding or collapsing). This animation offers more context about what to expect. The placement of the panel icon is at the bottom of the app frame side navigation panel. Learn more about the side navigation state control’s user customization and preserve user preferences. App frame variants: Top App Bar (TAB) will go over the use cases of hamburger and panel icons."
     },
     {
       "type": "guideline",
-      "content": "The following are some common terms used at Adobe for describing the core UI elements that make up the app frame, along with some notable usage considerations. Consider this as a starting point for you to take and develop into working language that may need to be more contextual for your product. Work with your Content Strategy partners to adapt it to your needs."
+      "content": "How to use the TAB.\n\nTo activate or deactivate the TAB, select the 9-grid icon. Once clicked on, the TAB will appear above the header. On a screen reader, if there is an alert banner present, then the visual placement from top to bottom would be alert banner, TAB, then header."
     },
     {
       "type": "guideline",
-      "content": "The word “content” is general in theory but specific in application. In general, it’s a catch-all word for something that is contained in a designated space, and communicates meaning or intention. Specific to the context of the app frame, it describes that what goes into this area is at the discretion of a given situation or user experience."
+      "content": "Product-Specific Variations.\n\nThe placement and appearance of the TAB icon may differ across Adobe products. Not all products will utilize the TAB. The currently supported products are Adobe Home, Firefly, Express, Photoshop, Lightroom, and Acrobat."
     },
     {
       "type": "guideline",
-      "content": "This is a commonly used internal term, but is not recommended for describing the interface to an end user. This is because it relies upon a visual metaphor to mimic an analog concept: something that “sinks” into a UI plane, like a water well sinks into the surface of the ground."
+      "content": "TAB products (Digital Media).\n\nFor products that use the TAB, the side navigation state control (panel icon) will be at the bottom of the side navigation. For mobile experiences, the side navigation state control (hamburger icon) and product switcher will be in the header."
     },
     {
       "type": "guideline",
-      "content": "Internal jargon is important and we want to be aligned across teams, but we also need to be careful about using internal terms, externally. By “user-facing term,” we mean that user to be the “end user”: the person who encounters the UI of an Adobe experience."
+      "content": "Non-TAB products (Digital Experience and Unified Shell).\n\nFor products that don’t use the TAB, the side navigation state control will always be the hamburger icon. View the Unified Shell component (Shell Frame) in the Spectrum 2 Experience Cloud Patterns library for more information."
     },
     {
       "type": "guideline",
-      "content": "In general, if you’re creating resources for internal usage (such as design guidelines or specs), you can safely use internal jargon. If you’re creating actual product UI, you will need to ensure that you’re using the appropriate terms that will help your user best understand and navigate the interface. Use the following steps to decide on terms:"
+      "content": "Non-TAB products (Digital Experience and Unified Shell).\n\nFor products that don’t use the TAB, the side navigation state control will always be the hamburger icon."
     },
     {
       "type": "guideline",
-      "content": "What's the context — the workflow or scenario — for where a term will appear? That will help you determine who you’re speaking to, with what language."
+      "content": "Some common Adobe terms for describing the UI.\n\nThe following are some common terms used at Adobe for describing the core UI elements that make up the app frame, along with some notable usage considerations. Consider this as a starting point for you to take and develop into working language that may need to be more contextual for your product. Work with your Content Strategy partners to adapt it to your needs."
     },
     {
       "type": "guideline",
-      "content": "Different deliverables will each have their own audience. For example:"
+      "content": "Panel, Rail.\n\nPanels and rails share so many similarities in their appearance and behaviors, as well as the same root concept: an area of content, with visible boundaries, affixed to one side, that has a specific focus or intention. These are a type of container, and can be flexible in what they contain. A panel is the preferred way to describe this general concept. This is because the word borrows from the well-known analog metaphor of a “control panel”: a flat board, usually square or rectangular, where controls are fixed."
     },
     {
       "type": "guideline",
-      "content": "Are you creating something for internal builders (designers, engineers, anyone creating products) at Adobe? Or are you creating something for an external user?"
+      "content": "Content area.\n\nSpectrum refers to a designated part of a composition of components as a content area if it can support many layout options, and is flexible in what it can contain. The word “content” is general in theory but specific in application. In general, it’s a catch-all word for something that is contained in a designated space, and communicates meaning or intention. Specific to the context of the app frame, it describes that what goes into this area is at the discretion of a given situation or user experience."
     },
     {
       "type": "guideline",
-      "content": "Be specific about who you’re speaking to. If you're speaking to an internal audience looking at design direction for how to build UI, that’s a different audience from the users who will ultimately work with the UI."
+      "content": "Well.\n\nA well is a type of container that is used to show non-user-editable content. It generally communicates lower-attention, supplementary information. This is a commonly used internal term, but is not recommended for describing the interface to an end user. This is because it relies upon a visual metaphor to mimic an analog concept: something that “sinks” into a UI plane, like a water well sinks into the surface of the ground."
     },
     {
       "type": "guideline",
-      "content": "Will the term appear as a UI string (such as the title of a panel)? Would it appear as a label in an image that shows the anatomy of different parts of the component?"
+      "content": "Identifying user-facing terms vs. internal-only terms.\n\nInternal jargon is important and we want to be aligned across teams, but we also need to be careful about using internal terms, externally. By “user-facing term,” we mean that user to be the “end user”: the person who encounters the UI of an Adobe experience. In general, if you’re creating resources for internal usage (such as design guidelines or specs), you can safely use internal jargon. If you’re creating actual product UI, you will need to ensure that you’re using the appropriate terms that will help your user best understand and navigate the interface. Use the following steps to decide on terms:"
     },
     {
       "type": "guideline",
-      "content": "The main focus for most users is on the content — the information being shown, and the actions to select from — rather than where or the means by which the action is contained."
+      "content": "Note your context.\n\nWhat's the context — the workflow or scenario — for where a term will appear? That will help you determine who you’re speaking to, with what language. Different deliverables will each have their own audience. For example: A label on a button in a UI mock, in Figma: end user Technical specs that show how to build UI: Adobe engineer Design guidelines that show assemblages of components: Adobe designer"
     },
     {
       "type": "guideline",
-      "content": "This app framework intentionally uses the anatomy term “content area” to describe the main information or main focus in a given view, because it’s a flexible area that’s contextual to the main view of a given place in a user’s workflow."
+      "content": "Assess your audience.\n\nAre you creating something for internal builders (designers, engineers, anyone creating products) at Adobe? Or are you creating something for an external user? Be specific about who you’re speaking to. If you're speaking to an internal audience looking at design direction for how to build UI, that’s a different audience from the users who will ultimately work with the UI."
     },
     {
       "type": "guideline",
-      "content": "To create more inclusive products, describe parts of the UI in terms of function (what something does, or what something is) rather than appearance or position (such as relative direction: left, right, top, bottom)."
+      "content": "Identify where the term will appear.\n\nWill the term appear as a UI string (such as the title of a panel)? Would it appear as a label in an image that shows the anatomy of different parts of the component? It’s generally OK to say things like \"left rail\" or “side panel” descriptively in day-to-day work conversation, but be careful about using that description in an end user/customer facing capacity. Review Creating accessible app frame terminology for more guidance."
     },
     {
       "type": "guideline",
-      "content": "Describe the actions or items available."
+      "content": "Focus on the content, not the container.\n\nThe main focus for most users is on the content — the information being shown, and the actions to select from — rather than where or the means by which the action is contained. This app framework intentionally uses the anatomy term “content area” to describe the main information or main focus in a given view, because it’s a flexible area that’s contextual to the main view of a given place in a user’s workflow."
     },
     {
       "type": "guideline",
-      "content": "Avoid describing where to find specific items or actions in relation to UI construction."
+      "content": "Avoid terms of relative direction or appearance.\n\nTo create more inclusive products, describe parts of the UI in terms of function (what something does, or what something is) rather than appearance or position (such as relative direction: left, right, top, bottom). Talk about the actions available or the names of the features inside of a part of the interface, rather than how the interface itself looks. View the Spectrum Inclusive UX writing guide for more guidelines and examples. Describe the actions or items available.Avoid describing where to find specific items or actions in relation to UI construction."
     },
     {
       "type": "guideline",
-      "content": "The word panel is acceptable as a user-facing term only when there is no other way to describe the interface."
+      "content": "Using “panel” and “rail” as user-facing terms.\n\nThe word panel is acceptable as a user-facing term only when there is no other way to describe the interface. The word rail is acceptable to use as internal jargon, but it should never be used as a user-facing term. This is because the word is about how something looks: a long, straight divider, like a slide rule or a railroad track. View the Spectrum in-product word list for more details and usage notes about these and other terms to refer to parts of the interface. Describe the action to take on the UI.Don’t describe the UI itself."
     },
     {
       "type": "guideline",
-      "content": "The word rail is acceptable to use as internal jargon, but it should never be used as a user-facing term. This is because the word is about how something looks: a long, straight divider, like a slide rule or a railroad track."
+      "content": "“Show” and “Hide”.\n\n“Show” and “hide” are the preferred terms to use to describe the open/close actions on the side navigation. This is for several reasons: Globalization readiness. The words “show” and “hide” both have low character counts in U.S. English, and are the most common already-existing terms to express this concept across Adobe products. Plain language. “Hide” is more straightforward and common language than “Minimize,” and is also at the appropriate reading level for UI text. Conceptual accuracy. “Show” and “Hide” better align to their associated actions; items aren’t disappearing completely from view, but are being tucked away or are changing appearance."
     },
     {
       "type": "guideline",
-      "content": "Describe the action to take on the UI."
+      "content": "When in doubt, use sentence case.\n\nAs you’re designing the UI content of your app frame using this framework, follow the Spectrum content standards for all UI text and labels. Most of the writing you’ll be doing for the app frame will be short labels. These, as well as all other UI content, are formatted in sentence case: only the first letter of the first word is capitalized. View the Spectrum Grammar and mechanics page."
     },
-    { "type": "guideline", "content": "Don’t describe the UI itself." },
     {
       "type": "guideline",
-      "content": "“Show” and “hide” are the preferred terms to use to describe the open/close actions on the side navigation. This is for several reasons:"
-    },
-    {
-      "type": "guideline",
-      "content": "As you’re designing the UI content of your app frame using this framework, follow the Spectrum content standards for all UI text and labels."
-    },
-    {
-      "type": "guideline",
-      "content": "Most of the components that will go into your app frame design have their own associated content standards:"
+      "content": "Refer to Spectrum Patterns.\n\nThere may be particular content standards or specific writing scenarios that are designed for your product. Defer to these product-specific terms and language preferences. Check the Spectrum Patterns documentation for product-specific writing guidelines, or ask your team’s Content Strategist for more resources."
     }
   ],
-  "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-overview/",
-  "lastUpdated": "2026-02-02",
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/app-frame/overview",
+  "lastUpdated": "2026-09-04",
   "status": "published",
-  "tags": ["designing"],
-  "related": [
-    { "ref": "containers" },
-    { "ref": "s2-app-frame-header-browsing-context" }
+  "tags": [
+    "App frame",
+    "Framework",
+    "Navigation",
+    "Browsing context",
+    "Editing context"
   ]
 }

package/guidelines/applying-the-type-system.json

@@ -0,0 +1,63 @@
+{
+  "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
+  "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/applying-the-type-system.json",
+  "name": "applying-the-type-system",
+  "title": "Applying the type system",
+  "category": "designing",
+  "documentBlocks": [
+    { "type": "purpose", "content": "Applying the type system" },
+    {
+      "type": "guideline",
+      "content": "Card.\n\nIn this card example, Title and Body text styles are used together to establish a clear visual hierarchy, helping users quickly identify the primary content while keeping supporting information easy to scan. Title S The card title uses the Title style to establish the primary focus of the card. It provides strong visual emphasis, making it easy for users to quickly identify and scan content across multiple cards. Body XS The supporting description uses the Body style because it provides additional context without competing with the title. Its lighter weight and smaller size reinforce the content hierarchy while maintaining readability. The body text is presented in gray-700 to further distinguish it as secondary information and keep attention on the primary title."
+    },
+    {
+      "type": "guideline",
+      "content": "Page section.\n\nSpectrum's type scale creates a clear visual hierarchy that naturally guides the eye through the page. By assigning each type style a distinct role, Spectrum organizes information into predictable patterns that make content easier to scan and understand. Title M Heading XXL Body M Body S Component M, used in a button group"
+    },
+    {
+      "type": "guideline",
+      "content": "Mobile browsing.\n\nThe same typography principles scale across screen sizes. On native mobile platforms, Spectrum preserves a clear visual hierarchy by adapting type styles to smaller layouts while maintaining consistent relationships between headings, supporting content, and actions. Heading L Title L Body XS Body S Monospace number / Body XXS"
+    },
+    {
+      "type": "guideline",
+      "content": "All-caps.\n\nAll-caps styles are not recommended for usage within UI components because it does not support accessibility requirements An all-caps style can still be used sparingly and strategically in use cases where longform content is the primary experience (like a blog post or a marketing website). All-caps text brings a heavier, punctuated feel to letterforms and adds visual impact to single words or short, standalone phrases."
+    },
+    {
+      "type": "guideline",
+      "content": "Use Spectrum font sizes.\n\nChoose from Spectrum's defined font sizes. By using unique font sizes, you risk upsetting the hierarchy and balance of typography in your product."
+    },
+    {
+      "type": "guideline",
+      "content": "Respect capitalization rules.\n\nUse sentence case for all UX content. For more on capitalization guidelines, go to Grammar and mechanics."
+    },
+    {
+      "type": "guideline",
+      "content": "Use tabular numbers for numerical data.\n\nNumbers within components should be tabular with lining figures. In tables, numbers should be right aligned to make numerical data easier to read and compare. This is used, for example, in tables, time stamps, and bar loaders. This is supported by Adobe Clean (via the Monospace uppercase option in Figma, the OpenType panel in Illustrator, or the CSS font feature settings). For iOS and Android, use the Spectrum Monospace numbers type styles."
+    },
+    {
+      "type": "do-dont",
+      "content": "Don't let paragraph widths get too thin",
+      "dont": "Paragraphs of text that are too long are difficult to follow, and paragraphs of text that are too thin are difficult to read. Ideally, blocks of text should be roughly 70 characters wide. Be sure to keep them at least between 50 and 120 characters wide."
+    },
+    {
+      "type": "guideline",
+      "content": "Keep content short and to the point.\n\nKeep paragraphs concise. Some users with cognitive disabilities (and even those who don't) can have a very difficult time reading and comprehending large blocks of text."
+    },
+    {
+      "type": "do-dont",
+      "content": "Don't fully-justify text",
+      "dont": "Do not use fully-justified blocks of text. This adds trapped white space within paragraphs, which makes it harder to read, especially for those with cognitive disabilities or dyslexia. Right alignment (left rag) is also discouraged for paragraphs of text."
+    }
+  ],
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/typography/applying-the-type-system",
+  "lastUpdated": "2026-08-13",
+  "status": "published",
+  "tags": [
+    "typography",
+    "visual hierarchy",
+    "readability",
+    "font sizes",
+    "monospace numbers",
+    "tabular numbers"
+  ]
+}

package/guidelines/attention-hierarchy.json

@@ -8,15 +8,7 @@
     { "type": "purpose", "content": "Attention hierarchy" },
     {
       "type": "guideline",
-      "content": "Design systems are ultimately communication systems. A main goal of any kind of UI communication — visual, linguistic, motion, and more — is to convey a message in a way that the audience can readily understand what they need to know and why it matters. And most importantly, communication needs to be respectful of user attention."
-    },
-    {
-      "type": "guideline",
-      "content": "**Attention hierarchy** is a core concept in Spectrum 2. This idea has always been a part of Spectrum as a design system — and a tenet of responsible UX design as a whole — but it's now more formalized as a way to validate assumptions using clear guidelines and considerations. It's based on the methods of typographic hierarchy, where scale, size, and text pairings help readers to readily recognize what's the most broad and important information to the most detailed and nice-to-know information. We've extended this practice beyond just text and into all the ways that UI communicates."
-    },
-    {
-      "type": "guideline",
-      "content": "Another way to think of attention hierarchy is as a way to manage the ratio of signal-to-noise in an experience. Different parts of the UI all communicate meaning, at different levels of attention. High attention elements show a primary area of focus, and communicate timely, high-signal meanings. Low attention elements blend into the background, and communicate more utilitarian, lower-priority meanings. Things like object styles, component options, and typography all draw different levels of attention."
+      "content": "Attention hierarchy is a core concept in Spectrum 2. This idea has always been a part of Spectrum as a design system — and a tenet of responsible UX design as a whole — but it’s now more formalized as a way to validate assumptions using clear guidelines and considerations. It’s based on the methods of typographic hierarchy, where scale, size, and text pairings help readers to readily recognize what’s the most broad and important information to the most detailed and nice-to-know information. We’ve extended this practice beyond just text and into all the ways that UI communicates. Another way to think of attention hierarchy is as a way to manage the ratio of signal-to-noise in an experience. Different parts of the UI all communicate meaning, at different levels of attention. High attention elements show a primary area of focus, and communicate timely, high-signal meanings. Low attention elements blend into the background, and communicate more utilitarian, lower-priority meanings. Things like object styles, component options, and typography all draw different levels of attention."
     },
     {
       "type": "guideline",
@@ -24,19 +16,18 @@
     },
     {
       "type": "guideline",
-      "content": "As a general rule, only one element or group of elements should have high attention on a page. Too many elements drawing high attention makes it difficult to focus."
-    },
-    {
-      "type": "guideline",
-      "content": "**Good example:** The \"Share\" button is the most timely and high-impact action to take in this example. It's high attention because the next step after finishing creating something within the canvas would be to share it."
-    },
-    {
-      "type": "guideline",
-      "content": "**Bad example:** The \"Share\" button is competing with the selected states of items in the navigation. These navigational items are still important for communicating wayfinding and context, but are not as timely as the action of sharing."
+      "content": "As a general rule, only one element or group of elements should have high attention on a page. Too many elements drawing high attention makes it difficult to focus. The plus button is the most timely and high impact action to take in this example.Selected state of items in the navigation is competing with the plus button."
     }
   ],
-  "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/attention-hierarchy/",
-  "lastUpdated": "2026-02-02",
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/attention-hierarchy",
+  "lastUpdated": "2026-08-24",
   "status": "published",
-  "tags": ["designing"]
+  "tags": [
+    "attention hierarchy",
+    "high attention",
+    "low attention",
+    "UI communication",
+    "elevation",
+    "contrast"
+  ]
 }

package/guidelines/background-layers.json

@@ -5,9 +5,22 @@
   "title": "Background layers",
   "category": "designing",
   "documentBlocks": [
+    { "type": "purpose", "content": "Background layers" },
     {
-      "type": "purpose",
-      "content": "Layer 1 can be used as the app frame color in professional editing applications, which require additional depth differentiation."
+      "type": "guideline",
+      "content": "In Spectrum, background layers are used differently depending on the primary context of the page. For pages where the primary purpose is the canvas and related actions for editing, view Editing contexts. For pages where the primary focus is browsing content, such as a Home or Files experience, view Browsing contexts. If you’re not sure whether a page is in an editing or browsing context, contact the Spectrum design team. In addition to the three existing background layer options — background layer 1, background layer 2, and background base — Spectrum includes an elevated option. Elevated background layers create depth and emphasize content floating on top of a canvas. Background layer Light theme Dark theme Elevatedgray-25 (with drop shadow)gray-75 (with drop shadow)Layer 2gray-25gray-75Layer 1gray-50gray-50Pasteboardgray-100gray-25"
+    },
+    {
+      "type": "guideline",
+      "content": "Overview.\n\nIn Spectrum, background layers are used differently depending on the primary context of the page. For pages where the primary purpose is the canvas and related actions for editing, view Editing contexts. For pages where the primary focus is browsing content, such as a Home or Files experience, view Browsing contexts. If you’re not sure whether a page is in an editing or browsing context, contact the Spectrum design team."
+    },
+    {
+      "type": "guideline",
+      "content": "Editing application.\n\nPages in editing contexts draw attention to the canvas, which is the primary focus."
+    },
+    {
+      "type": "guideline",
+      "content": "Elevated (highest attention).\n\nElevated backgrounds create the illusion of depth through the use of a drop shadow, and display content that appears on top of other content. They draw attention and are used sparingly. In an editing application, this background option works well for parts of the app frame that appear on top of the canvas, such as a floating toolbar, panel, or popover."
     },
     {
       "type": "guideline",
@@ -15,24 +28,45 @@
     },
     {
       "type": "guideline",
-      "content": "The pasteboard has a dedicated background layer. This is because no components are placed directly on top of it, with the exception of an artboard (which uses a white background color). Other components should be placed on a layer 1, layer 2, or elevated background."
+      "content": "Pasteboard.\n\nThe pasteboard has a dedicated background layer. This is because no components are placed directly on top of it, with the exception of an artboard (which uses a white background color). Other components should be placed on a layer 1, layer 2, or elevated background."
+    },
+    {
+      "type": "guideline",
+      "content": "Layer 1 can be used as the app frame color in professional editing applications, which require additional depth differentiation."
+    },
+    {
+      "type": "guideline",
+      "content": "Pasteboard.\n\nThe pasteboard has a dedicated background layer. This is because no components are placed directly on top of it, with the exception of an artboard (which uses a white background color)."
+    },
+    {
+      "type": "guideline",
+      "content": "Elevated (highest attention).\n\nElevated backgrounds create the illusion of depth through the use of a drop shadow, and display content that appears on top of other content. They draw attention and are used sparingly. In browsing contexts, this background layer style is used in components like menus and tooltips."
     },
     {
       "type": "guideline",
-      "content": "This example shows an editing application using background layer 2 for both the artboard and the app frame. An elevated background is used for a floating toolbar, which appears on top of the canvas."
+      "content": "Layer 2 is used to group related content together and to create separation from the primary content on a page, such as in the background of the app frame."
     },
     {
       "type": "guideline",
-      "content": "Spectrum 2 uses gray-25 as the base background color to draw attention to the primary content of a page. Using gray-25 allows for higher contrast between the background and content, and it provides a blank canvas for more vibrant colors."
+      "content": "Base.\n\nSpectrum 2 uses gray-25 as the base background color to draw attention to the primary content of a page. Using gray-25 allows for higher contrast between the background and content, and it provides a blank canvas for more vibrant colors. For using a drop shadow to draw emphasis to a container that isn’t elevated, view container emphasis. Background layer Light theme Dark theme Elevatedgray-25 (with drop shadow)gray-75 (with drop shadow)Layer 2gray-25gray-75Layer 1gray-50gray-50Pasteboardgray-100gray-25"
     },
     {
       "type": "guideline",
-      "content": "In dark theme, the primary background (using the background base layer) is the darkest color. This allows for more flexibility for the grays that are layered on top of it, and provides contrast for more vibrant user-created content."
+      "content": "Professional editing applications have the option to use background layer 1 for the app frame in order to create additional depth differentiation. To create separation for toolbars and panels that meet at the edges, include a border in size medium that matches the pasteboard color. In dark theme, the primary background (using the background base layer) is the darkest color. This allows for more flexibility for the grays that are layered on top of it, and provides contrast for more vibrant user-created content. This example shows containers that are emphasized to draw attention. They don’t use the elevated background because they don’t appear on top of other content. View container emphasis for more context.This example shows an editing application using background layer 2 for both the artboard and the app frame. An elevated background is used for a floating toolbar, which appears above the canvas."
     }
   ],
-  "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/background-layers/",
-  "lastUpdated": "2026-02-02",
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/color/background-layers",
+  "lastUpdated": "2026-08-13",
   "status": "published",
-  "tags": ["designing"],
-  "related": [{ "ref": "colors" }, { "ref": "typography-fundamentals" }]
+  "tags": [
+    "background layers",
+    "elevated background",
+    "editing contexts",
+    "browsing contexts",
+    "canvas",
+    "Layer 1",
+    "Layer 2",
+    "Pasteboard",
+    "artboard"
+  ]
 }

package/guidelines/bi-directionality.json

@@ -0,0 +1,57 @@
+{
+  "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
+  "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/bi-directionality.json",
+  "name": "bi-directionality",
+  "title": "Bi-directionality",
+  "category": "designing",
+  "documentBlocks": [
+    { "type": "purpose", "content": "Bi-directionality" },
+    {
+      "type": "guideline",
+      "content": "In digital experiences, languages that are based on Latin script (e.g., English and French), Cyrillic script (e.g., Russian and Bulgarian), Chinese and Japanese* are consistently read and written from left to right. Languages that are based on certain writing systems like Arabic (e.g., Arabic, Persian, and Urdu) and Hebrew (Hebrew and Yiddish), are mostly read and written from right to left. These languages are called “bi-directional,” or are also commonly referred to as “RTL” (“right-to-left”) languages. Digital experiences for these languages should be mirrored to follow the same right-to-left reading pattern. UI mirroring is the process of positioning components in the opposite side of the interface, which creates, as the term suggests, a mirror-like effect. * Chinese and Japanese, especially in printing, books, and publications, maintain their top-to-bottom, right-to-left writing/reading patterns, but are mainly using the left-to-right system in digital experiences."
+    },
+    {
+      "type": "guideline",
+      "content": "Mirror individual components.\n\nComponents and their constituting parts are affected by user interface mirroring. Mirroring guidelines for each component are available on their respective pages, when applicable."
+    },
+    {
+      "type": "guideline",
+      "content": "Don't mirror components that represent time.\n\nComponents that are used to represent the concept of time should not be mirrored (e.g., a video player)."
+    },
+    {
+      "type": "guideline",
+      "content": "Mirror composite images with directional flow.\n\nComposite images that depict a directional flow or convey a linear narrative require a dedicated bi-directional version since the sense of the narrative, reading from right to left, could appear reversed."
+    },
+    {
+      "type": "guideline",
+      "content": "Mirror icons that represent movement.\n\nIcons that depict horizontal movement (e.g., back icon) should be mirrored to follow the flow of the right-to-left interface."
+    },
+    {
+      "type": "guideline",
+      "content": "Don't mirror icons that represent time.\n\nIcons that refer to the passage of time (e.g., clock icon) should not be mirrored in right-to-left interfaces."
+    },
+    {
+      "type": "guideline",
+      "content": "Don't mirror checkmarks.\n\nCheckmarks are never mirrored in right-to-left interfaces."
+    },
+    {
+      "type": "guideline",
+      "content": "Don't mirror slashes.\n\nSlashes are never mirrored in right-to-left interfaces."
+    }
+  ],
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/inclusivity/bi-directionality",
+  "lastUpdated": "2026-09-03",
+  "status": "published",
+  "tags": [
+    "bi-directional",
+    "RTL",
+    "UI mirroring",
+    "right-to-left",
+    "time icons",
+    "back icon",
+    "checkmarks",
+    "slashes",
+    "directional flow",
+    "iconography mirroring"
+  ]
+}

package/guidelines/border-width.json

@@ -0,0 +1,42 @@
+{
+  "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
+  "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/border-width.json",
+  "name": "border-width",
+  "title": "Border width",
+  "category": "designing",
+  "documentBlocks": [
+    { "type": "purpose", "content": "Border width" },
+    {
+      "type": "guideline",
+      "content": "Borders when necessary only.\n\nBorders are an essential way to create separation, but they can also add visual noise to an interface by filling and disrupting negative space. As a result, they should be used sparingly, only when necessary. For example, a divider might sometimes be needed to separate two distinct action button groups. Or, an object might have a border to demarcate distinct areas, such as separating a panel or card from the rest of the content on a page. Whenever possible, achieve separation through other techniques, like negative space and section titles, instead of using borders."
+    },
+    {
+      "type": "guideline",
+      "content": "Consistent border widths.\n\nBorder width is a functional design choice, not a decorative one. Use a single border width throughout the interface, and only introduce variations to the thickness to communicate meaningful change, such as focus or selection. Avoid varying border widths solely to create visual interest or hierarchy."
+    },
+    {
+      "type": "guideline",
+      "content": "Medium borders (2 px) are the default size for most contexts. Components with border options use the default medium size, as well as focus rings which appear on keyboard focus."
+    },
+    {
+      "type": "guideline",
+      "content": "Small borders (1 px) are used in specific components and patterns where there’s greater density (for example, in accordions and tables)."
+    },
+    {
+      "type": "guideline",
+      "content": "Context-dependent end caps.\n\nThe rounding of divider end caps changes depending on how the divider is used. When a divider extends to both edges of a container, it uses square ends so it meets each edge cleanly. When a divider has visible gaps at both ends, it uses fully rounded end caps."
+    },
+    {
+      "type": "guideline",
+      "content": "Grouping related actions.\n\nUse a divider to separate groups of related actions in a header. This helps distinguish global actions from actions that apply only to the current view."
+    },
+    {
+      "type": "guideline",
+      "content": "Platform availability.\n\nThese tokens are currently available on web. Guidance for additional platforms will be added in a future release. StyleTokenValueSmall border-width-100 1 pxMedium border-width-200 2 pxLarge border-width-400 4 px"
+    }
+  ],
+  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/styles/object-styles/border-width",
+  "lastUpdated": "2026-08-14",
+  "status": "published",
+  "tags": ["border width", "divider"]
+}