Pointer Lock API - Part 2 - FW: Seeking some feedback

More (and extremely valuable) feedback from Ai Square related to the Pointer Lock API (Very glad I chased this)

Leonie, this larger topic, and Ai Squared's first response, was redirected to you on today's APA Call; please also include the enclosed as part of the response to the Pointer Lock API folks. Thanks!

JF

> -----Original Message-----
> From: Seth Holladay (Ai Squared)
> Subject: Re: Seeking some feedback
> 
> Hi John,
> 
> 
> I am a software engineer on the Sitecues team. I am responsible for reviewing
> this on our end and I work closely with Aaron on the design and UX of Sitecues.
> 
> 
> We do have some accessibility concerns. Our response is below.
> 
> 
> https://docs.google.com/document/d/1ZKSiTJyZg8d2_fZMMFBsJG97K02N_nO6
> rzI1sSRKYW0​
> 
> __
> 
> Context
> 
> 
> Pointer lock is important for making a user-friendly magnification technology. In
> particular, it is critical for implementing a technique called “edge push” for
> panning the magnified viewport around the available document area. This is
> similar to use case 10.6<https://w3c.github.io/pointerlock/#view-port-panning-
> by-moving-a-mouse-cursor-against-the-bounds-of-a-view-port.x> in the latest
> specification revision.
> 
> 
> Panning is the primary means for low vision users to see and read content that is
> not optimized for their magnification needs. For example, images are routinely
> larger than the magnified viewport size and text is not always line-wrapped.
> Edge push works by moving the viewport when the pointer comes near its
> boundaries, thus allowing the user to access content that is offscreen.
> 
> 
> Without pointer lock, it is not feasible to achieve edge pushing in a reliable
> manner because the pointer can easily exit the window before the panning
> implementation has detected enough events to fully move the viewport to the
> document edge. Compensating for this by increasing the speed of panning
> degrades the user experience due to hypersensitivity.
> 
> 
> With pointer lock, the implementation merely needs to decide that the pointer is
> within a reasonable distance of the viewport edge and moving towards it, then
> lock the pointer. After locking, the pushing mechanism uses the movementX and
> movementY event properties to pan the exact amount needed and unlocks the
> pointer when there is no more area to pan to or the pointer begins moving in the
> opposite direction.
> 
> 
> Being able to rely upon an exact amount to pan by allows the user experience to
> be dramatically smoother, as the implementation does not have to compensate
> for the possibility of missed events by being overly sensitive in its calibration.
> Maintaining the speed of movement the user expects is especially noteworthy
> because magnification is already disorienting in its nature.
> 
> Problems
> 
> 
> While pointer lock provides a valuable service to magnification technology, the
> details of the existing Pointer Lock API have some severe drawbacks for low
> vision users. Namely, the disappearance of the cursor causes disorientation in a
> situation where there is a crucial need to provide landmarks and points of
> reference to the user.
> 
> 
> Additionally, we are concerned with the accessibility of the permission view.
> Historically, user agents have done a poor job of implementing these in an
> accessible manner. And while the responsibility of this specification to change
> that is debatable, it is a roadblock for a magnifier to adopt this API. There are
> currently no means for an application to magnify the permission view and even
> the native zoom controls do not affect them.
> 
> Conclusion
> 
> 
> Our carefully considered opinion is that the API is not general enough in its
> applicability. The behavior is optimized for the use case of gaming. Its impact
> upon accessibility will be negligible - possibly detrimental - unless it comes with
> finer controls.
> 
> 
> Our recommendation is to reconsider the impact of FAQ section
> 12.4<https://w3c.github.io/pointerlock/#why-bundle>. If a compromise
> between utility and development cost is possible, we believe there would be a
> significant benefit to web accessibility in exploring it. Many of the features 12.4
> mentions, such as alternative measurements for pointer movement, are
> unnecessary or low priority for magnified panning.
> 
> 
> 
> Thanks for your time,
> 
> 
> 
> ~Seth
> 
> ___
> 
> Seth Holladay
> Full Stack Software Engineer
> sitecues<https://sitecues.com> by Ai Squared<http://www.aisquared.com>
> 857-259-5272
> 
> 
> ________________________________
> From: John Foliot <john.foliot@deque.com>
> Sent: Thursday, April 14, 2016 4:15 PM
> To: Jost Eckhardt
> Cc: Aaron Leventhal; Seth Holladay; Brian Lima; Fred Lichtenfels
> Subject: RE: Seeking some feedback
> 
> Hi Jost,
> 
> Thank-you for this, this is indeed extremely useful!
> 
> Off-hand, I do not have answers to the questions you pose, however we (the
> APA Working Group at the W3C) will return to the Working Group who are
> involved with this API with the questions, and I will ensure you also hear
> whatever answers we receive. That may take a more than a day or so, but this
> remains on my Work List until such time as it is resolved, so please stand by.
> 
> Thanks again for taking the time to review this.
> 
> JF
> ​--
> John Foliot
> Principal Accessibility Strategist
> Austin, TX
> 
> Deque Systems Inc.
> 2121 Cooperative Way, Suite 210,
> Herndon, VA 20171-5344
> Office: 703-225-0380
> john.foliot@deque.com<mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion
> 
> 
> 
> From: Jost Eckhardt 
> Sent: Thursday, April 14, 2016 1:48 PM
> To: John Foliot <john.foliot@deque.com>
> Cc: Aaron Leventhal; Seth Holladay; Brian Lima; Fred
> Lichtenfels 
> 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?
> 
> Thanks,
> Jost
> 
> ----------------------------------------------------------
> Jost Eckhardt
> VP of Engineering
> (802) 367-6120
> ----------------------------------------------------------
>

Received on Wednesday, 20 April 2016 22:08:32 UTC