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

package/components/tag.json

@@ -29,15 +29,22 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabTabbing into a group of tags places the focus on the first tag (only one tag receives the keyboard focus at a time).Arrow keysMoves focus through the group of tags.Page Up or Page DownMoves focus to the previous or next tag in the group (last becomes first, and first becomes last).Home or EndMoves focus to the first or last tag in the group.Backspace or DeleteRemoves the tag in focus from the group.SpaceIf the tag is selectable, the space bar will toggle selection."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Tabbing into a group of tags places the focus on the first tag (only one tag receives the keyboard focus at a time). Arrow keys Moves focus through the group of tags. Page Up or Page Down Moves focus to the previous or next tag in the group (last becomes first, and first becomes last). Home or End Moves focus to the first or last tag in the group. Backspace or Delete Removes the tag in focus from the group. Space If the tag is selectable, the space bar will toggle selection."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Description Default (Arrow)Use the default cursor for non-interactive tags.PointerUse the pointer cursor for interactive tags, such as tags that are removable or can be used to filter content.Grab handUse the grab hand cursor when the order of tags can be rearranged.Grab fistUse the grab fist cursor when holding a tag."
+      "content": "Cursor guidelines.\n\nCursor Description Default (Arrow) Use the default cursor for non-interactive tags. Pointer Use the pointer cursor for interactive tags, such as tags that are removable or can be used to filter content. Grab hand Use the grab hand cursor when the order of tags can be rearranged. Grab fist Use the grab fist cursor when holding a tag."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 ANon‑text elements—such as icons used in tags—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function.Info and relationships, Identify purpose 1.3.1, 1.3.6 AATags should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized.Text contrast 1.4.3 AALarge text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement.Resize text 1.4.4 AATags should be built in such a way that they can be resized without assistive technology up to 200%.Non-text contrast 1.4.11 AAThe visual presentation of icons and various states have a contrast ratio of at least 3:1.Text spacing 1.4.12 AALine height of text is at least 1.5x the font size. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non‑text elements—such as icons used in tags—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function. Info and relationships, Identify purpose 1.3.1, 1.3.6 AA Tags should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized. Text contrast 1.4.3 AA Large text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement. Resize text 1.4.4 AA Tags should be built in such a way that they can be resized without assistive technology up to 200%. Non-text contrast 1.4.11 AA The visual presentation of icons and various states have a contrast ratio of at least 3:1. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
+    }
+  ],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "Tag",
+      "package": "@react-spectrum/s2"
     }
   ],
   "options": {

package/components/text-area.json

@@ -65,15 +65,22 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabTabbing into a text area selects the existing text.Shift + TabMoves focus to the previous focusable element.EnterInserts a new line at the caret position.Arrow keysMove caret through text; with Shift, extend text selection.Home / EndMove caret to start/end of line (platform behavior may vary).Ctrl/Cmd + ASelect all text in the text area. Note: Standard native text-editing shortcuts (copy, paste, undo, redo, delete, word navigation) should be preserved and not overridden."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Tabbing into a text area selects the existing text. Shift + Tab Moves focus to the previous focusable element. Enter Inserts a new line at the caret position. Arrow keys Move caret through text; with Shift, extend text selection. Home / End Move caret to start/end of line (platform behavior may vary). Ctrl/Cmd + A Select all text in the text area. Note: Standard native text-editing shortcuts (copy, paste, undo, redo, delete, word navigation) should be preserved and not overridden."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Description TextUse text cursor over editable text area content in all states.PointerAny clickable control that is part of the text area (e.g., clear/reveal/help icon) uses the pointer cursor.Move (up/down and left/right)Use while dragging the resize handle (if resizing is enabled)."
+      "content": "Cursor guidelines.\n\nCursor Description Text Use text cursor over editable text area content in all states. Pointer Any clickable control that is part of the text area (e.g., clear/reveal/help icon) uses the pointer cursor. Move (up/down and left/right) Use while dragging the resize handle (if resizing is enabled)."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 ANon-text elements, such as icons paired with a text area (validation icons, clear-input icons), must provide a text alternative. All text areas need an accessible name (via a visible label, title, aria-label, or associated text) so screen readers can announce their purpose.Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAAText areas should be understandable by assistive technologies. The label, help text, error message, and required state must be programmatically associated with the field using semantic HTML or ARIA.Contrast 1.4.3 AAThe visual presentation of text has a contrast ratio of at least 4.5:1.Resize text 1.4.4 AAText areas can be resized up to 200% without loss of content or functionality and without assistive technology.Visual presentation 1.4.8 AAAThe width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified.Non-text contrast 1.4.11 AAThe visual presentation of illustrations, icons, and component states have a contrast ratio of at least 3:1. Not applicable for empty fields.Text spacing 1.4.12 AALine height of text is at least 1.5x the font size. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non-text elements, such as icons paired with a text area (validation icons, clear-input icons), must provide a text alternative. All text areas need an accessible name (via a visible label, title, aria-label, or associated text) so screen readers can announce their purpose. Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAA Text areas should be understandable by assistive technologies. The label, help text, error message, and required state must be programmatically associated with the field using semantic HTML or ARIA. Contrast 1.4.3 AA The visual presentation of text has a contrast ratio of at least 4.5:1. Resize text 1.4.4 AA Text areas can be resized up to 200% without loss of content or functionality and without assistive technology. Visual presentation 1.4.8 AAA The width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified. Non-text contrast 1.4.11 AA The visual presentation of illustrations, icons, and component states have a contrast ratio of at least 3:1. Not applicable for empty fields. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
+    }
+  ],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "TextArea",
+      "package": "@react-spectrum/s2"
     }
   ],
   "options": {

package/components/text-field.json

@@ -36,7 +36,7 @@
     },
     {
       "type": "guideline",
-      "content": "Review label-less designs.\n\nIn rare cases where context is sufficient and a label could be absent, make sure to have the design reviewed and approved by an accessibility expert. These should still include an aria-label in HTML (depending on the context, aria-label or aria-labelledby )."
+      "content": "Review label-less designs.\n\nIn rare cases where context is sufficient and a label could be absent, make sure to have the design reviewed and approved by an accessibility expert. These should still include an aria-label in HTML (depending on the context, aria-label or aria-labelledby)."
     },
     {
       "type": "guideline",
@@ -69,15 +69,22 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabTabbing into a text field moves focus into the field and selects the existing text.Shift + TabMoves focus to the previous focusable element.Printable charactersInserts text at the caret position.Left / Right ArrowMoves caret one character left/right.Home / EndMoves caret to start/end of field value.Backspace / DeleteRemoves character before/after caret.Ctrl / Cmd + ASelects all text.EnterSubmits the enclosing form or triggers the form’s default action (implementation/context dependent)."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Tabbing into a text field moves focus into the field and selects the existing text. Shift + Tab Moves focus to the previous focusable element. Printable characters Inserts text at the caret position. Left / Right Arrow Moves caret one character left/right. Home / End Moves caret to start/end of field value. Backspace / Delete Removes character before/after caret. Ctrl / Cmd + A Selects all text. Enter Submits the enclosing form or triggers the form’s default action (implementation/context dependent)."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Description TextUse over the field to indicate to the user that text is editable within the field.PointerAny clickable control that is part of the text field (e.g., clear/reveal/help icon) uses the pointer cursor."
+      "content": "Cursor guidelines.\n\nCursor Description Text Use over the field to indicate to the user that text is editable within the field. Pointer Any clickable control that is part of the text field (e.g., clear/reveal/help icon) uses the pointer cursor."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 ANon-text elements, such as icons used inside text fields (e.g., validation, clear, or affordance icons), must provide a text alternative that communicates their purpose. All text fields need an accessible name so screen readers can announce their function.Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAAText fields and their labels, descriptions, and error messages should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized.Contrast 1.4.3 AAThe visual presentation of text has a contrast ratio of at least 4.5:1.Resize text 1.4.4 AAText fields can be resized up to 200% without loss of content or functionality and without assistive technology.Visual presentation 1.4.8 AAAThe width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified.Non-text contrast 1.4.11 AAThe visual presentation of illustrations, icons, and component states have a contrast ratio of at least 3:1. Not applicable for empty fields.Text spacing 1.4.12 AALine height of text is at least 1.5x the font size. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non-text elements, such as icons used inside text fields (e.g., validation, clear, or affordance icons), must provide a text alternative that communicates their purpose. All text fields need an accessible name so screen readers can announce their function. Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAA Text fields and their labels, descriptions, and error messages should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized. Contrast 1.4.3 AA The visual presentation of text has a contrast ratio of at least 4.5:1. Resize text 1.4.4 AA Text fields can be resized up to 200% without loss of content or functionality and without assistive technology. Visual presentation 1.4.8 AAA The width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified. Non-text contrast 1.4.11 AA The visual presentation of illustrations, icons, and component states have a contrast ratio of at least 3:1. Not applicable for empty fields. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
+    }
+  ],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "TextField",
+      "package": "@react-spectrum/s2"
     }
   ],
   "options": {

package/components/time-field.json

@@ -9,5 +9,12 @@
     "category": "inputs",
     "documentationUrl": "https://spectrum.adobe.com/page/time-field/"
   },
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "TimeField",
+      "package": "@react-spectrum/s2"
+    }
+  ],
   "lifecycle": { "introduced": "1.0.0-draft" }
 }

package/components/toast.json

@@ -42,19 +42,23 @@
     },
     {
       "type": "guideline",
-      "content": "Multiple toasts.\n\nToasts are designed for brief, non-intrusive, and temporary notifications. While displaying multiple toasts is available via the React Spectrum implementation, we still discourage triggering multiple toasts simultaneously when possible, as this can be very distracting to the user. Frequent interruptions interfere with usability, especially for people with visual and cognitive disabilities (see WCAG Success Criterion 2.2.4 Interruptions ). Products should allow for users to be able turn off all types of alerts. Doing this helps people who want to focus and minimize information that they may find non-essential."
+      "content": "Multiple toasts.\n\nToasts are designed for brief, non-intrusive, and temporary notifications. While displaying multiple toasts is available via the React Spectrum implementation, we still discourage triggering multiple toasts simultaneously when possible, as this can be very distracting to the user. Frequent interruptions interfere with usability, especially for people with visual and cognitive disabilities (see WCAG Success Criterion 2.2.4 Interruptions). Products should allow for users to be able turn off all types of alerts. Doing this helps people who want to focus and minimize information that they may find non-essential."
     },
     {
       "type": "guideline",
-      "content": "Confirmation.\n\nFor a confirmation message ( neutral and positive variants), use a short past participle verb phrase: (optional) noun + verb ending in -ed + (optional) prepositional phrase with more information. If you refer to an interface element directly, put its name in bold text."
+      "content": "Writing for toasts depends on the nature of the message, whether it's communicating confirmation, information, or an error. For all kinds of toasts, keep the text to fewer than 2 lines in English, since it will become longer when localized."
     },
     {
       "type": "guideline",
-      "content": "Informational.\n\nFor an informational message ( informative variant ), write in a complete sentence following the formula of subject + verb phrase + optional additional information."
+      "content": "Confirmation.\n\nFor a confirmation message (neutral and positive variants), use a short past participle verb phrase: (optional) noun + verb ending in -ed + (optional) prepositional phrase with more information. If you refer to an interface element directly, put its name in bold text."
     },
     {
       "type": "guideline",
-      "content": "Error.\n\nFor an error message ( negative variant), use a short phrase — it can be a complete sentence or not — to describe what's happening as succinctly as possible. Whenever possible, include an in-line action for a user to take so that they can readily address the issue explained in the message."
+      "content": "Informational.\n\nFor an informational message (informative variant), write in a complete sentence following the formula of subject + verb phrase + optional additional information."
+    },
+    {
+      "type": "guideline",
+      "content": "Error.\n\nFor an error message (negative variant), use a short phrase — it can be a complete sentence or not — to describe what's happening as succinctly as possible. Whenever possible, include an in-line action for a user to take so that they can readily address the issue explained in the message."
     },
     {
       "type": "guideline",
@@ -74,15 +78,15 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabPlaces the focus on the next interactive element, which is either a button or a close button.Shift + TabPlaces the focus on the previous interactive element, which is either a button or a close button.Space or EnterIf focus is on the close button, dismisses the toast. If focus is on the button, executes the button action.EscDismisses the toast. This is equivalent to selecting the close button."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Places the focus on the next interactive element, which is either a button or a close button. Shift + Tab Places the focus on the previous interactive element, which is either a button or a close button. Space or Enter If focus is on the close button, dismisses the toast. If focus is on the button, executes the button action. Esc Dismisses the toast. This is equivalent to selecting the close button."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Usage Default (Arrow)Use the default cursor for non-interactive areas on the toast.PointerUse the pointer cursor for interactive areas on the toast such as the close button."
+      "content": "Cursor guidelines.\n\nCursor Usage Default (Arrow) Use the default cursor for non-interactive areas on the toast. Pointer Use the pointer cursor for interactive areas on the toast such as the close button."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 ANon‑text elements—such as icons used in toasts—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function.Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAAToasts should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized.Use of color 1.4.1 AColor is never used as the sole way to convey meaning in toasts. Toasts use color to reinforce their meaning, but every toast also includes a clear text description that communicates purpose.Text contrast minimums 1.4.3 AALarge text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement.Visual presentation 1.4.8 AAAThe width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified.Non-text contrast 1.4.11 AAThe visual presentation of icons have a contrast ratio of at least 3:1.Text spacing 1.4.12 AALine height of text is at least 1.5x the font size.Text spacing1.4.12AALine height of text is at least 1.5x the font size in wrapped tooltips. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Timing adjustable 2.2.1 AToasts should not auto-dismiss. If they do, users need a way to extend, pause, or dismiss time-limited content. Hovering, clicking, or keyboard focusing on the toast should keep it from disappearing.Seizures and physical feactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non‑text elements—such as icons used in toasts—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function. Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAA Toasts should be understandable by assistive technologies like screen readers. This means the proper semantic HTML or ARIA role should be utilized. Use of color 1.4.1 A Color is never used as the sole way to convey meaning in toasts. Toasts use color to reinforce their meaning, but every toast also includes a clear text description that communicates purpose. Text contrast minimums 1.4.3 AA Large text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement. Visual presentation 1.4.8 AAA The width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified. Non-text contrast 1.4.11 AA The visual presentation of icons have a contrast ratio of at least 3:1. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size in wrapped tooltips. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Timing adjustable 2.2.1 A Toasts should not auto-dismiss. If they do, users need a way to extend, pause, or dismiss time-limited content. Hovering, clicking, or keyboard focusing on the toast should keep it from disappearing. Seizures and physical feactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
     }
   ],
   "options": {

package/components/tooltip.json

@@ -54,15 +54,28 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabTabbing into an item that has a tooltip associated with it (e.g., an icon) shows the tooltip.EscHides the tooltip."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Tabbing into an item that has a tooltip associated with it (e.g., an icon) shows the tooltip. Esc Hides the tooltip."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Usage PointerIf the trigger is a button or link, or a focus-only element (like an info icon that shows a tooltip on hover), use the pointer cursor.Default (Arrow)If the trigger is an icon that is not clickable, use the default cursor.PointerIf the tooltip has a link, use the pointer cursor when interacting with the link."
+      "content": "Cursor guidelines.\n\nCursor Usage Pointer If the trigger is a button or link, or a focus-only element (like an info icon that shows a tooltip on hover), use the pointer cursor. Default (Arrow) If the trigger is an icon that is not clickable, use the default cursor. Pointer If the tooltip has a link, use the pointer cursor when interacting with the link."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content1.1.1ANon‑text elements—such as icons used in tooltips and icons that trigger tooltips—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function.Info and relationships, Identify purpose1.3.1, 1.3.6A, AAATooltips should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role should be utilized.Use of color1.4.1AColor is never used as the sole way to convey meaning in tooltips. Tooltips use color to reinforce their meaning, but every tooltip also includes a clear text label that communicates purpose.Text contrast minimums1.4.3AALarge text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement.Resize text1.4.4AATooltips should be built in such a way that they can be resized without assistive technology up to 200%.Visual presentation1.4.8AAAThe width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified.Non-text contrast1.4.11AAThe visual presentation of icons and various states have a contrast ratio of at least 3:1.Text spacing1.4.12AALine height of text is at least 1.5x the font size in wrapped tooltips. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non‑text elements—such as icons used in tooltips and icons that trigger tooltips—must provide a text alternative that communicates the control’s purpose. All controls, especially icon‑only controls, need an accessible name (for example, via a title, aria‑label, or associated text) so screen readers can announce their function. Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAA Tooltips should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role should be utilized. Use of color 1.4.1 A Color is never used as the sole way to convey meaning in tooltips. Tooltips use color to reinforce their meaning, but every tooltip also includes a clear text label that communicates purpose. Text contrast minimums 1.4.3 AA Large text has a contrast ratio of at least 3:1, and small text has a contrast ratio of at least 4.5:1. Incidental text such as disabled, hidden, or decorative text has no contrast requirement. Resize text 1.4.4 AA Tooltips should be built in such a way that they can be resized without assistive technology up to 200%. Visual presentation 1.4.8 AAA The width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified. Non-text contrast 1.4.11 AA The visual presentation of icons and various states have a contrast ratio of at least 3:1. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size in wrapped tooltips. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
+    }
+  ],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "Tooltip",
+      "package": "@react-spectrum/s2"
+    },
+    {
+      "platform": "web",
+      "componentName": "Tooltip",
+      "importPath": "@adobe/spectrum-wc/components/tooltip",
+      "notes": "Spectrum 2 web component custom element: swc-tooltip."
     }
   ],
   "options": {

package/components/tree-view.json

@@ -100,15 +100,22 @@
     },
     {
       "type": "guideline",
-      "content": "Keyboard interactions.\n\nKey Interaction TabMoves focus to the tree view, placing the first tree view item in focus.Shift + TabMoves focus out of the tree view to the previous focusable element.Down ArrowMoves focus to the tree view item below or to the next thumbnail of a tree view item.Up ArrowMoves focus to the tree view item above or to the previous thumbnail of a tree view item.Enter or SpaceSelects the currently focused tree view item. If focus is on a child of the tree view item, subsequent action is based on the child component’s keyboard interactions. For the drag icon, this places the user in drag-and-drop mode.Right Arrow (Left Arrow in RTL)Expands the currently focused tree view item. If the tree view item is already expanded, or if the tree view item is not expandable, focus is moved in a left-to-right direction along child components. If focus is on the rightmost child of the tree view item, focus does not move.Left Arrow (Right Arrow in RTL)Collapses the currently focused tree view item. If focus is on a child of the tree view item, focus is moved in a right-to-left direction along child components. If focus is on the leftmost child of the tree view item, focus is placed back on the parent tree view item.HomeMoves focus to the first item in the tree view without opening or closing a level.EndMoves focus to the last item in the tree view that is focusable without opening a level.Cmd + [ (optional)Moves the currently selected item up in the view order.Cmd + ] (optional)Moves the currently selected item down in the view order.Cmd + Z (optional)Undoes the action most recently taken, such as after the user drags and drops, reorders, or performs an action on a tree view item.Cmd + G (optional)Groups the selected tree view item(s) into a new parent tree view item.Shift + Cmd + G (optional)Ungroups or removes the selected parent tree view item, placing its children at the same level of hierarchy as the removed items.Printable charactersTypeahead: moves focus to next node matching typed text.* (optional)Expands all sibling nodes at the same level."
+      "content": "Keyboard interactions.\n\nKey Interaction Tab Moves focus to the tree view, placing the first tree view item in focus. Shift + Tab Moves focus out of the tree view to the previous focusable element. Down Arrow Moves focus to the tree view item below or to the next thumbnail of a tree view item. Up Arrow Moves focus to the tree view item above or to the previous thumbnail of a tree view item. Enter or Space Selects the currently focused tree view item. If focus is on a child of the tree view item, subsequent action is based on the child component’s keyboard interactions. For the drag icon, this places the user in drag-and-drop mode. Right Arrow (Left Arrow in RTL) Expands the currently focused tree view item. If the tree view item is already expanded, or if the tree view item is not expandable, focus is moved in a left-to-right direction along child components. If focus is on the rightmost child of the tree view item, focus does not move. Left Arrow (Right Arrow in RTL) Collapses the currently focused tree view item. If focus is on a child of the tree view item, focus is moved in a right-to-left direction along child components. If focus is on the leftmost child of the tree view item, focus is placed back on the parent tree view item. Home Moves focus to the first item in the tree view without opening or closing a level. End Moves focus to the last item in the tree view that is focusable without opening a level. Cmd + [ (optional) Moves the currently selected item up in the view order. Cmd + ] (optional) Moves the currently selected item down in the view order. Cmd + Z (optional) Undoes the action most recently taken, such as after the user drags and drops, reorders, or performs an action on a tree view item. Cmd + G (optional) Groups the selected tree view item(s) into a new parent tree view item. Shift + Cmd + G (optional) Ungroups or removes the selected parent tree view item, placing its children at the same level of hierarchy as the removed items. Printable characters Typeahead: moves focus to next node matching typed text. * (optional) Expands all sibling nodes at the same level."
     },
     {
       "type": "guideline",
-      "content": "Cursor guidelines.\n\nCursor Description Default (Arrow)Use the default arrow cursor for non-interactive headers and disabled text.PointerUse the pointer cursor for all interactive pieces of the tree view component.Grab handUse the grab hand on the drag handle when tree view objects can be moved.Grab fistUse the grab fist cursor when actively dragging tree items."
+      "content": "Cursor guidelines.\n\nCursor Description Default (Arrow) Use the default arrow cursor for non-interactive headers and disabled text. Pointer Use the pointer cursor for all interactive pieces of the tree view component. Grab hand Use the grab hand on the drag handle when tree view objects can be moved. Grab fist Use the grab fist cursor when actively dragging tree items."
     },
     {
       "type": "guideline",
-      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 ANon-text elements, such as icons used in tree view items, must provide a text alternative that communicates the item's purpose. All tree items, especially icon-only items, need an accessible name (for example, via a title, aria-label, or associated text) so screen readers can announce their function.Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAATree views should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role should be utilized, including parent/child relationships, expanded/collapsed states, and selection states.Use of color 1.4.1 AColor is not used as a means to convey information or distinguish elements.Contrast 1.4.3 AAThe visual presentation of text has a contrast ratio of at least 4.5:1.Visual presentation 1.4.8 AAAThe width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified.Non-text contrast 1.4.11 AAThe visual presentation of icons and component states have a contrast ratio of at least 3:1.Text spacing 1.4.12 AALine height of text is at least 1.5x the font size. 2. Operable RequirementCriterionLevel Compliance Keyboard 2.1.1, 2.1.3 A, AAAAll functionality of the component is operable through a keyboard without specific timing for keystrokes.Keyboard traps 2.1.2 AFocus can be moved away from the component using only a keyboard.Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAAThere is no flashing content or unnecessary motion or animation in this component.Focus order 2.4.3 ANavigation sequences receive focus in an order that preserves meaning and operability.Focus visible 2.4.7 AAKeyboard states use an indicator that is visible with at least 3:1 contrast."
+      "content": "WCAG 2.2 compliance.\n\nAny criterion not mention in the below table are not applicable to this component or are resolved with underlying requirements, engineering, and styles of the entire system. 1. Perceivable Requirement Criterion Level Compliance Non-text content 1.1.1 A Non-text elements, such as icons used in tree view items, must provide a text alternative that communicates the item's purpose. All tree items, especially icon-only items, need an accessible name (for example, via a title, aria-label, or associated text) so screen readers can announce their function. Info and relationships, Identify purpose 1.3.1, 1.3.6 A, AAA Tree views should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role should be utilized, including parent/child relationships, expanded/collapsed states, and selection states. Use of color 1.4.1 A Color is not used as a means to convey information or distinguish elements. Contrast 1.4.3 AA The visual presentation of text has a contrast ratio of at least 4.5:1. Visual presentation 1.4.8 AAA The width of text blocks is no more than 80 characters (40 for CJK languages), and text is never justified. Non-text contrast 1.4.11 AA The visual presentation of icons and component states have a contrast ratio of at least 3:1. Text spacing 1.4.12 AA Line height of text is at least 1.5x the font size. 2. Operable Requirement Criterion Level Compliance Keyboard 2.1.1, 2.1.3 A, AAA All functionality of the component is operable through a keyboard without specific timing for keystrokes. Keyboard traps 2.1.2 A Focus can be moved away from the component using only a keyboard. Seizures and physical reactions 2.3.1, 2.3.2, 2.3.3 A, AAA, AAA There is no flashing content or unnecessary motion or animation in this component. Focus order 2.4.3 A Navigation sequences receive focus in an order that preserves meaning and operability. Focus visible 2.4.7 AA Keyboard states use an indicator that is visible with at least 3:1 contrast."
+    }
+  ],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "TreeView",
+      "package": "@react-spectrum/s2"
     }
   ],
   "options": {

package/components/user-card.json

@@ -10,5 +10,12 @@
     "documentationUrl": "https://spectrum.adobe.com/page/user-card/"
   },
   "anatomy": [{ "name": "title" }],
+  "implementations": [
+    {
+      "platform": "web",
+      "componentName": "UserCard",
+      "package": "@react-spectrum/s2"
+    }
+  ],
   "lifecycle": { "introduced": "1.0.0-draft" }
 }

package/fields/structure.json

@@ -11,6 +11,5 @@
   },
   "scope": null,
   "required": false,
-  "valueType": "string",
-  "excludeFromLegacyKey": true
+  "valueType": "string"
 }

package/guidelines/ai-resource-guide.json

@@ -8,35 +8,27 @@
     { "type": "purpose", "content": "AI resource guide" },
     {
       "type": "guideline",
-      "content": "For component specs, anatomy, usage guidelines, design tokens, and Figma resources. View the Spectrum 2 Design Data website View the Figma MCP (connects Claude to Figma libraries)"
+      "content": "Spectrum Design Data puts the official Spectrum dataset (design tokens, component schemas, and Spectrum documentation and usage guidelines) directly in your AI assistant. We ship both an Agent Skill and an MCP server. See the Spectrum Data System documentation for more details."
     },
     {
       "type": "guideline",
-      "content": "Protopack is the Design Technology team's streamlined prototyping foundation. Protopack simplifies setup, includes production-ready Spectrum components, integrates with Adobe services, and supports easy deployment. It removes much of the configuration overhead so you can focus on designing, iterating, and exploring ideas.\" View the AD AI Prototyping Quick Start wiki View the Awesome Deployment Platform wiki Join the Protopack Slack channel"
+      "content": "@adobe/design-data-skill [npm: github].\n\nA skill the sets up access agents access to Spectrum design tokens, component schemas, and design-system data via the design data CLI."
     },
     {
       "type": "guideline",
-      "content": "Protopack for React Spectrum.\n\nDownload Protopack and view the RSP template View the React Spectrum Starter template in the Protopack app View the React Spectrum AI integration overview View the React Spectrum website"
+      "content": "@adobe/design-data-mcp [npm: github].\n\nThe MCP server for Adobe Spectrum design tokens, component schemas, and design guidelines and documentation."
     },
     {
       "type": "guideline",
-      "content": "Protopack for Spectrum Web Components.\n\nDownload Protopack and view the SWC template View the Spectrum 2 Web Components Starter template in the Protopack app View the Spectrum Web Components AI documentation View the Spectrum Web Components website"
+      "content": "React Spectrum.\n\nView the React Spectrum AI integration overview"
     },
     {
       "type": "guideline",
-      "content": "React Spectrum.\n\nView the React Spectrum AI integration overview View the React Spectrum website View the React Spectrum GitHub repository"
-    },
-    {
-      "type": "guideline",
-      "content": "Spectrum Web Components.\n\nView the Spectrum Web Components AI documentation View the Spectrum Web Components website View the Spectrum Web Components GitHub repository"
-    },
-    {
-      "type": "guideline",
-      "content": "Spectrum design data.\n\nView the Spectrum 2 Design Data AI resources View the Spectrum 2 Design Data website View the Spectrum 2 Design Data tools overview View the Spectrum 2 Design Data GitHub repository"
+      "content": "Spectrum Web Components.\n\nView the Spectrum Web Components AI skills"
     }
   ],
-  "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/support/ai-resource-guide",
-  "lastUpdated": "2026-08-27",
+  "sourceUrl": "https://spectrum.adobe.com/support/ai-resource-guide",
+  "lastUpdated": "2026-09-29",
   "status": "published",
   "tags": [
     "AI tooling",

package/guidelines/app-frame-overview.json

@@ -8,19 +8,19 @@
     { "type": "purpose", "content": "App frame" },
     {
       "type": "guideline",
-      "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."
+      "content": "Spectrum 2 treats the app frame as a framework to help product teams make the best decisions for their use cases. This is a resource that combines high-level framing, direction about construction, and specific examples for inspiration. It offers a balance of information that’s strategic and tactical, with the following principles at the forefront: Image: A stylized handshake icon in a red-to-purple-to-blue gradient, representing partnership and collaboration. (source: https://spectrum.adobe.com/foundations/app-frame/media_11cfce068432aba2f9060cc149b32c2e004fa8f56.png?width=750&format=png&optimize=medium) Image: Gradient circular icon with a white branching outline pattern, in red-to-purple tones. (source: https://spectrum.adobe.com/foundations/app-frame/media_17f5b288d52a84b5be39e3828f378d4b58ca3849d.png?width=750&format=png&optimize=medium) Image: Heart icon in a red-to-purple gradient with a blue wave accent. (source: https://spectrum.adobe.com/foundations/app-frame/media_1eed72408776ec432363d78bca1e17a23ff6d0819.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "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."
+      "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": "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."
+      "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": "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."
+      "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",
@@ -28,11 +28,11 @@
     },
     {
       "type": "guideline",
-      "content": "Browsing context: Zones.\n\nZones are the general areas into which certain types of actions should go. They’re not specific to components. Image: Diagram showing the three zones of the construction of the Spectrum 2 app frame: A, navigation zone, B, global action zone, and C, contextual action zone. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_19aef995718b2fb929aef522835b8af9a752400ed.png?width=750&format=png&optimize=medium)"
+      "content": "Browsing context: Zones.\n\nZones are the general areas into which certain types of actions should go. They’re not specific to components. Image: Diagram showing the three zones of the construction of the Spectrum 2 app frame: A, navigation zone, B, global action zone, and C, contextual action zone. (source: https://spectrum.adobe.com/foundations/app-frame/media_19aef995718b2fb929aef522835b8af9a752400ed.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "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."
+      "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",
@@ -44,7 +44,7 @@
     },
     {
       "type": "guideline",
-      "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. Image: Diagram showing the three parts of the anatomy of the Spectrum 2 app frame: A, header, B, side navigation, and C, content area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_187bd949ffe1f05a278b9a306eabdb7516805dc19.png?width=750&format=png&optimize=medium)"
+      "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. Image: Diagram showing the three parts of the anatomy of the Spectrum 2 app frame: A, header, B, side navigation, and C, content area. (source: https://spectrum.adobe.com/foundations/app-frame/media_187bd949ffe1f05a278b9a306eabdb7516805dc19.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
@@ -56,16 +56,15 @@
     },
     {
       "type": "guideline",
-      "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)."
+      "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": "Anatomy examples" },
     {
       "type": "guideline",
-      "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)."
+      "content": "Anatomy examples.\n\nImage: Two examples of Spectrum 2 app frame anatomy. Example one: Header only. Header contains the primary navigation and global actions. Example two: Header plus side navigation. Because the side navigation is present, the header is used for global, app-wide actions instead. (source: https://spectrum.adobe.com/foundations/app-frame/media_1b47658c35e18eead92d82cc540f886a57b6ee84f.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "content": "Anatomy examples.\n\nImage: Two examples of Spectrum 2 app frame anatomy. Example one: Header only. Header contains the primary navigation and global actions. Example two: Header plus side navigation. Because the side navigation is present, the header is used for global, app-wide actions instead. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1b47658c35e18eead92d82cc540f886a57b6ee84f.png?width=750&format=png&optimize=medium)"
+      "content": "There are two variants of the side navigation state control: hamburger and panel. They should never be used at the same time. Interacting with the side navigation state control (an icon-only button) will expand and collapse the width of the panel. This allows for the labels of the side navigational items to be shown or hidden. When used to expand the panel, the accessible name (optionally shown as a tooltip) changes to “Show menu labels.” When used to collapse the panel, the accessible name changes to “Hide menu labels.” Image: Two diagrams showing the difference between the side navigation state control. One is of panel icon and the other is of the hamburger icon. (source: https://spectrum.adobe.com/foundations/app-frame/media_128e76de99bdbfd9d2c9744699ee6fcd678f5f85f.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
@@ -75,6 +74,10 @@
       "type": "guideline",
       "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 Top App Bar (TAB) is the the most-up-to-date form of the 9-grid app switcher in Adobe Home. While the underlying functionality remains unchanged, the TAB introduces a more prominent visual placement, appearing at the top of the header when active."
+    },
     {
       "type": "guideline",
       "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."
@@ -89,19 +92,19 @@
     },
     {
       "type": "guideline",
-      "content": "Anatomy examples.\n\nImage: Examples of the product switcher in different places. One example of the Top App Bar (TAB) active at the top of the viewport with the panel icon state switcher at the end of the side navigation section. Another example is the mobile experience with the hamburger icon state switcher and the product switcher in the header. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_19bf4524cadbd94da0231a7cce0d587f0be0ac845.png?width=750&format=png&optimize=medium)"
+      "content": "Anatomy examples.\n\nImage: Examples of the product switcher in different places. One example of the Top App Bar (TAB) active at the top of the viewport with the panel icon state switcher at the end of the side navigation section. Another example is the mobile experience with the hamburger icon state switcher and the product switcher in the header. (source: https://spectrum.adobe.com/foundations/app-frame/media_19bf4524cadbd94da0231a7cce0d587f0be0ac845.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "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."
+      "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. Image: Diagrams of the hamburger side navigation state control in a web and mobile breakpoint. (source: https://spectrum.adobe.com/foundations/app-frame/media_1ba4d3297356f4f73b02b4fb05bed4596a9fcd706.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "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. Image: Diagrams of the hamburger side navigation state control in a web and mobile breakpoint. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1ba4d3297356f4f73b02b4fb05bed4596a9fcd706.png?width=750&format=png&optimize=medium)"
+      "content": "It’s ultimately up to product teams to decide how to translate the terms used in the framework anatomy — and other internal jargon — into UI language that makes the most sense for their end users. Internal product development jargon often unintentionally surfaces in UI, and this can create confusing experiences for the people using our products. In order to avoid that — as well as align across differences in team and individual jargon — the terms used here to describe the anatomy of the app frame are focused on communicating high-level construction (how something is built) and intention (how something is used)."
     },
     {
       "type": "guideline",
-      "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. Image: Illustration of where panels or rails appear in the app frame layout: to either the left or right side of the UI. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1c4e8402f034d1e4c9737e42b72fad58518c38c1f.png?width=750&format=png&optimize=medium)Image: Illustration of one example where a content area can appear in the app frame layout: as the main focus or work area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1600fc2e5b4260da2d3f688f8b0c9d7c4604016f1.png?width=750&format=png&optimize=medium)Image: Illustration of an example of where a well can appear in the app frame layout: in the middle of a content area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1a80cabda2a52fad2708546441c70773dd8942506.png?width=750&format=png&optimize=medium)"
+      "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. Image: Illustration of where panels or rails appear in the app frame layout: to either the left or right side of the UI. (source: https://spectrum.adobe.com/foundations/app-frame/media_1c4e8402f034d1e4c9737e42b72fad58518c38c1f.png?width=750&format=png&optimize=medium) Image: Illustration of one example where a content area can appear in the app frame layout: as the main focus or work area. (source: https://spectrum.adobe.com/foundations/app-frame/media_1600fc2e5b4260da2d3f688f8b0c9d7c4604016f1.png?width=750&format=png&optimize=medium) Image: Illustration of an example of where a well can appear in the app frame layout: in the middle of a content area. (source: https://spectrum.adobe.com/foundations/app-frame/media_1a80cabda2a52fad2708546441c70773dd8942506.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
@@ -117,7 +120,7 @@
     },
     {
       "type": "guideline",
-      "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: Image: A black-and-white line icon of a browser window with a top toolbar and a single dot. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_15b3b3fb77bc097c8d306652754e50f38e16cb7fb.png?width=750&format=png&optimize=medium)Image: A black-and-white line icon of a magnifying glass, representing search. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_12ac292a56a7ce97b0042216244922f5d9e32f56f.png?width=750&format=png&optimize=medium)Image: A black-and-white line icon of two overlapping user silhouettes, representing a group of people. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_150f01f672f95313815260ac49144b5023d36ae5e.png?width=750&format=png&optimize=medium)"
+      "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: Image: A black-and-white line icon of a browser window with a top toolbar and a single dot. (source: https://spectrum.adobe.com/foundations/app-frame/media_15b3b3fb77bc097c8d306652754e50f38e16cb7fb.png?width=750&format=png&optimize=medium) Image: A black-and-white line icon of a magnifying glass, representing search. (source: https://spectrum.adobe.com/foundations/app-frame/media_12ac292a56a7ce97b0042216244922f5d9e32f56f.png?width=750&format=png&optimize=medium) Image: A black-and-white line icon of two overlapping user silhouettes, representing a group of people. (source: https://spectrum.adobe.com/foundations/app-frame/media_150f01f672f95313815260ac49144b5023d36ae5e.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
@@ -137,26 +140,22 @@
     },
     {
       "type": "guideline",
-      "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. Image: Example of correct usage. Approvals. Colors. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_114c85b714942bddf4a0baaac51146c4e1755a454.png?width=750&format=png&optimize=medium)Describe the actions or items available.Image: Example of incorrect usage. Approvals rail. Colors panel. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_16927fb5340c20e1bd0dbaf651eb68d4c4d76032e.png?width=750&format=png&optimize=medium)Avoid describing where to find specific items or actions in relation to UI construction."
-    },
-    {
-      "type": "guideline",
-      "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. Image: Example of correct usage. Show more options. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1bc5bf7de9abaf2318532d97026370f9d9be0fa1e.png?width=750&format=png&optimize=medium)Describe the action to take on the UI.Image: Example of incorrect usage. Hide navigation rail. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_17fc6b06737dfff7420c77dd28a9df09d1715610d.png?width=750&format=png&optimize=medium)Don’t describe the UI itself."
+      "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. Image: Example of correct usage. Approvals. Colors. (source: https://spectrum.adobe.com/foundations/app-frame/media_114c85b714942bddf4a0baaac51146c4e1755a454.png?width=750&format=png&optimize=medium) Describe the actions or items available. Image: Example of incorrect usage. Approvals rail. Colors panel. (source: https://spectrum.adobe.com/foundations/app-frame/media_16927fb5340c20e1bd0dbaf651eb68d4c4d76032e.png?width=750&format=png&optimize=medium) Avoid describing where to find specific items or actions in relation to UI construction."
     },
     {
       "type": "guideline",
-      "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. Image: Example of correct usage. Show menu labels. Hide navigation. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_18c67799a786aa0e8335712032da5e43b57fdc230.png?width=750&format=png&optimize=medium)Image: Example of incorrect usage. Expand menu labels. Minimize navigation. Collapse side bar. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1ab30756ab3323c279063b24ab1950d5ecd12b932.png?width=750&format=png&optimize=medium)"
+      "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. Image: Example of correct usage. Show more options. (source: https://spectrum.adobe.com/foundations/app-frame/media_1bc5bf7de9abaf2318532d97026370f9d9be0fa1e.png?width=750&format=png&optimize=medium) Describe the action to take on the UI. Image: Example of incorrect usage. Hide navigation rail. (source: https://spectrum.adobe.com/foundations/app-frame/media_17fc6b06737dfff7420c77dd28a9df09d1715610d.png?width=750&format=png&optimize=medium) Don’t describe the UI itself."
     },
     {
       "type": "guideline",
-      "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. Image: Example of correct usage. All templates. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1f4aca7a576edf2610ac55b033fa6c32b0ce79736.png?width=750&format=png&optimize=medium)Image: Example of incorrect usage. All Templates. ALL TEMPLATES. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1d2fe39e9e168e4a5493e212e36a31d36e765060d.png?width=750&format=png&optimize=medium)"
+      "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. Image: Example of correct usage. Show menu labels. Hide navigation. (source: https://spectrum.adobe.com/foundations/app-frame/media_18c67799a786aa0e8335712032da5e43b57fdc230.png?width=750&format=png&optimize=medium) Image: Example of incorrect usage. Expand menu labels. Minimize navigation. Collapse side bar. (source: https://spectrum.adobe.com/foundations/app-frame/media_1ab30756ab3323c279063b24ab1950d5ecd12b932.png?width=750&format=png&optimize=medium)"
     },
     {
       "type": "guideline",
-      "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."
+      "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. Image: Example of correct usage. All templates. (source: https://spectrum.adobe.com/foundations/app-frame/media_1f4aca7a576edf2610ac55b033fa6c32b0ce79736.png?width=750&format=png&optimize=medium) Image: Example of incorrect usage. All Templates. ALL TEMPLATES. (source: https://spectrum.adobe.com/foundations/app-frame/media_1d2fe39e9e168e4a5493e212e36a31d36e765060d.png?width=750&format=png&optimize=medium)"
     }
   ],
-  "sourceUrl": "https://preview.spectrum.adobe.com/foundations/app-frame/overview",
+  "sourceUrl": "https://spectrum.adobe.com/foundations/app-frame/overview",
   "lastUpdated": "2026-09-04",
   "status": "published",
   "tags": [