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

package/components/text-field.json

@@ -16,248 +16,127 @@
     },
     {
       "type": "guideline",
-      "content": "Text fields collect custom text input. They can display optional cues to indicate formatting, validation, or other input requirements."
+      "content": "Minimum width.\n\nThe minimum width for a text field is 1.5 × the height of the field. This minimum width guarantees that small text fields are readable and easy to target on touch devices."
     },
     {
       "type": "guideline",
-      "content": "Text fields should always have an accessible name, typically provided by a visible text label. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the visible label may be hidden or omitted. When no visible label is present, the input must still expose an accessible name (for example, in HTML via “aria-label” or “aria-labelledby,” and on other platforms via the platform’s accessible-name mechanism)."
+      "content": "Text overflow.\n\nWhen the field label is too long for the available horizontal space, it wraps to form another line. The field text itself truncates."
     },
     {
       "type": "guideline",
-      "content": "Labels can be placed either on top or on the side. Top labels are the default and are recommended because they work better with long copy, localization, and responsive layouts. Side labels are most useful when vertical space is limited."
+      "content": "Mixed value.\n\nWhen a text field presents multiple values that are not identical, the field should show an en dash (–)."
     },
     {
       "type": "guideline",
-      "content": "The value shows a user’s entered text."
+      "content": "Help text overflow.\n\nWhen the help text is too long for the available horizontal space, it wraps to form another line."
     },
     {
       "type": "guideline",
-      "content": "The text field’s default width is field-default-width-\\[small/medium/large/extra-large]."
+      "content": "Include a label.\n\nEvery text field should have a label. A field without a label is ambiguous and not accessible."
     },
     {
       "type": "guideline",
-      "content": "Text fields come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequently used option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page."
+      "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",
-      "content": "Text fields can be marked as optional or required, depending on the situation. For required text fields, there are two styling options: a “(required)” label or an asterisk. If you use an asterisk, be sure to include hint text to explain what the asterisk means. Optional text fields are either denoted with text added to the end of the label — “(optional)” — or have no indication at all."
+      "content": "Follow capitalization rules.\n\nField labels should be in sentence case."
     },
     {
       "type": "guideline",
-      "content": "The asterisk used in this component is an icon that has specific spacing from the label text — not part of the label text itself."
+      "content": "Mark the minority of text fields in a form as required or optional.\n\nIn a single form, mark only the required fields or only the optional fields, depending on whichever is less frequent in the entire form. If most of the text fields are optional, only the required fields should be give an asterisk or have labels appended with \"(required)\". If most of the text fields are required, only the optional fields should be appended with \"(optional)\". An asterisk should never be used to note that a text field is optional."
     },
     {
       "type": "guideline",
-      "content": "Text fields can display a character count indicator when the length of the text entry needs to be kept under a predefined value. Character count indicators can be used in conjunction with other indicators (validation icon, “optional” or “required” indicators) when necessary."
+      "content": "Use help text to show hints, formatting, and requirements.\n\nThe description in the help text is flexible and encompasses a range of guidance. Sometimes this guidance is about what to input, and sometime it's about how to input. This includes information such as: An overall description of the input field Hints for what kind of information needs to be input Specific formatting examples or requirements The help text's message should not simply restate the same information in the label in order to prompt someone to interact with it. Don't add help text if it isn't actually relevant or meaningful to a user in order to try to maintain layout continuity with other inputs that require help text."
     },
     {
-      "type": "guideline",
-      "content": "Text fields can display a validation icon when the text entry is expected to conform to a specific format such as email address, credit card number, password creation requirements, and many more. The icon appears as soon as a user types a valid entry in the field."
-    },
-    {
-      "type": "guideline",
-      "content": "A text field can be marked as having an error to show that a value needs to be entered in order to move forward or that a value that was entered is invalid. If an error exists, the error icon always overrides the validation icon."
-    },
-    {
-      "type": "guideline",
-      "content": "A text field in a disabled state shows that an text field exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that a field may become available later."
-    },
-    {
-      "type": "guideline",
-      "content": "A text field can have help text below the field to give extra context or instruction about what a user should input in the field. The help text communicates a hint or helpful information, such as specific requirements for correctly filling out the field."
-    },
-    {
-      "type": "guideline",
-      "content": "A text field can be marked as having an error to show that a value needs to be entered in order to move forward or that a value that was entered is invalid. The error message communicates an error for when the field requirements aren’t met, prompting a user to adjust what they had originally input. If an error exists, the error icon always overrides the validation icon."
-    },
-    {
-      "type": "guideline",
-      "content": "The minimum width for a text field is 1.5 × the height of the field. This minimum width guarantees that small text fields are readable and easy to target on touch devices."
-    },
-    {
-      "type": "guideline",
-      "content": "When the field label is too long for the available horizontal space, it wraps to form another line. The field text itself truncates."
-    },
-    {
-      "type": "guideline",
-      "content": "When a text field presents multiple values that are not identical, the field should show an en dash (–)."
-    },
-    {
-      "type": "guideline",
-      "content": "When the help text is too long for the available horizontal space, it wraps to form another line."
-    },
-    {
-      "type": "guideline",
-      "content": "Every text field should have a label. A field without a label is ambiguous and not accessible."
+      "type": "do-dont",
+      "content": "Don't use placeholder text",
+      "dont": "Putting instructions for how to complete an input, requirements, or any other essential information into placeholder text is not accessible. Once a value is entered, placeholder text is no longer viewable; if someone is using an automatic form filler, they will never get the information in the placeholder text. Instead, use the help text description to convey requirements or to show any formatting examples that would help user comprehension. If there's placeholder text and help text at the same time, it becomes redundant and distracting, especially if they're communicating the same thing."
     },
     {
       "type": "guideline",
-      "content": "Field labels should be in sentence case."
+      "content": "Switch help text with error text.\n\nThe help text area also displays an error message. When a text field already includes help text and an error is triggered, the help text is replaced with error text. Once the error is resolved, the help text description reappears below the field. Since one gets replaced by the other, the language of the help text and error text need to work together to convey the same messaging. Help text explains the requirement or adds supplementary context for how to successfully complete the input. Error text tells a user how to fix the error by re-stating the input requirements or describing the necessary interaction. Make sure that the help text and the error text include the same essential information so that it isn't lost if one replaces the other like password requirements."
     },
     {
       "type": "guideline",
-      "content": "In a single form, mark only the required fields or only the optional fields, depending on whichever is less frequent in the entire form. If most of the text fields are optional, only the required fields should be give an asterisk or have labels appended with “(required)”. If most of the text fields are required, only the optional fields should be appended with “(optional)”. An asterisk should never be used to note that a text field is optional."
+      "content": "Write error text that shows a solution.\n\nWrite error messaging in a human-centered way by guiding a user and showing them a solution — don't simply state what's wrong and then leave them guessing as to how to resolve it. Ambiguous error messages can be frustrating and even shame-inducing for users. Also, keep in mind that something that a system may deem an error may not actually be perceived as an error to a user. Error text should be written in 1-2 short, complete sentences and in a clear and straightforward way. End sentences with a period, and never with an exclamation point. For text fields, the nature of the error is often related to something that needs to be fixed for in-line validation, so a helpful tone is most appropriate. For example, if someone were to miss filling out a required field that asks for their email address, write the error text like you're offering a hint or a tip to help guide them to understand what needs to go in the missing field: \"Enter your email address."
     },
     {
       "type": "guideline",
-      "content": "The help text’s message should not simply restate the same information in the label in order to prompt someone to interact with it. Don’t add help text if it isn’t actually relevant or meaningful to a user in order to try to maintain layout continuity with other inputs that require help text."
+      "content": "RTL.\n\nIn right‑to‑left languages, the text‑field layout is mirrored. The label is right‑aligned, and elements such as the character count, validation marker and error icon are left‑aligned. Keep in mind that some content, including email addresses, does not change direction or translate."
     },
     {
       "type": "guideline",
-      "content": "Putting instructions for how to complete an input, requirements, or any other essential information into placeholder text is not accessible. Once a value is entered, placeholder text is no longer viewable; if someone is using an automatic form filler, they will never get the information in the placeholder text."
+      "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)."
     },
     {
       "type": "guideline",
-      "content": "Instead, use the help text description to convey requirements or to show any formatting examples that would help user comprehension. If there's placeholder text and help text at the same time, it becomes redundant and distracting, especially if they're communicating the same thing."
+      "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."
     },
     {
       "type": "guideline",
-      "content": "The help text area also displays an error message. When a text field already includes help text and an error is triggered, the help text is replaced with error text. Once the error is resolved, the help text description reappears below the field."
-    },
-    {
-      "type": "guideline",
-      "content": "Since one gets replaced by the other, the language of the help text and error text need to work together to convey the same messaging. Help text explains the requirement or adds supplementary context for how to successfully complete the input. Error text tells a user how to fix the error by re-stating the input requirements or describing the necessary interaction. Make sure that the help text and the error text include the same essential information so that it isn’t lost if one replaces the other like password requirements."
-    },
-    {
-      "type": "guideline",
-      "content": "Write error messaging in a human-centered way by guiding a user and showing them a solution — don’t simply state what’s wrong and then leave them guessing as to how to resolve it. Ambiguous error messages can be frustrating and even shame-inducing for users. Also, keep in mind that something that a system may deem an error may not actually be perceived as an error to a user."
-    },
-    {
-      "type": "guideline",
-      "content": "Error text should be written in 1-2 short, complete sentences and in a clear and straightforward way. End sentences with a period, and never with an exclamation point. For text fields, the nature of the error is often related to something that needs to be fixed for in-line validation, so a helpful tone is most appropriate. For example, if someone were to miss filling out a required field that asks for their email address, write the error text like you’re offering a hint or a tip to help guide them to understand what needs to go in the missing field: “Enter your email address.”"
+      "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."
     }
   ],
   "options": {
-    "label": {
-      "type": "string"
-    },
+    "label": { "type": "string" },
     "labelPosition": {
       "type": "string",
       "default": "top",
-      "values": [
-        {
-          "value": "top"
-        },
-        {
-          "value": "side"
-        }
-      ]
-    },
-    "hideLabel": {
-      "type": "boolean",
-      "default": false
-    },
-    "value": {
-      "type": "string",
-      "description": "from minValue to maxValue"
-    },
-    "width": {
-      "type": "number"
+      "values": [{ "value": "top" }, { "value": "side" }]
     },
+    "hideLabel": { "type": "boolean", "default": false },
+    "value": { "type": "string", "description": "from minValue to maxValue" },
+    "width": { "type": "number" },
     "size": {
       "type": "string",
       "default": "m",
       "values": [
-        {
-          "value": "s"
-        },
-        {
-          "value": "m"
-        },
-        {
-          "value": "l"
-        },
-        {
-          "value": "xl"
-        }
+        { "value": "s" },
+        { "value": "m" },
+        { "value": "l" },
+        { "value": "xl" }
       ]
     },
     "necessityIndicator": {
       "type": "string",
       "default": "icon",
-      "values": [
-        {
-          "value": "text"
-        },
-        {
-          "value": "icon"
-        }
-      ]
-    },
-    "isRequired": {
-      "type": "boolean",
-      "default": false
-    },
-    "hasCharacterCount": {
-      "type": "boolean",
-      "default": false
-    },
-    "showValidIcon": {
-      "type": "boolean",
-      "default": false
+      "values": [{ "value": "text" }, { "value": "icon" }]
     },
+    "isRequired": { "type": "boolean", "default": false },
+    "hasCharacterCount": { "type": "boolean", "default": false },
+    "showValidIcon": { "type": "boolean", "default": false },
     "isError": {
       "type": "boolean",
       "default": false,
       "description": "If there is an error, this property overrides show valid icon."
     },
-    "isDisabled": {
-      "type": "boolean",
-      "default": false
-    },
-    "helpText": {
-      "type": "string"
-    },
-    "errorMessage": {
-      "type": "string"
-    }
+    "isDisabled": { "type": "boolean", "default": false },
+    "helpText": { "type": "string" },
+    "errorMessage": { "type": "string" }
   },
   "states": [
-    {
-      "name": "hover",
-      "trigger": "interaction"
-    },
-    {
-      "name": "focus-+-hover",
-      "trigger": "prop"
-    },
-    {
-      "name": "focus-+-not-hover",
-      "trigger": "prop"
-    },
-    {
-      "name": "keyboard-focus",
-      "trigger": "interaction"
-    }
+    { "name": "hover", "trigger": "interaction" },
+    { "name": "focus-+-hover", "trigger": "prop" },
+    { "name": "focus-+-not-hover", "trigger": "prop" },
+    { "name": "keyboard-focus", "trigger": "interaction" }
   ],
-  "lifecycle": {
-    "introduced": "1.0.0-draft"
-  },
+  "lifecycle": { "introduced": "1.0.0-draft" },
   "accessibility": {
     "role": "textbox",
     "intents": ["input"],
     "focusable": true,
     "wcag": [
-      {
-        "criterion": "1.3.1",
-        "level": "A",
-        "title": "Info and Relationships"
-      },
+      { "criterion": "1.3.1", "level": "A", "title": "Info and Relationships" },
       {
         "criterion": "1.3.5",
         "level": "AA",
         "title": "Identify Input Purpose"
       },
-      {
-        "criterion": "2.1.1",
-        "level": "A",
-        "title": "Keyboard"
-      },
-      {
-        "criterion": "4.1.2",
-        "level": "A",
-        "title": "Name, Role, Value"
-      }
+      { "criterion": "2.1.1", "level": "A", "title": "Keyboard" },
+      { "criterion": "4.1.2", "level": "A", "title": "Name, Role, Value" }
     ]
   }
 }

package/components/thumbnail.json

@@ -16,94 +16,53 @@
     },
     {
       "type": "guideline",
-      "content": "Thumbnails display a preview of an image, layer, or effect, and appear in a variety of locations as a visual reference."
+      "content": "Keyboard focus.\n\nThumbnails can be navigated using a keyboard in certain scenarios, such as layers or layer masks. When a thumbnail is used as pure representation of an item, focus should be set on the component the thumbnail is used within."
     },
     {
       "type": "guideline",
-      "content": "Thumbnail sizes scale exponentially. The opacity checkerboard responsively resizes to appropriately fit within each thumbnail size."
+      "content": "Image.\n\nThumbnails feature rounded corners and may include images with transparency. A subtle inset border helps distinguish images that might otherwise blend into the product's theme colors."
     },
     {
       "type": "guideline",
-      "content": "Thumbnails can be navigated using a keyboard in certain scenarios, such as layers or layer masks. When a thumbnail is used as pure representation of an item, focus should be set on the component the thumbnail is used within."
+      "content": "Layer.\n\nWhen thumbnails are used in layer management (such as Treeview, Compact or Detail Layers panels), the thumbnail is given a thick gray border."
     },
     {
       "type": "guideline",
-      "content": "Thumbnails feature rounded corners and may include images with transparency. A subtle inset border helps distinguish images that might otherwise blend into the product’s theme colors."
+      "content": "Selected layer.\n\nWhen a user selects a thumbnail in layer management, such as in Treeview, Compact or Detail Layers panels, it is highlighted with a thick blue border."
     },
     {
       "type": "guideline",
-      "content": "When thumbnails are used in layer management (such as Treeview, Compact or Detail Layers panels), the thumbnail is given a thick gray border."
+      "content": "Using thumbnails in treeview.\n\nTree view items can show thumbnails as an alternative to icons. Thumbnails are best used when a user needs to have a preview of the content represented by the tree view item. Icons can be used as a fallback for when an image is unavailable, but should be appropriately sized to match the thumbnail."
     },
     {
       "type": "guideline",
-      "content": "When a user selects a thumbnail in layer management, such as in Treeview, Compact or Detail Layers panels, it is highlighted with a thick blue border."
+      "content": "Be mindful of thumbnail size and proportions.\n\nTree views with thumbnails should use a thumbnail size that is appropriate to the size of the tree view itself. For example, an extra-large tree view would not work well with small thumbnails; those proportions may be better suited for using icons instead."
     },
     {
       "type": "guideline",
-      "content": "Tree view items can show thumbnails as an alternative to icons. Thumbnails are best used when a user needs to have a preview of the content represented by the tree view item. Icons can be used as a fallback for when an image is unavailable, but should be appropriately sized to match the thumbnail."
-    },
-    {
-      "type": "guideline",
-      "content": "Tree views with thumbnails should use a thumbnail size that is appropriate to the size of the tree view itself. For example, an extra-large tree view would not work well with small thumbnails; those proportions may be better suited for using icons instead."
-    },
-    {
-      "type": "guideline",
-      "content": "In some cases, multiple thumbnails need to be displayed in-line with the tree view item (e.g., layer masks). These thumbnails should be individually selectable and inherit all other behaviors of a standard tree view item, such as drag-and-drop behavior. Don't use more than 3 thumbnails per tree view item."
+      "content": "Multiple thumbnail.\n\nIn some cases, multiple thumbnails need to be displayed in-line with the tree view item (e.g., layer masks). These thumbnails should be individually selectable and inherit all other behaviors of a standard tree view item, such as drag-and-drop behavior. Don't use more than 3 thumbnails per tree view item."
     }
   ],
   "options": {
     "size": {
       "type": "number",
       "values": [
-        {
-          "value": 50
-        },
-        {
-          "value": 75
-        },
-        {
-          "value": 100
-        },
-        {
-          "value": 200
-        },
-        {
-          "value": 300
-        },
-        {
-          "value": 400
-        },
-        {
-          "value": 500
-        },
-        {
-          "value": 600
-        },
-        {
-          "value": 700
-        },
-        {
-          "value": 800
-        },
-        {
-          "value": 900
-        },
-        {
-          "value": 1000
-        }
+        { "value": 50 },
+        { "value": 75 },
+        { "value": 100 },
+        { "value": 200 },
+        { "value": 300 },
+        { "value": 400 },
+        { "value": 500 },
+        { "value": 600 },
+        { "value": 700 },
+        { "value": 800 },
+        { "value": 900 },
+        { "value": 1000 }
       ]
     }
   },
-  "states": [
-    {
-      "name": "disabled",
-      "trigger": "prop"
-    }
-  ],
-  "lifecycle": {
-    "introduced": "1.0.0-draft"
-  },
-  "accessibility": {
-    "focusable": false
-  }
+  "states": [{ "name": "disabled", "trigger": "prop" }],
+  "lifecycle": { "introduced": "1.0.0-draft" },
+  "accessibility": { "focusable": false }
 }

package/components/toast.json

@@ -16,121 +16,100 @@
     },
     {
       "type": "guideline",
-      "content": "Toasts display brief, temporary notifications. They appear briefly without blocking interaction and typically do not require user action."
+      "content": "Text overflow.\n\nWhen the text is too long for the available horizontal space, it wraps to form another line. In actionable toasts, the button moves below the text prior to text wrapping."
     },
     {
       "type": "guideline",
-      "content": "Toasts must include text to communicate a message. Write the text as concisely as possible while still being clear about what has happened or is happening."
+      "content": "Multiple toasts.\n\nThe default state can display up to three toasts at a time. To view additional toasts beyond this limit, users can click the \"Show all\" action button. Alternatively, they can reveal remaining toasts by interacting with a button or dismissing the component. Additionally, hovering over the upper part of the toasts triggers a subtle animation, signaling to the user that the group can be fully expanded. The expanded state displays a minimum of two toasts with a visible scroll indicator, while the maximum number adapts based on screen size. Users can either dismiss the toasts or collapse them back to the previous state. To enhance contrast, an overlay is applied beneath the group, similar to components like takeover dialogs. In the React Spectrum implementation, the action button group has a fixed light theme, as switching modes significantly reduces contrast. Please refer to more multiple toasts usage guideline below."
     },
     {
       "type": "guideline",
-      "content": "The neutral toast is the default variant. It is gray and does not have an icon. This is used when the message is neutral in tone or when its semantics do not fit in any of the other variants."
+      "content": "Toast or dialog?\n\nToasts should only be used for confirmations, simple notifications, and low-priority alerts that do not need to completely interrupt the user experience. Dialogs are ideal for when a situation requires a user's attention, either for displaying important information or prompting for a response."
     },
     {
       "type": "guideline",
-      "content": "The informative toast uses the informative semantic color (blue) and has an info icon to help those with color vision deficiency discern the message tone. This should be used when the message should call extra attention compared to the neutral variant."
+      "content": "Placement.\n\nBy default, a toast is placed at the bottom center for both desktop and mobile platform scales to avoid disrupting the user experience. For desktop applications, a toast should be placed 16 px away from the bottom of the viewport. If a toast isn't noticeable or disrupts the user experience, its placement can be changed to bottom end, top end, or top center."
     },
     {
-      "type": "guideline",
-      "content": "The positive toast uses the positive semantic color (green) and has a checkmark icon to help those with color vision deficiency discern the message tone. This is used to inform about a successful action or completion of a task."
-    },
-    {
-      "type": "guideline",
-      "content": "The negative toast uses the negative semantic color (red) and has an alert icon to help those with color vision deficiency to discern the message tone. This is used to show an error or failure."
+      "type": "do-dont",
+      "content": "Don't display more than one action",
+      "dont": "Actionable toasts should only have one button."
     },
     {
-      "type": "guideline",
-      "content": "By default, a toast will dismiss when the user clicks the close button. A toast also has the option to auto-dismiss. Be sure to set a minimum of 5 seconds so that users can have time to read the toast message. If an actionable toast is set to auto-dismiss, make sure that the action is still available elsewhere in the app."
+      "type": "do-dont",
+      "content": "Don't include a redundant action",
+      "dont": "Actionable toasts should not have a button with a redundant action. For example, including a \"Dismiss\" button would be redundant because all toasts already have a close button."
     },
     {
       "type": "guideline",
-      "content": "When the text is too long for the available horizontal space, it wraps to form another line. In actionable toasts, the button moves below the text prior to text wrapping."
+      "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": "The default state can display up to three toasts at a time. To view additional toasts beyond this limit, users can click the “Show all” action button. Alternatively, they can reveal remaining toasts by interacting with a button or dismissing the component. Additionally, hovering over the upper part of the toasts triggers a subtle animation, signaling to the user that the group can be fully expanded."
+      "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": "Please refer to more multiple toasts usage guideline below."
+      "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": "Toasts should only be used for confirmations, simple notifications, and low-priority alerts that do not need to completely interrupt the user experience."
+      "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",
-      "content": "Dialogs are ideal for when a situation requires a user’s attention, either for displaying important information or prompting for a response."
+      "content": "Write in sentence case with no period.\n\nLike all in-product content at Adobe, toasts and their actions are written in sentence case. If the toast's message is a single sentence, do not add a period to the end; this helps keep the text quicker to read and easier to parse. Toasts should ideally only be a single sentence, but if you need to use two or more sentences to most accurately communicate the information, add a period to the end of each sentence."
     },
     {
       "type": "guideline",
-      "content": "By default, a toast is placed at the bottom center for both desktop and mobile platform scales to avoid disrupting the user experience."
+      "content": "Use an instructive tone.\n\nToasts offer quick reference or context, so a user should be able to quickly read a message that's brief and optimized for delivery. Use an instructive tone that presents the message in a concise and neutral way. Because users are likely to see several toasts in quick succession, it's not appropriate to use overly playful, encouraging, or celebratory language. Just convey the message, then get out of the way so that they can get back to the task at hand. Toasts are not appropriate for promotional messaging or upsells that show the benefit of doing or trying something."
     },
     {
       "type": "guideline",
-      "content": "For desktop applications, a toast should be placed 16 px away from the bottom of the viewport."
+      "content": "Use generic language.\n\nWhenever possible, use generic language in confirmation and error messages. This approach allows for better localization and it also reduces the need to write many different versions of toasts for similar use cases. It's usually unnecessary to include specific filenames, usernames, or folders because a user can get that context from elsewhere in the UI."
     },
     {
       "type": "guideline",
-      "content": "If a toast isn’t noticeable or disrupts the user experience, its placement can be changed to bottom end, top end, or top center."
+      "content": "RTL.\n\nFor RTL (right-to-left) languages, the layout of the toast is mirrored. The icon is right-aligned and the close button is left-aligned. If the toast is actionable, the button placement is also inverted and appears on the left side."
     },
     {
       "type": "guideline",
-      "content": "Actionable toasts should only have one button."
+      "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."
     },
     {
       "type": "guideline",
-      "content": "Actionable toasts should not have a button with a redundant action. For example, including a “Dismiss” button would be redundant because all toasts already have a close button."
+      "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."
     },
     {
       "type": "guideline",
-      "content": "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": "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."
     }
   ],
   "options": {
-    "text": {
-      "type": "string"
-    },
+    "text": { "type": "string" },
     "variant": {
       "type": "string",
       "default": "neutral",
       "values": [
-        {
-          "value": "neutral"
-        },
-        {
-          "value": "informative"
-        },
-        {
-          "value": "positive"
-        },
-        {
-          "value": "negative"
-        }
+        { "value": "neutral" },
+        { "value": "informative" },
+        { "value": "positive" },
+        { "value": "negative" }
       ]
     },
     "actionLabel": {
       "type": "string",
       "description": "If undefined, this button does not appear."
     },
-    "isAutoDismissible": {
-      "type": "boolean",
-      "default": false
-    }
-  },
-  "lifecycle": {
-    "introduced": "1.0.0-draft"
+    "isAutoDismissible": { "type": "boolean", "default": false }
   },
+  "lifecycle": { "introduced": "1.0.0-draft" },
   "accessibility": {
     "intents": ["dismiss"],
     "focusable": true,
     "keyboardIntents": ["dismiss"],
     "wcag": [
-      {
-        "criterion": "4.1.3",
-        "level": "AA",
-        "title": "Status Messages"
-      }
+      { "criterion": "4.1.3", "level": "AA", "title": "Status Messages" }
     ]
   }
 }