Re: [w3c/pointerlock] pointerlockchange and the accessibility tree (#1)

>From a **very quick and dirty** test it seems that magnifiers and browsers don't work very nicely - they try to implement but there are weird thing.

For example:

Yandex Browser (blink) + MacOS Magnifier - the pointerlock works, but the first time you engage it you have to find the approve button, and once you click it you can't move back to the thing that was meant to get the pointerlock. If mousekeys are enabled, they still generate normal mousemove events, but the cursor doesn't move.

Firefox + MacOS magnifier: Seems to always want an interaction just to make sure. Somehow there are ways to move the magnifier view even in pointerlock - unless you also have mouse keys enabled in which case it is unclear what is happening.

Edge + Windows magnifier: If you move the mouse when pointerlock is on, the screen goes blank and won't come back. Beyond that I don't know what's happening at all.

I suspect that the issue is implementation, and that we don't need to add a normative requirement so much as some guidance. Magnifiers should allow people to move the part of the screen that is magnified, but also to lock their pointer and generate the `movementX` (or Y) so the app actually works, but that doesn't take a normative change to this spec.

I don't know enough about implementation to know whether an event really needs to be fired on the accessibility tree - which I guess would be a normative change. Being able to listen on `document` and check `pointerLockElement` might be sufficient.

I'm still trying to think through the consequences of having the mouse follow a focus that is controlled by e.g. the keyboard. Is that a "synthetic" event or not?

I'll try to do some more careful testing over the next few days.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/pointerlock/issues/1#issuecomment-226829453