Logs & Video   @ http://go/chrome-androidlogs1/5/600013

Note : Application version: Feedly  / 31.1.0 and Enable Accessibility by Settings -> Accessibility -> ON

This just sounds like how accessibility is supposed to work. Turning on accessibility re-maps all gestures and whatnot. -> paul to double check this is a wontfix?

I don't understand the glitch you're describing. What do you mean by the "second tap takes the user"? Note that with TalkBack, double-tapping will activate whatever is already selected. So selecting and then double-tapping an element requires a total of 3 taps.

The video seems to be corrupted. The file is mostly just the byte 0x3D over and over.

Please check the new video by refreshing the following link ==>  http://go/chrome-androidlogs1/5/600013

Thanks. The new video works and I can repro. The problem is that when following a link, the link's accessibility focus rectangle persists after the navigation.

This is an app bug. 

It looks like Feedly uses separate, overlapping WebViews: 1 for the title screen, and 1 for the article. When you navigate to the article, the title screen is still there, and is still set to "focusable". WebView isn't aware of any other Views it may be composited with, and can't know that it's been completely covered up. So WebView can't do anything about this.

Aside, it also seems to be impossible to focus the search menu on Feedly's home screen. Unfortunately, it doesn't look like Feedly has given any thought to accessibility.

I've tested navigation in Chrome and other WebView apps and the focus rectangle disappears as it should.