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

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



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