Element hidden by keyboard is still considered visible/clickable.

[sleekweasel]

So clicking on it causes a keyboard event (and the screen height doesn't change to show where the keyboard has reached).

[NickAb]

To make it clear, do you know for sure from test flow that a keyboard will be visible at this moment? If so, you can use Back action to lose focus on element and hide keyboard.

The problem is similar to once we have with App Bar or Message Dialog popups we have. Basically this elements are not part of application window, but rather parts of shell, which are not nicely accessible. Will need some research.

A quick solution can be to port back OnScreenKeyboard.Disable for Winium.StoreApps (and the decision to split two version of drivers to speed up initial development comes back to haunt me).
This command simple hides on screen keyboard so that it does not infer with test runner. But it is not a good solution. It will work good for Windows 8.1 emulators, but on Windows 10 emulators key mapping was changed and it seems Microsoft dropped support for explicit hiding/showing keyboard, only toggling keyboard is available.

[sleekweasel]

I do know from the flow that the keyboard is visible, and I did click back to hide it once I worked out why my click wasn't doing what I expected; it was just surprising that the element claimed to be visible but I ended up clicking keyboard buttons instead of what they concealed. :)

(Also frustrating that I couldn't detect how much of the screen was 'real' app as opposed to on-screen keyboard, but I understand that mightn't be available.)

[NickAb]

Yes , understand, unfortunately we were not able to get reliable results using MS Automation API for element visibility, so we come up with some heuristics.I will look into it once I get time, maybe we can add some checks for keyboard or something.