|
| 1 | +--- |
| 2 | +sidebar_label: Detect and manage changes |
| 3 | +title: 'Detect changes | Cypress Accessibility Documentation' |
| 4 | +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.' |
| 5 | +sidebar_position: 70 |
| 6 | +--- |
| 7 | + |
| 8 | +<ProductHeading product="accessibility" /> |
| 9 | + |
| 10 | +# Detect and manage changes |
| 11 | + |
| 12 | +Cypress Accessibility supports three main paths to observing and acting on changes in the accessibility report for your projects: |
| 13 | + |
| 14 | +- Run comparisons with [Branch Review](/accessibility/core-concepts/comparing-reports) |
| 15 | +- The [Results API](/accessibility/results-api) to fail builds or trigger alerts when results don't meet your standards |
| 16 | +- [Analytics](/cloud/features/analytics/enterprise-reporting#Cypress-Accessibility) for high-level trend-spotting and analysis |
| 17 | + |
| 18 | +In this guide we'll discuss how these work and some common situations where we might use them together. |
| 19 | + |
| 20 | +## Branch Review |
| 21 | + |
| 22 | +Branch Review helps you spot new issues quickly by comparing accessibility results from two Cypress runs. |
| 23 | + |
| 24 | +- Pinpoint when and where problems have been introduced |
| 25 | +- Understand and debug easily with fully rendered page snapshots |
| 26 | +- Share links to specific new issues with all the context needed to dive in |
| 27 | + |
| 28 | +### Branch Review use cases |
| 29 | + |
| 30 | +#### Speed up code reviews and deployments |
| 31 | + |
| 32 | +Use Branch review when reviewing a pull request made by another developer or before you create one of your own. You can compare the report from your changed branch with the equivalent report on the main branch. The comparison allows you to see any issues that your changes have improved or fixed completely, as well as net-new issues introduced, and any new instances of existing failures. |
| 33 | + |
| 34 | +Since this reduces the amount of violations to review to just what was affected by the PR code changes, you won't spend any time looking for what's relevant -- and if there is no difference, you'll know your PR does not affect the accessibility score and is safe to merge. |
| 35 | + |
| 36 | +See the main [Accessibility Branch Review docs](/accessibility/core-concepts/comparing-reports) for a video demo of this workflow. |
| 37 | + |
| 38 | +#### Compare reports during local development (without waiting for CI) |
| 39 | + |
| 40 | +You might expect that every Cypress Accessibility report requires a full standard Cypress test run in your Continuous Integration (CI) pipeline. |
| 41 | + |
| 42 | +A common accessibility workflow is to [create small Cypress Cloud recordings from your local development environment](/accessibility/guides/local-development) to preview the effects of any code changes. This allows for fast analysis of just a single test or two, or as much as you need to have confidence your changes are working -- especially if you are actively remediating accessibility issues. |
| 43 | + |
| 44 | +To get a high-quality comparison for a small set of tests, record the tests locally from your main branch, and then on the branch with changes. In Cypress Cloud, you will be able to compare these two runs knowing they cover exactly the same scope. |
| 45 | + |
| 46 | +This completely sidesteps the usual "push, build, run tests, report" cycle you might be used to, and is great when you need fast feedback. |
| 47 | + |
| 48 | +#### See what's changing between scheduled runs |
| 49 | + |
| 50 | +Many teams have some Cypress projects that run on a schedule and target a QA, staging, or production environment. These runs produce Cypress Accessibility reports but are not connected to specific pull requests with code changes. Branch Review works perfectly in these situations, even if all runs are on the same branch. |
| 51 | + |
| 52 | +Comparing reports on a regular schedule can let you see if accessibility issues have been introduced between this week and last week, for example, and then find the specific run where the changes happened. That "diff report" can can be forwarded to engineering or product teams as the basis of a ticket. |
| 53 | + |
| 54 | +### Note |
| 55 | + |
| 56 | +Comparing two runs in detail with Branch Review requires a good understanding of the runs themselves. The comparison is most useful if the runs are testing the same pages and workflows, and if each run fully passed all tests. This means that Cypress saw all the same states and variations of the application in both contexts. Your runs will likely never be 100% perfectly matching, but the closer they are, the better. |
| 57 | + |
| 58 | +## Results API |
| 59 | + |
| 60 | +Cypress Accessibility's [Results API](/accessibility/results-api) provides rich data related to the outcome of any accessibility report for a Cypress run. It supports adding a step in CI to block pull requests or trigger other side effects. To use the Results API, you'll need to [add a step in your CI process](/accessibility/results-api#Installation). This comes with a helper function which will automatically match your CI build with the related run in Cypress Cloud. |
| 61 | + |
| 62 | +Once you receive the results, you can perform any action you need to. Below are some of the common ones customers have told us about, where the results are compared with expectations. |
| 63 | + |
| 64 | +### Results API use cases |
| 65 | + |
| 66 | +#### Fail a build based on new failed accessibility rules |
| 67 | + |
| 68 | +The Results API provides a combined report with all the failing rules included. This means you can easily prepare a list of known, permitted failing rules to compare with the results from any run, and choose to fail only if a previously passing rule has started to fail. This is described in detail in the guide related to [blocking pull requests and setting policies](/accessibility/guides/block-pull-requests). |
| 69 | + |
| 70 | +This concept is simple but powerful because it provides extremely high confidence that any failed build is related to a specific recent code, content, or testing change. Especially if there are a high number of existing failures, the actual number of failed elements detected can vary from run-to-run, especially if existing broken components are reused in new ways. |
| 71 | + |
| 72 | +Rules that are fully passing do not have any of these problems, and for an extreme action like failing a pipeline, it's important to have high confidence that a problem is actually a new issues and can be traced to a specific build. With this confidence in place, the existing failed rules can be addressed one by one to get fully passing. |
| 73 | + |
| 74 | +#### Fail a build based on deviation from a desired score |
| 75 | + |
| 76 | +The Results API includes the specific failed element count and accessibility percentage score for the accessibility report. This makes it easy to set a score threshold and fail a build if the score falls below that expectation. This is especially useful when taking a monitoring approach, or wanting a broader, less specific standard than one based on specific rules. |
| 77 | + |
| 78 | +Changes in percentage score are directly related to changes in the number of elements detected failing accessibility rules throughout the run. Alerting or failing a pipeline for scores going down is a great way to know when you need to jump into Branch Review to understand the underlying causes of the change in score. |
| 79 | + |
| 80 | +#### Alert specific teams about failures they own |
| 81 | + |
| 82 | +In addition to the consolidated accessibility report, accessibility failures are listed per View in the results API. A View is always related to a specific URL pattern or component test, which means in many projects it is possible to connect accessibility issues in the Results API with the team responsible for solving issues in that part of the application. |
| 83 | + |
| 84 | +As an example, customers can use this functionality to trigger Slack webhooks that notify a particular channel of the issues in specific areas. The Results API provides direct links to the Views and to each failed rule within that View, making it easy to forward useful links to the correct places, or jump right into debugging from the CI output. |
| 85 | + |
| 86 | +## Analytics |
| 87 | + |
| 88 | +Analytics are located within the [Cypress Accessibility tab of Enterprise Reporting](/cloud/features/analytics/enterprise-reporting#Cypress-Accessibility) of Cypress Cloud. This provides an overview of accessibility trends across projects, and also supports filtering down to a single project and branch to see where scores have changed over time. |
| 89 | + |
| 90 | +### Analytics use cases |
| 91 | + |
| 92 | +#### Track progress and spot trends |
| 93 | + |
| 94 | +This level of reporting is ideal for documenting progress and spotting unexpected trends. When you see a project's score dropping over the long term, you can explore further with Branch Review to understand what changes are driving the score. You can compare reports before and after any shifts in scores to determine which accessibility issues were introduced. |
| 95 | + |
| 96 | +#### Set goals and minimum standards |
| 97 | + |
| 98 | +Seeing all projects in one place gives a good sense of each project's relative level and helps inform what values you might want to use for comparison when implementing a policy using the Results API. |
| 99 | + |
| 100 | +This also provides useful planning insights, because you can see your historical pace of improvements. If some projects are improving faster than others, you will be able to recognize this and understand how to replicate that success, or create realistic OKRs on a project basis. |
| 101 | + |
| 102 | +## Combine approaches |
| 103 | + |
| 104 | +As you can see above, there are times you may want to move between multiple systems to track down an issue. For example, if the Results API signals that a build on a feature branch has failed your accessibility standard, you might click through to the run itself, and then compare it with the main branch in Branch Review. That might be the end of the journey, but if the main branch is _also_ failing your policy, you can use high-level analytics to see when the score originally changed, and find the specific cause by comparing two runs from around that time. This helps detect where code was force merged, or when content served in the application had accessibility regression unrelated to code changes. |
| 105 | + |
| 106 | +As you use these tools, remember to hit the "Submit Feedback" button any time you see something that could be improved to help you understand what's important and what's changing. |
0 commit comments