Possibly relevant edge case: Pressing "Tab" on the Virtual keyboard (using Switch Access) successfully navigates as one would expect Tab to do. All alphanumeric keys, and also return and delete, and the button to close the keyboard, do not work.

I've been trying but still cannot repro on a Kevin with Chrome 70.0.3536 and OS Platform 10960.0.0.

- Step 2: chrome://manageAccessibility is a 404. I went to Settings --> Accessibility section instead. Hope it's the same thing. Also I believe "accessibility virtual keyboard" is the toggle item labelled as "Enable on-screen keyboard".

- Step 6: I guess this means using keys 1-2-3 on the physical keyboard that should emulate "switch" buttons and navigate the green highlight rings through on-screen items. However, doing so just results in digits 1-2-3 being typed into the text field. 

- Note that as at step 6, the cursor is blinking inside the text field, per step 4. I do have 1-2-3 mapped as next-previous-select (as seen in Switch Access Options screen, accessed from Accessibility settings).

Would you mind clarifying the steps a bit more? Thanks.

- Step 2 was a typo, sorry! It should have read chrome://settings/manageAccessibility, but you found the right page.

- Can you confirm what switches are set by clicking on the "Switch access options" below the toggle for Switch access, and seeing what it says under "Keyboard Mapping"? It shouldn't be typing 1-2-3 if they show up there, so if it is I need to investigate.

Just noticed that you said you checked the options page. That's very odd... Are you seeing a green or orange highlight ring appear when you enable Switch Access?

I'm seeing both green and orange rings. I notice digit keys 1-2-3 on the physical keyboard are mapped to Switch's next-previous-select and they seem to work as expected. 

However, upon steps 4 and 5 (so the text field is focused and the VK is open), those mappings no longer work and 1-2-3 on the physical keyboard literally input digits 1-2-3 into the text field where the cursor is.

Btw, one extra thing that you could help check: Is this happening with the "old UI" or "new UI" of the VK? To switch to old/new UI, just disable/enable the "Material Design virtual keyboard" entry in chrome://flags.

The behavior is identical for me whether the "Material Design virtual keyboard" flag is enabled or disabled. It's worth noting that I see no change in the accessibility virtual keyboard's appearance with that flag enabled vs. disabled, either.

As for why Switch Access doesn't read your key events wehn you're in the text field, I have no clue. The same version of Chrome on my eve works as expected... I'll try to get my hands on a kevin to see if it repros there.

With crrev.com/c/1222191, I still can't repro fully, using physical keys to emulate Switch navigation (as per configs in "Switch access options").

1/ Quite a lot of guessing and confusion just to get the focus rings onto the VK's keys. I'd appreciate some clear description of how the emulated navigation features work.

- "next" and "previous" seem to not just go next/previous among siblings at the same level, but also passing through their parent node in the a11y tree?

- "select" seems to function as both "descend down" and "ascend up" one level in the a11y tree, as well as actual focus selection on leaf nodes?

- What does "menu" do? What I see is that it freezes the navigation and requires Chrome restart to resolve. Also, I can 'never' disable Switch now as that just crashes Chrome, and the restarted Chrome still have Switch enabled.

- I kinda manage to guess the ring's colour codes but full description would be a helpful cheatsheet for quick reference.

2/ How do I go about doing step 7? Is that pressing the physical key that emulates "select" when the focus ring is on one of the VK's key? What I see:

- Doing "select": nothing happens.
- Doing "next" and "previous": navigation continues.
- Doing "menu" freezes things, as described above. 

Apparently, none of the above types the VK key's character into the text field, but there isn't visual animation feedback on the VK key as described (brief background colour change signifying the key being depressed then released). With that, I don't think the VK has been interacted with by Switch triggers at all.

1/ Thank you for the feedback. I'm still waiting to talk with designers on how to make the UI clearer, but it's good to know what is confusing heading into that.

Here's the short version:
- Green focus ring means this item is actionable, pressing select will perform the default action.
- Orange means this is a group containing multiple actionable items, pressing select will change your scope to that group.
- Red/dark orange means that this is your current scope, pressing select will move outwards into its parent scope.

Select necessarily performs different actions in different contexts, as Switch Access has to work with a single input button.

Menu is broken on builds with is_chrome_branded -- this is a known issue, I'm investigating. For the moment just avoid pressing it. (I'm attaching a screenshot of how SwitchAccess looks without is_chrome_branded so you can see the context menu.

Disabling SwitchAccess is similarly broken with is_chrome_branded (crbug.com/885212).

2/ When I wrote the above steps, I was using the old VirtualKeyboard. With the new keyboard UI, there is no visual indication you have pressed at all (but select is the button that should cause the button to press and an action to be performed).

I am fairly confident that Switch Access is sending a signal to the virtual keyboard, as select consistently works across all kinds of buttons and input on various websites I have tested on. I believe the default action on the keyboard buttons is not set.

Feel free to schedule a time to talk if you have more questions.

Thanks for explaining how navigation and colours work, and confirming known issues.

I've verified that indeed the VK keys (<div> elems with role="button") do not respond to AutomationNode.doDefault() triggered by SwitchAccess's selectCurrentNode(). Happening both on-device and in the VK's local debug page.

The VK actually has custom "motion handlers" and I think it doesn't handle default button action for some reason. Reassigning to the IME team in charge of "motion handlers".

Hi, any update on this bug? I’m very interested in getting this working.