Re: Use cases for event listener investigation

I'm torn on this one.

We use this as a heuristic in our own accessibility testing library, which
uses internal APIs to get event listeners. For example, if an element has a
click listener but isn't focusable, that's a potential warning.

However, we've found event delegation is increasingly common and renders
this check useless in those cases. Furthermore, I think it'd be a mistake
to have an accessibility audit do the reverse check and say that, e.g., an
element that doesn't have a keydown listener isn't accessible since it's
quite possible a different event listener is handling it.

Given all of the limitations, I'd like to know if there are any interesting
use-cases outside of accessibility testing.

The only one I can think of is a very slight programming convenience: a JS
widget that needs to remove event listeners could just use this interface
to iterate over any event listeners it may have registered on an element,
rather than keeping track of them.

On Fri, Aug 29, 2014 at 12:44 AM, James Craig <jcraig@apple.com> wrote:

> Hardening questions:
>
> > On Aug 28, 2014, at 6:59 AM, Gunderson, Jon R <jongund@illinois.edu>
> wrote:
> >
> > The use cases I have for identifying event listeners:
> >
> > 1.      Identity elements interactive elements (i.e. div element that is
> now a checkbox because it has an onclick or mouse events)
>
> What's the intended use of the DOM interface though? UAs already know this
> and expose it to the platform APIs. Is this for in-browser validation
> capability? Are there any non-validation use cases for wanting to do this?
>
> > 2.      Verify keyboard event support for elements with ARIA roles that
> require keyboard support
>
> Event registration is already possible with UAs and platform APIs. Why
> should there be a new DOM interface that does the same thing?
>
> Also, I'm not sure you could reliably detect what you're trying to detect,
> even with the system APIs. Often event delegation is used (so the event
> listener is a different node) and you would not be able to determine if the
> keys were properly handled. Is your intention to throw a validation warning
> if mousedown/mouseup/click is not registered on the element or any
> ancestor? How could you detect if the event is registered but no longer in
> use or ignored for the keys you're trying to verify?
>
> > 3.      Some advanced accessibility techniques like focus styling of the
> labels for checkboxes and radio buttons require the use of onfocus and
> onblur events
>
> Unless I'm misunderstanding you, that can be done today without a new
> EventTarget.listeners interface.
>
>
>
>