A11Y and HTML validation toolsSee original GitHub issue
We need tools to:
- check that the HTML we produce is robust (tags are closed, attributes are closed and not duplicated, etc.),
- check things related to a11y that can be checked automatically (alt attributes, aria usage, etc.).
After asking on the Lit slack, we think we could rely on 3 layers:
- linting and checking in the editor (easy since it relies on the a11y lit eslint plugin),
- automated and exhaustive testing, to be used before committing for instance ? (would rely on Open WC Chai Axe, as explained earlier),
- specific and more thorough testing for complex components, to be used before committing just to make sure nothing ever breaks in there without us noticing it ? (would rely on Modern Web Test Runner - a11y snapshot command). This last one looks quite specific and heavy because it generates an accessible tree so that you can check it. That’s why we would only use it for a few components.
What’s missing / Up for debate
From what I’ve tested, all these tools mainly focus on a11y and some basic HTML checks (tags must be closed, etc.). We’re still missing some pieces for HTML checking:
- Content models: for instance, buttons are phrasing contents. They only accept phrasing content as descendants. Using a
<div>inside it should raise an error but it does not in these tools. They only check stuff directly related to a11y. We used to consider this an accessibility issue but this is debatable (they are considering removing html validation checking from WCAG + I fail to see the issues it could actually cause).
- [Need more testing, I’ll edit later… 😅 ]
- Created a year ago
- Comments:7 (7 by maintainers)
Top GitHub Comments
I think someone in the Lit & Friends Slack mentioned something once.
I think I would like to have something automated for all components/stories. Having e2e tests for some components is a different topic.