Re: Use cases for event listener investigation

One potential possibility: if you could reliably detect that a focusable element has a click event but no key listener on itself or a delegate, you could polyfill the keyup behavior. 

My personal opinion is that the browsers should be handling this natively though, as they do with links and buttons.



> On Aug 29, 2014, at 4:19 AM, Dominic Mazzoni <dmazzoni@google.com> wrote:
> 
> 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.
>