axe-core | Accessibility engine for automated Web UI testing | Accessibility Testing library

As per my understanding the result.getViolations() and result.getInapplicable() are two different things and both yield a different result.

It might happened that the violation is not present but there are some rules for which no matching elements were found on the page.

Results Object The callback function passed in as the third parameter of axe.run runs on the results object.

This object has four components – a passes array, a violations array, an incomplete array and an inapplicable array.

1) The passes array keeps track of all the passed tests, along with detailed information on each one. This leads to more efficient testing, especially when used in conjunction with manual testing, as the user can easily find out what tests have already been passed.

The documentation for axe-core states that you need to specify which rules you intend to test against using axe.run options.

Landmarks are discussed in WCAG 1.3.6., which is a "Level AAA" item. It appears that axe-core is only capable of testing against "Level A" and "Level AA." In your example, the item is not listed by the tool as a WCAG failure, but rather a best-practices recommendation. This may be why it isn't showing up in your other tools.

If you can easily implement this recommendation, then I'd say go ahead and do it. If not, I wouldn't let something like this stop my code from going into production. Landmarks are nice-to-have, but it's far more important that you meet all "Level A" requirements and as many "Level AA" requirements as you reasonably can.

It's worth noting that any automated accessibility testing tool is nothing more than a starting point for manual evaluation. These tools often generate tons of false positives (and sometimes miss important things!) because it's often not possible to algorithmically determine whether something is genuinely useful to human visitors.

I've also seen pages/apps that pass automated tools with no errors (Wave, Axe, etc.), but they are completely impossible to use with assistive technology.

My problem was that an another tsconfig file was overwriting the root's definitions, and turned off ivy and ngcc altogether.

sr5c/tsconfig.app.json:

Replacing the line

Finally figured out a solution after visiting the NPM page for axe-cypress.

My suspicion is that you are getting this error as the site you are testing has a content security policy

A Content Security Policy (CSP) allows a website owner to protect their end users by ensuring no malicious third party JS, CSS images etc. are injected into the site. Anything included in the CSP is allowed, anything not included is blocked.

Within a CSP it will block JavaScript eval function, which is required in your programme.

The site owner would have to explicitly allow eval on their site (as it is blocked by default if you have any JS rules in your CSP) by adding unsafe-eval as one of the rules on their CSP.

Taken from the page I linked on CSP:-

'unsafe-eval'

Allows the use of eval() and similar methods for creating code from strings. You must include the single quotes.

The only way you could fix this is by asking the owner of the site to add that to their CSP or by changing whichever function is injecting eval into their site.

If you want another site to test to confirm it is CSP that is blocking your script you can try mine https://klu.io as my CSP is very strict.

It appears I got the problem correct but not the cause.

This was being caused by the website overriding window.eval to throw an error (basically disabling it). The following fiddle demonstrates this behaviour in it's most basic form.