Re: Use cases for event listener investigation

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.

Received on Friday, 29 August 2014 07:45:27 UTC