We are delighted to announce the first internally-developed accessibility check in Cypress Accessibility, with a new rule called “Interactive elements should be semantically correct”. This rule has already surfaced hundreds of previously-hidden accessibility issues across an early-preview set of Cypress Accessibility customers – issues that were not revealed by existing automated scans.
Today, it’s rolling out for every Cypress Accessibility project in Cypress Cloud! Look out for the "Cypress rule" badge in your reports.
Elements in disguise
This video explains how it's possible to detect accessibility issues based on Cypress tests that would not appear in a standard Lighthouse report or similar page scanning approach.
Our new Cypress rule takes into account information that is not available with a static scan: how does a user actually treat the elements on the page? When Cypress Accessibility detects keyboard and mouse interactions in your tests, we now assess the accessibility of the elements that received the interactions, and the related elements in the DOM tree.
This extra layer of detail helps us identify what are essentially interactive elements in disguise – they signal one thing in the markup, but mean something completely different to users.
Here are some typical examples of problems that can be detected with this interaction-first approach:
- Headers incorrectly used to trigger navigation on click
- Images used as buttons
- Images used for tooltip activation
- Span and div elements used to create custom interactive components like accordions
- Inaccessible custom checkboxes, radio buttons, and switches
- Interactive SVGs in data visualization
These kinds of issues may be familiar to you, if you’ve ever been surprised by seemingly basic accessibility problems revealed in manual testing, while having a squeaky clean 100 score in your automated accessibility report. You might wonder how they get through automated accessibility scans, and the answer is simple: the scanner thinks they are something else. There’s not a good way to cope with that by analyzing the HTML – you have to know what an element is expected to do, not just what it is.
Closing that gap allows you to find more issues, sooner, and then implement the elements with the appropriate markup. Correcting the markup and solving these problems brings those elements back into the coverage area of a standard scan, which can then help find remaining issues.
Why it matters
Many developers are not aware of the accessibility benefits of using one element over another, and may lean on whatever is most convenient or has the right visual appearance, then add interactive behavior using JavaScript. In most cases, this means that large important pieces of functionality are only available to sighted mouse users, excluding disabled users who depend on keyboard behavior or other assistive technology.
Using correct semantic HTML (such as native links and buttons) avoids these problems. It allows the browser to provide correct information to assistive technology so that the purpose of the elements is communicated correctly, and the elements can be activated in a suitable way.
Where Cypress Accessibility comes in
The kinds of components mentioned above are often tested in Cypress end-to-end or component tests. It’s custom functionality after all - and since it doesn’t use built-in browser behavior, it needs to be tested explicitly.
Cypress Accessibility, which runs in Cypress Cloud as runs are recorded, will flag "suspicious" interactions for review, in addition to running the standard Axe-Core ruleset. Since these checks run against every step of every user journey, you’ll see detailed information about elements even if they are deep in specific workflows – in places that are important to your business and to your users, but harder to catch in a surface-level assessment.
This new information will appear as part of a standard Cypress Accessibility report in the Cloud. The “Interactive elements must be semantically correct” rule is a manual-review only check that does not trigger failures or alter accessibility scores. It’s up to you how you use the findings and what the correct implementation is.
How to try this out on your Cypress tests
If you’re not already a Cypress Accessibility customer, join our new no-strings 1-week trial. Just let us know what Cypress Cloud organization you’d like to test and when to turn on the trial. If you don’t have a Cypress Org, you can grab a free account.
Accessibility reports will be generated for all runs recorded in your Cypress org during your trial week. This process has absolutely zero impact on your test execution and requires no changes to test code or config files. It’s a fully server-side process based on standard Cypress Cloud recordings. You’ll see page level breakdowns, be able to diff reports in Branch Review, and watch Accessibility results populate in Cypress Cloud integrations like Slack and Github.
Trials are free, with no obligation and no requirements – though we would love your feedback on the new rule’s behavior in your codebase, so please hit the feedback button if you have any questions.
When the trial is completed, you’ll retain access to any reports generated in the trial period. If you’d like to extend the trial beyond a week, contact us to discuss a full trial, which is typically two weeks long and involves some walkthroughs, Q&A, and support with customization according to your specific goals.
The future of Cypress rules
We've already learned from early feedback in this area, and plan to become more specific than this catch-all interaction check. Often it’s clear what the likely correct implementation would be based on the context in the test, and where real-world feedback supports it, we will harden some of these findings into narrower rules that could be configured to produce failures.
We're also exploring other ways in which your automated tests provide useful context for expanding accessibility coverage beyond what appears in static scans. Cypress Cloud's Test Replay and UI Coverage work based on extremely fine-grained information about exactly what happens in a test, and when.
Stay tuned for more updates – and if you are a Cypress Accessibility customer who would like to be on the leading edge of new developments in this area, please reach out to us and we can include you in these conversations.