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

package/components/radio-group.json

@@ -16,187 +16,90 @@
     },
     {
       "type": "guideline",
-      "content": "Radio groups organize related radio buttons into a single selection set. Only one option can be selected at a time."
+      "content": "Keyboard focus.\n\nA radio button can be navigated using a keyboard. The keyboard focus state takes the radio button's visual hover state and adds a blue ring to the radio button in focus."
     },
     {
       "type": "guideline",
-      "content": "Radio groups should use help text for error messaging and descriptions. Descriptions are valuable for giving context behind why a selection is required, or for clarifying the options."
+      "content": "Text overflow.\n\nWhen the label is too long for the horizontal space available, it wraps to form another line."
     },
     {
       "type": "guideline",
-      "content": "Radio groups can be marked as having an error to show that a selection needs to be made in order to move forward, or that a selection that was made is invalid. The error is indicated with negative help text, along with an icon."
+      "content": "Mixed value.\n\nWhen a radio button group presents multiple values that are not identical, the group should not show a selection. Any subsequent selection should update all values."
     },
     {
       "type": "guideline",
-      "content": "A radio group in a disabled state shows that a selection exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that an action may become available later. The field label, radio buttons, and help text are all displayed in a disabled state when the radio group is disabled."
+      "content": "When to use an emphasized radio group?\n\nEmphasized radio group is optimal for forms, settings, and other scenarios where the radio group need to be noticed. Default radio group is optimal for application panels where all the visual components are monochrome in order to direct focus to the canvas."
     },
     {
       "type": "guideline",
-      "content": "Radio groups can be marked as optional or required, depending on the situation. For required radio groups, there are two styling options: a “(required)” label or an asterisk. If you use an asterisk, be sure to include help text to explain what the asterisk means. Optional radio groups are either denoted with text added to the end of the label — “(optional)” — or have no indication at all."
+      "content": "Use radio buttons for mutually exclusive options.\n\nRadio buttons and checkboxes are not interchangeable. Radio buttons are best used for selecting a single option from a list of mutually exclusive options. Checkboxes are best used for selecting multiple options at once (or no options)."
     },
     {
       "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": "Always label radio groups.\n\nRadio groups should always have a label that clearly describes what the list of options represents. This is important for accessibility, since a screen reader will read the label before each option. Make sure to include a label, and don't assume that the options are self-explanatory without one. Write the label in sentence case."
     },
     {
       "type": "guideline",
-      "content": "By default, radio buttons are not emphasized (gray). This option is best for when the radio button is not the core part of an interface, such as in application panels, where all visual components are monochrome in order to direct focus to the content."
+      "content": "Radio group, switch, or checkbox?\n\nRadio buttons are best when only one option can be selected at a time from a set (e.g., choosing one preference or mode). Switches are best for communicating activation (e.g., turning a setting on or off). Checkboxes are best for communicating selection (e.g., selecting multiple items from a list)."
     },
     {
       "type": "guideline",
-      "content": "The emphasized (blue) version provides a visual prominence that is best for forms, settings, lists or grids of assets, and other situations where a radio button needs to be noticed."
+      "content": "RTL.\n\nFor RTL (right-to-left) languages, the layout of the radio group (and its components) is mirrored. The radio buttons and icons are placed on the right side of the text, and text is aligned to the right."
     },
     {
       "type": "guideline",
-      "content": "Radio groups 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": "Keyboard interactions.\n\nKey Interaction TabMoves focus onto or off of the button.Space or EnterExecutes the button action. The focus remains on the button except if the button opens or closes the current container. In this case, the focus moves to the target or back to the caller."
     },
     {
       "type": "guideline",
-      "content": "Radio groups can be either horizontal or vertical. By default, radio groups are vertical. Use a horizontal radio group when vertical space is limited."
+      "content": "Cursor guidelines.\n\nCursor Usage PointerUse the pointer cursor for all interactive components."
     },
     {
       "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."
-    },
-    {
-      "type": "guideline",
-      "content": "Radio groups should always have a label. In rare cases where context is sufficient and an accessibility expert has reviewed the design, the label could be undefined. These radio groups without a visible label should still include an aria-label in HTML (depending on the context, “aria-label” or “aria-labelledby”)."
-    },
-    {
-      "type": "guideline",
-      "content": "A radio button can be navigated using a keyboard. The keyboard focus state takes the radio button’s visual hover state and adds a blue ring to the radio button in focus."
-    },
-    {
-      "type": "guideline",
-      "content": "When the label is too long for the horizontal space available, it wraps to form another line."
-    },
-    {
-      "type": "guideline",
-      "content": "When a radio button group presents multiple values that are not identical, the group should not show a selection. Any subsequent selection should update all values."
-    },
-    {
-      "type": "guideline",
-      "content": "Emphasized radio group is optimal for forms, settings, and other scenarios where the radio group need to be noticed. Default radio group is optimal for application panels where all the visual components are monochrome in order to direct focus to the canvas."
-    },
-    {
-      "type": "guideline",
-      "content": "Radio buttons and checkboxes are not interchangeable. Radio buttons are best used for selecting a single option from a list of mutually exclusive options. Checkboxes are best used for selecting multiple options at once (or no options)."
-    },
-    {
-      "type": "guideline",
-      "content": "Radio groups should always have a label that clearly describes what the list of options represents. This is important for accessibility, since a screen reader will read the label before each option. Make sure to include a label, and don't assume that the options are self-explanatory without one. Write the label in sentence case."
-    },
-    {
-      "type": "guideline",
-      "content": "Radio buttons are best when only one option can be selected at a time from a set (e.g., choosing one preference or mode)."
-    },
-    {
-      "type": "guideline",
-      "content": "Switches are best for communicating activation (e.g., turning a setting on or off)."
-    },
-    {
-      "type": "guideline",
-      "content": "Checkboxes are best for communicating selection (e.g., selecting multiple items from a list)."
+      "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 buttons—must provide a text alternative that communicates the button’s purpose. All buttons, especially icon‑only buttons, 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, AAAButtons should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role of buttons should be utilized.Use of color 1.4.1 AColor is never used as the sole way to convey meaning in buttons. While negative buttons do use red to reinforce their purpose, every button also includes a clear text label that communicates the action it performs.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.Resize text 1.4.4 AAButtons should be built in such a way that they can be resized without assistive technology up to 200%.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 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 Requirement Criterion Level 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"
-        }
-      ]
+      "values": [{ "value": "top" }, { "value": "side" }]
     },
     "orientation": {
       "type": "string",
       "default": "vertical",
-      "values": [
-        {
-          "value": "horizontal"
-        },
-        {
-          "value": "vertical"
-        }
-      ]
+      "values": [{ "value": "horizontal" }, { "value": "vertical" }]
     },
     "size": {
       "type": "string",
       "default": "m",
       "values": [
-        {
-          "value": "s"
-        },
-        {
-          "value": "m"
-        },
-        {
-          "value": "l"
-        },
-        {
-          "value": "xl"
-        }
+        { "value": "s" },
+        { "value": "m" },
+        { "value": "l" },
+        { "value": "xl" }
       ]
     },
-    "isEmphasized": {
-      "type": "boolean",
-      "default": false
-    },
+    "isEmphasized": { "type": "boolean", "default": false },
     "necessityIndicator": {
       "type": "string",
       "default": "icon",
-      "values": [
-        {
-          "value": "text"
-        },
-        {
-          "value": "icon"
-        }
-      ]
-    },
-    "isRequired": {
-      "type": "boolean",
-      "default": false
+      "values": [{ "value": "text" }, { "value": "icon" }]
     },
-    "isError": {
-      "type": "boolean",
-      "default": false
-    },
-    "isDisabled": {
-      "type": "boolean",
-      "default": false
-    },
-    "errorMessage": {
-      "type": "string"
-    },
-    "description": {
-      "type": "string"
-    }
-  },
-  "lifecycle": {
-    "introduced": "1.0.0-draft"
+    "isRequired": { "type": "boolean", "default": false },
+    "isError": { "type": "boolean", "default": false },
+    "isDisabled": { "type": "boolean", "default": false },
+    "errorMessage": { "type": "string" },
+    "description": { "type": "string" }
   },
+  "lifecycle": { "introduced": "1.0.0-draft" },
   "accessibility": {
     "intents": ["choose"],
     "focusable": false,
     "wcag": [
-      {
-        "criterion": "1.3.1",
-        "level": "A",
-        "title": "Info and Relationships"
-      },
-      {
-        "criterion": "4.1.2",
-        "level": "A",
-        "title": "Name, Role, Value"
-      }
+      { "criterion": "1.3.1", "level": "A", "title": "Info and Relationships" },
+      { "criterion": "4.1.2", "level": "A", "title": "Name, Role, Value" }
     ]
   }
 }

package/components/rating.json

@@ -68,53 +68,24 @@
       "multipleOf": 0.5,
       "description": "From 0 to 5, can be a decimal to represent half stars"
     },
-    "isEmphasized": {
-      "type": "boolean",
-      "default": false
-    },
-    "isDisabled": {
-      "type": "boolean",
-      "default": false
-    }
+    "isEmphasized": { "type": "boolean", "default": false },
+    "isDisabled": { "type": "boolean", "default": false }
   },
   "states": [
-    {
-      "name": "hover",
-      "trigger": "interaction"
-    },
-    {
-      "name": "down",
-      "trigger": "interaction"
-    },
-    {
-      "name": "keyboard-focus",
-      "trigger": "interaction"
-    }
+    { "name": "hover", "trigger": "interaction" },
+    { "name": "down", "trigger": "interaction" },
+    { "name": "keyboard-focus", "trigger": "interaction" }
   ],
-  "lifecycle": {
-    "introduced": "1.0.0-draft"
-  },
+  "lifecycle": { "introduced": "1.0.0-draft" },
   "accessibility": {
     "role": "slider",
     "intents": ["choose"],
     "focusable": true,
     "keyboardIntents": ["increment", "decrement"],
     "wcag": [
-      {
-        "criterion": "1.3.1",
-        "level": "A",
-        "title": "Info and Relationships"
-      },
-      {
-        "criterion": "2.1.1",
-        "level": "A",
-        "title": "Keyboard"
-      },
-      {
-        "criterion": "4.1.2",
-        "level": "A",
-        "title": "Name, Role, Value"
-      }
+      { "criterion": "1.3.1", "level": "A", "title": "Info and Relationships" },
+      { "criterion": "2.1.1", "level": "A", "title": "Keyboard" },
+      { "criterion": "4.1.2", "level": "A", "title": "Name, Role, Value" }
     ]
   }
 }

package/components/search-field.json

@@ -16,191 +16,106 @@
     },
     {
       "type": "guideline",
-      "content": "Search fields enable finding or filtering items based on text input."
+      "content": "Minimum width.\n\nThe minimum width for a search field is 3× the height of the field, for both standard and quiet style. This minimum width guarantees that small search fields are readable and easy to target on touch devices."
     },
     {
       "type": "guideline",
-      "content": "A search field should include a label and a search icon. In the default state before a search term is input, the label is in regular body text style to meet contrast ratios and to show that this is a field label, not placeholder text. 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 entered text is too long for the available horizontal space in the field, the text truncates."
     },
     {
       "type": "guideline",
-      "content": "The value shows a user’s entered text in regular body text style."
+      "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 width of a search field can be customized appropriately for its context."
+      "content": "Keyboard focus.\n\nA search field can be navigated using a keyboard. The keyboard focus state takes the field's visual hover state and adds a blue ring to the field in focus."
     },
     {
       "type": "guideline",
-      "content": "Search 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": "In-field button.\n\nThe in-field button offers an option to clear any input search term. If search results are being shown in a menu or popover, selecting this button will close the menu and clear the field. If a search term has been entered and the results have appeared, selecting this will only clear the field and not affect the list of results."
     },
     {
       "type": "guideline",
-      "content": "A search field can have help text below the field to give extra context or instruction about what a user should input. The description communicates a hint or helpful information, such as a search’s scope."
+      "content": "Show a \"No results\" state instead of an error.\n\nSearch fields do not have an error state. Search functionality should anticipate spelling mistakes in search queries, and accommodate multiple spellings of words in search results — not treating any search term as an error. Instead of showing an error, show a \"No results\" page or a section with any suggestions for how to get results to appear."
     },
     {
       "type": "guideline",
-      "content": "Placeholder text provides hints about expected input values."
+      "content": "Searching versus filtering.\n\nIn a searching scenario, a user inputs a search term for a specific thing they're looking for. In a filtering scenario, a user generally knows what they're looking for, but may not have a specific thing in mind. The search field can be used for both of these contexts. For a search experience, use the search field as-is. For a filtering experience, add a filter icon next to the search field, where a user can narrow down their search results before (or instead of) searching using a specific term. Filters can appear below the search field as tags."
     },
     {
       "type": "guideline",
-      "content": "A search field in a disabled state shows that a search option exists, but is not available in that circumstance. This can be used to maintain layout continuity and communicate that it may become available later."
+      "content": "Searching within a category.\n\nCreate a scoped search by pairing a search field with a picker component. Add a picker (either quiet or standard style) where a user can select a topic or category that they would like to search within. It's helpful to also update the search field label to communicate what the user is searching within. Spectrum previously had a specific \"search within\" component that would allow a user to filter down a search field category before searching for a particular term. It was deprecated because it did not meet accessibility and localization requirements."
     },
     {
       "type": "guideline",
-      "content": "The minimum width for a search field is 3× the height of the field, for both standard and quiet style. This minimum width guarantees that small search fields are readable and easy to target on touch devices."
+      "content": "Include a label.\n\nAny search field should include a label inside the field, in the default state. The default label text is Search, but this can be customized to be more specific for use cases like scoped search, wayfinding, or building context — acting like a prompt for a user to search more specifically. Keep in mind that once a search term is entered the label text is no longer viewable. Use help text to show search formatting examples or give hints about what to input. It can be distracting or redundant if the search field label and its help text are both communicating the same thing, so write these thoughtfully."
     },
     {
       "type": "guideline",
-      "content": "When the entered text is too long for the available horizontal space in the field, the text truncates."
+      "content": "Follow capitalization rules.\n\nThe label within the search field should be in sentence case, following Spectrum's UX writing standards for capitalization."
     },
     {
       "type": "guideline",
-      "content": "When the help text is too long for the available horizontal space, it wraps to form another line."
+      "content": "RTL.\n\nIn right‑to‑left languages, the search‑field layout is mirrored. The icon and label are right‑aligned, and the in‑field button is left‑aligned. Keep in mind that some content, such as email addresses, does not change direction or translate. The magnifying‑glass icon itself is not mirrored. The handle stays on the right side because it represents holding the object, and most people worldwide are right‑handed."
     },
     {
       "type": "guideline",
-      "content": "A search field can be navigated using a keyboard. The keyboard focus state takes the field’s visual hover state and adds a blue ring to the field in focus."
+      "content": "Keyboard interactions.\n\nKey Interaction TabMoves focus onto or off of the button.Space or EnterExecutes the button action. The focus remains on the button except if the button opens or closes the current container. In this case, the focus moves to the target or back to the caller."
     },
     {
       "type": "guideline",
-      "content": "The in-field button offers an option to clear any input search term."
+      "content": "Cursor guidelines.\n\nCursor Usage PointerUse the pointer cursor for all interactive components."
     },
     {
       "type": "guideline",
-      "content": "If search results are being shown in a menu or popover, selecting this button will close the menu and clear the field. If a search term has been entered and the results have appeared, selecting this will only clear the field and not affect the list of results."
-    },
-    {
-      "type": "guideline",
-      "content": "Search fields do not have an error state. Search functionality should anticipate spelling mistakes in search queries, and accommodate multiple spellings of words in search results — not treating any search term as an error."
-    },
-    {
-      "type": "guideline",
-      "content": "Instead of showing an error, show a “No results” page or a section with any suggestions for how to get results to appear."
-    },
-    {
-      "type": "guideline",
-      "content": "In a searching scenario, a user inputs a search term for a specific thing they’re looking for. In a filtering scenario, a user generally knows what they’re looking for, but may not have a specific thing in mind."
-    },
-    {
-      "type": "guideline",
-      "content": "The search field can be used for both of these contexts. For a search experience, use the search field as-is. For a filtering experience, add a filter icon next to the search field, where a user can narrow down their search results before (or instead of) searching using a specific term. Filters can appear below the search field as tags."
-    },
-    {
-      "type": "guideline",
-      "content": "Spectrum previously had a specific “search within” component that would allow a user to filter down a search field category before searching for a particular term. It was deprecated because it did not meet accessibility and localization requirements."
-    },
-    {
-      "type": "guideline",
-      "content": "Any search field should include a label inside the field, in the default state. The default label text is Search, but this can be customized to be more specific for use cases like scoped search, wayfinding, or building context — acting like a prompt for a user to search more specifically."
-    },
-    {
-      "type": "guideline",
-      "content": "Keep in mind that once a search term is entered the label text is no longer viewable. Use help text to show search formatting examples or give hints about what to input. It can be distracting or redundant if the search field label and its help text are both communicating the same thing, so write these thoughtfully."
-    },
-    {
-      "type": "guideline",
-      "content": "The label within the search field should be in sentence case, following Spectrum’s UX writing standards for capitalization."
+      "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 buttons—must provide a text alternative that communicates the button’s purpose. All buttons, especially icon‑only buttons, 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, AAAButtons should be understandable by assistive technologies like screen readers. This means using the proper semantic HTML or ARIA role of buttons should be utilized.Use of color 1.4.1 AColor is never used as the sole way to convey meaning in buttons. While negative buttons do use red to reinforce their purpose, every button also includes a clear text label that communicates the action it performs.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.Resize text 1.4.4 AAButtons should be built in such a way that they can be resized without assistive technology up to 200%.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 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 Requirement Criterion Level 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"
-    },
-    "hideLabel": {
-      "type": "boolean",
-      "default": false
-    },
+    "label": { "type": "string" },
+    "hideLabel": { "type": "boolean", "default": false },
     "icon": {
       "$ref": "https://opensource.adobe.com/spectrum-design-data/schemas/types/workflow-icon.json",
       "description": "Icon must be present if the label is not defined."
     },
-    "value": {
-      "type": "string"
-    },
-    "width": {
-      "type": "number"
-    },
+    "value": { "type": "string" },
+    "width": { "type": "number" },
     "size": {
       "type": "string",
       "default": "m",
       "pattern": "^(x?s|m|x{0,3}l)$",
       "values": [
-        {
-          "value": "s"
-        },
-        {
-          "value": "m"
-        },
-        {
-          "value": "l"
-        },
-        {
-          "value": "xl"
-        }
+        { "value": "s" },
+        { "value": "m" },
+        { "value": "l" },
+        { "value": "xl" }
       ]
     },
-    "helpText": {
-      "type": "string"
-    },
-    "placeholder": {
-      "type": "string"
-    },
-    "isDisabled": {
-      "type": "boolean",
-      "default": false
-    }
+    "helpText": { "type": "string" },
+    "placeholder": { "type": "string" },
+    "isDisabled": { "type": "boolean", "default": false }
   },
   "states": [
-    {
-      "name": "down",
-      "trigger": "interaction"
-    },
-    {
-      "name": "hover",
-      "trigger": "interaction"
-    },
-    {
-      "name": "focus-+-hover",
-      "trigger": "prop"
-    },
-    {
-      "name": "focus-+-not-hover",
-      "trigger": "prop"
-    },
-    {
-      "name": "keyboard-focus",
-      "trigger": "interaction"
-    }
+    { "name": "down", "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" }
     ]
   }
 }