Solvedjavascript Option to disable a11y plugin?

We love the airbnb style guide, including the react stuff. But we don't want any of the a11y rules.

I saw this, which makes me think it would be relatively easy to only include a11y through some configuration:

module.exports = {
  extends: [
    'eslint-config-airbnb-base', // want this
    'eslint-config-airbnb-base/rules/strict', // want this
    './rules/react', // want this
    './rules/react-a11y', // don't want this
  ].map(require.resolve),
  rules: {}
};

The other option would be to include each item independently, but it would require the react rules to be published separately:

module.exports = {
  extends: [
    'airbnb-base',
    'airbnb-base/rules/strict',
    'airbnb-react' // doesn't actually exist
  ]
}

When we try to just access airbnb-react via the eslint-config-airbnb package, it still requires eslint-plugin-jsx-a11y due to the way modules are resolved:

module.exports = {
  extends: [
    'airbnb-base',
    'airbnb-base/rules/strict',
    'airbnb/rules/react'
  ]
}

Throws an error

ESLint couldn't find the plugin "eslint-plugin-jsx-a11y". This can happen for a couple different reasons...

Our workaround is to install eslint-plugin-jsx-a11y even though it's not used, and include each item independently like above. This works, but forces us to include the extra dependency that we don't want or need.

Any suggestions?

20 Answers

✔️Accepted Answer

For everyone who wondering how to use mentioned workaround:

const a11yOff = Object.keys(require('eslint-plugin-jsx-a11y').rules)
	.reduce((acc, rule) => { acc[`jsx-a11y/${rule}`] = 'off'; return acc }, {})

module.exports = {
	rules: {
		...a11yOff,
		// your rules
	},
}

Other Answers:

@ljharb Accessibility is not a requirement for our internal customer base and we are constrained by time to deliver our product. For most projects a11y is a good thing but sometimes it adds overhead if the rules are not necessary for your audience.

Manually disabling the rules is a bit difficult to track and maintain - and still forces us to require the dependency, even though we don't want it at all. If you believe the best option is to manually track all the rules and disable them, then I suppose this issue can be marked as resolved.

Also, thanks for calling out the legal implications; I'll be sure to pass this along and do the necessary research and make sure we aren't skipping out on what would otherwise be necessary by law.

Either way, perhaps you see value in keeping this issue open to resolution. For example building something that is not consumer-facing nor for a set of employees (i.e. projects that have nothing to do with making money or supporting employers).

As always thanks for the quick help @ljharb you are a beast.

Why don't you want any of the a11y rules?

just saw the PR in eslint-plugin-jsx-a11y, but I'm commenting here to keep the conversation in a single thread. i'm not sure this is something I'd want to put into the plugin, as it makes very little sense to provide an easy escape for users to avoid accessibility. the whole point of the plugin is to make it easier to build accessible apps. i have some sympathy for your time constraints, but accessibility isn't just something that's tacked on for use with assistive technologies; it's something that benefits all users. have you ever tabbed through a page before or turned on captions on a video? if you truly want to disable all of the rules (although this seems developer-hostile), I'd prefer you manually disabling the rules in your eslint config. Yes, you'll have an added devDependency that's not being used, but that's a much lower cost than providing an escape hatch for developers to ignore accessibility patterns in their code.

i'm happy to be convinced otherwise if you think I'm missing something! thanks for contributing and starting a discussion @justinhelmer 😄

More Issues: