Re: Use cases for event listener investigation

I acknowledge that's a valid reason. However, I'm not sure it will be enough to convince browser developers or the other working groups, especially since Shane said the idea has been proposed and rejected several times.


> On Sep 3, 2014, at 7:55 AM, Gunderson, Jon R <jongund@illinois.edu> wrote:
> 
> James,
>  
> The issue is really interoperability of web accessibility evaluation libraries being able to access event information.
>  
> If future of web accessibility evaluation tools are proprietary and localized to very specific browser/development environments then I guess the status quo will be good enough.  
>  
> Open source libraries like the OpenAjax Evaluation library are written in Javascript and the library currently has special code for each browser the library is being used on to identify events.  Special code has also been added to HTMLUnit to expose event information for the server based use of the OpenAjax Evaluation library for FAE 2.0 and FAE Auditor.
>  
> Prototype of FAE 2.0
> http://fae20.cita.illinois.edu <http://fae20.cita.illinois.edu/>
>  
> Prototype of FAE Auditor
> http://fae-audit-dev.cita.illinois.edu/audit/147d14454649dffb/rc/ <http://fae-audit-dev.cita.illinois.edu/audit/147d14454649dffb/rc/>
>  
> Even creating automated test cases for the OpenAjax Evaluation Library rules in the library is problematic since the special code for event information requires accessing browser specific APIs making test cases for event handlers untestable with just the library alone.
>  
> The issue is not whether it can be done, but can it be done in a way that support interoperability to make life easier for web accessibility evaluation and quality control tool developers.
>  
> Jon
>  
>  
> From: James Craig [mailto:jcraig@apple.com <mailto:jcraig@apple.com>] 
> Sent: Wednesday, September 03, 2014 2:14 AM
> To: Gunderson, Jon R
> Cc: James Nurthen; public-pfwg@w3.org <mailto:public-pfwg@w3.org>
> Subject: Re: Use cases for event listener investigation
>  
> Developer tools like the Safari Web Inspector (and other browsers web developer tools) provide all of this already. I'm still not seeing a real need to extend EventTarget, other than the minor convenience use Dominic mentioned below. 
>  
>  
> On Sep 2, 2014, at 8:10 AM, Gunderson, Jon R <jongund@illinois.edu <mailto:jongund@illinois.edu>> wrote:
>  
> The primary purpose of knowing events to me are:
>  
> 1.      Identifying interactive elements and do they have a ARIA role
> 2.      If an ARIA role needed certain event handlers identifying if those event handlers have been defined
> 3.      Based on the roles defined providing developers or QA people with information on the expected keyboard behaviors
> 4.      As IndieUI becomes available encouraging developers to use these events rather than device specific events
>  
> We need event handler information to provide this type of information.
>  
> Jon
>  
>  
> From: James Nurthen [mailto:james.nurthen@oracle.com <mailto:james.nurthen@oracle.com>] 
> Sent: Friday, August 29, 2014 3:05 PM
> To: public-pfwg@w3.org <mailto:public-pfwg@w3.org>
> Subject: Re: Use cases for event listener investigation
>  
> I would be very much against doing this. There are many times when there are redundant clickable elements for a mouse user where we provide just a single keyboard control for the same functionality. In this case if the browser were to add tab stops and key handlers for these this would negatively impact the user experience.
> 
> Regards,
> James
> On 8/29/2014 7:36 AM, James Craig wrote:
> 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 <mailto: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 <mailto:jcraig@apple.com>> wrote:
> Hardening questions:
> 
> > On Aug 28, 2014, at 6:59 AM, Gunderson, Jon R <jongund@illinois.edu <mailto: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.
> 
> 
> 
> 
>  
>  
> -- 
> Regards, James 
>  <http://www.oracle.com/>
> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918 <tel:+1%20415%20987%201918> 
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065 
>  <http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment
>  
> -- 
> Indifference towards people and 
> the reality in which they live
> is actually the one and only 
> cardinal sin in design.
>                 — Dieter Rams

-- 
Indifference towards people and 
the reality in which they live
is actually the one and only 
cardinal sin in design.
                — Dieter Rams