-
Notifications
You must be signed in to change notification settings - Fork 155
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
Automated checks for accessibility rules and standards #12018
Comments
@LukasHirt Could you recommend/suggest at which level we should have the automated accessibility checks? |
How would it look like if it would be implemented as part of e2e tests? Would it go through every page one-by-one? Would that mean we need to handle setup of different scenarios to cover all the screens? Generally speaking I am a bit hesitant to have this as part of e2e tests. Having to spin up the whole setup to check a11y roles, etc. feels like an overkill. Since this feels more like a "linter" (please correct me if I am wrong here) it looks more to me like a test that should be run outside of playwright. Could you give me please some better understanding what's the difference in effort between these two approaches? I guess if you say that having this as part of e2e tests would be 10x faster to develop as POC than having it at the component level, I would say go for it. If the difference wouldn't be that drastic I would personally prefer trying the component level first. But that's my 2 cents. If you still believe that playwright for this is the way to go, I'm not going to block you. |
yeah exactly. e2e means accessing web via url, navigating to the page and do the accessibility checks. that means it tests the accessibility of integrated components. As far as I can tell, with the component level, effort wise, we probably need to add a lot tests as there are large number of components and there will involve mocking and tests with state changes. This can do the element-level isolated checks. But with e2e and since we already have working setup for e2e, we just have to implement one or two test steps and write an accessibility feature then run the test using the existing e2e test run command. Also, checking the whole page or certain part of the page would be closer to how/what the end users will experience. I would say, it would be easier to get started with e2e test because of the existing setup. But with the component level, we might get lost in the large volume of available components in different packages. 😅 |
I see. I misunderstood than how this would work. I was imagining something alongside of a scan of codebase and just checking whether the roles are applied in the code. Then yes, POC with e2e tests seems more reasonable to me as well. |
This is also valid but would be good to start with rendered html. |
Automated Checks for Accessibility Rules
Accessibility issues like these (but not all) could have an automated checks:
+
accessibility standard rules violationsWhy automate?
Why not depend on automated tests ONLY?
Available Tools
Manual
Automation
POC
@axe-core/playwright
axe-core
Reports
Automated (axe-core):
Proposal
Add automated accessibility checks:
The text was updated successfully, but these errors were encountered: