component-driven / cypress-axe

Test accessibility with axe-core in Cypress
MIT License
618 stars 86 forks source link

Not detecting color-contrast violation #103

Open doemac opened 3 years ago

doemac commented 3 years ago

Expectation: << both the axe core extension and cypress (cy.checkA11y()) should report the same set of violations >>

Actual: << axe-core cypress check does not report color-contrast rule violation at all>>

Motivation: << To maintain consistency between manual browser testing and cypress automated testing >>

axe-core node version: 4.3.1 axe-core-devTools - 4.3.1 cypress-axe-core - 1.1.3

Browser and Assistive Technology versions

For Tooling issues:

blurbyte commented 3 years ago

Not sure if it's the same issue, but recently I was running a11y checks for very simple button component and when background and text colors were the same / nearly the same (around 2-3% difference in hue) violation was not reported. In other cases it worked just fine.

Again could be problem either with axe-core or cypress-axe, didn't have time to investigate it further unfortunately.

Packages versions:

guilhermenasszup commented 2 years ago

Same problem here. When I'm using chrome extension called Axe, the same violation is reported, but with cypress-axe none violation is detected.

MatteoPieroni commented 2 years ago

We're encountering this issue as well, I've added button text of the same colour as the background and cypress-axe is not reporting it, whereas axe dev-tools is.

Packages versions:

Is there anything we can do to help? I tried debugging but couldn't turn on any setting that would make this work.

rusZoopla commented 2 years ago

Following as have the same issue

lucasfreyptml commented 1 year ago

Following as same issue here

poida commented 1 year ago

Color contrast issues not being detected for us either, package versions:

Note for me thought the contrast issue wasn't being picked up by the axe chrome dev tools, so not sure if there is a problem with this or say axe-core?

nineteen88 commented 1 year ago

Also having the same issue, and doesn't look like a fix is in sight. We only noticed because we've just started using Playwright to perform our axe tests and that has flagged up that there are contrast issues. Coincidentally it seems to be using the same version of axe-core, so I'm not sure it's purely an issue with that.

rpasechnikov commented 2 months ago

Having the same issue with Chrome Axe dev tools plug in. Not picking up 2.3:1 colour contrast issue.

Hubbz commented 2 months ago

I had a similar issue while doing component testing. I'm not sure if this is the solution for everyone, but what worked for me was making sure cy.injectAxe(); runs before mount. :shrug:

This order worked.

cy.injectAxe();
mount(<MyComponent />);
cy.checkA11y('.my-component', axeConfig, axeViolationLog);

This order failed to pick up contrast violations.

mount(<MyComponent />);
cy.injectAxe();
cy.checkA11y('.my-component', axeConfig, axeViolationLog);
amichels commented 2 months ago

I'm not sure why, but I'm hoping someone else might know: seems like axe doesn't see the color contrast issue until you interact with the target element.

This does not detect color contrast issue:

it('displays discount code used', () => {
      cy.checkA11y();
      cy.get(selectors.cartSummary.appliedCode).should('include.text', subtotalDiscountCode);
 });

But this does:

it('displays discount code used', () => {
      cy.get(selectors.cartSummary.appliedCode).should('include.text', subtotalDiscountCode);
      cy.checkA11y();
 });

It appears that the element isn't available in the cypress provided win object until after cy.get is called on it.

This logs null inside cypress-axe when the first example above is ran, but logs the correct element when the second example is ran which indicates it exists at that point in the cypress-axe script

cy.window({ log: false }).then((win) => {
     console.log(win.document.querySelector('.promotions__promotion__code'));
});

I hope this helps someone who stumbles upon this issue.

leadegroot commented 2 months ago

I generally do a standard cy.get('#someid').contains('expected text') or something before the checkA11y because axe seems to need a little moment for the page to have finished drawing before the test is a reliable pass - ymmv