Docs for app quality config profiles and comment field

docs/accessibility/changelog.mdx

@@ -9,6 +9,15 @@ sidebar_position: 200
 
 # Changelog
 
+## Week of 12/12/2025
+
+- You can now create Jira issues directly from accessibility violations in the detail view. This allows you to quickly track and prioritize accessibility issues within your existing Jira workflow. The created Jira issue will include a link back to the accessibility violation in Cypress Cloud. [Learn more about creating Jira issues](/accessibility/core-concepts/inspecting-violation-details#create-jira-issue).
+
+## Week of 12/1/2025
+
+- The `profiles` configuration property allows you to use different configuration settings for different runs based on [run tags](/app/references/command-line#cypress-run-tag-lt-tag-gt). This enables you to customize accessibility testing behavior for different environments, branches, or test scenarios. See the [Profiles](/accessibility/configuration/profiles) guide for more details.
+- All configuration objects now support an optional `comment` property that you can use to provide context and explanations for why certain values are set. This helps make your configuration easier to understand and maintain, especially when working in teams or revisiting configuration after some time.
+
 ## Week of 10/13/2025
 
 - Individual rules, or set of rules, can now be ignored for specific elements using [a `data-a11y-ignore` attribute](/accessibility/configuration/ignoring-rules-per-element).

docs/accessibility/configuration/overview.mdx

@@ -22,50 +22,88 @@ To add or modify the configuration for your project, navigate to the "App Qualit
   alt="The Cypress Cloud UI showing the configuration editor"
 />
 
-You can use the provided editor to write configuration in JSON format. A complete configuration with all available options looks as follows:
+You can use the provided editor to write configuration in JSON format.
 
-```typescript
+After new configuration changes have been saved, you can reprocess any historical run using the "regenerate" button on the properties tab where the configuration values that were used for that run are displayed.
+
+This allows you to iterate on the config quickly without having to execute test runs and wait for the results. You can try out different configurations and see what effects your changes have to make sure everything works the way you intend.
+
+### Viewing Configuration for a Run
+
+You can view configuration information for each run in the Properties tab, as shown below. This configuration is determined when your run begins.
+
+<DocsImage
+  src="/img/accessibility/configuration/cypress-cloud-properties-tab-application-quality-config.png"
+  alt="The properties tab for a run, with an Application Quality section at the bottom"
+/>
+
+### Comments
+
+All configuration objects support an optional `comment` property that you can use to provide context and explanations for why certain values are set. This helps make your configuration easier to understand and maintain, especially when working in teams or revisiting configuration after some time.
+
+```json
+{
+  "elementFilters": [
+    {
+      "selector": "[data-testid*='temp']",
+      "include": false,
+      "comment": "Exclude temporary test elements from accessibility reports"
+    }
+  ]
+}
+```
+
+### Profiles
+
+The `profiles` property allows you to use different configuration settings for different runs based on [run tags](/app/references/command-line#cypress-run-tag-lt-tag-gt). See the [Profiles](/accessibility/configuration/profiles) guide for more details.
+
+### Complete configuration example
+
+A complete configuration with all available options looks as follows:
+
+```json
 {
   "views": [
     {
       "pattern": string,
       "groupBy": [
         string
-      ]
+      ],
+      "comment": string
     }
   ],
   "viewFilters": [
     {
       "pattern": string,
-      "include": boolean
+      "include": boolean,
+      "comment": string
     }
   ],
   "elementFilters": [
     {
       "selector": string,
-      "include": boolean
+      "include": boolean,
+      "comment": string
     }
   ],
   "significantAttributes": [
     string
-  ]
+  ],
   "attributeFilters": [
     {
       "attribute": string,
       "value": string,
-      "include": boolean
+      "include": boolean,
+      "comment": string
+    }
+  ],
+  "profiles": [
+    {
+      "name": string,
+      "config": {
+        // Any App Quality configuration options
+      }
     }
   ]
 }
 ```
-
-Note that these root-level App Quality configuration properties (`elementFilters`, `views`, and `viewFilters`) impact both UI Coverage and Accessibility.
-
-### Viewing Configuration for a Run
-
-You can view configuration information for each run in the Properties tab, as shown below. This is the configuration set for the project at the start of the run.
-
-<DocsImage
-  src="/img/accessibility/configuration/cypress-cloud-properties-tab-application-quality-config.png"
-  alt="The properties tab for a run, with an Application Quality section at the bottom"
-/>

docs/accessibility/configuration/profiles.mdx

@@ -0,0 +1,12 @@
+---
+sidebar_label: profiles
+title: 'Profiles | Cypress Accessibility'
+description: 'The `profiles` configuration property allows you to create configuration overrides that are applied based on run tags.'
+sidebar_position: 100
+---
+
+<ProductHeading product="accessibility" />
+
+# profiles
+
+<Profiles />

docs/accessibility/core-concepts/compare-reports.mdx

@@ -164,3 +164,17 @@ It's likely that your tests have never been used for always-on accessibility tes
 For example, sometimes the test may spend enough time on a page to see a confirmation message after a form is submitted, unless the server response is slow, then the test may finish without rendering the state.
 
 There are different solutions depending on the nature of the issue. If you want to ensure the state is always picked up in Cypress Accessibility, you can add some assertion about that state to your tests. On the other hand, if you do not want to account for this state at all, it can be ignored with [`elementFilters`](/accessibility/configuration/elementfilters) configuration. Either approach will lead to a more stable branch comparison.
+
+## Optimizing for Pull Request reviews
+
+If you plan to use branch comparison for investigating Pull Requests that have been blocked through the Results API for not meeting your standard, it's useful to implement this in a gradual way, prioritizing the developer experience at first.
+
+Choose a scope of rules, page, and elements that reduces ambiguity. A good starting point is something like "We will fail a build if it introduces new critical issues on the login or checkout page."
+
+If your application is unstable between runs in terms of content, pages, or different states reached, fine tune your configuration to ignore the unstable parts of the DOM that have issues already. These can be documented and dealt with on their own.
+
+When everything is dialled in correctly, the Branch Review diff will be 100% clean, unless something has actually changed in an area you didn't already know about. This gives you the highest confidence that if an issue is blocking a merge, it is genuinely a new problem introduced by the incoming Pull Request.
+
+If the team is not already familiar with accessibility, it's useful to consider which rules to start with. See the [starting from scratch guide](/accessibility/guides/improve-accessibility) for suggestions about this.
+
+If multiple teams are working on the same project and need accessibility results to be isolated from each other, consider splitting runs into dedicated Cypress projects or using [configuration profiles](/accessibility/configuration/profiles) so that each team can have a customized report for the areas they are responsible for.

docs/accessibility/core-concepts/inspecting-violation-details.mdx

@@ -36,14 +36,63 @@ Clicking on an element in the expanded Rule section provides:
 - **Pinned Element**: Highlights the element in the UI for easier identification.
 - **Copy Selector**: A button to copy the CSS selector uniquely identifying the element.
 - **Print to Console**: Logs the element reference to the browser's console for debugging. In Chrome-based browsers, you can right-click the logged element and select "Reveal in elements panel" to navigate directly to the live DOM.
-- **Share issue**: A button to copy markdown or plain text snippet to share the issue with your team or collaborators.
+- **Actions**: Share details of the accessibility problem or create a Jira issue (if the Jira integration is installed).
 - **Solutions**: A list of potential solutions to address the issue.
 
 <DocsImage
   src="/img/accessibility/core-concepts/cypress-accessibility-element-details-on-click.png"
   alt="Details displayed after clicking on an element in the Rules section of the Cypress Accessibility issue detail view. Options to copy the selector, print to console, share the issue, and solutions are available."
 />
 
+## Actions
+
+When you click on an element in the expanded Rule section, you can copy details of the accessibility violation to share, or directly create a Jira issue if you have the [Cypress Cloud Jira integration](/cloud/integrations/jira) installed.
+
+### Share issue
+
+The **Share issue** button allows you to copy a markdown or plain text snippet containing key details and related links for a particular accessibility violation. This makes it easy to share the issue with your team members or add it to tickets in your issue tracking system.
+
+<DocsImage
+  src="/img/accessibility/core-concepts/cypress-accessibility-element-details-on-click.png"
+  width="60%"
+  alt="The Share issue button visible in the element details panel after clicking on an element in the Rules section."
+/>
+
+The shared snippet includes:
+
+- The rule name and description
+- The element selector
+- Links back to the violation in Cypress Cloud
+- Context about the violation
+
+### Create Jira issue
+
+You can create Jira issues directly from accessibility violations in the detail view. This allows you to quickly track and prioritize accessibility issues within your existing Jira workflow.
+
+<DocsImage
+  src="/img/accessibility/a11y-jira-create.png"
+  width="60%"
+  alt="The Create Jira issue button in the element details panel for an accessibility violation."
+/>
+
+To create a Jira issue:
+
+1. Click on an element in the expanded Rule section to open the element details.
+2. Click the **Create Jira issue** button to open the Jira issue creation form.
+
+<DocsImage
+  src="/img/accessibility/a11y-jira-modal.png"
+  width="60%"
+  alt="The Jira issue creation modal form for creating a new issue from an accessibility violation."
+/>
+
+3. Complete the form by selecting the Jira project, issue type, assignee, and any additional fields required by your Jira configuration.
+4. Submit the form to create the issue in Jira.
+
+The created Jira issue will include a link back to the accessibility violation in Cypress Cloud, making it easy to navigate between your issue tracker and the detailed violation information.
+
+Additional context like related elements or comments for future triage can be added to the issue summary.
+
 ## Snapshots
 
 Snapshots are fully hydrated HTML and CSS representations of your application's state during the test. Unlike screenshots or video, these snapshots allow you to:
@@ -53,4 +102,4 @@ Snapshots are fully hydrated HTML and CSS representations of your application's
 
 This area also has the Test Replay button to provide access to any tests where this snapshot appeared, as well as the specific URL of the snapshot displayed at the bottom of the screen.
 
-It's also possible to cycle through the available snapshots to see all the states of the application that were captured, but this is usually not necessary. Think of snapshots more as examples and evidence relate to elements that are listed on the left hand side of the screen. The most useful way to go through the report is this way.
+It's also possible to cycle through the available snapshots to see all the states of the application that were captured, but this is usually not necessary. Think of snapshots more as examples and evidence related to elements that are listed on the left hand side of the screen. The most useful way to browse the report is to move through the elements on the left.

docs/accessibility/core-concepts/run-level-reports.mdx

@@ -85,7 +85,7 @@ Attributes for each rule include:
   - **Inapplicable**: No applicable elements detected for this rule.
   - **Ignored by config**: The rule was excluded at the project level.
 - **Description**: A summary of the rule.
-- **Severity**: The Axe Core® severity level for the rule.
+- **Severity**: The Axe Core® impact level for the rule.
 - **Counts**: The counts of failed, inconclusive, and ignored elements for the rule.
 
 ## Filtering

docs/accessibility/get-started/introduction.mdx

@@ -9,11 +9,11 @@ sidebar_position: 10
 
 # Automated accessibility checks on every test
 
-Cypress Accessibility adds detailed accessibility checks and workflows in Cypress Cloud, with zero impact on test execution.
+Cypress Accessibility adds detailed accessibility checks to Cypress Cloud. Checks run against every step of every test, with zero impact on test execution.
 
-- Instantly visualize, triage, and fix accessibility violations without any additional code or configuration.
-- Dive deep into each violation with live, fully-rendered DOM snapshots of your application as it appeared during your tests.
-- Filter out the noise to explore only newly-introduced issues related to specific commits.
+- Visualize, triage, and fix accessibility violations without any additional code or configuration.
+- Debug each violation with interactive DOM snapshots from.
+- Filter to newly-introduced issues related to specific commits.
 - Track your team's progress over time with historical scores to monitor improvements and identify regressions.
 
 <Btn
@@ -181,9 +181,11 @@ Cypress Accessibility delivers detailed, actionable accessibility reports direct
 - **Comprehensive reporting**: During test execution, unique states—defined by distinct DOM structures—are recorded for end-to-end views and components.
 - **DOM snapshots**: Each detected violation is accompanied by a [full-page, inspectable DOM snapshot](/accessibility/core-concepts/inspecting-violation-details), highlighting the exact location and context of the violation.
 - **Report generation**: [Detailed reports](/accessibility/core-concepts/run-level-reports) are generated, offering sortable and filterable views by page, component, or the entire test run. Rule-based summaries for an aggregated view of accessibility outcomes for the entire run are also available.
-- **Run comparison**: Compare the results from two runs and see only the new issues. Know before you merge if a code change is going to cause new accessibility problems.
+- **Run comparison**: [Compare the results](/accessibility/core-concepts/compare-reports) from two runs and see only the new issues. Know before you merge if a code change is going to cause new accessibility problems.
+- **Deep linking and sharing**: Easily share whatever you are looking at with your team at any time by copying the link, or using built-in sharing functionality and [Jira issue creation](http://localhost:3000/accessibility/core-concepts/inspecting-violation-details#Create-Jira-issue).
 - **Selective element handling**: Elements marked as "ignored" in tests are excluded from scoring but remain visible for manual review, ensuring flexibility via [configuration](/accessibility/configuration/overview).
 - **Flexible pipeline integration**: The [Results API](/accessibility/results-api) allows you to programmatically control your CI pipeline's behavior based on accessibility outcomes, enabling enforcement of accessibility policies.
+- **Run-specific configuration**: Use [Profiles](/accessibility/configuration/profiles) to apply different configuration settings based on run tags, enabling team-specific reporting and optimized settings for pull requests versus regression runs.
 
 Learn more about [how it works](/accessibility/core-concepts/how-it-works).
 

docs/accessibility/get-started/setup.mdx

@@ -46,6 +46,9 @@ Cypress Accessibility provides flexible configuration options to customize your
 - [Element filters](/accessibility/configuration/elementfilters): specify selectors for elements that should be excluded from Accessibility scans
 - [View filters](/accessibility/configuration/viewfilters): specify URL patterns for URLs that should be excluded from Accessibility scans. Excluding a URL also excludes all links to that URL.
 - [Views](/accessibility/configuration/views): specify URL patterns that represent views
+- [significantAttributes](/accessibility/configuration/significantattributes): specify which attributes should be considered significant when identifying elements in Cypress Accessibility.
+- [attributeFilters](/accessibility/configuration/attributefilters): exclude specific attributes or patterns that should not be used for element tracking.
+- [Profiles](/accessibility/configuration/profiles): use different configuration settings for different runs based on run tags
 
 To add or modify the configuration for your project, navigate to the **App Quality** tab in your project settings.