E-mail List Archives

Thread: [eslint] [react] onchange issue in new browsers

for

Number of posts in this thread: 5 (In chronological order)

From:
Date: Fri, Mar 31 2017 5:11AM
Subject: [eslint] [react] onchange issue in new browsers
No previous message | Next message →

Hi!

I am enabling an accessibility plugin for my eslint in a react project.
The plugin is this one https://github.com/evcohen/eslint-plugin-jsx-a11y

And i have a problem with the rule: jsx-a11y/no-onchange. I had the
description of the rule from the project:

*Enforce usage of onBlur over/in parallel with onChange on select menu
elements for accessibility. onBlur should be used instead of onChange,
unless absolutely necessary and it causes no negative consequences for
keyboard only or screen reader users. onBlur is a more declarative action
by the user: for instance in a dropdown, using the arrow keys to toggle
between options will trigger the onChange event in some browsers.
Regardless, when a change of context results from an onBlur event or an
onChange event, the user should be notified of the change unless it occurs
below the currently focused element.*

I know that the explanation is very good but I feel like this is a old
browser issue. Where the select execute the onchage when you are using the
arrow key to pic your selection.

The question is:
am I wrong and i should enforce this rule?
I prefer to document the scenarios where this is wrong instead of enforce a
rule. But if this is wrong in the most cases, let's enforce the rule.

From: Birkir R. Gunnarsson
Date: Fri, Mar 31 2017 6:25AM
Subject: Re: [eslint] [react] onchange issue in new browsers
← Previous message | Next message →

Hi

In most cases this 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) .. Ihave 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.

I would say, rough estimate, that 80% of onchange events I have seen
are ok, 20% are not.
But it all depends on what you are sing it for.
I would flag every onchange detection for manual review if possib.,
but you cannot automatically pass or fail ite






On 3/31/17, Raúl Martín < = EMAIL ADDRESS REMOVED = > wrote:
> Hi!
>
> I am enabling an accessibility plugin for my eslint in a react project.
> The plugin is this one https://github.com/evcohen/eslint-plugin-jsx-a11y
>
> And i have a problem with the rule: jsx-a11y/no-onchange. I had the
> description of the rule from the project:
>
> *Enforce usage of onBlur over/in parallel with onChange on select menu
> elements for accessibility. onBlur should be used instead of onChange,
> unless absolutely necessary and it causes no negative consequences for
> keyboard only or screen reader users. onBlur is a more declarative action
> by the user: for instance in a dropdown, using the arrow keys to toggle
> between options will trigger the onChange event in some browsers.
> Regardless, when a change of context results from an onBlur event or an
> onChange event, the user should be notified of the change unless it occurs
> below the currently focused element.*
>
> I know that the explanation is very good but I feel like this is a old
> browser issue. Where the select execute the onchage when you are using the
> arrow key to pic your selection.
>
> The question is:
> am I wrong and i should enforce this rule?
> I prefer to document the scenarios where this is wrong instead of enforce a
> rule. But if this is wrong in the most cases, let's enforce the rule.
> > > > >


--
Work hard. Have fun. Make history.

From:
Date: Fri, Mar 31 2017 7:03AM
Subject: Re: [eslint] [react] onchange issue in new browsers
← Previous message | Next message →

Thanks Birkir, that was a very nice reply!!!

I am creating a several eslint rules just for myself that i run
frequently to don't bother all developers. As well i will create a
documentation with those cases.

On Fri, Mar 31, 2017 at 2:26 PM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi
>
> In most cases this 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) .. Ihave 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.
>
> I would say, rough estimate, that 80% of onchange events I have seen
> are ok, 20% are not.
> But it all depends on what you are sing it for.
> I would flag every onchange detection for manual review if possib.,
> but you cannot automatically pass or fail ite
>
>
>
>
>
>
> On 3/31/17, Raúl Martín < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi!
> >
> > I am enabling an accessibility plugin for my eslint in a react project.
> > The plugin is this one https://github.com/evcohen/eslint-plugin-jsx-a11y
> >
> > And i have a problem with the rule: jsx-a11y/no-onchange. I had the
> > description of the rule from the project:
> >
> > *Enforce usage of onBlur over/in parallel with onChange on select menu
> > elements for accessibility. onBlur should be used instead of onChange,
> > unless absolutely necessary and it causes no negative consequences for
> > keyboard only or screen reader users. onBlur is a more declarative action
> > by the user: for instance in a dropdown, using the arrow keys to toggle
> > between options will trigger the onChange event in some browsers.
> > Regardless, when a change of context results from an onBlur event or an
> > onChange event, the user should be notified of the change unless it
> occurs
> > below the currently focused element.*
> >
> > I know that the explanation is very good but I feel like this is a old
> > browser issue. Where the select execute the onchage when you are using
> the
> > arrow key to pic your selection.
> >
> > The question is:
> > am I wrong and i should enforce this rule?
> > I prefer to document the scenarios where this is wrong instead of
> enforce a
> > rule. But if this is wrong in the most cases, let's enforce the rule.
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Graham Armfield
Date: Fri, Mar 31 2017 7:53AM
Subject: Re: [eslint] [react] onchange issue in new browsers
← Previous message | Next message →

Hi Birkir,

Scenario 2 might be more common on WordPress sites that have blog
functionality.

There is a WordPress widget that shows blog categories to allow users to
navigate to areas they may be interested in. This can be implemented as a
list of links, but also alternatively as a dropdown where selecting a
category from the list takes you to the listing page for the given
category. This functionality is triggered by the onchange event, which is
(as we know) triggered by using the up and down arrow keys within the
dropdown list.

Regards
Graham Armfield
Coolfields Consulting
​

From: Mallory
Date: Sun, Apr 02 2017 9:12AM
Subject: Re: [eslint] [react] onchange issue in new browsers
← Previous message | No next message

Additional information for devs in general:
it does depend on the browser whether up/down arrows trigger the
onchange. IE is definitely one of those browsers.

Firefox waits until the user blurs off and then only IF the selected
value is different than it was. Neither IE nor Firefox show all the
options at once (unless you the dev change it by setting the size to
equal the number of options on keyboard focus, then set back to 1 on
blur).

Blink and I thought webkit can show users the little popup box first,
but only if they hit the special keys (I thought ctrl+enter). Otherwise
the select stays closed showing only 1 option at a time like FF and IE.
However when closed, acts like FF (arrows don't call onchange but
blurring with different value does). If the little popup is open,
hitting Enter on that value makes it the new selected value.

I'm curious what Edge does.

Because my previous job had dropdowns who refreshed the whole page
(product filters), and I was not allowed to add a dedicated button to
the select, I rewrote onchange to wait for blurs and enter keys and
expanded the visible options using the size attribute, mostly because
trying to use the pages with IE was impossible and frustrating.

cheers,
_mallory

On Fri, Mar 31, 2017, at 03:53 PM, Graham Armfield wrote:
> Hi Birkir,
>
> Scenario 2 might be more common on WordPress sites that have blog
> functionality.
>
> There is a WordPress widget that shows blog categories to allow users to
> navigate to areas they may be interested in. This can be implemented as a
> list of links, but also alternatively as a dropdown where selecting a
> category from the list takes you to the listing page for the given
> category. This functionality is triggered by the onchange event, which is
> (as we know) triggered by using the up and down arrow keys within the
> dropdown list.
>
> Regards
> Graham Armfield
> Coolfields Consulting
> ​
> > > >