- From: James Nurthen <james.nurthen@oracle.com>
- Date: Fri, 29 Aug 2014 13:04:41 -0700
- To: public-pfwg@w3.org
- Message-ID: <5400DCD9.1070600@oracle.com>
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 Oracle <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 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Received on Friday, 29 August 2014 20:05:13 UTC