Curlylint now comes with 7 accessibility-related rules, ready to use in HTML templates. See All rules for details about the individual rules.
This is an important milestone for the linter – essentially demonstrating its usefulness once and for all, if that was still needed.
Most of the rules Curlylint currently ships with are very simple "HTML linting" rules for accessibility, based on established best practice:
aria_rolejust checks that
roleattributes are valid.
- Same for
html_has_lang, for the
- Same for
See a pattern? All of these are variations on the same theme of “HTML attributes should only contain a limited range of values based on established best practices”. This is great news for this project – it means there can be quite a lot of results achieved with minimal complexity when it comes to creating individual rules.
In the future, this could easily be taken further to cover:
- Security best practices, for example
rel="noopener", or disallowing
- HTML maintainability best practices, for example disallowing duplicate class attributes.
- And of course, more accessibility and ARIA best practices.
Obligatory mention of eslint-plugin-jsx-a11y, which has been a huge source of inspiration. Generally, modern React tooling has this figured out, with extensive static analysis available. For me, this isn’t just a nice-to-have – it’s hard to always keel all of those best practices in mind, and linting is there to automate this for you. Note this isn’t just React – Vue has its eslint-plugin-vue-a11y too!
This doesn’t have to stop at HTML. Curlylint already supports parsing template syntax, attempting to be usable as a linter for Jinja, Twig, Liquid, and the likes. We can also have rules to enforce best practices for this template syntax.
The first example of such a rule is
django_forms_rendering, which restricts how forms can be rendered in Django projects, for accessibility reasons. I’m very excited about opportunities like this to codify and share best practices in a way that scales well.