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

Rich Schwerdtfeger
CTO Accessibility Software Group

public-html-a11y-request@w3.org wrote on 04/18/2011 04:03:26 PM:

> From: Sam Ruby <rubys@intertwingly.net>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: Maciej Stachowiak <mjs@apple.com>, 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
> Date: 04/18/2011 04:10 PM
> Subject: Re: Issues the chairs overlooked in their review of the
> canvas  accessibility   API proposal for Issue 131
> Sent by: public-html-a11y-request@w3.org
>
> On 04/15/2011 04: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.
>
> Looking at the decision, there is two remaining comments that have not
> been addressed:
>
> > In addition, another objection to this aspect of the "Modify existing
> > Canvas 2D API caret and focus ring support" was that it makes focus
> > handling and caret selection inconsistent in an undesirable way;
> > authors cannot go with all native-style drawing or all custom-drawing
> > but would be forced to use a mix
>
> We would like to request that the Change Proposal be updated to either
> showing that there is no inconsistency, or by giving the justification
> for the inconsistency.
>
The current specification of drawFocusRing will draw the system focus ring
if a system style is set and that a magnifier's zoom location can be driven
by the call. However, if a system style for the focus ring is not set and
canDrawCustom is passed the function returns with nothing is drawn and the
magnifier is not notified of the focus ring to zoom to. The function
returns and a custom ring is then drawn by the author without the ability
to drive the magnifier.

With the change proposal, the author is responsible for setting up the ring
drawing style, for the path, prior to the drawFocusRing call. If the author
uses drawFocusRing() as specified in the change proposal the user agent
will draw the system style focus ring if such a setting exists, otherwise
it will draw the custom focus ring configured before the call.  Regardless
of which styling is used along the drawing path the magnifier zoom will be
driven by this call and the user agent will consistently use the system
styling for focus ring if one exists (such as high contrast styling) and if
such system setting does not exist the user agent will draw the focus ring
styling specified by the author prior to the call. If there is no native
styling then all custom drawing will be supported by the call and the
magnifier will be able to track the user.

As for caret tracking, neither the current specification or the change
proposal effects the drawing of a caret or a selection position. This is
consistent.

I will make sure these points are made in the change proposal.

> Additionally, the following was not found to make its case:
>
> > DrawFocusRing does not ensure that the focus ring, drawn, allows
> > the browser to follow focus ring conventions for the OS platform
> > that may also reflect user's preferences
>
> Can you clarify why the "Modify existing Canvas 2D API caret and focus
> ring support proposal" makes it impossible to draw focus without driving
> magnification?
>
Yes, that is made clear in the change proposal in Rationale bullet 2: "If
the author sets canDrawCustom to true and the operating system has not
specified out a focus ring is to be drawn, that drawing is turned over to
the author. Therefore the specification allows the author to draw focus
without driving magnification. "

Ordinary path drawing functions in canvas do not drive the magnifier and
drawFocusRing can't drive a magnifier in the situation where it does not
actually draw the focus ring as the author could actually draw the path
elsewhere and magnification could not accurately follow the new location.

I will update the change proposal with this added text.

> - Sam Ruby
>