How it works
The stages of the Cypress Accessibility process are as follows:
- As your run is recorded and specs are uploaded to Cypress Cloud, accessibility checks begin, based on the incoming Test Replay data, on the Cypress Cloud servers.
- When your run completes, the final specs are processed for accessibility checks. All earlier specs have already entered processing and are likely completed by the end of the run.
- Cypress Cloud organizes all the Views (pages and components) that were rendered during the run, merging and deduplicating across tests so that page-level results and live DOM snapshots can be grouped together.
- A combined "rule-level" report is created.
- The completed results are displayed in Cypress Cloud and are flagged in integrations such Slack as GitHub/Gitlab comments, and available CI via the Results API so that you can optionally fail your pipeline if your standards are not met.
About Axe Core®
Axe Core® is an open source library for detecting accessibility violations. It is used widely in the industry and have over 1 billion total downloads on npm. The library may be familiar from other tools, such as Lighthouse, or tools used for code linting, mobile testing and more, and has also been used extensively in Cypress tests through open-source packages (discussed more our accessibility testing guide). This means that Cypress Accessibility's configuration can often be easily aligned with your existing accessibility standards across different teams and platforms.
Axe Core® checks for accessibility violations in your website's user interface, based on common accessibility standards. A violation detected by Axe usually indicates that some users with disabilities would have a problem using or perceiving a feature. An example of a violation would be an image without alternative text provided in the markup, which means the content is not perceivable to visually-impaired users. Learn more about Axe.
While this process reaches a high standard for automated testing, it cannot test every possible aspect of compliance, especially for heavily custom interfaces or aspects requiring human judgment.
This means that a 100% axe score does not mean all possible accessibility errors have been ruled out. Deque reports that Axe Core® can detect up to 57% of the issues that would appear in a manual accessibility audit.
The value of this form of testing in Cypress Accessibility is to give you fast, reliable, easy-to-understand feedback about common accessibility mistakes that are found in most projects. Providing these results automatically as part of your test run means that you can find and fix these issues with minimal friction, shifting accessibility left in your software development lifecycle.
Axe Core® updates
Axe Core® publishes new versions several times a year. Cypress will wait at least 30 days after an Axe Core® release before updating the library used in the Cloud. This gives you a known minimum amount of time to see the changelog and make any necessary adjustments to your process in advance of Cypress Cloud bumping the version. Bug fixes or new rules in Axe Core® may cause previously-passing projects to fail.
We will strive to update Axe Core® in a timely manner after that 30-day buffer, but set no specific expectation around when that will be. Each release is different, and some do not affect the way Axe Core® is executed in Cypress Cloud at all, so those releases may be skipped.
The Cypress Accessibility changelog will reflect any Axe Core® updates that are made in Cypress Cloud, starting on December 1, 2025 (30 days after the publication of this policy).
Exceptions
In rare cases - such as if an Axe Core® update contains a critical security patch - we may need to update sooner than the 30-day window. If this happens we will communicate with affected customers.
Powered by Test Replay
Because Cypress Accessibility uses data captured through Cypress Test Replay, it is subject Test Replay limitations.