Li,
Please make sure the issue won't be repro on new language menu.

Any updates on this? It does repro on the new VK UI, though slightly differently: Touch-explore works, the focus goes thru entries with voice feedback, and it's lift-to-select. However, it's impossible to scroll thru the menu and access hidden entries.

Yeah right, seems touch-explore and scrolling widget has a fundamental conflict,
thought this might be a general issue for ChromeVox.

I will check how other scrolling page do ChromeVox and try to do the same thing for language menu.

Got 2 findings:

1. When ChromeVox turned on, should do double tap to trigger scroll, i.e. (tap->move) = touch to explore; (tap->tap->move) = scroll.

2. VK's touch to explore and double click to activate seems to have issues.

Common case:
1. tap->move->stay, ChromeVox speak out a11y info and nothing happens.
2. lift, nothing happens.
3. double tap, this is when real click happens.

VK:
1. tap->move->stay, read the a11y info, same as common case.
2. lift, real click happens

This might also be the reason why double tap to scroll fails, cause when the first tap lifts, the action is committed.

Also, I notice the a11y hint[1] when VK is open has "Find a key, then lift to type", thought this might be an intended behavior, maybe we should limit it to letter keys?


[1]: https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/chromevox/strings/chromevox_strings.grd?type=cs&q=TOUCH_TYPE&g=0&l=3036

I can confirm that during touch-explore (tap-then-move), lift-to-activate is the intended behaviour on the VK, although it's usually double-tap-to-activate elsewhere.

Thanks tranbaoduy@ for the information!

To fix this, we need to disable "lift-to-activate" feature on some of the keyboard elements such as language menu, if not to all.

tranbaoduy@, do you know whether this feature is per-container or per-element, if per-element, can we control the behavior from extension side?

Currently, "lift-to-activate" is for the entire VK container...

https://cs.chromium.org/chromium/src/ash/accessibility/touch_exploration_manager.cc?l=239-244&rcl=621dca55cf97abfac0e66a87a84cedfb02de7a5d

Thanks tranbaoduy!

Based on above information, I can think of 2 options:

1. Disable "lift-to-activate" for VK. Easy to change, but decreases input efficiency.

2. When ChromeVox is on, don't pop up language menu list, tap to "switch to next input method".

Also, this issue also applies to emoji, which requires scrolling too. If go with #2, we may also need to adjust it for ChromeVox(e.g. add buttons to switch to previous/next page).

pcovell@, which do you think is better, or any other ideas on this?

 Issue 904757  has been merged into this issue.