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



In fulfillment  of ACTION-2023, I forwarded Leonie’s question / request for comment from a Screen Magnifier vendor along to Aaron Leventhal of AI Squared. AI Squared kindly provided the following comments/questions back, which I believe we should follow up on.


While this closes ACTION-2023 for me, I would like to propose we add this to next week’s agenda for further discussion and resolution.






From: Jost Eckhardt 
Sent: Thursday, April 14, 2016 1:48 PM
To: John Foliot <john.foliot@deque.com>
Cc: Aaron Leventhal et. al.
Subject: RE: Seeking some feedback


Hi John,


>From the ZoomText perspective we have a few questions on the Pointer Lock mode:


1.      Will the browser be required to fire the pointerlockchange event (or a similar event) using an accessibility API?

a.      Reason I’m asking is, that ZoomText would need to know that this mode is entered otherwise ZoomText will continue to track the mouse and the user will not be able to interact with the web object

b.      If ZoomText is aware of the mode, it will turn its own mouse tracking off as well as mouse echo etc. - by the way this is a topic for Window-Eyes as well and maybe other screen readers. You don’t want the invisible mouse to start talking because it hovers over objects on the screen.

2.      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?

3.      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? 






Jost Eckhardt

VP of Engineering


Received on Saturday, 16 April 2016 15:52:50 UTC