Cypress Accessibility uses server-side processing to carry out accessibility checks when a test run is recorded to Cypress Cloud. Compared to typical in-test accessibility scans, this "out-of-test" approach comes with a few key advantages – no special setup, no performance impact on test execution, and improved consistency across runs. All states and variations can be checked, every time, without a single line of test code added.
The one thing these accessibility checks won't do is fail a test – because the checks are running in parallel, in Cypress Cloud. This means all your tests can be green and fully complete their workflows, so Cypress Accessibility will see all the steps along every user journey, leading to the most thorough reporting.
But developers and testers still want automated feedback, notifications, and pipeline failures when a build does not meet their accessibility standards. This is why we created the Cypress Accessibility Results API, which allows for programmatic access to the outcome of all the accessibility rules that were checked.
Last week, we extended the API with the most requested update: individual breakdowns of the accessibility report for all the pages or components reached during a run, plus accessibility scores and some new failed elements counts. These changes will make it easier and faster to teams to manage the outcome of each accessibility report, including alerting specific teams about failures in areas they own.
Always-on, non-disruptive accessibility checks attached to every test run, with fine-grained programmatic access to the results, give you complete flexibility in setting policies and choosing how to escalate something based on what issues have been detected and where.
Read more about it in our new guide to detecting and managing changes in Cypress Accessibility.
Happy testing!