Cypress Accessibility Testing Plugins: Open-Source Options

Short answer: Start with cypress-axe if you want to run axe-core checks at page or component states that your Cypress tests control. Consider wick-a11y for additional in-runner presentation and voice feedback, cypress-a11y-report for reporting, or cypress-accessibility-checker if you want IBM Equal Access Checker. Confirm the package’s current Cypress compatibility before installing. Automated scans find useful classes of issues, but they cannot establish that an interface is fully accessible.

This guide compares the open-source options and walks through a runnable cypress-axe setup. It also covers how to choose scan points, keep CI runtime manageable, troubleshoot common setup failures, and supplement automated rules with behavior-focused tests.

1. Open-source Cypress accessibility plugins at a glance

Plugin	Engine or role	Consider it when	Compatibility snapshot
`cypress-axe`	Integrates Deque’s axe-core and adds commands such as `checkA11y()`.	You want to author checks at chosen page and component states, with control over scope and rules.	Directory metadata reviewed October 3, 2026: version 1.7.0, updated August 2025, listed for Cypress ^10 through ^15.
`wick-a11y`	Extension built on cypress-axe, with additional finding presentation.	You want in-runner highlighting, reporting, and voice feedback described by its creator.	The reviewed directory excerpt did not establish a current version or compatibility range. Verify before adoption.
`cypress-a11y-report`	Axe-core reporting plugin built on cypress-axe.	You want a report-oriented extension and its release supports your Cypress version.	Directory metadata reviewed October 3, 2026: version 1.0.4, updated October 2024, listed for Cypress ^10 through ^13.
`cypress-accessibility-checker`	IBM Equal Access accessibility checker integration.	You want to evaluate a different checking engine and its findings against your needs.	Directory metadata reviewed October 3, 2026: version 4.0.34, updated September 2026, listed for Cypress ^13.2.0, ^15, and ^16.

These are community plugins. Cypress says community-owned plugins are not reviewed by Cypress, so check the current repository, package registry, license, release history, issues, package contents, and compatibility before depending on one. The versions and update dates above are a dated directory snapshot, not a guarantee of present support.

For most teams already using Cypress, cypress-axe is the straightforward starting point because Cypress documents it directly and it lets test authors decide which application states to scan. The other tools address output preferences or a different engine; they are not universal replacements.

2. Install and configure cypress-axe

Install the package as a development dependency:

npm install --save-dev cypress-axe

Register its commands in Cypress’s support file. In a current Cypress project this is commonly cypress/support/e2e.js (or e2e.ts); for component tests, use the component support file configured by your project.

// cypress/support/e2e.js
import 'cypress-axe';

Now visit a page, inject axe into the document, and invoke the accessibility check. This example checks the page after it has rendered:

// cypress/e2e/accessibility.cy.js
describe('home page accessibility', () => {
  it('has no detected axe violations in its initial state', () => {
    cy.visit('/');
    cy.injectAxe();
    cy.checkA11y();
  });
});

cy.injectAxe() makes axe available in the page under test; cy.checkA11y() scans the current state. A failing scan reports violations through the Cypress test, making them visible in local runs and CI. Run this against a real application route served by your test setup.

Scope a scan to a meaningful page region

Large documents may take longer to scan. If a test is specifically about a region, pass a selector as the first argument to inspect that region:

cy.checkA11y('main');

Scope scans only when that matches the assertion you intend to make. A region-only scan will not report issues outside that region, so retain broader checks where the whole page is in scope.

Choose rules and standards deliberately

checkA11y supports options for context, rule configuration, and result handling. A focused example disabling a specific rule looks like this:

cy.checkA11y(null, {
  rules: {
    'color-contrast': { enabled: false },
  },
});

Use rule exclusions sparingly and document why they exist. Disabling a rule means the scan no longer reports that class of issue for the configured run; it does not fix the underlying experience. Cypress documents configuring checks for selected WCAG success criteria and related rules. Follow the installed package’s documentation for the precise options supported by its version, and keep rule configuration consistent across CI and local development.

3. Scan the states people actually use

An accessibility scan evaluates one DOM state at a time. A clean initial page says nothing about a menu after opening, a dialog after submitting, or validation feedback after an invalid form submission. Put checks after the action that creates each important state.

describe('navigation accessibility', () => {
  it('checks the expanded menu state', () => {
    cy.visit('/');
    cy.injectAxe();
    cy.get('[aria-label="Open menu"]').click();
    cy.checkA11y();
  });
});

Use selectors that reflect the application’s stable, testable contract. The example selector is illustrative; use the actual accessible name or selector in your application. A practical test plan usually includes:

The initial page state after the relevant content has loaded.
Expanded navigation, dialogs, dropdowns, and other overlays.
Form error and success states, including the feedback shown after submission.
Important conditional or multi-step content.
Component states in component tests when that gives faster and more focused feedback.

Do not run the same whole-page scan repeatedly without a reason. At the same time, avoid saving runtime by omitting important states that change what users can see or do.

4. What automated checks can and cannot tell you

Rule-based scans can catch implementation problems such as poor color contrast, missing labels, and missing image alternative text. Their value is concrete: they can flag known patterns consistently at the states your tests visit.

“While automated scans do a good job at detecting violations of a known list of rules, no automated scan can prove that the interface is fully accessible and works well for users with disabilities.”

That is Cypress’s guidance. A passing scan is evidence that the selected rules did not report findings in the selected state. It is not a WCAG certification or a guarantee that assistive technology users can complete the workflow.

Complement scans with explicit Cypress assertions and human evaluation. Cypress documents testing keyboard navigation with native key events, checking image alt text and accessible names, and using accessible locators. Locators alone do not prove accessibility: assert expected implementation and behavior as well. Include keyboard-only use and screen-reader-relevant evaluation in your broader review process.

5. Choosing between plugins

Decision	Questions to ask
Engine and rules	Do you want axe-core, or do you want to evaluate IBM Equal Access Checker? Which standards and rules can the installed version configure?
Workflow	Can the team place checks after the relevant user actions and cover important page or component states?
Finding presentation	Are test failures and raw findings enough, or does the team need runner highlighting, reports, screenshots, or voice feedback?
Maintenance	Does the published package support your Cypress release? Is its repository active enough for your support expectations? What license applies?
CI impact	How much time do scans add, and are duplicate scans or unnecessarily broad scopes increasing it?
Manual complement	Who evaluates keyboard interaction, screen-reader experience, and product-specific expectations that rules cannot judge?

Use Cypress’s accessibility testing guide for the documented cypress-axe workflow and manual-testing context. Check the Cypress plugin directory for its current community-plugin listings, then confirm details with the package’s own published documentation and repository.

6. Performance, reliability, and cost

Scans take time because the engine evaluates DOM elements against applicable rules. Repeating scans across hundreds or thousands of application states can materially increase pipeline runtime. Cypress recommends choosing meaningful states, limiting scope where suitable, and considering component tests where appropriate.

Performance: Prefer a scan after each meaningful state transition over redundant scans of an unchanged DOM. Scope to a region only when the region is the intended test subject.
Reliability: Ensure the page and relevant asynchronous content have loaded before scanning. If the test scans too early, it may miss content or encounter a transient state. Use the application’s normal readiness signals rather than arbitrary sleeps where possible.
Maintenance: Pin and update dependencies through your normal package workflow. Recheck compatibility and review changed findings when upgrading Cypress, the plugin, or its underlying engine.
Cost: These are open-source integrations, but engineering time, CI minutes, maintenance, and follow-up remediation still have costs. Cypress also offers a paid Cypress Accessibility solution in Cypress Cloud; it is a separate managed option, not an open-source plugin.

7. Troubleshooting common problems

Symptom	Likely cause	Fix
`checkA11y` or `injectAxe` is not a Cypress command	The package was not imported by the support file, or the test uses a different support file than expected.	Install `cypress-axe`, add `import 'cypress-axe'` to the support file configured for that test type, and confirm Cypress loads that file.
A scan runs before content appears	The page’s data or interactive state has not finished loading.	Wait for a meaningful application signal or assert that the target content is present before injecting or scanning.
A scan passes but a menu or modal still has issues	The test scanned only the initial state.	Trigger the interaction, then run another scan against the expanded menu or open modal state.
CI takes much longer after adding scans	Many broad scans run across repeated or unchanged states.	Remove redundant scans, scope checks to relevant regions when justified, and consider component tests for isolated states. Keep coverage of important transitions.
A rule produces findings the team does not understand	The scan reports rule violations that need interpretation in the rendered context.	Inspect the affected element and rule explanation, determine the user impact, fix the markup or behavior, and only configure an exception when there is a documented reason.
Plugin installation fails or behaves differently after a Cypress upgrade	The installed release may not support the project’s Cypress version, or setup instructions may differ by release.	Check the package registry and repository compatibility, release notes, and setup guide. Select a compatible release before changing the test code.

8. Or skip the browser setup

If your goal is to capture a page for review or documentation, ScreenshotNeo is a website screenshot API and MCP server for developers. It is separate from accessibility testing: a screenshot can help you inspect or share a visual state, but it does not run accessibility rules or replace Cypress checks.

One GET request returns an image or PDF. For example, capture a page as WebP with cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Cookie banners, newsletter popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month, no card required.

9. Frequently asked questions

Does a passing cypress-axe test mean the page is accessible?

No. It means the configured automated rules did not report violations in the state scanned. Manual evaluation and application-specific tests remain necessary.

Can I use these plugins with Cypress component tests?

Cypress documents using accessibility checks in page or component states. Register the commands in the support file for the test type and confirm the chosen plugin version supports your Cypress setup.

Which plugin should a team try first?

For a direct axe-core workflow documented by Cypress, begin with cypress-axe. Choose another option when its reporting or checking engine better fits the team, after confirming maintenance and compatibility.

Should every test call checkA11y?

No. Place scans at representative states that expose distinct content or behavior. Repeated scans of an unchanged state add runtime without useful coverage.