Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color Contrast rules for WCAG2.0 And WCGA2.1 giving incorrect result. #4579

Open
praveshpr opened this issue Sep 14, 2024 · 4 comments
Open
Labels

Comments

@praveshpr
Copy link

I am using axe-core library in node js with playwright.

Details:-

Install Node.js if you haven't already.

Install Playwright: npm install playwright

Install @axe-core/playwright: npm install @axe-core/playwright

v4.10

I have below questions.
1.What default rule Axe-core uses to scan the website for accessibility ?

Issue:-
2.When I am using axe core to scan web page I noticed that It is giving issue for Color contrast.
It is showing expected color contrast should be 3, but it found 1.9.2 and apart from this I got other issues as well.
I have concern about this[I read some where in article that Default scan tag used by axe core is WCGA2.0, is that correct? if yes then is that color contrast rules are different form WCAG2.0 & WCAG2.1? if yes then what is the different?]
And same when I scan the page using tags "wcag22aa","wcag21aa",then my page does not show any accessibility issues.

Now I wanted to understand this, what happens why it gave error with default scan and why not with wcag22aa","wcag21aa" tags?
What does it mean?

3.How accurate the scan results is with axe-core? in terms of %.

4.Can we take it as 100% accessibility free it it passes certain scan rule?

@straker
Copy link
Contributor

straker commented Sep 16, 2024

Thanks for the questions.

  1. Axe-core runs all WCAG 2.0 and 2.1, A and AA rules except those with tags experimental and deprecated. WCAG 2.2 and WCAG AAA rules are not run by default.
  2. Would it be possible to see the page where the error is happening? Without that it will be hard to tell why it's giving color contrast issues.
    As for the reason it doesn't throw issues for wcag22aa, wcag21aa tags, that is because color contrast is a wcag2aa rule. The way the tags work in axe-core is you have to pass all the tags you want enabled. For example, wcag22aa does not enable wcag21aa nor wcag2aa. You'll have to pass each of those for those rules to run.
  3. Axe-core aims for a 0 false positive rate, so when axe-core reports a violation it typically means it's a real problem.
  4. Automated testing cannot guarantee that a web page is 100% accessible. Automated test can only capture ~60% of all accessibility problems. The remaining problems would have to be found by manual investigation and testing the page. Furthermore, automated tests are not always able to 100% test any given WCAG rule, so even if the axe-core result passes the rule, it doesn't mean there are no problems.

@praveshpr
Copy link
Author

praveshpr commented Sep 19, 2024 via email

@straker
Copy link
Contributor

straker commented Sep 20, 2024

The way the tags work in axe-core is you have to pass all the tags you want enabled. For example, wcag22aa does not enable wcag21aa nor wcag2aa. You'll have to pass each of those for those rules to run.

color-contrast is a wcag2a rule, and the issues above are from the link-in-text-bock rule, which is also a wcag2a rule. When you pass tags to be run in axe-core, you have to pass all tags you wanted run. Since you did not pass wcag2a as a tag it did not run those rules.

So if you wanted to run all WCAG A and AA rules, you'd need to pass the following tags (we don't have any wcag22a rules so it's not passed):

wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa

@praveshpr
Copy link
Author

praveshpr commented Sep 21, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants