Fire an accessible click event when a web node is clicked on.

third_party/WebKit/Source/core/events/EventDispatcher.cpp

Index: third_party/WebKit/Source/core/events/EventDispatcher.cpp
diff --git a/third_party/WebKit/Source/core/events/EventDispatcher.cpp b/third_party/WebKit/Source/core/events/EventDispatcher.cpp
index f6ad638c6b532bcaeeb316a0ee4f10f7288d01d3..94a0a2b35bccd04cde2979de53eb3c65ff7d2ad8 100644
--- a/third_party/WebKit/Source/core/events/EventDispatcher.cpp
+++ b/third_party/WebKit/Source/core/events/EventDispatcher.cpp
@@ -199,6 +199,10 @@ inline void EventDispatcher::dispatchEventPostProcess(void* preDispatchEventHand
     m_event->setCurrentTarget(nullptr);
     m_event->setEventPhase(0);
 
+    // Fire an accessibility event indicating a node was clicked on.
+    if (AXObjectCache* cache = m_node->document().existingAXObjectCache())
+        cache->handleClicked(m_node);

[Rick Byers, 2016/02/02 18:22:57]

This is being called for ALL types of events (not just click), I don't think
that's what you want (eg. a scroll shouldn't be considered a click), and it's
also potentially a performance issue (eg. for every touchmove/mousemove).

Do you want to include the case where JavaScript generates an event named
"click"?

What about other sources of internal "clicks", eg. the enter key is pressed on a
button?

What about the common case of a touchscreen tap, where the page is calling
preventDefault on the touch events (eg. using a FastClick library even though
there's no benefit on Chrome)?  Handling that case will be trickier.  In general
"preventDefault" means "don't do any native browser handling" - should that
include disabling this accessibility hook?

Based on the above, I can help you refine / relocate this hook.

[dmazzoni, 2016/02/02 18:35:48]

Oops, I had a line of code that checked for the event type matching
EventTypeNames::click, I accidentally deleted that while removing logging.
Yes, my intent was to capture that case too. I want real clicks, simulated
clicks.
Great question.

If we could fire the accessible click event when someone's using FastClick
that'd be nice.

Overall it'd be desirable if we didn't fire the event if the user clicks on
something like a static text node or the document body and there are no click
handlers. But if the page has some click handlers for tracking, or if there's no
good way to do this, that's okay.

Most important is that I do not want this to fire if you drag or scroll or
something like that.

I hope that's clear.

Also, do I probably want to fire the event on the
eventTargetRespectingTargetRules or on m_node? What will
eventTargetRespectingTargetRules be if it's not a node, how would I map it to a
node in that case?

[Rick Byers, 2016/02/02 18:55:37]

Ok.  Please share the logic with the isTrustedOrClick check below (so we're
comparing with event names only once).
Yep, makes sense.  Handling FastClick scenarios will be a little tricky but
doable.  If it's not critical, I suggest you file a separate bug for that and we
can discuss the details there for a future CL (I may be making some changes
that'll make it relatively easy). 
Looks like the only difference is in handling pseudo elements
(https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-elements).  I'm
guessing you probably want eventTargetRespectingTargetRules, but it depends on
what the consumer of this is doing with the node.  Also be sure the consumer can
handle ShadowDOM alright.

+
     // Pass the data from the preDispatchEventHandler to the postDispatchEventHandler.
     m_node->postDispatchEventHandler(m_event.get(), preDispatchEventHandlerResult);