- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Thu, 14 Apr 2011 13:04:05 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Paul Cotton <Paul.Cotton@microsoft.com>, public-canvas-api@w3.org, public-canvas-api-request@w3.org, public-html@w3.org, public-html-a11y@w3.org, Sam Ruby <rubys@intertwingly.net>
- Message-ID: <OFB3CC0278.194FD7B8-ON86257872.0062C83F-86257872.00634044@us.ibm.com>
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
Received on Thursday, 14 April 2011 18:04:54 UTC