Include accessibility rules

[sholladay]

Most applications ought to follow accessibility standards to be inclusive and usable for people with disabilities. To that end, there is a fantastic ESLint plugin, jsx-a11y, which provides rules that enforce best practices around accessibility.

Thoughts on using the plugin here?

[sindresorhus]

This is blocked by eslint/eslint#3458.

[fregante]

Why? Aren't eslint-plugin-react and eslint-plugin-react-hooks plugins themselves?

[sindresorhus]

@fregante Yes, but they are plugins everyone would want.

[fregante]

How would eslint/eslint#3458 solve that?
Wouldn't its resolution mean you can list eslint-plugin-jsx-a11y in eslint-config-xo-react's dependencies?

[sindresorhus]

Wouldn't its resolution mean you can list eslint-plugin-jsx-a11y in eslint-config-xo-react's dependencies?

A dependency is cheap, but requiring people to manually install stuff is not.

[sindresorhus]

I wonder if it's possible to expose xo-react/accessibility. I don't think that would require normal users to need to install the accessibility plugin.

[fregante]

A dependency is cheap, but requiring people to manually install stuff is not.

Doesn't everyone just copy-paste the whole string from the readme? It's already long:

$ npm install --save-dev eslint-config-xo eslint-config-xo-react eslint-plugin-react eslint-plugin-react-hooks

I suppose that the issue here would be for existing users who'd have install eslint-plugin-jsx-a11y when updating eslint-config-xo-react

[sindresorhus]

Every style guide using this package would have to include install instructions for eslint-plugin-jsx-a11y too.

I suppose that the issue here would be for existing users who'd have install eslint-plugin-jsx-a11y when updating eslint-config-xo-react

This too. I don't want to inconvenience people and force them to install, maintain, and possibly upgrade a plugin they don't want.

[papb]

Every style guide using this package would have to include install instructions for eslint-plugin-jsx-a11y too.

Perhaps it is possible to work around this by trying to require eslint-plugin-jsx-a11y and silently skipping its rules if it is not found, instead of crashing?

[GriffinSauce]

Yes, but they are plugins everyone would want.

This too. I don't want to inconvenience people and force them to install, maintain, and possibly upgrade a plugin they don't want.

This logic locks you into never adding another plugin right? That doesn't sound very constructive.

The idea with XO is to be opinionated, when you let optionality take precedent you're breaking that philosophy and people might as well just go back to copy-paste-tweaking ESLint configs.

Accessibility needs people to be opinionated in its favour. Skipping it is a path of lazyness that we as a community take far too often. I urge you to take a stand and say "XO supports a11y - if you want to built inaccessible things this is not the tool for you".

[sholladay]

Perhaps it is possible to work around this by trying to require eslint-plugin-jsx-a11y and silently skipping its rules if it is not found, instead of crashing?

I'd rather it be required. But if it had to be optional, a warning should still be printed to avoid silent accidental failure.

Regardless, my understanding is that configs cannot directly import plugins. So I don't think it's even possible to make it optional. Edit: Actually, you're right, a try / catch around the import would probably work.

[JamesJosephFinn]

The jsx-a11y config/plugin initially mentioned in this issue has since been replaced in the community with the now-popular jsx-eslint/eslint-plugin-jsx-a11y. It would be good to see this integrated into the XO project.

[sholladay]

I believe this issue should be much more straightforward now with the flat config system.

I also updated the link, thanks James.