Bringing accessibility rules into the core organization/repository

What is the problem you’re trying to solve?

Following up on a thread in the stylelint/contributors team.

There are several different plugins (with varying levels of maintenance) that focus on accessibility:

• https://github.com/YozhikM/stylelint-a11y
• https://github.com/ronilaukkarinen/stylelint-a11y
• https://github.com/thibaudcolas/stylelint-accessible

Overall, I agree that there’s a limited niche for Stylelint in the world of accessibility, especially as many accessibility concerns involve context (which linters and other static analysis tools can miss). I do think it’s great if we can play a small part in this larger ecosystem.

However, @alexander-akait has mentioned that the importance of accessibility could warrant bringing some of these projects into the core organization. This could help with unifying/deduplicating work, and also improve maintenance of important libraries. That being said, I know the value of these plugins is less clear-cut, and additional maintenance burden is surely nontrivial (we already do a lot)!

Specific rules

@thibaudcolas has also written up some rule ideas; for posterity’s sake (since the thread is private), I’ll copy-paste them here:

So far I’ve focused on rules that are broadly applicable to a lot of different styling methodologies, with few false positives. And in particular rules that can either be implemented “as a config” only / by wrapping existing rules. I was hoping to build all of those myself but would happily see other people take a stab too / instead.

• RTL support – generally I’d argue multilingual support is an accessibility consideration. So checking for:
  • Systematic usage of logical properties and values, never physical ones.
  • Never using float. As browser support for flow-relative logical values is very poor.
  • Only logical values for text-align.
• forced colors / Windows high contrast mode / contrast themes
  • Never using legacy IE-only media queries
  • Only using valid system color keywords (no typos, no vendor-specific keywords)
• General best practices
  • No text-align: justify. Makes it harder to read text.
  • No text-overflow: ellipsis as it hides text
  • Only relative units for font size
  • Only em units for media queries

And finally there are rules that could likely help but aren’t as generally applicable, or would risk creating a lot of false positives. I could see myself wanting to build and enforce those to help on projects with very strict accessibility goals, but they would likely be hard to apply on lots of projects:

• Correct usage of prefers-reduced-motion
• No forced-color-adjust: none
• No text-transform: uppercase. Creates problems when screen readers interpret “ADD” as an acronym
• No icon fonts – they can create issues for screen reader users if implemented poorly.
• No background images – as they don’t work in high contrast mode
• No position: absolute. Makes it very hard to create RTL layouts, and also can cause trouble when resizing text

What solution would you like to see?

I’m thinking that this is less of a “solution to see” and more of a discussion issue: what is the future of these projects, and is this something that we should adopt (similar to the postcss plugins that we now have in our namespace).

Since I have comparatively little experience in developing for and maintaining Stylelint, I think having seasoned contributors offer their perspective would be very helpful. In addition, having the plugin authors (such as @thibaudcolas, who has been active) chime in would be great!

If we think this is the wrong avenue to have this discussion, feel free to close/move elsewhere!

[mattxwang]

Ah! I never submitted the issue (just going through my GitHub notifs). Just saw that you opened #6509. Happy to take that up!

I’ll knock out a few of the other actionables over the rest of this break!

[jeddy3]

P.S. @jeddy3 did you want me to submit an issue / implement the media-feature-name-unit-allowed-list? I can certainly do that, I know I promised it earlier!

Yes, please. It’d be useful in its own right but also as a rule that the accessible plugin could use.