Skip to main content
Cypress AccessibilityPremium Solution

Results API

The @cypress/extract-cloud-results module provides the getAccessibilityResults utility which enables you to programmatically fetch your run's Accessibility results in a CI environment. It determines the Cypress run created for the given CI workflow and will return the Accessibility results associated with that run. The results will be returned once the Cypress run has finished and the Accessibility report has been processed.

This allows you to review the results within CI and to determine if the results are acceptable or need to be addressed before code changes can merge. It provides overall accessibility scores and violation details for the runs, as well as page- or component-level feedback. This supports a wide variety of needs related to alerting about failures in specific focus areas of the application or creating fine-grained regression monitoring according to the current standards being met by each page.

info

Examples and use cases

This page focuses on how the Results API works and what kinds of information can be accessed. For examples of how this can be used, see our higher-level guides:

Supported CI Providers​

Fetching Accessibility results for a run supports fetching results for the following CI providers. Please see the docs below for information on general setup.

Please reach out to Cypress Support to request support for a different provider.

Installation​

Install the @cypress/extract-cloud-results module in your install step in CI.

npm install --force https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz
caution

Do not check this module in as a dependency. You should install it separately outside of your normal module installation. Use --force to get the latest version.

If you check this in as a dependency, your installation will fail when we update the package.

Usage​

1. Get the Results​

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:

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 uses the Results API to ensure no new violations have been introduced. You can reference this script as a real example.

scripts/verifyAccessibilityResults.js
const { getAccessibilityResults } = require('@cypress/extract-cloud-results')

/**
 * The list of rules that currently have 1+ elements that have been flagged with
 * violations within the Cypress Accessibility report that need to be addressed.
 *
 * Once the violation is fixed in the Accessibility report,
 * the fixed rule should be removed from this list.
 *
 * View the Accessibility report for the Cypress run in the Cloud
 * for more details on how to address these failures.
 */
const rulesWithExistingViolations = [
  'aria-required-children',
  'empty-heading',
  'aria-dialog-name',
  'link-in-text-block',
  'list',
]

getAccessibilityResults({
  projectId: '...', // optional if set from env
  recordKey: '...', // optional if set from env
  runTags: [process.env.RUN_TAGS], // required if recording multiple runs
}).then((results) => {
  const { runNumber, accessibilityReportUrl, summary, rules } = results
  const { total } = summary.violationCounts

  console.log(
    `Received ${summary.isPartialReport ? 'partial' : ''} results for run #${runNumber}.`
  )
  console.log(`See full report at ${accessibilityReportUrl}.`)

  // write your logic to conditionally fail based on the results
  if (total === 0) {
    console.log('No Accessibility violations detected!')
    return
  }

  const { critical, serious, moderate, minor } = summary.violationCounts

  console.log(`${total} Accessibility violations were detected:`)
  console.log(`  - ${critical} critical`)
  console.log(`  - ${serious} serious`)
  console.log(`  - ${moderate} moderate`)
  console.log(`  - ${minor} minor.`)

  const newRuleViolations = rules.filter((rule) => {
    return !rulesWithExistingViolations.includes(rule.name)
  })

  if (newRuleViolations.length > 0) {
    console.error(
      'The following rules were violated that were previously passing:'
    )
    console.error(newRuleViolations)
    throw new Error(
      `${newRuleViolations.length} rule regressions were introduced and must be fixed.`
    )
  }

  if (total < rulesWithExistingViolations.length) {
    console.warn(
      `It seems you have resolved ${rulesWithExistingViolations.length - total} rule(s). Remove them from the list of problematic rules so regressions are not introduced.`
    )
  }

  console.log('No new Accessibility violations detected!')
})

getAccessibilityResults Arguments​

getAccessibilityResults uses the following attributes to identify the Cypress run and return the Accessibility results:

getAccessibilityResults({
  // The Cypress project ID.
  // Optional if the CYPRESS_PROJECT_ID env is set
  // Can be explicitly passed to override the env var
  projectId: string

  // The project's record key.
  // Optional if the CYPRESS_RECORD_KEY env is set
  // Can be explicitly passed to override the env var
  recordKey: string

  // The run tags associated with the run.
  // Required IF you are recording multiple Cypress runs from a single CI build.
  // Pass the run tags you used when recording in each run
  // See below for more information
  runTags: string[]
})

Result Types​

The Accessibility results for the run are returned as an object containing the following data:

{
  // The run number of the identified build.
  runNumber: number

  // The run url for the identified build.
  runUrl: 'https://cloud.cypress.io/projects/:project_id/runs/:run_number'

  // The status of the identified build.
  runStatus: 'passed' | 'failed' | 'errored' | 'timedOut' | 'cancelled' | 'noTests'

   // The url that deep links into the summarized Accessibility report for the identified build.
  accessibilityReportUrl: 'https://cloud.cypress.io/[...]'

  // The axe-core library version used when generating the Accessibility report.
  // See https://github.com/dequelabs/axe-core. Example: 4.10.0
  axeVersion: string

  summary: {
    // Indicates whether a complete Accessibility report was generated.
    // For example, if a run was cancelled and the report expected to run
    // for 20 specs, but only 10 ran, this would result in a partial report.
    isPartialReport: boolean

    // The total detected violations and the breakdown by rule severity.
    violationCounts: {
      // The count of unique rules that detected a violation.
      total: number,
      // The count of unique critical rules that detected a violation.
      critical: number,
      // The count of unique serious rules that detected a violation.
      serious: number,
      // The count of unique moderate rules that detected a violation.
      moderate: number,
      // The count of unique minor rules that detected a violation.
      minor: number,
    },

    // The accessibility score for the run as a whole, to two decimal places
    score: number,

    // The count of distinct failed elements detected during the run, across all views
    failedElements: number

  }

  // The list of violated rules.
  rules: [{
    // The name of the rule. See https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md.
    name: string
    // The likely impact the rule has on a user with a disability.
    severity: 'critical' | 'serious' | 'moderate' | 'minor'
    // The status of the rule for the run.
    status: 'violation'
    // The url that deep links the report for this specific rule violation.
    accessibilityReportUrl: 'https://cloud.cypress.io/[...]'
  }]

  // This list of views with accessibility violations detected,
  // and details of failed rules on each view
  views: [
      {
        // The url that deep links the report for this view, with no rule-preselected
        accessibilityReportUrl: 'https://cloud.cypress.io/[...]'
        // The name of the view as it appears in the accessibility report
        displayName: "/app/get-started/why-cypress",
        // The accessibility score for this particular view
        score: number
        // The list of violated rules for this specific view
        rules: Rule[]
      }
    ]

}

Comparing against a baseline​

For comprehensive examples of comparing results against a baseline, including complete code examples, baseline structure, and best practices, see the Block pull requests and set policies guide.

2. Add to CI Workflow​

In your CI workflow that runs your Cypress tests,

  1. Update your install job to install the @cypress/extract-cloud-results module.
  2. Pass in the necessary arguments to getAccessibilityResults.
  3. Add a new step to the job that runs your Cypress tests to verify the Accessibility results.
info

If you record multiple runs in a single CI build, you must record these runs using the --tag parameter and then call getAccessibilityResults with the runTags argument for each run.

This is necessary to identify each unique run and return a corresponding set of results. The tags are how each run is uniquely identified. Tags can also be used to activate Profiles that apply different configuration settings to your runs.

Example

  • Let's imagine that within a single CI build you call cypress run --record multiple times because you're running one set of tests against a staging environment, followed by a production environment.
  • In this scenario, you pass a different --tag to each cypress run
    • cypress run --record --tag staging
    • cypress run --record --tag production
  • When calling getAccessibilityResults you would then pass these same tags to get the unique set of results for each run
    • getAccessibilityResults({ runTags: ['staging']})
    • getAccessibilityResults({ runTags: ['production']})

Example Job Workflow Update:​

test_cypress.yaml
name: My Workflow
on: push

env:
  CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}

jobs:
  run-cypress:
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v6
      - name: install
        run: npm install
      - name: Run
        run: npx cypress run --record
+     - name: Verify Accessibility Results
+       run: |
+          npm install --force https://cdn.cypress.io/extract-cloud-results/v1/extract-cloud-results.tgz
+          node ./scripts/verifyAccessibilityResults.js

Required CI environment variables​

The @cypress/extract-cloud-results helper detects the correct Cloud run by matching environment variables from where it runs against those present when the run was recorded, which is why it works automatically from the same CI context (as in the examples above).

Knowing which variables it looks for helps with more complex setups and with local iteration: set them to match what was present in CI to pull a specific run (recorded within the last 7 days) from your machine.

Prerequisites​

Two prerequisites apply to every provider:

  1. Record the Cypress run and run your validation script within the same CI run (the same build, workflow, or pipeline).
  2. Run the validation script after the run has been recorded, either in a separate job that depends on the recording job (using your provider's dependency option, such as needs, dependsOn, or requires), or serially after the recording step in the same job.

Environment variables by CI provider​

Each CI provider has a unique combination of components, patterns, and environment variables that must be interpreted by this module. Expand a provider below for its essential environment variables.

GitHub Actions

References: Understanding GitHub Actions | GitHub Actions default environment variables

Essential environment variables

  • GITHUB_ACTIONS - Presence identifies the environment as a GitHub Actions environment.
  • GITHUB_RUN_ID - Value uniquely identifies a GitHub Actions workflow instance. Value does not change as jobs in the workflow are re-executed.
  • GITHUB_RUN_ATTEMPT - Value identifies the workflow instance's attempt index. Value is incremented each time jobs are re-executed.
GitLab

References: GitLab CI/CD pipelines | GitLab predefined variables

Essential environment variables

  • GITLAB_CI - Presence identifies the environment as a GitLab CI environment
  • CI_PIPELINE_ID - Value uniquely identifies a GitLab pipeline workflow. This value does not change as jobs in the pipeline are retried.
  • CI_JOB_NAME - Value uniquely identifies a single job name within a pipeline. Ex. run-e2e
  • CI_JOB_ID - Value uniquely identifies an execution instance of a job. This value will change each time a job is executed/re-executed.
Jenkins

References: Jenkins documentation | Jenkins environment variables

Jenkins is heavily customizable through the usage of plugins, which limits the amount of assumptions we can make about available environment variables and overall behavior.

We have implemented Jenkins support within this module using the broadest set of available default values. For the purposes of this documentation, though, we will discuss terms related to Jenkins Pipeline support.

Essential environment variables

  • JENKINS_HOME - Presence identifies the environment as a Jenkins environment
  • BUILD_URL - Value uniquely identifies a Jenkins job execution, including name and id characteristics.
Azure

References: Azure Pipelines key concepts | Azure Pipelines predefined variables

Note: Cypress v13.13.1 is the earliest Cypress release that records the environment variables necessary for this module to identify runs in an Azure environment. Previous Cypress versions are not supported in Azure pipelines.

Essential environment variables

  • TF_BUILD and AZURE_HTTP_USER_AGENT - Combined presence identifies the environment as an Azure pipeline environment.
  • SYSTEM_PLANID - Value uniquely identifies a pipeline run. Value does not change as jobs within the pipeline are retried from failure.
  • SYSTEM_JOBID - Value uniquely identifies a job execution. Value changes each time a job is retried from failure, in conjunction with the SYSTEM_JOBATTEMPT being incremented.
  • SYSTEM_JOBATTEMPT - Value identifies the pipelines shared attempt index. Value is incremented when jobs are retried from failure.
CircleCI

References: About CircleCI | CircleCI built-in environment variables

Note: Cypress v13.13.1 is the earliest Cypress release that records the environment variables necessary for this module to identify runs in an CircleCI environment. Previous Cypress versions are not supported in CircleCI pipelines.

Essential environment variables

  • CIRCLECI - Presence identifies the environment as a CircleCI environment
  • CIRCLE_PIPELINE_ID - Value uniquely identifies a CircleCI pipeline, created on push or manually triggered through the UI. This value does not change as workflows within the pipeline are re-executed.
  • CIRCLE_WORKFLOW_ID - Value uniquely identifies an instance of a workflow's execution within a pipeline. This value will be updated upon each workflow execution; in other words, retrying a workflow from failure from the Circle UI will create a new workflow with a new CIRCLE_WORKFLOW_ID value available to the jobs executed within it.
  • CIRCLE_WORKFLOW_JOB_ID - Value uniquely identifies an execution instance of a named job within a workflow instance.
AWS CodeBuild

References: AWS CodeBuild documentation | AWS CodeBuild environment variables

Essential environment variables

  • CODEBUILD_BUILD_ID - Presence identifies the environment as an AWS CodeBuild environment. Value uniquely identifies a build.
Drone

References: Drone pipeline overview | Drone environment reference

Essential environment variables

  • DRONE - Presence identifies the environment as a Drone environment.
  • DRONE_BUILD_NUMBER - Value uniquely identifies a Drone build.
Bitbucket

References: Bitbucket Cloud documentation | Bitbucket variables and secrets

Essential environment variables

  • BITBUCKET_BUILD_NUMBER - Presence identifies the environment as a Bitbucket environment. Value uniquely identifies a build.
  • BITBUCKET_STEP_RUN_NUMBER - Value indicates a build step execution index and increments when a step is retried. Initial value of 1.
Buildkite

References: Buildkite documentation | Buildkite environment variables

Essential environment variables

  • BUILDKITE - Presence identifies the environment as a Buildkite environment.
  • BUILDKITE_BUILD_ID - Value uniquely identifies a build. This value does not change across different jobs within the same build.
  • BUILDKITE_JOB_ID - Value uniquely identifies a job execution. Each job in a build has a unique job ID.
  • BUILDKITE_RETRY_COUNT - Value indicates the retry attempt for a job. Default value of 0.

Local development example​

To iterate on your verification script and see everything working without putting code into your CI environment, simulate the CI context for a specific Cypress run locally. This can save a lot of time when getting started.

If you executed a run in GitHub Actions and it was recorded to Cypress Cloud, you would set these 4 environment variables to replicate the context of that run locally and execute your local handler script. This is a great way to iterate on your script and verify everything is working as expected, without having to integrate anything in CI. It's also useful for debugging.

CYPRESS_PROJECT_ID=AAA
CYPRESS_RECORD_KEY=BBB
GITHUB_ACTIONS=true
GITHUB_RUN_ID=111
GITHUB_RUN_ATTEMPT=1
node verifyResults.js

The Results API will then look for the Cypress Cloud run that matches this run ID. If there is more than one Cypress Cloud run found for that GitHub Actions Run, you can pass run tags to narrow down to one run's report.

Contents