cypress-io · marktnoonan · Jul 10, 2025 · Jun 23, 2025 · Jun 30, 2025 · Jun 30, 2025
diff --git a/docs/accessibility/changelog.mdx b/docs/accessibility/changelog.mdx
@@ -9,6 +9,24 @@ sidebar_position: 200
 
 # Changelog
 
+## Week of 7/7/2025
+
+- A new custom accessibility rule, ["Interactive elements should be semantically correct"](/accessibility/core-concepts/cypress-rules#Interactive-elements-should-be-semantically-correct), is now available. This rule is based on the interactions that take place during your test execution, and helps detect accessibility issues that are not a part of typical DOM-based accessibility scans.
+
+## Week of 6/2/2025
+
+- We now support fetching Accessibility results from Drone CI with the [Results API](/accessibility/results-api).
+
+## Week of 5/26/2025
+
+- A new [element identification](/accessibility/core-concepts/element-identification) algorithm is now available for Cypress Accessibility. This produces improved element deduplication across different snapshots and runs, and incorporates testing-specific attributes like Test IDs into the element recognition and deduplication process. This replaces the default Axe-Core® element identification behavior.
+- Two new configuration options are available in Cypress Accessibility - [`significantAttributes`](/accessibility/configuration/significantattributes) and [`attributeFilters`](/accessibility/configuration/attributefilters). These allow you to fine-tune Cypress's element identification behavior to ensure stable and relevant locators are used.
+- Branch Review for Cypress Accessibility is now generally available, with an updated interface for displaying new and resolved violations, based on feedback during the Beta period. Thank you all for hitting the feedback button! [Learn more about comparing reports](/accessibility/core-concepts/compare-reports).
+
+## Week of 5/12/2025
+
+- We now support fetching Accessibility results from AWS CodeBuild with the [Results API](/accessibility/results-api).
+
 ## Week of 3/24/2025
 
 - Cypress Accessibility results are now included in the [Data Extract API](/cloud/integrations/data-extract-api) so that you can retrieve data over time.

diff --git a/docs/accessibility/core-concepts/cypress-rules.mdx b/docs/accessibility/core-concepts/cypress-rules.mdx
@@ -0,0 +1,103 @@
+---
+title: 'Cypress Rules | Cypress Accessibility Documentation'
+description: 'Review the main areas to pay attention to when first reviewing an accessibility report for a Cypress run.'
+sidebar_position: 70
+sidebar_label: Cypress rules
+sidebar_custom_props: { 'new_label': true }
+---
+
+<ProductHeading product="accessibility" />
+
+# Cypress rules
+
+## What are Cypress rules?
+
+In addition to running the default ruleset of the Axe-Core® library, Cypress develops custom rules that take advantage of the additional layer of information available in a test automation context. These rules are identified by a "Cypress Rule" badge, to distinguish them from the main Axe-Core® rule set.
+
+The first custom rule that we have implemented is called "Interactive elements should be semantically correct." At launch, it is a non-blocking **manual-review** rule that will either pass if no issues are found, or return an inconclusive state.
+
+## Why do we need custom accessibility rules?
+
+Conventional accessibility checks work by scanning the DOM of a web page to discover errors and inconsistencies that would affect the accessibility of the content. These checks use signals based on the nature of the content itself to determine what the correct accessible experience should be. Buttons, links, and form fields without labels can all be detected this way - if they are written correctly.
+
+This form of "passive" accessibility scan is limited to what can be learned from the page itself, because there is no other source of input about the purpose of the elements on the screen. The tools used are typically general-purpose scanners that can be called in many different contexts, not always in a test automation pipeline.
+
+In Cypress Accessibility, we can build rules that move beyond a passive scan and offer more insights about the accessibility of what you are testing, based on your existing test activities, which already describe how a user is supposed to move through the application, and what elements they use.
+
+This helps provide early detection of issues that might later appear in manual testing or in bug reports from users, increasing the total range of issues detectable in an automated scan without custom assertions or setup.
+
+## Interactive elements should be semantically correct
+
+- **ID**: `cy-semantic-html-warning`
+- **Tag**: `cypress-rule`
+- **Severity**: `serious`
+
+:::caution
+This rule requires that runs be recorded using Cypress version 13.14.0 or above.
+:::
+
+<DocsImage
+  src="/img/accessibility/core-concepts/cypress-rule.png"
+  width="60%"
+  alt="A custom Cypress accessibility rule called 'Interactive elements should be semantically correct' has two failed elements displayed. One element is open and message reads 'This element should use semantic HTML or ARIA to support the interactions that take place during tests. Detected interactions: mousedown, mouseup, click."
+/>
+
+This custom rule is intended to surface potential usability problems with the kinds of elements that Axe-Core® traditionally does not evaluate as interactive, such as div, span, SVG, and image elements.
+
+This works based on the interactions that take place during testing. Often an inaccessible custom component will have Cypress tests that perform interactions the way a user does, and that allows us to detect a mismatch between the underlying purpose of the element in code, and the usage of the element in the context of a test.
+
+### How to pass this rule
+
+You should look at the purpose and nature of the specific elements flagged by this rule and decide what interactive element is appropriate.
+
+For example:
+
+- If the element that gets flagged is a span that has been styled to look like a button and submits a form, the correct solution would be to instead use a standard HTML button element. This communicates the expected action and is activated with the space bar or enter key.
+
+- If the same element is styled with underlined text, and when clicked it resets the URL to navigate to a new page, the correct solution would be to instead use a link element with a `href` attribute.
+
+In each case, the solution is to choose the element that provides the best information to the user, so they can independently understand what the action does, and activate it.
+
+After you have updated to a suitable HTML solution, elements will then be able to be correctly parsed and analyzed by the standard Axe-Core® checks.
+
+:::info
+**Tip**: Follow the [first rule of ARIA use](https://www.w3.org/TR/using-aria/#firstrule) and implement interactive controls with standard semantic HTML where possible, relying on ARIA `role` attributes only when no suitable HTML element is available.
+:::
+
+### Why this matters
+
+In the Web Content Accessibility Guidelines (WCAG), interactive elements are required to meet a wide range of Success Criteria (SCs) in order to follow the POUR principles, which stands for Perceivable, Operable, Understandable, and Robust.
+
+Interactive elements that are not semantically correct often don't appear in automated scans, but do appear in manual testing, because they are usually not operable with a keyboard or correctly understandable when described by a screen reader.
+
+Custom components implemented this way have a direct impact on the independence of disabled users.
+
+### Related WCAG Success Criteria
+
+An incorrectly implemented interactive element may be failing multiple Success Criteria from WCAG, for example:
+
+- [SC 1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG21/#info-and-relationships)
+  - Elements may incorrectly appear to be non-interactive generic elements
+- [SC 2.1.1 Keyboard](https://www.w3.org/TR/WCAG21/#keyboard)
+  - Non-interactive elements require custom implementations for keyboard accessibility and focus states
+- [SC 4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG21/#name-role-value)
+  - Non-interactive elements require explicit ARIA roles to have their function and name correctly described by assistive technology such as screen readers
+
+### Status
+
+This rule is available in all Cypress Accessibility projects, though it is not enabled by default. Reach out to Cypress if you would like to have this rule enabled for you.
+
+### Possible outcomes
+
+For each run, this rule can be in one of four states. Most importantly, it will never fail, which means it will not affect your accessibility score.
+
+| Outcome                      | Description                                                                                                                           |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
+| **Pass**                     | No interactive elements with semantic issues were detected during the test run.                                                       |
+| **Inconclusive**             | Interactive elements with potential semantic issues were detected. You should review each element and determine the correct solution. |
+| **Not Applicable**           | The test run did not interact with any elements, or the version of Cypress was below 13.14.0, so interaction data was not gathered.   |
+| **Ignored by configuration** | The rule was not executed during this test run because it was intentionally turned off.                                               |
+
+### False positives
+
+Please use the "Submit Feedback" button in the product to let us know if you see something that you think is a false positive. Our goal with any new rules is to follow the general Axe-Core® philosophy that minimizes false positives, so we will make adjustments for specific situations that are not already known as we learn about them.
diff --git a/docs/accessibility/get-started/introduction.mdx b/docs/accessibility/get-started/introduction.mdx
@@ -3,7 +3,6 @@ sidebar_label: Introduction
 title: 'Accessibility Testing | Cypress Documentation'
 description: 'Cypress Accessibility provides organized, visual, and actionable accessibility reports, based completely on the tests you record to Cypress Cloud, and powered by Axe Core® by Deque Systems.'
 sidebar_position: 10
-sidebar_custom_props: { 'new_label': true }
 ---
 
 <ProductHeading product="accessibility" />

diff --git a/docs/accessibility/guides/production-monitoring.mdx b/docs/accessibility/guides/production-monitoring.mdx
@@ -1,19 +1,19 @@
 ---
-sidebar_label: Production monitoring
+sidebar_label: Production monitoring and website crawling
 title: 'Production monitoring | Cypress Accessibility Documentation'
 description: 'Monitor accessibility issues in production by running scheduled Cypress tests against live environments, capturing dynamic content changes, and generating automated reports for a comprehensive accessibility overview.'
 sidebar_position: 60
 ---
 
 <ProductHeading product="accessibility" />
 
-# Production monitoring
+# Production monitoring and website crawling
 
-Cypress is commonly used in CI and local development workflows. It can also be leveraged to monitor production or staging environments through scheduled tests. This approach is particularly useful for environments involving dynamic content, such as those managed by Content Management Systems (CMS), where content changes can impact accessibility.
+Cypress is commonly used in CI and local development workflows. It can also be used to monitor production or staging environments through scheduled tests. This approach is particularly useful for environments involving dynamic content, such as those managed by Content Management Systems (CMS), where content changes can impact accessibility.
 
 Dynamic or externally controlled content, such as A/B tests or user-generated content, often makes it challenging to write explicit assertions. For these cases, production smoke tests can serve as high-level health checks, ensuring the accessibility of dynamic UI variations without requiring full test coverage.
 
-## Using Cypress for Production Monitoring
+## Using Cypress for production monitoring
 
 Cypress Accessibility enables you to test dynamic content seamlessly. By visiting a production URL within your Cypress tests and performing minimal UI interactions, you can capture the page's accessibility state in reports. This allows teams to detect accessibility issues introduced outside the regular development lifecycle.
 
@@ -34,6 +34,9 @@ describe('Accessibility Scan', () => {
       Cypress._.each(URLs, (URL) => {
         cy.visit(URL)
         cy.contains('<YOUR_FOOTER_CONTENT>').scrollIntoView()
+        // perform some repeatable actions here that influence accessibility, for example:
+        //  - change from light mode to dark mode
+        //  - modify the viewport size to simulate mobile screens and higher zoom levels
       })
     })
   })

diff --git a/docs/accessibility/results-api.mdx b/docs/accessibility/results-api.mdx
@@ -34,6 +34,7 @@ Fetching Accessibility results for a run supports fetching results for the follo
 - [GitLab](/app/continuous-integration/gitlab-ci)
 - [Jenkins](/app/continuous-integration/overview#Jenkins)
 - [AWS CodeBuild](/app/continuous-integration/aws-codebuild)
+- Drone
 
 Please reach out to Cypress Support to request support for a different provider.
 
@@ -59,6 +60,25 @@ If you check this in as a dependency, your installation will fail when we update
 
 Write a script using the `getAccessibilityResults` utility to retrieve the results and perform one or more assertions to verify if the changes are acceptable. This script will be executed in CI.
 
+#### Basic example
+
+This snippet uses the `getAccessibilityResults()` helper to log out the results. It assumes your Project ID and Record Key variable are set. The following should work in any of the supported CI Providers out of the box:
+
+```javascript title="scripts/verifyAccessibilityResults.js"
+// Assuming these environment variables are set:
+// CYPRESS_PROJECT_ID=your-id
+// CYPRESS_RECORD_KEY=your-record-key
+
+const { getAccessibilityResults } = require('@cypress/extract-cloud-results')
+
+getAccessibilityResults().then((results) => {
+  // use `console.dir` instead of `console.log` because the data is nested
+  console.dir(results, { depth: Infinity })
+})
+```
+
+#### How to assert that only known rules are failing in the run
+
 The Cypress App [repository](https://github.com/cypress-io/cypress) uses the Results API to ensure no new violations have been introduced. You can reference [this script](https://github.com/cypress-io/cypress/blob/develop/scripts/verify-accessibility-results.js) as a real example.
 
 ```javascript title="scripts/verifyAccessibilityResults.js"
@@ -133,7 +153,7 @@ getAccessibilityResults({
 })
 ```
 
-#### `getAccessibilityResults` Arguments
+### `getAccessibilityResults` Arguments
 
 `getAccessibilityResults` uses the following attributes to identify the Cypress run and return the Accessibility results:
 
@@ -444,5 +464,33 @@ phases:
 +      - CYPRESS_INTERNAL_ENV=staging CYPRESS_PROJECT_ID=[slug] CYPRESS_RECORD_KEY=[KEY] node ./scripts/verifyAccessibilityResults.js
 ```
 
+</TabItem>
+
+<TabItem value="Drone" >
+```diff title=".drone.yaml"
+  kind: pipeline
+  name: default
+
+environment:
+CYPRESS_PROJECT_ID: example_project_slug
+CYPRESS_RECORD_KEY:
+from_secret: example_record_key_secret
+
+steps:
+
+- name: test
+  image: node:latest
+  commands:
+  - npm install
+  - npx cypress run --record
+
+* - name: validate
+* image: node:latest
+* commands:
+* - npm install --force https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz
+* - node ./scripts/verifyAccessibilityResults.js
+
+```
 </TabItem>
 </Tabs>
+```
diff --git a/docs/cloud/account-management/users.mdx b/docs/cloud/account-management/users.mdx
@@ -144,7 +144,7 @@ The permissions for each user role for Cypress Cloud:
 
 Cypress App users can "request" access to a given organization. If a developer on
 your team has access to Cypress and your project's source code - they can request
-to be given access to your organization from within the Cypres App. This means
+to be given access to your organization from within the Cypress App. This means
 instead of you having to invite team members up front, they can request access and
 you can choose to accept or deny them access.
 

diff --git a/docs/ui-coverage/changelog.mdx b/docs/ui-coverage/changelog.mdx
@@ -16,10 +16,18 @@ UI Coverage now supports defining custom commands that will count towards covera
 - [`additionalInteractionCommands`](/ui-coverage/configuration/additionalinteractioncommands)
 - [`allowedInteractionCommands`](/ui-coverage/configuration/allowedinteractioncommands)
 
+## Week of 6/2/2025
+
+- We now support fetching UI Coverage results from Drone CI with the [Results API](/ui-coverage/results-api).
+
 ## Week of 5/26/2025
 
 - Launched AI-powered Test Generation in Cypress Cloud, to help you quickly add tests for the untested elements detected in UI Coverage reports, in a way that follows your existing practices and conventions. For more details, read [our blog post](https://www.cypress.io/blog/add-your-missing-tests-faster-with-test-generation-in-ui-coverage).
 
+## Week of 5/12/2025
+
+- We now support fetching UI Coverage results from AWS CodeBuild with the [Results API](/ui-coverage/results-api).
+
 ## Week of 4/1/2024
 
 - **Shadow DOM and iFrame Support:** UI Coverage now supports Shadow DOM and iFrames for reporting on interactions. Both of these settings are off by default. Please contact your Cypress representative to opt in.

diff --git a/docs/ui-coverage/get-started/introduction.mdx b/docs/ui-coverage/get-started/introduction.mdx
@@ -3,7 +3,6 @@ title: 'Test coverage with UI Coverage | Cypress Documentation'
 description: 'Increase your test coverage with UI Coverage, a visual test coverage report based on the interactive elements that make up your application.'
 sidebar_label: Introduction
 sidebar_position: 10
-sidebar_custom_props: { 'new_label': true }
 ---
 
 <ProductHeading product="ui-coverage" />

diff --git a/docs/ui-coverage/results-api.mdx b/docs/ui-coverage/results-api.mdx
@@ -20,6 +20,8 @@ The utility supports the following CI providers. Refer to the linked guides for
 - [GitHub Actions](/app/continuous-integration/github-actions)
 - [GitLab](/app/continuous-integration/gitlab-ci)
 - [Jenkins](/app/continuous-integration/overview#Jenkins)
+- [AWS CodeBuild](/app/continuous-integration/aws-codebuild)
+- Drone
 
 For other CI providers, contact Cypress Support to request support.
 
@@ -324,5 +326,66 @@ workflows:
       - run-cypress
 ```
 
+</TabItem>
+
+<TabItem value="AWS CodeBuild" >
+
+```diff title="buildspec.yaml"
+phases:
+  install:
+    runtime-versions:
+      nodejs: latest
+    commands:
+      # Set COMMIT_INFO variables to send Git specifics to Cypress Cloud when recording
+      # https://docs.cypress.io/app/continuous-integration/overview#Git-information
+      - export COMMIT_INFO_BRANCH="$(git rev-parse HEAD | xargs git name-rev |
+        cut -d' ' -f2 | sed 's/remotes\/origin\///g')"
+      - export COMMIT_INFO_MESSAGE="$(git log -1 --pretty=%B)"
+      - export COMMIT_INFO_EMAIL="$(git log -1 --pretty=%ae)"
+      - export COMMIT_INFO_AUTHOR="$(git log -1 --pretty=%an)"
+      - export COMMIT_INFO_SHA="$(git log -1 --pretty=%H)"
+      - export COMMIT_INFO_REMOTE="$(git config --get remote.origin.url)"
+      - npm ci
+  pre_build:
+    commands:
+      - npm run cypress:verify
+      - npm run cypress:info
+  build:
+    commands:
+      - CYPRESS_INTERNAL_ENV=staging CYPRESS_PROJECT_ID=[slug] npx cypress run --record --key [KEY]
++  post_build:
++    commands:
++      - npm install --force https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz
++      - CYPRESS_INTERNAL_ENV=staging CYPRESS_PROJECT_ID=[slug] CYPRESS_RECORD_KEY=[KEY] node ./scripts/verifyUICoverageResults.js
+```
+
+</TabItem>
+
+<TabItem value="Drone" >
+```diff title=".drone.yaml"
+  kind: pipeline
+  name: default
+
+environment:
+CYPRESS_PROJECT_ID: example_project_slug
+CYPRESS_RECORD_KEY:
+from_secret: example_record_key_secret
+
+steps:
+
+- name: test
+  image: node:latest
+  commands:
+  - npm install
+  - npx cypress run --record
+
+* - name: validate
+* image: node:latest
+* commands:
+* - npm install --force https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz
+* - node ./scripts/verifyUICoverageResults.js
+
+```
 </TabItem>
 </Tabs>
+```
diff --git a/static/img/accessibility/core-concepts/cypress-rule.png b/static/img/accessibility/core-concepts/cypress-rule.png