W3C home > Mailing lists > Public > public-apa@w3.org > June 2016

RE: Seeking some feedback (ref: Action-2023)

From: Léonie Watson <tink@tink.uk>
Date: Sat, 4 Jun 2016 11:29:07 +0100
To: "'John Foliot'" <john.foliot@deque.com>, <public-apa@w3.org>
Message-ID: <771b01d1be4b$f03254b0$d096fe10$@tink.uk>
JF & APA,

 

This information from AISquared is extremely helpful. I know you have thanked them already JF, but I wanted to reiterate it here. Some comments and questions…

 

 

AISquared: “Will the browser be required to fire the pointerlockchange event (or a similar event) using an accessibility API?”

 

I’ve filed an issue against Pointer Lock based on this question [1].

 

AISquared: “Where should ZoomText track to when this mode is entered? Is there a way to find the locking object and maybe even an area of interest within the object?”

 

I don’t fully understand this, so could use some help phrasing the relevant question and/or filing a pertinent issue.

 

It sounds as though once a pointer lock has been established and the mouse is no longer used to control magnification focus/orientation, there needs to be some object/point within the available viewport that magnification software can track by default – thus keeping the viewport and the magnified viewport in synch with each other.

 

If my understanding is correct, a suitable question might be:

 

“What mechanisms are available to allow magnification software to identify a suitable focal point within the available viewport?”

 

AISquared: “Assuming a ZoomText user wants to play a game that uses this mode, but needs magnification at least at 2x. I think the only way to move the viewport 

around will be the keyboard (ZoomText panning alt+arrow keys). That might not be efficient during the game. Could the web object fire aria alerts or some other events to notify ZoomText about changing points of interest for ZoomText to track them into view?”

 

The game (or whatever application was using pointer lock) could be built from any available web technology (HTML, SVG, Canvas, React etc.). In other words what happens within the application environment would need to be handled by the technologies used to create its interface, not by the pointer lock API.

 

I have a feeling this may also be the answer to question #2. It would need to be something within the application environment that was identified as the focal point. It may be that this can be done through the pointer lock API though.

 

Léonie.

[1] https://github.com/w3c/pointerlock/issues/1 

 

-- 

@LeonieWatson tink.uk Carpe diem

 
Received on Saturday, 4 June 2016 10:29:44 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 4 June 2016 10:29:44 UTC