Do we need a no-onchange rule?

[yamanoku]

Hello. ✋

I was recently trying out Svelte tutorial and encountered the following error.

A11y: on:blur must be used instead of on:change, unless absolutely necessary and it causes no negative consequences for keyboard only or screen reader users.

It's one where you have to use on:blur if you are using only on:change.

I just remembered that there is a no-onchange rule in eslint-plugin-vuejs-accessibility.

https://github.com/vue-a11y/eslint-plugin-vuejs-accessibility/blob/master/docs/no-onchange.md

By the way, I also looked at the eslint-plugin-jsx-a11y rules, but they are now deprecated. Please check the details below.

https://github.com/jsx-eslint/eslint-plugin-jsx-a11y/issues/398

As for React.js, it seems that using the onBlur event will cause a warning on the console.

---

Is it really a problem to just write onChange? I've been looking into it. In the WebAim discussion, the following is a "mostly" OK response. https://webaim.org/discussion/mail_thread?thread=8036#post1

In most cases this is actually ok.

I would say, rough estimate, that 80% of onchange events I have seen are ok, 20% are not.

Of the articles referenced in eslint-plugin-vuejs-accessibility, one seems to have an invalid link, and the other link is from around 2004.

---

It is important to have accessibility measures as a rule, but I think that this rule needs to be updated.

I have two suggestions for the no-onchange rule.

• Treat the rule itself as deprecated (as in jsx).
• Make this rule a warning only, rather than an error (is this possible?)

Of course, this is just my opinion from what I've seen, and I'd like to hear opinions from various people. :-)

[fpigeonjr]

From what I am reading here it is something that is deprecated and meant to target older-browsers. https://open-wc.org/docs/linting/eslint-plugin-lit-a11y/rules/no-invalid-change-handler/

Probably going to turn off in my project by

// .eslintrc
 "vuejs-accessibility/no-onchange": ["off"],

[vhoyer]

I would say that if someone get this issue to fix, it would be removing it from the recommended and add a note about it being deprecated on the documentation of the rule? probably best to include some links about the decision about it's deprecation, at least this issues link.

[vhoyer]

I see that we didn't really have much of a discussion about this, but the points presented are very compelling in my opinion, that's why I'm saying this, but if someone has anything against it, we'd like to hear from you. :smile: