Remove legacy label cr-ui-accessibility

Ping! Any updates to this bug?

OK, I debugged this a bit. It turns out that because alert() is synchronous and blocks all JavaScript until it closes, the alert pops up *before* we're able to send the TYPE_VIEW_CLICKED event. We do fire that event after the alert closes, which you should be able to verify from TalkBack.

Can you find an example of where this doesn't work that doesn't involve alert?

The website where I originally observed this was plus.google.com, specifically, when toggling the "+1" buttons. It could be that they are firing some events that block Chrome from sending TYPE_VIEW_CLICKED event, but I am not positive what these may be.

I tried it out with Plus. The reason it's not working there is because Plus is intercepting the raw touch event and calling preventDefault on it, so a Click event never fires.

Chrome's input event team says there should be no need to do this for Chrome, though it is a useful trick for some browsers.

Rick, you mentioned earlier you had an idea of how we could make this work with FastClick. Could you suggest an approach and then assign it back to me?

To refresh your memory, the original patch was https://codereview.chromium.org/1655153003/ and it works fine without FastClick.

Sorry for dropping this.  Yes ideally sites wouldn't try to replace our built-in tap handling anymore - see https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away?hl=en.  In general if the page has called preventDefault on a touchEnd then we have to assume that the user interaction wasn't really a tap (eg. maybe it's a painting app and the user is just dropping bits of paint, not actually trying to activate something).

But due to the stupid 300ms click delay, this sort of code is pretty common so we need to deal with it.  I think the options are:

1) Have TalkBack wired up to respond to the unfiltered gesture event sequence somehow.  See TouchDispositionGestureFilter - there will be a GestureTap waiting in the queue there.  When OnTouchEventAck is called indicating the touch has been cancelled, the gesture will get dropped on the floor (the website has indicated it's handling the touch instead).  It may be reasonable for some UI elements to get a first crack or last-chance access to these discarded gestures.  But beware that this means there may be "double handling".  The site has explicitly said "browser don't do anything with this event, I'm handling it".

2) Have TalkBack wired up to raw touch events instead of the higher-level gestures.  Eg. again it could be sniffing the event stream just before (or just after) it goes to the renderer and looking specifically for a WebTouchEvent with:
 - touchesLength==1 (single-touch)
 - touches[0].state==StateReleased (a lift)
 - movedBeyondSlopRegion==false (a tap as opposed to a drag).
That's basically the signal that a tap-like touch has just occurred.

Does that help?  I don't know anything about how TalkBack is wired up today, so sorry if this is a little naive.  mfomitchev@/tdresser@ might have more specific ideas.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Closing as WontFix. I think Chrome's behavior is fine.