Replace on:change with on:blur

[Isaac-Tait]

Addresses the A11y warning on the tutorial module Block 6 Lesson 6:
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. (24:1)

It appears that this PR has been attempted before but declined due to the change creating some conflicts when using a mouse vs. the keyboard. However, the PR(s?) are several months old and as far as I can tell the change from on:change to on:blur no longer has any negative effects. Perhaps this is because of browser updates... I checked several browsers and did not notice any of the previously noticed ill effects (I was checking on a Mac... Can anyone verify on IE? If needed I could spin up an AWS Windows VM).

Link to discussion here, here and the previous PR here.

Tagging previous authors to offer input, if any - @gsimone & @pablote

Tests

npm test returns errors related to WebSocket... Error: WebSocket is not open: readyState 3 (CLOSED) I am pretty sure my changes are not causing that. Likely my environment (?).
3194 passed, 24 pending, 8 failing...

npm run lint checks out okay.

[rmunn]

Now that I've read through the previous PR, I think I'm 👎 on this change as it currently is. I think a better way to handle this would be for the docs to discuss the difference between on:change and on:blur, the accessibility implications of both (especially for keyboard-only users, who will be firing on:change repeatedly as they scroll through the list of options) and what you need to think about when using on:change. I.e., just make sure the on:change handler doesn't do anything major like browsing to another page or deleting a record; as long as the on:change handler will cause no problems if fired repeatedly for every option on the list, then you're fine from an a11y standpoint.

Now, that might be a bit much to squeeze into the tutorial. But a paragraph or two in the API docs would be a good idea, and then we can insert one sentence into the tutorial that says "Click here to read more" and links to that section of the API docs.

But I don't want to recommend on:blur instead of on:change as the default interaction mode for <select> dropdowns, because as #4946 (comment) says, that's bad UX for mouse users. If on:change is done right and therefore doesn't cause bad UX for keyboard-only users (who I estimate will be less than 2% of the visitors to most sites) but changing it to on:blur does cause bad UX for mouse/touchscreen users (who would be more than 98% of visitors), then that change is not a win. If it was really bad UX for the 2%, and the 98% would barely notice the change, then of course you should do it, but in the vast majority of cases on:change does not cause problems for the 2% of users, and using on:blur would be bad UX for the 98%.

I also think that #4946 (comment) is important enough that I'm just going to copy it straight over here:

There's a webaim.org mailing thread that discusses this issue: https://webaim.org/discussion/mail_thread?thread=8036

Quoting the reply:

In most cases [using onChange] is actually ok.
There are 3 scenarios where this is absolutely a problem (and defect
under WCAG 3.2.2)

1. If the onchange event automatically moves focus to somewhere else
   on the page.
   This is a problem, because when you are in a dropdown and press the
   arrow key the onchange event is triggered. Then your focus may land
   somewhere else. If you are a keyboard only user and wanted to select
   the 6th option in the dropdown it could take you a long time if you
   have to refocus the dropdown for every arrow down press.
2. If the onchange event triggers navigating to a different page or
   opening of another user agent (like auto playing a video or displaying
   a PDF file) .. I have never seen this except in theoretical scenarios ,
   but it could be coded that way.
3. If the onchange event changes content that is located, in content
   order, before the dropdown. This could be remediated in some cases
   using an ARIA live region, but it is usually just a bad idea.
   If your interaction with a control changes the content, the change
   should occur after the control, it is commonsensical.

The most important point, IMHO, is the third one. Most people would easily figure out points 1 and 2, but point 3 wouldn't occur to most non-impaired developers unless they were told about it, or unless they tried out screen-reader software for themselves. So I think it's worth mentioning that point somehow in the API docs section that discusses the a11y implications of on:change vs on:blur.

[rmunn]

Oh, and here's another reason for me to give a 👎 vote to this PR: that a11y warning is deprecated now in eslint-plugin-jsx-a11y. See #4946 (comment) for details; basically, IE versions before IE 11 used to do the wrong thing in onChange, but all modern browsers (including IE 11, even though including IE 11 stretches the definition of "modern" quite a bit) do the right thing in onChange when navigated by a keyboard, and so the a11y warning is only necessary if you're forced to take IE 10 or earlier into account. (And if you still have to deal with IE 10 or earlier, you have my sympathies.)

[jan-musi]

I don't know what to do about this, but I hope my "new Svelte learner" thoughts are helpful:

• When I encountered the warning in the tutorial, I assumed it was something I was supposed to fix in that step.
• When I fixed it manually, I felt like it reinforced the a11y note from a previous step, because I learned what Svelte a11y warnings look like and I learned how easy they are to fix.
• When the "Show me" button didn't fix it, I was confused, because I see the "Show me" button as a "Skip to a good end state" button.
• When I thought about the meaning behind the warning, I was even more confused, as I didn't know that onBlur was preferred.

Thank you for a great tutorial!

[jan-musi]

#5967 is related because it appears similarly in this later tutorial step: https://svelte.dev/tutorial/sharing-code

[antony]

@burgerreto2020 click unsubscribe in the right hand column.

[benmccann]

Thanks for taking a look at fixing the warning. The warning was recently removed (#6457), so I believe this can be left as is