{
  "doc": {
    "id": "accessibility/configuration/components",
    "title": "components: add component and team context to Cypress Accessibility selectors",
    "description": "Make Cypress Accessibility append component-identifying attributes, such as data-component-name, data-team, or data-page-area, to violation target selectors so every finding shows which component, team, or region it belongs to.",
    "section": "accessibility",
    "source_path": "/llm/markdown/accessibility/configuration/components.md",
    "version": "29f95bf8bb06f320986f3749f5bf09a35a409eab",
    "updated_at": "2026-09-04T10:49:54.630Z",
    "headings": [
      {
        "id": "accessibility/configuration/components#add-component-context-components",
        "text": "Add component context - components",
        "level": 1
      },
      {
        "id": "accessibility/configuration/components#why-use-components",
        "text": "Why use components?",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#how-component-attributes-appear-in-selectors",
        "text": "How component attributes appear in selectors",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#scope",
        "text": "Scope",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#setting-components",
        "text": "Setting components",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#syntax",
        "text": "Syntax",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#componentattributes",
        "text": "componentAttributes",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#componentattributefilters",
        "text": "componentAttributeFilters",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#how-are-components-rules-applied",
        "text": "How are components rules applied?",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#validation-rules",
        "text": "Validation rules",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#examples",
        "text": "Examples",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#append-the-design-system-component-name",
        "text": "Append the design-system component name",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#html",
        "text": "HTML",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#result",
        "text": "Result",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#add-component-and-team-context-together",
        "text": "Add component and team context together",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#html",
        "text": "HTML",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#result",
        "text": "Result",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#add-the-surrounding-page-region",
        "text": "Add the surrounding page region",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#html",
        "text": "HTML",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#result",
        "text": "Result",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#keep-a-generic-component-name-out-of-selectors",
        "text": "Keep a generic component name out of selectors",
        "level": 3
      },
      {
        "id": "accessibility/configuration/components#config",
        "text": "Config",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#html",
        "text": "HTML",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#result",
        "text": "Result",
        "level": 4
      },
      {
        "id": "accessibility/configuration/components#how-components-compares-to-other-options",
        "text": "How components compares to other options",
        "level": 2
      },
      {
        "id": "accessibility/configuration/components#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "accessibility/configuration/components#why-use-components",
      "doc_id": "accessibility/configuration/components",
      "heading": "Why use components?",
      "heading_level": 2,
      "content_markdown": "## Why use components?\n\n*   **Place every finding in context**: A selector like `[data-cy=\"row-action\"][data-component=\"DataGridDeleteButton\"]` says exactly which component is responsible, where a bare identifier could be any button in your application.\n*   **Route issues to the right owner**: Append an attribute like `data-team` and you can assign accessibility findings, or group them in a report, by the team that owns the DOM.\n*   **Speed up handoffs to people and AI**: Selectors that carry component and page context can be dropped into a Jira ticket or handed to an LLM for triage without the surrounding page HTML.\n*   **Cross-reference your design system**: Attributes such as `data-design-system-version` in the selector let you correlate accessibility issues with the component library version that produced them.\n",
      "section": "accessibility",
      "anchors": [
        "why-use-components"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 161
    },
    {
      "id": "accessibility/configuration/components#how-component-attributes-appear-in-selectors",
      "doc_id": "accessibility/configuration/components",
      "heading": "How component attributes appear in selectors",
      "heading_level": 2,
      "content_markdown": "## How component attributes appear in selectors\n\nCypress Accessibility identifies each element with a stable selector, replacing the default Axe-Core® target so results for the same element can be deduplicated across the many snapshots in a run. That identifier is chosen from a prioritized list of attributes ([`significantAttributes`](/llm/markdown/accessibility/configuration/significantattributes.md) followed by defaults like `data-cy` and `id`) and is usually the shortest thing that uniquely identifies the element.\n\nEvery attribute you list in `componentAttributes` is treated as **required**: wherever it appears on the element or one of its ancestors, Cypress keeps it in the selector. Take this button, which fails an accessibility check because its label text is hidden:\n\n```\n<button data-cy=\"signup\" data-component=\"IconButton\">\n  <span style=\"display:none\">Sign up now!</span>\n</button>\n```\n\nBy default, the violation target selector is just the identifier:\n\n```\n[data-cy=\"signup\"]\n```\n\nViewed on its own, that could be any button. List `data-component` as a component attribute:\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\nNow the component name is appended, even though the selector was already unique:\n\n```\n[data-cy=\"signup\"][data-component=\"IconButton\"]\n```\n\nWhen a required attribute is on an **ancestor** instead of the element itself, Cypress adds it as context with a descendant combinator. Given a `data-page-area` on a wrapping section:\n\n```\n<section data-page-area=\"checkout\">\n  <button data-cy=\"pay\"><span style=\"display:none\">Pay</span></button>\n</section>\n```\n\nlisting `data-page-area` reports the button with that region in front:\n\n```\n[data-page-area=\"checkout\"] [data-cy=\"pay\"]\n```\n\ncomponents adds context on top of whatever already identifies an element. To change which attribute _identifies_ it, use [`significantAttributes`](/llm/markdown/accessibility/configuration/significantattributes.md) instead.\n",
      "section": "accessibility",
      "anchors": [
        "how-component-attributes-appear-in-selectors"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 339
    },
    {
      "id": "accessibility/configuration/components#scope",
      "doc_id": "accessibility/configuration/components",
      "heading": "Scope",
      "heading_level": 2,
      "content_markdown": "## Scope\n\nThe components object is only valid under an `accessibility` key in your App Quality configuration. Unlike [`significantAttributes`](/llm/markdown/accessibility/configuration/significantattributes.md) or [`attributeFilters`](/llm/markdown/accessibility/configuration/attributefilters.md), it has no root-level or UI Coverage form. It can also be set inside a [`profiles`](/llm/markdown/accessibility/configuration/profiles.md) entry to apply to tagged runs.\n",
      "section": "accessibility",
      "anchors": [
        "scope"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 57
    },
    {
      "id": "accessibility/configuration/components#setting-components",
      "doc_id": "accessibility/configuration/components",
      "heading": "Setting components",
      "heading_level": 2,
      "content_markdown": "## Setting components\n\nTo add or edit components, open the **App Quality** tab in your project settings in Cypress Cloud. See [Setting configuration](/llm/markdown/accessibility/configuration/overview.md#Setting-Configuration) for details, including how to regenerate past reports with a new configuration without rerunning your tests.\n",
      "section": "accessibility",
      "anchors": [
        "setting-components"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 52
    },
    {
      "id": "accessibility/configuration/components#syntax",
      "doc_id": "accessibility/configuration/components",
      "heading": "Syntax",
      "heading_level": 2,
      "content_markdown": "## Syntax\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        {\n          \"attributeName\": string,\n          \"includeInSelector\": boolean,\n          \"comment\": string\n        }\n      ],\n      \"componentAttributeFilters\": [\n        {\n          \"attribute\": string,\n          \"value\": string,\n          \"include\": boolean,\n          \"comment\": string\n        }\n      ],\n      \"comment\": string\n    }\n  }\n}\n```\n\n### `componentAttributes`\n\nEach entry names an attribute to append to the selector when it's present on the element with the violation. Attribute names are stored in lowercase and **must be unique** in the list.\n\n| Option | Required | Default | Description |\n| --- | --- | --- | --- |\n| `attributeName` | Yes |  | The HTML attribute name to append, for example `data-component-name`. `class` is also supported. |\n| `includeInSelector` | No | `true` | When `true`, the attribute is appended to the selector wherever the element has it. |\n| `comment` | No |  | A note for your team explaining why the entry exists. Comments never appear in reports. |\n\nWhen `includeInSelector` is `false`, the entry is kept for documentation or future use but doesn't change selector generation, the same as leaving it out.\n\n### `componentAttributeFilters`\n\nThese filters fine-tune **which attribute values** are appended. They apply only to the attributes in `componentAttributes`, using the same regular-expression style as [`attributeFilters`](/llm/markdown/accessibility/configuration/attributefilters.md): `attribute` and `value` are regex patterns. For a given attribute value, **the first rule whose `attribute` and `value` both match** decides whether it's appended. A filter with no matching `componentAttributes` entry does nothing.\n\n| Option | Required | Default | Description |\n| --- | --- | --- | --- |\n| `attribute` | Yes |  | Regex matched against the component attribute's name. |\n| `value` | No | `.*` | Regex matched against the attribute's value. |\n| `include` | No | `true` | When `false`, matching values are not appended to the selector. |\n| `comment` | No |  | A note for your team. Comments never appear in reports. |\n\nUse `include: false` to keep a noisy or generic value out of your selectors, such as a layout primitive whose name adds no context, while still appending the meaningful ones.\n\nYou can also add a `comment` to the components object itself to document the whole block. Comments are for your team, never appear in reports, and are the supported place for notes because Cypress Cloud rejects properties it doesn't recognize. See [Comments](/llm/markdown/accessibility/configuration/overview.md#Comments).\n\n### How are components rules applied?\n\nKeep these behaviors in mind when building your configuration:\n\n*   **Listed attributes are kept wherever they appear.** A component attribute on the element is appended to its selector; the same attribute on an ancestor is added in front as descendant-combinator context. An element whose ancestor chain has none of the listed attributes is unaffected.\n*   **They're added on top of the identifier, not instead of it.** The element is still identified by `significantAttributes` and the defaults; component attributes add context. They're added even when the selector is already unique.\n*   **They help with uniqueness and deduplication.** Because a required attribute is part of the selector, one that distinguishes the element can make the selector shorter and more stable than the positional fallback Cypress would use otherwise, which keeps the same element from splitting into several across snapshots.\n*   **On one element, appended attributes follow your list order.** Multiple attributes appended to the same element appear in the order you list them in `componentAttributes`. An attribute that already identifies the element isn't added a second time.\n*   **Default attribute filters don't apply here.** The [default filters](/llm/markdown/accessibility/configuration/attributefilters.md) that keep dynamic, UUID-like values out of _identifying_ selectors don't touch component attributes. `componentAttributeFilters` are the only way to exclude component-attribute values, so list a rule if an attribute's value is sometimes noisy.\n*   **`class` is supported.** Listing `class` as a component attribute appends the element's class value; `componentAttributeFilters` apply to it the same way.\n\n### Validation rules\n\nCypress Cloud validates the whole configuration before saving it and rejects a components block that breaks any of these:\n\n*   Each `attributeName` must be a valid HTML attribute name. Names are compared in lowercase and must be unique across `componentAttributes`.\n*   Each `componentAttributeFilters` `attribute` and `value` must be a valid regular expression.\n*   No two `componentAttributeFilters` rules may be identical across `attribute`, `value`, and `include`.\n*   Only the properties documented above are allowed. An unrecognized key is rejected rather than ignored.\n",
      "section": "accessibility",
      "anchors": [
        "syntax"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 963
    },
    {
      "id": "accessibility/configuration/components#componentattributes",
      "doc_id": "accessibility/configuration/components",
      "heading": "componentAttributes",
      "heading_level": 3,
      "content_markdown": "### `componentAttributes`\n\nEach entry names an attribute to append to the selector when it's present on the element with the violation. Attribute names are stored in lowercase and **must be unique** in the list.\n\n| Option | Required | Default | Description |\n| --- | --- | --- | --- |\n| `attributeName` | Yes |  | The HTML attribute name to append, for example `data-component-name`. `class` is also supported. |\n| `includeInSelector` | No | `true` | When `true`, the attribute is appended to the selector wherever the element has it. |\n| `comment` | No |  | A note for your team explaining why the entry exists. Comments never appear in reports. |\n\nWhen `includeInSelector` is `false`, the entry is kept for documentation or future use but doesn't change selector generation, the same as leaving it out.\n",
      "section": "accessibility",
      "anchors": [
        "componentattributes"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 187
    },
    {
      "id": "accessibility/configuration/components#componentattributefilters",
      "doc_id": "accessibility/configuration/components",
      "heading": "componentAttributeFilters",
      "heading_level": 3,
      "content_markdown": "### `componentAttributeFilters`\n\nThese filters fine-tune **which attribute values** are appended. They apply only to the attributes in `componentAttributes`, using the same regular-expression style as [`attributeFilters`](/llm/markdown/accessibility/configuration/attributefilters.md): `attribute` and `value` are regex patterns. For a given attribute value, **the first rule whose `attribute` and `value` both match** decides whether it's appended. A filter with no matching `componentAttributes` entry does nothing.\n\n| Option | Required | Default | Description |\n| --- | --- | --- | --- |\n| `attribute` | Yes |  | Regex matched against the component attribute's name. |\n| `value` | No | `.*` | Regex matched against the attribute's value. |\n| `include` | No | `true` | When `false`, matching values are not appended to the selector. |\n| `comment` | No |  | A note for your team. Comments never appear in reports. |\n\nUse `include: false` to keep a noisy or generic value out of your selectors, such as a layout primitive whose name adds no context, while still appending the meaningful ones.\n\nYou can also add a `comment` to the components object itself to document the whole block. Comments are for your team, never appear in reports, and are the supported place for notes because Cypress Cloud rejects properties it doesn't recognize. See [Comments](/llm/markdown/accessibility/configuration/overview.md#Comments).\n",
      "section": "accessibility",
      "anchors": [
        "componentattributefilters"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 281
    },
    {
      "id": "accessibility/configuration/components#how-are-components-rules-applied",
      "doc_id": "accessibility/configuration/components",
      "heading": "How are components rules applied?",
      "heading_level": 3,
      "content_markdown": "### How are components rules applied?\n\nKeep these behaviors in mind when building your configuration:\n\n*   **Listed attributes are kept wherever they appear.** A component attribute on the element is appended to its selector; the same attribute on an ancestor is added in front as descendant-combinator context. An element whose ancestor chain has none of the listed attributes is unaffected.\n*   **They're added on top of the identifier, not instead of it.** The element is still identified by `significantAttributes` and the defaults; component attributes add context. They're added even when the selector is already unique.\n*   **They help with uniqueness and deduplication.** Because a required attribute is part of the selector, one that distinguishes the element can make the selector shorter and more stable than the positional fallback Cypress would use otherwise, which keeps the same element from splitting into several across snapshots.\n*   **On one element, appended attributes follow your list order.** Multiple attributes appended to the same element appear in the order you list them in `componentAttributes`. An attribute that already identifies the element isn't added a second time.\n*   **Default attribute filters don't apply here.** The [default filters](/llm/markdown/accessibility/configuration/attributefilters.md) that keep dynamic, UUID-like values out of _identifying_ selectors don't touch component attributes. `componentAttributeFilters` are the only way to exclude component-attribute values, so list a rule if an attribute's value is sometimes noisy.\n*   **`class` is supported.** Listing `class` as a component attribute appends the element's class value; `componentAttributeFilters` apply to it the same way.\n",
      "section": "accessibility",
      "anchors": [
        "how-are-components-rules-applied"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 328
    },
    {
      "id": "accessibility/configuration/components#validation-rules",
      "doc_id": "accessibility/configuration/components",
      "heading": "Validation rules",
      "heading_level": 3,
      "content_markdown": "### Validation rules\n\nCypress Cloud validates the whole configuration before saving it and rejects a components block that breaks any of these:\n\n*   Each `attributeName` must be a valid HTML attribute name. Names are compared in lowercase and must be unique across `componentAttributes`.\n*   Each `componentAttributeFilters` `attribute` and `value` must be a valid regular expression.\n*   No two `componentAttributeFilters` rules may be identical across `attribute`, `value`, and `include`.\n*   Only the properties documented above are allowed. An unrecognized key is rejected rather than ignored.\n",
      "section": "accessibility",
      "anchors": [
        "validation-rules"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 112
    },
    {
      "id": "accessibility/configuration/components#examples",
      "doc_id": "accessibility/configuration/components",
      "heading": "Examples",
      "heading_level": 2,
      "content_markdown": "## Examples\n\n### Append the design-system component name\n\nThe button below fails `button-name` because its label is hidden. It carries a `data-cy` test id and a `data-component` name from the design system. Listing `data-component` appends the component name to the selector, so the finding names the component instead of a generic id.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<button data-cy=\"signup\" data-component=\"IconButton\">\n  <span style=\"display:none\">Sign up now!</span>\n</button>\n```\n\n#### Result\n\nThe violation target selector displayed in the report:\n\n```\n[data-cy=\"signup\"][data-component=\"IconButton\"]\n```\n\n### Add component and team context together\n\n`componentAttributes` is a list, so you can append more than one attribute. Here the design-system component name and the owning team are both added, so findings can be read, filtered, or assigned by either.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true },\n        { \"attributeName\": \"data-team\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<img\n  data-testid=\"hero-banner\"\n  data-component=\"HeroBanner\"\n  data-team=\"marketing\"\n  src=\"hero.png\"\n/>\n```\n\n#### Result\n\nThe image fails `image-alt`, and its selector now shows the component and the team that owns it:\n\n```\n[data-testid=\"hero-banner\"][data-component=\"HeroBanner\"][data-team=\"marketing\"]\n```\n\n### Add the surrounding page region\n\nComponent attributes don't have to be on the element itself. When a listed attribute sits on an ancestor, such as a `data-page-area` on the wrapping landmark, Cypress adds it in front of the identifier as context, so a violation reads as belonging to a region of the page.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-page-area\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<nav data-page-area=\"global-header\">\n  <button data-cy=\"menu-toggle\">\n    <span style=\"display:none\">Open menu</span>\n  </button>\n</nav>\n```\n\n#### Result\n\nThe button is identified by its own `data-cy`, with the region prepended as ancestor context:\n\n```\n[data-page-area=\"global-header\"] [data-cy=\"menu-toggle\"]\n```\n\n### Keep a generic component name out of selectors\n\nSome component names add no context. A layout primitive like `Box` wraps elements all over the application, so appending it to every selector is noise. Keep `data-component` appended in general, but use a `componentAttributeFilters` rule to skip the values that don't help.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ],\n      \"componentAttributeFilters\": [\n        {\n          \"attribute\": \"data-component\",\n          \"value\": \"^(Box|Stack|Flex)$\",\n          \"include\": false,\n          \"comment\": \"Layout primitives add no useful context\"\n        }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<button data-cy=\"row-delete\" data-component=\"DataGridDeleteButton\">Delete</button>\n<button data-cy=\"page-close\" data-component=\"Box\">Close</button>\n```\n\n#### Result\n\nThe meaningful component name is appended; the layout primitive is filtered out, leaving that element on its identifier alone:\n\n```\n[data-cy=\"row-delete\"][data-component=\"DataGridDeleteButton\"]\n[data-cy=\"page-close\"]\n```\n\nAfter saving configuration changes, regenerate a recent run to preview the effect of your rules without rerunning your tests. See [Setting configuration](/llm/markdown/accessibility/configuration/overview.md#Setting-Configuration) for how to regenerate a report.\n",
      "section": "accessibility",
      "anchors": [
        "examples"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 629
    },
    {
      "id": "accessibility/configuration/components#append-the-design-system-component-name",
      "doc_id": "accessibility/configuration/components",
      "heading": "Append the design-system component name",
      "heading_level": 3,
      "content_markdown": "### Append the design-system component name\n\nThe button below fails `button-name` because its label is hidden. It carries a `data-cy` test id and a `data-component` name from the design system. Listing `data-component` appends the component name to the selector, so the finding names the component instead of a generic id.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<button data-cy=\"signup\" data-component=\"IconButton\">\n  <span style=\"display:none\">Sign up now!</span>\n</button>\n```\n\n#### Result\n\nThe violation target selector displayed in the report:\n\n```\n[data-cy=\"signup\"][data-component=\"IconButton\"]\n```\n",
      "section": "accessibility",
      "anchors": [
        "append-the-design-system-component-name"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 132
    },
    {
      "id": "accessibility/configuration/components#add-component-and-team-context-together",
      "doc_id": "accessibility/configuration/components",
      "heading": "Add component and team context together",
      "heading_level": 3,
      "content_markdown": "### Add component and team context together\n\n`componentAttributes` is a list, so you can append more than one attribute. Here the design-system component name and the owning team are both added, so findings can be read, filtered, or assigned by either.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true },\n        { \"attributeName\": \"data-team\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<img\n  data-testid=\"hero-banner\"\n  data-component=\"HeroBanner\"\n  data-team=\"marketing\"\n  src=\"hero.png\"\n/>\n```\n\n#### Result\n\nThe image fails `image-alt`, and its selector now shows the component and the team that owns it:\n\n```\n[data-testid=\"hero-banner\"][data-component=\"HeroBanner\"][data-team=\"marketing\"]\n```\n",
      "section": "accessibility",
      "anchors": [
        "add-component-and-team-context-together"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 137
    },
    {
      "id": "accessibility/configuration/components#config",
      "doc_id": "accessibility/configuration/components",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true },\n        { \"attributeName\": \"data-team\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n",
      "section": "accessibility",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 40
    },
    {
      "id": "accessibility/configuration/components#add-the-surrounding-page-region",
      "doc_id": "accessibility/configuration/components",
      "heading": "Add the surrounding page region",
      "heading_level": 3,
      "content_markdown": "### Add the surrounding page region\n\nComponent attributes don't have to be on the element itself. When a listed attribute sits on an ancestor, such as a `data-page-area` on the wrapping landmark, Cypress adds it in front of the identifier as context, so a violation reads as belonging to a region of the page.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-page-area\", \"includeInSelector\": true }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<nav data-page-area=\"global-header\">\n  <button data-cy=\"menu-toggle\">\n    <span style=\"display:none\">Open menu</span>\n  </button>\n</nav>\n```\n\n#### Result\n\nThe button is identified by its own `data-cy`, with the region prepended as ancestor context:\n\n```\n[data-page-area=\"global-header\"] [data-cy=\"menu-toggle\"]\n```\n",
      "section": "accessibility",
      "anchors": [
        "add-the-surrounding-page-region"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 149
    },
    {
      "id": "accessibility/configuration/components#keep-a-generic-component-name-out-of-selectors",
      "doc_id": "accessibility/configuration/components",
      "heading": "Keep a generic component name out of selectors",
      "heading_level": 3,
      "content_markdown": "### Keep a generic component name out of selectors\n\nSome component names add no context. A layout primitive like `Box` wraps elements all over the application, so appending it to every selector is noise. Keep `data-component` appended in general, but use a `componentAttributeFilters` rule to skip the values that don't help.\n\n#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ],\n      \"componentAttributeFilters\": [\n        {\n          \"attribute\": \"data-component\",\n          \"value\": \"^(Box|Stack|Flex)$\",\n          \"include\": false,\n          \"comment\": \"Layout primitives add no useful context\"\n        }\n      ]\n    }\n  }\n}\n```\n\n#### HTML\n\n```\n<button data-cy=\"row-delete\" data-component=\"DataGridDeleteButton\">Delete</button>\n<button data-cy=\"page-close\" data-component=\"Box\">Close</button>\n```\n\n#### Result\n\nThe meaningful component name is appended; the layout primitive is filtered out, leaving that element on its identifier alone:\n\n```\n[data-cy=\"row-delete\"][data-component=\"DataGridDeleteButton\"]\n[data-cy=\"page-close\"]\n```\n\nAfter saving configuration changes, regenerate a recent run to preview the effect of your rules without rerunning your tests. See [Setting configuration](/llm/markdown/accessibility/configuration/overview.md#Setting-Configuration) for how to regenerate a report.\n",
      "section": "accessibility",
      "anchors": [
        "keep-a-generic-component-name-out-of-selectors"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 208
    },
    {
      "id": "accessibility/configuration/components#config",
      "doc_id": "accessibility/configuration/components",
      "heading": "Config",
      "heading_level": 4,
      "content_markdown": "#### Config\n\nApp Quality Config\n\n```\n{\n  \"accessibility\": {\n    \"components\": {\n      \"componentAttributes\": [\n        { \"attributeName\": \"data-component\", \"includeInSelector\": true }\n      ],\n      \"componentAttributeFilters\": [\n        {\n          \"attribute\": \"data-component\",\n          \"value\": \"^(Box|Stack|Flex)$\",\n          \"include\": false,\n          \"comment\": \"Layout primitives add no useful context\"\n        }\n      ]\n    }\n  }\n}\n```\n",
      "section": "accessibility",
      "anchors": [
        "config"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 56
    },
    {
      "id": "accessibility/configuration/components#result",
      "doc_id": "accessibility/configuration/components",
      "heading": "Result",
      "heading_level": 4,
      "content_markdown": "#### Result\n\nThe meaningful component name is appended; the layout primitive is filtered out, leaving that element on its identifier alone:\n\n```\n[data-cy=\"row-delete\"][data-component=\"DataGridDeleteButton\"]\n[data-cy=\"page-close\"]\n```\n\nAfter saving configuration changes, regenerate a recent run to preview the effect of your rules without rerunning your tests. See [Setting configuration](/llm/markdown/accessibility/configuration/overview.md#Setting-Configuration) for how to regenerate a report.\n",
      "section": "accessibility",
      "anchors": [
        "result"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 71
    },
    {
      "id": "accessibility/configuration/components#how-components-compares-to-other-options",
      "doc_id": "accessibility/configuration/components",
      "heading": "How components compares to other options",
      "heading_level": 2,
      "content_markdown": "## How components compares to other options\n\nThree configuration properties all work with attributes, but they do different jobs:\n\n*   [`significantAttributes`](/llm/markdown/accessibility/configuration/significantattributes.md) chooses the single attribute that **identifies** the element and becomes its selector.\n*   [`attributeFilters`](/llm/markdown/accessibility/configuration/attributefilters.md) **removes** dynamic or generated attribute values from identification, so they can't be used as selectors.\n*   components **adds context** to the selector, from the element or its ancestors, on top of whatever identifies the element, without changing which attribute identifies it.\n\nFor background on how Cypress picks identifiers, see [Element identification](/llm/markdown/accessibility/core-concepts/element-identification.md).\n",
      "section": "accessibility",
      "anchors": [
        "how-components-compares-to-other-options"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 115
    },
    {
      "id": "accessibility/configuration/components#see-also",
      "doc_id": "accessibility/configuration/components",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [Element identification](/llm/markdown/accessibility/core-concepts/element-identification.md): how elements are identified across snapshots.\n*   [`significantAttributes`](/llm/markdown/accessibility/configuration/significantattributes.md): choose which attribute identifies an element.\n*   [`attributeFilters`](/llm/markdown/accessibility/configuration/attributefilters.md): stop dynamic or generated attribute values from identifying elements.\n*   [Inspecting violation details](/llm/markdown/accessibility/reports/element-detail-view.md): where violation target selectors appear in reports.\n*   [Work with AI agents](/llm/markdown/accessibility/work-with-ai-agents.md): triage findings through Cypress Cloud MCP.\n*   [Configuration overview](/llm/markdown/accessibility/configuration/overview.md): where to set configuration and regenerate reports.\n*   [Cypress Accessibility FAQ](/llm/markdown/accessibility/faq.md): common questions and troubleshooting.\n",
      "section": "accessibility",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/accessibility/configuration/components.json",
      "token_estimate": 95
    }
  ]
}