E-mail List Archives
Re: [eslint] [react] onchange issue in new browsers
From:
- Next message: Graham Armfield: "Re: [eslint] [react] onchange issue in new browsers"
- Previous message: Dona Patrick: "Re: Accessible Excel files -- two questions"
- Next message in Thread: Graham Armfield: "Re: [eslint] [react] onchange issue in new browsers"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: [eslint] [react] onchange issue in new browsers"
- View all messages in this Thread
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 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 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.
> > > > >
- Next message: Graham Armfield: "Re: [eslint] [react] onchange issue in new browsers"
- Previous message: Dona Patrick: "Re: Accessible Excel files -- two questions"
- Next message in Thread: Graham Armfield: "Re: [eslint] [react] onchange issue in new browsers"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: [eslint] [react] onchange issue in new browsers"
- View all messages in this Thread