Skip to content
Latchkey

cypress-axe "N accessibility violations were detected" in CI

cypress-axe injected axe-core and cy.checkA11y() found a non-empty violations set, so it fails the test. The default violation callback logs each rule id, impact, and the number of nodes affected.

What this error means

A Cypress test fails on cy.checkA11y() with "A accessibility violation(s) were detected" and, in the command log, a table of rule ids such as color-contrast and label with node counts.

cypress-axe
AssertionError: 3 accessibility violation(s) were detected: expected 3 to equal 0

Violations:
  color-contrast   (serious)   2 nodes
  label            (critical)  1 node

Common causes

The tested view contains real WCAG violations

axe evaluated the live DOM Cypress rendered and matched one or more rules. The count equals the number of distinct rules with failing nodes.

The check ran before dynamic content settled

Calling cy.checkA11y() before the app hydrated or a modal opened can both miss context and produce misleading results; wait for the element first.

How to fix it

Fix each reported rule

  1. Read the rule ids in the violations table (color-contrast, label, image-alt).
  2. Apply the WCAG fix for each rule.
  3. Re-run the spec so cy.checkA11y() finds zero violations.
a11y.cy.js
cy.get('main').should('be.visible');
cy.injectAxe();
cy.checkA11y();

Scope the check and log full details

Scan a specific region and log detailed violations so the exact selectors are visible, rather than disabling the whole assertion.

a11y.cy.js
cy.checkA11y('main', null, (violations) => {
  cy.task('log', violations);
});

How to prevent it

  • Wait for the view to render before calling cy.checkA11y().
  • Scope checks to meaningful regions to keep failures actionable.
  • Fix rules rather than removing the accessibility assertion.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →