WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Mar 31, 2017 6:25AM

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 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.