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

Thanks, we'll take this as input into the request to reopen the issue.

Regards,
Maciej

On Apr 15, 2011, at 1:01 PM, Richard Schwerdtfeger wrote:

> Hi Maciej,
> 
> We have updated the original change request for Issue 131 (http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection) include:
> 
> - to include the 508 Rationale, etc.
> - to include a clarification the text baseline request. Note: in bug report 11239 we made a reference to Webkit code to see how the change would apply (Charles Pritchard on 4/13)
> - changed the return value for blink rate from an int to a WebIDL long. Ian had mentioned this to be an oversight on one of the discussion groups.
> 
> Hopefully, that will address the chairs' concerns. 
> 
> Best Regards,
> Rich
> 
> 
> Rich Schwerdtfeger
> CTO Accessibility Software Group
> 
> <graycol.gif>Maciej Stachowiak ---04/14/2011 12:49:31 PM---Hi Rich, Thanks for your input. It seems your note provides new information, namely the section 508-
> 
> 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.
> 
> 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?
> 
> 
> 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?
> 
> 
> Regards,
> Maciej
> 
> 
> 
> 
>