Re: Issues the chairs overlooked in their review of the canvas accessibility API proposal for Issue 131

Rich Schwerdtfeger
CTO Accessibility Software Group

public-canvas-api-request@w3.org wrote on 04/14/2011 12:42:33 PM:

> From: Maciej Stachowiak <mjs@apple.com>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Paul Cotton <Paul.Cotton@microsoft.com>, Sam Ruby
> <rubys@intertwingly.net>, public-html@w3.org, public-canvas-
> api@w3.org, public-html-a11y@w3.org
> Date: 04/14/2011 12:49 PM
> Subject: Re: Issues the chairs overlooked in their review of the
> canvas  accessibility  API proposal for Issue 131
> Sent by: public-canvas-api-request@w3.org
>
> Hi Rich,
>
> Thanks for your input. It seems your note provides new information,
> namely the section 508-based rationale for the canDrawCustom change.
> The Chairs will discuss the matter on our Monday call, and will take
> it under consideration as a request to reopen based on new information.
>

Thank you. If you agree with the change related to canDrawCustom we will
clarify baseline in a modified change proposal as requested.

> I also have some questions about two parts of your note:
>
> On Apr 14, 2011, at 7:46 AM, Richard Schwerdtfeger wrote:
>
> 2. The chairs decision to keep the existing drawFocusRing creates a
> problem in that the function can not be used to drive a magnifier as
> it draws an unneeded focus ring. The function also provides no
> guidance as to how the user agent is to use this information to
> drive a magnifier. For the same reason it does not allow an author
> to use the X, Y position to drive a magnifier during the selection
> process. Our proposal does and explains how a user agent is to drive
> a magnifier.
>
> For these reasons, why is the existing drawFocusRing function a
> better solution for driving a magnifer when moving a caret and the
> user's selection position?
> It seems like this is referring to the aspect of your proposal that
> asks for a separate setCaretSelectionRect call to be added, instead
> of using drawFocusRing to report caret position. If so, then this
> change was in fact adopted by the decision The arguments relating to
> this point are addressed in the section of the decision labeled
> "Objections regarding a single call or separate calls for caret and
> focus ring". It seems like the argument you mention was addressed,
> and was the prevailing argument.
>
> Is that what you had in mind? If so, does this address your concerns?
>
>
Yes.

> 3. The chairs ignored bullet 1 of the details section of the Change
> Proposal which was to address a request from magnifier vendors to
> have the with and height of the caret or selection position to
> better position the magnifier at high magnification levels:
> "moved to setting of the caret and selection position to a separate
> API from DrawFocusRing to a separate API called setCaretSelectionPos
> that takes x, y, w, h parameters to define the caret selection
> position being reported to the browser to pass on the the platform
> accessibility API services. The additional width and height of the
> caret will allow user agents to better assist screen magnifiers in
> positioning the zoom position at large magnification levels with
> combined with the semantic information provided by the corresponding
> element passed from fallback content."
> The current specification for focus ring does not address this.
> The change to have setCaretSelectionPos that takes x,y,w,h
> parameters *was* adopted by the decision. The arguments relating to
> this point are addressed in the section of the decision labeled
> "Objections regarding API to report the bounds of the caret vs just
> a point". It seems like the argument you mention was addressed, and
> was the prevailing argument.
>
> Is that what you had in mind? If so, does this address your concerns?
>
Yes.

> Regards,
> Maciej