unencessary event listeners reqistered on custom elements?

[Steve Faulkner]

 I have found that on non interactive polymer based custom elements, when using Firefox, a click handler is exposed via accessibility APIs. This causes assistive technology such as a screen reader to announce the custom element as clickable (when it isn't).

Would appreciate some help tracking down the cause, as it is annoying to users.

custom element example where the issue occurs: https://github.com/ThePacielloGroup/w3c-heading demo page http://thepaciellogroup.github.io/w3c-heading/

[Daniel Freedman]

Hi Steve,

Alice and Addy alerted me to this the other day, and I'm going to carve out some time to work on this, probably tomorrow.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/d32ad8ac-6a0d-41aa-baeb-492d04e7ed87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Faulkner]

On Thursday, 8 May 2014 23:25:18 UTC+1, Daniel Freedman wrote:

Hi Steve,

Alice and Addy alerted me to this the other day, and I'm going to carve out some time to work on this, probably tomorrow.

great! thank you.

[Daniel Freedman]

It looks like any element with a mousedown handler is treated as a clickable element in firefox: http://jsbin.com/vegan/1/quiet

The example only has a div and mousedown handler, no bits of Polymer anywhere.

The Polymer gesture library adds mouse listeners so it doesn't have to wrap addEventListener and keep track of interested elements. However, it does not add a click event listener, and it seems odd to me that only Firefox adds the click default action for this strategy. Chrome and IE both give an accDefaultAction of none.

Alice, Addy, this seems like a FF bug to me. Can one of you reach out to their a11y team to figure out why they made this heuristic?

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/dea3c1f3-3f2a-41c8-b215-fcbc92b7bc59%40googlegroups.com.

[Daniel Freedman]

Correct link: http://jsbin.com/vegam/1/quiet.

[Steve Faulkner]

I have emailed [1] Marco, Dave and Alex from the Moz acc team to see if they can help. Marco is already aware of the issue.

[1] http://lists.w3.org/Archives/Public/www-archive/2014May/0003.html

[Daniel Freedman]

I made a reply to that thread.

In essence, an interaction between the ShadowDOM Polyfill is and Polymer's gesture system is causing the mouse handlers to be set. The gesture system is a bit naive in that it spams all ShadowRoots with mouse handlers to recognize gestures, and the ShadowDOM Polyfill has to put those handlers on the host element and do some event path fixups.

The solution is to keep track of what elements are interested in gesture events, and only set up listeners on those elements. I'll have to do a bit of work to implement this, and add some hooks into Polymer elements, but hopefully that will result in at least limiting the "clickable" action to elements that are interactive.

Perhaps that is not even far from wrong in that case.

Thoughts?

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ec982dea-c566-42ae-971a-a19a3f4ea174%40googlegroups.com.

[Steve Faulkner]

I made a reply to that thread.

thanks, it would be great to be able at least flag non interactive elements in some way so that event listeners are not assigned, if other methods to achieve the desired outcome are not practical/possible.

--

Regards

SteveF

HTML 5.1