Move a11y check to the eslint plugin

[AlexRMU]

Describe the problem

The current a11y check is far from perfect. There are many open and closed issues related to it.
If a user cares about the quality of his project, including accessibility, he probably uses eslint anyway. For others, frequent warnings only annoy them and they have to turn off the check manually.

Describe the proposed solution

The a11y check is a large number of checks of various sizes and complexity that can be disabled or configured. This is literally a regular eslint plugin.
In addition, it needs to be greatly improved: slots, actions, custom elements, etc. It is better to put all this in a separate repository.

Alternatives considered

Leave everything as it is.

Importance

would make my life easier

[AlexRMU]

related to:
#9188
#8964
#8558
sveltejs/eslint-plugin-svelte#311
sveltejs/language-tools#650

[jsudelko]

I'm completely in favor of this. Largely motivated by sveltejs/language-tools#650. The Svelte community as a whole has spent so many brain cycles trying to engineer around a solved problem. Conventions and patterns already exist for enabling/disabling linting in ESLint and we now have an AST-based plugin which should make it easier. We shouldn't be re-inventing the wheel especially if it's holding us back rather than helping us.

There are also a number of accessibility checks that simply don't make sense component-level, but page-level that should happen in SvelteKit (see sveltejs/kit#1265 for example). We should have component & framework level rules in configured in one place (i.e ESLint) and build on the already established patterns in that ecosystem.

[Rich-Harris]

My personal opinion: a11y is too important to be delegated to eslint. Many people, myself included, do not want to use eslint, and moving these checks outside the framework will mean that many applications — perhaps most — won't get them.

Exhibit A:

The direct consequence of this would be that more a11y bugs would end up in Svelte apps, and the web would be less accessible as a result. That's not something we should take lightly.

[AlexRMU]

You can export functions from the eslint package (if possible) and use them in svelte.
That is, the development will go on separately, the default checks will remain, the user can disable them and use through the eslint package.

[Rich-Harris]

You can export functions from the eslint package (if possible) and use them in svelte

This is a... bold statement. What do you anticipate this code would look like, concretely?

[AlexRMU]

The main code of the a11y checks is in https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/compiler/phases/2-analyze/a11y.js and https://github.com/sveltejs/svelte/blob/main/packages/svelte/src/compiler/warnings.js.
The checks are performed on the code created from the source using compiler.compile.

I suggest:

1. Create a public package. Not a part of the compiler, but a separate library.
   It is desirable that a strong specialized library be used, or at least researched.
   https://github.com/GoogleChrome/lighthouse
   https://github.com/dequelabs/axe-core
   https://github.com/microsoft/accessibility-insights-web
   https://testing-library.com/docs/dom-testing-library/api-accessibility/
   https://github.com/IBMa/equal-access
   https://react-spectrum.adobe.com/react-aria/accessibility.html
   https://storybook.js.org/docs/7.1/writing-tests/accessibility-testing
   https://github.com/medialize/ally.js
   https://github.com/jsx-eslint/eslint-plugin-jsx-a11y
   https://github.com/pa11y/pa11y
   https://github.com/AccessLint/accesslint.js
   https://github.com/A11yance/aria-query
   Or you can just copy and slightly change the current code.
   At the input, it receives compiled code or something else, I don't know, and returns a list of warnings with metadata.
2. Use this package in the compiler.
3. Use this package in https://github.com/sveltejs/language-tools.
4. Use this package in https://github.com/sveltejs/eslint-plugin-svelte or create a separate plugin.

• Users will be able to use the package for their own purposes separately from everything else, or they will be able to create and use their own instead.
• All the tools use the same package and settings of the same type, it can be just Record<string, boolean> or something more complicated, with filters and selectors, I don't know.
• By default, all checks are enabled in the compiler.
• It will also solve Handle warning emitted from the Svelte compiler #8558 , the user will be able to create and use the same or different settings everywhere.

[Rich-Harris]

Closing this as not planned — a11y checks will remain in Svelte. There's no plausible implementation that relies on an external package, and we don't want to make a11y an optional extra.