W3C home > Mailing lists > Public > public-aria@w3.org > March 2016

Re: onclick and Firefox

From: Alexander Surkov <surkov.alexander@gmail.com>
Date: Thu, 31 Mar 2016 10:03:41 -0400
Message-ID: <CA+epNsd61_+8iSgEZ6qGUgpg1LfkL=OiS4h3v2wrrDOHXe5BYQ@mail.gmail.com>
To: Joseph Scheuhammer <clown@alum.mit.edu>
Cc: Rich Schwerdtfeger <richschwer@gmail.com>, Rich Schwerdtfeger <schwer@us.ibm.com>, ARIA Working Group <public-aria@w3.org>
On Wed, Mar 30, 2016 at 11:17 AM, Joseph Scheuhammer <clown@alum.mit.edu>
wrote:

> Hi Alex,
>
> Thanks for clarifying.  This was very helpful.
>
> On 2016-03-30 10:17 AM, Alexander Surkov wrote:
> >
> >
> > On Wed, Mar 30, 2016 at 9:31 AM, Joseph Scheuhammer
> > <clown@alum.mit.edu <mailto:clown@alum.mit.edu>> wrote:
> >
> >     On 2016-03-29 6:00 PM, Alexander Surkov wrote:
> >     > Hi, Rich. I'm not completely sure what you mean.
> >
> >     Maybe this will clear it up:  in an earlier email, you wrote:
> >
> >     > If you put an input element under a body with onclick, then I
> >     think it
> >     > won't pick up the body's action.
> >
> >     I took that to mean that clicking on the <input> would not invoke the
> >     body's onclick handler.  I tested it and it does invoke the body's
> >     onclick handler.
> >
> >
> > I was talking about accessibility layer only. If you mean DOM events,
> > then it's probably correct behavior as events should be bubbling.
>
> I took you to mean DOM events.
>
> >
> >
> >       In order to avoid that handler, you need to add a
> >     click listener to the <input> element itself that calls the event's
> >     stopPropagation() method.
> >
> >
> > I'm still confused. Do you mean the accessibility layer should add DOM
> > events listeners?
>
> No, not at all.  I'm saying that an author would need to add a DOM click
> event listener to stop the click from bubbling up to the body's handler.
>

I was sure there's a misunderstanding, but had no clue where


>
> >
> >
> >
> >     Then again, maybe that's not what you meant by your comment about
> >     input
> >     elements.  What did you mean?  :-)
> >
> >
> > I meant that an accessible object for input element shouldn't expose
> > 'click' action of a document accessible, which is picked up from
> > HTML:body click listener.
> >
> >
>
> Yes, that makes sense.  Does it generalize to all accessible objects?  I
> think it does.  That is, if there is a <p> DOM element, there would be a
> corresponding 'paragraph' accessible object, but that accessible would
> not expose a click action inherited from the <body> DOM click listener.
>
Only the accessible object that corresponds to the <body> element
> exposes the click action.
>

I afraid it's not what Firefox does, but it'd be good to try some tests for
sure. Anyway this is all about the legacy. In modern world the AT don't
need actions on text leaf accessibles, they even don't have to have text
leaf accessibles themselves. Thus I'm not sure how much we should care
about this.


>
> Generally, the presence of a click listener on an ancestor DOM element
> does not, by itself, cause creation of accessible objects for all of the
> descendant DOM elements.
>

Correct, however the ancestor element itself should get an accessible, at
least, that's what Firefox does.


>
> Back to Rich's original question:
> > ... if an author were to place an onclick handler on the body tag
> > Firefox was exposing it through actions in all the descendant elements
> > in the accessibility tree. Is that still true?
>
> To which you replied:
> > Yes but to text leaf descendants only.
>
> Final question:  do those text leaf descendants each expose the click
> action?
>

yes, they do.


>
> Thanks.
>
> --
> ;;;;joseph.
>
> 'Die Wahrheit ist Irgendwo da Drau├čen. Wieder.'
>                  - C. Carter -
>
>
Received on Thursday, 31 March 2016 14:04:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:21 UTC